For en nybegynner systemadministrator: hvordan skape orden ut av kaos

Jeg er FirstVDS-systemadministrator, og dette er teksten til den første introduksjonsforelesningen fra mitt korte kurs om å hjelpe nybegynnere. Spesialister som nylig har begynt å engasjere seg i systemadministrasjon står overfor en rekke av de samme problemene. For å tilby løsninger påtok jeg meg å skrive denne forelesningsserien. Noen ting i den er spesifikke for å være vert for teknisk støtte, men generelt kan de være nyttige, om ikke for alle, så for mange. Så jeg har tilpasset forelesningsteksten for å dele her.

Det spiller ingen rolle hva stillingen din heter - det som betyr noe er at du faktisk er involvert i administrasjonen. La oss derfor starte med hva en systemadministrator bør gjøre. Dens hovedoppgave er å sette ting i orden, holde orden og forberede seg på fremtidige økninger i orden. Uten en systemadministrator blir serveren et rot. Logger skrives ikke, eller feil ting er skrevet i dem, ressurser fordeles ikke optimalt, disken fylles med all slags søppel og systemet begynner sakte å dø av så mye kaos. Rolig! Systemadministratorer i din person begynner å løse problemer og eliminere rotet!

Pilarer i systemadministrasjon

Men før du begynner å løse problemer, er det verdt å bli kjent med de fire hovedpilarene for administrasjon:

1. Dokumentasjon
2. Mal
3. Optimalisering
4. Automasjon

Dette er det grunnleggende. Hvis du ikke bygger arbeidsflyten din på disse prinsippene, vil den være ineffektiv, uproduktiv og generelt ha liten likhet med ekte administrasjon. La oss se på hver enkelt separat.

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

Документация betyr ikke å lese dokumentasjon (selv om du ikke kan klare deg uten den), men også å vedlikeholde den.

Slik oppbevarer du dokumentasjon:

• Har du støtt på et nytt problem du aldri har sett før? Skriv ned hovedsymptomene, diagnosemetodene og prinsippene for eliminering.
• Har du kommet opp med en ny, elegant løsning på et vanlig problem? Skriv det ned slik at du ikke trenger å finne det opp på nytt om en måned.
• Har de hjulpet deg med å finne ut et spørsmål du ikke forsto? Skriv ned hovedpunktene og begrepene, tegn et diagram for deg selv.

Hovedideen: du bør ikke stole helt på ditt eget minne når du mestrer og bruker nye ting.

I hvilket format du vil gjøre dette er opp til deg: det kan være et system med notater, en personlig blogg, en tekstfil, en fysisk notisblokk. Det viktigste er at postene dine oppfyller følgende krav:

1. Ikke vær for lang. Fremhev hovedideene, metodene og verktøyene. Hvis det å forstå et problem krever å dykke inn i lavnivåmekanikken for minneallokering i Linux, ikke omskriv artikkelen du lærte det fra - gi en lenke til den.
2. Oppføringene skal være tydelige for deg. Hvis linjen race cond.lockup lar deg ikke umiddelbart forstå det du beskrev med denne linjen - forklar. God dokumentasjon tar ikke en halvtime å forstå.
3. Søk er en veldig god funksjon. Hvis du skriver blogginnlegg, legg til tagger; hvis du er i en fysisk notatbok, stikk små post-its med beskrivelser. Det er liten vits i dokumentasjon hvis du bruker like mye tid på å søke etter et svar i den som du ville ha brukt på å løse spørsmålet fra bunnen av.

Slik kan dokumentasjon se ut: fra primitive notater i en notisblokk (bildet over), til en fullverdig flerbrukerkunnskapsbase med tagger, søk og alle mulige bekvemmeligheter (under).

Ikke bare trenger du ikke å lete etter de samme svarene to ganger, men dokumentering vil være en stor hjelp til å lære nye emner (notater!), vil forbedre edderkoppfølelsen din (evnen til å diagnostisere et komplekst problem med ett overfladisk blikk), og vil legge til organisasjon til handlingene dine. Hvis dokumentasjonen er tilgjengelig for kollegene dine, vil den tillate dem å finne ut hva og hvordan du stablet opp der når du ikke er der.

