🥇För en nybörjare systemadministratör: hur man gör ordning på kaos

Jag är FirstVDS-systemadministratör, och det här är texten till den första introduktionsföreläsningen från min korta kurs om att hjälpa nybörjare. Specialister som nyligen har börjat ägna sig åt systemadministration möter ett antal av samma problem. För att erbjuda lösningar åtog jag mig att skriva denna föreläsningsserie. Vissa saker i den är specifika för att tillhandahålla teknisk support, men i allmänhet kan de vara användbara, om inte för alla, så för många. Så jag har anpassat föreläsningstexten för att dela här.

Det spelar ingen roll vad din position heter - det som spelar roll är att du faktiskt är involverad i administrationen. Låt oss därför börja med vad en systemadministratör bör göra. Dess främsta uppgift är att få ordning på saker och ting, hålla ordning och reda på framtida ökningar. Utan en systemadministratör blir servern en enda röra. Loggar skrivs inte, eller fel saker skrivs i dem, resurserna fördelas inte optimalt, disken fylls med alla sorters skräp och systemet börjar sakta dö av så mycket kaos. Lugnt! Systemadministratörer i din person börjar lösa problem och eliminera röran!

Systemadministrationens pelare

Men innan du börjar lösa problem är det värt att bekanta dig med de fyra huvudpelarna för administration:

Dokumentation
Mallar
Optimering
Automatisering

Detta är grunderna. Om du inte bygger ditt arbetsflöde på dessa principer kommer det att bli ineffektivt, improduktivt och i allmänhet inte likna verklig administration. Låt oss titta på var och en separat.

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

Документация betyder inte att läsa dokumentation (även om du inte kan vara utan den), utan också att underhålla den.

Så här sparar du dokumentation:

Har du stött på ett nytt problem som du aldrig har sett förut? Skriv ner de viktigaste symptomen, metoderna för diagnos och principerna för eliminering.
Har du kommit på en ny, elegant lösning på ett vanligt problem? Skriv ner det så att du inte behöver uppfinna det igen om en månad.
Hjälpte de dig att lista ut en fråga du inte förstod? Skriv ner huvudpunkterna och begreppen, rita ett diagram för dig själv.

Huvudtanken: du ska inte helt lita på ditt eget minne när du behärskar och tillämpar nya saker.

I vilket format du kommer att göra detta är upp till dig: det kan vara ett system med anteckningar, en personlig blogg, en textfil, ett fysiskt anteckningsblock. Huvudsaken är att dina register uppfyller följande krav:

Var inte för lång. Lyft fram de viktigaste idéerna, metoderna och verktygen. Om att förstå ett problem kräver att du dyker in i lågnivåmekaniken för minnesallokering i Linux, skriv inte om artikeln du lärde dig det från - ge en länk till den.
Posterna ska vara tydliga för dig. Om linjen race cond.lockup låter dig inte omedelbart förstå vad du beskrev med denna rad - förklara. Bra dokumentation tar inte en halvtimme att förstå.
Sök är en mycket bra funktion. Om du skriver blogginlägg, lägg till taggar; om i en fysisk anteckningsbok, klistra små post-its med beskrivningar. Det är ingen mening med dokumentation om du lägger lika mycket tid på att leta efter ett svar i den som du skulle spendera på att lösa frågan från början.

Så här kan dokumentation se ut: från primitiva anteckningar i ett anteckningsblock (bilden ovan), till en fullfjädrad kunskapsbas för flera användare med taggar, sökning och alla möjliga bekvämligheter (nedan).

Du behöver inte bara leta efter samma svar två gånger, utan att dokumentera kommer att vara till stor hjälp för att lära dig nya ämnen (anteckningar!), kommer att förbättra din spindelkänsla (förmågan att diagnostisera ett komplext problem med en ytlig blick), och kommer att lägga till organisation till dina handlingar. Om dokumentationen är tillgänglig för dina kollegor kommer de att kunna ta reda på vad och hur du hopade där när du inte är där.

Mallar

Mallar är att skapa och använda mallar. För att lösa de flesta typiska problem är det värt att skapa en specifik handlingsmall. En standardiserad sekvens av steg bör användas för att diagnostisera de flesta problem. När du har reparerat/installerat/optimerat något ska prestandan för detta kontrolleras med hjälp av standardiserade checklistor.

Mallar är det bästa sättet att organisera ditt arbetsflöde. Genom att använda standardprocedurer för att lösa de vanligaste problemen får du en hel del coola grejer. Genom att till exempel använda checklistor kan du diagnostisera alla funktioner som är viktiga för ditt arbete och ignorera diagnosen oviktig funktionalitet. Och standardiserade procedurer kommer att minimera onödiga kast och minska sannolikheten för fel.

