Vraag Welke sysadmin-dingen moet elke programmeur weten?


Als programmeur hebben we de neiging om sysadmins als vanzelfsprekend te beschouwen. De paar keer dat ik zonder een goed systeembeheerder ben geweest, heb ik echt waardering gekregen voor wat jullie doen. Wanneer we ons in een omgeving zonder een systeembeheerder begeven, welke woorden van wijsheid kunt u ons dan aanbieden?


96


oorsprong




antwoorden:


Ik zou beginnen met:

  1. Altijd heb een back-upsysteem van een soort. Nog beter als het een geschiedenis heeft.
  2. Overweeg enkele faalpunten en hoe hiermee om te gaan als ze falen.
  3. Afhankelijk van de hoeveelheid computers die erbij betrokken is, zal het zoeken naar en maken van een standaardafbeelding op verschillende computers ieders leven gemakkelijker maken - nee "het werkt op de mijne" omdat ze zo'n en dergelijk programma normaal gesproken niet hebben geïnstalleerd.
  4. Document alles, alleen al vanwege jou zullen vergeet hoe je iets opzet.
  5. Blijf op de hoogte van beveiligingsupdates.

70



het documenteren van alle stappen is iets wat ik goede sysadmins heb zien doen en ik ben er zelf mee begonnen. Zeer nuttig, inderdaad. - Nathan DeWitt
Overweeg zelfdocumenterende systemen. Waarom zou u bijvoorbeeld een lijst met hostnamen ergens in een tekstbestand of wiki bewaren als een zonebekendgemaakt zonebestand de standaard informatiebron is? - Dave Cheney
Dave, is dat goed-gecommenteerde zonebestand voor iedereen toegankelijk? Als ik een nieuwe persoon ben die aan boord komt, is het niet eenvoudiger om te horen "ga naar deze wiki voor al je antwoorden" in plaats van "alles is overal gedocumenteerd." DNS is gedocumenteerd in DNS-instellingen De whozit is gedocumenteerd in de whozit configuratiebestand.De database is gedocumenteerd in het databaseconfiguratiebestand. " Dat lijkt erg ... onvriendelijk tegen mij. - Nathan DeWitt
Nathan, Dave: De kunst is natuurlijk om een ​​script te gebruiken om de wiki van de canonieke bron bij te werken. Het heeft wonderen voor me gedaan, het spijt me echt dat ik het niet kan gebruiken waar ik nu werk. - Anders Eurenius
Ik zou hieraan willen toevoegen: Bouw een testsysteem. U hebt een omgeving nodig waar falen een optie is. Ik heb hiervoor een server waarop VirtualBox wordt uitgevoerd, maar ik heb mijn persoonlijke werkstation gebruikt wanneer er geen servers beschikbaar zijn - Mark Porter


<voeg hier grote bericht disclaimer in>

Sommige hiervan zijn al eerder gezegd, maar het is voor herhaling vatbaar.

Documentatie:

  • Document alles. Als je er geen hebt, installeer dan een wiki onder de radar, maar zorg ervoor dat je een back-up maakt. Begin met het verzamelen van feiten, en op een dag zal er een grote foto ontstaan.

  • Maak diagrammen voor elk logisch blok en houd ze bijgewerkt. Ik kon niet tellen hoeveel keer een nauwkeurige netwerkkaart of clusterdiagram me heeft bewaard.

  • Bewaar logboeken voor elk systeem, ook al zijn het alleen kopieer- en plakopdrachten voor het bouwen ervan.

  • Bij het bouwen van uw systeem installeert en configureert u uw apps, test u deze en werkt u uw benchmarking uit. Veeg de schijven nu af. Ernstig. 'dd' de eerste megabyte van de voorkant van de schijven of anderszins maakt het vak niet meer opstartbaar. De klok tikt: bewijs dat uw documentatie het helemaal opnieuw kan opbouwen (of, nog beter, bewijzen dat uw collega niets anders kan dan uw documentatie). Dit vormt de helft van je plan voor noodherstel.

  • Nu heb je de eerste helft van je plan voor noodherstel, documenteer de rest; hoe u de status van uw toepassing terugkrijgt (bestanden terugzetten vanaf band, databases opnieuw laden vanaf stortplaatsen), details van leveranciers / support, netwerkvereisten, hoe en waar vervangende hardware te krijgen - alles wat u maar kunt bedenken helpt om uw systeem weer up-to-date te krijgen.

