Компания
496,81
рейтинг
5 апреля 2012 в 13:02

Разное → План аварийного восстановления — уверенность в завтрашнем дне для всей компании и спокойный сон ИТ-отдела


Знакомая ситуация?

Есть такая штука – непрерывность бизнеcа. Эта сфера уже достаточно развита и подразумевает, что ваш бизнес может продолжить работу без происшествий даже после попадания метеорита в дата-центр или офис.

Интересно, что сейчас в России успешное внедрение планов аварийного восстановления бизнеса обладает побочным эффектом в виде быстрого карьерного роста предложившего и внедрившего.


Будет непросто убедить топ-менеджеров инвестировать большие деньги в защиту от того, что вряд ли когда-то случится. Для этого нужно собрать доказательную базу и с цифрами в руках продемонстрировать, что потери бизнеса будут в разы больше инвестиций в резервы. В этом поможет давно сформированная методика анализа воздействия на бизнес – Business Impact Analysis.

Помимо ИТ, сейчас часто рассматриваются и другие ресурсы, необходимые для работы компании в кризисной ситуации – персонал, офисные помещения, производственные мощности и прочее. В стандарте «В525999-1:2006. Управление непрерывностью бизнеса» кристаллизовалось вот такое определение: «Непрерывность бизнеса — стратегическая и тактическая способность организации планировать свои действия и реагировать на инциденты и нарушения нормального хода бизнеса с целью продолжения деловых операций на определенном приемлемом уровне»

Зачем нужен план DRP или даже BCP?


Вести работу по обеспечению непрерывности деятельности должна любая компания, которой дорог собственный бизнес. Да, нам повезло жить в сейсмически стабильной области, вдалеке от торнадо, селевых потоков и извержений вулканов. Но для деловой репутации компании может быть не менее разрушительной потеря информации о клиентах из-за пожара, затопления серверной, террористической атаки – продолжите сами. Даже банальное отключение электричества и каналов связи может привести к серьезным потерям денег. Например, для банка это может обернуться паникой среди вкладчиков, которые понесутся забирать свои вклады, опасаясь, что их деньги вот-вот пропадут. Это, кстати, страшный сон любого банкира.

Движение в этом направлении поможет повысить отказоустойчивость ИТ-систем в целом. Многие технологические и организационные решения работают не только на катастрофические сбои, но и на часто случающиеся отказы отдельных систем. Следовательно, ваш ночной сон будет более крепким.

Если к тому же вы работаете в банке, то в соответствии с указанием ЦБ № 2194-У, ваш работодатель должен иметь план обеспечения непрерывности и восстановления деятельности (ОНиВД). Очень возможно, что формально этот документ есть, но про ИТ там только общие слова. Конкретизировать и обогатить его будет очень правильным шагом.

Помимо своей основной цели, работа по написанию планов DRP (восстановление ИТ-инфраструктуры) и BCP (всего, что требуется для определенного бизнес-процесса) позволяет разобраться в своих ИТ-системах и бизнес-процессах. Очень часто знания не формализованы и находятся в головах отдельных экспертов, при этом ни у кого нет понимания в целом, тем более в виде документа.

Сегодня для многих эта сфера — возможность быстрого карьерного роста, поскольку реализация таких проектов — не самая сильная часть сформировавшихся ИТ-департаментов. Часто в компаниях тема непрерывности бизнеса начинала расти именно с подачи ИТ-специалистов, а не консультантов, работающих с рисками.

Реализация проекта


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

1. Анализ воздействия на бизнес и анализ рисков. На этом этапе оценивается ущерб от простоя бизнес-процессов (хотя бы на уровне экспертных мнений), определяются зависимости бизнес-процесса от ИТ, ключевых сотрудников, оборудования, коммуникаций и проч. Если ваш проект чисто ИТ-шный, либо если у вас нет описанных бизнес-процессов, можно начинать не от БП, а от ИТ-систем. Также определяется, какие риски мы будем рассматривать. Проводится анализ, как реализация этих рисков будет влиять на наши бизнес-процессы.

Пример: простой любимой социальной сети (или онлайн-игры) вызывает резкую панику и отток пользователей, плюс рост популярности конкурентов. Аналитики определяют возможную сумму ущерба и вероятность – и формируют бюджет на защиту. Может оказаться, что содержание резервной площадки с полным дублированием в разы экономичнее, чем даже регулярные отказы мелких систем, вызывающих 2-3 минутные простои.

