🥇 Kezdő rendszergazdának: hogyan csinálj rendet a káoszból

FirstVDS rendszergazda vagyok, ez az első bevezető előadás szövege a kezdő kollégák segítéséről szóló rövid tanfolyamomból. Azok a szakemberek, akik nemrég kezdtek el foglalkozni a rendszeradminisztrációval, számos hasonló problémával szembesülnek. Hogy megoldásokat kínáljak, vállaltam ennek az előadássorozatnak a megírását. Vannak benne dolgok, amelyek kifejezetten a technikai támogatás fogadására vonatkoznak, de általában hasznosak lehetnek, ha nem mindenkinek, akkor sokak számára. Így az előadás szövegét adaptáltam, hogy megosszam itt.

Nem számít, hogy mi a beosztása – az számít, hogy valójában részt vesz az adminisztrációban. Ezért kezdjük azzal, hogy mit kell tennie egy rendszergazdának. Fő feladata a dolgok rendbetétele, a rend fenntartása és a jövőbeli rendnövelésekre való felkészülés. Rendszergazda nélkül a szerver zűrzavarossá válik. A naplókat nem írják, vagy rossz dolgokat írnak bele, az erőforrások nem oszlanak el optimálisan, a lemez megtelik mindenféle szeméttel és a rendszer lassan kihal a sok káosztól. Nyugodtan! A rendszergazdák az Ön személyében elkezdik megoldani a problémákat és megszüntetni a rendetlenséget!

A rendszeradminisztráció pillérei

Mielőtt azonban hozzáfogna a problémák megoldásához, érdemes megismerkedni az adminisztráció négy fő pillérével:

Dokumentáció
Sablonozás
Optimalizálás
Automatizálás

Ez az alap. Ha nem ezekre az elvekre építi fel munkafolyamatát, az eredménytelen lesz, nem lesz eredményes, és általában kevéssé fog hasonlítani a valódi adminisztrációhoz. Nézzük mindegyiket külön-külön.

dokumentáció

dokumentáció nem a dokumentáció elolvasását jelenti (bár enélkül nem megy), hanem a karbantartást is.

A dokumentáció megőrzése:

Találkozott már olyan új problémával, amilyet még soha nem látott? Írja le a főbb tüneteket, a diagnózis módszereit és az elimináció elveit.
Új, elegáns megoldást talált ki egy gyakori problémára? Írd le, hogy ne kelljen egy hónap múlva újra feltalálnod.
Segítettek neked kitalálni egy kérdést, amit nem értesz? Írja le a főbb pontokat és fogalmakat, rajzoljon egy diagramot magának.

A fő gondolat: új dolgok elsajátítása és alkalmazása során nem szabad teljesen megbíznia saját memóriájában.

Hogy ezt milyen formátumban teszi, az Önön múlik: lehet egy rendszer jegyzetekkel, egy személyes blog, egy szöveges fájl, egy fizikai jegyzettömb. A lényeg az, hogy a nyilvántartások megfeleljenek a következő követelményeknek:

Ne legyen túl sokáig. Emelje ki a főbb ötleteket, módszereket és eszközöket! Ha egy probléma megértéséhez bele kell merülni a Linux memóriakiosztás alacsony szintű mechanikájába, ne írja át azt a cikket, amelyből tanulta, hanem adjon meg egy hivatkozást.
A bejegyzéseknek egyértelműnek kell lenniük. Ha a vonal race cond.lockup nem teszi lehetővé, hogy azonnal megértse, amit ezzel a sorral leírt - magyarázza el. A jó dokumentáció megértéséhez nem kell fél óra.
A keresés nagyon jó funkció. Ha blogbejegyzéseket ír, adjon hozzá címkéket; ha fizikai jegyzetfüzetben van, ragasszon kis post-it-eket leírásokkal. Nem sok értelme van a dokumentációnak, ha annyi időt töltesz a válasz keresésével, mint amennyit a kérdés nulláról való megoldásával töltött volna.

Így nézhet ki a dokumentáció: a primitív jegyzetektől a jegyzettömbben (fenti kép), a teljes, többfelhasználós tudásbázisig címkékkel, kereséssel és minden lehetséges kényelemmel (lent).

Nem csak, hogy nem kell kétszer ugyanazokat a válaszokat keresnie, de a dokumentálás nagy segítséget jelent az új témák elsajátításában (jegyzetek!), javítja a pókérzéket (egy felületes pillantással egy összetett probléma diagnosztizálásának képességét), és szervezettséget ad a cselekvéseihez. Ha a dokumentáció elérhető a kollégái számára, akkor ki tudják deríteni, hogy mit és hogyan halmoztál fel ott, amikor nem vagy ott.

