Філософія системного адміністрування

Переклад: Іван Песін

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

Автоматизувати все, що можна

Документувати все, що можна

Спілкуватися якомога більше

Знати свої ресурси

Нижче ми розглянемо кожну з цих ідей докладніше.

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

Ось деякі типи завдань, які зазвичай автоматизуються:

Перевірка вільного дискового простору і звітність по ньому

Збір інформації про продуктивність системи

Підтримка облікових записів (створення, видалення і т.п.)

Функції, пов'язані з діяльністю компанії (завантаження нових даних на веб-сервер, виконання щомісячних, квартальних, кодових звітів та ін.)

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

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

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

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

"Я зроблю це пізніше."

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

"Навіщо записувати? Я це запам'ятаю."

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

"Якщо я буду тримати це у себе в голові, вони мене не звільнять - у мене буде гарантія зайнятості!"

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

Будемо сподіватися, що тепер ви переконані в перевазі ведення системної документації. Це приводить нас до наступного питання: що ви повинні документувати? Ось неповний список:

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

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

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

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

Ім'я або ініціали людини, що зробила зміни

Дата внесення змін

Причина по якій були внесені змін

В результаті виходять короткі і корисні записи:

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

Взагалі, при написанні повідомлень, краще дотримуватися такого плану:

Розповідайте користувачам що ви збираєтеся робити

Розповідайте користувачам що ви робите

Розповідайте користувачам що ви зробили

Давайте тепер детальніше розглянемо ці кроки.

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

Як мінімум ви повинні описати:

Коли вони відбудуться

Чому це відбувається

Приблизно скільки цієї займе часу

Зміни (якщо є), з якими зіткнуться користувачі

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

Зупинка системи запланований на вечір п'ятниці

У п'ятницю, починаючи з 18:00 (опівночі для наших колег в Берліні), всі бухгалтерські програми будуть недоступні протягом, приблизно, чотирьох годин.

У цей час будуть вноситься зміни в апаратну і програмну частини сервера баз даних бухгалтерії. Ці зміни повинні будуть значно зменшити час, необхідний для запуску програм Кредиторська заборгованість, Дебіторська заборгованість та генерації тижневого балансового звіту.

Більшість користувачів не повинні помітити ніяких змін, крім збільшення швидкості роботи. Однак, ті користувачі, які написали власні SQL-запити, повинні враховувати, що будуть внесені зміни в схему деяких індексів. Ці зміни задокументовані на внутрішньому веб-сайті, в розділі "Бухгалтерія".

Кілька пунктів, які варто відзначити:

Повідомляйте відповідному чином про час початку і тривалості всіх зупинок, які необхідні для внесення змін.

Завжди вказуйте час майбутніх змін так, щоб всі користувачі зрозуміли його однозначно, незалежно від того, де вони знаходяться.

Використовуйте вирази, зрозумілі користувачам. Їх не цікавить, що новий процесор має частоту 2ГГц і вдвічі більший кеш другого рівня, або що база даних буде перенесена на масив RAID 5.

Цей крок, в основному, є останнім попередженням про майбутню подію; по суті, це повинно бути коротке повторення першого повідомлення, але з підкресленою наближається терміном події ( "Оновлення системи буде виконано СЬОГОДНІ УВЕЧЕРІ"). Також це гарне місце для відповідей на будь-які питання, які ви отримали після першого повідомлення.

Розвиваючи наш випадок з попереднього розділу, наводимо приклад останнього попередження:

Зупинка системи запланований сьогодні ввечері

Нагадування: Зупинка системи, анонсований в понеділок буде виконаний, як і заплановано, сьогодні о 18:00 (опівночі для берлінського офісу). Детальний повідомлення про зупинку системи знаходиться на внутрішньому веб-сайті, в розділі "Системне адміністрування".

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

Нагадуємо, що ті з вас, хто написав свої SQL-запити можливо будуть повинні внести в них зміни, оскільки зміняться схеми деяких індексів. Зміни задокументовані на внутрішньому сайті компанії, в розділі "Бухгалтерія".

Ваші користувачі попереджені; тепер ви можете братися за роботу.

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

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

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

У нашому випадку, при виконанні робіт адміністратор зіткнувся з проблемами. Новий процесорний модуль не запрацював; після дзвінка до виробника виявилося, що для заміни на місці необхідний спеціальний модуль. Міграція бази даних на RAID-масив пройшло успішно (хоча і зайняло більше часу ніж планувалося, через проблеми з процесорним модулем).

Зупинка системи завершений

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

Якщо у вас є питання звертайтеся до відділу системного адміністрування по тел. 4321.

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

Примітка

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

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

Зловмисник каже, що дзвонить звідкись з іншого кінця Землі (можливо, ця частина історії вигадана, а можливо на вашому сайті з'являвся прес-реліз про проведену фінансовим директором виставці).

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

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

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

Коротко: будь-якими способами доносите інформацію до ваших користувачів.

Системні адміністратори, які поставляться серйозно до всіх цих порад і будуть намагатися їх виконувати, стануть відмінними адміністраторами. але не надовго. Рано чи пізно, щось зміниться і одного разу він виявиться в калюжі. У чому ж причина? Наш супер адміністратор не зміг правильно спланувати події.

Звичайно, ніхто не може передбачити майбутнє зі 100% точністю. Однак, трохи спостережливості зробить очевидним безліч речей:

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

Розмова про наближення поглинанні іншої фірми, означає, що ви станете відповідати за нові (можливо несумісні) вилучені системи

Уміння бачити такі знаки (і відповідно на них реагувати) полегшить життя вам і вашим користувачам.

Фраза "передбачити непередбачуване" банальна, але вона відображає істину, яку повинні розуміти всі системні адміністратори:

У вашій практиці будуть випадки, які вас застануть зненацька.

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

Що ж в такому випадку повинен робити системний адміністратор, який передбачає непередбачене? Ймовірно ви можете тримати кілька запасних дисків на випадок апаратних проблем [1]. Такі диски можна тимчасово додати [2] в систему для вирішення виниклої необхідності в просторі. Крім того, це дасть час для ґрунтовного рішення проблеми (наприклад, для виконання стандартної процедури замовлення додаткового диска).

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

Примітка

І звичайно, системний адміністратор, який передбачає непередбачене, буде застосовувати RAID (або подібні технології) для зменшення наслідків збою критичних дисків при експлуатації систем.

Знову таки, системний адміністратор, який намагається передбачити проблеми, налаштовує свої системи так, щоб додавання диска в систему відбувалося якомога простіше.