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

1. Сначала определить влияние, затем искать причину

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

Такой подход защищает от распространённой ошибки: исследования самого заметного компонента вместо поиска элемента, который действительно отличает успешный запрос от неуспешного.

Полезные вопросы:

  • Проблема относится к одному пользователю, подсети, площадке или сервису?
  • Что продолжает работать?
  • Какие изменения происходили перед инцидентом?
  • Удаётся ли стабильно воспроизвести симптом?

2. Построить временную шкалу

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

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

3. Проследить путь транзакции

Проследите один проблемный запрос по всей среде. В зависимости от инцидента путь может включать клиент, DNS, коммутацию, маршрутизацию, межсетевой экран, VPN, службы идентификации, приложение, хранилище и внешнюю зависимость.

На каждой границе задавайте два вопроса:

  1. Доходит ли запрос до этой точки?
  2. Уходит ли из неё ожидаемый ответ?

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

4. Отделить факты от предположений

Ведите короткую рабочую запись из четырёх разделов:

  • Факты: непосредственно наблюдаемые события с отметками времени.
  • Гипотезы: возможные объяснения, которые ещё не доказаны.
  • Проверки: действия, способные подтвердить или опровергнуть гипотезу.
  • Изменения: выполненные вмешательства и их результат.

Это упрощает совместную диагностику и не позволяет ранней версии незаметно превратиться в «установленный факт».

5. Стабилизировать систему контролируемыми изменениями

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

Не объединяйте несколько независимых исправлений в одно действие. Если сервис восстановится, нужно понимать, какое изменение помогло. Если нет — должен сохраниться понятный путь возврата.

6. Завершить работу после восстановления

«Сервис восстановлен» — важный этап, но не конец работы. Подтвердите результат с точки зрения пользователя или бизнеса, проверьте побочные эффекты и зафиксируйте:

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

Хороший результат инцидента — не только работающий сервис. Это система, которую проще понимать, контролировать и поддерживать при следующих изменениях.