🥇Начинаещият сисадмин: как да превърнете хаоса в ред

Аз съм системен администратор на FirstVDS и това е текстът на първата въведителна лекция от краткия ми курс за помощ на начинаещи колеги. Специалистите, които току-що започват да се занимават със системно администриране, се сблъскват с редица от едни и същи проблеми. За да предложа решения, реших да напиша този цикъл лекции. Някои неща в него са специфични за техническата поддръжка на хостинг, но в общи линии могат да бъдат полезни, ако не за всички, то за много. Затова адаптирах текста на лекцията, за да споделя тук.

Няма значение каква е вашата длъжност — важно е, че всъщност се занимавате с администриране. Затова ще започнем с това, с което трябва да се занимава системният администратор. Основната му задача е да подреди, поддържа реда и да се подготви за предстоящото увеличение на реда. Без системен администратор на сървъра започва хаос. Логовете не се пишат или съдържат неверни данни, ресурсите се разпределят неефективно, дискът се запълва с всякакъв боклук и системата започва да се срине от такова количество безпорядък. Спокойно! Системните администратори в лицето ви започват да решават проблеми и да отстраняват хаоса!

Стълбовете на системното администриране

Но преди да започнем да решаваме проблемите, е добре да се запознаем с четирите основни стълба на администрирането:

Документация
Шаблонизация
Оптимизация
Автоматизация

Това е основата на основите. Ако не изградите работния си процес въз основа на тези принципи, той ще бъде неефективен, непродуктивен и като цяло малко ще прилича на истинско администриране. Нека да разгледаме всеки от тях поотделно.

Документация

Документация подразбира под себе си не само четене на документация (въпреки че без това не става), но и водене на записки.

Как да водите документация:

Сблъскали сте се с нов проблем, който преди не сте виждали? Запишете основните симптоми, начините на диагностика и принципите за отстраняване.
Измислили сте ново елегантно решение на стандартен проблем? Запишете го, за да не се налага да го изобретявате отново след месец.
Някой ви е помогнал да разберете въпрос, в който не сте разбирали нищо? Запишете основните тези и концепции, нарисувайте си схема.

Основна идея: не трябва напълно да се доверявате на собствената си памет при усвояването и прилагането на новото.

Форматът, в който ще го правите, зависи само от вас: това може да бъде система за бележки, личен блог, текстов файл или физически тетрадка. Най-важното е вашите записи да отговарят на следните изисквания:

Да не бъдат прекалено дълги. Изтъквайте основните идеи, методи и средства. Ако разбирането на проблема изисква да се гмуркате в механиката на работата с паметта в Linux, не пренаписвайте статията, от която сте я узнали — дайте линк към нея.
Записите трябва да бъдат разбираеми за вас. Ако редът race cond.lockup не ви позволява веднага да разберете какво описвате с него — пояснете. В добра документация не е нужно да се разбирате в продължение на половин час.
Търсенето е много полезна функция. Ако водите записи в блог, добавяйте тагове; ако в физически тетрадка — залепете малки пост-ити с описания. Няма особено значение в документацията, ако търсенето на отговор в нея ви отнема толкова време, колкото би ви отнело да решите въпроса от нулата.

Така може да изглежда документация: от примитивни записи в тетрадката (горната снимка) до напълно функционална мултиплейър база знания с тагове, търсене и всички възможни удобства (по-долу).

Вие не само, че няма да се налага да търсите същите отговори два пъти: документирането ще бъде страхотно помощно средство в изучаването на нови теми (конспекти!), ще подобри вашето интуитивно чувство (способността да диагностицирате сложен проблем с един бърз поглед) и ще добави организираност в действията ви. Ако документацията бъде достъпна за вашите колеги, те ще могат да разберат какво и как сте сътворили, когато не сте на място.

Шаблонизация

Шаблонизация е създаването и използването на шаблони. За решаването на повечето стандартни въпроси е добре да се създаде определен шаблон на действия. За диагностика на повечето проблеми трябва да се използва стандартизирана последователност от действия. Когато поправите/инсталирате/оптимизирате нещо, работоспособността на това нещо трябва да се проверява по стандартизирани чек-листи.

Шаблонизация е най-добрият начин за организиране на работния процес. Използвайки стандартни процедури за решаване на най-често срещаните проблеми, получавате много полезни неща. Например, използването на чеклистове ще ви позволи да диагностицирате всички важни функции за работа и да отстраните диагностиката на маловажната функционалност. Стандартизираните процедури ще сведат до минимум ненужните колебания и ще намалят вероятността за грешки.