Sablonozás

Sablonozás a sablonok létrehozása és használata. A legtöbb tipikus probléma megoldásához érdemes egy konkrét cselekvési sablont létrehozni. A legtöbb probléma diagnosztizálásához szabványos lépéssorozatot kell használni. Ha valamit megjavított/telepített/optimalizált, ennek a valaminek a teljesítményét szabványos ellenőrzőlisták segítségével kell ellenőrizni.

A munkafolyamat megszervezésének legjobb módja a sablonozás. Ha szabványos eljárásokat használ a leggyakoribb problémák megoldására, akkor sok nagyszerű dolgot kap. Például az ellenőrző listák segítségével diagnosztizálhat minden olyan funkciót, amely fontos a munkája szempontjából, és elveti a nem fontos funkciók diagnózisát. A szabványosított eljárások pedig minimalizálják a szükségtelen dobálást és csökkentik a hiba valószínűségét.

Az első fontos pont az, hogy az eljárásokat és az ellenőrző listákat is dokumentálni kell. Ha csak a memóriára hagyatkozik, elmulaszthat néhány igazán fontos ellenőrzést vagy műveletet, és mindent tönkretehet. A második fontos pont az, hogy minden sablongyakorlatot lehet és kell is módosítani, ha a helyzet úgy kívánja. Nincsenek ideális és abszolút univerzális sablonok. Ha van probléma, de a sablonellenőrzés nem tárta fel, az nem jelenti azt, hogy nincs probléma. Mielőtt azonban elkezdené tesztelni néhány valószínűtlen hipotetikus problémát, először mindig érdemes elvégezni egy gyors sablontesztet.

Optimalizálás

Optimalizálás magáért beszél. A munkafolyamatot a lehető legnagyobb mértékben optimalizálni kell az idő és a munkaerőköltség tekintetében. Számtalan lehetőség van: billentyűkódok, rövidítések, reguláris kifejezések, elérhető eszközök megtanulása. Keresse ezeknek az eszközöknek a gyakorlatiasabb felhasználási lehetőségeit. Ha egy parancsot naponta 100-szor hív meg, rendelje hozzá egy billentyűparancshoz. Ha rendszeresen kell csatlakoznia ugyanazokhoz a szerverekhez, írjon be egy álnevet egyetlen szóban, amely oda fog kapcsolódni:

Ismerkedjen meg az eszközök különféle lehetőségeivel – talán van egy kényelmesebb terminálkliens, DE, vágólapkezelő, böngésző, e-mail kliens, operációs rendszer. Tudja meg, milyen eszközöket használnak kollégái és barátai – talán okkal választják őket. Ha megvannak az eszközök, tanuld meg használni őket: tanuld meg a billentyűket, rövidítéseket, tippeket és trükköket.

Optimálisan használja a szabványos eszközöket - coreutils, vim, reguláris kifejezések, bash. Az utolsó háromhoz rengeteg csodálatos kézikönyv és dokumentáció található. Segítségükkel gyorsan eljuthat az „úgy érzem magam, mint egy majom, aki laptoppal töri a diót” állapotból a „Majom vagyok, aki laptoppal rendelek magamnak diótörőt” állapotba.

automatizálás

automatizálás átviszi a nehéz műveleteket fáradt kezünkből az automatizálás fáradhatatlan kezébe. Ha valamilyen szabványos eljárást hajtanak végre öt azonos típusú parancsban, akkor miért ne csomagolná ezeket a parancsokat egy fájlba, és hívhatna meg egy parancsot, amely letölti és végrehajtja ezt a fájlt?

Maga az automatizálás 80%-ban saját eszközeid írását és optimalizálását jelenti (és további 20%-ban megpróbálja őket úgy működni, ahogy kellene). Lehet ez csak egy fejlett egysoros, vagy egy hatalmas, mindenható eszköz webes felülettel és API-val. A fő kritérium itt az, hogy egy eszköz létrehozása nem vesz igénybe több időt és erőfeszítést, mint amennyi időt és erőfeszítést megtakarít az eszközzel. Ha öt órát töltesz egy olyan szkript megírásával, amelyre soha többé nem lesz szükséged egy olyan feladathoz, amelynek megoldása a szkript nélkül egy-két órába telt volna, ez nagyon rossz munkafolyamat-optimalizálás. Csak akkor tölthet öt órát egy eszköz létrehozásával, ha a feladatok száma, típusa és ideje ezt lehetővé teszi, ami nem gyakran történik meg.

