Как правильно спланировать аварийное восстановление: корректировка по потребности бизнеса

Максимально оперативное восстановление IT-инфраструктуры очень важно для любого бизнеса - ее простой это прямая потеря денег. Но насколько важно? Не каждый бизнес может себе позволить все самые затратные средства максимально быстрого поднятия системы. Как же вычислить точную сумму, которую целесообразно на это потратить?

Баланс между потребностями аварийного восстановления и финансовыми возможностями предприятия необходимо найти сразу после того, как мы определили возможные причины сбоя сервисов и наиболее подходящие средства их починки. Когда вы его найдете, его нужно будет закрепить в специальном соглашении - обычно его называют SLA, Service Level Agreement.

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

Внутренняя служба - время поддержки

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

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

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

Внешние подрядчики вообще часто воспринимаются как прекрасное решение в любом аварийном сценарии. на самом деле это далеко не всегда так.

Внешние подрядчики - SLA

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

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

Что же делать? Что ж, если вы уже в сотрудничестве, то вариантов немного -

• Попытаться все-таки утвердить необходимое вам SLA и право на случайные проверки готовности подрядчика к услугам в необходимых рамках. Подрядчик на это, естественно, может и не пойти.
• Сменить подрядчика на более подходящего - впрочем, случайные проверки и тут будут необходимы.
• Добавить еще одного, резервного внешнего помощника, чтобы дополнить услуги первого.
• Бывает так, что вы имеете дело с монополистом тех или иных услуг, который на заключение нужного вам SLA не идет. Что ж, остается довести это до сведения руководства и попытаться организовать себе сервис самостоятельно.

Определившись с тем, кто будет восстанавливать систему, переходим к тому, что потребуется для восстановительных работ.

Резервы для восстановления сервисов

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

Но иногда предприятие не может себе позволить почти никаких резервов или же может позволить себе их лишь частично. Тут важно объяснить начальству, как оценивать "резерв": например, приобрести сразу два коммутатора может показаться дорогим удовольствием, но как соотносятся цена второго коммутатора и цена дня простоя из-за отказа первого? Наверняка дороже.

Для бизнеса также может быть более приемлемо подписать контракты на срочную замену устройств в случае поломки - обычно это контракт "на следующий рабочий день", но сколько это, опять же, будет в потерянных деньгах?

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

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

Что не вошло в SLA

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

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