Първият важен момент е, че процедурите и чеклистовете също трябва да се документират. А ако разчитате само на паметта, може да пропуснете важна проверка или операция и всичко да се провали. Вторият важен момент е, че всички шаблонни практики могат и трябва да бъдат модифицирани, ако ситуацията го изисква. Няма идеални и абсолютно универсални шаблони. Ако има проблем и шаблонната проверка не го е открила — това не означава, че проблемът не съществува. Въпреки това, преди да се заемете с проверка на малко вероятни хипотетични проблеми, винаги е добре първо да направите бърза шаблонна проверка.

Оптимизация

Оптимизация казва само за себе си. Работният процес трябва да бъде максимално оптимизиран по отношение на време и трудозатрати. Вариантите тук са безброй: научете горещи клавиши, съкращения, регулярни изрази и налични инструменти. Търсете начини за по-практично използване на тези инструменти. А ако 100 пъти на ден извиквате команда, свържете я с клавишно съкращение. Ако ви е необходимо редовно да се свързвате с едни и същи сървъри, запишете alias с едно слово, който ще ви свързва с тях:

Разгледайте различни налични инструменти — може да се окаже, че има по-удобен терминален клиент, DE, мениджър на Clipboard, браузър, пощенски клиент или операционна система. Разберете какви инструменти използват вашите колеги и познати — може би те не са ги избрали просто така. След като подберете инструментите, научете се да ги прилагате: научете клавиши, съкращения, съвети и трикове.

Оптимално използвайте стандартните инструменти — coreutils, vim, регулярни изрази, bash. За последните три има огромно количество страхотни ръководства и документация. С тяхна помощ можете доста бързо да преминете от състояние на "чувствам се като маймуна, която чупи ядки с лаптоп" до "аз съм маймуна, която използва лаптоп, за да поръча счупвачка за ядки".

Автоматизация

Автоматизация ще премести тежките операции от нашите изморени ръце в непрестанните ръце на автоматизацията. Ако някоя стандартна процедура се изпълнява с пет еднакви команди, защо да не обвитете всичките тези команди в един файл и да не извикате една команда, която сваля и изпълнява този файл?

Всъщност автоматизацията на 80% се състои от написването и оптимизацията на собствените ви инструменти (и още 20% от опитите да ги накарате да работят както трябва). Това може да бъде просто напреднал едноредов код или огромен всемогъщ инструмент с уеб интерфейс и API. Основният критерий тук — създаването на инструмент не трябва да отнема повече време и усилия, отколкото времето и усилията, които този инструмент ще ви спести. Ако пишете скрипт пет часа, който никога повече няма да ви бъде полезен, за задача, за решаването на която без скрипт ви е отнело час или два — това е много лоша оптимизация на работния процес. Можете да отделите пет часа за създаването на инструмент, само ако количеството, типът задачи и времето го позволяват, което не се случва често.

Автоматизацията не задължително предполага написването на пълноценни скриптове. Например, за да създадете куп еднотипни обекти от списък, е достатъчен ловък едноредов код, който автоматично ще направи това, което вие бихте направили с ръце, превключвайки между прозорците с много копи-пейст.

Всъщност, ако построите процеса на администриране на тези четири стълба, можете доста бързо да повишите своята ефективност, продуктивност и квалификация. Въпреки това, този списък трябва да бъде допълнен с още един пункт, без който работата в IT практически е невъзможна — самообучение.

Самообучение на системния администратор

За да бъдете поне малко компетентни в тази сфера, трябва постоянно да учите и да научавате нови неща. Ако нямате най-малко желание да се сблъсквате с неизвестното и да се разбирате, много бързо ще "заседнете". В ИТ постоянно се появяват различни нови решения, технологии и методи, и ако не ги изучавате поне повърхностно — сте на път към загуба. Много области на информационните технологии имат много сложна и обширна основа. Например, работата на мрежата. Мрежите и интернетът са навсякъде, срещате ги ежедневно, но ако задълбаете в технологиите, които стоя зад тях, ще откриете огромна и много сложна дисциплина, изучаването на която — не е разходка в парка.

Не включих тази точка в списъка, защото тя е ключова за ИТ като цяло, а не само за системното администриране. Естествено, няма да успеете да научите всичко веднага — просто физически нямате достатъчно време. Затова при самообразованието е необходимо да помните за необходимите нива на абстракция.

