Соотносим потребности бизнеса с его возможностями

В предыдущих статьях (1,2), посвященных вопросам планирования аварийного восстановления, были описаны процедуры сбора и обработки информации об ИТ-инфраструктуре организации, позволяющие получить точную информацию о:

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

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

Данный этап полностью состоит из согласования с руководством компании следующих аспектов взаимодействия:

1. Время поддержки бизнеса внутренней ИТ-службой

Готовность технических специалистов приступить к аварийному восстановлению сразу после получения информации о сбое является основным фактором для определения времени поддержки. Восьмичасовой рабочий день, отпуска, болезни, отгулы естественно ограничивают данную возможность. Если у вас нет специалистов с необходимыми для проведения восстановительных работ компетенциями или нет достаточного перекрытия инженерами как по времени, так и на случай отсутствия одного из них, то бизнесу не стоит рассчитывать на поддержку в графике 24/7. Если же текущее перекрытие специалистами не позволяет гарантировать оперативность реагирования даже в графике 9*5, то тут возможны следующие варианты:

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

Однако и с внешними подрядчиками все не так однозначно:

2. SLA с внешними подрядчиками

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

Если существующее соглашение об уровне обслуживания внешнего поставщика является неудовлетворительным для вашего бизнеса (или просто отсутствует), то тут возможны следующие варианты:

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

После того, как вы определились с людьми и/или компаниями, которые будут заниматься восстановительными работами, вы можете обозначить время поддержки пользовательских сервисов, которое может быть заложено в рамки соглашения об уровне обслуживания между ИТ-отделом и бизнесом. Осталось только согласовать предельные сроки их восстановления, а для этого необходимо обсудить:

3. Получение резервов, необходимых для аварийного восстановления

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

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

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

4. Предварительные заготовки для ускорения аварийного восстановления

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

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

5. Объем выполняемых регламентных задач

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

6. Ситуации, выходящие за рамки SLA.

Есть ситуации, в которых сложно спрогнозировать сроки восстановление и которые выходят за рамки планирования. Это не только форс-мажорные ситуации, но еще и события с одновременным отказом двух и более элементов одного типа, возникновение которых допускает теория вероятности.

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

На этом этап согласования можно считать завершенным — остались лишь мелкие формальности:

Закрепляем согласованные параметры и действуем

Результаты ваших переговоров с руководством стоит закрепить на бумаге, отразив в ней:

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

Закрепленные в документе договоренности позволят вам перейти из ситуации когда «ИТ-инфраструктура делает вид что работает, а бизнес делает вид что вкладывает в нее», к ситуации, когда бизнес понимает, на какой уровень сервиса он может рассчитывать в зависимости от инвестиций в ИТ.

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

Успехов!

Иван Кормачев
t.me/depit_ru

Планирование аварийного восстановления. Часть третья — заключительная