Till nybörjarsystemadministratören: hur man skapar ordning ur kaos

Jag är systemadministratör på FirstVDS, och detta är texten för den första introduktionsföreläsningen i min korta kurs för att hjälpa nya kollegor. Specialister som nyligen har börjat syssla med systemadministration stöter på en rad gemensamma problem. För att erbjuda lösningar har jag tagit mig an att skriva denna serie föreläsningar. Vissa saker i den är specifika för teknisk support för webbhotell, men generellt kan de vara till nytta, om inte för alla, så för många. Därför har jag anpassat texten för föreläsningen för att dela den här.

Det spelar ingen roll vad din titel är — det viktiga är att du faktiskt sysslar med administration. Så låt oss börja med vad en systemadministratör ska göra. Den huvudsakliga uppgiften är att städa upp, upprätthålla ordning och förbereda för framtida ökning av ordning. Utan en systemadministratör blir det kaos på servern. Loggar skrivs inte, eller de innehåller inte vad de ska, resurserna fördelas på ett ineffektivt sätt, disken fylls med all möjlig skräp och systemet börjar sakta att lida av all denna oordning. Lugn! Systemadministratörer i ditt ansikte tar sig an att lösa problem och städa upp kaoset!

Säulen för systemadministration

Men innan vi börjar lösa problem, är det värt att bekanta sig med de fyra grundpilarna för administration:

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

Detta är grunderna. Om du inte bygger din arbetsprocess på dessa principer kommer den att vara ineffektiv, oproduktiv och i allmänhet knappt likna verklig administration. Låt oss gå igenom varje punkt noggrant.

Dokumentation

Dokumentation innebär inte bara att läsa dokumentation (även om det är nödvändigt), utan också att föra anteckningar.

Så här för du dokumentation:

• Har du stött på ett nytt problem som du aldrig har sett förut? Skriv ner de grundläggande symtomen, metoderna för diagnos och principerna för lösning.
• Har du kommit på en ny elegant lösning på ett typiskt problem? Skriv ner den så att du inte behöver uppfinna den på nytt om en månad.
• Har någon hjälpt dig att lösa en fråga som du inte förstod något av? Skriv ner de grundläggande punkterna och koncepten, rita en skiss för dig själv.

Huvudidén: du bör inte helt lita på ditt eget minne när du lär dig och tillämpar nya saker.

I vilket format du gör detta beror endast på dig: det kan vara ett noteringssystem, en personlig blogg, en textfil eller en fysisk anteckningsbok. Det viktigaste är att dina anteckningar uppfyller följande krav:

1. Inte vara alltför långa. Lyfta fram de viktigaste idéerna, metoderna och verktygen. Om förståelsen av problemet kräver att man dyker ner i den lågnivåmekanik som rör minneshanteringen i Linux, ska du inte skriva om artikeln från vilken du lärde dig det — ge bara en länk till den.
2. Anteckningarna måste vara förståeliga för dig. Om raden race cond.lockup inte gör att du genast förstår vad du beskrivit med den raden - förklara. Bra dokumentation kräver inte att man gräver i en halvtimme för att förstå.
3. Sökning är en mycket bra funktion. Om du skriver i en blogg, lägg till taggar; om i en fysisk anteckningsbok - klistra små post-it-lappar med beskrivningar. Det finns inte mycket mening med dokumentation om du spenderar lika mycket tid på att söka efter svar där som du skulle göra på att lösa frågan från början.

Så här kan dokumentationen se ut: från primitiva anteckningar i en anteckningsbok (bilden ovan), till en fullfjädrad flervalskunskapsbas med taggar, sökning och alla tänkbara bekvämligheter (nederst).

Du kommer inte bara att behöva söka efter samma svar två gånger: dokumentation kommer att vara en fantastisk hjälp när du lär dig nya ämnen (anteckningar, eller hur!), förbättra din intuition (förmågan att diagnostisera ett komplext problem vid en hastig blick), och tillföra struktur i dina handlingar. Om dokumentationen är tillgänglig för dina kolleger, kommer den även att hjälpa dem att förstå vad och hur du har gjort när du inte är på plats.

Mallförfarande

Mallförfarande är skapandet och användningen av mallar. För att lösa de flesta standardfrågor är det värt att skapa en specifik handlingsmall. För att diagnostisera de flesta problem bör en standardiserad handlingssekvens användas. När du har åtgärdat/installera/optimerat något, är det viktigt att kontrollera funktionaliteten genom standardiserade checklistor.

Mallisering är det bästa sättet att organisera arbetsprocessen. Genom att använda standardiserade procedurer för att lösa de mest vanligt förekommande problemen får du massor av fördelar. Till exempel, att använda checklistor gör att du kan diagnostisera alla viktiga funktioner för arbetet och utesluta mindre viktiga funktioner. Standardiserade procedurer minimerar onödiga osäkerheter och minskar risken för fel.

