Algajale süsteemiadministratsioon: kuidas kaosest korda luua

Olen FirstVDSi süsteemiadministraator ning see on tekst minu lühikursuse esimesest sissejuhatavast loengust, mis on mõeldud algajale kolleegile. Spetsialistid, kes on hiljuti alustanud süsteemiadministreerimisega, seisavad silmitsi mitmete samade probleemidega. Pakkuda lahendusi, otsustasin kirjutada selle loengute tsükli. Mõned asjad on spetsiifilised hostingu tehnilise toe jaoks, kuid üldiselt võivad need osutuda kasulikuks, kui mitte kõigile, siis paljudele. Seepärast kohandasin loengu teksti, et jagada seda siin.

Ei ole oluline, kuidas teie ametit nimetatakse — tähtis on see, et te tegelikult tegelete haldamisega. Seetõttu alustame sellest, mida süsteemiadministraator tegema peab. Tema põhiülesanne on korrastamine, korra hoidmine ja ette valmistamine eelseisvateks suurendusteks. Ilma süsteemiadministraatorita muutub serveris olukord segaseks. Logisid ei kirjutata või neis on vale teave, ressursid jaotatakse ebaoptimaalselt, kett täitub igasuguse prügi ja süsteem hakkab suure kaose tõttu aeglaselt kokku kukkuma. Rahu! Süsteemiadministraatorid teie ees asuvad probleemide lahendamisele ja segaduse kõrvaldamisele!

Süsteemiadministratsiooni alustalad

Kuid enne probleemide lahendama asumist tasub tutvuda nelja põhialusega, mida haldamine eeldab:

1. Dokumentatsioon
2. Malli loomine
3. Optimeerimine
4. Automatiseerimine

See on aluste alus. Kui te ei raja oma tööprotsessi nende põhimõtete peale, jääb see ebaefektiivseks, produktiivseks ja ei meenuta tõelist haldamist. Vaatame igaüht eraldi.

Dokumentatsioon

Dokumentatsioon ei tähenda ainult dokumentatsiooni lugemist (kuigi ilma selleta ei saa), vaid ka selle pidamist.

Kuidas koostada dokumentatsiooni:

• Kas olete sattunud uue probleemi otsa, mida te pole kunagi varem näinud? Kirjeldage põhilisi sümptomeid, diagnostika viise ja lahendamise põhimõtteid.
• Kas leidsid elegantse lahenduse tavalisele probleemile? Kirjuta see üles, et ei peaks seda kuu aja pärast uuesti välja mõtlema.
• Kas keegi aitas sul aru saada küsimusest, milles sa mitte midagi ei mõistnud? Kirjuta üles põhiteesid ja kontseptsioonid, joonista endale skeem.

Põhiteema: ei tohiks täielikult usaldada oma mälu uue omandamisel ja rakendamisel.

Millises formaadis seda teete, sõltub ainult teist: see võib olla märgistusüsteem, isiklik blogi, tekstifail või füüsiline märkmik. Peamine on, et teie märkmed vastavad järgmistele nõuetele:

1. Ärge olge liigsed pikad.Tooge esile peamised ideed, meetodid ja vahendid. Kui probleemi mõistmine nõuab süvenemist Linuxi mälu eraldamise madalamate mehhanismidesse, ärge kirjutage ümber artiklit, millest te seda õppisite — viidake sellele.
2. Märkmed peavad olema teile arusaadavad. Kui rida race cond.lockup ei luba teil kohe aru saada, mida te selle reaga kirjeldasite - selgitage. Heas dokumentatsioonis ei pea pool tundi otsima.
3. Otsing on väga hea funktsioon. Kui te peate päevikut, lisage sildid; kui füüsilisse märkmikusse - kleepige väiksed post-it'id koos kirjeldustega. Dokumentatsioonis pole mõtet, kui te selle kaudu vastuse leidmiseks kulutate sama kaua aega, kui oleksite investeerinud probleemist lahenduse leidmisse alates nullist.

Nii võib dokumentatsioon välja näha: alates primitiivsetest märkmetest märkmikus (ülemine pilt) kuni täisfunktsionaalse mitme kasutaja teadmistebaasini siltide, otsingu ja kõigi võimalike mugavustega (allpool).