Az automatizálás nem feltétlenül jelent teljes értékű szkriptek megírását. Például ahhoz, hogy egy csomó azonos típusú objektumot hozzon létre egy listából, csak egy okos egysorosra van szüksége, amely automatikusan megteszi azt, amit kézzel csinálna, váltogatva az ablakok között, sok másolás-beillesztéssel.

Valójában, ha erre a négy pillérre építi az adminisztrációs folyamatot, gyorsan növelheti hatékonyságát, termelékenységét és képzettségét. Ezt a listát azonban ki kell egészíteni még egy tétellel, amely nélkül az informatikában való munka szinte lehetetlen - az önképzés.

Rendszergazda önképzés

Ahhoz, hogy egy kicsit is hozzáértő legyél ezen a területen, folyamatosan tanulnod és új dolgokat kell megtanulnod. Ha a legcsekélyebb vágyad sincs szembenézni az ismeretlennel és rájönni, akkor nagyon hamar elakadsz. Folyamatosan mindenféle új megoldás, technológia, módszer jelenik meg az informatikában, és ha ezeket legalább felületesen nem tanulmányozod, akkor a kudarc felé haladsz. Az információs technológia számos területe nagyon összetett és terjedelmes alapokon áll. Például a hálózati működés. A hálózatok és az internet mindenhol ott vannak, minden nap találkozunk velük, de ha beleásunk a mögöttük lévő technológiába, egy hatalmas és nagyon összetett tudományágat fedezünk fel, amelynek tanulmányozása soha nem séta a parkban.

Ezt a tételt azért nem vettem fel a listára, mert általában az informatika számára kulcsfontosságú, nem csak a rendszeradminisztráció szempontjából. Természetesen nem fogsz tudni mindent azonnal megtanulni – egyszerűen fizikailag nincs elég időd. Ezért az önképzés során emlékeznie kell az absztrakció szükséges szintjeire.

Nem kell azonnal megtanulnia, hogyan működik az egyes segédprogramok belső memóriakezelése, és hogyan működik együtt a Linux memóriakezeléssel, de jó tudni, hogy sematikusan mi a RAM, és miért van rá szükség. Nem kell tudnia, hogy a TCP és az UDP fejlécek szerkezetileg miben térnek el egymástól, de jó ötlet lenne megérteni a protokollok működésének alapvető különbségeit. Nem kell megtanulnia, hogy mi a jelcsillapítás az optikában, de jó lenne tudni, hogy a valódi veszteségek miért öröklődnek mindig a csomópontokon keresztül. Nincs abban semmi baj, ha tudjuk, hogyan működnek bizonyos elemek az absztrakció egy bizonyos szintjén, és nem feltétlenül értjük meg az összes szintet, amikor egyáltalán nincs absztrakció (csak megőrülsz).

A te szakterületeden azonban nem túl jó az absztrakció szintjén való gondolkodás, hogy „na, ez egy olyan dolog, ami lehetővé teszi a weboldalak megjelenítését”. A következő előadások azoknak a főbb területeknek az áttekintését szolgálják, amelyekkel a rendszeradminisztrátornak foglalkoznia kell, ha az absztrakció alacsonyabb szintjén dolgozik. Megpróbálom az áttekintett ismeretek mennyiségét az absztrakció minimális szintjére korlátozni.

A rendszeradminisztráció 10 parancsolata

Tehát megtanultuk a négy fő pillért és alapot. Elkezdhetjük a problémák megoldását? Még nem. Mielőtt ezt megtenné, tanácsos megismerkedni az úgynevezett „legjobb gyakorlatokkal” és a jó modor szabályaival. Ezek nélkül valószínűleg többet ártasz, mint használsz. Tehát kezdjük:

Néhány kollégám úgy gondolja, hogy a legelső szabály az, hogy „ne árts”. De hajlamos vagyok nem érteni. Ha megpróbálsz nem ártani, nem tudsz semmit tenni – a túl sok cselekvés potenciálisan romboló hatású. Szerintem a legfontosabb szabály: „készíts biztonsági másolatot”. Még ha kárt is teszel, mindig vissza lehet gurulni, és nem lesz minden olyan rossz.
Mindig készítsen biztonsági másolatot, amikor az idő és a hely lehetővé teszi. Biztonsági másolatot kell készítenie arról, hogy mit fog megváltoztatni, és mit kockáztat, hogy elveszítsen egy potenciálisan romboló tevékenység miatt. Célszerű ellenőrizni a biztonsági mentés integritását és az összes szükséges adat meglétét. A biztonsági másolatot nem szabad azonnal törölni, miután mindent ellenőriztünk, kivéve, ha lemezterületet kell felszabadítanunk. Ha a hely megköveteli, készítsen biztonsági másolatot a személyes szerverére, és egy hét múlva törölje.
A második legfontosabb szabály (amit én magam is gyakran megszegek) az "ne bújj el". Ha készítettél biztonsági másolatot, írd meg, hogy hol, nehogy a kollégáidnak kelljen keresniük. Ha nem magától értetődő vagy összetett tevékenységet végzett, írja le: hazamész, és a probléma megismétlődik vagy másnál is felmerülhet, és kulcsszavak segítségével megtalálják a megoldást. Még ha olyasmit is csinál, amit jól tud, a kollégái esetleg nem.
A harmadik szabályt nem kell magyarázni: "soha ne csinálj olyat, aminek a következményeit nem tudod, nem képzeled vagy nem érted". Ne másoljon parancsokat az internetről, ha nem tudja, mit csinálnak, hívja a man-t, és először elemezze őket. Ne használjon kész megoldásokat, ha nem érti, mit csinálnak. Tartsa az obfuszkált kód végrehajtását az abszolút minimumon. Ha nincs ideje rájönni, akkor valamit rosszul csinál, és el kell olvasnia a következő pontot.
"Teszt". Az új szkripteket, eszközöket, egysoros parancsokat és parancsokat nem a kliens gépen, hanem ellenőrzött környezetben kell tesztelni, ha csak minimális potenciál van a romboló műveletekre. Még ha mindenről biztonsági másolatot készített (és megtette), az állásidő nem a legmenőbb dolog. Ehhez hozz létre egy külön szervert/virtuálist/chrootot és ott teszteld. Elromlott valami? Ezután elindíthatja a „harcban”.
"Ellenőrzés". Minimalizálja az összes olyan műveletet, amelyet nem irányít. Egy csomagfüggőségi görbe lehúzhatja a rendszer felét, és a yum remove-hoz beállított -y jelző lehetőséget ad a rendszer-helyreállítási készségek gyakorlására a semmiből. Ha a műveletnek nincsenek ellenőrizetlen alternatívái, akkor a következő pont egy kész mentés.
"Jelölje be". Ellenőrizze tettei következményeit és azt, hogy vissza kell-e térnie egy biztonsági másolathoz. Ellenőrizze, hogy a probléma valóban megoldódott-e. Ellenőrizze, hogy a hiba ismétlődik-e, és milyen feltételek mellett. Ellenőrizd, mit tudsz megtörni a tetteiddel. Felesleges bízni a munkánkban, de ellenőrizni soha.
"Kommunikálni". Ha nem tudja megoldani a problémát, kérdezze meg kollégáit, hogy találkoztak-e ezzel. Ha vitatható döntést szeretne alkalmazni, ismerje meg kollégái véleményét. Talán jobb megoldást kínálnak. Ha nem vagy magabiztos a tetteiben, beszélje meg azokat kollégáival. Még ha ez az Ön szakterülete is, egy újszerű pillantás a helyzetre sok mindent megvilágíthat. Ne szégyelld saját tudatlanságodat. Jobb feltenni egy hülye kérdést, hülyének nézni és választ kapni, mint nem feltenni a kérdést, nem kapni választ, és a végén bolondnak lenni.
"Ne utasítsd vissza a segítséget indokolatlanul". Ez a pont fordítottja az előzőnek. Ha hülyeséget kérdeznek, pontosítsd és magyarázd el. Lehetetlent kérnek – magyarázd el, hogy lehetetlen és miért, kínálj fel alternatívákat. Ha nincs időd (tényleg nincs időd, nem vágyad) - mondd, hogy sürgős kérdésed van, sok munkád van, de később megoldod. Ha a kollégáknak nincs sürgős feladata, ajánlja fel velük a kapcsolatot és delegálja a kérdést.
"Adj visszajelzést". Valamelyik kollégája elkezdett új technikát vagy új forgatókönyvet használni, és találkozik-e ennek a döntésének negatív következményeivel? Jelentsd. Talán három sor kóddal vagy öt percnyi technika finomításával megoldható a probléma. Találkoztál már hibával a szoftveredben? Hiba bejelentése. Ha reprodukálható vagy nem kell reprodukálni, akkor nagy valószínűséggel javítani fogják. Mondja el kívánságait, javaslatait és építő kritikáját, és tegyen fel kérdéseket megvitatásra, ha relevánsnak tűnik.
"Kérjen visszajelzést". Mindannyian tökéletlenek vagyunk, csakúgy, mint a döntéseink, és a legjobb módja annak, hogy tesztelje döntése helyességét, ha szóba hozza a vitát. Ha optimalizált valamit egy ügyfél számára, kérje meg, hogy figyelje a munkát; lehet, hogy a rendszer szűk keresztmetszete nem ott van, ahol kereste. Ön írt egy súgószkriptet – mutassa meg kollégáinak, talán megtalálják a módját a javításának.

