Til den nybegyndende sysadmin: hvordan man skaber orden ud af kaos

Jeg er systemadministrator ved FirstVDS, og dette er teksten til den første introduktionsforelæsning i mit korte kursus, der hjælper nye kolleger. Specialister, der for nylig er begyndt at arbejde med systemadministration, står over for en række af de samme problemer. For at tilbyde løsninger har jeg taget mig af at skrive denne række af forelæsninger. Nogle ting i den er specifikke for teknisk support af hosting, men generelt kan de vise sig at være nyttige, hvis ikke for alle, så for mange. Derfor har jeg tilpasset tekstens indhold for at dele den her.

Det er ligegyldigt, hvad din stilling hedder — det vigtigste er, at du i realiteten beskæftiger dig med administration. Så lad os starte med, hvad en systemadministrator bør beskæftige sig med. Hans primære opgave er at bringe orden, opretholde orden og forberede sig på kommende stigninger i orden. Uden en systemadministrator på serveren begynder der at opstå rod. Logs bliver ikke skrevet, eller de indeholder ikke det, der er nødvendigt, ressourcer bliver fordelt suboptimalt, disken fyldes med alskens skrald, og systemet begynder langsomt at falde sammen under vægten af kaos. Tag det roligt! Systemadministratorer kommer til at løse problemerne og rydde op!

Søjlerne af systemadministration

Men før vi går i gang med problemløsningen, er det værd at blive bekendt med de fire grundlæggende søjler i administration:

1. Dokumentation
2. Skabelonisering
3. Optimering
4. Automatisering

Dette er grundlaget for grundlæggende. Hvis man ikke bygger sin arbejdsproces på disse principper, vil den være ineffektiv, uproduktiv og overhovedet ikke ligne rigtig administration. Lad os se på hver enkelt.

Dokumentation

Dokumentation dette indebærer ikke kun at læse dokumentation (selvom man ikke kan komme uden om det), men også at føre den.

Hvordan man fører dokumentation:

• Stødte du på et nyt problem, som du aldrig har set før? Skriv de vigtigste symptomer, diagnosemetoder og principper for løsning ned.
• Har du fundet på en ny elegant løsning på et typisk problem? Skriv den ned, så du ikke skal opfinde den igen om en måned.
• Fik du hjælp til at forstå et spørgsmål, som du ikke vidste noget om? Skriv de vigtigste punkter og koncepter ned, og tegne et diagram til dig selv.

Hovedideen: Stol ikke helt på din egen hukommelse, når du lærer og anvender noget nyt.

Hvordan du gør dette, afhænger kun af dig: det kan være et notessystem, en personlig blog, en tekstfil, eller en fysisk notesbog. Det vigtigste er, at dine optegnelser overholder følgende krav:

1. De må ikke være for lange. Fremhæv hovedideer, metoder og værktøjer. Hvis forståelsen af problemet kræver, at du dykker ned i den lavniveau mekanik for hukommelsesallokering i Linux, så omskriv ikke den artikel, hvorfra du lærte det — giv et link til den.
2. Optegnelserne skal være forståelige for dig. Hvis linjen race cond.lockup ikke umiddelbart lader dig forstå, hvad du har beskrevet med denne linje — så forklar det. I god dokumentation skal man ikke bruge halve timer på at finde ud af det.
3. Søgning er en meget god funktion. Hvis du fører optegnelser i en blog, så tilføj tags; hvis i en fysisk notesbog — så sæt små post-it sedler med beskrivelser på. Der er ikke meget mening i dokumentation, hvis du bruger lige så lang tid på at finde svar i den, som du ville bruge på at løse spørgsmålet fra bunden.

Sådan kan dokumentationen se ud: fra primitive optegnelser i notesbogen (billedet ovenfor), til en fuldt fungerende, flerbruger vidensbase med tags, søgning og alle mulige faciliteter (nedenfor).

Du skal ikke bare undgå at lede efter de samme svar to gange: dokumentationen vil være en stor hjælp i studiet af nye emner (notater!), forbedre din evne til at diagnosticere komplekse problemer ved blot at kaste et overfladisk blik, og tilføje mere orden i dine handlinger. Hvis dokumentationen er tilgængelig for dine kolleger, vil den gøre det muligt for dem at forstå, hvad og hvordan du har lavet det, når du ikke er til stede.

Skabelonisering

Skabelonisering — er skabelsen og brugen af skabeloner. For at løse de fleste standardspørgsmål bør der oprettes en bestemt handlingsskabelon. For at diagnosticere de fleste problemer skal der anvendes en standardiseret procedure. Når du har repareret/installeret/optimeret noget, bør funktionaliteten af dette noget kontrolleres ved hjælp af standardiserede tjeklister.

