Algajale süsteemiadministraatorile: kuidas segadusest korda teha

Ma olen süsteemiadministraator FirstVDS ja see on minu lühikursuse esimesest vestlusest järgnev tekst, mis on suunatud uutele kolleegidele. Spetsialistid, kes on just hakanud süsteemiadministreerimisega tegelema, seisavad silmitsi sama tüüpi probleemidega. Vastuste pakkumiseks olen otsustanud kirjutada selle loengute tsükli. Kuigi mõned asjad on spetsiifilised hostingu tehnilisele toele, võivad need tervikuna osutuda kasulikuks vähemalt paljudele. Seetõttu kohandasin loenguteksti, et jagada seda siin.

Ei ole oluline, kuidas teid nimetatakse — tähtis on, et te tegelikult tegelete administreerimisega. Alustame seega sellest, millega peaks süsteemiadministraator tegelema. Tema peamine ülesanne on korrastamine, korrashoid ja ettevalmistamine tulevasteks olukordadeks. Ilma süsteemiadministraatorita hakkab serveris valitsema segadus. Logid ei salvestu või sisaldavad vale teavet, ressursid jaotatakse alajaotult, kett täitub jäätmetega ja süsteem hakkab sellise kaose tõttu aeglaselt kokku varisema. Rahunege! Teie ees seisavad süsteemiadministraatorid, kes on valmis probleeme lahendama ja segadust likvideerima!

Süsteemiadministreerimise põhipunktid

Kuid enne probleemide lahendamisele asumist tasub tutvuda nelja põhijärgiga administreerimises:

1. Dokumentatsioon
2. Mallide kasutamine
3. Optimeerimine
4. Automatiseerimine

Need on alused, millele tuginedes ei saa tõhusat ja produktiivset süsteemiadministreerimist üles ehitada. Vaatame igaüht neist eraldi.

Dokumentatsioon

Dokumentatsioon tähendab mitte ainult dokumentatsiooni lugemist (kuigi see on hädavajalik), vaid ka selle pidamist.

Kuidas dokumentatsiooni pidada:

• Kas olete kokku puutunud uue probleemiga, mida te pole kunagi varem näinud? Kirjake üles peamised sümptomid, diagnostika meetodid ja lahendamise põhimõtted.
• Kas leidsid uue elegantse lahenduse tavalisele probleemile? Kirjake see üles, et ei peaks sellele järgmisel kuul uuesti mõtlema.
• Kas keegi aitas teid küsimusest, milles te ei mõistnud midagi? Kirjake üles peamised mõtted ja kontseptsioonid, joonistage endale skeem.

Peamine idee: uute oskuste õppimisel ja rakendamisel ei tasu täielikult loota oma mälule.

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

1. Ärge olge üleliia pikad. Tõstke esile põhiteemad, meetodid ja vahendid. Kui probleemist arusaamiseks on vajalik sukelduda madalatasemelisse mälu haldamise mehhanismi Linuxis, ärge kirjutage ümber artiklit, millest te seda õppisite - viidake sellele.
2. Märkmed peavad olema teile arusaadavad. Kui rida race cond.lockup ei võimalda teil kohe mõista, mida see rida kirjeldab - selgitage. Heas dokumentatsioonis ei pea tundide viisi vaeva nägema.
3. Otsing on väga hea funktsioon. Kui hoidate blogi, lisage silte; kui füüsilises märkmikus - kleepige väiksed post-it'id kirjeldustega. Dokumentatsioonis pole erilist mõtet, kui kulutate vastuse leidmiseks sama palju aega kui probleemi ise lahendamisele.

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

Te ei pea mitte ainult otsima samu vastuseid korduvalt: dokumenteerimine on suurepärane abivahend uute teemade õppimisel (märkus on ju!), arendab teie intuitsiooni (võimet diagnoosida keerulisi probleeme, heites vaid ühe pinnapealse pilgu) ning lisab teie tegevusele organiseeritust. Kui dokumentatsioon on teie kolleegidele kergesti ligipääsetav, aitab see neil mõista, mida ja kuidas te seal olete kokku keeranud, kui te ei ole kohal.

Malli loomine

