For en nybegynder systemadministrator: hvordan man skaber orden ud af kaos

Jeg er FirstVDS-systemadministrator, og dette er teksten til det første introduktionsforedrag fra mit korte kursus om at hjælpe uerfarne kollegaer. Specialister, der for nylig er begyndt at engagere sig i systemadministration, står over for en række af de samme problemer. For at tilbyde løsninger påtog jeg mig at skrive denne forelæsningsrække. Nogle ting i det er specifikke for hosting af teknisk support, men generelt kan de være nyttige, hvis ikke for alle, så for mange. Så jeg har tilpasset foredragsteksten til at dele her.

Det er lige meget, hvad din stilling hedder - det, der betyder noget, er, at du faktisk er involveret i administrationen. Lad os derfor starte med, hvad en systemadministrator skal gøre. Dens hovedopgave er at bringe tingene i orden, opretholde orden og forberede fremtidige stigninger i orden. Uden en systemadministrator bliver serveren et rod. Der skrives ikke logs, eller der er skrevet de forkerte ting i dem, ressourcer fordeles ikke optimalt, disken er fyldt med alverdens affald og systemet begynder langsomt at dø af så meget kaos. Roligt! Systemadministratorer i din person begynder at løse problemer og eliminere rod!

Systemadministrationens søjler

Men før du begynder at løse problemer, er det værd at blive bekendt med de fire hovedsøjler i administrationen:

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

Dette er det grundlæggende. Hvis du ikke bygger din arbejdsgang på disse principper, vil den være ineffektiv, uproduktiv og i almindelighed have ringe lighed med reel administration. Lad os se på hver enkelt separat.

Records

Records betyder ikke at læse dokumentation (selvom du ikke kan undvære den), men også at vedligeholde den.

Sådan opbevarer du dokumentation:

• Er du stødt på et nyt problem, som du aldrig har set før? Skriv ned de vigtigste symptomer, metoder til diagnose og principper for eliminering.
• Har du fundet på en ny, elegant løsning på et almindeligt problem? Skriv det ned, så du ikke behøver at genopfinde det om en måned.
• Har de hjulpet dig med at finde ud af et spørgsmål, du ikke forstod? Skriv hovedpunkterne og begreberne ned, tegn et diagram for dig selv.

Hovedideen: du skal ikke stole helt på din egen hukommelse, når du mestrer og anvender nye ting.

I hvilket format du vil gøre dette er op til dig: det kan være et system med noter, en personlig blog, en tekstfil, en fysisk notesblok. Det vigtigste er, at dine optegnelser opfylder følgende krav:

1. Vær ikke for lang. Fremhæv de vigtigste ideer, metoder og værktøjer. Hvis forståelsen af ​​et problem kræver at dykke ned i mekanikken på lavt niveau af hukommelsesallokering i Linux, skal du ikke omskrive artiklen, du lærte den af ​​- giv et link til den.
2. Indtastningerne skal være tydelige for dig. Hvis linjen race cond.lockup tillader dig ikke umiddelbart at forstå, hvad du beskrev med denne linje - forklar. God dokumentation tager ikke en halv time at forstå.
3. Søgning er en meget god funktion. Hvis du skriver blogindlæg, skal du tilføje tags; hvis du er i en fysisk notesbog, så sæt små post-its med beskrivelser. Der er ingen mening i dokumentation, hvis du bruger lige så meget tid på at lede efter et svar i den, som du ville bruge på at løse spørgsmålet fra bunden.

Sådan kan dokumentation se ud: fra primitive noter i en notesblok (billedet ovenfor) til en fuldgyldig vidensbase for flere brugere med tags, søgning og alle mulige bekvemmeligheder (nedenfor).

Ikke alene behøver du ikke at lede efter de samme svar to gange, men at dokumentere vil være en stor hjælp til at lære nye emner (noter!), vil forbedre din edderkopsans (evnen til at diagnosticere et komplekst problem med et overfladisk blik), og vil tilføje organisation til dine handlinger. Hvis dokumentationen er tilgængelig for dine kolleger, vil den give dem mulighed for at finde ud af, hvad og hvordan du har hobet dig op der, når du ikke er der.