Skabelonisering er den bedste måde at organisere arbejdsprocessen på. Ved at bruge standardprocedurer til at løse de mest almindelige problemer får du mange fordele. For eksempel vil brugen af tjeklister gøre det muligt for dig at diagnosticere alle vigtige funktioner for arbejdet og udelukke diagnosen af uvigtige funktionaliteter. Standardiserede procedurer vil minimere unødvendige afvigelser og reducere fejltagelsens sandsynlighed.

Et vigtigt aspekt er, at procedurer og tjeklister også skal dokumenteres. Hvis man blot stoler på sin hukommelse, kan man komme til at glemme en vigtig kontrol eller operation, og alt kan falde fra hinanden. En anden vigtig pointe er, at alle skabelonpraksisser kan og bør modificeres, hvis situationen kræver det. Der findes ikke perfekte og absolut universelle skabeloner. Hvis der er et problem, men den skabelonbaserede kontrol ikke afslørede det, betyder det ikke, at der ikke er et problem. Men før du tager fat på at kontrollere nogle usandsynlige hypotetiske problemer, er det altid en god idé først at lave en hurtig skabelonkontrol.

Optimering

Optimering taler for sig selv. Arbejdsprocessen skal maksimaloptimeres med henblik på tids- og arbejdsomkostninger. Der er utallige muligheder her: lær genvejstaster, forkortelser, regulære udtryk og tilgængelige værktøjer. Søg efter mere praktiske anvendelsesmetoder for disse værktøjer. Hvis du bruger samme kommando 100 gange om dagen, så bind den til en tastetryk. Hvis du regelmæssigt skal tilslutte til de samme servere, så opret et alias i ét ord, der vil forbinde dig dertil:

Gør dig bekendt med forskellige tilgængelige værktøjer — måske er der en mere praktisk terminalklient, DE, clipboard manager, browser, e-mailklient eller operativsystem. Find ud af, hvilke værktøjer dine kolleger og bekendte bruger — de har måske ikke valgt dem uden grund. Efter at have valgt værktøjer, lær at anvende dem: lær taster, forkortelser, tips og tricks.

Brug de standardværktøjer optimalt — coreutils, vim, regulære udtryk, bash. For de sidste tre findes der et væld af gode manualer og dokumentation. Med deres hjælp kan man hurtigt gå fra at "føle sig som en abe, der slår nødder med en bærbar computer" til "jeg er en abe, der bruger min bærbare computer til at bestille en nødnøgle."

Automatisering

Automatisering vil overføre tunge opgaver fra vores trætte hænder til de uermattelige hænder af automatisering. Hvis en standardprocedure udføres med fem ensartede kommandoer, hvorfor så ikke pakke alle disse kommandoer ind i en enkelt fil og kalde én kommando, som downloader og udfører denne fil?

Egentligt består automatisering 80% af at skrive og optimere sine egne værktøjer (og yderligere 20% af at få dem til at fungere som de skal). Det kan være en simpel avanceret enlinje-kode eller et kæmpestort, almægtigt værktøj med web-interface og API. Hovedkriteriet her er, at skabelsen af værktøjet ikke skal tage mere tid og kræfter end den tid og de kræfter, værktøjet vil spare dig. Hvis du bruger fem timer på at skrive et script, der aldrig vil komme til nytte igen, til en opgave, der ville tage dig en til to timer uden scriptet — så er det en meget dårlig optimering af arbejdsprocessen. Man kan bruge fem timer på at skabe et værktøj, kun hvis mængden, typen af opgaver og tid tillader det, hvilket sjældent sker.

Automatisering indebærer ikke nødvendigvis at skrive fuldverdige scripts. For eksempel, for at oprette en bunke ensartede objekter fra en liste, kan en snedig enlinje-kode være tilstrækkelig til automatisk at gøre det, du ville gøre manuelt, ved at skifte mellem vinduer med masser af copy-paste.

Egentligt kan man, hvis man bygger administrationsprocessen på disse fire søjler, hurtigt forbedre sin effektivitet, produktivitet og kvalifikationer. Men denne liste skal suppleres med et ekstra punkt, uden hvilket arbejde i IT praktisk talt er umuligt — selvuddannelse.

Selvuddannelse for systemadministratoren

For anyone to be somewhat competent in this field, it's essential to continuously learn and discover new things. If you have no desire to confront the unknown and understand it, you'll quickly fall behind. In IT, numerous new solutions, technologies, and methods constantly emerge; if you don't study them at least superficially, you're headed for defeat. Many areas of information technology are built on complex and extensive foundations. For instance, consider network operations. Networks and the internet are everywhere, and you encounter them daily, but when you delve into the technologies behind them, you uncover a vast and intricate discipline that studying is far from a walk in the park.