Te ei pea mitte ainult otsima sama vastust kaks korda: dokumenteerimine on suurepärane abivahend uute teemade õppimisel (kokkuvõtted ju!), arendab teie ämbliku intuitsiooni (võimet diagnoosida keerulisi probleeme, heites vaid ühe pinnapealse pilgu), lisab teie tegevusele organiseeritust. Kui dokumentatsioon on teie kolleegidele kergesti kättesaadav, võimaldab see neil aru saada, mida ja kuidas te seal teinud olete, kui te ei viibi kohal.

Mallide loomine

Mallide loomine — see on mallide loomine ja kasutamine. Enamikku tüüpilisi küsimusi lahendades tasub luua teatud tegevusmall. Enamikku probleeme diagnoosides tuleb kasutada standardiseeritud tegevuste järjestust. Kui olete midagi parandanud/paigaldanud/optimeerinud, tasub selle toimimist kontrollida vastavalt standardiseeritud kontrollnimekirjadele.

Malle kasutamine on parim viis tööprotsessi korraldamiseks. Kasutades tüüpilisi protseduure kõige sagedamate probleemide lahendamiseks, saate palju kasulikku. Näiteks kontrollnimekirjade kasutamine võimaldab teil diagnoosida kõik olulised tööfunktsioonid ja kõrvaldada ebaolulise funktsionaalsuse diagnoosimine. Standardiseeritud protseduurid vähendavad tarbetu segaduse tekkimise võimalust ja vähendavad vea tõenäosust.

Esimene oluline punkt on see, et protseduure ja kontrollliste tuleb samuti dokumenteerida. Kui loota lihtsalt mälule, võib mõni tõeliselt oluline kontroll või toiming jätta tähelepanuta ja kõik kokku kukkuda. Teine oluline punkt on see, et kõiki mallipraktikaid saab ja tuleb modifitseerida, kui olukord seda nõuab. Täiuslikke ja täiesti universaalseid malle ei ole. Kui probleem esineb, kuid malli kontroll ei ole seda tuvastanud, ei tähenda see, et probleemi ei oleks. Kuid enne, kui asuda kontrollima võimalikke ebatõenäolisi hüpoteetilisi probleeme, tuleks alati esmalt teha kiire mallikontroll.

Optimeerimine

Optimeerimine kõneleb enda eest. Töövoog tuleb maksimaalselt optimeerida aega ja tööjõudu arvestades. Siin on lõputult võimalusi: õppige kiirkLinke, lühendeid, regulaaravaldisi ja olemasolevaid tööriistu. Otsige praktilisemaid kasutusvõimalusi nende tööriistadega. Kui kutsute paar korda päevas sama käsku, seadistage see klaviatuuril lühendiks. Kui peate pidevalt ühenduma samade serveritega, saate seadistada aliasi ühe sõnaga, mis viib teid sinna:

Tutvuge erinevate saadaval olevate tööriistadega — võib-olla on olemas mugavam terminali klient, DE, lõikepulk, brauser, e-posti klient, operatsioonisüsteem. Uurige, milliseid tööriistu kasutavad teie kolleegid ja tuttavad — ehk nad valivad need mitte ilma põhjuseta. Pärast tööriistade valimist õppige neid rakendama: harjuta klavisi, otseteid, näpunäiteid ja nippe.

Kasutage standardseid tööriistu võimalikult tõhusalt — coreutils, vim, regulaaravaldised, bash. Viie viimase osas on tohutult palju suurepäraseid juhiseid ja dokumentatsiooni. Nende abil on võimalik üsna kiiresti liikuda seisundist "ma tunnen end nagu ahv, kes lööb pähkleid sülearvutiga" kuni "ma olen ahv, kes kasutab sülearvutit pähklipurustaja tellimiseks."

Automatiseerimine

Automatiseerimine viib rasketest toimingutest meie väsinud kätest masinaga töötavate käte külge. Kui mõnda standardset protseduuri täidetakse viie samasuguse käsuga, siis miks mitte mähkida kõik need käsud ühte faili ja kutsuda välja üks käsk, mis selle faili alla laadib ja täidab?