Не е необходимо веднага да учите как работи вътрешното управление на паметта на всяка отделна утилита и как то взаимодействува с управлението на паметта на Linux, но поне е полезно да знаете схематично какво представлява оперативната памет и защо е необходима. Не е нужно да знаете как структурно се различават заглавията при TCP и UDP, но би било полезно да разбирате основните различия в работата на протоколите. Не трябва да изследвате какво представляват загубите на сигнал в оптиката, но би било добре да знаете защо реалните загуби винаги се предават по възлите. Няма нищо лошо в това да знаете как работят определени елементи на определено ниво на абстракция и не е необходимо да разглеждате абсолютно всички нива, когато абстракцията изобщо я няма (просто ще полудеете).

Въпреки това, в своята област, да разсъждавате на нивото на абстракция "ну това е нещо, което позволява показването на сайтчета" — не е особено добре. Следващите лекции ще бъдат посветени на преглед на основните области, с които системният администратор се сблъсква в работата на по-ниски нива на абстракция. Ще се опитам да ограничим количеството разглеждани знания до минималното ниво на абстракция.

10 заповеди на системното администриране

И така, усвоихме четири основни стълба и основа. Можем ли да започнем да решаваме проблемите? Още не. Преди това е желателно да се запознаете с така наречените „най-добри практики“ и правила на добрия тон. Без тях има вероятност да причините повече вреда, отколкото полза. И така, да започнем:

Някои от моите колеги смятат, че най-важното правило е „не вреди“. Но аз съм склонен да не се съглася. Когато се опитваш да не навредиш, не можеш и да действаш — прекалено много действия потенциално са деструктивни. Най-важното правило за мен е — „направи резервна копия“. Дори да навредите, винаги можете да се върнете назад и всичко вече няма да изглежда толкова зле.
Резервни копия трябва да се правят винаги, когато времето и мястото позволяват. Необходимо е да се бекъпва онова, което ще променяте, и онова, което рискувате да загубите при потенциально деструктивно действие. Освен това, резервната копия трябва да бъде проверена за целостта и наличието на всички нужни данни. Не трябва да се изтрива веднага след проверка, освен ако не е необходимо да се освободи място на диска. Ако мястото е проблем, бекъпнете на личния си сервер и изтрийте след една седмица.
Второто по важност правило (което аз самият често нарушавам) е — „не крий“. Ако вече сте направили резервно копие, запишете къде, за да не се налага на вашите колеги да го търсят. Ако сте извършили неочевидни или сложни действия, запишете ги: ще си отидете у дома, а проблемът може да се повтори или да възникне у някой друг и вашето решение ще бъде намерено по ключови думи. Дори ако правите нещо, което добре познавате, колегите ви може да нямат тази информация.
Третото правило не се нуждае от обяснение: „никога не прави нещо, чиито последици не знаеш, не представаваш или не разбираш“. Не копирайте команди от интернет, ако не знаете какво правят. Прочетете man и първо го разберете. Не прилагане на готови решения, ако не можете да разберете какво правят. Ограничете до абсолютния минимум изпълнението на обфускиран код. Ако нямате време да се запознаете, вие правите нещо не така и трябва да се запознаете с следващия пункт.
„Тествай“. Новите скриптове, инструменти, едноредови кодове и команди трябва да се тестват в контролирана среда, а не на клиентската машина, ако там има поне минимален потенциал за разрушителни действия. Дори ако всичко е архивирано (а вие го направихте), времето на спиране не е най-хубавото нещо. Осигурете си отделен сървър/виртуална машина/chroot и тествайте там. Нищо не се счупи? Тогава може да пуснете на 'боевото'.
«Контролирай». Намалете до минимум всички операции, които не контролирате. Една извратена зависимост от пакет може да потегли половината от системата, а зададеният флаг -y за yum remove дава възможност да потренирате своите умения за възстановяване на системата от нулата. Ако действието няма неконтролируеми алтернативи - следващия пункт и готовия бекъп.
«Проверявай». Проверявайте последствията от вашите действия и дали е нужно да се върнете на бекъпа. Проверявайте, дали проблемът наистина е решен. Проверявайте, възпроизвежда ли се грешката и при какви условия. Проверявайте какво можете да разрушите с действията си. Доверието в нашата работа е излишно, а проверката - никога.
«Общувай». Ако не можете да решите проблема, попитайте колегите си, дали те са се сблъсквали с нещо подобно. Искате да приложите спорно решение - узнавайте мнението на колеги. Може би те ще предложат по-добро решение. Нямате увереност в действията си - обсъдете ги с колеги. Дори ако това е ваша експертна област, свежият поглед върху ситуацията може да изясни много. Не се срамувайте от собственото си незнание. По-добре да зададете глупав въпрос, да изглеждате глупави и да получите отговор, отколкото да не зададете въпроса, да не получите отговор и да останете в глупост.
«Не отказвай помощ без основание». Тази точка е обратното на предишната. Ако ви зададат глупав въпрос - изяснете и обяснете. Просят невъзможно - обяснете, че то е невъзможно и защо, предлагайте алтернативи. Ако нямате време (наистина нямате време, а не желание) - кажете, че имате неотложен въпрос с голям обем работа, но ще се заемете по-късно. Ако колегите нямат неотложни задачи, предложете да се обърнат към тях и делегирайте въпроса.
«Давай фидбек». Някой от колегите започна да прилага нова методология или нов скрипт, а вие се сблъсквате с негативни последици от това решение? Уведомете ни за това. Възможно е проблемът да се решава с три реда код или пет минути корекции на методологията. Срещнали сте бъг в софтуера? Докладвайте за бъга. Ако може да се възпроизведе или не е необходимо да се възпроизвежда, вероятно ще бъде поправен. Изразявайте желания, предложения и конструктивна критика, повдигайте въпроси за обсъждане, ако смятате, че са актуални.
«Помолете за обратна връзка». Всички ние не сме съвършени, както и нашите решения, а най-добрият начин да проверим правилността на решението си е да го представим за обсъждане. Оптимизирали сте нещо при клиента — помолете да следят работата, може «вратата» на системата да не е там, където сте търсили. Написали сте помощен скрипт — покажете го на колегите, може да намерят начин да го подобрят.