Mal

Mal er opprettelse og bruk av maler. For å løse de fleste typiske problemer, er det verdt å lage en spesifikk handlingsmal. En standardisert sekvens av trinn bør brukes for å diagnostisere de fleste problemer. Når du har reparert/installert/optimalisert noe, bør ytelsen til dette noe kontrolleres ved hjelp av standardiserte sjekklister.

Maling er den beste måten å organisere arbeidsflyten på. Ved å bruke standardprosedyrer for å løse de vanligste problemene får du mye kult. For eksempel vil bruk av sjekklister tillate deg å diagnostisere alle funksjoner som er viktige for arbeidet ditt og forkaste diagnosen uviktig funksjonalitet. Og standardiserte prosedyrer vil minimere unødvendig kasting og redusere sannsynligheten for feil.

Det første viktige poenget er at prosedyrer og sjekklister også må dokumenteres. Hvis du bare stoler på minnet, kan du gå glipp av en veldig viktig sjekk eller operasjon og ødelegge alt. Det andre viktige poenget er at all malpraksis kan og bør endres hvis situasjonen krever det. Det er ingen ideelle og absolutt universelle maler. Hvis det er et problem, men en malsjekk ikke avslørte det, betyr ikke dette at det ikke er noe problem. Men før du begynner å teste noen usannsynlige hypotetiske problemer, er det alltid verdt å gjøre en rask maltest først.

Optimalisering

Optimalisering taler for seg selv. Arbeidsprosessen må optimaliseres så mye som mulig med tanke på tid og arbeidskostnader. Det er utallige alternativer: lær tastatursnarveier, forkortelser, regulære uttrykk, tilgjengelige verktøy. Se etter mer praktisk bruk av disse verktøyene. Hvis du ringer en kommando 100 ganger om dagen, tilordne den til en hurtigtast. Hvis du regelmessig trenger å koble til de samme serverne, skriv et alias i ett ord som kobler deg dit:

Gjør deg kjent med de forskjellige alternativene som er tilgjengelige for verktøy - kanskje det er en mer praktisk terminalklient, DE, utklippstavleadministrator, nettleser, e-postklient, operativsystem. Finn ut hvilke verktøy dine kolleger og venner bruker – kanskje de velger dem av en grunn. Når du har verktøyene, lær hvordan du bruker dem: lær nøklene, forkortelser, tips og triks.

Gjør optimal bruk av standardverktøy - coreutils, vim, regulære uttrykk, bash. For de tre siste er det et stort antall fantastiske manualer og dokumentasjon. Med deres hjelp kan du raskt gå fra tilstanden "Jeg føler meg som en ape som knekker nøtter med en bærbar datamaskin" til "Jeg er en ape som bruker en bærbar datamaskin til å bestille meg en nøtteknekk."

Automatisering

Automatisering vil overføre vanskelige operasjoner fra våre slitne hender til automatiseringens utrettelige hender. Hvis en standardprosedyre utføres i fem kommandoer av samme type, hvorfor ikke pakke alle disse kommandoene inn i én fil og kalle én kommando som laster ned og utfører denne filen?

Automatisering i seg selv er 80 % skriving og optimalisering av dine egne verktøy (og ytterligere 20 % prøver å få dem til å fungere som de skal). Det kan bare være en avansert one-liner eller et enormt allmektig verktøy med et nettgrensesnitt og API. Hovedkriteriet her er at å lage et verktøy ikke skal ta mer tid og krefter enn hvor mye tid og krefter verktøyet vil spare deg for. Hvis du bruker fem timer på å skrive et skript du aldri kommer til å trenge igjen, for en oppgave det ville tatt deg en time eller to å løse uten skriptet, er dette en veldig dårlig arbeidsflytoptimalisering. Du kan bruke fem timer på å lage et verktøy bare hvis antall, type oppgaver og tid tillater det, noe som ikke ofte er tilfelle.

