🥇Voor een beginnende systeembeheerder: hoe je orde in de chaos kunt scheppen

Ik ben FirstVDS systeembeheerder en dit is de tekst van de eerste inleidende lezing van mijn korte cursus over het helpen van beginnende collega's. Specialisten die onlangs met systeembeheer zijn begonnen, worden met een aantal dezelfde problemen geconfronteerd. Om oplossingen te bieden, heb ik mij ertoe verbonden deze serie lezingen te schrijven. Sommige dingen daarin zijn specifiek voor het hosten van technische ondersteuning, maar over het algemeen kunnen ze nuttig zijn, zo niet voor iedereen, dan voor velen. Daarom heb ik de tekst van de lezing aangepast om hier te delen.

Het maakt niet uit hoe uw functie heet; het gaat erom dat u feitelijk betrokken bent bij de administratie. Laten we daarom beginnen met wat een systeembeheerder moet doen. Zijn belangrijkste taak is om orde op zaken te stellen, de orde te handhaven en zich op orde voor te bereiden op toekomstige stijgingen. Zonder een systeembeheerder wordt de server een puinhoop. Logboeken worden niet geschreven, of er worden verkeerde dingen in geschreven, bronnen worden niet optimaal verdeeld, de schijf is gevuld met allerlei soorten afval en het systeem begint langzaam dood te gaan door zoveel chaos. Rustig! Systeembeheerders in uw persoon beginnen problemen op te lossen en de rommel te elimineren!

Pijlers van systeembeheer

Voordat u echter problemen begint op te lossen, is het de moeite waard om vertrouwd te raken met de vier belangrijkste pijlers van bestuur:

Documentatie
Sjablonen
Optimalisatie
Automatisering

Dit is de basis. Als u uw workflow niet op deze principes baseert, zal deze ineffectief en onproductief zijn en over het algemeen weinig gelijkenis vertonen met echte administratie. Laten we ze allemaal afzonderlijk bekijken.

Документация

Документация betekent niet het lezen van documentatie (hoewel je niet zonder kunt), maar ook het onderhouden ervan.

Documentatie bewaren:

Bent u een nieuw probleem tegengekomen dat u nog nooit eerder heeft gezien? Noteer de belangrijkste symptomen, diagnosemethoden en eliminatieprincipes.
Heeft u een nieuwe, elegante oplossing bedacht voor een veelvoorkomend probleem? Schrijf het op, zodat je het over een maand niet opnieuw hoeft uit te vinden.
Hebben ze je geholpen een vraag te bedenken die je niet begreep? Schrijf de belangrijkste punten en concepten op, teken een diagram voor jezelf.

Het hoofdidee: je moet niet volledig op je eigen geheugen vertrouwen bij het beheersen en toepassen van nieuwe dingen.

In welk formaat je dit doet, bepaal je zelf: het kan een systeem zijn met notities, een persoonlijke blog, een tekstbestand, een fysiek notitieblok. Het belangrijkste is dat uw administratie aan de volgende eisen voldoet:

Wees niet te lang. Markeer de belangrijkste ideeën, methoden en hulpmiddelen. Als het begrijpen van een probleem vereist dat je in de basismechanismen van geheugentoewijzing in Linux duikt, herschrijf dan niet het artikel waaruit je het hebt geleerd; geef er een link naar.
De vermeldingen moeten voor u duidelijk zijn. Als de lijn race cond.lockup staat je niet toe om meteen te begrijpen wat je met deze regel hebt beschreven - leg uit. Het kost geen half uur om goede documentatie te begrijpen.
Zoeken is een zeer goede functie. Als je blogposts schrijft, voeg dan tags toe; plak in een fysiek notitieboekje kleine post-its met beschrijvingen. Documenteren heeft weinig zin als je evenveel tijd besteedt aan het zoeken naar een antwoord als aan het helemaal opnieuw oplossen van de vraag.

Zo kan documentatie eruit zien: van primitieve aantekeningen in een kladblok (foto hierboven) tot een volwaardige multi-user kennisbank met tags, zoeken en alle mogelijke gemakken (hieronder).