Skabelon

Skabelon er oprettelse og brug af skabeloner. For at løse de fleste typiske problemer er det værd at oprette en specifik handlingsskabelon. En standardiseret rækkefølge af trin bør bruges til at diagnosticere de fleste problemer. Når du har repareret/installeret/optimeret noget, bør ydelsen af ​​dette noget kontrolleres ved hjælp af standardiserede tjeklister.

Skabeloner er den bedste måde at organisere din arbejdsgang på. Ved at bruge standardprocedurer til at løse de mest almindelige problemer, får du en masse fede ting. For eksempel vil brug af tjeklister give dig mulighed for at diagnosticere alle funktioner, der er vigtige for dit arbejde, og kassere diagnosen om uvigtig funktionalitet. Og standardiserede procedurer vil minimere unødvendige kast og reducere sandsynligheden for fejl.

Det første vigtige punkt er, at procedurer og tjeklister også skal dokumenteres. Hvis du bare stoler på hukommelsen, kan du gå glip af en virkelig vigtig kontrol eller operation og ødelægge alt. Det andet vigtige punkt er, at al skabelonpraksis kan og bør ændres, hvis situationen kræver det. Der er ingen ideelle og absolut universelle skabeloner. Hvis der er et problem, men et skabelontjek ikke afslørede det, betyder det ikke, at der ikke er noget problem. Før du begynder at teste nogle usandsynlige hypotetiske problemer, er det dog altid værd at lave en hurtig skabelontest først.

Optimering

Optimering taler for sig selv. Arbejdsprocessen skal optimeres så meget som muligt med hensyn til tid og lønomkostninger. Der er utallige muligheder: lær tastaturgenveje, forkortelser, regulære udtryk, tilgængelige værktøjer. Se efter mere praktisk anvendelse af disse værktøjer. Hvis du kalder en kommando 100 gange om dagen, skal du tildele den til en tastaturgenvej. Hvis du regelmæssigt skal oprette forbindelse til de samme servere, skal du skrive et alias i ét ord, der forbinder dig dertil:

Gør dig bekendt med de forskellige muligheder, der er tilgængelige for værktøjer - måske er der en mere bekvem terminalklient, DE, klippebordsmanager, browser, e-mailklient, operativsystem. Find ud af, hvilke værktøjer dine kolleger og venner bruger – måske vælger de dem af en grund. Når du har værktøjerne, skal du lære at bruge dem: lær nøglerne, forkortelserne, tips og tricks.

Gør optimal brug af standardværktøjer - coreutils, vim, regulære udtryk, bash. For de sidste tre er der et stort antal vidunderlige manualer og dokumentation. Med deres hjælp kan du hurtigt gå fra tilstanden "Jeg føler mig som en abe, der knækker nødder med en bærbar computer" til "Jeg er en abe, der bruger en bærbar computer til at bestille mig en nøddeknækker."

Automation

Automation vil overføre vanskelige operationer fra vores trætte hænder til automatiseringens utrættelige hænder. Hvis en eller anden standardprocedure udføres i fem kommandoer af samme type, hvorfor så ikke pakke alle disse kommandoer ind i én fil og kalde én kommando, der downloader og udfører denne fil?

Selve automatiseringen består i 80 % af at skrive og optimere dine egne værktøjer (og yderligere 20 % forsøger at få dem til at fungere, som de skal). Det kunne bare være en avanceret one-liner eller et kæmpe almægtigt værktøj med en webgrænseflade og API. Hovedkriteriet her er, at oprettelse af et værktøj ikke bør tage mere tid og kræfter end den mængde tid og kræfter, som værktøjet vil spare dig. Hvis du bruger fem timer på at skrive et script, som du aldrig får brug for igen, til en opgave, der ville have taget dig en time eller to at løse uden scriptet, er dette en meget dårlig workflow-optimering. Du kan kun bruge fem timer på at oprette et værktøj, hvis antallet, typen af ​​opgaver og tiden tillader det, hvilket ikke ofte er tilfældet.