Automatisering betyr ikke nødvendigvis å skrive fullverdige skript. For eksempel, for å lage en haug med objekter av samme type fra en liste, er alt du trenger en smart one-liner som automatisk vil gjøre det du ville gjort for hånd, bytte mellom vinduer, med massevis av copy-paste.

Faktisk, hvis du bygger administrasjonsprosessen på disse fire pilarene, kan du raskt øke effektiviteten, produktiviteten og kvalifikasjonene. Imidlertid må denne listen suppleres med ett element til, uten hvilket det er nesten umulig å jobbe med IT - selvutdanning.

Systemadministrator selvutdanning

For å være enda litt kompetent på dette området, må du hele tiden studere og lære nye ting. Hvis du ikke har det minste ønske om å møte det ukjente og finne ut av det, vil du bli sittende fast veldig fort. Alle slags nye løsninger, teknologier og metoder dukker stadig opp i IT, og hvis du ikke studerer dem i det minste overfladisk, er du på vei til å mislykkes. Mange områder innen informasjonsteknologi står på et svært komplekst og omfangsrikt grunnlag. For eksempel nettverksdrift. Nettverk og internett er overalt, du møter dem hver dag, men når du først har gravd i teknologien bak dem, vil du oppdage en enorm og veldig kompleks disiplin som aldri er en tur i parken.

Jeg tok ikke med dette elementet i listen fordi det er nøkkelen for IT generelt, og ikke bare for systemadministrasjon. Naturligvis vil du ikke kunne lære absolutt alt med en gang - du har rett og slett ikke fysisk nok tid. Derfor, når du utdanner deg selv, bør du huske de nødvendige abstraksjonsnivåene.

Du trenger ikke umiddelbart å lære hvordan den interne minneadministrasjonen til hvert enkelt verktøy fungerer, og hvordan det samhandler med Linux-minneadministrasjon, men det er greit å vite hva RAM er skjematisk og hvorfor det er nødvendig. Du trenger ikke vite hvordan TCP- og UDP-overskrifter er strukturelt forskjellige, men det vil være en god idé å forstå de grunnleggende forskjellene i hvordan protokollene fungerer. Du trenger ikke å lære hva signaldempning er i optikk, men det ville være fint å vite hvorfor reelle tap alltid arves på tvers av noder. Det er ingenting galt med å vite hvordan visse elementer fungerer på et visst abstraksjonsnivå og ikke nødvendigvis forstå absolutt alle nivåer når det ikke er noen abstraksjon i det hele tatt (du blir bare gal).

Men i ditt felt er det ikke veldig bra å tenke på abstraksjonsnivået "vel, dette er en ting som lar deg vise nettsteder". De følgende forelesningene vil bli viet en oversikt over hovedområdene som en systemansvarlig må forholde seg til ved arbeid på lavere abstraksjonsnivåer. Jeg vil prøve å begrense mengden kunnskap som vurderes til et minimumsnivå av abstraksjon.

10 bud om systemadministrasjon

Så vi har lært de fire hovedpilarene og grunnlaget. Kan vi begynne å løse problemer? Ikke ennå. Før du gjør dette, er det tilrådelig å gjøre deg kjent med de såkalte "beste praksisene" og reglene for god oppførsel. Uten dem vil du sannsynligvis gjøre mer skade enn nytte. Så la oss begynne:

1. Noen av mine kolleger mener at den aller første regelen er «gjør ingen skade». Men jeg er tilbøyelig til å være uenig. Når du prøver å ikke skade, kan du ikke gjøre noe - for mange handlinger er potensielt ødeleggende. Jeg tror den viktigste regelen er - "lag en sikkerhetskopi". Selv om du gjør noe skade, kan du alltid rulle tilbake og alt blir ikke så ille.

   Du bør alltid ta backup når tid og sted tillater det. Du må sikkerhetskopiere hva du vil endre og hva du risikerer å miste på grunn av en potensielt destruktiv handling. Det anbefales å sjekke sikkerhetskopien for integritet og tilstedeværelsen av alle nødvendige data. Sikkerhetskopien bør ikke slettes umiddelbart etter at du har sjekket alt, med mindre du trenger å frigjøre diskplass. Hvis plasseringen krever det, sikkerhetskopierer du den til din personlige server og sletter den etter en uke.

