🥇Dla początkującego administratora systemu: jak z chaosu stworzyć porządek

Jestem administratorem systemów w FirstVDS i to jest tekst pierwszego wprowadzenia do mojego krótkiego kursu wsparcia dla początkujących kolegów. Specjaliści, którzy niedawno zaczęli zajmować się administracją systemami, stają przed szeregiem tych samych problemów. Aby zaproponować rozwiązania, postanowiłem napisać ten cykl wykładów. Niektóre rzeczy w nim są specyficzne dla wsparcia technicznego hostingu, ale ogólnie mogą okazać się przydatne, jeśli nie dla wszystkich, to dla wielu. Dlatego dostosowałem tekst wykładu, aby móc się nim podzielić tutaj.

Nie ma znaczenia, jak nazywa się twoje stanowisko — ważne, że de facto zajmujesz się administrowaniem. Dlatego zaczniemy od tego, czym powinien się zajmować administrator systemu. Jego głównym zadaniem jest uporządkowanie, utrzymanie porządku i przygotowanie na nadchodzące zwiększenia porządku. Bez administratora systemu na serwerze zaczyna się chaos. Logi nie są pisane, lub pisze się w nich coś innego, zasoby są przydzielane nieoptymalnie, dysk wypełnia się różnymi śmieciami, a system zaczyna powoli się „załamywać” od takiej ilości chaosu. Spokojnie! Administratorzy systemów w twojej osobie przystępują do rozwiązywania problemów i usuwania chaosu!

Filary administracji systemów

Jednak zanim przystąpimy do rozwiązywania problemów, warto zapoznać się z czterema głównymi filarami administracji:

Dokumentacją
Szablonowaniem
Optymalizacją
Automatyzacją

To podstawa podstaw. Jeśli nie budować swojego procesu pracy na tych zasadach, będzie on nieefektywny, nieproduktywny i w ogóle mało przypominający prawdziwą administrację. Przyjrzyjmy się każdemu z osobna.

Dokumentacja

Dokumentacja polega nie tylko na czytaniu dokumentacji (choć bez tego się nie obejdzie), ale także na jej prowadzeniu.

Jak prowadzić dokumentację:

Czy natrafiłeś na nowy problem, którego wcześniej nigdy nie widziałeś? Zapisz główne objawy, metody diagnozy i zasady eliminacji.
Czy wymyśliłeś nowe eleganckie rozwiązanie typowego problemu? Zapisz je, aby nie musieć wynajdywać go na nowo za miesiąc.
Czy ktoś pomógł ci zrozumieć jakąś kwestię, w której nic nie rozumiałeś? Zapisz główne tezy i koncepcje, narysuj sobie schemat.

Główna idea: nie warto całkowicie ufać własnej pamięci przy przyswajaniu i zastosowaniu nowego.

To, w jakim formacie to zrobisz, zależy tylko od Ciebie: może to być system notatek, osobisty blog, plik tekstowy lub fizyczny notatnik. Najważniejsze, aby Twoje zapisy spełniały następujące wymagania:

Nie być zbyt długie. Wyróżniaj główne pomysły, metody i środki. Jeśli zrozumienie problemu wymaga zgłębienia niskopoziomowej mechaniki działania pamięci w Linuxie, nie przepisuj artykułu, z którego to wiedziałeś — podaj do niego link.
Zapisy powinny być zrozumiałe dla Ciebie. Jeśli linijka race cond.lockup nie pozwala Ci od razu zrozumieć, co tą linijką opisałeś — wyjaśnij. W dobrej dokumentacji nie powinno się rozmyślać przez pół godziny.
Wyszukiwanie — to bardzo dobra funkcja. Jeśli prowadzisz notatki w blogu, dodawaj tagi; jeśli w fizycznym notatniku — przyklejaj małe karteczki post-it z opisami. Nie ma większego sensu w dokumentacji, jeśli na znalezienie w niej odpowiedzi wydajesz tyle czasu, ile poświęciłbyś na rozwiązanie problemu od zera.

Tak może wyglądać dokumentacja: od prymitywnych zapisków w notatniku (zdjęcie powyżej), po pełnoprawną wieloosobową bazę wiedzy z tagami, wyszukiwaniem i wszelkimi możliwymi udogodnieniami (poniżej).

