Отказоустойчивость ИТ-инфраструктуры: в Artimate описали, как искать скрытые зависимости

Изображение: recraft
Команда AIOps-платформы Artimate опубликовала руководство по проверке отказоустойчивости ИТ-инфраструктуры. Авторы разбирают, почему задублированные системы иногда выходят из строя одновременно и как заметить такой риск до аварии.
Почему резерв не гарантирует отказоустойчивость
Кластеры, реплики и резервные каналы закладывают в архитектуру на случай сбоя. Слабое место появляется, когда основной и резервный контуры используют общий ресурс: сетевой сегмент, систему хранения, площадку или инфраструктурный сервис. Пока этот ресурс исправен, архитектура выглядит надёжной. Если он откажет, переключаться будет некуда.
С точки зрения непрерывности бизнеса это опасный разрыв. Формально резерв есть, и в отчётах риск не отражается. Реальная отказоустойчивость сервиса проверяется только инцидентом.
Четыре скрытых риска для отказоустойчивости
В руководстве выделены типовые сценарии:
- единая точка отказа, от которой зависят сразу несколько систем;
- резервный контур, работающий на той же инфраструктуре, что и основной;
- зависимость приложения от базы данных, очереди или внешнего сервиса, которую не выявляет проверка доступности;
- изменения — миграции, обновления, перенастройка сети, — после которых связи становятся другими, а документация остаётся прежней.
Последний сценарий авторы связывают с плановыми работами. Когда их влияние оценивают по одному компоненту, без учёта цепочки до бизнес-сервиса, рутинная операция может закончиться инцидентом.
Как проверить отказоустойчивость: от сервиса к ресурсам и обратно
Проверку предлагают вести в двух направлениях. Первое — сверху вниз: от критичного бизнес-сервиса к приложениям, базам данных и физическим ресурсам. Так видно, в каких узлах сходятся цепочки разных сервисов. Второе — снизу вверх: от конкретного сервера, СХД или коммутатора к сервисам, которые пострадают при его отказе. На той же логике строится [оценка влияния изменений (impact analysis)] перед техническими работами.
В результате команда заранее знает зону влияния каждого компонента. Это позволяет выбрать окно обслуживания, подготовить резервный путь и предупредить владельцев сервисов.
Карта зависимостей как основа отказоустойчивости
Отдельный раздел посвящён ресурсно-сервисной модели (РСМ). Это граф, связывающий инфраструктуру с бизнес-сервисами. Artimate RSM синхронизируется с Zabbix, Proxmox и сетевым сканером, а к внешним системам мониторинга подключается через Correlation API. Поступивший алерт сопоставляется с объектом модели и получает контекст: какие сервисы затронуты, насколько они критичны, кто за них отвечает.
В результате дежурный инженер видит и отказавший узел, и остановившиеся из-за него сервисы. Решение о том, что восстанавливать первым, принимается быстрее.
«Резервирование часто проверяют по формальному признаку: второй экземпляр есть, значит, защита обеспечена. При этом отказ обычно приходит по связи, которой нет на схеме. Наша задача — показать такие связи заранее, пока они не стали причиной инцидента», — отмечает Никита Гладких, руководитель продукта Artimate.
Полная версия руководства с чек-листом проверки отказоустойчивости серверов, сети и хранилища опубликована в блоге Artimate: «Отказоустойчивость ИТ-инфраструктуры: как найти скрытые зависимости».