Ако постоянно прилагате тези практики в работата, повечето проблеми спират да бъдат проблеми: вие не само ще сведете до минимум собствените си грешки и провали, но и ще имате възможност да поправяте грешки (в лицето на резервни копия и колеги, които ще ви посъветват да направите резервно копие). Следващото са само техническите детайли, в които, както е известно, се крие дяволът.

Основните инструменти, с които ще трябва да работите повече от 50% от времето — grep и vim. Какво може да бъде по-просто? Търсене в текст и редактиране на текст. Въпреки това и grep, и vim са мощни многофункционални инструменти, които позволяват да търсите и редактирате текст ефективно. Ако някой Windows notepad позволява просто да напишете/изтриете ред, то в vim можете да правите почти всичко с текста. Не вярвате — извикайте командата vimtutor от терминала и започнете да учите. Що се отнася до grep — основната му сила е в регулярните изрази. Да, самия инструмент позволява доста гъвкаво формулиране на условия за търсене и извеждане на данни, но без RegExp това няма особено значение. И трябва да познавате регулярните изрази! Поне на базово ниво. В началото бих ви препоръчал да погледнете това видеото, в него се разглеждат основите на регулярните изрази и тяхното приложение съвместно с grep. О, да, при съвместяването им с vim, получавате ULTIMATE POWER възможност да правите с текста такива неща, че да им се сложат значки 18+.

От останалите 50%, 40% са за пакета инструменти coreutils. За coreutils списъкът можете да видите в Wikipedia, а наръчникът за целия списък — на сайта GNU. Това, което не е покрито от този набор, го има в утилитите POSIX. Не е нужно да запомняте всичките опции наизуст, но е полезно поне да знаете какво могат основните инструменти — няма да се наложи да изобретявате велосипеда отново. Някак си ми трябваше да заменя новите редове с интервали в изхода от една утилита, и болният ум роди конструкция от вида sed ':a;N;$!ba;s/n/ /g', приближил се колега ме изгони с метла от конзолата, а после реши задачата, написвайки tr 'n' ' '.

Бих ви предложил да запомните какво изпълнява всяка отделна утилита и кратките опции за най-често използваните команди; за всичко останало има man. Не се колебайте да повикате man, ако по нещо се съмнявате. И непременно прочетете man за самия man — той съдържа важна информация за това, какво ще намерите.

Знаейки тези инструменти, ще можете ефективно да решите значителна част от задачите, с които ще се сблъскате на практика. В следващите лекции ще разгледаме кога да прилагате тези инструменти и структурите на основните услуги и приложения, към които те се прилагат.

С вас беше системният администратор FirstVDS Кирил Цветков.

Източник: habr.com