Nie tylko nie będziesz musiał dwukrotnie szukać tych samych odpowiedzi: dokumentowanie będzie doskonałym wsparciem w nauce nowych tematów (notatki!), wzmocni Twoje wyczucie problemu (zdolność do diagnozowania skomplikowanego problemu, rzucając jedno powierzchowne spojrzenie), doda organizacji Twoim działaniom. Jeśli dokumentacja będzie dostępna dla Twoich współpracowników, pozwoli im zrozumieć, co i jak tam nakombinowałeś, gdy Ciebie nie będzie.

Szablonowanie

Szablonowanie — to tworzenie i wykorzystywanie szablonów. Dla większości typowych problemów warto stworzyć określony szablon działań. W przypadku diagnozowania większości problemów należy stosować ustandaryzowaną sekwencję działań. Gdy coś naprawisz/zainstalujesz/optymalizujesz, wydajność tego czegoś warto sprawdzić według ustandaryzowanych checklist.

Szablonowanie to najlepszy sposób organizacji pracy. Korzystając z typowych procedur do rozwiązywania najczęstszych problemów, zyskujesz wiele cennych rzeczy. Na przykład, zastosowanie checklist pozwoli ci zdiagnozować wszystkie kluczowe funkcje pracy i odrzucić diagnostykę mniej istotnych funkcji. A ustandaryzowane procedury zminimalizują zbędne komplikacje i zmniejszą prawdopodobieństwo błędów.

Pierwszym ważnym punktem jest to, że procedury i checklisty również należy dokumentować. Jeśli po prostu liczyć na pamięć, można pominąć jakąś naprawdę ważną kontrolę lub operację i wszystko się rozpadnie. Drugim ważnym punktem jest to, że wszystkie praktyki szablonowe można i należy modyfikować, jeśli sytuacja tego wymaga. Nie ma idealnych i absolutnie uniwersalnych szablonów. Jeśli problem występuje, a kontrola szablonowa go nie ujawnia — to nie znaczy, że problem nie istnieje. Jednak zanim przystąpisz do sprawdzania jakichkolwiek mało prawdopodobnych hipotez, zawsze warto najpierw przeprowadzić szybką kontrolę szablonową.

Optymalizacja

Optymalizacja mówi sama za siebie. Proces pracy należy maksymalnie zoptymalizować pod względem czasu i nakładów pracy. Opcji jest niezliczona ilość: naucz się skrótów klawiszowych, skrótów, wyrażeń regularnych, dostępnych narzędzi. Szukaj sposobów na bardziej praktyczne wykorzystanie tych narzędzi. Jeśli wywołujesz komendę 100 razy dziennie, przypisz ją do skrótu klawiszowego. Jeśli regularnie potrzebujesz łączyć się z tymi samymi serwerami, zapisz alias w jednym słowie, który cię tam połączy:

Zapoznaj się z różnymi dostępnymi narzędziami — być może istnieje bardziej wygodny klient terminala, DE, menedżer schowka, przeglądarka, klient pocztowy, system operacyjny. Dowiedz się, z jakich narzędzi korzystają twoi koledzy i znajomi — może wybierają je nie bez powodu. Po dobraniu narzędzi naucz się ich stosować: zapamiętaj klucze, skróty, wskazówki i triki.

Optymalnie wykorzystuj standardowe narzędzia — coreutils, vim, wyrażenia regularne, bash. Dla ostatnich trzech dostępnych jest ogromna liczba znakomitych podręczników i dokumentacji. Dzięki nim możesz dość szybko przejść od stanu „czuję się jak małpa, która tłucze orzechy laptopem” do „jestem małpą, która używa laptopa do zamówienia orzechotłuczek”.

Automatyzacja

Automatyzacja przeniesie ciężkie operacje z naszych zmęczonych rąk do niezmordowanych rąk automatyki. Jeśli jakaś standardowa procedura jest realizowana w pięciu jednorodnych komendach, to czemu nie owinąć tych wszystkich komend w jeden plik i nie wywołać jednej komendy, która ten plik pobiera i wykonuje?

Sama automatyzacja w 80% składa się z pisania i optymalizacji własnych narzędzi (i jeszcze na 20% z prób sprawienia, żeby działały tak, jak należy). Może to być po prostu zaawansowany jednoliniowy skrypt lub ogromne wszechpotężne narzędzie z interfejsem webowym i API. Głównym kryterium tutaj jest to, że stworzenie narzędzia nie powinno zajmować więcej czasu i wysiłku, niż ilość czasu i wysiłku, którą to narzędzie zaoszczędzi. Jeśli piszesz skrypt przez pięć godzin, który nigdy więcej nie będzie ci potrzebny, w celu rozwiązania zadania, którego bez skryptu mógłbyś załatwić w godzinę lub dwie — to bardzo zła optymalizacja procesu pracy. Można spędzić pięć godzin na stworzenie narzędzia tylko wtedy, gdy ilość, typ zadań i czas to umożliwiają, co zdarza się rzadko.

