Планування аварійного відновлення. Друга частина

    

Готуємося до будь падінь

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

0 коментарів

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