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