Automatyzacja niekoniecznie oznacza pisanie pełnoprawnych skryptów. Na przykład, aby stworzyć mnóstwo jednorodnych obiektów z listy, wystarczy zwinny jednoliniowy skrypt, który automatycznie zrobi to, co robiłbyś ręcznie, przełączając się między oknami, z masą kopiowania i wklejania.

Właściwie, jeśli zbudujesz proces administrowania na tych czterech filarach, możesz dość szybko zwiększyć swoją efektywność, produktywność i kwalifikacje. Jednak tę listę należy uzupełnić jeszcze jednym punktem, bez którego praca w IT jest praktycznie niemożliwa — samokształceniem.

Samokształcenie administratora systemów

Aby być w tej dziedzinie choć trochę kompetentnym, należy ciągle się uczyć i poznawać nowe rzeczy. Jeśli nie masz najmniejszej chęci, aby stawiać czoła nieznanemu i się w tym orientować, bardzo szybko "spadniesz". W IT wciąż pojawiają się różne nowe rozwiązania, technologie i metody, a jeśli nie uczysz się ich przynajmniej powierzchownie – jesteś na drodze do porażki. Wiele obszarów technologii informacyjnej opiera się na dość skomplikowanej i obszernej podstawie. Na przykład praca sieci. Sieci i internet są wszędzie, stykasz się z nimi na co dzień, ale gdy zagłębisz się w technologie, które za nimi stoją, odkryjesz ogromną i bardzo skomplikowaną dyscyplinę, której nauka – ani razu nie jest spacerem po parku.

Nie włączyłem tego punktu do listy, ponieważ jest kluczowy dla IT w ogóle, a nie tylko dla administracji systemów. Oczywiście, nie uda się nauczyć wszystkiego od razu – po prostu fizycznie nie starczy ci czasu. Dlatego podczas samokształcenia warto pamiętać o niezbędnych poziomach abstrakcji.

Nie musisz od razu uczyć się, jak działa wewnętrzne zarządzanie pamięcią w każdej pojedynczej aplikacji i jak współdziała z zarządzaniem pamięcią Linuksa, ale wiedzieć, jak wygląda schematycznie pamięć operacyjna i po co jest potrzebna, to dobra rzecz. Nie musisz znać strukturalnych różnic między nagłówkami TCP i UDP, ale byłoby dobrze zrozumieć podstawowe różnice w działaniu protokołów. Nie musisz uczyć się, co oznaczają tłumienia sygnału w optyce, ale dobrze jest wiedzieć, dlaczego rzeczywiste straty zawsze dziedziczą się po węzłach. Nie ma nic złego w tym, aby wiedzieć, jak działają konkretne elementy na określonym poziomie abstrakcji, i nie trzeba rozkładać na czynniki pierwsze absolutnie wszystkich poziomów, gdy abstrakcji wcale nie ma (po prostu się zgubisz).

Jednak w swojej dziedzinie rozważanie na poziomie abstrakcji „to taka rzecz, która pozwala wyświetlać stronki” – nie jest zbyt dobre. Następne wykłady będą poświęcone przeglądowi głównych obszarów, z którymi administrator systemu musi się zmierzyć w pracy na niższych poziomach abstrakcji. Postaram się ograniczyć ilość omawianej wiedzy do minimalnego poziomu abstrakcji.

10 przykazań administracji systemu

Zatem przyswoiliśmy cztery główne filary i fundament. Czy możemy zacząć rozwiązywać problemy? Jeszcze nie. Przedtem warto zapoznać się z tzw. „best practices” i zasadami dobrego tonu. Bez nich istnieje ryzyko, że przyniesiesz więcej szkody niż pożytku. Zaczynajmy:

Niektórzy z moich kolegów uważają, że pierwszą zasadą jest „nie zaszkodź”. Ale skłaniam się do myślenia, że się nie zgadzam. Kiedy próbujesz nie zaszkodzić, to nie możesz nic zrobić – zbyt wiele działań może być potencjalnie destrukcyjnych. Uważam, że najważniejszą zasadą jest – „zrób kopię zapasową”. Nawet jeśli zaszkodzisz, zawsze można cofnąć się i nie będzie już tak źle.
Kopie zapasowe należy robić zawsze, gdy czas i miejsce na to pozwalają. Powinieneś tworzyć kopie zapasowe rzeczy, które zamierzasz zmieniać, oraz tego, co ryzykujesz utratą przy potencjalnie destrukcyjnym działaniu. Kopie zapasowe najlepiej sprawdzić pod kątem integralności i obecności wszystkich potrzebnych danych. Nie warto usuwać kopii zapasowych tuż po tym, jak wszystko sprawdzisz, jeśli nie trzeba zwolnić miejsca na dysku. Jeśli miejsce wymaga — zrób kopię zapasową na własny serwer i usuń po tygodniu.
Drugą co do ważności zasadą (którą sam często łamię) jest — „nie ukrywaj”. Jeśli zrobiłeś kopię zapasową, napisz — gdzie, aby twoim kolegom nie przyszło szukać. Jeśli wykonałeś jakieś nieoczywiste lub skomplikowane działania, zapisz to: pójdziesz do domu, a problem może się powtórzyć lub pojawić u kogoś innego i twoje rozwiązanie zostanie znalezione po słowach kluczowych. Nawet jeśli robisz coś, co dobrze znasz, twoi koledzy mogą o tym nie wiedzieć.
Trzeciej zasady nie trzeba wyjaśniać: „nigdy nie rób czegoś, konsekwencji czego nie znasz, nie wyobrażasz sobie lub nie rozumiesz”. Nie kopiuj poleceń z internetu, jeśli nie wiesz, co one robią, zawołaj man i najpierw to rozważ. Nie stosuj gotowych rozwiązań, jeśli nie możesz zrozumieć, co one robią. Zminimalizuj do absolutnego minimum wykonanie złożonego kodu. Jeśli nie masz czasu na zrozumienie — to znaczy, że coś robisz źle i powinieneś zapoznać się z następnym punktem.
„Testuj”. Nowe skrypty, narzędzia, jednowiersze i polecenia powinny być testowane w kontrolowanym środowisku, a nie na komputerze klienckim, jeśli istnieje choćby minimalny potencjał do działań destrukcyjnych. Nawet jeśli wszystko zbackupowałeś (a na pewno to zrobiłeś), przestoje nie są fajne. Stwórz w tym celu osobny serwer/maszynę wirtualną/chroot i testuj tam. Nic się nie zepsuło? Można wtedy uruchamiać na „produkcyjnych”.
„Kontroluj”. Zminimalizuj wszystkie operacje, których nie kontrolujesz. Jedna krzywa zależność w paczce może pociągnąć za sobą połowę systemu, a flaga -y ustawiona dla yum remove daje Ci możliwość poćwiczenia umiejętności przywracania systemu od podstaw. Jeśli działanie nie ma niekontrolowanych alternatyw — przejdź do następnego punktu i przygotowanego backupu.
„Sprawdzaj”. Sprawdzaj skutki swoich działań i to, czy trzeba wrócić do backupu. Sprawdzaj, czy problem rzeczywiście został rozwiązany. Sprawdzaj, czy błąd się powtarza i w jakich warunkach. Sprawdzaj, co możesz zepsuć swoimi działaniami. Zaufanie w naszej pracy to za mało, ale sprawdzanie — nigdy.
„Rozmawiaj”. Jeśli nie możesz rozwiązać problemu, zapytaj kolegów, czy się z tym spotkali. Chcesz zastosować kontrowersyjne rozwiązanie — poznaj zdanie kolegów. Może zaproponują lepsze rozwiązanie. Nie jesteś pewny swoich działań — przedyskutuj je z kolegami. Nawet jeśli to Twoja dziedzina ekspertyzy, świeże spojrzenie na sytuację może wiele wyjaśnić. Nie wstydź się swojej niewiedzy. Lepiej zadać głupie pytanie, wydawać się głupcem i otrzymać odpowiedź, niż nie zadać pytania, nie otrzymać odpowiedzi i pozostać naiwnym.
„Nie odmawiaj pomocy bez podstaw”. Ten punkt to przeciwieństwo poprzedniego. Jeśli zadano Ci głupie pytanie — wyjaśnij i wytłumacz. Jeśli proszą o coś niewykonalnego — wyjaśnij, dlaczego to jest niewykonalne i ofiaruj alternatywy. Jeśli nie masz czasu (naprawdę nie masz czasu, a nie ochoty) — powiedz, że masz pilną sprawę lub dużą ilość pracy, ale zajmiesz się tym później. Jeśli koledzy nie mają pilnych zadań, zaproponuj, aby się do nich zgłosili i deleguj pytanie.
„Dawaj feedback”. Ktoś z kolegów zaczął stosować nową metodę lub nowy skrypt, a Ty napotykasz negatywne skutki tej decyzji? Zgłoś to. Być może problem można rozwiązać w trzech linijkach kodu lub pięciu minutach modyfikacji metody. Natknąłeś się na błąd w oprogramowaniu? Zgłoś błąd. Jeśli występuje lub nie ma potrzeby go reprodukować, prawdopodobnie zostanie naprawiony. Wyrażaj życzenia, propozycje i konstruktywną krytykę, przedstawiaj pytania do dyskusji, jeśli wydają się aktualne.
„Proś o feedback”. Wszyscy nie jesteśmy doskonali, tak jak i nasze decyzje, a najlepszym sposobem na zweryfikowanie poprawności swojej decyzji jest przedstawienie jej do dyskusji. Optymalizowaliście coś u klienta - poproście o monitorowanie działania, może „wąskie gardło” systemu nie jest tam, gdzie szukaliście. Napisaliście skrypt-pomocnika - pokażcie go kolegom, może znajdą sposób na jego ulepszenie.