2. Den nest viktigste regelen (som jeg selv ofte bryter) er "ikke gjem deg". Hvis du har tatt en sikkerhetskopi, skriv hvor, slik at kollegene dine ikke trenger å lete etter den. Hvis du har gjort noen ikke-åpenbare eller komplekse handlinger, skriv det ned: du vil gå hjem, og problemet kan gjentas eller oppstå for noen andre, og løsningen din vil bli funnet ved hjelp av nøkkelord. Selv om du gjør noe du kan godt, kan det hende at kollegene dine ikke gjør det.
3. Den tredje regelen trenger ikke å bli forklart: "Gjør aldri noe som du ikke vet, forestiller deg eller forstår". Ikke kopier kommandoer fra Internett hvis du ikke vet hva de gjør, ring mann og analyser dem først. Ikke bruk ferdige løsninger hvis du ikke forstår hva de gjør. Hold utførelse av obfuskert kode til et absolutt minimum. Hvis du ikke har tid til å finne ut av det, gjør du noe galt, og du bør lese neste punkt.
4. "Test". Nye skript, verktøy, one-liners og kommandoer bør testes i et kontrollert miljø, ikke på klientmaskinen, hvis det til og med er minimalt med potensial for destruktive handlinger. Selv om du har sikkerhetskopiert alt (og du gjorde det), er ikke nedetid det kuleste. Lag en egen server/virtuell/chroot for dette og test der. Er noe ødelagt? Deretter kan du starte den på "combat".

   
   

5. "Kontroll". Minimer alle operasjoner du ikke kontrollerer. Én pakkeavhengighetskurve kan dra ned halve systemet, og -y-flagget satt for yum remove gir deg muligheten til å øve på systemgjenopprettingsferdighetene fra bunnen av. Hvis handlingen ikke har noen ukontrollerte alternativer, er neste punkt en ferdig backup.
6. "Kryss av". Sjekk konsekvensene av handlingene dine og om du trenger å rulle tilbake til en sikkerhetskopi. Sjekk for å se om problemet virkelig er løst. Sjekk om feilen er gjengitt og under hvilke forhold. Sjekk hva du kan bryte med handlingene dine. Det er unødvendig å stole på arbeidet vårt, men aldri å sjekke.
7. "Kommunisere". Hvis du ikke kan løse problemet, spør kollegene dine om de har vært borti dette. Hvis du vil bruke en kontroversiell avgjørelse, finn ut hva kollegene dine mener. Kanskje de vil tilby en bedre løsning. Hvis du ikke er trygg på handlingene dine, diskuter dem med kollegene dine. Selv om dette er ditt kompetanseområde, kan et nytt blikk på situasjonen avklare mye. Ikke skamm deg over din egen uvitenhet. Det er bedre å stille et dumt spørsmål, se ut som en tosk og få et svar, enn å ikke stille spørsmålet, ikke få svar og ende opp med å bli en tosk.
8. "Ikke avslå hjelp på urimelig måte". Dette punktet er det motsatte av det forrige. Får du et dumt spørsmål, forklar og forklar. De spør etter det umulige – forklar at det er umulig og hvorfor, tilby alternativer. Hvis du ikke har tid (du har virkelig ikke tid, ikke lyst) - si at du har et presserende spørsmål, mye arbeid, men du vil ordne det senere. Dersom kollegaer ikke har presserende oppgaver, tilby å kontakte dem og delegere spørsmålet.
9. "Gi tilbakemelding". Har en av dine kolleger begynt å bruke en ny teknikk eller et nytt manus, og møter du negative konsekvenser av denne avgjørelsen? Rapporter det. Kanskje kan problemet løses på tre linjer med kode eller fem minutter med å finpusse teknikken. Har du kommet over en feil i programvaren din? Rapporter en feil. Hvis det er reproduserbart eller ikke trenger å reproduseres, vil det mest sannsynlig bli fikset. Gi uttrykk for dine ønsker, forslag og konstruktiv kritikk, og ta opp spørsmål til diskusjon hvis de virker relevante.
10. "Be om tilbakemelding". Vi er alle ufullkomne, akkurat som våre avgjørelser, og den beste måten å teste riktigheten av avgjørelsen din på er å ta den opp til diskusjon. Hvis du har optimalisert noe for en klient, be dem om å overvåke arbeidet, kanskje flaskehalsen i systemet ikke er der du lette etter. Du har skrevet et hjelpemanus – vis det til kollegene dine, kanskje de finner en måte å forbedre det på.

