Kezdő rendszergazdáknak: hogyan teremtsenek rendet a káoszból

Én a FirstVDS-nél dolgozó rendszergazda vagyok, és ez az első bevezető előadás szövege a kezdő kollégáknak szánt rövid kurzusomból. Azok a szakemberek, akik nemrég kezdtek el rendszergazdálkodással foglalkozni, számos azonos problémával találkoznak. A megoldások javaslása érdekében úgy döntöttem, hogy írok egy előadás-sorozatot. Néhány dolog specifikus a hoszting műszaki támogatásához, de összességében hasznos lehet, ha nem mindenki számára, akkor sokaknak. Ezért adaptáltam az előadás szövegét, hogy itt megosszam.

Nem számít, mi a pozíciód neve – a lényeg, hogy valójában rendszergazdálkodással foglalkozol. Tehát kezdjük azzal, mivel is foglalkozik a rendszergazda. A fő feladata a rend fenntartása, a káosz tisztítása és a jövőbeni rendnövelése. Rendszergazda nélkül a szerveren káosz kezdődik. A naplók nem íródnak, vagy nem azok íródnak, amiknek kellene, az erőforrások nem optimálisan oszlanak meg, a lemez tele van mindenféle szeméttel, és a rendszer elkezd lassan összeomlani a káosz mennyisége miatt. Nyugalom! A rendszergazdák az önök személyében megkezdik a problémák megoldását és a zűrzavar rendezését!

A rendszergazdálkodás pillérei

De mielőtt a problémák megoldásába kezdenénk, érdemes megismerkedni a négy alapvető pillérral:

1. Dokumentáció
2. Sablonozás
3. Optimalizálás
4. Automatizálás

Ez az alapok alapja. Ha nem ezen elvek mentén építjük fel a munkafolyamatunkat, az hatástalan, terméketlen és egyáltalán nem hasonlít a valódi rendszergazdálkodásra. Nézzük meg mindegyiket külön-külön.

kódkönyvtárra lépésével érheti el.

kódkönyvtárra lépésével érheti el. nem csupán a dokumentáció olvasását jelenti (bár ez elengedhetetlen), hanem annak vezetését is.

Hogyan vezessük a dokumentációt:

• Új problémával találkoztál, amit korábban sosem láttál? Írd le a főbb tüneteket, a diagnosztikai módszereket és a megoldási elveket.
• Kitaláltál egy új, elegáns megoldást egy tipikus problémára? Írd le, hogy ne kelljen újra feltalálnod egy hónap múlva.
• Segítettek megérteni egy olyan kérdést, amiben semmit nem tudtál? Írd le a főbb téziseket és fogalmakat, rajzolj magadnak egy diagramot.

A fő gondolat: nem érdemes teljesen megbízni a saját memóriádban, amikor új dolgokat tanulsz és alkalmazol.

A formátum, ahogy ezt meg fogja tenni, csak öntől függ: lehet ez egy jegyzetelő rendszer, személyes blog, szöveges fájl vagy fizikai jegyzetfüzet. A legfontosabb, hogy a feljegyzései megfeleljenek a következő követelményeknek:

1. Ne legyenek túl hosszúak. Az alapvető ötleteket, módszereket és eszközöket emelje ki. Ha a probléma megértéséhez szükséges belemerülni a memóriaallokálás alacsony szintű mechanikájába Linuxon, ne írja újra azt a cikket, ahonnan megtudta — hivatkozzon rá.
2. A feljegyzéseknek érthetőeknek kell lenniük az ön számára. Ha a sor race cond.lockup nem engedi megérteni, hogy mit írt le, akkor magyarázza el. A jó dokumentációban nem kell fél órát tölteni a megértéssel.
3. A keresés – nagyon jó funkció. Ha blogot ír, adjon hozzá címkéket; ha fizikai jegyzetfüzetbe ír, ragassza fel a kis post-it cetliket leírásokkal. Nincs különösebb értelme a dokumentációnak, ha annyi időt tölt a választ keresgéléssel, mint amennyit a kérdés nulláról való megoldásával.

Így nézhet ki a dokumentáció: az egyszerű jegyzetektől a többfelhasználós tudásbázisokig címkékkel, kereséssel és minden lehetséges kényelemmel.

Nemcsak az lesz, hogy nem kell ugyanazokat a válaszokat kétszer keresnie: a dokumentálás csodálatos segítséget nyújt az új témák tanulmányozásában (hiszen ezek jegyzetek!), fejleszti az érzékét (a bonyolult problémák diagnosztizálásának képessége egy felszínes pillantással), és rendet teremt a cselekedeteiben. Ha a dokumentáció elérhető a kollégái számára, segíti őket abban, hogy megértsék, mit és hogyan csinált, amikor Ön nem lesz jelen.