Det första viktiga att tänka på är att procedurer och checklistor också behöver dokumenteras. Om man bara litar på minnet kan man missa en verkligen viktig kontroll eller operation, vilket kan leda till problem. Den andra viktiga punkten är att alla mallar och rutiner kan och bör modifieras om situationen kräver det. Det finns inga perfekta och helt universella mallar. Om det finns ett problem och den mallade kontrollen inte identifierade det betyder det inte att problemet inte finns. Men innan du börjar kontrollera osannolika hypotetiska problem bör du alltid först genomföra en snabb mall- kontroll.

Optimering

Optimering talar för sig själv. Arbetsprocessen måste optimeras så mycket som möjligt när det gäller tids- och arbetsinsats. Det finns otaliga alternativ: lär dig tangentbordsgenvägar, förkortningar, reguljära uttryck och tillgängliga verktyg. Sök efter mer praktiska användningar av dessa verktyg. Om du använder ett kommando 100 gånger om dagen, häng upp det på en tangentbordsgenväg. Om du regelbundet behöver ansluta till samma servrar, skriv ett alias i ett ord som kopplar dig dit:

Utforska olika alternativ av tillgängliga verktyg — kanske finns det en mer praktisk terminalklient, DE, urklippshanterare, webbläsare, e-postklient eller operativsystem. Ta reda på vilka verktyg dina kollegor och bekanta använder — kanske väljer de dem av en anledning. Efter att ha valt verktyg, lär dig att använda dem: memorera knappar, förkortningar, tips och tricks.

Optimalt använda standardverktyg — coreutils, vim, reguljära uttryck, bash. För de tre senaste finns det mängder av fantastiska manualer och dokumentation. Med deras hjälp kan man ganska snabbt gå från att "känna sig som en apa som slår nötter med en laptop" till "jag är en apa som använder en laptop för att beställa en nötknäckare".

Automatisering

Automatisering överför tunga operationer från våra trötta händer till de oupphörliga händerna av automation. Om någon standardprocedur utförs med fem identiska kommandon, varför inte slå ihop alla dessa kommandon i en fil och kalla på ett enda kommando som laddar ner och utför filen?

Egentligen består automation till 80% av att skriva och optimera sina egna verktyg (och 20% av att få dem att fungera som de ska). Det kan vara en avancerad enradare eller ett enormt allsmäktigt verktyg med webgränssnitt och API. Huvudkriteriet här är att skapandet av verktyget inte får ta mer tid och ansträngning än den tid och ansträngning som verktyget sparar. Om du spenderar fem timmar på att skriva ett skript som du aldrig kommer att använda igen för en uppgift som skulle ta en eller två timmar utan skript — det är en mycket dålig optimering av arbetsflödet. Man kan spendera fem timmar på att skapa ett verktyg, bara om mängden, typen av uppgifter och tiden tillåter det, vilket sällan är fallet.

Automation innebär inte nödvändigtvis att skriva fullständiga skript. Till exempel, för att skapa en mängd liknande objekt från en lista behöver man bara en smart enradare som automatiskt gör det du skulle göra för hand, skiftande mellan fönster med massor av copy-paste.

Egentligen, om man bygger administrationsprocessen på dessa fyra pelare, kan man ganska snabbt öka sin effektivitet, produktivitet och kompetens. Men denna lista behöver kompletteras med ytterligare en punkt, utan vilken arbete inom IT nästan är omöjligt — självutbildning.

Självutbildning för systemadministratörer

För att vara något kompetent inom detta område måste man ständigt lära sig och upptäcka nytt. Om du inte har minsta lust att konfrontera det okända och förstå det, kommer du snabbt att «falla». Inom IT dyker det ständigt upp nya lösningar, teknologier och metoder, och om du inte studerar dem åtminstone ytligt — är du på väg att förlora. Många områden inom informationsteknologi vilar på en ganska komplex och omfattande grund. Till exempel nätverksarbete. Nätverk och internet finns överallt, du stöter på dem dagligen, men när du börjar gräva i teknologierna bakom dem, upptäcker du en enorm och mycket komplex disciplin vars studium — absolut inte är en promenad i parken.

Jag tog inte med detta punkt i listan eftersom den är avgörande för IT i allmänhet, och inte bara för systemadministration. Naturligtvis kan du inte lära dig allt på en gång — du har helt enkelt inte tillräckligt med tid. Därför bör du vid självutbildning komma ihåg de nödvändiga abstraktionsnivåerna.