Automatisering betyder ikke nødvendigvis at skrive fuldgyldige scripts. For at oprette en masse objekter af samme type fra en liste, behøver du for eksempel bare en smart one-liner, der automatisk vil gøre, hvad du ville gøre i hånden, skifte mellem vinduer med masser af copy-paste.

Faktisk, hvis du bygger administrationsprocessen på disse fire søjler, kan du hurtigt øge din effektivitet, produktivitet og kvalifikationer. Denne liste skal dog suppleres med et punkt mere, uden hvilket arbejde i IT er næsten umuligt - selvuddannelse.

Systemadministrator selvuddannelse

For at være en smule kompetent på dette område skal du hele tiden studere og lære nye ting. Hvis du ikke har det mindste ønske om at se det ukendte i øjnene og finde ud af det, bliver du hurtigt hængende. Der dukker hele tiden alle mulige nye løsninger, teknologier og metoder op i IT, og hvis man ikke studerer dem i det mindste overfladisk, er man på vej mod fiasko. Mange områder inden for informationsteknologi står på et meget komplekst og omfangsrigt grundlag. For eksempel netværksdrift. Netværk og internettet er overalt, du støder på dem hver dag, men når du først har gravet i teknologien bag dem, vil du opdage en enorm og meget kompleks disciplin, hvis studie aldrig er en tur i parken.

Jeg medtog ikke dette punkt på listen, fordi det er nøglen til IT generelt og ikke kun for systemadministration. Naturligvis vil du ikke være i stand til at lære absolut alt med det samme - du har simpelthen ikke fysisk nok tid. Derfor, når du uddanner dig selv, bør du huske de nødvendige abstraktionsniveauer.

Du behøver ikke umiddelbart at lære, hvordan den interne hukommelsesstyring af hvert enkelt hjælpeprogram fungerer, og hvordan det interagerer med Linux-hukommelsesstyringen, men det er godt at vide, hvad RAM er skematisk, og hvorfor det er nødvendigt. Du behøver ikke vide, hvordan TCP- og UDP-headere er strukturelt forskellige, men det ville være en god idé at forstå de grundlæggende forskelle i, hvordan protokollerne fungerer. Du behøver ikke at lære, hvad signaldæmpning er i optik, men det ville være rart at vide, hvorfor reelle tab altid nedarves på tværs af noder. Der er intet galt i at vide, hvordan visse elementer fungerer på et bestemt abstraktionsniveau og ikke nødvendigvis at forstå absolut alle niveauer, når der slet ikke er nogen abstraktion (du bliver bare skør).

Men i dit felt er det ikke særlig godt at tænke på abstraktionsniveauet "jamen, det er en ting, der giver dig mulighed for at vise websteder". De følgende forelæsninger vil blive helliget en oversigt over de hovedområder, som en systemadministrator skal beskæftige sig med, når der arbejdes på lavere abstraktionsniveauer. Jeg vil forsøge at begrænse mængden af ​​gennemgået viden til et minimumsniveau af abstraktion.

10 bud om systemadministration

Så vi har lært de fire hovedsøjler og grundlaget. Kan vi begynde at løse problemer? Ikke endnu. Før du gør dette, er det tilrådeligt at sætte dig ind i de såkaldte "best practices" og regler for god opførsel. Uden dem vil du sandsynligvis gøre mere skade end gavn. Så lad os begynde:

1. Nogle af mine kolleger mener, at den allerførste regel er "gør ingen skade." Men jeg er tilbøjelig til at være uenig. Når du prøver ikke at skade, kan du ikke gøre noget - for mange handlinger er potentielt ødelæggende. Jeg tror den vigtigste regel er - "lav en sikkerhedskopi". Selvom du gør noget, kan du altid rulle tilbage, og alt bliver ikke så slemt.

   Du bør altid tage backup, når tid og sted tillader det. Du skal tage backup af, hvad du vil ændre, og hvad du risikerer at miste på grund af en potentielt destruktiv handling. Det er tilrådeligt at kontrollere sikkerhedskopien for integritet og tilstedeværelsen af ​​alle nødvendige data. Sikkerhedskopien bør ikke slettes umiddelbart efter du har tjekket alt, medmindre du skal frigøre diskplads. Hvis placeringen kræver det, skal du sikkerhedskopiere den til din personlige server og slette den efter en uge.

