Диагностика инцидента: почему полезно идти от приложения вниз

Как связать пользовательский симптом с приложением, ОС, виртуализацией, сетью и хранилищем.

Когда пользователь сообщает, что «система тормозит», соблазнительно сразу проверить CPU гипервизора, дисковую latency и сеть. Эти данные полезны, но без привязки к конкретной операции легко потратить часы на показатели, не связанные с проблемой.

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

Сначала воспроизводимость

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

Затем приложение

Логи приложения, внутренние тайминги, ошибки, обращения к БД и внешним сервисам показывают, где было проведено время конкретной операции.

Если приложение видит длительный SQL-запрос, следующим шагом становится СУБД. Если оно долго ждёт файловую операцию, можно переходить к ОС и storage.

Ниже по стеку

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

Практический вывод

Диагностика «от приложения вниз» не означает, что проблема обязательно находится в приложении. Это способ сохранить причинно-следственную связь и не исследовать инфраструктуру вслепую.