I didn't include this point in the list because it's crucial for IT in general, not just for system administration. Naturally, you won't be able to learn everything at once — there just won't be enough time. Therefore, when self-educating, you should remember the necessary levels of abstraction.

You don't have to immediately understand how the internal memory management works for every specific utility, and how it interacts with Linux memory management, but knowing what RAM is schematically and why it's needed is definitely useful. You don't need to know how the headers of TCP and UDP structurally differ, but it would be good to understand the main differences in how the protocols operate. You don't have to study what signal attenuation means in optics, but it would be beneficial to know why actual losses are always inherited through nodes. There's nothing wrong with knowing how certain elements work at a certain level of abstraction, and it's not necessary to dismantle all levels when there's no abstraction whatsoever (you'll just go crazy).

However, discussing in your field at an abstract level like 'well, it's this thing that allows you to display websites' isn't very good. The next lectures will focus on reviewing the basic areas that system administrators encounter while working at lower levels of abstraction. I will try to limit the knowledge covered to the minimum level of abstraction.

The 10 Commandments of System Administration

Så, vi har lært fire grundlæggende søjler og fundament. Kan vi begynde at løse problemer? Endnu ikke. Før dette er det tilrådeligt at sætte sig ind i såkaldte „best practices“ og regler for god opførsel. Uden dem er der risiko for, at du påfører mere skade end gavn. Lad os begynde:

1. Nogle af mine kolleger mener, at den første regel er „gør ikke skade“. Men jeg er ikke enig. Når man prøver at undgå at skade, kan man heller ikke gøre noget — for mange handlinger er potentielt destruktive. Jeg anser den vigtigste regel for at være — „lav en backup“. Selv hvis du skader noget, kan du altid rulle tilbage, og det vil ikke være så slemt.

   Du bør altid lave backup, når tid og plads tillader det. Lav backup af det, du vil ændre og af det, du risikerer at miste ved potentielt destruktiv handling. Det er en god idé at tjekke backupens integritet og sikre, at alle nødvendige data er der. Du bør ikke slette backup straks efter, at du har tjekket det, medmindre du skal frigøre plads på disken. Hvis pladsen kræver det — lav backup på din personlige server og slet efter en uge.

2. Den næst vigtigste regel (som jeg ofte selv overtræder) — „skjul ikke“. Hvis du har lavet en backup, så skriv ned — hvor, så dine kolleger ikke behøver at lede efter den. Hvis du har udført nogle uklar eller komplekse handlinger, så skriv det ned: du drager hjem, men problemet kan gentage sig eller opstå for nogen anden, og din løsning kan findes ved at søge med nøgleord. Selv hvis du laver noget, du godt kender, er det muligt, at dine kolleger ikke ved det.
3. Den tredje regel skal ikke forklares: „gør aldrig noget, hvis du ikke kender konsekvenserne, ikke kan forestille dig dem eller ikke forstår dem“. Kopier ikke kommandoer fra internettet, hvis du ikke ved, hvad de gør; kald man først og læs dem. Anvend ikke færdige løsninger, hvis du ikke kan forstå, hvad de gør. Reducer anvendelsen af obfuskeret kode til et absolut minimum. Hvis du ikke har tid til at undersøge — så laver du noget forkert, og du bør sætte dig ind i næste punkt.
4. „test“. Nye scripts, værktøjer, one-liners og kommandoer bør testes i et kontrolleret miljø, ikke på klientmaskinen, hvis der er mindst en mulighed for destruktive handlinger. Selv hvis du har lavet en backup (og det har du), er nedetid ikke det sjoveste. Opret en separat server/virtuelt miljø/chroot til dette formål og test der. Gik det ikke i stykker? Så kan du køre det på 'produktionsmiljøet'.

   
   