Malli loomine on mallide loomine ja kasutamine. Enamikule tüüpilistele probleemidele tuleks luua kindel tegevusmall. Enamik probleemide diagnoosimise puhul tuleks kasutada standardiseeritud tegevuste järjestust. Kui olete midagi parandanud/paigaldanud/optimeerinud, tuleks selle töötavust kontrollida standardiseeritud kontrollnimekirjade järgi.

Malli vormindamine on parim viis tööprotsessi korraldamiseks. Kasutades tüüpilisi protseduure sagedaste probleemide lahendamiseks, saavutate palju kasulikke tulemusi. Näiteks kontrollnimekirjade kasutamine võimaldab teil diagnostika käigus tuvastada kõik olulised tööfunktsioonid ja kõrvaldada ebaolulise funktsionaalsuse kontrollimise. Standardiseeritud protseduurid vähendavad tarbetut segadust ja vähendavad vea tekkimise tõenäosust.

Esimene oluline punkt on see, et protseduure ja kontrollnimekirju tuleb samuti dokumenteerida. Lootes lihtsalt mälule, võite jätta vahele mõne tegelikult olulise kontrolli või toimingu ning kogu töö võib kokku kukkuda. Teine oluline punkt on see, et kõiki mallipõhiseid praktikaid saab ja tuleb olukorra nõudmisel muuta. Ideaalseid ja täiesti universaalseid malle ei ole. Kui probleem on olemas ja malliline kontroll seda ei tuvastanud, ei tähenda see, et probleemi ei ole. Enne kontrollimist hüpoteetiliste ja vähe tõenäoliste probleemide üle tasub alati kõigepealt teha kiire malliline kontroll.

Optimeerimine

Optimeerimine räägib enda eest. Tööprotsessi tuleb maksimaalselt optimeerida ajakulu ja vaevanõudmise osas. Siin on lõputult võimalusi: õppige kuumad klahvid, lühenemised, regulaaravaldised ja saadaolevad tööriistad. Otsige praktilisemaid viise nende tööriistade kasutamiseks. Kui kutsute päeva jooksul 100 korda üles ülesande, minge see klahvikombinatsioonile. Kui peate regulaarsete ajavahemike järel samadele serveritele ühendust võtma, kirjutage alias ühe sõnana, mis viib teid sinna.

Tutvuge erinevate saadaolevate tööriistade variantidega – võib-olla on olemas mugavam terminalikliendi, töölaud, lõikepuhver, brauser, e-posti klient, operatsioonisüsteem. Uurige, milliseid tööriistu kasutavad teie kolleegid ja tuttavad – võib-olla nad valivad neid mitte juhuslikult. Pärast tööriistade valimist õppige neid kasutama: õppige võtmeid, lühenemisi, näpunäiteid ja trikke.

Kasutage standardseid tööriistu nagu coreutils, vim, regulaaravaldised, bash optimaalsete tulemuste saavutamiseks. Viimase kolme kohta on olemas hulk suurepäraseid käsiraamatuid ja dokumentatsiooni. Nende abil on võimalik kiiresti liikuda seisundist "ma tunnen end nagu ahv, kes püüab mutreid sülearvutiga lõhki lüüa" selle staadiumini, kus "ma olen ahv, kes kasutab sülearvutit, et tellida pähkliprinterit."

Automatiseerimine

Automatiseerimine viib rasketelt toimingutelt meie väsinud käte pealt väsimatu automaatika kätkedele. Kui mõni standardne protseduur on viie sama tüüpi käsu täitmine, siis miks mitte pakkida kõik need käsud ühte faili ja kutsuda ühe käsu, mis selle faili tõmbab ja täidab?

Tegelikult koosneb automaatimine 80% oma tööriistade kirjutamisest ja optimeerimisest (ning 20% katsetamisest, et neid õigesti tööle panna). See võib olla lihtsalt arenenud ühekohaline käsk või tohutu kõikehõlmav tööriist veebiliidese ja API-ga. Peamine kriteerium on see, et tööriista loomine ei peaks võtma rohkem aega ja vaeva kui see, kui palju aega ja vaeva see tööriist teile kokku hoiab. Kui veedate viis tundi skripti kirjutamisega, mis teile enam kunagi kasulik ei ole, ülesande jaoks, mille lahendamiseks kuluks teil ilma skriptita tund või kaks — on see väga halb tööprotsessi optimeerimine. Viie tunni tööriista loomine on lubatud ainult siis, kui tehtavate ülesannete hulka, tüüpi ja aega see võimaldab, mis ei juhtu sageli.