2. Den næstvigtigste regel (som jeg selv ofte bryder) er "skjul dig ikke". Hvis du har lavet en backup, så skriv hvor, så dine kollegaer ikke skal lede efter den. Hvis du gjorde nogle ikke-oplagte eller komplekse handlinger, så skriv det ned: du går hjem, og problemet kan blive gentaget eller opstå for en anden, og din løsning vil blive fundet ved hjælp af nøgleord. Selvom du gør noget, du ved godt, kan dine kollegaer ikke.
3. Den tredje regel behøver ikke at blive forklaret: "Gør aldrig noget, hvis konsekvenser du ikke ved, forestiller dig eller forstår". Kopier ikke kommandoer fra internettet, hvis du ikke ved, hvad de gør, ring til mand og parse dem først. Brug ikke færdige løsninger, hvis du ikke kan forstå, hvad de gør. Hold eksekvering af sløret kode på et absolut minimum. Hvis du ikke har tid til at finde ud af det, så gør du noget forkert, og du bør læse næste punkt.
4. "Prøve". Nye scripts, værktøjer, one-liners og kommandoer bør testes i et kontrolleret miljø, ikke på klientmaskinen, hvis der overhovedet er et minimalt potentiale for destruktive handlinger. Selvom du sikkerhedskopierede alt (og det gjorde du), er nedetid ikke det fedeste. Opret en separat server/virtuel/chroot til dette og test der. Er noget gået i stykker? Så kan du starte den på "combat".

   
   

5. "Styring". Minimer alle operationer, som du ikke kontrollerer. Én pakkeafhængighedskurve kan trække halvdelen af ​​systemet ned, og -y-flaget sat til yum remove giver dig mulighed for at øve dine systemgendannelsesfærdigheder fra bunden. Hvis handlingen ikke har nogen ukontrollerede alternativer, er næste punkt en færdig backup.
6. "Kontrollere". Tjek konsekvenserne af dine handlinger, og om du skal rulle tilbage til en backup. Tjek for at se, om problemet virkelig er blevet løst. Tjek om fejlen er gengivet og under hvilke forhold. Tjek, hvad du kan bryde med dine handlinger. Det er unødvendigt at stole på vores arbejde, men aldrig at tjekke.
7. "Kommunikere". Hvis du ikke kan løse problemet, så spørg dine kolleger, om de er stødt på dette. Hvis du ønsker at anvende en kontroversiel beslutning, så find ud af dine kollegers mening. Måske vil de tilbyde en bedre løsning. Hvis du ikke er sikker på dine handlinger, så diskuter dem med dine kolleger. Selvom dette er dit område af ekspertise, kan et nyt blik på situationen afklare meget. Skam dig ikke over din egen uvidenhed. Det er bedre at stille et dumt spørgsmål, ligne et fjols og få et svar, end ikke at stille spørgsmålet, ikke få et svar og ende med at blive et fjols.
8. "Nægt ikke hjælp urimeligt". Dette punkt er det modsatte af det forrige. Får du et dumt spørgsmål, så forklar og forklar. De beder om det umulige - forklarer, at det er umuligt, og hvorfor, tilbyder alternativer. Hvis du ikke har tid (du har virkelig ikke tid, ikke lyst) - sig, at du har et presserende spørgsmål, meget arbejde, men du vil ordne det senere. Hvis kolleger ikke har akutte opgaver, så tilbud at kontakte dem og uddelegere spørgsmålet.
9. "Give tilbagemelding". Er en af ​​dine kollegaer begyndt at bruge en ny teknik eller et nyt manuskript, og møder du negative konsekvenser af denne beslutning? Rapporter det. Måske kan problemet løses med tre linjer kode eller fem minutters finpudsning af teknikken. Er du stødt på en fejl i din software? Anmeld en fejl. Hvis det er reproducerbart eller ikke skal gengives, vil det højst sandsynligt blive rettet. Giv udtryk for dine ønsker, forslag og konstruktiv kritik, og stil spørgsmål til diskussion, hvis de virker relevante.
10. "Bed om feedback". Vi er alle ufuldkomne, ligesom vores beslutninger, og den bedste måde at teste rigtigheden af ​​din beslutning på er at tage den op til diskussion. Hvis du har optimeret noget til en klient, så bed dem om at overvåge arbejdet; måske er flaskehalsen i systemet ikke der, du ledte efter. Du har skrevet et hjælpescript - vis det til dine kolleger, måske finder de en måde at forbedre det på.

