Доступность сервиса редко ломается «в один момент». Чаще это накапливающееся ухудшение: растёт время ответа, деградируют очереди, теряются ресурсы, возникают ошибки маршрутизации, нарушаются зависимости. Поэтому проверка доступности должна быть не разовой активностью, а регулярным процессом с чёткими метриками и ответственными.
Ниже — единый чек-лист, который можно использовать как для внутренней проверки перед запуском, так и для регулярного контроля. Он рассчитан на совместную работу бизнеса (цели, ожидания, договорённости) и IT (инфраструктура, мониторинг, тестирование, реагирование).
Сначала договоритесь, что именно считать доступностью
Проверять доступность без измеримых критериев — всё равно что лечить без диагноза. Начните с определения набора требований, которые можно проверить технически и согласовать с бизнесом.
Метрики: SLA и SLO, uptime, latencies и «сервисность»
Обычно используют несколько уровней:
- SLA (договорной уровень для клиента): процент доступности или иной целевой показатель, связанный с обязательствами и компенсациями.
- SLO (операционный уровень для команды): более узкий и управляемый показатель, например error budget.
- Uptime/Availability: доля времени, когда сервис доступен и корректно отвечает.
- Latency: время ответа и его хвосты, которые чаще всего портят пользовательский опыт даже при «формально рабочем» аптайме.
- Error rate: доля запросов с ошибками (HTTP 5xx, timeouts, отказ в зависимости).
Практический ориентир: определяйте доступность не только как «сайт открывается», а как «критичные пользовательские сценарии выполняются с нужным качеством». Например, авторизация может быть «доступна», но при росте таймаутов заказ не проходит — значит, доступность для бизнеса уже нарушена.
Критичные пользовательские сценарии и карта зависимостей
В чек-листе обязательно закрепите перечень сценариев, ради которых сервис существует:
- вход/регистрация
- поиск
- просмотр карточки товара/страницы
- создание заказа/заявки
- оплата или интеграция с платёжным провайдером
- уведомления (email/SMS/push)
- админские операции (если они критичны для управления сервисом)
Дальше нужна карта зависимостей: внешний API, платёжные шлюзы, базы данных, очереди, DNS, CDN, балансировщики, сервисы авторизации, системы мониторинга. Проверка доступности всегда упирается в то, что именно может сломаться и как это будет ощущаться пользователем.
RTO/RPO и режимы восстановления
Бизнесу важны сроки восстановления и потери данных:
- RTO (Recovery Time Objective): за какое время сервис вернётся в работоспособность.
- RPO (Recovery Point Objective): сколько данных можно потерять при восстановлении.
Если эти параметры не согласованы, команда будет «восстанавливать как получится», а бизнес не сможет принять осмысленное решение о рисках. В чек-лист включайте тесты на достижимость RTO/RPO, иначе договорённости останутся на бумаге.
Инвентаризация: что именно проверяем и где это находится
До запуска тестов соберите факты. Большинство провалов происходит не из-за отсутствия мониторинга, а из-за того, что команды не знают, какие экземпляры, регионы, версии и каналы трафика реально участвуют в работе сервиса.
Единый реестр сервисов и их владельцев
Сформируйте список:
- сервис (API, фронтенд, worker, cron)
- окружения (dev/stage/prod)
- регионы и кластера
- варианты развёртывания (blue/green, canary, multi-tenant)
- владельцы и контакты (on-call, дежурные, escalation)
Мини-ошибка, которая встречается постоянно: у сервиса есть «владелец», но нет назначенного ответственного за доступность. В итоге при инциденте непонятно, кто принимает решения по остановке, откату или масштабированию.
Инвентаризация сетевых путей и точек отказа
Проверьте:
- балансировщики и правила маршрутизации
- DNS (TTLs, кэширование, корректность записей)
- CDN (правила кэширования, bypass для динамики)
- TLS сертификаты и их продление
- прокси/ingress/egress политика
- сетевые политики в Kubernetes/VM
Отдельно стоит пройтись по «скрытым» точкам отказа: cron-задания, ренователи токенов, интеграции по расписанию, фоновые очистки очередей. Их часто забывают, а доступность сценариев ломается позже, чем ожидают.
Чек-лист проверки доступности на стороне IT: от архитектуры до эксплуатации
Ниже — практический список того, что нужно проверить технарям. Он подходит как для подготовки к релизу, так и для регулярных аудитов.
1) Устойчивость сервиса: отказ одного компонента не валит всё
Уточните, что в архитектуре предусмотрены механизмы отказоустойчивости:
- таймауты на внешние вызовы и устойчивые retry с backoff
- circuit breaker для зависимостей
- ограничение параллелизма и контроль очередей
- идемпотентность критичных операций (повторы не должны ломать данные)
- graceful degradation: часть функциональности может стать недоступной, но сценарий должен завершаться корректно, насколько это возможно
Типичная ошибка: попытки «лечить» недоступность бесконечными ретраями. Это увеличивает нагрузку на зависимость и ускоряет каскадный отказ.
2) Изоляция и отказоустойчивость инфраструктуры
Проверка должна включать:
- мультизонность/мультихостность для продовых компонентов
- репликация БД и понятная стратегия failover
- наличие резервных ресурсов под нагрузку инцидента (capacity headroom)
- автоматическое масштабирование и ограничения на него (чтобы не положить систему самим автоскейлом)
- устойчивость к частичным проблемам (например, сбой одной ноды не должен блокировать сервис)
Если у вас есть план обслуживания, убедитесь, что он не противоречит отказоустойчивости. Например, при отключении одной зоны сервис всё ещё должен обслуживать критичные сценарии в пределах SLO.
3) Бэкапы, DR и фактическая проверка восстановления
Наличие бэкапа не равно восстановлению. В чек-листе должны быть регулярные процедуры тестирования:
- восстановление тестовой точки во временную среду
- восстановление в прод/предпрод по сценарию с согласованными окнами
- проверка целостности данных после восстановления
- проверка времени восстановления компонентов, включая миграции/схемы
Типичная ошибка: бэкапы делаются регулярно, но не тестируются. В результате при реальной аварии выясняется, что формат данных несовместим, ключи утеряны или скорость восстановления не соответствует RTO.
4) Канареечные релизы и управление риском изменений
Доступность часто ломается не из-за инфраструктуры, а из-за изменения кода. Проверьте:
- canary/blue-green для критичных компонентов
- критерии остановки канареек (триггеры по error rate, latency p99, росту 5xx)
- откат до рабочей версии при ухудшении SLO
- миграции БД по безопасным паттернам (расщепление схемы и данных, backward compatibility)
Отдельно стоит согласовать, кто и по каким данным принимает решение остановить релиз. Если решение завязано на «ручные ощущения», команда потеряет минуты или часы.
Мониторинг и алертинг: проверяем не только факт «жив/мертв»
Чтобы проверка доступности была полезной, она должна предсказывать проблемы до того, как они станут публичными.
5) Логика алертов: что сработает и когда
Алерт должен отвечать на вопросы:
- что именно сломалось (какая зависимость, какой слой, какой endpoint/операция)
- каков масштаб (процент ошибок, рост задержек, деградация очереди)
- насколько это критично для сценариев бизнеса
- как быстро это обнаруживается (время от начала деградации до алерта)
Рекомендация для практики: избегайте алертов только на уровне «CPU 90%». Это симптом. Нужны алерты на признаки сценариев:
- рост rate 5xx и timeouts на эндпоинтах, которые критичны
- увеличение p95/p99 latency в пределах SLO
- рост длины очередей или старения сообщений (если есть queue-based обработка)
- ошибки доставки уведомлений (и отдельно — воронка, где именно теряются письма/события)
Типичная ошибка: слишком шумные алерты. Команда начинает игнорировать их, и в момент реального кризиса никто не реагирует.
6) Корреляция: связываем алерт с причиной и контекстом
В идеале алерт должен давать:
- ссылку на дашборд с трендами
- топ-метрики и последние релизы/конфигурационные изменения
- распределение ошибок по причинам (например, DNS failures, timeout to DB, auth errors)
- пример ошибок из логов с трассировкой (trace ID)
Чтобы это работало, продумайте единые идентификаторы и трассировку: correlation ID от входящего запроса до внешнего вызова. Тогда проверка доступности превращается в диагностику, а не в ручной поиск по графикам.
7) Доступность изнутри и снаружи: synthetic monitoring
Проверьте два режима:
- internal checks: быстрые health/readiness проверки из инфраструктуры
- external synthetic: имитация пользовательского сценария с внешних точек
Важно не путать:
- health endpoint (процесс жив)
- readiness (готовность принимать запросы)
- успешность сценария (бизнес-метрики: заказ создаётся, оплата проходит, уведомление отправляется)
В чек-лист включайте минимум один synthetic сценарий, который отражает реальный пользовательский путь. И обязательно прогоняйте его в разных регионах/доступных зонах, если у сервиса multi-region.
Периодическая проверка доступности: что делать еженедельно, ежемесячно и перед релизом
Разовая проверка перед запуском не заменяет регулярный контроль. Компоненты деградируют, конфиги меняются, зависимости «уезжают» по API или квотам.
Перед релизом: релизная проверка доступности
Минимальный набор:
- подтверждение готовности канареечного режима и критериев остановки
- проверка миграций и их backward compatibility
- прогон smoke-тестов критичных сценариев
- обновление/проверка документации по rollbacks
- убедиться, что алертинг покрывает изменившиеся точки (endpoints, очереди, интеграции)
И ещё один пункт, который часто пропускают: проверьте истечение сертификатов и конфигураций, если релиз меняет TLS/ключи. У недоступности есть «плавающий» характер, и релиз может совпасть с краем срока действия.
Еженедельно: контроль трендов и качества данных мониторинга
Проверьте:
- какие алерты чаще всего срабатывают без инцидентов (ложные срабатывания)
- есть ли «слепые зоны», где метрики не приходят (обрывы агента, ошибки интеграции)
- корректность каллибрации дашбордов и точность временных окон
- покрытие SLO метриками: всё ли, что важно бизнесу, измеряется
Если метрики приходят, но с задержкой или неверным временем, алерт может сработать поздно или с неверной интерпретацией.
Ежемесячно: нагрузочные и деградационные тесты
Включайте:
- нагрузочные тесты на критичные сценарии с целевой нагрузкой (и кратковременными пиками)
- тесты на отказ зависимости (например, симуляция медленного ответа внешнего API)
- проверка поведения при росте очередей и ограничениях
- тест failover и восстановление в рамках DR-планов
Деградационные тесты особенно важны. Сервис может быть формально доступен, но при задержках внешнего API ошибаться и «залипать» в retry. Тогда SLO окажется под угрозой.
Проверка доступности со стороны бизнеса: что нужно от IT и как управлять ожиданиями
Бизнесу важно не устройство кластера, а предсказуемость результатов. Поэтому сформируйте понятный механизм контроля.
Понимайте, какие сценарии и метрики отвечают за ценность
Оформите совместно:
- список критичных сценариев
- SLO по ним (availability и/или quality metrics)
- приоритеты: какие сбои допустимы, а какие считаются инцидентом уровня P1/P2
- влияние на доход/потери (даже на качественном уровне: «влияет на конверсию», «блокирует заказы»)
Если у бизнеса нет сценарного взгляда, IT будет отчитываться про «сервис доступен», а пользователи будут видеть проблемы в ключевом потоке.
Проверьте процесс коммуникации: что, когда и кем сообщается
Согласуйте:
- каналы связи (чат, почта, статус-страница, инцидент-страница)
- порядок эскалации при росте инцидента
- шаблон статуса: что сейчас, какой следующий шаг, ожидаемое время восстановления
- формат постмортема и сроки его публикации
Особенно полезно заранее зафиксировать ожидания по частоте обновлений: иногда отсутствие обновлений воспринимается как отсутствие прогресса, даже если команда работает.
Контроль качества отчётов: без «технического шума»
От IT ожидается не только первопричина, но и управленческая часть:
- какие меры предотвращения приняты
- какие изменения нужны в процессе релизов/мониторинга
- какие зависимости требуют контракта по доступности (например, внешние API)
Бизнес должен видеть, что следующий инцидент будет менее вероятным или менее болезненным.
Инциденты и постмортем: проверка доступности продолжается после восстановления
Доступность — это не только про «вернули работоспособность». Это про то, чтобы повторяемость проблем снижалась. Поэтому процесс после инцидента входит в чек-лист.
8) Плейбук реагирования и роли
Убедитесь, что есть:
- роли и зоны ответственности (incident commander, communications, tech lead)
- список типовых категорий инцидентов (сетевая недоступность, деградация БД, ошибки интеграции, массовые 5xx)
- пошаговые действия для каждой категории
- критерии «когда откатываемся» и «когда масштабируемся»
Если плейбук размытый, команда будет тратить первые 10–30 минут на уточнение вместо стабилизации.
9) RCA: разбор причин с фокусом на предотвращение
Хороший постмортем отвечает на вопросы:
- что произошло (факты и таймлайн)
- почему произошло (техническая причина, не обязательно единственная)
- почему не было обнаружено раньше (пробелы мониторинга/тестов/релизных процедур)
- что меняем, чтобы не повторилось (конкретные таски с владельцами и сроками)
Проверка доступности должна включать аудит качества постмортемов: есть ли в них измеримые действия или только описание ситуации.
Доступность для интеграций и микросервисов: где чаще всего «прячется» недоступность
Если у вас микросервисная архитектура, сервис может быть «жив», но пользовательские сценарии будут падать из-за цепочки зависимостей.
10) Contract testing и контроль версий API
Для интеграций проверьте:
- контрактное тестирование при изменениях API
- версии эндпоинтов и совместимость в период миграций
- поведение при частичных ответах (например, частично отсутствуют поля)
Если контракт нарушается, система может вести себя непредсказуемо: от падений до тихой деградации. Доступность тогда страдает без явных признаков «сервер умер».
11) Timeouts и лимиты на внешние вызовы
Убедитесь, что:
- везде стоят разумные таймауты
- retry не дублирует попытки внутри таймера (двойные повторы)
- есть лимиты на параллелизм
- результаты кэшируются там, где это оправдано
И снова, частая ошибка: отсутствует единый стандарт таймаутов и повторов. В итоге один сервис ждёт 60 секунд, другой 5, третий ретраит бесконечно — и пользователь чувствует простои, хотя каждый компонент «работает».
Точки контроля, которые стоит включить в любой чек-лист
Чтобы чек-лист был практичным, держите его компактным и проверяемым. Ниже пункты, которые почти всегда дают максимум эффекта.
- Сценарии бизнеса определены и привязаны к SLO/метрикам.
- Мониторинг покрывает не только здоровье процесса, но и качество сценария.
- Алерты настроены на ошибки и деградацию ключевых операций, а не на CPU «вообще».
- Таймауты, ретраи и circuit breaker применяются согласованно.
- Есть тесты восстановления DR, подтверждающие достижимость RTO/RPO.
- Канареечные релизы имеют критерии остановки и документированный rollback.
- Постмортем заканчивается конкретными изменениями с владельцами и сроками.
- Регулярные синтетические проверки имитируют реальные пути пользователя.
Если хотя бы два пункта не выполняются, доступность будет «случайной удачей», а не управляемым качеством.
Типичные ошибки при проверке доступности сервисов
Эти ошибки повторяются у разных команд. Их легче предотвратить заранее, чем потом исправлять после инцидента.
1. Проверяют только uptime, игнорируя latency и ошибочную обработку сценариев. Результат: формально всё «в зеленом», но пользователи не могут выполнять операции.
2. Алерты настроены на низкоуровневые симптомы без привязки к критичным сценариям. Команда тонет в шуме и теряет реакцию на важное.
3. Нет инвентаризации зависимостей и сценариев по регионам. Проблема всплывает на «неочевидной» зоне или версии.
4. DR существует на уровне процесса, но не подтверждается тестами восстановления. При аварии выясняется, что восстановление не укладывается в RTO.
5. Релизные проверки не включают критерии остановки и rollback для canary/feature flags. Команда опасается менять «на проде», а риск растёт.
6. Постмортемы превращаются в отчёт «что случилось», без плана предотвращения. Инциденты повторяются с разной статистикой, но одной причиной.
Как внедрить чек-лист в работу команды: план на 30–45 дней
Чек-лист полезен только тогда, когда он встраивается в процесс. Вот практичный план, который обычно занимает 30–45 дней.
1. Проведите совместную сессию бизнеса и IT и зафиксируйте критичные сценарии, SLO и категории инцидентов. На выходе должны быть измеримые критерии и список «что считается недоступностью».
2. Составьте инвентаризацию сервиса: зависимости, окружения, версии, регионы, владельцы. Цель — убрать «серые зоны», где непонятно, кто отвечает и что именно тестируется.
3. Аудит мониторинга: какие метрики и алерты есть, какие отсутствуют, какие ложные. Согласуйте правила алертов (что, когда и при каких порогах срабатывает).
4. Проведите синтетические проверки по ключевым сценариям и доведите их до стабильного качества (минимум ложных срабатываний).
5. Подготовьте и отработайте план DR/восстановления в тестовом режиме: не только бэкап, но и восстановление с проверкой целостности.
6. Запустите канареечный или хотя бы безопасный сценарий релиза для одного критичного компонента. Привяжите остановку к метрикам SLO.
7. После первых сбоев или тестовых инцидентов проведите постмортем по стандарту с внедрением конкретных задач.
Дальше цикл повторяется: раз в месяц улучшаете покрытие и устойчивость, раз в квартал — пересматриваете SLO и сценарии.
Заключение: проверка доступности — это управляемый цикл, а не разовая проверка
Если обобщить чек-лист, получается простая логика: сначала договоритесь о сценариях и измеримых SLO, затем проверьте, что мониторинг и алертинг действительно отражают качество сервиса, после этого убедитесь в устойчивости, восстановлении и безопасных релизах. И обязательно закрепите процесс инцидентов так, чтобы каждый раз вы не просто «чините», а снижаете вероятность повторения.
Возьмите ваш текущий процесс и отметьте, какие пункты закрыты, какие требуют доработки, а какие нужно внедрить в ближайший цикл. Начните с двух самых сильных точек: синтетика по критичным сценариям и тест восстановления DR. Эти меры быстро превращают «доступность на глаз» в проверяемый результат.