Automatisering:

  • Automatiseer zoveel als je kunt. Als u drie keer iets moet doen, zorg dan dat de tweede wordt besteed aan de ontwikkeling van uw automatisering, zodat de derde volledig geautomatiseerd is. Als u het niet kunt automatiseren, documenteer het dan. Er zijn automatiseringssuites die er zijn - kijk of je ze voor je kunt laten werken.

Toezicht houden:

  • Applicatie-instrumentatie is puur goud. Door transacties in het systeem te kunnen bekijken, wordt het debuggen en het oplossen van problemen eenvoudiger.

  • Maak end-to-end tests die niet alleen bewijzen dat de applicatie nog leeft, maar echt doen wat het zou moeten doen. Punten zijn van jou als het kan worden opgevijzeld in het monitoringsysteem voor waarschuwingsdoeleinden. Dit dient dubbele dienst; afgezien van het bewijzen dat de app werkt, maakt het systeemupgrades aanzienlijk eenvoudiger (monitoringsysteem meldt groen, upgrade werkte, tijd om naar huis te gaan).

  • Benchmark, monitor en verzamel statistieken over alles wat normaal is om dit te doen. Benchmarks vertellen u wanneer u kunt verwachten dat iets de magische rook zal laten ontsnappen. Monitoring vertelt u wanneer het heeft. Metrics en statistieken maken het gemakkelijker om nieuwe kit (met verse magische rook) te krijgen via het management.

  • Als u geen monitoringsysteem heeft, implementeer er dan een. Bonuspunten als u de bovengenoemde end-to-end-tests daadwerkelijk uitvoert.

Veiligheid:

  • "chmod 777" (ook bekend als alle toegang / privileges verlenen) is nooit de oplossing.

  • Abonneer u op het 'least bit'-principe; als het niet is geïnstalleerd, gekopieerd of anderszins op de schijf leeft, kan het niet in gevaar komen. "Kitchen sink" OS en software-installaties kunnen het leven gemakkelijker maken tijdens de bouwfase, maar u betaalt er uiteindelijk voor.

  • Weet waar elke open poort op een server voor is. Controleer ze regelmatig om er zeker van te zijn dat er geen nieuwe verschijnen.

  • Probeer niet een besmette server schoon te maken; het moet helemaal opnieuw worden opgebouwd. Opnieuw opbouwen naar een reserveserver met vers gedownloade media, alleen de gegevens van back-ups herstellen (omdat de binaries mogelijk in gevaar zijn) of de gehackte host naar een geïsoleerde locatie klonen zodat u deze opnieuw kunt samenstellen op dezelfde kit. Er is een hele juridische nachtmerrie omheen, dus vergis je aan de kant van het bewaren voor het geval je juridische wegen moet volgen. (Opmerking: IANAL).

Hardware:

  • Ga er nooit van uit dat iets zal doen wat het op de doos zegt. Bewijs dat het doet wat je nodig hebt, voor het geval dat niet het geval is. Je merkt dat je vaker zegt "het werkt bijna" dan je zou verwachten.

  • Beknibbel niet op extern hardwarebeheer. Seriële consoles en lichtmanagement moeten als verplicht worden beschouwd. Bonuspunten voor op afstand gestuurde stroomstroken voor die momenten waarop u geen opties meer heeft.

(Terzijde: er zijn twee manieren om een ​​probleem om 3 uur op te lossen, een daarvan is warm zijn, op een laptop werken via een VPN in je pyjama, de andere betreft een dikke jas en een rit naar het datacenter / kantoor. verkiezen.)

