Планування аварійного відновлення. Частина перша

    

Визначаємо місця, де стоїть підстелити соломку

 
  
Відмови в роботі інформаційних систем — події, які неможливо виключити повністю. Незалежно від причин того, що сталося збою, в момент його виникнення на системного адміністратора лягає тягар відповідальності з оперативного відновлення працездатності не тільки ІТ-систем, а й бізнесу в цілому.
 
У циклі з трьох коротких статей я постараюся доступно описати процес формування плану аварійного відновлення, який дозволяє перевести завдання з відновлення працездатності систем в розряд заздалегідь узгоджених з керівництвом заходів, що мають свій графік, ресурси і бюджет.
 
У першій статті мова піде про визначення зони планування, або пошуку тих інфраструктурних елементів, відмова в роботі яких негативно впливає на частоту пульсу системного адміністратора. Отже, по порядку:
 
 
1. Складаємо список критичних користувальницьких ІТ-сервісів
Мета планування аварійного відновлення — забезпечити оперативне відновлення роботи кінцевого сервісу, який отримує користувач, а не якоїсь конкретної залізяки чи програми. Користувачеві не важливо, працює або зламаний його принтер — йому важливо може він віддрукувати документи чи ні. Скаржитися користувач буде не на те, що в сервері відмовив жорсткий диск, а на те, що у нього не працює «1С-ка» або «пошта».
 
З цієї причини перше, що ми робимо — визначаємо список критичних користувальницьких ІТ-сервісів, для яких будемо планувати аварійне відновлення. Зазвичай це:
 
 
     
  • Електронна пошта,
  •  
  • Телефонний зв'язок,
  •  
  • Система управління підприємством,
  •  
  • Спільна робота з документами,
  •  
  • Друк документів,
  •  
  • Доступ в Інтернет,
  •  
  • І так далі.
  •  
По суті, користувальницькі сервіси — це ті робочі інструменти, які купує бізнес, вкладаючи гроші в залізо, ПО і зарплати фахівців і які критичні для його функціонування. Наприклад сервер «Counter Strike», звичайно ж, є важливим елементом у питаннях поліпшення робочого настрою співробітників, але не критичним для роботи бізнесу.
 
 
2. Визначаємо точки відмови користувача сервісів
Якщо користувач буде скаржитися на проблеми в якомусь кінцевому сервісі, то лагодити все одно доведеться конкретний елемент в ІТ-інфраструктурі. Тому на даному етапі необхідно виявити всі системи, програми та ІТ-сервіси, відмова в роботі яких неминуче призведе до зупинки або зниження якості роботи критичних для користувача сервісів. Простіше кажучи, ваше завдання знайти всі точки відмови.
 
Під точкою відмови ми маємо на увазі ту інфраструктурну одиницю, про яку ми не можемо сказати більше, ніж «воно не працює». Наприклад, якщо ваш маршрутизатор модульний, то в ньому може відмовити як саме шасі, так і вставляються в нього модулі. Якщо вашої компетенції достатньо для локалізації та заміни відмовили блоків у разі збою — у вас кілька точок відмови в одному пристрої, якщо ні — то точка відмови одна.
 
Так, у сервісу «Електронна пошта» можуть бути наступні точки відмови (включаючи, але не обмежуючись):
 
 
     
  • Серверна ОС,
  •  
  • Серверне поштове додаток,
  •  
  • Комутатор ядра,
  •  
  • Електропостачання,
  •  
  • Зовнішня зона DNS,
  •  
  • Попадання в «чорні списки»,
  •  
  • Кондиціювання серверної.
  •  
Важливо! Не треба виключати з точок відмови наднадійне обладнання, з яким «точно нічого не трапиться». Коли (саме коли, а не якщо) ваша наднадійна СГД втратить всі дані, продовжите ви сміятися в цирку чи ні, буде залежати тільки від вашої готовності до цієї ситуації.
 
 
3. Визначаємо залежності точок відмови
Збої в роботі деяких точок відмови можуть провокувати збої в роботі інших. Наприклад, відмова ДБЖ призведе до зупинки в роботі серверів і, як наслідок, при відновленні електропостачання у вас може не заробити щось ще. Також і зупинка гіпервізора може викликати помилки в роботі віртуальних серверів, які розміщувалися на ньому. Водночас, відмова клієнтського комутатора не впливає на роботу іншого обладнання або сервісів, і при його коректної заміни все працюватиме, як і раніше.
 
Для користувальницького сервісу «Електронна пошта» залежності точок відмови можуть виглядати так:
 
 
Схема 1. Залежності точок відмови.
 
У дану схему необхідно додати і інші критичні користувальницькі сервіси та відповідні точки відмови.
 
Чітке розуміння впливу точок відмови один на одного і на призначені для користувача сервіси допоможе вам при подальшому плануванні, а саме при складанні процедур локалізації точок відмови, визначенні умов відновлення та факторів ризику. Але про це докладніше в наступній статті.
 
Гарного дня!
    
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.