Den första viktiga punkten är att även rutiner och checklistor behöver dokumenteras. Om du bara litar på minnet kan du missa någon riktigt viktig kontroll eller operation och förstöra allt. Den andra viktiga punkten är att all mallpraxis kan och bör modifieras om situationen kräver det. Det finns inga idealiska och absolut universella mallar. Om det finns ett problem, men en mallkontroll inte avslöjade det, betyder det inte att det inte är något problem. Men innan du börjar testa några osannolika hypotetiska problem är det alltid värt att göra ett snabbt malltest först.

optimering

optimering talar för sig själv. Arbetsprocessen behöver optimeras så mycket som möjligt vad gäller tid och arbetskostnader. Det finns otaliga alternativ: lär dig kortkommandon, förkortningar, reguljära uttryck, tillgängliga verktyg. Leta efter mer praktisk användning av dessa verktyg. Om du ringer ett kommando 100 gånger om dagen, tilldela det till en kortkommando. Om du regelbundet behöver ansluta till samma servrar, skriv ett alias i ett ord som kopplar dig dit:

Bekanta dig med de olika alternativen som finns för verktyg - kanske finns det en mer bekväm terminalklient, DE, urklippshanterare, webbläsare, e-postklient, operativsystem. Ta reda på vilka verktyg dina kollegor och vänner använder – kanske väljer de dem av en anledning. När du har verktygen, lär dig hur du använder dem: lär dig nycklar, förkortningar, tips och tricks.

Utnyttja standardverktyg optimalt - coreutils, vim, reguljära uttryck, bash. För de tre sista finns det ett stort antal underbara manualer och dokumentation. Med deras hjälp kan du snabbt gå från tillståndet "Jag känner mig som en apa som knäcker nötter med en bärbar dator" till "Jag är en apa som använder en bärbar dator för att beställa mig en nötknäckare."

Automation

Automation kommer att överföra svåra operationer från våra trötta händer till automations outtröttliga händer. Om någon standardprocedur utförs i fem kommandon av samma typ, varför inte slå in alla dessa kommandon i en fil och anropa ett kommando som laddar ner och kör den här filen?

Automatiseringen i sig är att 80 % skriver och optimerar dina egna verktyg (och ytterligare 20 % försöker få dem att fungera som de ska). Det kan bara vara en avancerad one-liner eller ett enormt allsmäktigt verktyg med ett webbgränssnitt och API. Huvudkriteriet här är att skapa ett verktyg inte bör ta mer tid och ansträngning än den mängd tid och ansträngning som verktyget kommer att spara dig. Om du lägger fem timmar på att skriva ett manus som du aldrig kommer att behöva igen, för en uppgift som skulle ha tagit dig en timme eller två att lösa utan manuset, är detta en mycket dålig arbetsflödesoptimering. Du kan spendera fem timmar på att skapa ett verktyg bara om antalet, typen av uppgifter och tiden tillåter det, vilket inte ofta är fallet.

Automatisering innebär inte nödvändigtvis att skriva fullfjädrade skript. Till exempel, för att skapa ett gäng objekt av samma typ från en lista, behöver du bara en smart one-liner som automatiskt gör vad du skulle göra för hand, växla mellan fönster, med massor av copy-paste.

Om du bygger administrationsprocessen på dessa fyra pelare kan du faktiskt snabbt öka din effektivitet, produktivitet och kvalifikationer. Denna lista behöver dock kompletteras med ytterligare en punkt, utan vilken det är nästan omöjligt att arbeta inom IT - självutbildning.

Systemadministratör självutbildning

För att vara ens lite kompetent inom detta område måste du ständigt studera och lära dig nya saker. Om du inte har den minsta önskan att möta det okända och lista ut det, kommer du att fastna väldigt snabbt. Det dyker ständigt upp alla möjliga nya lösningar, teknologier och metoder inom IT, och om man inte studerar dem åtminstone ytligt är man på väg att misslyckas. Många områden inom informationsteknologin står på en mycket komplex och omfångsrik grund. Till exempel nätverksdrift. Nätverk och internet finns överallt, du stöter på dem varje dag, men när du väl gräver i tekniken bakom dem kommer du att upptäcka en enorm och mycket komplex disciplin, vars studie aldrig är en promenad i parken.

Jag tog inte med denna post i listan eftersom den är nyckeln för IT i allmänhet, och inte bara för systemadministration. Naturligtvis kommer du inte att kunna lära dig allt direkt - du har helt enkelt inte tillräckligt med tid fysiskt. Därför bör du komma ihåg de nödvändiga abstraktionsnivåerna när du utbildar dig själv.

