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

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

Изображение: recraft

Команда AIOps-платформы Artimate опубликовала руководство по проверке отказоустойчивости ИТ-инфраструктуры. Авторы разбирают, почему задублированные системы иногда выходят из строя одновременно и как заметить такой риск до аварии.

Почему резерв не гарантирует отказоустойчивость

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

С точки зрения непрерывности бизнеса это опасный разрыв. Формально резерв есть, и в отчётах риск не отражается. Реальная отказоустойчивость сервиса проверяется только инцидентом.

Четыре скрытых риска для отказоустойчивости

В руководстве выделены типовые сценарии:

  • единая точка отказа, от которой зависят сразу несколько систем;
  • резервный контур, работающий на той же инфраструктуре, что и основной;
  • зависимость приложения от базы данных, очереди или внешнего сервиса, которую не выявляет проверка доступности;
  • изменения — миграции, обновления, перенастройка сети, — после которых связи становятся другими, а документация остаётся прежней.

Последний сценарий авторы связывают с плановыми работами. Когда их влияние оценивают по одному компоненту, без учёта цепочки до бизнес-сервиса, рутинная операция может закончиться инцидентом.

Как проверить отказоустойчивость: от сервиса к ресурсам и обратно

Проверку предлагают вести в двух направлениях. Первое — сверху вниз: от критичного бизнес-сервиса к приложениям, базам данных и физическим ресурсам. Так видно, в каких узлах сходятся цепочки разных сервисов. Второе — снизу вверх: от конкретного сервера, СХД или коммутатора к сервисам, которые пострадают при его отказе. На той же логике строится [оценка влияния изменений (impact analysis)] перед техническими работами.

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

Карта зависимостей как основа отказоустойчивости

Отдельный раздел посвящён ресурсно-сервисной модели (РСМ). Это граф, связывающий инфраструктуру с бизнес-сервисами. Artimate RSM синхронизируется с Zabbix, Proxmox и сетевым сканером, а к внешним системам мониторинга подключается через Correlation API. Поступивший алерт сопоставляется с объектом модели и получает контекст: какие сервисы затронуты, насколько они критичны, кто за них отвечает.

В результате дежурный инженер видит и отказавший узел, и остановившиеся из-за него сервисы. Решение о том, что восстанавливать первым, принимается быстрее.

«Резервирование часто проверяют по формальному признаку: второй экземпляр есть, значит, защита обеспечена. При этом отказ обычно приходит по связи, которой нет на схеме. Наша задача — показать такие связи заранее, пока они не стали причиной инцидента», — отмечает Никита Гладких, руководитель продукта Artimate.

Полная версия руководства с чек-листом проверки отказоустойчивости серверов, сети и хранилища опубликована в блоге Artimate: «Отказоустойчивость ИТ-инфраструктуры: как найти скрытые зависимости».

Artimate
Автор: Artimate
Artimate — интеллектуальная AIOps-платформа, которая выступает единым интерфейсом для всех данных ИТ-мониторинга. Платформа использует инструменты ML-анализа для корреляции событий событий из систем мониторинга, объединения инцидентов в единую картину, поиска первопричин и предотвращения сбоев до их влияния на бизнес-сервисы.
Комментарии:

Как мы обрабатываем данные: политика обработки персональных данных