A sablonosítás

A sablonosítás az sablonok létrehozása és használata. A legtöbb tipikus kérdés esetén érdemes elkészíteni egy adott cselekvési tervet. A legtöbb probléma diagnosztizálásához egy szabványos cselekvési sorrendet kell alkalmazni. Amikor valamit megjavított, telepített vagy optimalizált, annak működését érdemes a szabványos ellenőrzőlisták alapján ellenőrizni.

A sablonosítás a munkafolyamatok szervezésének legjobb módja. Ha standard eljárásokat használ a leggyakoribb problémák megoldására, rengeteg nagyszerű dolgot kaphat. Például a ellenőrzőlisták használata lehetővé teszi az összes fontos funkció diagnosztizálását, míg a jelentéktelen funkcionális diagnosztikai tünetek kiszűrését. A standardizált eljárások minimalizálják a szükségtelen tépelődéseket és csökkentik a hibák valószínűségét.

Az első fontos tényező, hogy az eljárásokat és a ellenőrzőlistákat is dokumentálni kell. Ha csak a memóriára hagyatkozik, kihagyhat egy fontos ellenőrzést vagy műveletet, ami mindent tönkretehet. A második fontos tényező — hogy minden sablonos gyakorlatot módosítani kell, ha a helyzet ezt megköveteli. Nincsenek tökéletes és minden körülmények között alkalmazható sablonok. Ha probléma merül fel, és a sablonos ellenőrzés nem fedezte fel azt — ez nem jelenti azt, hogy nincs probléma. Mielőtt hipotetikus, valószínűtlen problémák ellenőrzésébe kezdene, mindig érdemes először egy gyors sablonos ellenőrzést végezni.

Optimalizálás

Optimalizálás beszél magáért. A munkafolyamatot maximálisan optimalizálni kell idő- és munkaköltség szempontjából. Számtalan lehetőség van: tanulja meg a billentyűparancsokat, a rövidítéseket, a reguláris kifejezéseket, elérhető eszközöket. Keressen lehetőségeket ezek praktikusabb használatára. Ha naponta 100-szor hívja meg a parancsot, rendeljen hozzá egy billentyűkombinációt. Ha rendszeresen ugyanazokhoz a szerverekhez kell csatlakoznia, jegyezzen fel egy alias-t egy szóban, ami oda csatlakoztatja:

Ismerkedjen meg a rendelkezésre álló eszközök különféle lehetőségeivel — lehet, hogy van kényelmesebb terminálkliense, DE-je, vágólap-kezelője, böngészője, levelezője, operációs rendszere. Tudja meg, hogy kollégái és ismerősei milyen eszközöket használnak — lehet, hogy nem véletlenül választják azokat. Miután kiválasztotta az eszközöket, tanulja meg azokat alkalmazni: tanulja meg a billentyűparancsokat, a rövidítéseket, a tippeket és trükköket.

Használja optimálisan a standard eszközöket — coreutils, vim, reguláris kifejezések, bash. Az utolsó háromhoz rengeteg csodálatos kézikönyv és dokumentáció létezik. Ezek segítségével viszonylag gyorsan eljuthatunk a „mint egy majom, aki a laptopjával tör diót” állapotból a „mint egy majom, aki laptopot használ, hogy diótörőt rendeljen” szintre.

Automatizálás

Automatizálás átviszi a nehéz műveleteket fáradt kezeinkből a fáradhatatlan automatizálás kezeibe. Ha egy standard eljárás öt azonos parancsból áll, miért ne csomagolnánk ezeket a parancsokat egy fájlba, és ne hívnánk meg egyetlen parancsot, amely ezt a fájlt letölti és végrehajtja?

Az automatizálás 80%-a valójában saját eszközök írásából és optimalizálásából áll (és még 20%-a abból, hogy megpróbáljuk őket a megfelelő módon működtetni). Ez lehet egy egyszerű fejlett egysoros parancs vagy egy hatalmas, mindenható eszköz webböngészővel és API-val. A fő szempont az, hogy az eszköz létrehozása nem foglalhat el több időt és energiát, mint amennyit az eszköz megtakarít nekünk. Ha öt órát ír egy szkripten, amely soha többé nem fog kelleni, azért a feladatért, amelynek megoldása egy-két órát venne igénybe szkript nélkül — akkor ez nagyon rossz munkafolyamat-optimalizáció. Öt órát csak az eszköz létrehozására lehet fordítani, ha a feladatok mennyisége, típusa és ideje ezt lehetővé teszi, ami nem gyakori.

