Мы живем в эпоху КИИ, когда сбои в инфраструктурах все чаще становятся фатальными. В связи с этим выдвигаются повышенные требования к их сервисному обслуживанию. Рассмотрим особенности техподдержки КИИ, SLA и самые распространенные ошибки.
Ключевые отличия техподдержки КИИ
Поддержка критически важной инфраструктуры (КИИ) принципиально отличается от обслуживания стандартных ИТ-систем из-за сопутствующих рисков и повышенных требований к устойчивости. Любой простой в КИИ может привести к остановке ключевых сервисов бизнеса, поэтому и регламенты, и организация поддержки работают по другим правилам.
Основное ключевое отличие — SLA (service level agreement, контрактные обязательства перед клиентом). Для КИИ время реакции измеряется не часами, а минутами, фиксированное время восстановления тоже существенно жестче: самые распространенные интервалы — 4, 6 или 8 часов. При этом сроки реагирования зависят от класса инцидентов. Для событий первого уровня применяются самые жесткие параметры: реакция в течение
Второй важный момент — подготовка и наличие складов запасных компонентов. Чтобы выполнить восстановление за фиксированное время, запас оборудования должен быть заранее подобран под конкретную инфраструктуру и находиться недалеко от объекта. В обычной ИТ-среде, в отличие от КИИ, запчасти часто хранятся централизованно или закупаются по мере необходимости.
Третье отличие — сервисные окна и плановые работы. Любые операции, не относящиеся к аварийным, заранее согласуются и выполняются тогда, когда нагрузка на систему минимальна, обычно ночью или в выходные. Даже кратковременное отключение или снижение производительности в рабочие часы может привести к срыву процессов, поэтому календарь работ планируется значительно тщательнее, чем в обычных ИТ-средах.
Отличается также уровень экспертизы инженерной команды. Специалисты, обслуживающие КИИ, должны понимать специфику конкретного сегмента. Это диктует и набор процедур, и требования к квалификации, и порядок эскалаций. Наконец, в случае с КИИ проводится более жесткий контроль за всеми процедурами и изменения. Любые обновления, модификации, проходят через расширенные регламенты. Даже небольшие новшества тщательно проверяются на совместимость с действующей схемой. В обычных ИТ-системах многие операции выполняются быстрее и проще.
Иначе говоря, техподдержка КИИ — это особый режим работы, где важны скорость реакции, заранее подготовленная инфраструктура для восстановления, высшая степень предсказуемости и нулевая толерантность к ошибкам. Именно это определяет отличия в том числе в сервисных процедурах.
Отсюда вытекают и требования к поставщикам техподдержки. Они должны обладать всеми возможностями, чтобы закрыть все вышеперечисленные моменты. Это и экспертная команда, готовая работать по жестким SLA, и склады запчастей, расположенные вблизи объектов, и отработанная логистика, и обязательная — или как минимум крайне желательная — сертификация инженеров, подтверждающая их компетентность.
Выбор сервисной модели
Выбор модели техподдержки для КИИ зависит прежде всего от масштаба заказчика и характера его бизнеса. У крупных организаций и компаний обычно есть собственные команды. Но для компаний меньшего масштаба создание собственного сервисного центра может быть экономически неоправданным.
Во многих случаях рациональнее обращаться к внешнему сервисному провайдеру. У проверенных подрядчиков есть круглосуточный колл-центр, дежурные группы инженеров и экспертиза, позволяющая обеспечить качественный сервис, в том числе для КИИ. При этом уровень компетенций внешних команд, как правило, выше, чем может себе позволить компания второго эшелона, поскольку поставщики сервиса работают с большим количеством кейсов, регулярно обучают инженеров и поддерживают практику по разным видам оборудования.
Возможна и гибридная модель, когда часть задач решается локально, а часть — передается внешнему сервису. Например, заказчик может оставить у себя первую линию или дежурную смену, а специализированные работы, связанные с ремонтом, заменой оборудования, анализом сложных инцидентов или поддержкой узкоспециализированных систем, передать внешнему подрядчику. Такой подход позволяет снижать затраты и одновременно удерживать внутри важные компетенции.
Ошибки при техподдержке КИИ и как их избежать
Работа с критически важной инфраструктурой требует иного уровня ответственности, чем обслуживание обычных ИТ-систем. Каждая ошибка в проектировании, эксплуатации или поддержке оборачивается серьезными последствиями и крупными денежными потерями, не говоря о юридической ответственности. Вот самые распространенные просчеты, которые допускаются в организации техподдержки КИИ.
- Отсутствие избыточности. Дублирование ключевых узлов повышает стоимость проекта, но обеспечивает кратное увеличение надежности. Тем не менее многие заказчики предпочитают экономить и отказываются от резервирования. В результате критичные сервисы оказываются завязанными на одиночные компоненты, и выход из строя одного устройства приводит к простою или остановке работы.
- Неправильная оценка класса оборудования. В инфраструктуре заказчиков нередко встречаются приложения, размещенные на low-end системах, которые по уровню надежности не предназначены для такой нагрузки. Критически важная инфраструктура должна работать на системах среднего и высокого класса, где предусмотрены механизмы устойчивости, резервирования, «горячей» замены и встроенной защиты от сбоев. Ошибка в выборе оборудования часто становится самой дорогой, поскольку исправить ее «по ходу дела» невозможно.
- Невнимание к резервным копиям. Даже высоконадежная инфраструктура не исключает аппаратных сбоев, человеческого фактора или киберугроз. Многочисленные инциденты последних лет показывают, что без надежных резервных копий теряется возможность восстановить критически важные данные.
- Отсутствие дублирования каналов передачи данных. Надежность КИИ зависит не только от серверов и систем хранения, но и от сетевой инфраструктуры. Один канал связи или одна точка подключения превращают всю систему в уязвимую конструкцию, где сбой внешнего провайдера способен остановить процессы полностью.
- Недостаточная подготовка персонала. Даже самая надежная архитектура теряет смысл, если команда не обладает достаточной квалификацией или внутри компании отсутствуют регламентированные процессы. Важно, чтобы инженеры умели поддерживать систему ежедневно, регулярно проверяли состояние резервных копий, знали инструкции по восстановлению после аварий и могли действовать по четко прописанным сценариям.
И главное, о чем необходимо помнить — это баланс между надежностью и оправданностью с точки зрения бизнеса. Можно построить идеальную, максимально защищенную от сбоев инфраструктуру, но не исключено, что ее цена окажется неподъемной. Или, наоборот, другая крайность — неустойчивая система при максимальной экономии средств. Поэтому руководствоваться в первую очередь следует соотношением цены и качества.
Нельзя допускать пробелов в архитектуре, которые могут привести к отказу оборудования, но и чрезмерное усложнение системы без экономического обоснования также нельзя назвать правильным подходом. При риске отказов нужно провести оценку и выяснить, что потеряет компания, если критическая инфраструктура простаивает несколько часов. Если риск недопустим и потенциальные потери несравнимы со стоимостью оборудования, инфраструктуру необходимо усиливать — внедрять резервирование, настраивать полноценные резервные копии, заключать сервисные контракты с более жесткими SLA и минимизировать вероятность простоя.