2. Аудит текущей защищенности. Очень редко в компаниях есть исчерпывающая информация об инфраструктуре, в том числе информационной, требуемой для повседневной работы. Цель этапа – засучив рукава обследовать все и понять, насколько защищены мы сейчас, где слабые места, и что нужно делать, чтобы минимизировать риски. Какие-то «бутылочные горлышки» возможно устранить сразу и без больших затрат.

3. Третий этап подразумевает разработку стратегии обеспечения непрерывности — технических и организационных мер, повышающих готовность компании к чрезвычайным ситуациям. По его окончании может производиться аренда резервного офиса, закупки оборудования, аренда каналов, заключение договоров с подрядчиками итд.

4. На четвертом этапе собственно пишутся планы обеспечения непрерывности бизнеса (BCP), либо ИТ-систем (DRP). Они включают в себя четкую последовательность шагов — что кому и когда делать при наступлении чрезвычайной ситуации. Это значит, что каждый специалист должен понимать, что и как конкретно делать вместо панического бега по офиса и звонков всем подряд.

5. Следом должны проводиться учения по планам, их корректировка и запуск механизма постоянной актуализации. Поддержание готовности компании к чрезвычайной ситуации — непрерывный процесс. Каждый квартал планы должны актуализироваться, а каждые полгода желательно проводить учения. Только при соблюдении двух этих условий все ваши усилия окупятся, когда проблема случится.


Случается

Как начать и к чему стремиться?


  1. Изучите матчасть. В этой области масса своих терминов и подходов, причем точное значение может быть не так очевидно «с точки зрения банальной эрудиции». Для того чтобы перейти ко второму шагу, вы сами должны точно понимать, чего вы хотите и говорить на одном языке с отраслевыми спецами.
  2. Доведите идею до высокого руководства. Без поддержки идея обречена на провал. Потратьте несколько часов, дней, недель чтобы очень четко и образно донести до руководства, к каким последствиям могут привести катастрофические сбои, желательно их оцифровать. Приблизительную оценку сделать очень просто – берете годовой оборот или прибыль по какому-то направлению или компании в целом. Делите на 365 и получаете грубую оценку упущенной выгоды за день простоя (если, конечно, это направление завязано на ИТ). К ней надо прибавлять прямые потери и ущерб репутации, но это можно сделать и позже.
  3. В этот момент или даже немного раньше есть смысл привлечь внешнего консультанта. Его опыт может быть решающим фактором успеха на начальном этапе, когда глаза разбегаются от количества задач, людей, систем которых надо учесть в проекте. Но даже если в него вовлечены самые опытные консультанты, у Вас и вашей команды должно быть огромное желание довести проект до конца – это будет долгий и трудный путь.
  4. Ограничьте область действия проекта. Лучше сделать его для нескольких наиболее критичных ко времени простоя бизнес-процессов/ИТ-систем, чем взяться сразу за все и не добиться результата.
  5. Сформируйте управляющий комитет, состоящий из топ-менеджеров и назначьте профессионального и авторитетного руководителя проекта. Замечательно, если это вы и есть.
  6. Подготовьте реалистичный план проекта. В зависимости от размера организации, работа может длиться от нескольких месяцев до года. Если ваш проект предполагается боле продолжительным, лучше разбить его на несколько подпроектов, либо ограничить scope.
  7. Привлеките лучших из возможных экспертов. Во многом, для этого нужна поддержка руководства. Обычно эксперты и так загружены и требуется скорректировать их приоритеты.
  8. Пройдите все этапы, и ни в коем случае не отказывайтесь от тестирования и прогона аварийных ситуаций в духе «учебных тревог».
  9. Регулярно актуализируйте планы, добавляйте в них новые системы, всегда задавайтесь вопросом «а что я буду делать, если это откажет»?

Если дальше интересно, могу рассказать какие конкретно меры приводят к достижению 80% результата при 20% работы и затрат. Проще говоря, с помощью ряда простых действий можно подготовить компанию к чрезвычайной ситуации, затем, если эта ситуация всё же случится (пусть даже не очень серьёзная) – предотвратить последствия и собрать данные, которые помогут убедить руководство в необходимости внедрения полного процесса.