Tõeliselt automatiseerimine koosneb 80% oma tööriistade kirjutamisest ja optimeerimisest (ja veel 20% katsetamisest, et need töötaksid nagu peaks). See võib olla lihtsalt keeruline ühesõnaline skript või suur, kõikvõimas tööriist veebiliidese ja API-ga. Peamine kriteerium on see, et tööriista loomine ei tohiks võtta rohkem aega ja vaeva kui see, kui palju aega ja vaeva see tööriist säästab. Kui te kirjutate skripti viis tundi, mis pole kunagi enam vajalik, ülesande lahendamiseks, milleks oleks arvatavasti kulunud tund-kaks ilma skriptita — see on väga halb protsessi optimeerimine. Viie tunni tööriista loomine on põhjendatud ainult siis, kui ülesannete hulk, tüüp ja aeg seda võimaldavad, mis juhtub harva.

Automatiseerimine ei tähenda tingimata täiendavate skriptide kirjutamist. Näiteks, et luua hulk sarnaseid objekte loendist, piisab oskuslikust ühesõnalistest skriptidest, mis automatiseerivad selle, mida te teeksite käsitsi, akende vahel vahetades, koos hulkade kopeeritud ja kleebitud teksti.

Tegelikult, kui ehitada haldusprotsess nende nelja samba peale, siis on võimalik üsna kiiresti suurendada oma efektiivsust, tootlikkust ja kvalifikatsiooni. Kuid seda nimekirja tuleb täiendada veel ühe punktiga, ilma milleta on IT töö praktiliselt võimatu — eneseharimisega.

Süsteemiadministraatori eneseharimine

Kuna olla selles valdkonnas vähemalt veidi kompetentne, on vajalik pidevalt õppida ja uut teada saada. Kui teil puudub vähimgi soov silmitsi seista tundmatuga ja arusaada asjadest, siis kukute väga kiiresti madalamale tasemele. IT-s ilmuvad pidevalt uued lahendused, tehnoloogiad ja meetodid, ning kui te ei tutvu nendega vähemalt pinnapealselt — olete kaotamise teel. Paljud infotehnoloogia valdkonnad toetuvad üsna keerulisele ja ulatuslikule alusele. Näiteks võrgu töö. Võrgud ja internet on igal pool, te puutute nendega kokku igapäevaselt, kuid kui kaevate välja tehnoloogiat, mis nende taga seisab, leiate tohutu ja väga keerulise distsipliini, mille uurimine ei ole sugugi lihtne jalutuskäik pargis.

Ma ei lisanud seda punkti nimekirja, kuna see on oluline IT valdkonnas üldiselt, mitte ainult süsteemiadministreerimises. Loomulikult ei ole võimalik kõike korraga õppida — teil ei jätku lihtsalt füüsiliselt aega. Seetõttu tuleb enesetäiendamisel arvestada vajalike abstraktsiooni tasemetega.

Te ei pea kohe õppima, kuidas iga eraldi tööriista sisemine mälu haldamine töötab ja kuidas see suhtleb Linuxi mälu haldamisega, kuid oleks kasulik teada, milline on operatiivmälu skeemiliselt ja miks see vajalik on. Te ei pea teadma, kuidas TCP ja UDP päised struktuuriliselt erinevad, kuid oleks hea mõista protokollide põhilisi erinevusi töös. Te ei pea uurima, mis on signaali nõrgenemine optikas, kuid oleks kasulik teada, miks reaalsed kadud päranduvad alati sõlmedele. Pole midagi halba selles, et teate, kuidas teatud elemendid töötavad teatud abstraktsioonitasemel, ja ei ole vajalik peatuda kõigil tasanditel, kui abstraktsiooni pole üldse (te lihtsalt kaotate arusaama).

Kuid oma valdkonnas abstraktsiooni tasemel arutamine "see on lihtsalt asi, mis võimaldab näidata veebilehti" — ei ole väga hea. Järgmised loengud keskenduvad peamistele valdkondadele, millega süsteemiadministraator oma töö käigus madalamate abstraktsioonitasemete juures kokku puutub. Püüan piirata käsitletavate teadmiste arvu minimaalsele abstraktsioonitasemele.

10 süsteemiadministreerimise käsku

Nii oleme õppinud neli peamist alust ja vundamenti. Kas saame alustada probleemide lahendamist? Mitte veel. Enne seda on soovitatav tutvuda nii nimetatud „parimate praktikate” ja head tavad. Ilma neis, on oht, et teete rohkem kahju kui kasu. Alustame siis:

