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

Резервный сервер, кластер и второй коммутатор ещё не гарантируют отказоустойчивость: бизнес-сервис всё равно может стать недоступным. Основной и запасной контуры нередко опираются на один и тот же узел — коммутатор, гипервизор, канал связи или систему хранения. 

Если смотреть на компоненты по отдельности, такие риски не видны. Для устранения сбоя инженеру приходится анализировать всю цепочку: от физического оборудования до приложений и бизнес-сервисов. Ниже разберём, как выявлять скрытые зависимости, оценивать последствия отказа и заранее просчитывать влияние плановых работ (impact analysis).

Материал будет полезен специалистам эксплуатации, инженерам инфраструктуры, архитекторам, SRE и ITSM-командам.

Что такое отказоустойчивость и почему одного резервирования мало

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

С ней часто путают высокую доступность (high availability). Разница в том, что здесь короткий перерыв является допустимым — главное восстановиться в сроки, заданные SLA.

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

Простой пример. Две виртуальные машины размещены на разных физических серверах. При этом обе подключены к одному коммутатору и пишут данные в одну СХД. Откажет общая инфраструктура — и основной, и резервный контуры станут недоступны одновременно.

Поэтому оценивают не отдельные компоненты, а цепочку целиком:

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

Какие скрытые зависимости создают риск отказа

Скрытая зависимость — связь, которую не видно ни в списке серверов, ни на схеме резервирования, хотя от неё зависит доступность сервиса. Чаще других встречаются четыре сценария.

1. Общая точка отказа

Несколько систем используют один инфраструктурный узел — единую точку отказа (SPOF, single point of failure). Пока он работает, архитектура выглядит отказоустойчивой. При его отказе одновременно затрагиваются несколько сервисов.

2. Зависимость резервного контура от основной инфраструктуры

Узлы кластера отказоустойчивости могут стоять на разных хостах, но работать через одну сеть или общую СХД. В итоге зарезервированы только вычислительные ресурсы, а цепочка доставки сервиса — нет.

3. Неочевидная зависимость приложения

На проверочный запрос приложение отвечает, а ключевую операцию выполнить не может: недоступна база данных, сетевой сервис, очередь или внешняя система.

4. Риск, который появляется после изменения

Перенос виртуальной машины, рестарт гипервизора, новая сетевая конфигурация — любое из этих действий способно задеть сервисы, которые на первый взгляд никак не касались изменяемого компонента.

Матрица проверки общей точки отказа

Почему одного мониторинга недостаточно для оценки влияния сбоя

Система мониторинга фиксирует метрики, доступность компонентов и технические события. Но по отдельным алертам не всегда понятно, относятся ли они к одной первопричине и какой бизнес-сервис оказался под угрозой.

Представим отказ сетевого оборудования. Мониторинг может зафиксировать недоступность коммутатора, нескольких серверов и приложений. Инженеру нужно быстро определить:

• какие события вызваны одной первопричиной;
• какой бизнес-сервис действительно пострадал;
• работает ли резервный контур;
• что восстанавливать в первую очередь;
• какие действия могут расширить зону отказа.

Если данные мониторинга, CMDB, сетевого сканера и инфраструктурных систем не связаны между собой, команда тратит время на восстановление контекста. Из-за этого растёт время восстановления сервиса — MTTR (Mean Time to Recovery).

При инциденте важно понять не только, что вышло из строя, но и каков радиус влияния. Для этого нужна актуальная карта зависимостей.

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

Что такое ресурсно-сервисная модель (РСМ)

Ресурсно-сервисная модель (РСМ) Artimate — это карта зависимостей ИТ-ландшафта, которая связывает технические ресурсы, приложения и бизнес-сервисы.

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

Модель не заменяет систему мониторинга, она хранит контекст, с которым внешняя система мониторинга или механизм корреляции (correlation engine) может сопоставить алерт, получить связанные объекты и определить потенциальное влияние на сервисы.

Для такой работы нужны три условия:

• объекты инфраструктуры представлены в модели;
• связи между ними актуальны и проверены;
• внешние идентификаторы — hostname, IP, ID хоста мониторинга или CMDB ID — корректно сопоставляются с объектами модели.

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

Как проверить отказоустойчивость с помощью карты зависимостей

Начать можно с двух сторон — от критичного сервиса или от конкретного компонента.

Проверка сверху вниз: от сервиса к ресурсам

1. Выберите критичный бизнес-сервис.
2. Составьте перечень приложений, баз данных и сетевых сервисов, без которых он не работает.
3. Для каждого из них найдите виртуальные машины и физические хосты.
4. Посмотрите, не сходятся ли эти объекты в один узел.

Проверка снизу вверх: от компонента к сервисам

1. Выберите сервер, VM, базу данных, СХД или сетевой компонент.
2. Постройте цепочку зависимых объектов.
3. Определите, какие бизнес-сервисы окажутся в зоне влияния.
4. Сравните влияние отказа с критичностью сервисов и владельцами.

Проверка с двух сторон помогает отделить отказ технического компонента от отказа бизнес-сервиса. Сервер может выйти из строя, а сервис — продолжить работу на резерве. Бывает и наоборот: небольшой сетевой компонент выводит из строя сразу несколько критичных систем.