Az automatizálás nem feltétlenül jelenti teljes értékű szkriptek írását. Például, ha egy listából sok hasonló objektumot szeretnénk létrehozni, elegendő egy ügyes egysoros parancs, amely automatikusan elvégzi azt, amit kézzel csinálna, az ablakok váltogatásával, sok másolás-beillesztéssel.

Ha valóban ezekre a négy pillérre építjük az adminisztrációs folyamatot, meglehetősen gyorsan növelhetjük a hatékonyságunkat, termelékenységünket és képzettségünket. Azonban ezt a listát ki kell egészíteni egy további ponttal, amely nélkül az IT területen a munka gyakorlatilag lehetetlen — a önképzéssel.

A rendszergazda önképzése

Ahhoz, hogy egy kicsit is kompetensek legyünk ebben a területen, folyamatosan tanulni és újat felfedezni kell. Ha nincs minimális hajlandósága szembenézni a bizonytalansággal és megérteni azt, nagyon gyorsan "le fog csúszni". Az IT területén folyamatosan új megoldások, technológiák és módszerek jelennek meg, és ha ezeket nem tanulmányozza legalább felszínesen — akkor a veszteség felé halad. Számos informatikai terület nagyon komplex és átfogó alapokra épül. Például a hálózatok működése. A hálózatok és az internet mindenhol jelen vannak, nap mint nap találkozunk velük, de ha mélyebben megvizsgálja az önálló technológiákat, egy hatalmas és nagyon bonyolult tudományágra bukkant, amelynek tanulmányozása — nem egyszerű séta a parkban.

Ezt a pontot nem szerettem volna beletenni a listába, mert ez az IT egészére nézve kulcsfontosságú, nemcsak a rendszeradminisztrációra vonatkozik. Nyilvánvaló, hogy mindent és azonnal megtanulni lehetetlen — fizikailag nem lesz elegendő ideje. Ezért az önképzés során fontos figyelembe venni a szükséges absztrakciós szinteket.

Nem szükséges azonnal megtanulnia, hogyan működik a memória menedzsment minden egyes alkalmazásnál, és hogyan interakcióba lép a Linux memória menedzsmentjével, de nem árt tudni, hogy a RAM mit jelent ábrázolt formában és hogy mire van szükség. Nem kell tudni, hogy a TCP és az UDP fejléc struktúrája miben tér el, de nem árt megérteni a protokollok működésében lévő alapvető különbségeket. Nem szükséges tanulmányozni, mi jelenti a jelcsillapítást az optikában, de jó lenne tudni, hogy a valódi veszteségek mindig a csomópontokon öröklődnek. Nincs semmi rossz abban, ha tudja, hogy bizonyos elemek hogyan működnek egy adott absztrakciós szinten, és nem szükséges mindent megérteni, amikor az absztrakció teljesen hiányzik (egyszerűen megőrülne).

Azonban a saját területén az "ez egy olyan dolog, amely lehetővé teszi a weboldalak megjelenítését" absztrakciós szinten való érvelés — nem túl bölcs dolog. A következő előadások a rendszeradminisztrátor munkájával járó alapvető területek áttekintésére összpontosítanak, alacsonyabb absztrakciós szinten. Igyekszem minimalizálni az áttekintett tudás absztrakciós szintjét.

A rendszeradminisztrálás 10 parancsolata

Tehát, megértettük a négy alapvető pillért és alapot. Lehet kezdeni a problémák megoldását? Még nem. Előtte érdemes megismerkedni a „legjobb gyakorlatokkal” és a jó modor szabályaival. Ezek nélkül nagyobb kárt okozhat, mint hasznot. Tehát, kezdjük:

1. Néhány kollégám szerint az első szabály - „ne árts”. De én nem értek ezzel egyet. Amikor próbálsz nem árni, akkor igazából nem tudsz semmit sem tenni - túl sok cselekedet potenciálisan destruktív. A legfontosabb szabály szerintem - „készíts biztonsági másolatot”. Még ha árthat is, mindig lehet visszatérni, és a helyzet már nem lesz annyira súlyos.

   Mindig biztonsági másolatot kell készíteni, amikor az idő és a hely lehetővé teszi. Olyan dolgokat kell menteni, amelyeket megváltoztatsz és azt, amit potenciálisan elveszíthetsz egy destruktív művelet során. A biztonsági másolatot érdemes ellenőrizni a teljesség és az összes szükséges adat meglétére. A biztonsági másolatot nem érdemes azonnal törölni, miután mindent ellenőriztél, ha nem szükséges helyet felszabadítani a lemezen. Ha helyet kell felszabadítani - készíts biztonsági másolatot a saját szerveredre és töröld egy hét múlva.