Hvis du hele tiden anvender denne praksisen i arbeidet ditt, vil de fleste problemene slutte å være problemer: du vil ikke bare redusere antall egne feil og forfalskninger til et minimum, men du vil også ha muligheten til å rette opp feil (i form for sikkerhetskopier og kolleger som vil råde deg til sikkerhetskopiering). Videre - bare tekniske detaljer, der, som vi vet, djevelen ligger.

De viktigste verktøyene du må jobbe med mer enn 50 % av tiden er grep og vim. Hva kan være enklere? Tekstsøk og tekstredigering. Imidlertid er både grep og vim kraftige multiverktøy som lar deg søke og redigere tekst effektivt. Hvis noen Windows-notisblokker lar deg ganske enkelt skrive/slette en linje, kan du i vim gjøre nesten hva som helst med tekst. Hvis du ikke tror meg, ring vimtutor-kommandoen fra terminalen og begynn å lære. Når det gjelder grep, er dens hovedstyrke i vanlige uttrykk. Ja, selve verktøyet lar deg stille inn søkebetingelser og sende ut data ganske fleksibelt, men uten RegExp gir ikke dette mye mening. Og du trenger å kunne vanlige uttrykk! I hvert fall på et grunnleggende nivå. Til å begynne med vil jeg råde deg til å se på dette video, dekker det grunnleggende om regulære uttrykk og deres bruk i forbindelse med grep. Å ja, når du kombinerer dem med vim, får du den ULTIMATE POWER-evnen til å gjøre ting med tekst som du må merke dem med 18+ ikoner.

Av de resterende 50 % kommer 40 % fra coreutils-verktøysettet. For coreutils kan du se på listen på wikipedia, og manualen for hele listen er på nettsiden GNU. Det som ikke dekkes i dette settet er i verktøyene POSIX. Du trenger ikke å lære alle nøklene utenat, men det er nyttig å i det minste vite omtrent hva de grunnleggende verktøyene kan gjøre. Du trenger ikke finne opp hjulet på nytt fra krykker. Jeg trengte på en eller annen måte å erstatte linjeskift med mellomrom i utdataene fra et eller annet verktøy, og den syke hjernen min fødte en konstruksjon som sed ':a;N;$!ba;s/n/ /g', en kollega kom opp og kjørte meg bort fra konsollen med en kost, og løste deretter problemet ved å skrive tr 'n' ' '.

Jeg vil råde deg til å huske hva hvert enkelt verktøy gjør og nøklene til de mest brukte kommandoene for alt annet som finnes. Ring gjerne mannen hvis du er i tvil. Og sørg for å lese mannen selv - den inneholder viktig informasjon om hva du finner.

Når du kjenner til disse verktøyene, vil du effektivt kunne løse en betydelig del av problemene du vil møte i praksis. I de følgende forelesningene skal vi se på når du skal bruke disse verktøyene og rammeverket for de underliggende tjenestene og applikasjonene de gjelder for.

FirstVDS systemadministrator Kirill Tsvetkov var med deg.

Kilde: www.habr.com