И ещё одно: если у вас были примеры, когда продуманное планирование «чёрного дня» реально помогло, расскажите, пожалуйста, в комментариях.
Автор: @Dmitry_Doshaniy
КРОК
рейтинг 496,81

Комментарии (27)

  • 0
    отличная статья!
    Если дальше интересно....

    Ждем продолжения ;)
  • +4
    И ещё одно: если у вас были примеры, когда продуманное планирование «чёрного дня» реально помогло, расскажите, пожалуйста, в комментариях.

    Не знаю как насчет сработавших планов, но вот на тему когда планов не было, а «черный день» пришел — наверное у каждого админа найдется не одна история :)

    Продолжение было бы весьма позновательно.
    • +3
      Хорошо, в следующем топике будет пошаговое руководство по основным моментам.
      • +1
        Пожалуйста, пригласите к изучению, как опубликуете.
        Боюсь пропустить.
  • 0
    Спасибо за статью. Тоже поднимал данный вопрос со своим руководством. Но руководство не хочет платить за него деньги.
    Тогда я описал риски и время восстановления в нормальном режиме(без спешки) и заставил их эти риски принять на себя.
    Теперь сплю спокойно.

    К сожалению культура русского ИТ на очень низком уровне… Не понимают баре, что это нужно…
    Нужно просто чтобы что-то упало и перестало работать. Как упадёт, так сразу можно подсовывать бумаги на подпись на закупку всего нужного оборудования и т.д. и т.п.
    • 0
      > Как упадёт, так сразу можно подсовывать бумаги на подпись на закупку всего нужного оборудования и т.д. и т.п.

      Да, и первой из всех этих бумаг — заявление об увольнении ПСЖ.
    • +1
      Тогда я описал риски и время восстановления в нормальном режиме(без спешки) и заставил их эти риски принять на себя.

      Да, только вот все равно в итоге жопа в мыле будет у простых админов а не у руководителя IT подразделений. Мало того, но даже после того как наступает «черный день», ситуация с планом DR может и не поменяться (не только в плане «построить резервный пункт», но и даже в плане простых инструкций «кому куда бежать»).
    • 0
      У меня на одном месте работы была беседа (инициаторы — безопасники и высокое начальство) на тему «Что делать если все поломается». Было обсчитано два варианта — нормальный и максимально дешевый (т.е. практически на коленке). Посмотрев цифры, высокое начальство резюмировало: «Да ну его на№№№, вот как упадет, так и будем думать что делать». Вот что тут можно сказать по этому поводу, да и стоит ли?
  • +15
    Рассказали как то историю падения одного Датацентра.
    Стоял большой корпоративны федеральный ДатаЦентр.
    Весь из себя Т4 (самый надежный) по всем стандартам выполненный и с железом на полмлрддолларей внутри.

    В здание заведены два луча питания от независимых источников.

    Полностью обеспечено резервное питание на аккумуляторах (20-90минут в зависимости от важности сервера), а так же дизель генератор на три дня работы и резервный чуть поменьше.
    И было все хорошо.
    И ДатаЦент был плечом геокластераразных распределенных систем.

    И тут одному человеку показалось что не нужно в этом нежилом здании электричество и вырубил он ОБА луча питания.
    И был это человек из ХХХЭнерго.

    Вид из здания:
    Мигнул свет. Стало тише. Включилось резервное питание.
    В машинных залах противно запищали упсы.
    Вот сейчас зарычит дизель и все… можно спокойно бить ХХХЭнерго.
    Вот сейчас…
    ……
    Блин…

    Прошиб озноб и стало жарко.
    Жарко… Кондиционеры… Они же не питаются от упсов (проектировщикам надо по голове, а лучше головой и желательно об угол)
    Значит времени до перегрева 15 минут.

    А потом … даже подумать страшно.

    И тут все забегали. Вспоминая порядок действийпо инструкции №1 (полная ж##а с питанием)
    Побежали проверять генераторы. Ведущий – мертвый и незаводится.

    Резервный! Не помним как заводить и что делать.

    В это время в машинном зале админы лихорадочно укладывают сервера.
    Берегут ключевую систему, а она самая горячая…
    10 минут. Критическая температура – лег первым апликейшен.
    Всё спасать больше нечего сервисы легли. ShotDown.

    Становиться тише. 15 минут

    Эффект домино нарастает. Сервера падают с температурой. В зале 70 градусов. Двери открывать нельзя (пыль из 3000-5000 радиаторов выгребать никто не хочет) да и не спасет.

    Становиться совсем тихо.

    Все. ДатаЦентр мертв.

    Ведущий дежурный администратор садиться на пол в машинном зале обхватывает голову руками сидит минуту, достает сигарету и закуривает.
    Уже похрен, пожарка тоже без питания. =)

    Резерв аккумуляторов исчерпан. Здание погружается во тьму.
    • 0
      Они периодические пробные запуски генераторов не проводили?
      • 0
        почему не запустился генератор я не знаю.
        скорее всего забили на тестовые пуски, а может слили дизель с резерва, там вариантов много.
        итог один
    • +1
      хех, вся эта система работает только с периодической проверкой.
      в 27001 требуется обязательное (как правило годовое) тестирование BCP, в 25999 вроде тоже.

      зачетная история:) если б еще паблик была, так можно нести руководству как реальный пример, чтобы получить коммитмент на устройство нормальной схемы.
      • 0
        Она в паблике была. Только в официальной версии и не так драматично, без подробностей.

        Вообще если копнуть тот же синус, то за каждой из историй «технологических сбоев в системе и простоев» стоит не меньшая драматургия событий со своими интригами, переживаниями смертями процессов и целых ферм:)
        • +1
          О, да. Недавно читал про самую большую ДДОС атаку и действия атакуемых, так как будто остросюжетный боевик посмотрел.
          • 0
            Рождается новый жанр. ИТ-боевик.
            Bullet time вместо пуль будет показывать экран терминала и набираемые команды. :)
    • 0
      Эпично. Я бы такой кин посмотрел… :)
      У меня в практике было по факту тоже весело — сел аккум на генераторе, и его пришлось снимать срочно с машины главного энергетика. :)
      Но простой всеравно был. Электрика находилась в ведении энергетиков.
      • 0
        Админ хорор:)
        В принципе снять не долго. Главное найти дата центр:)

        А на счет питания у энергетиков — стандартная тема. Разделение не всегда приводит к правильным последствиям.
    • 0
      Человек из ХХХЭнерго жив?
      • 0
        Конечно. Но стал мудр:) и проницателен. Так как дзен ему объяснили:)
        • 0
          Хм… странно… я думал он был лишён как минимум конечностей =)
          • 0
            А что взять то? Омтается понять и простить.
    • 0
      Ух ты ж какой ит-хоррор…
  • +2
    Real Life DR & BC, with VMware SRM
    www.vsamurai.com/english/2011/3/23/real-life-dr-bc-with-vmware-srm.html

    История от первого лица о том, как VMware SRM и продуманный план помогли восстановить работу в резервном ДЦ во время мартовских землетрясений в Японии в прошлом году.
  • 0
    В библиотеке ITIL есть великолепные рекомендации и описания.В последнем издании количество томов уменьшилось. Попробуйте прочесть.
  • 0
    Вся эта штука с безопасностью очень полезна и правильна и работает она только в экстренных ситуациях, которые происходят крайне редко. Однако, именно подготовка к таким ситуациям и требуется самая тщательная и дорогая, так как если хоть один момент упущен, все насмарку
  • +2
    В наших реалиях (в частности в Незалежной) гораздо актуальней план эвакуации в случае маски-шоу от УБЭПа или налоговой, а также от дружественных визитов прокуратуры
  • 0
    Сама подготовка снижает вероятность аварии на порядок.
    Во время подготовки к таким событиям ликвидируются все узкие места, приводится в порядок документация и она доже начинает отражать реальность. И прочее и прочее.

    Да, мы потратили несколько ночей на стресс-тест оборудования, не считая все подготовки к тестам. Но и работало все потом хорошо, и после аварии (свет погас, а энергетики забыли наш луч к дизелю подключить) система сама поднялась. Детали к сожалению не могу рассказать, но как и выше описано гасили серверы в по приоритету, дабы основные системы, которые включать очень и очень долго, получили шанс.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разное