Niet alleen hoef je niet twee keer naar dezelfde antwoorden te zoeken, maar documenteren zal een grote hulp zijn bij het leren van nieuwe onderwerpen (aantekeningen!), het zal je spider-sense verbeteren (het vermogen om een complex probleem met één oppervlakkige blik te diagnosticeren), en zal organisatie aan uw acties toevoegen. Als de documentatie beschikbaar is voor uw collega's, kunnen zij erachter komen wat en hoe u zich daar heeft opgestapeld als u er niet bent.

Sjablonen

Sjablonen is het maken en gebruiken van sjablonen. Om de meeste typische problemen op te lossen, is het de moeite waard om een specifiek actiesjabloon te maken. Voor het diagnosticeren van de meeste problemen moet een gestandaardiseerde reeks stappen worden gebruikt. Wanneer je iets hebt gerepareerd/geïnstalleerd/geoptimaliseerd, moet de prestatie ervan worden gecontroleerd aan de hand van gestandaardiseerde checklists.

Sjablonen zijn de beste manier om uw workflow te organiseren. Door standaardprocedures te gebruiken om de meest voorkomende problemen op te lossen, krijg je veel coole dingen. Met behulp van checklists kunt u bijvoorbeeld alle functies diagnosticeren die belangrijk zijn voor uw werk en de diagnose van onbelangrijke functionaliteit terzijde schuiven. En gestandaardiseerde procedures zullen onnodig gooien tot een minimum beperken en de kans op fouten verkleinen.

Het eerste belangrijke punt is dat ook procedures en checklists gedocumenteerd moeten worden. Als u alleen maar op uw geheugen vertrouwt, kunt u een heel belangrijke controle of handeling missen en alles verpesten. Het tweede belangrijke punt is dat alle sjabloonpraktijken kunnen en moeten worden aangepast als de situatie dit vereist. Er zijn geen ideale en absoluut universele sjablonen. Als er een probleem is, maar een sjablooncontrole heeft dit niet aan het licht gebracht, betekent dit niet dat er geen probleem is. Voordat u echter enkele onwaarschijnlijke hypothetische problemen gaat testen, is het altijd de moeite waard eerst een snelle sjabloontest uit te voeren.

Optimalisatie

Optimalisatie spreekt voor zich. Het werkproces moet zoveel mogelijk worden geoptimaliseerd in termen van tijd en arbeidskosten. Er zijn talloze opties: leer sneltoetsen, afkortingen, reguliere expressies, beschikbare tools. Zoek naar meer praktische toepassingen van deze hulpmiddelen. Als u een opdracht 100 keer per dag oproept, wijst u deze toe aan een sneltoets. Als u regelmatig verbinding moet maken met dezelfde servers, schrijf dan een alias in één woord waarmee u daar naartoe kunt verbinden:

Maak uzelf vertrouwd met de verschillende opties die beschikbaar zijn voor tools - misschien is er een handiger terminalclient, DE, klembordmanager, browser, e-mailclient, besturingssysteem. Ontdek welke tools uw collega's en vrienden gebruiken - misschien kiezen ze deze met een reden. Zodra u over de hulpmiddelen beschikt, leert u hoe u ze kunt gebruiken: leer de sleutels, afkortingen, tips en trucs.

Maak optimaal gebruik van standaardtools - coreutils, vim, reguliere expressies, bash. Voor de laatste drie zijn er een groot aantal prachtige handleidingen en documentatie. Met hun hulp kun je snel overgaan van de toestand van ‘Ik voel me een aap die noten kraakt met een laptop’ naar ‘Ik ben een aap die een laptop gebruikt om voor mezelf een notenkraker te bestellen.’

Automatisering

Automatisering zal moeilijke handelingen van onze vermoeide handen overbrengen naar de onvermoeibare handen van de automatisering. Als er een standaardprocedure wordt uitgevoerd in vijf commando's van hetzelfde type, waarom zouden we dan niet al deze commando's in één bestand verpakken en één commando aanroepen dat dit bestand downloadt en uitvoert?

Automatisering zelf bestaat voor 80% uit het schrijven en optimaliseren van je eigen tools (en nog eens 20% probeert ze naar behoren te laten werken). Het kan gewoon een geavanceerde oneliner zijn of een enorme almachtige tool met een webinterface en API. Het belangrijkste criterium hierbij is dat het maken van een tool niet meer tijd en moeite mag kosten dan de hoeveelheid tijd en moeite die de tool je zal besparen. Als u vijf uur besteedt aan het schrijven van een script dat u nooit meer nodig zult hebben, voor een taak die u zonder het script een uur of twee zou hebben gekost om op te lossen, is dit een zeer slechte workflowoptimalisatie. Je kunt alleen vijf uur besteden aan het maken van een tool als het aantal, het soort taken en de tijd het toelaten, wat niet vaak het geval is.