Project management:

  • Betrek de mensen die het systeem zullen onderhouden vanaf de eerste dag van de levenscyclus van het project. De doorlooptijden op kit en hersentijd kunnen en zullen verrassen, en er is geen twijfel dat ze (zouden?) Normen of vereisten moeten hebben die projectafhankelijkheden worden.

  • Documentatie is onderdeel van het project. U krijgt nooit de tijd om alles op te schrijven nadat het project is afgesloten en het systeem is verplaatst naar onderhoud. Zorg er dus voor dat het bij het begin als inspanning in het schema wordt opgenomen.

  • Implementeer geplande veroudering vanaf de eerste dag in het project en start de verversingscyclus zes maanden vóór de uitschakelingsdag die u in de projectdocumentatie hebt opgegeven.

Servers hebben een gedefinieerde levensduur wanneer ze geschikt zijn voor gebruik in de productie. Het einde van deze levensduur wordt meestal gedefinieerd als wanneer de verkoper meer gaat opladen in het jaarlijkse onderhoud dan het zou kosten om de kit te vernieuwen, of ongeveer drie jaar, naargelang wat het kortste is. Na die tijd zijn ze ideaal voor ontwikkel- / testomgevingen, maar u moet er niet op vertrouwen om het bedrijf te runnen. Als je de omgeving na 2 1/2 jaar opnieuw bezoekt, heb je voldoende tijd om door de benodigde management- en financiële hoepels te springen voor nieuwe kit die moet worden besteld en om een ​​soepele migratie te implementeren voordat je de oude kit naar de grote leverancier in de lucht stuurt.

Ontwikkeling:

  • Zorg ervoor dat uw ontwikkelings- en staging-systemen op productie lijken. VM's of andere virtualisatietechnieken (zones, LDOM's, vservers) maken real-world-in-alles-zintuig-maar-prestatie productie klonen eenvoudig.

backups

  • Gegevens waarvan u geen back-up maakt, zijn gegevens die u niet wilt. Dit is een onveranderlijke wet. Zorg ervoor dat je realiteit overeenkomt met deze.

  • Back-ups zijn moeilijker dan ze eruitzien; sommige bestanden zullen open of gesloten zijn, terwijl andere moeten worden afgesloten om enige hoop op herstel te hebben en al deze problemen moeten worden aangepakt. Sommige back-uppakketten hebben agents of andere methoden om met open / vergrendelde bestanden om te gaan, andere pakketten niet. Databases naar schijf dumpen en deze back-uppen telt als één vorm van "quiescing", maar het is niet de enige methode.

  • Back-ups zijn waardeloos, tenzij ze worden getest. Trek om de paar maanden een willekeurige tape uit de archieven, zorg ervoor dat deze daadwerkelijk gegevens bevat en de gegevens consistent zijn.

En het belangrijkst ...

Kies je faalwijzen, of Murphy zal ... en Murphy werkt niet volgens jouw planning.

Ontwerp voor mislukking, documenteer de door elk systeem ontworpen zwakke punten, wat hen triggert en hoe te herstellen. Het maakt het verschil als er iets misgaat.


44



+1 Het is alsof iemand in mijn gedachten keek - en het was prachtig; p - Oskar Duveborn
"Benchmark, monitor en verzamel statistieken over alles wat normaal is om dit te doen." Benchmarks vertellen wanneer je mag verwachten dat iets de magische rook zal laten ontsnappen Monitoring vertelt je wanneer het is Metrics en statistieken maken het gemakkelijker om nieuwe kit te krijgen (met verse magie rook) door het management. "  Puur goud - T.J. Crowder


Ga er niet eenvoudig van uit. Ik ken veel programmeurs die denken dat alleen omdat ze IIS of Apache op hun devbox kunnen instellen dat ze een webfarm kunnen runnen. Begrijp wat de taak inhoudt en doe onderzoek en planning, denk niet alleen dat het werk van de sysadmin het gemakkelijke is dat u in tien minuten kunt doen om uw app te implementeren.


43