Jeśli regularnie stosujesz te praktyki w pracy, większość problemów przestaje być problemami: nie tylko zminimalizujesz liczbę swoich własnych błędów i wpadek, ale również będziesz mieć możliwość ich naprawienia (w postaci kopii zapasowych i kolegów, którzy mogą Ci doradzić, abyś je zrobił). Dalej już tylko techniczne szczegóły, w których, jak wiadomo, tkwi diabeł.

Podstawowe narzędzia, z którymi będziesz musiał pracować ponad 50% czasu – grep i vim. Co może być prostszego? Wyszukiwanie w tekście i edytowanie tekstu. Jednak grep i vim to potężne wielofunkcyjne narzędzia, które umożliwiają efektywne wyszukiwanie i edytowanie tekstu. Jeśli jakieś notatki w Windows pozwolą Ci po prostu napisać/usunąć linijkę, to w vimie możesz robić z tekstem niemal wszystko. Nie wierzysz - wywołaj z terminala polecenie vimtutor i zaczynaj uczyć się. Jeśli chodzi o grep - jego główną siłą są wyrażenia regularne. Tak, samo narzędzie pozwala dość elastycznie ustalać warunki wyszukiwania i wyświetlane dane, ale bez RegExp to nie ma większego sensu. A znajomość wyrażeń regularnych jest konieczna! Chociażby na podstawowym poziomie. Na początek polecam Ci obejrzeć to wideo, w nim omawiane są podstawy wyrażeń regularnych i ich zastosowanie razem z grep. Ach tak, łącząc je z vim, zyskujesz ULTIMATE POWER możliwość robienia z tekstem takich rzeczy, że trzeba je obwiesić znaczkami 18+.

Z pozostałych 50% 40% przypada na zestaw narzędzi coreutils. Listę dla coreutils możesz zobaczyć w wikipedia, a podręcznik do całej listy — na stronie GNU. To, co nie jest objęte tym zestawem, znajduje się w narzędziach POSIX. Nie musisz na pamięć znać wszystkich kluczy, ale dobrze jest przynajmniej orientować się, co mogą podstawowe narzędzia — to przydatne. Nie będziesz musiał wymyślać koła na nowo z prostymi rozwiązaniami. Kiedyś musiałem zamienić znaki nowej linii na spacje w wyjściu z jakiegoś narzędzia, a chory umysł wymyślił konstrukcję w postaci sed ':a;N;$!ba;s/n/ /g', podszedł kolega, odepchnął mnie miotłą od konsoli, a potem rozwiązał problem, pisząc tr 'n' ' '.

Polecałbym zapamiętać, co mniej więcej wykonuje każde pojedyncze narzędzie i klucze do najczęściej używanych poleceń, na wszystko inne jest man. Nie wahaj się wzywać man, jeśli masz jakiekolwiek wątpliwości. I koniecznie przeczytaj man o samym man — zawiera ważne informacje o tym, co możesz znaleźć.

Z znajomością tych narzędzi będziesz mógł efektywnie rozwiązać znaczną część problemów, z którymi spotkasz się w praktyce. W następnych wykładach omówimy, kiedy stosować te narzędzia i struktury głównych usług oraz aplikacji, do których są one stosowane.

Z wami był administrator systemów FirstVDS Kirill Cwietkow.

Źródło: habr.com