Hvis du konstant anvender disse praksisser i dit arbejde, vil de fleste af problemerne ophøre med at være problemer: du vil ikke kun reducere antallet af dine egne fejl og skrammer til et minimum, men du vil også have mulighed for at rette fejl (i form for backups og kolleger, der vil rådgive dig til backup). Yderligere - kun tekniske detaljer, hvori, som vi ved, djævelen ligger.

De vigtigste værktøjer, du skal arbejde med mere end 50% af tiden, er grep og vim. Hvad kunne være enklere? Tekstsøgning og tekstredigering. Men både grep og vim er kraftfulde multiværktøjer, der giver dig mulighed for at søge og redigere tekst effektivt. Hvis en Windows-notesblok tillader dig blot at skrive/slette en linje, så kan du i vim gøre næsten alt med tekst. Hvis du ikke tror mig, så ring til vimtutor-kommandoen fra terminalen og begynd at lære. Hvad angår grep, er dens største styrke i regulære udtryk. Ja, selve værktøjet giver dig mulighed for at indstille søgebetingelser og outputdata ret fleksibelt, men uden RegExp giver dette ikke meget mening. Og du skal kende regulære udtryk! I hvert fald på et grundlæggende niveau. Til at begynde med vil jeg råde dig til at se på dette видео, den dækker det grundlæggende i regulære udtryk og deres brug i forbindelse med grep. Åh ja, når du kombinerer dem med vim, får du den ULTIMATE POWER evne til at gøre sådanne ting med tekst, at du skal mærke dem med 18+ ikoner.

Af de resterende 50 % kommer 40 % fra coreutils-værktøjssættet. For coreutils kan du se på listen på Wikipedia, og manualen til hele listen er på hjemmesiden GNU. Hvad der ikke er dækket af dette sæt er i hjælpeprogrammerne POSIX. Du behøver ikke at lære alle nøglerne udenad, men det er nyttigt i det mindste at vide nogenlunde, hvad de grundlæggende værktøjer kan. Du behøver ikke genopfinde hjulet fra krykker. Jeg havde på en eller anden måde brug for at erstatte linjeskift med mellemrum i outputtet fra et eller andet hjælpeprogram, og min syge hjerne fødte en konstruktion som sed ':a;N;$!ba;s/n/ /g', kom en kollega hen og kørte mig væk fra konsollen med en kost, og løste så problemet ved at skrive tr 'n' ' '.

Jeg vil råde dig til at huske, hvad hvert enkelt værktøj gør og nøglerne til de mest brugte kommandoer; for alt andet er der en mand. Du er velkommen til at ringe til mand, hvis du er i tvivl. Og sørg for at læse manden selv – den indeholder vigtige oplysninger om, hvad du finder.

Ved at kende disse værktøjer vil du være i stand til effektivt at løse en væsentlig del af de problemer, du vil støde på i praksis. I de følgende forelæsninger vil vi se på, hvornår disse værktøjer skal bruges og rammerne for de underliggende tjenester og applikationer, de gælder for.

FirstVDS systemadministrator Kirill Tsvetkov var med dig.

Kilde: www.habr.com