- PVSM.RU - https://www.pvsm.ru -
Лучшее, что может случиться, — это если результаты того, что я делаю, никогда и никому не пригодятся.
Можно сказать, что я профессиональный параноик: моя задача — разрабатывать планы действий на случай чрезвычайных ситуаций и обучать людей грамотно реагировать в таких случаях. Зачем это нужно? Довольно просто — чтобы в случае непредвиденных ситуаций всегда была страховка.
Есть базовые риски (например, остановка дата-центра или пожар в главном офисе), есть известные риски от руководства, есть наш анализ критичности технических систем. Этот список рисков постоянно обновляется, и каждая из угроз должна быть закрыта.
Для компании такой подход означает защиту от кучи угроз, плюс банальную экономию на возможных простоях. По примерной оценке, затраты на нашу работу составили всего 5-10 процентов от суммы возможных убытков в случае чрезвычайных ситуаций, которые удалось предотвратить.
Важно понять, что мы не строим отдельные планы на каждый случай. Наши планы нацелены на устранение самой плохой ситуации. В документах есть указания на все стороны участников, просто в зависимости от ситуаций некоторые ветви планов могут быть не использованы. Это значит, что мы не делаем специальный план на случай прилёта агрессивных пришельцев, но команды восстановления смогут работать по веткам «повреждение ЦОДа» и так далее.
Так как мы являемся техническим подразделением, то и наши планы нацелены на устранение проблем в технической области. Потому технические службы у нас задействованы во всех планах. Колл-центры задействованы везде, так как через них идет оповещение абонентов. Сотрудники PR тоже входят в кризисный комитет, они знают о всех наших ЧС и восстановлениях и в зависимости от решений антикризисного комитета решают, что и кому говорить.
Кроме того, что мы строим всевозможные планы по восстановлению и резервированию систем, ещё мы же делаем предварительную работу, в частности, инициируем внутри компании проекты по резервированию систем.
Таблица ниже иллюстрирует процесс присвоения ИТ-приложениям класса восстановления и технических решений по резервированию, в соответствии с RTO и RPO.
Распределение классов восстановления и технических решений по резервированию не точно совпадает с приведенной выше таблицей. Эта таблица служит только для пояснения в рамках топика.
Не бывает такого, чтобы мы написали документ, а он лёг «в стол». Планы постоянно меняются, поскольку меняется ситуация. Люди приходят и уходят. Постоянно меняется аппаратная и программная часть системы или услуги. Меняются технологии. Меняется критичность услуги, соответственно, меняются требования ко времени восстановления, и приходится менять техническое решение. То есть, это живой организм.
Сотрудники уже давно спокойно воспринимают, что мы постоянно проводим как «бумажные» тестирования, вроде «что ты будешь делать, если», так и имитации, когда аварийные ситуации обыгрываются на месте.
Из последних крупных примеров реальных ситуаций: в 2010 году, летом, во время аномальной жары, в основном ЦОД стали отказывать кондиционеры и останавливаться один за другим. Температура внутри ЦОД стала опасно расти.
До активации плана дело не дошло: сработала наша подготовка по резервированию. Благодаря переносу большой части систем, в резервный ЦОД было снижено выделение теплоты, и мы обошлись без аварии. И много других случаев, когда то ленточная копия в резервном ЦОДе, то наличие резервного оборудования во время биллинг-цикла, то наличие реплицируемых данных на массиве в резервном центре помогали восстанавливать сервис за небольшой промежуток времени.
Показательно, что сейчас уже никто не боится внеплановых отключений электропитания и жары в летнее время года. Да, некое «проседание» сервиса будет, но он очень быстро будет «поднят».
На первых этапах к нам относились только как к параноикам.
В 2003-2004 годах тема аварийного восстановления в IT была абсолютно не известна в России (а уж про аварийное восстановление бизнеса как таковое вообще никто не слышал). Развитие пошло от безопасников: инициативные люди в подразделении информбезопасности начали продвигать эту идею. Показывали кучу презентаций, взяли в помощники консультанта, который помогал рисовать и убеждать. Ключевым моментом был пожар у одного из интеграторов, который тогда плотно работал с «ВымпелКомом». После того, как у них сгорел ЦОД, руководство всерьез задумалось. Позвали из Англии специалистов, которые разработали первые политики и стратегии, плюс дали векторы движения.
Одним из первых шагов было введение тотального бекапа. Идея простая: вся информация подлежит резервному копированию. Даже бумажные документы сканируются и также складываются на ленту. Есть схема cross site backup, когда все, что подлежит резервному копированию, также дублируется в резервный ЦОД и там хранится по тем же политикам.
Мы регулярно проводим обучение и проверки работы команд восстановления сервисов — это как учебные тревоги. Проводим курсы, сертифицируем, даём практику. Готовых специалистов на рынке просто нет.
Итак, если вначале мы были параноиками, и нас не очень понимали, то сейчас всё изменилось. Во многих документах наши требования становятся блокирующими. Руководители подразделений серьёзно относятся к возможным рискам — и при этом понимают, что отчасти благодаря нашей работе, в случае любых сложных IT-проблем есть возможность быстро восстановиться. Думаю, это очень бережет нервы.
Автор: lucas_409
Источник [1]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/upravlenie-proektami/36436
Ссылки в тексте:
[1] Источник: http://habrahabr.ru/post/183164/
Нажмите здесь для печати.