Несколько слов о планировании стратегии восстановления

Отвлекитесь на минутку от чтения и ответьте для себя на вопрос: насколько в действительности для Вас критичен простой Вашего сервиса продолжительностью в 1 минуту? Ответили? Думаю, если не все, то большинство из читателей подумали: «Переживём». А теперь ответьте, насколько критичен простой в 5 минут? А в 30, час, сутки? На каком-то из шагов в голове прозвучит: «Нет, ну это уже многовато». Только что Вы заложили один из важных параметров, необходимых для составления плана обеспечения непрерывности работы ИТ сервиса. О том, что это такое, и какой к нему лучше подходит соус, читайте под катом.



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



«Планирование непрерывности бизнеса (также иногда называется планированием непрерывности и отказоустойчивости бизнеса) определяет, насколько организация подвергается внутренним и внешним угрозам, и задаёт необходимые аппаратные и программные инструменты, позволяющие обеспечить эффективное противодействие и восстановление нормального функционирования организации с сохранением конкурентного преимущества и системной целостности» (Эллиот и др., 1999).

Этот термин изначально введён для более «тяжёлых» случаев — нарушений в работе офисов или дата-центров, вызванных пожарами, стихийными бедствиями, преступными действиями третьих лиц и прочими случаями, которые обычно происходят намного реже, чем, например, выход из строя жёсткого диска. Британский институт стандартов даже выпустил специальный стандарт по управлению непрерывностью бизнес-процессов — BS 25999. Однако мы не будем так углубляться, а просто постараемся помочь Вам понять для себя, как и насколько основательно Вам стоит готовиться к возможным перебоям.

Что Вы готовы потерять?

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

При возникновении нештатной ситуации есть три основных параметра, которые могут «теряться»: данные, время и деньги. Сопутствующие проблемы в виде потери репутации, упущенной выгоды и т.п. в итоге можно свести к этим трём.

Между параметрами существует очень тонкая связь. Например, чем меньше Вы готовы потерять времени и данных, тем больше денег Вам нужно вложить в резервирование мощностей и информации. При снижении затрат с сохранением времени восстановления может увеличиться потеря данных. И так далее.

Ещё до того, как заглянуть под кат, Вы, надеюсь, уже определили, какое максимальное время простоя допустимо для Вашего проекта. В терминологии планирования отказоустойчивости этот параметр называется целевым временем восстановления (recovery time objective, RTO). Это время, за которое должно быть восстановлено нормальное функционирование сервиса или бизнес-процесса для предотвращения тяжёлых последствий. Естественно, что для Вас является тяжёлыми последствиями, Вы также должны определить для себя сами.

Второй важный параметр, который Вы должны оценить при планировании, — целевая точка восстановления (recovery point objective, RPO). Это ещё один временной интервал. Он характеризует максимальное приемлемое время, за которое могут быть утеряны данные ИТ сервиса. Параметр этот описать несколько сложнее. Нельзя просто сказать, что это допустимый объём потери данных, хотя в нулевом приближении его именно так и рассматривают. Грубо говоря, это предельное время с начала создания последней доступной резервной копии до точки аварии.



Есть ещё два параметра — актуальные время и точка восстановления, но их можно узнать либо в процессе симуляции, либо в случае самой аварии.

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

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

Кто виноват?

В первую очередь, руководитель проекта и его ответственные специалисты. Провайдеры делают всё, что в их силах, для обеспечения максимального аптайма, но практически в любом договоре-оферте будет написано (возможно, третьим шрифтом), что провайдер не несёт никакой ответственности за любые перебои и потерю данных по любым причинам. Даже если пьяный инженер случайно отформатирует не тот сервер, с большой вероятностью ни на что серьёзнее искренних извинений и сожалений Вам рассчитывать не придётся. Кроме того, напомню тезис: всё когда-нибудь выходит из строя. Даже то, что позиционируется как сверхбесперебойная услуга (достаточно вспомнить масштабный даунтайм облака Amazon).



Сохранность Ваших данных и работоспособности услуг должна беспокоить прежде всего именно Вас. Именно Вы должны дать ответ на следующий вопрос:

Что делать?

Учиться на чужих ошибках, насколько это возможно. Современное информационное пространство позволяет проанализировать опыт великого множества отказов и оценить потенциальные слабые места своего проекта.

Первое, что нужно сделать на пути к составлению плана обеспечения непрерывности работы, — избавиться от иллюзий. Был на нашей практике случай, когда пользователь просто проигнорировал необходимость делать бэкапы. Не заработало корректно автоматическое резервное копирование в панели управления — ну и не надо. Он искренне считал, что RAID1 его спасёт. Каково же было его удивление, когда первый диск в массиве существенно деградировал, а на втором была масса ошибок в файловой таблице. Попытка оперативно заменить первый диск и пересобрать массив ни к чему хорошему не привела, как можно догадаться. Нашим администраторам пришлось возвращать работающий на грани полного отказа диск и мучительно долго вытаскивать из него данные байт за байтом. Аргумент, почему пользователь не делал бэкапы, нас удивил: «У меня за 6 лет работы никогда такого не было». Видимо, чем раньше в жизни администратора случается крупная потеря данных, тем лучше для его будущих проектов.

Второе — определите потенциальные угрозы, их вероятность и продолжительность воздействия. Сколько времени понадобится на переключение на сервис фильтрации DDoS? Сколько времени займёт замена диска или сервера целиком в Вашем дата-центре? Сколько времени понадобится на развёртывание проекта в другом ЦОД, если в Вашем случится пожар, наводнение, или просто провайдер внезапно прекратит своё существование? Где его развёртывать, за какое время будет предоставлено новое оборудование и т.п. Если полученные цифры не укладываются в ожидаемое Вами RTO, заранее поищите других провайдеров, инфраструктура которых поможет Вам восстановиться. Также определитесь, сколько данных Вы готовы потерять, и подберите подходящую схему резервирования.

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

Четвёртое — внедряйте. Простого подсчёта и оценки не достаточно. Нужно применить необходимые меры на практике. Закажите необходимое резервное оборудование и услуги, подпишите необходимые договоры, включите мониторинг. Распишите для себя в текстовом документе, к какому сервису в каких случаях обращаться, какая процедура действий в том или ином случае. Можно даже разок провести симуляцию того или иного отказа. За наличие чёткой и последовательной инструкции Вы ещё скажете себе спасибо, когда что-то случится. Наличие прописанного плана восстановления позволит Вам существенно сэкономить время и пучок нервов. Ситуация из разряда непредвиденных перейдёт просто в разряд чрезвычайных. Вы уже не будете блуждать во мраке, как слепой котёнок.



Ценность чего-либо в нашей жизни определяется тем, много ли мы готовы отдать, чтобы это сохранить. Если Вы действительно цените результаты своего труда, не забудьте позаботиться об их сохранности. Кто, если не Вы?