Du behöver inte omedelbart lära dig hur den interna minneshanteringen för varje enskilt verktyg fungerar och hur den interagerar med Linux-minneshanteringen, men det är bra att veta vad RAM är schematiskt och varför det behövs. Du behöver inte veta hur TCP- och UDP-huvuden är strukturellt olika, men det skulle vara en bra idé att förstå de grundläggande skillnaderna i hur protokollen fungerar. Du behöver inte lära dig vad signaldämpning är i optik, men det skulle vara trevligt att veta varför verkliga förluster alltid ärvs över noder. Det är inget fel med att veta hur vissa element fungerar på en viss abstraktionsnivå och inte nödvändigtvis förstå absolut alla nivåer när det inte finns någon abstraktion alls (du blir bara galen).

Men inom ditt område är det inte särskilt bra att tänka på abstraktionsnivån "ja, det här är en sak som låter dig visa webbplatser". Följande föreläsningar kommer att ägnas åt en översikt över de huvudområden som en systemadministratör måste hantera när man arbetar på lägre abstraktionsnivåer. Jag kommer att försöka begränsa mängden kunskap som granskas till en minimal abstraktionsnivå.

10 budord för systemadministration

Så vi har lärt oss de fyra huvudpelarna och grunden. Kan vi börja lösa problem? Inte än. Innan du gör detta är det tillrådligt att bekanta dig med de så kallade "bästa metoderna" och reglerna för gott uppförande. Utan dem kommer du sannolikt att göra mer skada än nytta. Så, låt oss börja:

Några av mina kollegor tror att den allra första regeln är "gör ingen skada". Men jag är benägen att inte hålla med. När du försöker att inte skada kan du inte göra någonting - för många handlingar är potentiellt destruktiva. Jag tror att den viktigaste regeln är - "gör en säkerhetskopia". Även om du gör en del skada kan du alltid rulla tillbaka och allt blir inte så illa.
Du bör alltid säkerhetskopiera när tid och plats tillåter det. Du måste säkerhetskopiera vad du kommer att förändra och vad du riskerar att förlora på grund av en potentiellt destruktiv handling. Det är tillrådligt att kontrollera säkerhetskopian för integritet och närvaron av all nödvändig data. Säkerhetskopieringen bör inte raderas direkt efter att du har kontrollerat allt, om du inte behöver frigöra diskutrymme. Om platsen kräver det, säkerhetskopiera den till din personliga server och radera den efter en vecka.
Den näst viktigaste regeln (som jag själv ofta bryter mot) är "gömma dig inte". Om du har gjort en säkerhetskopia, skriv var, så att dina kollegor inte behöver leta efter den. Om du gjorde några icke-uppenbara eller komplexa handlingar, skriv ner det: du kommer att gå hem, och problemet kan upprepas eller uppstå för någon annan, och din lösning kommer att hittas med nyckelord. Även om du gör något du kan väl kanske dina kollegor inte gör det.
Den tredje regeln behöver inte förklaras: "Gör aldrig något vars konsekvenser du inte vet, föreställer eller förstår". Kopiera inte kommandon från Internet om du inte vet vad de gör, ring mannen och analysera dem först. Använd inte färdiga lösningar om du inte kan förstå vad de gör. Håll exekvering av obfuskerad kod till ett absolut minimum. Om du inte har tid att ta reda på det, då gör du något fel och du bör läsa nästa punkt.
"Testa". Nya skript, verktyg, one-liners och kommandon bör testas i en kontrollerad miljö, inte på klientdatorn, om det ens finns minimal potential för destruktiva åtgärder. Även om du säkerhetskopierade allt (och det gjorde du), är driftstopp inte det coolaste. Skapa en separat server/virtuell/chroot för detta och testa där. Är något trasigt? Sedan kan du starta den på "combat".
"Kontrollera". Minimera alla operationer som du inte kontrollerar. En paketberoendekurva kan dra ner halva systemet, och flaggan -y för yum remove ger dig möjlighet att öva på dina systemåterställningsfärdigheter från grunden. Om åtgärden inte har några okontrollerade alternativ är nästa punkt en färdig backup.
"Kolla upp". Kontrollera konsekvenserna av dina handlingar och om du behöver återgå till en säkerhetskopia. Kontrollera om problemet verkligen har lösts. Kontrollera om felet återskapas och under vilka förhållanden. Kolla vad du kan bryta med dina handlingar. Det är onödigt att lita på vårt arbete, men aldrig att kontrollera.
"Kommunicera". Om du inte kan lösa problemet, fråga dina kollegor om de har stött på detta. Om du vill tillämpa ett kontroversiellt beslut, ta reda på dina kollegors åsikt. Kanske kommer de att erbjuda en bättre lösning. Om du inte är säker på dina handlingar, diskutera dem med dina kollegor. Även om detta är ditt expertområde, kan en ny titt på situationen klargöra mycket. Skäms inte för din egen okunnighet. Det är bättre att ställa en dum fråga, se ut som en dåre och få ett svar, än att inte ställa frågan, inte få ett svar och sluta bli en dåre.
"Vejra inte hjälp orimligt". Denna punkt är motsatsen till den föregående. Om du får en dum fråga, förtydliga och förklara. De frågar efter det omöjliga - förklara att det är omöjligt och varför, erbjuda alternativ. Om du inte har tid (det finns verkligen ingen tid, inte lust) - säg att du har en brådskande fråga, en stor mängd arbete, men du kommer att reda ut det senare. Om kollegor inte har akuta uppgifter, erbjud dig att kontakta dem och delegera frågan.
"Ge feedback". Har en av dina kollegor börjat använda en ny teknik eller ett nytt manus, och stöter du på negativa konsekvenser av detta beslut? Rapportera det. Kanske kan problemet lösas med tre rader kod eller fem minuters förfining av tekniken. Har du stött på en bugg i din programvara? Rapportera en bugg. Om det är reproducerbart eller inte behöver reproduceras kommer det med största sannolikhet att fixas. Kom med dina önskemål, förslag och konstruktiv kritik och ta upp frågor för diskussion om de verkar relevanta.
"Be om feedback". Vi är alla ofullkomliga, precis som våra beslut, och det bästa sättet att testa riktigheten av ditt beslut är att ta upp det till diskussion. Om du har optimerat något för en kund, be dem att övervaka arbetet, kanske är flaskhalsen i systemet inte där du letade efter. Du har skrivit ett hjälpmanus – visa det för dina kollegor, kanske hittar de ett sätt att förbättra det.

