Соотносим потребности бизнеса с его возможностями
В предыдущих статьях (1,2), посвященных вопросам планирования аварийного восстановления, были описаны процедуры сбора и обработки информации об ИТ-инфраструктуре организации, позволяющие получить точную информацию о:
- ИТ-сервисах, критичных для бизнеса компании,
- Текущем времени восстановления их работы в случае сбоя,
- Минимально достижимых сроках аварийного восстановления,
- Необходимых ресурсах для их достижения.
И все бы ничего, если бы не ограниченные финансовые возможности организации, не позволяющие приобрести все необходимые резервы для оперативного восстановления. По этой причине заключительная задача планирования аварийного восстановления – поиск баланса между потребностями и финансовыми возможностями бизнеса, и закрепление его в виде соглашения об уровне обслуживания (Service Level Agreement – SLA) в части устранения возникающих инцидентов.
Данный этап полностью состоит из согласования с руководством компании следующих аспектов взаимодействия:
1. Время поддержки бизнеса внутренней ИТ-службой
Готовность технических специалистов приступить к аварийному восстановлению сразу после получения информации о сбое является основным фактором для определения времени поддержки. Восьмичасовой рабочий день, отпуска, болезни, отгулы естественно ограничивают данную возможность. Если у вас нет специалистов с необходимыми для проведения восстановительных работ компетенциями или нет достаточного перекрытия инженерами как по времени, так и на случай отсутствия одного из них, то бизнесу не стоит рассчитывать на поддержку в графике 24/7. Если же текущее перекрытие специалистами не позволяет гарантировать оперативность реагирования даже в графике 9*5, то тут возможны следующие варианты:
- Измерять сроки восстановления не с момента возникновения инцидента, а с начала работы специалиста по аварии,
- Сделать предварительные заготовки для возможности восстановления пользовательского сервиса менее компетентными специалистами,
- Обучить резервного специалиста необходимым навыкам,
- Передать точку отказа или полностью пользовательский сервис на обслуживание внешнему подрядчику, соответствующего необходимым параметрам SLA.
Однако и с внешними подрядчиками все не так однозначно:
2. SLA с внешними подрядчиками
За внешним благополучием сотрудничества с внешним подрядчиком может скрываться его неспособность устранять инциденты в требуемые бизнесу временные рамки. Удобство и эффективность работы может обернуться головной болью при первых же проблемах из-за отсутствия у внешнего поставщика понимания требуемого вам уровня сервиса.
Если существующее соглашение об уровне обслуживания внешнего поставщика является неудовлетворительным для вашего бизнеса (или просто отсутствует), то тут возможны следующие варианты:
- Договориться об изменении условий с существующим подрядчиком. Закрепить за собой право на несколько случайных проверок выполнения SLA,
- Сменить подрядчика на того, чье стандартное SLA соответствует вашим требованиям. И опять же проверять его выполнение,
- Подключить резервного оператора услуг для оперативного переключения на него в случае проблем у основного,
- Смириться и оставить все без изменений, если подрядчик является монополистом. Донести данное положение дел до руководства компании и закрепить его с ними,
- Организовать данный сервис собственными силами.
После того, как вы определились с людьми и/или компаниями, которые будут заниматься восстановительными работами, вы можете обозначить время поддержки пользовательских сервисов, которое может быть заложено в рамки соглашения об уровне обслуживания между ИТ-отделом и бизнесом. Осталось только согласовать предельные сроки их восстановления, а для этого необходимо обсудить:
3. Получение резервов, необходимых для аварийного восстановления
Наличие необходимых резервов оборудования напрямую влияет на возможность оперативного восстановления сервиса. Если у вас в компании один физический сервер, то при его отказе восстановить работу будет просто не на чем (подробнее об определении необходимых резервов смотри предыдущую статью). Если же на данный момент у вас в компании нет всех необходимых для проведения восстановительных работ резервов оборудования, то тут возможны следующие варианты:
- Приобрести оборудование заранее, если стоимость простоя заведомо превышает их цену. К примеру, резервный коммутатор стоит значительно дешевле простоя на срок его приобретения,
- Подписать сервисный контракт на замену отказавшего оборудования, если условие «замена на следующий рабочий день» приемлемо для бизнеса,
- Согласовать оперативное выделение средств на приобретение нужного элемента в случае сбоя, если стоимость простоя сопоставима с резервным элементом,
- Согласовать снижение качества работы систем в случае возникновения сбоя и/или отключения второстепенных сервисов для запуска в работу бизнес-критичных систем,
- Согласовать оперативное выделение средств на приобретение менее мощного оборудования для временного запуска в работу отказавшего сервиса с худшими параметрами качества.
В принципе, на этом этапе вы уже можете обозначить сроки, в которые возможно восстановление тех или иных пользовательских сервисов в случае любых сбоев. Если же сроки даже в случае наличия всех необходимых резервов не устраивают руководство, то это повод обсудить:
4. Предварительные заготовки для ускорения аварийного восстановления
Это может быть как дополнительная система мониторинга, резервного копирования так и дополнительный сервер или сетевое оборудование, настроенное и работающее в режиме горячей замены. Именно они могут потребоваться вам, чтобы еще чуть быстрее локализовать и восстановить работу пользовательского сервиса.
После того как вы утвердили с руководством все необходимые инвестиции в людей, сервисные контракты, оборудование и программное обеспечение, вы можете помимо времени поддержки согласовать также и предельные сроки восстановления пользовательских сервисов. Но чтобы гарантировать достижение этих сроков нужен еще один маленький штрих:
5. Объем выполняемых регламентных задач
Чтобы гарантировать восстановление в случае сбоев вы должны быть уверены, что при возникновении аварийной ситуации у вас будут все необходимые ресурсы для восстановления. Для этого необходимо постоянно контролировать их наличие и корректность. Обладая информацией о согласованных ранее резервах и ресурсах, вы можете составить точный перечень необходимых регламентных мероприятий, регулярное выполнение которых может потребовать привлечения дополнительных технических специалистов. Это необходимая плата за надежность, но, к сожалению, иногда даже она бесполезна:
6. Ситуации, выходящие за рамки SLA.
Есть ситуации, в которых сложно спрогнозировать сроки восстановление и которые выходят за рамки планирования. Это не только форс-мажорные ситуации, но еще и события с одновременным отказом двух и более элементов одного типа, возникновение которых допускает теория вероятности.
Зачастую не имеет экономического смысла готовить ИТ-инфраструктуру и ИТ-специалистов к оперативному устранению любых аварий. В некоторых случаях куда дешевле и эффективнее подготовить сам бизнес к действиям в случае их возникновения. К примеру, заготовить бланки накладных для ручного оформления товаров, на случай полного отказа компьютерных систем, или организовать строгий учет первичной документации, чтобы восстановить хозяйственный операции с момента последнего форс-мажорного резервного копирования базы не представляло сложностей. Возможные же технические меры, позволяющие уменьшить негативное влияние подобных ситуаций на бизнес, были описаны ранее.
На этом этап согласования можно считать завершенным — остались лишь мелкие формальности:
Закрепляем согласованные параметры и действуем
Результаты ваших переговоров с руководством стоит закрепить на бумаге, отразив в ней:
- Согласованное с бизнесом время поддержки пользовательских сервисов,
- Гарантируемые сроки восстановления их работы в случае сбоев,
- Деньги (включая сроки их выделения) и мероприятия, необходимые для достижения поставленных целей,
- Ситуации, выходящие за рамки планирования и перечень мероприятий, позволяющих уменьшить ущерб в случае их возникновения.
Закрепленные в документе договоренности позволят вам перейти из ситуации когда «ИТ-инфраструктура делает вид что работает, а бизнес делает вид что вкладывает в нее», к ситуации, когда бизнес понимает, на какой уровень сервиса он может рассчитывать в зависимости от инвестиций в ИТ.
На этом планирование аварийного восстановления можно считать успешно завершенным. Правда иногда, после оценки всех необходимых изменений и их стоимости, становится понятно, что дешевле в корне изменить существующую ИТ-инфраструктуру. Но это уже совсем другая история.
Успехов!
Автор: ikormachev