Ha folyamatosan alkalmazza ezeket a gyakorlatokat a munkája során, akkor a legtöbb probléma megszűnik probléma lenni: nemcsak a saját hibáinak és hamisításainak a számát csökkenti a minimumra, hanem lehetőség nyílik a hibák kijavítására is (a biztonsági mentések formájában és kollégáival, akik tanácsot adnak Önnek, hogy készítsen biztonsági másolatot). Továbbá - csak technikai részletek, amelyekben, mint tudjuk, az ördög rejlik.

A fő eszközök, amelyekkel az idő több mint 50%-ában kell dolgozni, a grep és a vim. Mi lehetne egyszerűbb? Szövegkeresés és szövegszerkesztés. Azonban mind a grep, mind a vim hatékony többfunkciós eszköz, amely lehetővé teszi a szöveg hatékony keresését és szerkesztését. Ha néhány Windows jegyzettömb lehetővé teszi, hogy egyszerűen írjon/töröljön egy sort, akkor a vim-ben szinte bármit megtehet a szöveggel. Ha nem hiszi nekem, hívja a vimtutor parancsot a terminálból, és kezdje el a tanulást. Ami a grep-et illeti, fő erőssége a reguláris kifejezésekben van. Igen, maga az eszköz lehetővé teszi a keresési feltételek és a kimeneti adatok meglehetősen rugalmas beállítását, de RegExp nélkül ennek nincs sok értelme. És tudnia kell a reguláris kifejezéseket! Legalábbis alap szinten. Kezdésként azt tanácsolom, hogy nézze meg ezt videó, lefedi a reguláris kifejezések alapjait és a grep-pel való használatukat. Ó, igen, ha kombinálja őket a vim-mel, akkor megkapja az ULTIMATE POWER képességet, hogy olyan szöveggel végezzen dolgokat, amelyet 18+ ikonokkal kell megjelölnie.

A fennmaradó 50%-ból 40% a coreutils eszköztárból származik. A coreutils listát a címen tekintheti meg wikipedia, és a teljes lista kézikönyve megtalálható a webhelyen GNÚ. Amire ez a készlet nem vonatkozik, az a segédprogramokban található POSIX. Nem kell fejből megtanulni minden billentyűt, de hasznos, ha legalább nagyjából tudjuk, mire képesek az alapvető eszközök. Nem kell mankóból újra feltalálni a kereket. Valahogy ki kellett cserélnem a sortöréseket szóközökkel a kimenetben valamilyen segédprogramból, és beteg agyam olyan konstrukciót szült, mint pl. sed ':a;N;$!ba;s/n/ /g', odajött egy kolléga, aki egy seprűvel elhajtott a konzoltól, majd írással megoldotta a problémát tr 'n' ' '.

Azt tanácsolom, hogy emlékezzen az egyes eszközök működésére és a leggyakrabban használt parancsok kulcsaira; minden máshoz ott van az ember. Nyugodtan hívja a férfit, ha kétségei vannak. És feltétlenül olvassa el magát az embert - fontos információkat tartalmaz arról, hogy mit fog találni.

Ezen eszközök ismeretében képes lesz hatékonyan megoldani a gyakorlatban felmerülő problémák jelentős részét. A következő előadások során megvizsgáljuk, hogy mikor érdemes használni ezeket az eszközöket, valamint az alapul szolgáló szolgáltatások és alkalmazások keretrendszerét, amelyekre vonatkoznak.

A FirstVDS rendszergazdája, Kirill Tsvetkov veled volt.

Forrás: will.com

Kezdő rendszergazdának: hogyan teremtsünk rendet a káoszból