+1 hiervoor. Het is niet omdat we het redden kijken makkelijk dat het eigenlijk is. - Gert M
Als een generalist die zowel admin als programmeerwerk doet, begrijp ik volledig je benarde situatie. 1 - Avery Payne
Het gaat de andere kant op natuurlijk, ik heb een paar sysadmin-typen gevonden die echt het verschil niet begrijpen tussen het soort scripts en kleine hulpprogramma's die we allemaal kunnen kloppen en "echte" programmering. - Rob Moir
+1 Robert: Of de sysadmin die zegt "het is een eenvoudige if-verklaring" om een ​​slecht ontworpen netwerkarchitectuur te omzeilen. Wederzijds respect en begrip is de sleutel. - Steven Evers


  • Realiseer je dat veel van de servers en / of netwerkapparatuur die ze neigen, net als kinderen uit een tweede gezin, steeds beter zijn. Dit zijn hun baby's.  Ze verzorgen ze, helpen hen wanneer ze ziek zijn en houden ze waakzaam in de gaten voor problemen. Deze moet niet op deze manier, maar na vele jaren, dat is het vaak. Houd hier rekening mee wanneer u uw zorgen over apparatuur communiceert die niet naar behoren functioneert of aan verwachting voldoet. En als je een antwoord krijgt dat je niet begrijpt, probeer het dan te filteren via dit wereldbeeld.
  • Wees op goede werktermen. Klinkt cheezy, maar het is zijn gewicht in goud waard. Op een dag zul je een speciale gunst nodig hebben. En op een dag zal die systeembeheerder graag zijn best doen om het leven een beetje makkelijker voor je te maken, alleen deze ene keer.
  • Die werkrelatie gaat in beide richtingen. Als de sysadmin erg druk is en je het leven een beetje gemakkelijker zou kunnen maken door een klein script of programma te schrijven, doe het dan! Ze zullen het meer waarderen dan je weet.
  • Wees heel duidelijk. "This sucks" is niet zo duidelijk als "het hebben van een intermitterende netwerkverbinding een beetje vervelend is, is er een kans dat je ernaar kunt kijken?"
  • Als je denkt dat je app zal schalen, vraag het dan aan de beheerder ervan uitgaande dat het zal. Ze kunnen iets "zien" wat u niet weet, of iets weten over de prestatielimieten van de apparatuur waarop u gaat inzetten.
  • Als uw app moet worden afgestemd, maar het lijkt geen probleem met de code te zijn, vraagt ​​u vriendelijk hoe de servers presteren. Sysadmins verzorgen hun machines liefdevol en zijn niet blij als ze "ziek" of "misdragen" zijn. Als je het mooi vraagt, wordt een noodlottige machine rond (of gerepareerd / vervangen).
  • (zoals elders vermeld) documenteer de instellingen die u gebruikt, en waarom je gebruikt ze. Het is niet handig om "selectievakje X" of "uncomment config file line Y" in te stellen. U zou de optie kunnen instellen die al uw gegevens bij de volgende herstart wist voor alles wat u weet.
  • Als u niet de tijd heeft om de instelling op papier te documenteren, probeer deze zo mogelijk in het systeem te documenteren. Bij configuratiebestanden zou dit bijna standaard moeten zijn - elke verandering van instelling moet worden gedatampeerd, met initialen, het verwachte effect van die instelling en de reden waarom het was veranderd (zie eerder opsommingsteken). Deze kleine gewoonte heeft mijn spek meer dan eens tijdens crunch-time gered. "Waarom hebben we dat gedaan?" "Omdat we beleid X hebben verplicht, en de instelling Y ons het gedrag geeft dat we nodig hebben voor beleid X".
  • Bier. Of Cola. Of zelfs water. Drankjes zijn altijd welkom. Een sysadmin zijn, is dorstig werken.

27



