Современный бизнес зависит от доступности ИТ-систем практически на каждом этапе работы: от приёма заказов и расчётов до логистики и взаимодействия с клиентами. При этом даже распределённая инфраструктура и использование крупных облачных платформ не исключают масштабных сбоев.
Для руководителя главный вопрос заключается не в том, можно ли полностью избежать отказов, а в том, насколько компания готова продолжать работу и восстанавливаться после них. Как подготовиться к таким рискам и реагировать на них, порталу «Риск-менеджмент. Практика» рассказал генеральный директор DBI Михаил Сарычев.
Почему резервирование не гарантирует непрерывность
Компании инвестируют в резервные копии, несколько серверов и географически распределённую инфраструктуру, рассчитывая снизить вероятность простоя. Однако отдельные элементы защиты не всегда образуют работающую систему аварийного восстановления.
Резервная копия может оказаться неполной или непригодной для восстановления. Альтернативная площадка — не иметь необходимых вычислительных ресурсов. Запуск приложения может зависеть от базы данных, системы авторизации или интеграционного компонента, который остаётся недоступным.
Особую сложность представляют масштабные инциденты, когда множество компаний одновременно пытаются перенести системы или создать резервные среды. Доступность ресурсов может быть ограничена, а штатные сценарии переключения могут оказаться недоступны.
Следовательно, устойчивость определяется не количеством резервных компонентов, а способностью восстановить целостную бизнес-функцию в реальных условиях отказа.
Четыре составляющие устойчивости ИТ
Первая — мониторинг инфраструктуры. Мониторинг должен выявлять не только недоступность серверов, но и нарушения в работе бизнес-сервисов. Важно автоматически регистрировать инциденты, назначать ответственных и своевременно информировать заинтересованные стороны.
Вторая — подготовленные сценарии восстановления. Для критичных систем необходимо определить допустимое время простоя и объём данных, который компания готова потерять при аварии. Эти параметры должны определять требования к резервированию.
Третья — независимость резервных контуров. Резервные копии, площадки и необходимые компоненты должны быть защищены от общих факторов отказа. Следует учитывать не только физическую инфраструктуру, но и сетевые зависимости, средства управления доступом и внешние сервисы.
Четвёртая — готовность команды. В критической ситуации недостаточно иметь документацию. Специалисты должны понимать последовательность действий, зоны ответственности и порядок эскалации. Регулярные учения помогают обнаружить организационные проблемы до того, как они повлияют на реальный бизнес.
Open Source и коммерческие продукты: разные модели риска
Устойчивость инфраструктуры зависит и от программных продуктов, на которых она построена. При этом ни Open Source, ни коммерческое ПО не гарантируют отсутствия сбоев сами по себе.
Коммерческий продукт может предоставлять договорную техническую поддержку, регламентированные обновления и возможность эскалации критических инцидентов производителю. Однако наличие договора не означает, что любой сбой будет устранён в требуемый бизнесу срок: это зависит от условий поддержки, архитектуры решения и характера проблемы.
Open Source позволяет гибко управлять конфигурациями и адаптировать программное обеспечение. Но ответственность за интеграцию компонентов, обновления, проверку совместимости и организацию поддержки может в большей степени лежать на самой компании или её ИТ-партнёре.
Разница особенно заметна в зависимости от масштаба инфраструктуры. Для небольшой компании сопровождение открытого решения может быть относительно простым. В крупной корпоративной среде с сотнями систем и многочисленными интеграциями обновление одного компонента способно повлиять на совместимость других систем, а устранение проблемы потребовать участия нескольких инженерных команд.
В то же время крупная инфраструктура может эффективно работать на Open Source при наличии зрелых процессов эксплуатации, автоматизации и квалифицированных специалистов. А коммерческое ПО может оказаться источником значительных затрат или зависимости от одного поставщика.
При оценке рисков необходимо учитывать полную стоимость владения, доступность компетенций, сроки устранения критических проблем, жизненный цикл продукта и возможность продолжить работу при недоступности поддержки.
Для критичных систем важно заранее определить, кто отвечает за обновления и восстановление, какие обязательства закреплены договором и какие альтернативные сценарии доступны в случае отказа.
Собственная поддержка или аутсорсинг: что лучше для бизнеса
Отдельный фактор устойчивости — организация первой и второй линий технической поддержки. Даже надёжная инфраструктура не поможет быстро восстановить работу, если обращение долго ищет ответственного, проблема неправильно диагностирована или у специалистов нет доступа к актуальной документации.
Первая линия поддержки (L1) принимает и классифицирует обращения, фиксирует инциденты, выполняет первичную диагностику и решает типовые проблемы по установленным инструкциям. Вторая линия (L2) занимается более сложными техническими вопросами, анализирует причины неисправностей и восстанавливает работоспособность систем в пределах своей компетенции. При необходимости подключаются профильные инженеры третьей линии и разработчики.
Компании могут организовать поддержку собственными силами, передать её внешнему подрядчику или использовать комбинированную модель. У каждого подхода есть преимущества и ограничения.
Сильная сторона собственной команды — глубокое знание внутренней среды.
Штатные специалисты обычно хорошо понимают архитектуру систем, историю изменений, особенности бизнес-процессов и неочевидные зависимости. Это особенно важно для сложных корпоративных решений, которые годами развивались под специфические потребности компании.
Однако при нестандартном инциденте собственная команда может дольше искать решение, если ранее не сталкивалась с подобной проблемой или не располагает необходимой экспертизой по конкретной технологии. Кроме того, возможности внутренней команды ограничены её численностью и набором компетенций.
Преимущество аутсорсинга — широта практического опыта. Специалисты профильного подрядчика сталкиваются с различными архитектурами, конфигурациями и сценариями отказов у множества заказчиков. Такая насмотренность помогает быстрее выдвигать гипотезы, распознавать нетипичные проблемы и находить альтернативные способы восстановления.
При этом внешней команде необходимо предоставить актуальную документацию, доступы и сведения об архитектуре конкретного заказчика. Без этого даже высокая техническая квалификация не компенсирует недостаток контекста. Поэтому эффективный аутсорсинг не отменяет необходимости управлять знаниями о собственной инфраструктуре.
На практике часто оправдана гибридная модель: внутренняя команда отвечает за архитектурный контекст, приоритеты и взаимодействие с бизнесом, а внешний партнёр обеспечивает дополнительные компетенции, масштабируемость и поддержку в необходимом режиме.
ITSM и документация — основа управляемого восстановления
Независимо от модели поддержки, существенную роль играют ITSM-процессы (IT Service Management, управление ИТ-услугами) и специализированные системы управления ИТ-услугами. Они позволяют связать мониторинг, регистрацию инцидентов, назначение ответственных, эскалацию, контроль сроков и информирование заказчиков в единый процесс.
При этом сама по себе установка ITSM-системы не решает проблему. Необходимо определить правила классификации инцидентов, приоритеты, зоны ответственности и порядок взаимодействия между линиями поддержки и профильными инженерами.
Не менее важна документация. Для критичных систем должны быть доступны актуальные схемы архитектуры, зависимости между компонентами, инструкции по диагностике, сценарии переключения и процедуры восстановления. Документы необходимо обновлять после изменений инфраструктуры и проверять на практике.
В условиях серьёзного сбоя специалисты не должны тратить критически важное время на выяснение того, кто отвечает за систему, где находятся инструкции и какие действия допустимы. Эти вопросы должны быть решены заранее.
Что делать во время технологического сбоя
При масштабном инциденте важно не начинать хаотичное восстановление всех систем одновременно. Это может привести к конкуренции за ресурсы, дополнительным ошибкам и потере контроля над происходящим.
Сначала необходимо определить масштаб воздействия и выделить бизнес-функции, восстановление которых имеет наибольший приоритет. Затем следует проверить состояние данных и резервных ресурсов, определить доступные сценарии запуска и назначить ответственных за каждый этап.
Переключение на резервную площадку не всегда является оптимальным решением. Иногда безопаснее дождаться восстановления основного контура, иногда запустить часть функций на альтернативных ресурсах. Выбор зависит от критичности сервиса, состояния данных, технических ограничений и доступных мощностей.
Не менее важна коммуникация. Руководству и владельцам бизнес-процессов необходимо сообщать, какие системы затронуты, что уже сделано, какие ограничения сохраняются и когда будет следующая оценка ситуации. Если достоверный срок восстановления неизвестен, лучше прямо обозначить неопределённость, чем давать необоснованные обещания.
Опыт DBI показывает, что даже при серьёзных повреждениях инфраструктуры дата-центров профессиональная команда при наличии необходимых доступов, подготовленных сценариев и доступных ресурсов способна восстанавливать критичные системы крупнейших компаний страны за считаные часы, а в отдельных случаях за десятки минут. При этом сроки зависят от характера повреждений, архитектуры систем и доступности резервных мощностей.
Главный вывод: результат определяется не только техническими характеристиками инфраструктуры, но и готовностью людей, процессов и инструментов поддержки к работе в аварийной ситуации.
Post-mortem: восстановить систему недостаточно
После завершения инцидента необходимо провести детальный разбор — post-mortem. Его цель не в поиске виноватых, а в выявлении причин и условий, которые привели к сбою или увеличили время восстановления.
Следует проверить, соответствовали ли действительности архитектурные предположения, были ли актуальны инструкции, корректно ли работали конфигурации и хватило ли резервных ресурсов. Отдельно необходимо оценить скорость обнаружения проблемы, действия команды, качество коммуникации и эффективность принятых решений.
Масштабный инфраструктурный сбой невозможно заранее предусмотреть во всех деталях. Но его последствия можно уменьшить, если использовать полученный опыт для исправления документации, конфигураций и процессов.
Важно, чтобы каждый вывод превращался в конкретное действие с ответственным и сроком выполнения. Иначе post-mortem остаётся формальным отчётом, не повышающим устойчивость системы.
Как руководителю оценить готовность бизнеса
Для первичной оценки достаточно ответить на пять вопросов:
- Как долго компания может работать без каждой критичной ИТ-системы?
- Когда в последний раз проверялось восстановление из резервной копии?
- Можно ли запустить ключевые сервисы при недоступности основной площадки?
- Хватит ли альтернативных ресурсов, если сбой затронет несколько зон инфраструктуры?
- Есть ли у компании подготовленная команда, актуальная документация и отработанные процедуры реагирования?
Если ответы основаны на предположениях, а не на результатах испытаний, это самостоятельный риск, который необходимо устранить.
ИТ-устойчивость – это не разовый проект и не свойство выбранной облачной платформы. Это постоянная работа с архитектурой, программными продуктами, процессами и людьми.
Полностью исключить технологические сбои невозможно. Но можно заранее определить допустимые последствия, подготовить альтернативные решения и научиться действовать в условиях неопределённости. Именно это позволяет превратить устойчивость ИТ из технической характеристики в реальный инструмент защиты бизнеса.
