Ідеальний сисадмін

Автор : Денис Овсієнко

Переклад українською : Ярослав Федевич

Не знаю, наскільки це вірно для інших ОС (принаймні, не для всіх точно), але для Linux однозначно справедливо наступне: операційна система — це не набір файлів. Точніше, не просто набір файлів, а сукупність досить порядного багажу знань: стандартів, прийнятих методик і просто узгоджень із одного боку, й поточного стану живої системи в цілому з іншого, включаючи й кожен окремо взятий файл.

Відповідно й адміністрування операційної системи відрізняється від адміністрування вмісту файлового архіву.

Давайте ще раз глянемо на сам термін «операційна система». Тут недаремно вживається слово «система» — її компоненти найчастіше не можуть працювати окремо один від одного, виходить, у більшості випадків якісь компоненти залежать від інших компонентів.

Ті, у свою чергу, залежать ще від чогось, породжуючи важко відслідковувані ієрархічні й/або циклічні залежності, причому, підкреслю, не тільки на рівні наявності/відсутності файлів потрібних версій, а також і мережних служб, викликів RPC, інших неочевидних зв'язків.

Чому тут я роблю наголос на файлах? Тому, що це найперший показник упорядкованості системи й, мабуть, єдина її сфера, в якій можливо навести хоч якийсь лад. Якщо ви ще не читали книжку Maximum RPM, обов'язково прочитайте хоча б перші розділи.

Автор книги постарався (і це в нього вийшло) пояснити принципи пакетного підходу, успішно застосовуваного в більшості вчорашніх, сьогоднішніх і завтрашніх дистрибутивів, наочно й переконливо. Якщо ви не маєте змоги прямо сьогодні звернутися до цієї фундаментальної, й досить-таки застарілої праці, поясню. Суть першого розділу зводиться до двох тверджень:

людина не може самотужки відстежувати залежності між тисячами й десятками тисяч файлів;
машина повинна працювати, а людина — думати (приписується IBM, наскільки пам'ятаю).

Хто винен?

Досить давно можна зустріти посібники по встановленню ПЗ для Linux, написані найрізноманітнішим контингентом, які зводяться до благословення й прокльону більшості програм для POSIX (*NIX): configure && make && make install !

Багато хто може запитати: «І що тут такого? Я сам так роблю». Влучне запитання. Якщо інструкція називається «Як встановити < назву ПЗ > за 15 хвилин» і виконання приписаних кроків справді дозволяє отримати працюючу програму за 15 хвилин, що в цьому неправильного?

Ось що: такі інструкції по совісті повинні називатися «Як встановити < назву ПЗ > за 15 хвилин, якщо у Вас вже не крутиться робоча інсталяція, котру небажано ламати через невдало скомпільовані файли чи знесення конфігураційного файлу, який писався тиждень, некерованим make install; якщо ви напам'ять пам'ятаєте всі ключі configure; якщо ви самостійно напишете сценарії цього ПЗ для init і logrotate; якщо ви не збираєтеся автоматизовано оновлюватися до наступної версії і якщо ви самостійно відшукаєте всі файли, які наплодив make install, коли захочете позбутися цього ПЗ».

Трохи менш привабливо, так? Мені таке формулювання не подобається, хоча це й справа особистого смаку. Все залежить від того, якої мети бажаємо досягти.

Визначмося, чи є сенс далі читати далі? Якщо:

необхідно досягнути швидкого ефекту будь-яким чином (є спеціальна група ліків: симптоматичні, єдина їхня дія в тому, що ви почуваєтеся здоровими і навантажуєте звичайною нормою роботи хворий організм);
вам ліньки читати документацію;
ви перевстановлюєте систему дуже часто і анітрохи від цього не страждаєте;
відновлення системи у вас популярністю не користується;
вас цілком влаштовує робити резервне копіювання всієї файловій системи, щоб нічого випадково не забути,

то напружуватися дуже й не варто. Якщо ж наявні такі ознаки:

ваша основна спеціалізація — супровід серверів, а не користувачів;
ви безпосередньо, тобто особисто своєю зарплатою/репутацією відповідаєте за доступність і правильну роботу сервісів в режимі як мінімум 245/246;
ви відповідаєте більш ніж за 1 машину;
ви адмініструєте публічно доступні сервіси і усвідомлюєте, що свіжу вразливість сканер-автомат здатний намацати і проломити за кілька секунд; час відновлення працездатності пошкодженої чи знищеної ділянки мережі і/або серверу не має перевищувати час монтажу апаратного забезпечення + кілька годин;
надання сервісів вашої інфраструктурою планується не на найближчі кілька місяців, а постійно;
показник праці системних адміністраторів мусить бути сумою зусиль нинішніх і попередніх працівників, а не випадковим значенням з ряду рознесених за часом і напрямком спроб змінити щось на краще,

то дуже ймовірно, що системне адміністрування — ваша робота й виконувати її можна лише правильно, інакше це вже буде зовсім іншим заняттям.

Причому що більша організація й що інтенсивніше в ній використовуються інформаційні технології, то це очевидніше.

Втім, це справедливо для більшості професій.

Що робити?

Отже, як впоратися з фермою серверів?

По-перше, зрозумійте, що час, що залишився до повної втрати даних — в кращому випадку залишок техресурсу конкретного сервера.

По-друге, розділіть котлети й мухи. Тобто визначте, що саме на кожному сервері є унікальними даними (бази даних, наповнення серверів Тенет, мастер-зони DNS і т. д.) і старанно заінвентарюйте.

Виділіть собі час і регулярно робіть резервне копіювання, поклавши на всі інші заняття — це ваша козирна карта в ситуації.

Другою частиною буде строкатий табір встановленого ПЗ з супровідними конфігураційними файлами (якщо деякі з них нетривіальні, то розумніше буде їх віднести до першої групи). Виясніть, що саме й де у вас працює, можливо, не обійдеться без сюрпризів.

Фронт робіт намічено, але як оцінити ступінь відповідності ідеалу?

Дуже просто. Наприклад, є напрацьована методика обслуговування апаратних маршрутизаторів: необхідно лише зберігати в безпечному місці копію файлу його поточної конфігурації.

Припустимо, в маршрутизатор потрапляє блискавка й від нього залишається лише пом'ята металева коробка з вуглинками. Вимагаємо новий такої ж моделі, заливаємо конфігурацію і — вуаля! — штатний режим відновлено.

Досить показово. Застосуймо той самий підхід, але з відомими ускладненнями в подробицях.

Насамперед необхідно знати, що відновлювати. Для цього все, що можна встановити з RPM, які входять у дистрибутив, а не збирати самотужки, має бути встановлено з RPM. У цьому випадку ви отримуєте замість карти з скарбом «візьми вихідники з цього сайта, латки з цього, а скрипт, який запускає configure, в архіві, що лежить там... ще й там... не пам'ятаю, пошукай» стисле і однозначне «встанови пакет такий-то».

Передбачаю заперечення: що робити, якщо в дистрибутиві стара версія пакету? А якщо пакету в дистрибутиві немає? На перше відповім: користуйтеся системою оновлень вашого дистрибутиву й налаштуйте її на ваше локальне дзеркало оновлень (невже дзеркало ще не налаштоване?).

Якщо періодичність оновлень залишає бажати кращого, змініть дистрибутив, ви маєте право розумного вибору коштів, коли на вас покладено відповідальність за результат. Можливо, це вирішить відразу й друге запитання.

Якщо не вирішить, то попросіть видавців дистрибутива зробити це, повинні ж вони мати якийсь зворотний зв'язок!

Якщо не допоможе, зберіть пакет самі, а ще краще — зберіть і попросіть включити в дистрибутив, все одно роботу вже зроблено і ви зможете допомогти іншим адміністраторам. Деякі з них витратять час, що звільниться, на складання і включення пакета, який у майбутньому може знадобитися вам.

Отже, ви маєте список стандартних пакетів, і, можливо, трохи самотужки зібраних RPM. Візьміть підхожий параметрами запасний сервер і виконайте встановлення нової системи. Збережіть список пакунків з інсталятора (якщо він цього не вміє, ви маєте право змінити свої уподобання).

Кілька слів про набори пакетів: вибір «встановлювати все» не такий добрий, як здається. По-перше, ви отримаєте пакети, які ніколи не використовуватимуться, але вимагатимуть відновлення.

По-друге, якщо якийсь із використовуваних вами стандартних чи самотужки зібраних пакетів має неправильні залежності, ви цього просто не помітите, а неправильні залежності — річ неприємна і гарантує певний відсоток збоїв в майбутньому.

По-третє, на спеціалізованому сервері власне система із ПЗ може займати 300 мегабайт, так навіщо ж викидати зайві гігабайти (5–10 і більше залежно від дистрибутива) на вітер? Дисковий простір зайвим не буває, це перевірене часом правило.

Озирніться, чи не забуто щось за бортом. Я, наприклад, найчастіше забував встановити утиліти мережевої діагностики. Коли так — повторюйте встановлення зі збереженням списку пакетів до досягнення стану «ні додати, ні відняти».

Вітаю, тепер ви справді знаєте, що саме працює у вас на конкретно взятому сервері. Дискета, як відомо, річ дешева й ненадійна, тому найкраще буде помістити її образ і на CD з конфігураційними файлами. Основна частина роботи зроблена, тепер необхідно лише підтримувати ваші увічнені на звичайному CD-R концентровані відомості актуальними.

Відновлення найдорожчого — даних — в термінах роботи з пакетами не формулюється і залежить від самих даних, тож постарайтеся прорепетирувати цю сцену самостійно, але з дотриманням тих самих вимог: лише чистий сервер і стос компакт-дисків у руках. Якщо все, абсолютно все працює так само, як і на виробничому сервері, спробуйте їх підмінити і почекайте тиждень.

Переходьте до наступного серверу.

Як жити далі?

Складне по суті питання, але щодо системного адміністрування можу дати однозначну відповідь «краще».

Тепер ви знаєте, звідки та для чого у вашій системі з'являються файли. Знаєте тому, що з'являються вони з пакетів і мають відповідні записи в базі даних RPM.

Тепер ви можете безстрашно запускати програму відновлення вашої системи (хіба у вас такої немає? ;-), бо вона — справді система, система, заснована на пакетах, котрі мають залежності, й відновлення системи звести до обновлення пакетів.

Ви ще пам'ятаєте кілька пропозицій про маршрутизатор, в який може спокійно вдарити блискавка? Мораль цього прикладу не в тому, що всі маршрутизатори мають бути спеціалізованими залізячками, а в словах «...копію файла його поточної конфігурації», точніше, в слові «поточної».

Знову, незамиленим оком подивіться на це слово. Поточна — виходить, безперервно мінлива. Життя не стоїть на місці, виходять нові версії дистрибутивів. Головне, що має бути незмінним — відображення довгострокових і важливих змін конфігурації вашої системи в її резервних копіях.

Сподіваюсь, якщо ви будете застосовувати таку практику, то тепер при встановленні навіть одного справді потрібного пакету, при редагуванні навіть одного рядка в одному конфігураційному файлі ви думатимете про нарізку свіжого екземпляра того CD, який лежить замкненим у сейфі та в будь-який ситуації дозволяє вам іти додому вчасно.