Сколько ещё будет сбоев и когда следующий
Главный сервис снова лежал и все опять "стояли на ушах". Когда это закончится, толком никто сказать не может. Технари конечно что-то обещают, но после третьего раза им уже мало кто верит. Знакомо?
По этому поводу обычно появляются опасения, сколько ждать еще таких проблем и насколько вообще стабильна ситуация - не пора ли готовиться к проблемам большего масштаба.
Задача
Все проблемы эксплуатации без глубокого анализа так просто не найти, но можно вывести пару показателей, которые прояснят некоторые моменты:
- Сколько инцидентов ждать в ближайшую неделю или месяц. Под уже можно планировать дежурства, спринты и т.п.
- Насколько вероятен один, но «по-настоящему долгий» сбой. Готовить ли эскалацию и резерв заранее (что обычно выливается в целый бюджет), или это редкость, риск по которой дешевле не учитывать.
Как это считается
Два метода из семейства прогнозов - «что будет дальше?»
- Прогноз частоты событий (Пуассон)
Основа: в расчёт берётся текущая статистика частоты поломок.
Долгосрочные изменения: если системы стали падать чаще (или реже) и новый темп держится больше двух месяцев, прогноз строится только по новым данным, а старые отбрасываются.
Краткосрочные всплески: если частота сбоев изменилась совсем недавно, основной прогноз не меняется: за пару недель невозможно отличить случайность от стабильного ухудшения. Но дополнительно считается запасной сценарий: «что будет, если текущий всплеск станет нормой».
Нестабильность: если аварии происходят неравномерно (то ни одной, то сразу много), прогноз даёт более широкий разброс: не «будет ровно 5 сбоев», а «будет от 2 до 8».
Горизонт прогнозирования: нельзя предсказать будущее на долгий срок, если мало прошлых данных. Срок прогноза не длиннее собранной истории: есть данные за две недели - предсказываем только на неделю вперёд.
- Риск долгого простоя
Суть: оценить вероятность длительных отказов системы.
Обычная статистика: если нас интересует длительность сбоя, которая уже встречалась в прошлом, оценка строится простым подсчётом таких случаев в истории.
Беспрецедентные аварии: если нужно оценить риск аварии дольше всех прошлых рекордов, применяется специальная математическая модель для редких событий. Это теоретический расчёт, поэтому приводится диапазон вероятности, а не точное число случаев.
Фильтрация данных: простоем считаются только критические инциденты (приоритеты 1 и 2). Долго висящие несрочные заявки простоем не считаются: пока они ждут в очереди, сам сервис продолжает работать.
Результат: какая доля всех инцидентов превращается в по-настоящему долгий простой и сколько таких случаев ждать в месяц.
Что прогноз видит и чего нет
На основе уже выявленных паттернов и сценариев вот какие варианты уже выдает отчет:
| Что в журнале | Что пишет отчёт |
|---|---|
| Внезапные всплески аварийнапример, после релиза | Система не паникует и не завышает прогноз в разы. Основной расчёт идёт по старой норме, а для всплеска даётся отдельный сценарий «что будет, если это не прекратится». |
| Сезонные перегрузкинапример, декабрь | Прогноз на спокойный январь не строится по пиковому декабрю. Если есть данные за прошлый год, система распознаёт это как сезонность. |
| Неравномерные сбоито густо, то пусто | Если аварии идут волнами, система расширяет диапазон прогноза, чтобы учесть эту нестабильность, и отдельно показывает, насколько крупные разовые всплески портят картину. |
| Слишком мало данныхистория всего за 2 недели | Система отказывается гадать на месяц вперёд. Прогноз строится максимум на одну неделю, с объяснением причин. |
| Незакрытые инциденты | Учитываются в частоте поломок, но не участвуют в расчёте времени простоя: они ещё не починены. По ним выводится отдельная сводка: сколько их висит и есть ли среди них критичные. |
| Автозакрытие заявоксистема сама закрывает тикет через 3 дня | Анализатор распознаёт такие искусственные задержки и не считает их реальными долгими сбоями, чтобы не искажать статистику простоев. |
| Массовые чисткиразом закрыли 60 старых заявок | Система видит эту аномалию, указывает дату «чистки» и исключает эти тикеты из расчёта длительности аварий. |
| Учёт времени бюрократииесть только время формального закрытия | Если фиксируется только время закрытия заявки, а не реального восстановления сервиса, отчёт честно предупредит о погрешности и попросит в будущем указывать точную дату починки. |
Пример 1. Сколько сбоев ждать
Ситуация: интернет-магазин. Две недели назад выкатили неудачное обновление, количество ошибок резко выросло, откат не сделали.
Что покажет отчёт: в следующем месяце ожидается от 61 до 118 инцидентов, в среднем 88. Но если не исправить текущий всплеск (сейчас 10 сбоев в день вместо привычных 3), за месяц накопится больше 300 сбоев.
В чём польза: вы получаете реалистичный диапазон, а не ложно точную цифру. Нагрузку на техподдержку можно планировать под базовый уровень, не раздувая штат из-за временного всплеска. И при этом видна цена промедления, если неудачный релиз не починить прямо сейчас.
Пример 2. Риск долгого простоя
Ситуация: тот же интернет-магазин в нормальном режиме работы. Оцениваем риск того, что критичный сервис упадёт дольше чем на 6 часов.
Что покажет отчёт: 3% всех сбоев длятся больше 6 часов, в среднем это около 3 раз в месяц. Если брать только самые критичные аварии (высший приоритет), они затягиваются на 6+ часов примерно раз в два месяца.
В чём польза: становится ясно, что долгий простой - не абстрактная страшилка, а регулярное событие. Цифра 3% обманчива: это шанс для одного конкретного инцидента. В масштабах месяца долгая авария произойдёт почти наверняка. Значит, под неё нужен заранее утверждённый план: кто принимает решение о переходе на резерв и кто отвечает за связь с клиентами.
Как применять эти данные в работе
Понимание реальной частоты и длительности сбоев переводит управление ИТ из режима «тушения пожаров» в режим планирования:
- Дежурства и наймРесурсы распределяются под математически обоснованный прогноз, а не под эмоции от последней аварии. Понятно, когда нужен усиленный состав, а когда достаточно базовой поддержки.
- Обоснование ИТ-бюджетаРезервирование мощностей стоит дорого. Теперь на руках есть цифры, чтобы доказать бизнесу необходимость покупки «железа» - или, наоборот, показать, что риск крупного простоя ничтожен и тратить миллионы на резерв бессмысленно.
- Управление SLAВы перестаёте обещать клиентам и смежным отделам невыполнимую доступность в 99,99%, если отчёт показывает регулярные многочасовые просадки. Условия договоров корректируются под реальные возможности системы.