Voor het probleem met het configuratiebestand, documentatie / wijziging, raad ik aan om alle configuratiebestanden in een versiecontrolesysteem te plaatsen. Dit zou heel gemakkelijk voor programmeurs moeten zijn, omdat ze hopelijk al zo'n systeem gebruiken voor hun broncode. Als ze ook een opmerking toevoegen wanneer ze een wijziging doorvoeren, is het gemakkelijk om terug te gaan in de geschiedenis en te zien wat er is gewijzigd toen en waarom. - Anders Sandvig
+1 daarvoor, omdat het "de cirkel sluit" over verandermanagement. Goede suggestie. - Avery Payne
Uitstekende suggestie voor het geven van duidelijke foutmeldingen. Niets frustreert me meer dan nadat ik heb verteld dat er een probleem is en omdat ik weet dat het mogelijk veel mensen kan beïnvloeden, moet ik de details van een belangeloze programmeur plagen - Dave Cheney


Beveiliging is niet een bijzaak. Hoewel een gehackte app de programmeur incompetent kan maken, is het (ten minste) een verloren weekend besteed aan het verifiëren, opschonen en / of herstellen van back-ups voor een systeembeheerder.

Bestrijd back-ups overigens niet als versiebeheer. Ze zijn bedoeld voor noodherstel en zijn niet echt ontworpen om uw code te herstellen, omdat u bent vergeten wat u hebt gewijzigd.

En stop blindelings met het beschuldigen van Windows Updates dat je code wordt verbroken. Het kan me niet schelen dat het werkte, vertel me waarom het nu niet werkt - dan kunnen we zien wiens schuld het is.


23





Hoe netwerkproblemen te debuggen en te zien hoe uw programma wordt uitgevoerd met sysadmin-tools. Als een programmeur die is begonnen met systeembeheer, sta ik er versteld van hoe impotent veel programmeurs ooit een netwerk worden "stopt gewoon".

  • Wireshark, om uw code op een black-box manier, pakket-voor-pakket te zien lopen
  • Hulpprogramma's om rechtstreeks verbinding te maken met netwerkservices:
    • Telnet, netcat of socat voor gewone verbindingen via TCP of UDP
    • OpenSSL voor hetzelfde met encryptie (hint: proberen openssl s_client -connect target-host:port soms) voor het handmatig verbinden met netwerkdiensten
  • graven (in het BIND 9 pakket) voor het debuggen van naamomzetting
  • Kunnen vertellen welk deel van de netwerkstack is mislukt op basis van de timing en andere kenmerken van een mislukte verbinding
  • Mogelijk HTTPFox en / of Firebug

17



1. Elke ontwikkelaar die een applicatie schrijft die afhankelijk is van solide netwerkprestaties moet 'TCP / IP Illustrated v1' lezen, van wijlen groot W. Richard Stevens, voordat hij ooit begint te coderen. - Murali Suriar
Bedankt voor alle upvotes jongens. Het baalt me ​​jarenlang om programmeurs in een hulpeloze stilstand te zien zodra het onderliggende netwerk faalt. En tegenwoordig is bijna alle programmering netwerkprogrammering. - jhs


Weet hoe problemen op te lossen.

Het is heel gemakkelijk om te betalen (bijvoorbeeld, uw netwerk is mijn communicatie met de database aan het spuiten). Dit kan de fout van het netwerk zijn, maar u moet toepassingslogboeken hebben met fouten die met Google of SO een probleem in de configuratie van een app kunnen onthullen.

Iedereen houdt ervan de hardware, het besturingssysteem of het netwerk de schuld te geven, dus als je wat meer due diligence doet, wordt de systeembeheerder een gelukkig persoon. Omdat, als niets anders, u in staat zou zijn om hen in een bepaalde richting te wijzen op wat er verkeerd zou kunnen zijn (in tegenstelling tot te zeggen "uw netwerk zuigt" of iets dat even nuttig is).


14



Absoluut. Ik kan niet beginnen met het tellen van de uren die ik heb besteed aan het zoeken naar problemen op de verkeerde plaatsen door mensen die me in de richting wijzen fout richting - Gert M


Documenteer alles wat je kunt. Ik kan u niet vertellen hoe vaak het laatste systeembeheerder het leuk vond om niet iets te documenteren voor 'werkzekerheid' of iemand die gewoon in en uit wilde stappen. Net zoals een programmeur goede opmerkingen moet achterlaten, moeten sysadmins documenteren. Een diagram van de topologie zou ook leuk zijn.


8