Кращі практики та ресурси щодо розробки плану відновлення стихійних лих? [зачинено]

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

Наш план полягає в тому, щоб прийняти наш план ІТ-ІД і продовжити його, і сказати: "Ей, це те, що ми хочемо в плані ДР для ІТ, чи відповідає це те, що робить решта університету? Чи є відновлені пріоритети обслуговування? я хотів змінити? " Ми маємо досить гарну ідею, що є рештою плану, і ми очікуємо, що це добре перейде.

Що я шукаю - це вказівки щодо того, як розширити план ЗР та які питання я повинен думати. Чи є у вас улюблені ресурси, книги, навчання, пов'язані з розробкою плану ДР?

Прекрасним джерелом інформації є Disaster Recovery Journal ( про ).

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

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

Я вважаю, що їх щоквартальні публікації також є цікавими та інформативними ( підписатись ).

Переконайтеся, що у вас є список аварійних контактів. він також нагадує реєстр

Це повинно виглядати як дерево і показувати, хто з ким контактує. Наприкінці відділення остання особа повинна зателефонувати першою та повідомити всіх, до кого не вдалося зв’язатися.

(Це може бути узгоджено за допомогою HR та використовуватись для будь-якого типу катастроф)

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

Переконайтеся, що у вас є офлайн / віддалена документація вашої мережі

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

Ці два фактори можуть бути різними в різний час року та різними в різних системах.

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

Один із підходів, який можна використовувати для клієнтів, якщо ви виявите, що вони неохоче втягуються, - це задавати їм питання ДР з точки зору ІТ. Приклад запитання про те, які у них плани, якщо всі їх паперові файли згоряють. Це може допомогти їм більше долучитися до ширшої справи, пов'язаної з охороною здоров’я, і може ввести корисну інформацію у ваші власні плани.

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

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

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

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

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

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

Сіань

Існує кілька стандартів Британського інституту стандартів (BSi), які зосереджені на управлінні безперервністю та ліквідації наслідків аварій.

• BS 25999-1: 2006 Управління безперервністю бізнесу, Частина 1: Кодекс практики
• BS 25999-2: 2007 Управління безперервністю бізнесу. Специфікація
• BS 25777: 2008 Управління безперервністю інформаційних та комунікаційних технологій. Кодекс практики

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

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

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

Що стосується книг, там планується відновлення після катастроф Джона Вільяма Тоїго, тепер це вже 3-е видання, з горизонтом 4-го видання (блог + книга).

Лора,

Ось посилання від SQLServerPedia, що дає основи DR.

http://sqlserverpedia.com/blog/sql-server-backup-and-restore/disaster-recovery-basics-tutorial/

Читайте також на темі "Безперервність бізнесу"