1. Mõned mu kolleegid arvavad, et kõige esimene reegel on „ära tee halba”. Kuid ma ei ole nõus. Kui püüad mitte kahjustada, siis ei saa ka midagi teha — liiga palju tegevusi on potentsiaalselt destruktiivsed. Kõige olulisem reegel, mida ma pean, on — „tee varukoopia”. Isegi kui teete kahju, on alati võimalik tagasi rullida, ja siis ei ole kõik enam nii hull.

   Backup peaks should be a priority whenever time and space permit. Focus on backing up what you'll modify and what you risk losing due to potential destructive actions. It's a good idea to verify the integrity of the backup and ensure all necessary data is included. Don’t delete the backup right after verification unless you need to free up disk space. If space is a concern, back it up to your personal server and delete it after a week.

2. The second most important rule (which I often break myself) — «don’t keep it hidden». If you’ve created a backup, let others know where it is so that your colleagues don’t have to search for it. If you've performed any non-obvious or complex actions, document them: you might leave for the day, but the problem can recur or arise for someone else, and your solution can be found by searching relevant keywords. Even if you’re doing something you're familiar with, your colleagues may not know it.
3. The third rule needs no explanation: «never do something whose consequences you don't know, can't envision, or don’t understand». Ära kopeeri käske internetist, kui sa ei tea, mida need teevad; kasuta man'i ja analüüsi neid esmalt. Ära rakenda valmis lahendusi, kui sa ei mõista, mida need teevad. Vähenda obfuskeeritud koodi täitmist absoluutsele miinimumile. Kui sul pole aega süveneda — teed sa midagi valesti ja peaksid tutvuma järgmise punktiga.
4. „Testi“. Uusi skripte, tööriistu, ühesõnalisi käske ja komande tuleb testida kontrollitud keskkonnas, mitte kliendi masinal, kui seal on vähemalt minimaalne potentsiaal hävitavateks tegevusteks. Isegi kui oled kõik varundanud (ja sa tegid seda), siis katkestus ei ole kõige meeldivam asi. Sea selleks eraldi server/virtuaalmasin/chroot ja testi seal. Kas midagi ei rikutud? Siis võid ellu viia „tootmises“.

   
   

5. „Kontrolli“. Minimeerige kõik teie kontrolli all olevaid toiminguid. Ühe paketi kõver sõltuvus võib inimesi kaasa tõmmata poolest süsteemist, ja yum remove lipp -y, annab teile võimaluse harjutada oma oskusi süsteemi taastamisest nullist. Kui toimingul ei ole kontrollimatuid alternatiive — liikuge järgmise punkti ja valmis varukoopia juurde.
6. „Kontrolli“. Kontrollige oma tegevuste tagajärgi ja kas on vaja varukoopia peale tagasi minna. Kontrollige, kas probleem on tõepoolest lahendatud. Kontrollige, kas viga kordub ja millistes tingimustes see juhtub. Kontrollige, mida saaksite oma tegevustega rikkuda. Usaldus meie töös on üleliigne, kuid kontrollimine — kunagi mitte.
7. „Suhtle“. Kui probleem ei lahene, küsige kolleegidelt, kas nad on sellise olukorraga kokku puutunud. Kui soovite rakendada vaidlusalust lahendust, uurige kolleegide arvamust. Võimalik, et nad pakuvad paremat lahendust. Kui te pole oma tegevustes kindel, arutage neid kolleegidega. Isegi kui see on teie ekspertvaldkond, võib värske vaatenurk palju selgust tuua. Ärge kartke oma teadmiste puudumist. parem on esitada rumal küsimus, paista tola ja saada sellele vastus, kui mitte esitada küsimust, mitte saada vastust ja jääda tola.
8. „Ära keela abi alusetult“. See punkt on eelneva vastand. Kui teile esitatakse rumal küsimus, selgitage ja selgitage. Kui palutakse midagi, mis on teostatav, selgitage, miks see ei ole võimalik ja pakkuge alternatiive. Kui pole aega (reaalselt pole aega, mitte ei taha) – öelge, et teil on kiire küsimus või suur töökoormus, kuid lahendate selle hiljem. Kui kolleegidel pole kiireid ülesandeid, pakkuda, et nad pöörduksid teie poole ja delegeerida küsimus.
9. „Andke tagasisidet“. Kas keegi teie kolleegidest on hakanud kasutama uut meetodit või skripti ning te saate negatiivseid tagajärgi selle otsuse tõttu? Andke sellest teada. Probleem võib lahendada kolme rea koodi või viie minuti meetodi täiustamisega. Kas leidsid tarkvaras vea? Teata veast. Kui see on korduv või pole vajalik selle korratavuse kontrollimine, siis tõenäoliselt parandatakse see. Jagage oma soove, ettepanekuid ja konstruktiivset kriitikat, tugege küsimusi aruteluks, kui tundub, et need on aktuaalsed.
10. „Küsi tagasisidet“. Me kõik ei ole ideaalsed, nagu ei ole ka meie otsused, ja parim viis kontrollida oma otsuse õigsust on tuua see aruteluks. Kui olete kliendi juures midagi optimeerinud, paluge neil jälgida tööd, võib-olla on süsteemis pudelikael teises kohas, kui te otsisite. Kui olete kirjutanud väikese abiskripti, näidake seda kolleegidele, võib-olla leiavad nad viisi selle täiustamiseks.

