За начинаещ системен администратор: как да създадем ред от хаоса

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

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

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

Въпреки това, преди да започнете да решавате проблеми, си струва да се запознаете с четирите основни стълба на администрацията:

1. Документация
2. Шаблониране
3. Оптимизация
4. Автоматизация

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

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

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

Как се съхранява документацията:

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

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

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

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

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

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

Шаблониране

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

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

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

Оптимизация

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

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

Използвайте оптимално стандартните инструменти - coreutils, vim, регулярни изрази, bash. За последните три има огромен брой прекрасни ръководства и документация. С тяхна помощ можете бързо да преминете от състоянието „Чувствам се като маймуна, която чупи ядки с лаптоп“ до „Аз съм маймуна, която използва лаптоп, за да си поръча крекер за ядки“.

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

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

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

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

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

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

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

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

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

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

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

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

1. Някои мои колеги смятат, че първото правило е „не вреди“. Но съм склонен да не се съглася. Когато се опитвате да не навредите, не можете да направите нищо - твърде много действия са потенциално разрушителни. Мисля, че най-важното правило е - „направете резервно копие“. Дори и да нанесете някаква повреда, винаги можете да се върнете назад и всичко няма да е толкова лошо.

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

2. Второто най-важно правило (което самият аз често нарушавам) е "не се крий". Ако сте направили резервно копие, напишете къде, за да не се налага колегите да го търсят. Ако сте извършили някои неочевидни или сложни действия, запишете го: ще се приберете вкъщи и проблемът може да се повтори или да възникне за някой друг и вашето решение ще бъде намерено с помощта на ключови думи. Дори да правите нещо, което познавате добре, вашите колеги може да не го правят.
3. Третото правило не е необходимо да се обяснява: „никога не правете нещо, последствията от което не знаете, не си представяте или разбирате“. Не копирайте команди от интернет, ако не знаете какво правят, обадете се на човек и първо ги анализирайте. Не използвайте готови решения, ако не разбирате какво правят. Поддържайте изпълнението на обфусциран код до абсолютния минимум. Ако нямате време да го разберете, значи правите нещо нередно и трябва да прочетете следващата точка.
4. "Тест". Новите скриптове, инструменти, едноредови команди и команди трябва да се тестват в контролирана среда, а не на клиентската машина, ако има дори минимален потенциал за разрушителни действия. Дори и да сте архивирали всичко (и сте го направили), престоят не е най-готиното нещо. Създайте отделен сървър/виртуален/chroot за това и тествайте там. Има ли нещо счупено? След това можете да го стартирате на „бой“.

   
   

5. "Контрол". Минимизирайте всички операции, които не контролирате. Една крива на зависимост на пакета може да повлече надолу половината система, а флагът -y, зададен за премахване на yum, ви дава възможност да практикувате уменията си за възстановяване на системата от нулата. Ако действието няма неконтролирани алтернативи, следващата точка е готово резервно копие.
6. "проверка". Проверете последствията от вашите действия и дали трябва да се върнете към резервно копие. Проверете дали проблемът наистина е разрешен. Проверете дали грешката се възпроизвежда и при какви условия. Проверете какво можете да нарушите с действията си. Излишно е да се доверявате на нашата работа, но никога да не проверявате.
7. "общуване". Ако не можете да разрешите проблема, попитайте вашите колеги дали са се сблъсквали с това. Ако искате да приложите противоречиво решение, разберете мнението на вашите колеги. Може би те ще предложат по-добро решение. Ако не сте уверени в действията си, обсъдете ги с колегите си. Дори ако това е вашата област на експертиза, нов поглед върху ситуацията може да изясни много. Не се срамувайте от собственото си невежество. По-добре е да зададеш глупав въпрос, да изглеждаш като глупак и да получиш отговор, отколкото да не зададеш въпроса, да не получиш отговор и в крайна сметка да се окажеш глупак.
8. „Не отказвайте неразумно помощ“. Тази точка е обратната на предишната. Ако ви зададат глупав въпрос, пояснете и обяснете. Искат невъзможното - обяснете, че е невъзможно и защо, предложете алтернативи. Ако нямате време (наистина нямате време, а не желание) - кажете, че имате спешен въпрос, много работа, но ще го разрешите по-късно. Ако колегите нямат спешни задачи, предложете да се свържете с тях и делегирайте въпроса.
9. „Дайте обратна връзка“. Някой от вашите колеги започнал ли е да използва нова техника или нов сценарий и сблъсквате ли се с негативни последици от това решение? Докладвайте го. Може би проблемът може да бъде решен с три реда код или пет минути усъвършенстване на техниката. Попадали ли сте на грешка във вашия софтуер? Докладвайте грешка. Ако е възпроизводимо или не е необходимо да се възпроизвежда, най-вероятно ще бъде поправено. Изразете своите желания, предложения и конструктивна критика и повдигнете въпроси за обсъждане, ако изглеждат уместни.
10. „Искане на обратна връзка“. Всички ние сме несъвършени, както и нашите решения, и най-добрият начин да проверите правилността на вашето решение е да го поставите на обсъждане. Ако сте оптимизирали нещо за клиент, помолете го да наблюдава работата; може би тясното място в системата не е там, където сте търсили. Написахте помощен скрипт - покажете го на колегите си, може би те ще намерят начин да го подобрят.

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

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

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

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

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

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

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