Архитектурные риски удобно оценивать через системный анализ ИТ-инфраструктуры. Если сбой уже произошёл, пригодится расследование инцидентов и RCA.

Чек-лист проверки отказоустойчивости

Отказоустойчивость сервера и виртуализация

Проверьте:

• на каких физических хостах работают виртуальные машины;
• не используют ли основной и резервный экземпляры один гипервизор;
• подключены ли оба хоста к разным коммутаторам;
• какие общие СХД и каналы связи используют оба контура и какие отказы этих ресурсов способны нарушить работу сервиса; 
• какие приложения и бизнес-сервисы размещены на этих ресурсах.

Отказоустойчивость сети

Проверьте:

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

Отказоустойчивость данных и хранилища

Проверьте:

• где находятся основная база и реплика;
• не делят ли они одну систему хранения или площадку;
• независимы ли сетевые пути к данным;
• проверена ли процедура восстановления из резервной копии;
• какой бизнес-сервис зависит от конкретной базы или хранилища.

Карта зависимостей не заменяет проверку целостности копий и тест восстановления. Зато по ней видно, какие ресурсы и сервисы нужно включить в такую проверку.

Почему переключение на резерв не всегда восстанавливает сервис

Один из опасных сценариев — резервный контур использует ту же инфраструктуру, которая стала причиной отказа.

Например, основная и резервная виртуальные машины размещены на разных хостах, но подключены к одному коммутатору. Когда коммутатор откажет, переключение на резерв не вернёт доступность приложения.

Перед failover стоит проверить:

• есть ли у основного и резервного экземпляра общие сетевые зависимости;
• не используют ли они одну СХД, гипервизор или площадку;
• какие бизнес-сервисы зависят от обоих контуров;
• сохранится ли путь до пользователя или внешней системы.

Если эти объекты и связи внесены в модель, Artimate RSM помогает увидеть на графе, не сходятся ли оба контура в общий узел.

Как провести оценку влияния изменений перед плановыми работами

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

Для этого стоит ответить на три вопроса:

• от каких ресурсов зависит изменяемый компонент;
• какие приложения и бизнес-сервисы зависят от него;
• кого из команд и владельцев уведомить о работах.

Практический порядок:

1. Выбрать изменяемый ресурс.
2. Построить цепочку зависимостей вверх до бизнес-сервисов.
3. Проверить наличие резервного пути.
4. Определить критичность затрагиваемых сервисов.
5. Выбрать окно обслуживания и план восстановления.
6. После изменения обновить модель, если состав связей изменился.

Так модель работает не только при расследовании инцидентов, но и в процессах change management и планирования работ.

Как связать алерты с графом зависимостей

Построить карту инфраструктуры — только половина задачи. Её нужно связать с событиями мониторинга. В Artimate RSM для этого есть Correlation API.

В результате команда получает не просто технический алерт, а понимание того, что он значит для доступности сервисов.

Artimate RSM работает как дополнительный слой поверх существующего мониторинга, а не вместо него. Модель синхронизируется с Zabbix, Proxmox и Network Scanner, а через Correlation API к ней можно подключить любую внешнюю систему мониторинга. Собственный агент и отдельное хранилище временных рядов (TSDB) для этого не нужны. Поэтому внедрение ресурсно-сервисной модели можно рассматривать как развитие текущей системы управления инфраструктурой.

Как организовать поиск скрытых зависимостей: 7 шагов

1. Выделить критичные бизнес-сервисы. Зафиксировать сервисы, простой которых сильнее всего влияет на бизнес.
2. Описать связи. Связать сервисы с приложениями и инфраструктурой, на которой они работают.
3. Найти общие точки отказа. Проверить, от каких ресурсов зависит несколько критичных сервисов.
4. Сравнить пути. Найти общие сетевые, вычислительные, дисковые и площадочные ресурсы.
5. Связать модель с мониторингом. Настроить сопоставление hostname, IP и других идентификаторов с объектами модели.
6. Проверить сценарии отказа. Оценить impact и подтвердить отказоустойчивость контролируемыми тестами.
7. Поддерживать модель актуальной. Включить обновление связей в процессы изменений и синхронизации инфраструктурных источников.

Результат — не статичная схема, а рабочая модель, к которой обращаются во время инцидентов, перед изменениями и при развитии архитектуры.

Чем Artimate РСМ полезен для отказоустойчивости

Artimate RSM хранит единую модель ИТ-ландшафта и связывает технические объекты с бизнес-сервисами. Для отказоустойчивости это даёт:

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

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

Отказоустойчивость начинается с понимания зависимостей

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

РСМ Artimate помогает хранить эту цепочку в едином графе, связывать технические алерты с объектами инфраструктуры и оценивать потенциальное влияние отказа или планового изменения.

Хотите проверить, какие сервисы зависят от конкретного ресурса? Запросите демонстрацию Artimate RSM — команда покажет на примере, как строится граф зависимостей, определяется зона влияния и добавляется бизнес-контекст к техническому алерту.