2️⃣Второй акт: парадокс низкой утилизации как инцидент ➡️Истинная катастрофа производительности часто происходит при низких показателях CPU. ℹ️Это классические сценарии: 1. Блокировки (lock contention) или deadlock в приложении или СУБД: потоки выстроились в очередь, ожидая доступа к ресурсу. CPU простаивает, запросы таймаутятся, пользователи страдают, а метрика загрузки процессора спокойно показывает 15%. 2. Проблемы с внешними зависимостями (медленные API, сбойные микросервисы, лаговые диски): приложение проводит время в ожидании ответа, не нагружая CPU. 3. Проблемы планировщика ОС или JVM (для Java-приложений). ‼️В этих случаях мониторинг, зацикленный на утилизации, будет молчать, пока бизнес теряет деньги.😱 Это наглядно доказывает его нерелевантность как индикатора инцидента. ➡️От утилизации к производительности Ключевой сдвиг парадигмы заключается в отказе от метрик утилизации ресурсов в пользу метрик производительности и удовлетворенности пользователей. ‼️На первое место должны выходить: 1. Latency (задержка): P95, P99 времена ответа приложения. Рост задержек — это прямой сигнал о проблеме, независимо от того, как ведет себя CPU. 2. Throughput (пропускная способность): RPS (запросов в секунду), TPS (транзакций). Падение throughput при стабильной или растущей нагрузке — явный инцидент. 3. Rate of Errors: Процент ошибок (5xx, 4xx, таймауты). Это конечный результат многих проблем, которые CPU может и не заметить. 4. Saturation (насыщение): Длина очередей, количество ожидающих потоков. Это более точный показатель «перегруженности», чем утилизация CPU. Очередь на 1000 запросов — инцидент, даже если CPU загружен на 60%. ➡️Это — метрики бизнеса. Они отвечают на вопрос «Что чувствует пользователь?», а не «Как поживает наше железо?».☑️ ⚠️ Высокая утилизация CPU становится проблемой только тогда и только в том случае, когда она отрицательно коррелирует с этими ключевыми метриками: вызывает рост latency, падение throughput или увеличение ошибок.⚠️ ℹ️Заключение: от паники к аналитике ➡️Поэтому объявлять инцидент по факту превышения порога в 80-90% утилизации CPU — архаичная и опасная практика. Она ведет к «холиварам» между разработчиками и сисопами, бессмысленному масштабированию «вслепую» и игнорированию реальных, но тихих катастроф. ‼️Современный подход требует: 1️⃣·Деградировать «CPU Utilization» до вспомогательной, диагностической метрики. Ее место на информационных дашбордах, а не в правилах алертинга. 2️⃣Строить алерты на основе метрик производительности (Latency, Errors, Saturation). Это страхует от пропуска реальных инцидентов. 3️⃣Использовать утилизацию CPU в связке с другими данными (профилировщики, трейсинг, логи) для последующего анализа причин возникших проблем с производительностью. Высокая утилизация — не причина звонить в колокол, а повод взять в руки отладчик и профилировщик, когда проблема уже обнаружена другими средствами. ➡️Таким образом, переход от религии утилизации к культу производительности — это признак зрелости инженерной культуры. Это понимание, что цель инфраструктуры — не быть красивой и ненагруженной, а эффективно и предсказуемо обслуживать бизнес-логику. ‼️И судить о ее здоровье нужно по конечному результату, а не по абстрактной загруженности одной из ее многочисленных шестеренок.