Automaatimine ei tähenda tingimata täieõiguslike skriptide kirjutamist. Näiteks, et luua hulk ühesuguseid objekte loendist, piisab leidlikust ühekohalisest käskust, mis automaatselt teeb seda, mida te teeksite oma kätega, vahetades akende vahel ja toimetades palju kopeerimise ja kleepimisega.

Tegelikult, kui ehitada haldustsükkel nende nelja sambaga, võib oma efektiivsust, tootlikkust ja kvalifikatsiooni kiiresti tõsta. Siiski tuleb sellele nimekirjale lisada veel üks punkt, ilma milleta on IT-töötamine praktiliselt võimatu — eneseteadlikkus.

Süsteemiadministraatori eneseteadlikkus

Ettevõttes selles valdkonnas vähemalt pisut kompetentsed olema, tuleb pidevalt õppida ja uutest asjadest teada saada. Kui teil pole mingisugust soovi silmitsi seista tundmatuga ja aru saada, kukute te kiiresti läbi. IT-s ilmuvad pidevalt igasugused uued lahendused, tehnoloogiad ja meetodid, ning kui te ei õpi neid vähemalt pinnapealselt — olete kaotuse teel. Paljud informaatika valdkonnad toetuvad väga keerulisele ja ulatuslikule põhialusele. Näiteks võrgutöö. Võrgud ja internet on kõikjal, kohtute nendega igapäevaselt, kuid kui kaevuda tehnikatesse, mis nende taga on, avastate tohutu ja väga keerulise teaduse, mille õppimine — ei ole sugugi jalutuskäik pargis.

Ma ei lisanud neid punkte nimekirja, sest see on IT jaoks üldiselt, mitte ainult süsteemi haldamise jaoks. Loomulikult ei õnnestu teil kõike kohe ja täielikult õppida — teil pole lihtsalt füüsiliselt piisavalt aega. Seetõttu tuleb enesetäiendamisel silmas pidada vajalikke abstraktsiooni tasemeid.

Te ei pea kohe õppima, kuidas iga eraldi tööriista sisemine mälu haldamine töötab ja kuidas see suhtleb Linuxi mälu haldamisega, aga see, mis operatiivmälu kujundlikult endast kujutab ja miks see vajalik on, on hea teada. Te ei pea teadma, kuidas TCP ja UDP pealkirjade struktuuriliselt erinevad, kuid oleks hea mõista nende protokollide peamisi erinevusi töös. Te ei pea uurima, mida tähendavad signaali nõrgenemised optikas, kuid oleks hea teada, miks tõelised kadu alati sõlmedes edasi antakse. Pole midagi halba selles, et teate, kuidas teatud elemendid teatud abstraktsiooni tasemel töötavad, ja pole vajalik kõiki tasemeid täielikult lahti võtta, kui abstraktsiooni üldse ei eksisteeri (te lihtsalt lähete hulluks).

Siiski ei ole oma valdkonnas arutlemine abstraktsiooni tasemel "noh, see on selline asi, mis võimaldab näidata saite" — väga hea. Järgmised loengud keskenduvad põhivaldkondade ülevaatusele, millega süsteemi administraator töö tõttu madalamatel abstraktsiooni tasemetel kokku puutub. Püüan piirata käsitletavaid teadmisi minimaalse abstraktsiooni tasemeni.

10 käsu süsteemi haldamiseks

Nii, oleme õppinud neli peamist alust ja alust. Kas saame probleemide lahendamisega alustada? Veel ei saa. Enne on mõistlik tutvuda nii nimetatud „parimate praktikatega“ ja headuse reeglitega. Ilma nendeta on oht, et teete rohkem kahju kui kasu. Nii et alustame:

1. Mõned mu kolleegid arvavad, et esimene reegel on „ära tee halba“. Kuid ma kipun sellega mitte nõustuma. Kui üritad mitte halba teha, siis ei saa sa ka midagi teha — liiga palju tegevusi on potentsiaalselt destruktiivsed. Peamine reegel on minu arvates — „tee varukoopia“. Isegi kui teed kahju, saad alati tagasi minna ja kõik ei ole enam nii hull.

   Varukoopiaid tuleks teha alati, kui aeg ja koht seda lubavad. Varukoopiaid tuleb teha sellest, mida kavatsete muuta, ja sellest, mida riskite kaotada potentsiaalselt destruktiivse tegevuse käigus. Varukoopia tuleks kontrollida terviklikkuse ja kõikide vajalike andmete olemasolu osas. Varukoopiat ei tohiks kohe pärast seda kustutada, kui olete kõik kontrollinud, kui te ei pea vabastama ketta ruumi. Kui ruumi on liiga vähe — tehke varukoopia oma isiklikule serverile ja eemaldage see nädala pärast.

2. Teine tähtsuselt reegel (mida ma ise sageli rikun) on „ära varja“. Kui oled teinud varukoopia, kirjuta üles — kuhu, et sinu kolleegidel ei peaks seda otsima minema. Kui oled teinud mõningaid mitteilmsi või keerulisi toiminguid, kirja pane: lähed kodu, kuid probleem võib korduda või kellegil teisel tekkida ja sinu lahendus leitakse märksõnade kaudu. Isegi kui teed midagi, mida hästi tead, ei pruugi seda teadma sinu kolleegid.
3. Kolmandat reeglina ei pea selgitama: „ära tee kunagi seda, mille tagajärgi sa ei tea, ei kujuta ette ega mõista“. Ära kopeeri käske internetist, kui sa ei tea, mida nad teevad, kutsu man välja ja analüüsi esmalt. Ära kasuta valmis lahendusi, kui sa ei saa aru, mida nad teevad. Vähenda absoluutsele miinimumile obfuskeritud koodi käitamise. Kui sul ei ole aega süveneda, teed sa midagi valesti ja peaksid tutvuma järgmise punktiga.
4. „testi“. Uued skriptid, tööriistad, ühe realised koodid ja käsud tuleks testida kontrollitud keskkonnas, mitte kliendi arvutis, kui seal on kasvõi minimaalne potentsiaal hävitavateks tegevusteks. Isegi kui olete kõik varundanud (ja te olete seda teinud), ei ole seisak kõige toredam asi. Looge selle jaoks eraldi server/virtuaalmasin/chroot ja testige seal. Kas midagi ei katkenud? Siis võib alustada "tootis" versiooniga.

   
   

5. „Kontrolli“. Vähendage miinimumini kõik toimingud, mida te ei kontrolli. Üks vale sõltuvus paketist võib kaasa tõmmata pool süsteemi, ja lipp -y, mis on määratud yum remove jaoks, annab teile võimaluse harjutada süsteemi taastamist nullist. Kui toimingul ei ole kontrollimatute alternatiive — liikuge järgmise punkti ja valmidusvara poole.
6. „Kontrolli“. Kontrollige oma tegevuste tagajärgi ja kas peate varukoopia peale tagasi minema. Kontrollige, kas probleem on tõeliselt lahendatud. Kontrollige, kas viga kordub ja millistes tingimustes. Kontrollige, mida te oma toimingutega murda saate. Usaldamine meie töös — liigne, kuid kontrollimine — mitte kunagi.
7. „Suhtle“. Kui probleem ei lahene, küsige kolleegidelt, kas nad on samasuguste probleemidega kokku puutunud. Kui soovite rakendada vaieldavat lahendust — uurige kolleegide arvamust. Võib-olla pakuvad nad paremat lahendust. Kui te oma tegevustes ei ole kindel — arutage neid kolleegidega. Isegi kui see on teie teadmiste valdkond, võib värske vaatenurk palju selgitada. Ärge kartke oma teadmiste puudumist. Paremini on küsida rumalat küsimust, näida tobedana ja selle küsimuse kohta vastus saada, kui mitte küsida seda küsimust, mitte saada vastust ja jääda tobedaks.
8. „Ära keela abi ilma põhjuseta“. See punkt on eelneva tagakülg. Kui teile esitati rumal küsimus — selgitage ja selgitage. Kui küsitakse midagi teostatamatut — selgitage, et see on teostatav ja miks, pakkudes alternatiive. Kui teil ei ole aega (reaalselt ei ole aega, mitte soovide puudumine) — öelge, et teil on kiire küsimus või suur töökoormus, kuid te lahendate selle hiljem. Kui teie kolleegidel ei ole kiireid ülesandeid, pakkuge neilt abi ja delegeerige probleem.
9. „Anna tagasisidet“. Kui keegi kolleegidest on hakanud rakendama uut meetodit või uut skripti ning te kohtate selle otsuse negatiivseid tagajärgi, andke sellest teada. Probleem võib lahenduda kolme koodi rea või viie minuti lisandustega. Kas kohtasite tarkvaras puudust? Andke teada. Kui seda on võimalik korrata või ei pea seda korrata, siis tõenäoliselt parandatakse see. Jagage oma soove, ettepanekuid ja konstruktiivset kriitikat, arutage teemasid, mis tunduvad olevat aktuaalsed.
10. «Küsi tagasisidet». Me kõik oleme ebatäiuslikud, nagu ka meie lahendused, ja parim viis oma otsuse õigsuse kontrollimiseks on see arutusele võtta. Kas olete kliendi juures midagi optimeerinud — paluge jälgida tööd, võib-olla on süsteemis „pudelikael” mitte seal, kus te otsisite. Kas olete kirjutanud abiks skripti — näidake seda kolleegidele, nad võivad leida viisi selle parandamiseks.