Kui neid tavasid pidevalt rakendada, lakivad enamik probleemidest olemast probleemid: te mitte ainult ei vähenda oma kõrvalekaldeid ja eksimusi miinimumini, vaid teil on ka võimalus vigu parandada (varukoopiate ja kolleegide, kes soovitavad teil varundada, abil). Edasi liigume vaid tehniliste detailide juurde, kus nagu teada, peitubki kurat.

Peamised tööriistad, millega peate töötama rohkem kui 50% ajast, on grep ja vim. Mis võiks olla lihtsam? Teksti otsimine ja redigeerimine. Siiski on nii grep kui ka vim võimsad multifunktsionaalsed tööriistad, mis võimaldavad teksti tõhusalt otsida ja redigeerida. Kui mõni Windowsi notepad võimaldab teil lihtsalt rida kirjutada/ kustutada, siis vim'is saate tekstiga peaaegu kõike teha. Ei usu? Käivitage terminalis käsk vimtutor ja hakake õppima. Mis puudutab grep'i, siis tema peamine jõud seisneb regulaarsetes väljendites. Jah, see tööriist võimaldab üsna paindlikult määrata otsingutingimusi ja väljundandmeid, kuid ilma RegExp'ita pole sellel erilist mõtet. Ja regulaarseid väljendeid on vaja teada! Isegi põhitasemel. Alustuseks soovitaksin teil vaadata seda video, see käsitleb regulaarsete väljendite ja nende rakendamise aluseid koos grep'iga. Ah jah, nende ühendamisel vim'iga saate ULTIMATE POWER võimaluse teha tekstiga selliseid asju, et neid on vaja varustada 18+ ikoonidega.

Järelejäänud 50%-st tuleb 40% coreutils'i tööriistakomplektist. Coreutils'i nimekirja leiate vikipeedia, ja kogu nimekirja manuaal on veebis GNU. Mis ei kuulu selle komplekti, on utiliitides POSIX. Ei ole tingimata vajalik seda kõike peast teada, kuid oleks kasulik mõista, mida põhivahendid suudavad — siis ei pea ratast uuesti leiutama. Kunagi pidin asendama reavahed tühikutega mingi utiliidi väljundis ja mu ekslikud mõtted viisid sellise konstruktsioonini sed ':a;N;$!ba;s/n/ /g', kolleeg, kes lähenes, peletas mind konsoolist välja ja lahendas ülesande, kirjutades tr 'n' ' '.

Soovitan meeles pidada, mida iga eraldi tööriist ja nende võtmed peamiselt teevad; selle kõikide jaoks on man. Ärge kartke kutsuda man, kui te milleski kahtlete. Ja kindlasti lugege man'i ka man'i kohta — seal on oluline teave selle kohta, mida te leiate.

Nende tööriistade tundmine võimaldab teil tõhusalt lahendada olulise osa probleemidest, millega praktikas kokku puutute. Järgmistes loengutes käsitleme, millal neid tööriistu ja struktuure rakendada ning milliste põhiteenuste ja rakendustega need on seotud.

Teiega oli süsteemihaldur FirstVDS Kirill Tsvetkov.

Allikas: habr.com