Du behöver inte direkt lära dig hur den interna minneshanteringen fungerar för varje enskild applikation, och hur den interagerar med minneshanteringen i Linux, men det är bra att veta vad RAM schema ser ut och varför det behövs. Du behöver inte veta hur TCP- och UDP-huvuden strukturellt skiljer sig åt, men det vore bra att förstå grundläggande skillnader i protokollens funktion. Du behöver inte studera vad signaldämpningar i optik innebär, men det vore bra att veta varför verkliga förluster alltid är kopplade till noder. Det är inget fel med att veta hur vissa element fungerar på en viss abstraktionsnivå, och det är inte nödvändigt att förstå alla nivåer när det inte finns någon abstraktion alls (du kommer bara att bli galen).

Men inom sitt område är det inte så bra att resonera på en abstraktionsnivå som "ja, det är en grej som låter oss visa webbplatser". De kommande föreläsningarna kommer att handla om en översikt över de grundläggande områden som systemadministratörer måste konfrontera i arbetet på lägre abstraktionsnivåer. Jag kommer att försöka begränsa mängden kunskap som täcks till den minimi abstraaktionsnivå.

10 budord för systemadministration

Så, vi har lärt oss fyra grundpelare och en grund. Kan vi börja lösa problemen? Inte ännu. Innan dess är det bra att bekanta sig med så kallade "best practices" och regler för god ton. Utan dem finns det risk att du orsakar mer skada än nytta. Så, låt oss börja:

1. Några av mina kollegor anser att den allra första regeln är "gör ingen skada". Men jag lutar åt att inte hålla med. När man försöker att inte skada kan man inte heller åstadkomma något — för många handlingar är potentiellt destruktiva. Den viktigaste regeln anser jag är — "gör en backup". Även om du orsakar skada, kan du alltid återgå, och allt blir inte så dåligt.

   Man bör alltid göra en backup när tid och plats tillåter det. Backup bör göras på det som du kommer att ändra och det som du riskerar att förlora vid potentiellt destruktiva handlingar. Backup bör verifieras på integritet och närvaro av alla nödvändiga data. Backup bör inte raderas direkt efter att du har kontrollerat allt, om det inte är nödvändigt att frigöra diskutrymme. Om det krävs plats — gör en backup på din personliga server och ta bort den efter en vecka.

2. Den näst viktigaste regeln (som jag själv ofta bryter) är — "dölj inte". Om du har gjort en backup, skriv ner — vart, så att dina kollegor inte behöver leta efter den. Om du har utfört några otydliga eller komplicerade åtgärder, skriv ner dem: du går hem, och problemet kan komma tillbaka eller uppstå för någon annan, och din lösning kommer att hittas med nyckelord. Även om du gör något som du känner till väl, kan dina kollegor sakna den kunskapen.
3. Den tredje regeln behöver ingen förklaring: "gör aldrig det vars konsekvenser du inte känner till, inte föreställer dig eller inte förstår". Kopiera inte kommandon från internet om du inte vet vad de gör, kalla på man och analysera dem först. Använd inte färdiga lösningar om du inte kan förstå vad de gör. Minimera användningen av obfuskerad kod. Om du inte har tid att förstå — då gör du något fel och du bör bekanta dig med nästa punkt.
4. "testa". Nya skript, verktyg, enradare och kommandon bör testas i en kontrollerad miljö, inte på klientmaskinen, om det finns någon som helst potentiell risk för destruktiva åtgärder. Även om du har tagit backup (och det har du), är nedtid inte en rolig sak. Skaffa en separat server/virtuell maskin/chroot för detta ändamål och testa där. Inget är trasigt? Då kan du köra i produktion.

   
   