Automatisering betekent niet noodzakelijkerwijs het schrijven van volwaardige scripts. Om bijvoorbeeld een aantal objecten van hetzelfde type uit een lijst te maken, is een slimme oneliner voldoende, die automatisch doet wat u met de hand zou doen: schakelen tussen vensters, met een hoop kopiëren en plakken.

Als u het administratieproces op deze vier pijlers bouwt, kunt u uw efficiëntie, productiviteit en kwalificaties snel verhogen. Deze lijst moet echter worden aangevuld met nog een item, zonder welk werken in de IT bijna onmogelijk is: zelfstudie.

Zelfstudie systeembeheerder

Om zelfs maar een beetje bekwaam te zijn op dit gebied, moet je voortdurend nieuwe dingen studeren en leren. Als je niet het minste verlangen hebt om het onbekende onder ogen te zien en erachter te komen, zul je heel snel vastlopen. Er verschijnen voortdurend allerlei nieuwe oplossingen, technologieën en methoden in de IT, en als je ze niet op zijn minst oppervlakkig bestudeert, ben je op weg naar mislukking. Veel gebieden van de informatietechnologie hebben een zeer complexe en omvangrijke basis. Bijvoorbeeld netwerkbeheer. Netwerken en internet zijn overal, je komt ze elke dag tegen, maar als je je eenmaal verdiept in de technologie erachter, zul je een enorme en zeer complexe discipline ontdekken, waarvan de studie nooit een wandeling in het park is.

Ik heb dit item niet in de lijst opgenomen omdat het essentieel is voor IT in het algemeen, en niet alleen voor systeembeheer. Natuurlijk kun je niet meteen alles leren; fysiek heb je simpelweg niet genoeg tijd. Daarom moet u bij het opleiden van uzelf de noodzakelijke abstractieniveaus onthouden.

Je hoeft niet meteen te leren hoe het interne geheugenbeheer van elk afzonderlijk hulpprogramma werkt en hoe het samenwerkt met het Linux-geheugenbeheer, maar het is goed om schematisch te weten wat RAM is en waarom het nodig is. U hoeft niet te weten hoe TCP- en UDP-headers structureel verschillen, maar het zou een goed idee zijn om de fundamentele verschillen in de manier waarop de protocollen werken te begrijpen. Je hoeft niet te leren wat signaalverzwakking in de optica is, maar het zou leuk zijn om te weten waarom echte verliezen altijd over de knooppunten heen worden geërfd. Er is niets mis mee om te weten hoe bepaalde elementen werken op een bepaald abstractieniveau en niet noodzakelijkerwijs alle niveaus te begrijpen als er helemaal geen abstractie is (je wordt gewoon gek).

In jouw vakgebied is het denken op abstractieniveau “nou, dit is iets waarmee je websites kunt weergeven” echter niet erg goed. De volgende lezingen zullen gewijd zijn aan een overzicht van de belangrijkste gebieden waarmee een systeembeheerder te maken krijgt als hij op lagere abstractieniveaus werkt. Ik zal proberen de hoeveelheid beoordeelde kennis te beperken tot een minimaal abstractieniveau.

10 geboden van systeembeheer

We hebben dus de vier belangrijkste pijlers en fundamenten geleerd. Kunnen we beginnen met het oplossen van problemen? Nog niet. Voordat u dit doet, is het raadzaam om vertrouwd te raken met de zogenaamde “best practices” en regels voor goede manieren. Zonder hen doe je waarschijnlijk meer kwaad dan goed. Dus laten we beginnen:

Sommige van mijn collega’s zijn van mening dat de allereerste regel ‘doe geen kwaad’ is. Maar ik ben geneigd het daar niet mee eens te zijn. Als je probeert geen kwaad te doen, kun je niets doen; te veel acties zijn potentieel destructief. Ik denk dat de belangrijkste regel is: “maak een back-up”. Zelfs als je wat schade aanricht, kun je altijd terugdraaien en alles zal niet zo erg zijn.
U moet altijd een back-up maken wanneer tijd en plaats dit toelaten. U moet een back-up maken van wat u gaat veranderen en wat u dreigt te verliezen als gevolg van een potentieel destructieve actie. Het is raadzaam om de back-up te controleren op integriteit en de aanwezigheid van alle benodigde gegevens. De back-up mag niet onmiddellijk worden verwijderd nadat u alles hebt gecontroleerd, tenzij u schijfruimte moet vrijmaken. Als de locatie dit vereist, maakt u een back-up op uw persoonlijke server en verwijdert u deze na een week.
De tweede belangrijkste regel (die ik zelf vaak overtreed) is "niet verbergen". Als je een back-up hebt gemaakt, schrijf dan waar, zodat je collega’s daar niet naar hoeven te zoeken. Als u een aantal niet voor de hand liggende of complexe acties hebt uitgevoerd, schrijf deze dan op: u gaat naar huis en het probleem kan zich herhalen of zich voor iemand anders voordoen, en uw oplossing zal worden gevonden met behulp van trefwoorden. Zelfs als u iets doet wat u goed kent, kunnen uw collega's dat niet doen.
De derde regel hoeft niet uitgelegd te worden: “Doe nooit iets waarvan je de gevolgen niet kent, voorstelt of begrijpt”. Kopieer geen opdrachten van internet als u niet weet wat ze doen, bel man en analyseer ze eerst. Gebruik geen kant-en-klare oplossingen als u niet begrijpt wat ze doen. Beperk de uitvoering van versluierde code tot een absoluut minimum. Als je geen tijd hebt om erachter te komen, dan doe je iets verkeerd en moet je het volgende punt lezen.
"Test". Nieuwe scripts, tools, oneliners en commando's moeten worden getest in een gecontroleerde omgeving, en niet op de clientcomputer, als er zelfs maar een minimale kans is op destructieve acties. Zelfs als je van alles een back-up hebt gemaakt (en dat heb je gedaan), is downtime niet het coolste. Maak hiervoor een aparte server/virtual/chroot aan en test daar. Is er iets kapot? Dan kun je het op "gevecht" starten.
"Controle". Minimaliseer alle handelingen waar u geen controle over heeft. Eén pakketafhankelijkheidscurve kan de helft van het systeem naar beneden trekken, en de vlag -y die is ingesteld voor yum remove geeft u de mogelijkheid om uw vaardigheden op het gebied van systeemherstel vanaf het begin te oefenen. Als de actie geen ongecontroleerde alternatieven kent, is het volgende punt een kant-en-klare back-up.
"Rekening". Controleer de gevolgen van uw acties en of u terug moet naar een back-up. Controleer of het probleem daadwerkelijk is opgelost. Controleer of de fout wordt gereproduceerd en onder welke omstandigheden. Ga na wat je kunt breken met je acties. Het is niet nodig om op ons werk te vertrouwen, maar het nooit te controleren.
"Communiceren". Mocht je het probleem niet kunnen oplossen, vraag dan aan je collega’s of zij dit zijn tegengekomen. Als u een controversieel besluit wilt toepassen, vraag dan naar de mening van uw collega's. Wellicht bieden zij een betere oplossing. Als u geen vertrouwen heeft in uw acties, bespreek deze dan met uw collega's. Ook al is dit jouw vakgebied, een frisse blik op de situatie kan veel verhelderen. Schaam u niet voor uw eigen onwetendheid. Het is beter om een domme vraag te stellen, er als een dwaas uit te zien en een antwoord te krijgen, dan de vraag niet te stellen, geen antwoord te krijgen en uiteindelijk een dwaas te zijn.
“Weiger hulp niet op onredelijke wijze”. Dit punt is het omgekeerde van het vorige. Als je een domme vraag wordt gesteld, verduidelijk en leg het uit. Ze vragen om het onmogelijke - leggen uit dat het onmogelijk is en waarom, bieden alternatieven. Als je geen tijd hebt (er is echt geen tijd, geen verlangen), zeg dan dat je een dringende vraag hebt, een grote hoeveelheid werk, maar dat je het later wel zult uitzoeken. Als collega's geen dringende taken hebben, bied dan aan contact met hen op te nemen en de vraag te delegeren.
"Geef feedback". Heeft een van uw collega's een nieuwe techniek of een nieuw script in gebruik genomen en ondervindt u negatieve gevolgen van deze beslissing? Rapporteer het. Misschien kan het probleem worden opgelost in drie regels code of in vijf minuten om de techniek te verfijnen. Bent u een bug in uw software tegengekomen? Rapporteer een bug. Als het reproduceerbaar is of niet hoeft te worden gereproduceerd, zal het hoogstwaarschijnlijk worden opgelost. Geef uw wensen, suggesties en opbouwende kritiek door en stel vragen ter discussie als deze relevant lijken.
"Vraag om feedback". We zijn allemaal onvolmaakt, net als onze beslissingen, en de beste manier om de juistheid van uw beslissing te testen is door deze ter discussie te stellen. Als je iets hebt geoptimaliseerd voor een klant, vraag hem of haar dan om het werk te monitoren; misschien zit het knelpunt in het systeem niet waar je naar op zoek was. U heeft een helpscript geschreven. Laat het aan uw collega's zien, misschien vinden zij een manier om het te verbeteren.