Om du ständigt tillämpar dessa metoder i ditt arbete kommer de flesta av problemen att upphöra att vara problem: du kommer inte bara att minska antalet egna misstag och förfalskningar till ett minimum, utan du kommer också att ha möjlighet att rätta till misstag (i form av säkerhetskopior och kollegor som kommer att råda dig att säkerhetskopiera). Vidare - bara tekniska detaljer, i vilka, som vi vet, djävulen ligger.

De viktigaste verktygen du kommer att behöva arbeta med mer än 50 % av tiden är grep och vim. Vad kan vara enklare? Textsökning och textredigering. Men både grep och vim är kraftfulla multiverktyg som låter dig söka och redigera text effektivt. Om något Windows-anteckningsblock tillåter dig att helt enkelt skriva/ta bort en rad, kan du i vim göra nästan vad som helst med text. Om du inte tror mig, ring kommandot vimtutor från terminalen och börja lära dig. När det gäller grep är dess främsta styrka i reguljära uttryck. Ja, verktyget i sig låter dig ställa in sökvillkor och mata ut data ganska flexibelt, men utan RegExp är det inte mycket meningsfullt. Och du behöver känna till reguljära uttryck! Åtminstone på grundnivå. Till att börja med skulle jag råda dig att titta på detta video, den täcker grunderna för reguljära uttryck och deras användning i samband med grep. Åh ja, när du kombinerar dem med vim får du den ULTIMATE POWER förmågan att göra sådana saker med text att du måste märka dem med 18+ ikoner.

Av de återstående 50 % kommer 40 % från coreutils toolkit. För coreutils kan du titta på listan på wikipedia, och manualen för hela listan finns på webbplatsen GNU. Det som inte täcks i denna uppsättning finns i verktygen POSIX. Du behöver inte lära dig alla nycklar utantill, men det är bra att åtminstone veta ungefär vad de grundläggande verktygen kan göra. Du behöver inte uppfinna hjulet på nytt från kryckor. Jag behövde på något sätt ersätta radbrytningar med mellanslag i utdata från något verktyg, och min sjuka hjärna födde en konstruktion som sed ':a;N;$!ba;s/n/ /g', en kollega kom fram och körde bort mig från konsolen med en kvast, och löste sedan problemet genom att skriva tr 'n' ' '.

Jag skulle råda dig att komma ihåg vad varje enskilt verktyg gör och nycklarna till de mest använda kommandona; för allt annat finns människan. Ring gärna mannen om du är tveksam. Och se till att läsa mannen själv – den innehåller viktig information om vad du hittar.

Genom att känna till dessa verktyg kommer du att effektivt kunna lösa en betydande del av de problem som du kommer att stöta på i praktiken. I följande föreläsningar kommer vi att titta på när man ska använda dessa verktyg och ramverken för de underliggande tjänsterna och applikationerna de gäller.

FirstVDS systemadministratör Kirill Tsvetkov var med dig.

Källa: will.com

För en nybörjare som systemadministratör: hur man skapar ordning ur kaos