5. «Kontrolér». Minimer alle operationer, som du ikke kontrollerer. Abnorme afhængigheder i en pakke kan trække halvdelen af systemet med sig, og den angivne flag for yum remove -y giver dig mulighed for at træne dine færdigheder i at gendanne systemet fra bunden. Hvis handlingen ikke har uregulerede alternativer — så gå videre til næste punkt og hav en klar backup.
6. «Tjek». Tjek konsekvenserne af dine handlinger, og om det er nødvendigt at gå tilbage til backupen. Tjek, om problemet virkelig er løst. Tjek, om fejlen kan reproduceres, og under hvilke omstændigheder. Tjek, hvad du kan ødelægge med dine handlinger. At stole på i vores arbejde er overflødigt, men at tjekke er aldrig unødvendigt.
7. «Tal sammen». Hvis du ikke kan løse problemet, så spørg dine kolleger, om de har stødt på noget lignende. Hvis du ønsker at anvende en tvivlsom løsning — flere meninger er altid gode at få. Måske vil de finde en bedre løsning. Hvis du er usikker på dine handlinger — diskuter dem med dine kolleger. Selvom det er dit ekspertområde, kan et friskt syn på situationen kaste lys over meget. Vær ikke flov over dit uvidende. Det er bedre at stille et dumt spørgsmål, fremstå som en idiot og få et svar end ikke at stille spørgsmålet, ikke få et svar og forblive en idiot.
8. «Afvis ikke hjælp uden grund». Dette punkt er den modsatte side af det foregående. Hvis du får et dumt spørgsmål — afklar og forklar. Hvis de beder om noget umuligt — forklar, at det er umuligt og hvorfor, og foreslå alternativer. Hvis der ikke er tid (rigtigt ikke tid, ikke blot mangel på lyst) — sig, at du har en presserende opgave eller stort arbejde, men du vil tage dig af det senere. Hvis kollegerne ikke har presserende opgaver, så foreslå at kontakte dem og delegere spørgsmålet.
9. «Giv feedback». Har nogen af dine kolleger begyndt at anvende en ny metode eller et nyt script, og får du negative konsekvenser af denne beslutning? Giv os besked. Måske kan problemet løses med tre linjer kode eller fem minutters tilpasning af metoden. Stødte du på en fejl i softwaren? Rapportér om fejlen. Hvis den kan reproduceres, eller hvis det ikke er nødvendigt at reproducere den, vil den sandsynligvis blive rettet. Del ønsker, forslag og konstruktiv kritik, bring spørgsmål op til diskussion, hvis de synes relevante.
10. «Bed om feedback». Vi er alle uperfekte, ligesom vores løsninger, og den bedste måde at teste rigtigheden af ens beslutninger på er at bringe dem til diskussion. Har du optimeret noget for en kunde - bed dem om at følge arbejdet, måske er 'flaskehalsen' i systemet ikke der, hvor du troede. Har du skrevet et hjælpescript - vis det til kollegerne, de kan måske finde en måde at forbedre det på.

Hvis man konstant anvender disse praksisser i arbejdet, stopper mange problemer med at være problemer: du vil ikke kun minimere dine egne fejl og problemer, men også have mulighed for at rette fejl (gennem backups og kolleger, der kan anbefale dig at tage en backup). Herefter er det kun tekniske detaljer tilbage, som jo, som bekendt, gemmer på djævlen.

De primære værktøjer, du skal arbejde med mere end 50% af tiden, er grep og vim. Hvad kunne være enklere? At søge i tekst og redigere tekst. Men både grep og vim er kraftfulde multifunktionelle værktøjer, der gør det muligt at søge og redigere tekst effektivt. Mens en Windows Notepad kun lader dig skrive/videre slette en linje, kan du i vim gøre næsten hvad som helst med teksten. Hvis du ikke tror på det - kald kommandoen vimtutor fra terminalen og begynd at lære. Med hensyn til grep er dens primære styrke i regulære udtryk. Ja, værktøjet tillader at definere søgekriterier og outputdata ret fleksibelt, men uden RegExp giver det ikke meget mening. Og du skal kende regulære udtryk! I det mindste på et grundlæggende niveau. Til at starte med vil jeg anbefale, at du ser på dette en video, det forklarer grundlaget for regulære udtryk og deres anvendelse sammen med grep. Ah ja, når du kombinerer dem med vim, får du ULTIMATE POWER til at gøre ting med teksten, som kræver 18+ mærkning.

Af de resterende 50% udgør 40% værktøjspakken coreutils. Du kan se listen for coreutils i Wikipedia, og manualen for hele listen er på hjemmesiden GNU. Hvad der ikke er dækket af dette sæt, findes i værktøjerne POSIX. Det er ikke nødvendigt at huske alle nøgler udenad, men det er nyttigt at vide, hvad de primære værktøjer kan — så undgår du at opfinde cyklen med krummer. Engang måtte jeg erstatte linjeskift med mellemrum i output fra et eller andet værktøj, og jeg kom op med en konstruktion som sed ':a;N;$!ba;s/n/ /g', men en kollega kom hen og væmmede mig væk fra konsollen, og så løste han opgaven med tr 'n' ' '.

Jeg vil anbefale at huske, hvad næsten hver enkelt værktøj udfører og nøglerne til de mest anvendte kommandoer; til alt andet er der man. Tøv ikke med at kalde man, hvis du er i tvivl om noget. Og læs bestemt man på selve man — det indeholder vigtige informationer om, hvad du vil finde.

Ved at kende disse værktøjer kan du effektivt løse en betydelig del af de opgaver, du støder på i praksis. I de næste lektioner vil vi se på, hvornår disse værktøjer og strukturerne for de grundlæggende tjenester og applikationer, de anvendes på, skal anvendes.

Jeg har været systemadministrator hos FirstVDS, Kirill Tsvetkov.

Kilde: habr.com