2. A második legfontosabb szabály (amit én gyakran megszegnék) - „ne rejtsd el”. Ha készítettél biztonsági másolatot, írd le — hová, hogy a kollégáidnak ne kelljen keresniük. Ha valamilyen nem egyértelmű vagy bonyolult lépéseket tettél, írd le: hazamész, a probléma pedig megismétlődhet, vagy valaki másnál is felmerülhet, és a megoldásodat kulcsszavak alapján találják majd meg. Még ha valami olyat is csinálsz, amit jól ismersz, a kollégáid ezt nem biztos, hogy tudják.
3. A harmadik szabályt nem kell magyarázni: „soha ne csinálj olyat, aminek a következményeit nem ismered, nem képzeled el vagy nem érted”. Ne másolj parancsokat az internetről, ha nem tudod, hogy mit csinálnak, keresd meg a man-t és először olvasd el. Ne alkalmazz kész megoldásokat, ha nem tudod megérteni, hogy mit csinálnak. Minimalizáld az obfuszkált kód futtatását. Ha nincs időd a megértésre - akkor valószínűleg valamit rosszul csinálsz, és érdemes megismerkedned a következő ponttal.
4. „Tesztelj”. Az új szkripteket, eszközöket, egysoros parancsokat és parancsokat mindig ellenőrizni kell egy kontrollált környezetben, nem pedig az ügyfélszámítógépen, ha ott legalább minimális potenciál van a destruktív tevékenységekre. Még ha mindent le is mentettél (azt megtetted), a leállás nem a legjobb dolog. Indíts egy külön szervert/virtuális gépet/chroot-ot, és tesztelj ott. Semmi sem romlott el? Akkor lehet futtatni a „termelésiben”.

   
   

5. „Kontrollálj”. Minimalizáld az összes olyan műveletet, amit nem te irányítasz. Egy helytelen függőség egy csomagban fél rendszert magával ránt. A yum remove zászló -y pedig lehetőséget biztosít arra, hogy gyakorold a rendszer helyreállítását nulláról. Ha a műveletnek nincsenek kontrollálatlan alternatívái — következő lépés és a kész biztonsági másolat.
6. „Ellenőrizz”. Ellenőrizd a cselekedeteid következményeit, és hogy szükséges-e visszaállni a biztonsági másolatra. Ellenőrizd, valóban megoldódott-e a probléma. Ellenőrizd, hogy reprodukálható-e a hiba és milyen körülmények között. Ellenőrizd, mit tudsz tönkretenni a cselekedeteiddel. A bizalom a munkánkban felesleges, de az ellenőrzés sosem az.
7. „Kommunikálj”. Ha nem sikerül megoldanod a problémát, kérdezd meg a kollégáidat, hogy találkoztak-e hasonlóval. Ha vitás megoldást szeretnél alkalmazni — kérdezd meg a kollégák véleményét. Lehet, hogy jobb megoldást javasolnak. Ha nem vagy biztos a tetteidben — beszéld meg őket a kollégáiddal. Még ha ez a te szakterületed is, egy friss nézőpont sokat világosíthat a helyzeten. Ne félj a tudatlanságodtól. Jobb egy hülye kérdést feltenni, bolondnak tűnni és választ kapni rá, mint nem feltenni a kérdést, nem kapni választ és bolondnak maradni.
8. „Ne utasíts el segítséget indokolatlanul”. Ez a pont az előző ellentéte. Ha hülye kérdést tettek fel neked — világosítsd meg és magyarázd el. Ha lehetetlent kérnek — magyarázd el, hogy miért lehetetlen és javasolj alternatívákat. Ha nincs időd (valóban nincs időd, nem csak kedved) — mondd, hogy sürgős kérdésed van, nagy munkaterhet hordozol, de később foglalkozol vele. Ha a kollégáknak nincsenek sürgős feladataik, javasold, hogy forduljanak hozzájuk és delegáld a kérdést.
9. „Adj visszajelzést”. Valaki a kollégák közül új módszert vagy új szkriptet kezdett alkalmazni, és Ön a döntés negatív következményeivel szembesül? Jelezze ezt. Lehetséges, hogy a probléma három sor kódban vagy öt perc finomításban megoldható. Rábukkant egy hibára a szoftverben? Jelentse a hibát. Ha reprodukálható, vagy nem szükséges reprodukálni, valószínűleg meg fogják javítani. Fogalmazza meg kívánságait, javaslatait és konstruktív kritikáját, hozza elő a kérdéseket a megbeszélésre, ha relevánsnak tűnnek.
10. „Kérj visszajelzést”. Mindannyian imperfekt az alap, ahogyan a döntéseink is, és a legjobb módja a döntéseink helyességének ellenőrzésére, ha megbeszéljük őket. Ha optimalizáltunk valamit egy ügyfélnél — kérjük, figyelje meg a működését, lehet, hogy a rendszer „palacknyaka” nem ott van, ahol kerestük. Írtunk egy segédszkriptet — mutassuk meg a kollégáknak, lehet, hogy találnak módot annak javítására.

