Стало ли реально хуже после изменения
После релиза или миграции кажется, что сбоев стало больше. Коммерсанты жалуются. Технари не видят проблем (настоящий профессионал всегда найдёт способ объяснить, почему это не у него)) Откатывать? Или это пара неудачных дней и всё само рассосётся? В такой ситуации нужен даже не арбитр, а только цифры и факты.
Задача
Понять по журналу инцидентов, менялась ли частота сбоев за период: когда, насколько и какой тренд у нового уровня. «Кажется» - слабый аргумент. Несколько плохих дней подряд бывают и без причины, поэтому разницу необходимо отличить от обычного колебания.
Как это считается
Метод из семейства поиска отклонений - «где и что не так?».
- Автоматический поиск переломовАлгоритм сам перебирает всю историю и сравнивает средние показатели «до» и «после» каждого дня. Чтобы исключить случайности, он подстраивается под естественную нестабильность ваших данных: риск ошибочной «находки» - всего 3-5%.
- Определение характера измененийСистема называет не одну точку, а интервал дат, в котором произошёл сдвиг. Если произошёл резкий сбой, отчёт зафиксирует «ступеньку». Если аварийность нарастала медленно - постепенный рост.
- Изоляция временных всплесковАномалии длительностью от 5 дней, где сбоев стало в полтора раза больше, анализируются отдельно. Если после них всё вернулось в норму, алгоритм считает это разовым всплеском, а при наличии годовой истории сверяет с прошлым годом на предмет сезонности.
- Требования к даннымНужно только время создания всех заявок, и открытых, и закрытых. Поиск изменений запускается при истории от 4 недель, а на годовых данных алгоритм уверенно замечает устойчивые сдвиги от 20-25%.
Что метод видит и чего нет
Порог у этого метода тонкий: слишком низкий - и метод находит «ухудшения» в обычном шуме, слишком высокий - и пропускает настоящие. Поэтому каждую картину мы проверяли на 40-150 искусственных журналах с заранее известным ответом. Ниже - как часто метод прав.
| Что было в журнале | Что говорит отчёт |
|---|---|
| Резкий скачок сбоевнапример, сменили подрядчика | Скачок на треть найден во всех проверках. Отчёт называет окно дат, а не один день. Скачком его прямо называет в трёх случаях из десяти, в остальных пишет: «либо резкий скачок, либо постепенный рост - по данным не отличить». |
| Постепенный рост аварийностинапример, постоянно добавляются новые магазины | Рост на 30% за год найден в 8 случаях из 10. Внезапным скачком метод его не назвал ни разу. |
| Небольшой ростменьше чем на 20-25% | Тонет в обычных колебаниях от недели к неделе. Отчёт пишет, что сдвига не видно, и называет, от какого роста метод его заметил бы. |
| Временный всплеск и возврат в нормунапример, откатили неудачный релиз | Двухнедельный всплеск найден во всех проверках, даты - день в день. Основной прогноз строится по обычному уровню, а не по уровню всплеска. |
| Стабильный период без изменений | В 95 случаях из 100 отчёт пишет, что значимых сдвигов нет. Если сбои идут волнами, ложная находка бывает в 7 случаях из 100. |
| Стало хуже по длительности, а не по числусбоев столько же, но чинят дольше | Метод считает только число сбоев и такое ухудшение не видит. Куда смотреть - в строке «Изменений не видно» таблицы ниже. |
| Слишком мало данныхвыгрузка меньше чем за 4 недели | Поиск изменений не запускается: история слишком короткая, чтобы отличить случайность от реального сдвига. |
Почему система не всегда может отличить резкий скачок от плавного роста. В любой компании количество инцидентов от недели к неделе естественным образом колеблется, в среднем на 20-25%. Если аварийность выросла на треть, этот рост тонет в привычном фоновом «шуме». Поэтому точную дату поломки часто невозможно определить с точностью до дня: система выдаёт «окно дат», а о резком скачке говорит только тогда, когда он явно превышает обычную погрешность.
Картины и что с ними делать
Журнал заявок редко пишет, почему произошел сбой (поля «причина» часто нет, или пишется то, что было понятно смене, в начале). Поэтому отчёт распознает типичные математические сценарии и подсказывает, где искать корень проблемы и как реагировать.
| Сценарий | Возможные причины | Как проверить | Что делать |
|---|---|---|---|
| Резкий скачок (ступенька) | Выкатили крупное обновление, сменили подрядчика, резко выросло число точек продаж. Либо поменялись правила: система мониторинга начала сама создавать заявки. | Поднять историю изменений за эти даты и посмотреть авторов заявок: живые люди или роботы мониторинга. | Если бизнес вырос - усилить дежурную смену. Если виноват релиз или подрядчик - вернуть проблему инициаторам. Если заработал новый мониторинг - реального ухудшения нет, просто поменялись правила подсчёта. |
| Постепенный рост | Планомерный рост нагрузки, старение оборудования, накопление технического долга. | Сопоставить рост числа заявок с ростом числа пользователей или магазинов по месяцам. | Если заявок на одну точку столько же, сколько раньше, - это нормальная плата за масштабирование. Если больше - искать «бутылочное горлышко» в архитектуре или изношенное железо. |
| Временный всплеск с возвратом в норму | Неудачный релиз, который быстро откатили, авария у провайдера, внезапный наплыв клиентов из-за акции. | Изучить журнал обновлений и тексты заявок. Если тексты одинаковые - это не сотня разных поломок, а одна массовая авария. | Расследовать весь всплеск как единый инцидент: найти первопричину и разобрать, почему на восстановление ушло именно столько времени. |
| Подъём в самом конце графика | В первые недели невозможно определить, что это: короткий всплеск, сезонная нагрузка или новая, более высокая норма аварийности. | Сравнить с тем же периодом прошлого года и проверить недавние релизы. | Не паниковать. Базовый прогноз не меняется, но строится дополнительный сценарий «что, если это надолго». Окончательные выводы - через месяц, когда накопится статистика. |
| Изменений не видно | Частота поломок не превысила привычные колебания. | - | Если бизнесу всё равно «кажется, что стало хуже», причину недовольства нужно искать в другом месте. Скорее всего, сбоев больше не стало, но они стали дольше чиниться, стали более критичными для клиентов или бьют по одному и тому же больному сервису. |
Пример результата
Ситуация: торговая сеть с интернет-магазином. Система самостоятельно, без подсказанных дат, нашла аномалию в истории заявок.
В чём польза:
- Получили точные рамки для расследования: достаточно было проверить журнал релизов и изменений именно за эти две недели, чтобы найти причину.
- Прогноз на следующий месяц не искажается и строится по обычному уровню, около 3 сбоев в сутки: две плохие недели его почти не сдвигают.
- Если бы выгрузка оборвалась прямо посреди всплеска, система не стала бы делать поспешных выводов и честно предупредила бы, что пока неясно: короткий ли это сбой, сезонность или начало затяжного ухудшения.