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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Успехов!

Автор: ikormachev

Источник