Kui neid praktikaid pidevalt rakendada, lakkab suurem osa probleemidest olemast probleemid: te ei vähenda mitte ainult oma vigade ja eksimuste arvu miinimumini, vaid teil on ka võimalused neid parandada (backuppide ja kolleegide näol, kes soovitavad teil varundada). Edasi liikudes — ainult tehnilised detailid, milles, nagu teada, peitub kurat.

Põhiworkingriistad, millega peate rohkem kui 50% ajast töötama — grep ja vim. Mis võiks olla lihtsam? Tekstipõhine otsing ja teksti redigeerimine. Kuid grep ja vim on võimsad multifunktsionaalsed tööriistad, mis võimaldavad tõhusalt otsida ja redigeerida teksti. Kui mõni Windowsi Notepad võimaldab teil lihtsalt rida kirjutada/kustutada, siis vim'is saate tekstiga teha peaaegu kõike. Ei usu — kutsuge terminalist välja käsk vimtutor ja alustage õppimist. Mis puudutab grepi — tema peamine jõud on regulaarsetes väljendites. Jah, see tööriist võimaldab üsna paindlikult määrata otsingu tingimused ja väljundandmed, kuid ilma RegExp-ita ei ole sellel erilist mõtet. Ja regulaarsete väljendite tundmine on vajalik! Vähemalt põhitõdede tasemel. Alguseks soovitaksin vaadata seda. video, see seal as regular expressions and their applications together with grep. Oh yes, when combined with vim, you gain ULTIMATE POWER to do such things with text that they have to be labeled 18+.

Out of the remaining 50%, 40% is accounted for by the coreutils toolkit. You can find the list for coreutils at vikipeediale, and the manual for the entire list is available on the website Gnu’s Not Unix), mille eesmärgiks on arendada süsteemikomponente, et luua vabalt kasutatav Unix'i analoog, mis võimaldab täielikult loobuda suletud tarkvarast. GNU juhtimisel on moodustatud vabade projektide kogukond, mis liiguvad ühise eesmärgi suunas ja arenevad ühtse ideoloogia ja filosoofia kohaselt. Alguses olid projekti keskseid elemente. What is not covered by this set can be found in utilities POSIX-i. It's not necessary to memorize all the keys by heart, but it's useful to at least know what the main tools can do — it saves you from reinventing the wheel with crutches. Once, I needed to replace line breaks with spaces in the output from some utility, and my tired brain came up with something like sed ':a;N;$!ba;s/n/ /g', a colleague who approached chased me away from the console with a broom, and then solved the problem by writing tr 'n' ' '.

I would recommend remembering what each individual tool roughly does and the keys to the most frequently used commands; for everything else, there's man. Don't hesitate to call man if you're in doubt about something. And definitely read man on man itself — it contains important information about what you'll find.

Knowing these tools, you will be able to effectively solve a significant portion of the tasks you encounter in practice. In the upcoming lectures, we will discuss when to apply these tools and the structures of the main services and applications they relate to.

This is system administrator Kirill Tsvetkov from FirstVDS.

Allikas: habr.com