5. «Kontrollera». Minimera alla operationer som du inte har kontroll över. En felaktig beroende hos ett paket kan dra med sig halva systemet, och flaggan -y för yum remove ger dig möjlighet att träna på att återställa systemet från grunden. Om åtgärden inte har några okontrollerbara alternativ — går vi vidare till nästa punkt med en färdig backup.
6. «Kontrollera». Kontrollera konsekvenserna av dina åtgärder och om du behöver återgå till backupen. Kontrollera om problemet verkligen har lösts. Kontrollera om felet går att reproducera och under vilka förhållanden. Kontrollera vad du kan bryta med dina åtgärder. Att lita på i vårt arbete — är överflödigt, men att kontrollera — är aldrig fel.
7. «Kommunicera». Om du inte kan lösa problemet, fråga kollegor om de har stött på något liknande. Vill du tillämpa en tveksam lösning — ta reda på vad kollegorna tycker. Kanske föreslår de en bättre lösning. Har du ingen säkerhet i dina åtgärder — diskutera dem med kollegor. Även om det är ditt expertområde, kan en fräsch synvinkel klargöra mycket. Tveka inte att erkänna vad du inte vet. Bättre att ställa en dum fråga, verka dum och få ett svar, än att inte ställa frågan, inte få något svar och förbli dum.
8. «Avböj inte att hjälpa utan anledning». Denna punkt är motsatsen till föregående. Om du får en dum fråga — klargör och förklara. Om någon ber om något omöjligt — förklara varför det är omöjligt och erbjud alternativ. Om du verkligen inte har tid (verkligen ingen tid, inte bara ovilja) — säg att du har en brådskande fråga och en stor arbetsbelastning, men att du kommer att ta itu med det senare. Om kollegorna inte har några brådskande uppgifter, föreslå att de kan kontakta dem och delegera frågan.
9. «Ge feedback». Har en kollega börjat använda en ny metod eller ett nytt skript, och nu upplever du negativa konsekvenser av detta beslut? Rapportera detta. Kanske kan problemet lösas med tre rader kod eller fem minuters justeringar av metoden. Har du stött på en bugg i mjukvaran? Rapportera buggen. Om den går att reproducera eller inte behöver reproduceras, kommer den sannolikt att fixas. Framför önskemål, förslag och konstruktiv kritik, ta upp frågor till diskussion om de verkar relevanta.
10. «Be om feedback». Vi är alla ofullkomliga, precis som våra beslut, och det bästa sättet att verifiera riktigheten av ens beslut är att ta upp det till diskussion. Har du optimerat något för en kund—be dem att övervaka arbetet, kanske finns det ett ‘flaskhals’ i systemet där du inte letade. Har du skrivit ett hjälpskript—visa det för kollegorna, kanske de hittar sätt att förbättra det.

Om du ständigt tillämpar dessa metoder i arbetet, slutar majoriteten av problemen att vara problem: du minskar inte bara antalet egna misstag och stora missöden, utan får också möjlighet att korrigera fel (genom backups och kollegor som råder dig att göra en backup). Nästa steg är endast tekniska detaljer, där som bekant djävulen ligger.

De viktigaste verktygen som du kommer att arbeta med mer än 50% av tiden är grep och vim. Vad kan vara enklare? Sökning i text och redigering av text. Men både grep och vim är kraftfulla multifunktionella verktyg som gör det möjligt att söka och redigera text effektivt. Om en Windows notepad bara låter dig skriva/ta bort en rad, så kan du i vim göra nästan vad som helst med texten. Tveka inte—använd kommandot vimtutor från terminalen och börja lära dig. När det kommer till grep är dess styrka i reguljära uttryck. Ja, verktyget gör det möjligt att ställa in sök- och utdata villkor ganska flexibelt, men utan RegExp har det inte så mycket mening. Och du behöver åtminstone kunna grundläggande kunskaper om reguljära uttryck. För att börja skulle jag rekommendera att du tittar på det här. video, i de förklaras grunderna i reguljära uttryck och deras tillämpning tillsammans med grep. Åh ja, när du kombinerar dem med vim, får du ULTIMATE POWER att göra med texten sådana saker att de måste märkas med 18+ etiketter.

Av de kvarvarande 50 % utgör 40 % verktygspaketet coreutils. För coreutils kan du se listan i Wikipedia, och manualen för hela listan finns på webbplatsen (Gnu’s Not Unix), som syftar till att utveckla systemkomponenter för att skapa ett fritt alternativ till Unix, vilket gör det möjligt att helt undvika proprietär programvara. Under GNU:s skydd har det skapats en gemenskap av fria projekt, som rör sig mot ett gemensamt mål och utvecklas i enlighet med en enad ideologi och filosofi. Initialt var de centrala delarna av projektet. Vad som inte täcks av detta kit finns i verktygen POSIX. Det är inte nödvändigt att memorera detta med alla nycklar, men det är bra att åtminstone ungefär veta vad de viktigaste verktygen kan — det är användbart. Du behöver inte uppfinna hjulet åter med krumelurer. Jag behövde en gång ersätta radbrytningar med blanksteg i utdata från något verktyg, och min trötta hjärna kom på en konstruktion som sed ':a;N;$!ba;s/n/ /g', en kollega som kom förbi drev mig bort från konsolen med en kvast, och sedan löste han problemet genom att skriva tr 'n' ' '.

Jag skulle rekommendera att minnas vad varje enskilt verktyg gör och nycklarna för de mest använda kommandona, för allt annat finns det man. Tveka inte att kalla på man om du är osäker på något. Och se till att läsa man på själva man — det innehåller viktig information om vad du kommer att hitta.

Genom att känna till dessa verktyg kan du effektivt lösa en stor del av de uppgifter du kommer att möta i praktiken. I kommande föreläsningar kommer vi att gå igenom när man ska använda dessa verktyg och strukturerna för de grundläggande tjänster och applikationer de gäller.

Med dig var systemadministratören FirstVDS Kirill Tsvetkov.

Källa: habr.com