Ha ezeket a gyakorlatokat folyamatosan alkalmazza a munkájában, a legtöbb probléma már nem lesz probléma: nemcsak a saját hibáit és balfogásait minimalizálja, hanem lesz lehetősége a hibák kijavítására (a biztonsági mentések és a kollégák segítsége által, akik azt tanácsolják, hogy készítsen biztonsági mentést). Tovább pedig csak technikai részletek, amelyekben, mint tudjuk, a részletekben rejlik aördög.

A legfontosabb eszközök, amelyekkel a munkaidőnek több mint 50%-ában dolgozni fog, a grep és a vim. Mi lehetne ennél egyszerűbb? Szövegkeresés és szöveg szerkesztés. Azonban a grep és a vim is rendkívül erőteljes, multifunkcionális eszközök, melyek lehetővé teszik a szöveg hatékony keresését és szerkesztését. Míg egy Windows-os notepad lehetővé teszi, hogy egyszerűen írjon/töröljön egy sort, a vim-ben majdnem mindent megtehet a szöveggel. Nem hiszi? Hívja a terminálból a vimtutor parancsot, és kezdje el tanulni. Ami a grep-et illeti — alapvető ereje a reguláris kifejezésekben rejlik. Igen, maga az eszköz eléggé rugalmasan képes meghatározni a keresési feltételeket és a kimeneti adatokat, de RegExp nélkül ez nem sok értelmet nyer. És a reguláris kifejezések tudása elengedhetetlen! Legalább az alap szinten. Kezdetnek azt javaslom, hogy nézze meg ezt. videón, ebben a reguláris kifejezések alapjait és alkalmazásukat tárgyaljuk a greppel. Ja, ha ezeket a vim-mel kombinálod, az ULTIMATIV HATALMAT ad arra, hogy a szöveggel olyan dolgokat csinálj, hogy 18+-os figyelmeztetéseket kell hozzáadni.

A fennmaradó 50%-ból 40% a coreutils eszközkészlethez tartozik. A coreutils listáját itt találhatod a Wikipédiában, míg a teljes lista útmutatója a weboldalon található GNU. Amit ez a készlet nem fed le, az a POSIXhasználati segédprogramokban található. Nem szükséges az összes kulcsszót fejből tudni, de jó, ha tudod, hogy az alapvető eszközök mit tudnak – hasznos. Nem kell saját kerékpárt feltalálni a bottal. Egyszer el akartam helyettesíteni a sorvégeket szóközökkel valamilyen segédprogram kimenetében, és a fájdalmas agyam szült egy, az alábbihoz hasonló konstrukciót sed ':a;N;$!ba;s/n/ /g', a megjelenő kolléga elzavart a konzoltól, majd megoldotta a feladatot, úgy hogy írta tr 'n' ' '.

Azt javaslom, hogy jegyezd meg, körülbelül mi a funkciója minden egyes eszköznek és a leggyakrabban használt parancsok kulcsait, minden máshoz ott a man. Ne habozz man-t hívni, ha valamiben bizonytalan vagy. És mindenképpen olvasd el a man-ról a man-t – fontos információkat tartalmaz arról, amit meg fogsz találni.

Ezeknek az eszközöknek a megismerésével hatékonyan meg tudod oldani a gyakorlatban előforduló feladatok jelentős részét. A következő előadásokban azt fogjuk megvizsgálni, mikor alkalmazzuk ezeket az eszközöket és az alapvető szolgáltatások valamint alkalmazások struktúráit, amelyekhez tartoznak.

Veled volt a FirstVDS rendszergazdája, Kirill Cvjetkov.

Forrás: habr.com