Почему одни инциденты в Linux решают быстрее других
Инциденты с явным техническим сигналом — вроде CrashLoopBackOff в Kubernetes или кода 502 Bad Gateway — решают в 85-90% попыток. Абстрактная формулировка «приложение не запускается» даёт успех только в 42,6%. Такую разницу зафиксировал автор под ником verin_is: он собрал статистику 366 попыток восстановить сломанный Linux-сервис и опубликовал разбор на Хабре.
Краткий ответ
Из 366 инцидентов в учебном Linux-окружении сервис восстановили в 192 случаях — 52,5%. Разброс по типам большой: сценарии с конкретным сигналом в названии ошибки, CrashLoopBackOff и 502, решают в 85-90% случаев, а абстрактные формулировки без указания подсистемы, вроде «приложение не запускается» или OOM Killer, — в 40-43%. Выборка собрана на учебном стенде, а не в продакшене.
Что измеряли и где теряется половина попыток
Автор собирал статистику в учебном Linux-окружении: пользователь получает сервер со сломанным сервисом, открывает терминал в браузере и сам ищет причину — без заранее заданной последовательности команд. Можно смотреть журналы, процессы, сетевые соединения и конфигурацию, единственное условие — вернуть сервис в рабочее состояние.
Данные охватывают период с 10 октября по 8 ноября 2026 года: 775 запросов на запуск стенда, 752 подготовленных окружения, 366 взятых в работу инцидентов, 246 попыток с проверкой решения и 192 успешных. Медианное время успешного решения — 7 минут 49 секунд.
Самое заметное — разрыв в воронке. Из 366 принятых в работу инцидентов до проверки решения дошли только 246: 120 попыток закончились или были брошены раньше. Автор статистики честно признаёт, что причина неизвестна — возможно, люди изучали интерфейс, запускали стенд повторно или не поняли, с чего начать диагностику.
Зато среди тех 246 попыток, которые довели до проверки, успешными оказались 192 — около 78%. Это примерно в полтора раза выше базового показателя 52,5% по всей выборке.
Похожая картина знакома инженерам по дежурствам: довести расследование до конца обычно надёжнее, чем бросить его на полпути, хотя это наблюдение сделано на учебном стенде, а не на проде.
Какие инциденты оказались сложнее и почему
Разбивка по типам инцидентов показывает разброс от 40% до 90% успеха:
| Инцидент | Взяли в работу | Успешность |
|---|---|---|
| Kubernetes: CrashLoopBackOff | 10 | 90% |
| 502 Bad Gateway | 14 | 85,7% |
| Высокая нагрузка на CPU | 29 | 69% |
| База данных не отвечает | 53 | 49,1% |
| Too many open files | 14 | 42,9% |
| Приложение не запускается | 136 | 42,6% |
| OOM Killer убивает процессы | 30 | 40% |
CrashLoopBackOff — это уже инструкция: смотреть состояние пода, события в namespace и журналы контейнера. Код 502 Bad Gateway указывает на конкретное звено — связь прокси с upstream, порт или Unix-сокет, хотя медианное время успешного прохождения здесь выросло до 13 минут 57 секунд: высокий процент успеха не означает быстрое решение.
А формулировка «приложение не запускается» не называет подсистему вообще. Причина может быть в конфигурации, зависимостях, правах доступа или окружении запуска — диагност тратит первые минуты на то, чтобы понять, в какую сторону копать. Похожая картина с OOM Killer (40%) и Too many open files (42,9%): оба сценария требуют знания специфичных механизмов Linux, которые не видны из самого сообщения об ошибке — проверить journalctl -k при внезапном завершении процесса или посмотреть лимиты уже работающего процесса через cat /proc/<PID>/limits, а не ulimit -n в своей оболочке.
Что здесь спорно
Выборка по Kubernetes — всего 10 попыток, по 502 Bad Gateway — 14; на таких объёмах один-два случая меняют процент на 7-10 пунктов. Автор статистики сам отмечает: делать вывод «Kubernetes проще для диагностики, чем обычное приложение» было бы неверно — возможно, до сценариев с Kubernetes в принципе чаще доходят более подготовленные пользователи, и дело не в самой ошибке, а в составе выборки.
Окружение при этом учебное: люди решают заранее подготовленные сценарии без давления реального инцидента, SLA и эскалаций. Переносить проценты «как есть» на продакшен-метрики MTTR было бы некорректно. Ценность здесь не в абсолютных цифрах, а в структуре эффекта: явный сигнал в ошибке против абстрактной формулировки.
Что проверить в своей команде
Для платформенных и SRE-команд в этой статистике есть три практические зацепки.
Алертинг. Если алерт звучит как «сервис недоступен» без указания подсистемы, он работает примерно как сценарий «приложение не запускается» в этом исследовании — диагност тратит первые минуты на локализацию, а не на фикс. Алерты, которые сразу называют компонент и симптом — под в CrashLoopBackOff, 502 от конкретного upstream — сокращают этот путь.
Runbook. Для сценариев с низкой успешностью в статистике — OOM Killer, лимиты файловых дескрипторов, абстрактное «не запускается» — полезно заранее прописать первые команды диагностики: journalctl -k, проверку /proc/<PID>/limits, чеклист по переменным окружения и правам доступа.
Обучение новичков. Разбор показывает, что явные сигналы вроде CrashLoopBackOff и так хорошо описаны в документации Kubernetes, и новички разбирают их быстро. Слабое место — расследование без подсказок, когда ошибка не называет виновную подсистему. Такие сценарии стоит тренировать отдельно.
Статистика на 366 попытках небольшая, но она подтверждает наблюдение, знакомое инженерам по собственному опыту: чем точнее сигнал об ошибке, тем короче путь к восстановлению сервиса. Проверить стоит простое — сколько алертов и сообщений об ошибках в своей системе звучат как «приложение не запускается», и начать убирать абстрактность именно там.
FAQ
Что такое MTTR и как его посчитали в этом исследовании?
MTTR — среднее время восстановления сервиса после инцидента. В разборе на Хабре вместо среднего использовали медианное время успешного решения — 7 минут 49 секунд, посчитанное по 192 успешным попыткам из 366 взятых в работу.
Почему CrashLoopBackOff в Kubernetes решают лучше, чем «приложение не запускается»?
CrashLoopBackOff сразу указывает направление диагностики: состояние пода, события в namespace, журналы контейнера. Формулировка «приложение не запускается» не называет подсистему, и диагност тратит время на локализацию причины, а не на сам фикс.
Можно ли опираться на эту статистику для production-инцидентов?
Данные собраны в учебном Linux-окружении на выборке 366 попыток, часть категорий (Kubernetes, 502 Bad Gateway) представлена всего 10-14 случаями. Абсолютные проценты переносить на продакшен некорректно, но структуру эффекта — явный сигнал против абстрактной ошибки — стоит проверить на своих алертах.
Что делать с большим отсевом инцидентов до проверки решения?
Из 366 взятых инцидентов 120 не дошли даже до стадии проверки решения. Причина неизвестна из самих данных, но для production это повод проверить, не упирается ли дежурный в неочевидный первый шаг диагностики, и не нужен ли более явный стартовый чеклист в runbook.