Jsem správce systému FirstVDS a toto je text první úvodní přednášky z mého krátkého kurzu o pomoci začínajícím kolegům. Specialisté, kteří se nedávno začali zabývat správou systému, čelí řadě stejných problémů. Abych nabídl řešení, zavázal jsem se napsat tuto sérii přednášek. Některé věci v něm jsou specifické pro hostování technické podpory, ale obecně mohou být užitečné, když ne pro každého, tak pro mnohé. Upravil jsem tedy text přednášky, abych je zde mohl sdílet.
Nezáleží na tom, jak se vaše pozice jmenuje – důležité je, že se ve skutečnosti podílíte na správě. Začněme proto tím, co by měl správce systému dělat. Jeho hlavním úkolem je dát věci do pořádku, udržovat pořádek a připravit se na budoucí nárůst pořádku. Bez správce systému se server stává nepořádkem. Logy se nepíší, nebo se v nich píšou špatné věci, zdroje nejsou optimálně rozmístěny, disk je zaplněný všelijakým odpadem a systém začíná pomalu umírat tolika chaosem. Klidně! Správci systému ve vaší osobě začínají řešit problémy a odstraňovat nepořádek!
Pilíře správy systému
Než se však pustíte do řešení problémů, vyplatí se seznámit se se čtyřmi hlavními pilíři administrativy:
- Dokumentace
- Šablony
- Optimalizace
- Automatizace
To je základ. Pokud svůj workflow nepostavíte na těchto principech, bude neefektivní, neproduktivní a obecně se jen málo podobá skutečné administrativě. Podívejme se na každou zvlášť.
Документация
Документация neznamená číst dokumentaci (i když se bez ní neobejdete), ale také ji udržovat.
Jak uchovávat dokumentaci:
- Narazili jste na nový problém, který jste ještě neviděli? Zapište hlavní příznaky, metody diagnostiky a zásady eliminace.
- Přišli jste na nové, elegantní řešení běžného problému? Zapište si to, abyste to za měsíc nemuseli znovu vymýšlet.
- Pomohli vám zjistit otázku, které jste nerozuměli? Zapište si hlavní body a pojmy, nakreslete si schéma.
Hlavní myšlenka: při osvojování a aplikaci nových věcí byste neměli zcela důvěřovat vlastní paměti.
V jakém formátu to uděláte, je na vás: může to být systém s poznámkami, osobní blog, textový soubor, fyzický poznámkový blok. Hlavní věc je, že vaše záznamy splňují následující požadavky:
- Nebuď moc dlouhý. Zdůrazněte hlavní myšlenky, metody a nástroje. Pokud pochopení problému vyžaduje ponořit se do nízkoúrovňové mechaniky alokace paměti v Linuxu, nepřepisujte článek, ze kterého jste se to naučili – uveďte na něj odkaz.
- Záznamy by vám měly být jasné. Pokud linka
race cond.lockupneumožňuje okamžitě pochopit, co jste tímto řádkem popsal - vysvětlete. Pochopení dobré dokumentace nezabere půl hodiny. - Vyhledávání je velmi dobrá funkce. Pokud píšete blogové příspěvky, přidejte štítky; pokud ve fyzickém sešitě, nalepte malé post-it s popisy. Dokumentace nemá smysl, pokud v ní strávíte hledáním odpovědi tolik času, kolik byste strávili řešením otázky od začátku.
I takto může vypadat dokumentace: od primitivních poznámek v poznámkovém bloku (obrázek výše), až po plnohodnotnou víceuživatelskou znalostní bázi s tagy, vyhledáváním a všemi možnými vymoženostmi (níže).
Nejen, že nebudete muset hledat stejné odpovědi dvakrát, ale dokumentování bude skvělým pomocníkem při učení se nových témat (poznámky!), zlepší váš pavoučí smysl (schopnost diagnostikovat složitý problém jedním povrchním pohledem), a přidá organizaci do vašich akcí. Pokud je dokumentace k dispozici vašim kolegům, umožní jim zjistit, co a jak jste tam naskládali, když tam nejste.
Šablony
Šablony je tvorba a používání šablon. Pro vyřešení většiny typických problémů se vyplatí vytvořit konkrétní šablonu akce. Pro diagnostiku většiny problémů by měla být použita standardizovaná sekvence kroků. Když jste něco opravili/nainstalovali/optimalizovali, měl by být výkon tohoto něčeho zkontrolován pomocí standardizovaných kontrolních seznamů.
Šablony jsou nejlepším způsobem, jak uspořádat pracovní postup. Použitím standardních postupů k řešení nejběžnějších problémů získáte spoustu skvělých věcí. Například používání kontrolních seznamů vám umožní diagnostikovat všechny funkce, které jsou důležité pro vaši práci, a zahodit diagnostiku nedůležitých funkcí. A standardizované postupy minimalizují zbytečné házení a snižují pravděpodobnost chyby.
Prvním důležitým bodem je, že postupy a kontrolní seznamy musí být také zdokumentovány. Pokud se spoléháte pouze na paměť, můžete promeškat nějakou opravdu důležitou kontrolu nebo operaci a vše zničit. Druhým důležitým bodem je, že všechny šablonovací postupy mohou a měly by být upraveny, pokud to situace vyžaduje. Ideální a absolutně univerzální šablony neexistují. Pokud existuje problém, ale kontrola šablony jej neodhalila, neznamená to, že problém neexistuje. Než však začnete testovat některé nepravděpodobné hypotetické problémy, vždy se vyplatí nejprve provést rychlý test šablony.
Optimalizace
Optimalizace mluví sama za sebe. Pracovní proces je potřeba co nejvíce optimalizovat z hlediska času a mzdových nákladů. Možností je nespočet: naučit se klávesové zkratky, zkratky, regulární výrazy, dostupné nástroje. Hledejte praktičtější využití těchto nástrojů. Pokud voláte příkaz 100krát denně, přiřaďte jej klávesové zkratce. Pokud se potřebujete pravidelně připojovat ke stejným serverům, napište alias jedním slovem, který vás tam spojí:
Seznamte se s různými možnostmi nástrojů – možná existuje pohodlnější terminálový klient, DE, správce schránky, prohlížeč, e-mailový klient, operační systém. Zjistěte, jaké nástroje používají vaši kolegové a přátelé – možná si je vybírají z nějakého důvodu. Jakmile budete mít nástroje, naučte se je používat: naučte se klíče, zkratky, tipy a triky.
Optimálně využívat standardní nástroje – coreutils, vim, regulární výrazy, bash. Na poslední tři existuje obrovské množství nádherných manuálů a dokumentace. S jejich pomocí můžete rychle přejít ze stavu „Cítím se jako opice, která louská ořechy s notebookem“ do „Jsem opice, která si pomocí notebooku objednává louskáč ořechů“.
Automatizace
Automatizace přenese náročné operace z našich unavených rukou do neúnavných rukou automatizace. Pokud se nějaký standardní postup provádí v pěti příkazech stejného typu, tak proč nezabalit všechny tyto příkazy do jednoho souboru a nezavolat jeden příkaz, který tento soubor stáhne a provede?
Samotná automatizace je z 80 % psaní a optimalizace vašich vlastních nástrojů (a dalších 20 % se snaží, aby fungovaly tak, jak mají). Může to být jen pokročilý one-liner nebo obrovský všemocný nástroj s webovým rozhraním a API. Hlavním kritériem zde je, že vytvoření nástroje by nemělo zabrat více času a úsilí, než kolik času a úsilí vám nástroj ušetří. Pokud strávíte pět hodin psaním skriptu, který už nikdy nebudete potřebovat, u úkolu, jehož řešení by vám bez skriptu zabralo hodinu nebo dvě, je to velmi špatná optimalizace pracovního postupu. Pět hodin vytvářením nástroje můžete strávit pouze v případě, že to počet, typ úkolů a čas dovolí, což se často nestává.
Automatizace nemusí nutně znamenat psaní plnohodnotných skriptů. Chcete-li například vytvořit hromadu objektů stejného typu ze seznamu, potřebujete pouze chytrou jednolinku, která automaticky udělá to, co byste dělali ručně, přepínáním mezi okny, s hromadou copy-paste.
Ve skutečnosti, pokud postavíte administrativní proces na těchto čtyřech pilířích, můžete rychle zvýšit svou efektivitu, produktivitu a kvalifikaci. Tento seznam je však potřeba doplnit ještě o jednu položku, bez které se práce v IT téměř neobejde – sebevzdělávání.
Sebevzdělávání správce systému
Abyste byli v této oblasti alespoň trochu kompetentní, musíte neustále studovat a učit se nové věci. Pokud nemáte sebemenší chuť postavit se neznámému čelem a přijít na to, velmi rychle se zaseknete. V IT se neustále objevují nejrůznější nová řešení, technologie a metody, a pokud je alespoň povrchně neprostudujete, jste na cestě k neúspěchu. Mnoho oblastí informačních technologií stojí na velmi složitém a objemném základě. Například provoz sítě. Sítě a internet jsou všude, potkáváte je každý den, ale jakmile zabrousíte do technologie, která za nimi stojí, objevíte obrovskou a velmi komplexní disciplínu, jejíž studium nikdy není procházkou růžovým sadem.
Tuto položku jsem do seznamu nezařadil, protože je klíčová pro IT obecně, nejen pro správu systému. Přirozeně se nebudete moci naučit úplně všechno hned – prostě nemáte fyzicky dost času. Proto byste při sebevzdělávání měli pamatovat na potřebné úrovně abstrakce.
Nemusíte se hned učit, jak funguje správa vnitřní paměti každého jednotlivého nástroje a jak spolupracuje se správou paměti Linuxu, ale je dobré vědět, co je to RAM schematicky a proč je potřeba. Nemusíte vědět, jak se hlavičky TCP a UDP strukturálně liší, ale bylo by dobré porozumět základním rozdílům v tom, jak protokoly fungují. Nemusíte se učit, co je útlum signálu v optice, ale bylo by fajn vědět, proč se skutečné ztráty vždy dědí napříč uzly. Není nic špatného vědět, jak fungují určité prvky na určité úrovni abstrakce a neporozumět nutně všem úrovním, když abstrakce vůbec neexistuje (prostě se z toho zblázníte).
Ve vašem oboru však myšlení na úrovni abstrakce „no, to je věc, která vám umožňuje zobrazovat webové stránky“, není příliš dobré. Následující přednášky budou věnovány přehledu hlavních oblastí, kterými se musí správce systému zabývat při práci na nižších úrovních abstrakce. Pokusím se omezit množství recenzovaných znalostí na minimální úroveň abstrakce.
10 přikázání správy systému
Takže jsme se naučili čtyři hlavní pilíře a základy. Můžeme začít řešit problémy? Ještě ne. Před tím je vhodné seznámit se s tzv. „best practices“ a pravidly slušného chování. Bez nich pravděpodobně naděláte více škody než užitku. Takže začněme:
- Někteří z mých kolegů věří, že úplně prvním pravidlem je „neškodit“. Ale přikláním se k nesouhlasu. Když se snažíte neublížit, nemůžete nic dělat – příliš mnoho akcí je potenciálně destruktivních. Myslím, že nejdůležitější pravidlo je - "vytvořit zálohu". I když způsobíte nějaké poškození, vždy se můžete vrátit a všechno nebude tak špatné.
Vždy byste měli zálohovat, když to čas a místo dovolí. Musíte zálohovat to, co změníte a co riskujete ztrátu kvůli potenciálně destruktivní akci. Je vhodné zkontrolovat integritu zálohy a přítomnost všech potřebných dat. Záloha by se neměla smazat ihned poté, co vše zkontrolujete, pokud nepotřebujete uvolnit místo na disku. Pokud to umístění vyžaduje, zálohujte jej na svůj osobní server a po týdnu jej smažte.
- Druhé nejdůležitější pravidlo (které sám často porušuji) je "neschovávej se". Pokud jste si udělali zálohu, napište kde, ať ji kolegové nemusí hledat. Pokud jste provedli nějaké nesrozumitelné nebo složité akce, zapište si to: půjdete domů a problém se může opakovat nebo se může objevit u někoho jiného a vaše řešení bude nalezeno pomocí klíčových slov. I když děláte něco, co dobře znáte, vaši kolegové nemusí.
- Třetí pravidlo není třeba vysvětlovat: "nikdy nedělej něco, o čem nevíš, nepředstavuješ si to nebo čemu nerozumíš". Nekopírujte příkazy z internetu, pokud nevíte, co dělají, zavolejte člověku a nejprve je analyzujte. Nepoužívejte hotová řešení, pokud nerozumíte tomu, co dělají. Omezte provádění zmateného kódu na absolutní minimum. Pokud nemáte čas na to přijít, pak děláte něco špatně a měli byste si přečíst další bod.
- "Test". Nové skripty, nástroje, jednoduché řádky a příkazy by měly být testovány v kontrolovaném prostředí, nikoli na klientském počítači, pokud existuje byť jen minimální potenciál pro destruktivní akce. I když jste vše zálohovali (a to jste udělali), prostoje nejsou nejúžasnější věcí. Vytvořte pro to samostatný server/virtuální/chroot a otestujte tam. Je něco zlomené? Poté jej můžete spustit v „boji“.
- "Řízení". Minimalizujte všechny operace, které nemáte pod kontrolou. Jedna křivka závislosti balíčku může stáhnout polovinu systému a příznak -y nastavený pro yum remove vám dává příležitost procvičit si své schopnosti obnovy systému od nuly. Pokud akce nemá žádné nekontrolované alternativy, dalším bodem je připravená záloha.
- "Šek". Zkontrolujte důsledky svých akcí a zda se potřebujete vrátit zpět k zálohě. Zkontrolujte, zda byl problém skutečně vyřešen. Zkontrolujte, zda se chyba reprodukuje a za jakých podmínek. Zkontrolujte, co můžete svými činy zlomit. Je zbytečné naší práci důvěřovat, ale nikdy nekontrolovat.
- "Komunikovat". Pokud nemůžete problém vyřešit, zeptejte se svých kolegů, zda se s tím setkali. Pokud chcete uplatnit kontroverzní rozhodnutí, zjistěte si názor svých kolegů. Možná nabídnou lepší řešení. Pokud si nejste jisti svými činy, proberte je se svými kolegy. I když se jedná o oblast vaší odbornosti, nový pohled na situaci může mnohé objasnit. Nestyďte se za vlastní nevědomost. Je lepší položit hloupou otázku, vypadat jako blázen a dostat odpověď, než se zeptat, nedostat odpověď a skončit jako blázen.
- „Neodmítejte pomoc bezdůvodně“. Tento bod je opakem předchozího. Pokud dostanete hloupou otázku, objasněte a vysvětlete. Žádají nemožné – vysvětlujte, že je to nemožné a proč, nabídněte alternativy. Pokud nemáte čas (opravdu nemáte čas, ne touhu) - řekněte, že máte naléhavou otázku, hodně práce, ale vyřešíte to později. Pokud kolegové nemají naléhavé úkoly, nabídněte jim, že je kontaktujete a delegujte otázku.
- "Dát zpětnou vazbu". Začal někdo z vašich kolegů používat novou techniku nebo nový scénář a setkáváte se s negativními důsledky tohoto rozhodnutí? Nahlásit to. Možná lze problém vyřešit ve třech řádcích kódu nebo pěti minutách zdokonalování techniky. Narazili jste na chybu ve svém softwaru? Nahlásit chybu. Pokud je reprodukovatelný nebo není třeba reprodukovat, bude s největší pravděpodobností opraven. Vyslovte svá přání, návrhy a konstruktivní kritiku, a pokud se zdají být relevantní, předkládejte otázky k diskusi.
- "Požádat o zpětnou vazbu". Všichni jsme nedokonalí, stejně jako naše rozhodnutí, a nejlepší způsob, jak otestovat správnost svého rozhodnutí, je předložit jej k diskusi. Pokud jste něco optimalizovali pro klienta, požádejte ho, aby sledoval práci; možná úzké hrdlo v systému není tam, kde jste hledali. Napsali jste skript nápovědy – ukažte jej svým kolegům, možná najdou způsob, jak jej vylepšit.
Budete-li tyto praktiky ve své práci neustále uplatňovat, většina problémů přestane být problémy: nejenom snížíte počet vlastních chyb a záměn na minimum, ale budete mít také možnost chyby opravit (v forma záloh a kolegové, kteří vám poradí zálohovat). Dále - pouze technické detaily, ve kterých se, jak víme, skrývá čert.
Hlavní nástroje, se kterými budete muset pracovat více než 50 % času, jsou grep a vim. Co by mohlo být jednodušší? Vyhledávání a úpravy textu. Jak grep, tak vim jsou však výkonné multi-nástroje, které vám umožní efektivně vyhledávat a upravovat text. Pokud vám některý poznámkový blok Windows umožňuje jednoduše napsat/smazat řádek, pak ve vimu můžete s textem dělat téměř cokoliv. Pokud mi nevěříte, zavolejte z terminálu příkaz vimtutor a začněte se učit. Pokud jde o grep, jeho hlavní síla je v regulárních výrazech. Ano, samotný nástroj umožňuje poměrně flexibilně nastavovat podmínky vyhledávání a vydávat data, ale bez RegExp to nedává moc smysl. A musíte znát regulární výrazy! Alespoň na základní úrovni. Pro začátek bych vám doporučil podívat se na toto , pokrývá základy regulárních výrazů a jejich použití ve spojení s grep. Ach ano, když je zkombinujete s vim, získáte ULTIMATE POWER schopnost dělat věci s textem, které musíte označit 18+ ikonami.
Ze zbývajících 50 % pochází 40 % ze sady nástrojů coreutils. Pro coreutils se můžete podívat na seznam na a manuál k celému seznamu je na webu . Co není zahrnuto v této sadě, je ve službách . Nemusíte se všechny klávesy učit nazpaměť, ale je užitečné alespoň zhruba vědět, co základní nástroje umí. Nemusíte znovu vynalézat kolo z berliček. Nějak jsem potřeboval nahradit zalomení řádků mezerami ve výstupu z nějaké utility a můj nemocný mozek zrodil konstrukci jako sed ':a;N;$!ba;s/n/ /g', přišel kolega a odvezl mě od konzole koštětem a problém pak vyřešil psaním tr 'n' ' '.
Doporučil bych vám pamatovat si, co každý jednotlivý nástroj dělá a klávesy k nejčastěji používaným příkazům, na všechno ostatní je člověk. Neváhejte a zavolejte muži, pokud máte nějaké pochybnosti. A určitě si přečtěte i samotného muže – obsahuje důležité informace o tom, co najdete.
Se znalostí těchto nástrojů budete schopni efektivně řešit významnou část problémů, se kterými se v praxi setkáte. V následujících přednáškách se podíváme na to, kdy tyto nástroje použít, a na frameworky pro základní služby a aplikace, na které se vztahují.
Byl s vámi správce systému FirstVDS Kirill Tsvetkov.
Zdroj: www.habr.com