Als u deze praktijken voortdurend in uw werk toepast, zullen de meeste problemen ophouden problemen te zijn: u zult niet alleen het aantal van uw eigen fouten en fack-ups tot een minimum beperken, maar u zult ook de mogelijkheid hebben om fouten te corrigeren (in de vorm van back-ups en collega’s die u adviseren om een back-up te maken). Verder - alleen technische details, waarin, zoals we weten, de duivel ligt.

De belangrijkste tools waarmee je meer dan 50% van de tijd zult moeten werken zijn grep en vim. Wat kan eenvoudiger? Tekst zoeken en tekst bewerken. Zowel grep als vim zijn echter krachtige multitools waarmee u tekst efficiënt kunt zoeken en bewerken. Als je in een Windows-kladblok eenvoudig een regel kunt schrijven/verwijderen, dan kun je in vim bijna alles met tekst doen. Als je me niet gelooft, bel dan het vimtutor-commando vanaf de terminal en begin met leren. Wat grep betreft, de grootste kracht ligt in reguliere expressies. Ja, met de tool zelf kun je vrij flexibel zoekvoorwaarden instellen en gegevens uitvoeren, maar zonder RegExp heeft dit weinig zin. En je moet reguliere expressies kennen! In ieder geval op basisniveau. Om te beginnen zou ik u aanraden hiernaar te kijken video, behandelt het de basisprincipes van reguliere expressies en hun gebruik in combinatie met grep. Oh ja, als je ze combineert met vim, krijg je de ULTIEME KRACHT om zulke dingen met tekst te doen dat je ze moet labelen met meer dan 18 pictogrammen.

Van de resterende 50% komt 40% uit de coreutils-toolkit. Voor coreutils kunt u de lijst bekijken op wikipedia, en de handleiding voor de hele lijst staat op de website GNU. Wat niet in deze set wordt behandeld, zit in de hulpprogramma's POSIX. Je hoeft niet alle toetsen uit je hoofd te leren, maar het is wel handig om in ieder geval ongeveer te weten wat de basisinstrumenten kunnen doen. Je hoeft het wiel niet opnieuw uit te vinden vanuit krukken. Op de een of andere manier moest ik regeleinden vervangen door spaties in de uitvoer van een of ander hulpprogramma, en mijn zieke brein bracht een constructie als sed ':a;N;$!ba;s/n/ /g', kwam een collega naar voren en reed me met een bezem weg van de console, en loste het probleem vervolgens op door te schrijven tr 'n' ' '.

Ik zou je willen aanraden om te onthouden wat elk afzonderlijk gereedschap doet en wat de toetsen zijn voor de meest gebruikte commando's; voor al het andere is er de mens. Bel gerust man als u twijfelt. En zorg ervoor dat je de man zelf leest: deze bevat belangrijke informatie over wat je zult vinden.

Als u deze hulpmiddelen kent, kunt u een aanzienlijk deel van de problemen die u in de praktijk tegenkomt, effectief oplossen. In de volgende lezingen zullen we bekijken wanneer we deze tools moeten gebruiken en welke raamwerken voor de onderliggende diensten en applicaties waarop ze van toepassing zijn.

FirstVDS-systeembeheerder Kirill Tsvetkov was bij je.

Bron: www.habr.com

Voor een beginnende systeembeheerder: hoe je orde in de chaos schept