Какие сбои возвращаются по циклу: от интуиции к прогнозу
«Опять упал ночной обмен с базой. Кажется, уже было что-то такое, и до этого тоже...» В ИТ-поддержке часто возникает это чувство дежавю. Но доказать закономерность «на глаз» почти невозможно: между этими похожими событиями в журнале лежат сотни других, случайных заявок.
Задача
Если анализ по часам ищет жёсткую привязку к расписанию недели, то анализ циклов - это предиктивная аналитика. Метод ищет скрытый ритм инцидентов, которые возвращаются через равные промежутки времени или привязаны к календарю. Алгоритм автоматически сканирует журнал и отвечает на три вопроса:
- Какой сбой возвращается по циклу. Выявляет уязвимую систему и её шаг - раз в сколько дней или в какие именно дни месяца происходит поломка.
- Насколько это неслучайно. Считает, сколько раз инцидент совпал с вычисленным циклом, и сравнивает это с обычным фоновым ритмом системы, исключая случайные совпадения.
- Когда ждать следующую аварию. Рассчитывает дату ближайшего сбоя по циклу по принципу «если ничего не менять» - либо фиксирует, что цепь прервалась и причину уже устранили.
Как алгоритм ищет циклы
В основе метода лежит перебор гипотез и строгая проверка на случайность. Алгоритм не просто ищет всплески, а выявляет математически подтверждённый ритм для каждой конкретной ИТ-системы. Как это работает шаг за шагом:
- Изоляция систем и ночных сбоев. Журнал делится по системам (например, 1С, сайт, биллинг). Особое внимание алгоритм уделяет ночным сбоям (с 00:00 до 07:00). Ночью пользователи спят, поэтому всплеск заявок в это время - скорее всего след упавшего скрипта или задания.
- Перебор шагов. Система проверяет все возможные интервалы: раз в 2 дня, раз в 10 дней и так далее, охватывая периоды до четверти всей длины журнала. Отдельно проверяется привязка к конкретным датам (например, «последние три дня каждого месяца»).
- Исключение недель. Шаги в 7, 14 и 21 день здесь не ищутся. Их выявляет анализ по дням недели и часам, чтобы один и тот же инцидент не дублировался в отчётах.
- Защита от случайного шума. Чтобы стать «циклом», сбой должен попасть в ритм минимум 4 раза и заметно превышать обычный фон системы. Алгоритм сравнивает каждый подозрительный день с нормой. Горячий сезон или разовая череда аварий циклом не станут. Порог отсечения высокий: на случайных данных система просто промолчит, не выдавая ложных срабатываний.
- Прогноз следующей даты. Если математика подтверждает наличие активного цикла, алгоритм называет дату следующего ожидаемого инцидента по принципу «если ничего не менять».
- Контроль исправления. Если в последние три ожидаемых дня цикла сбоев не было, прогноз не строится. Отчёт фиксирует, что цикл прекратился - скорее всего, инженеры уже нашли и устранили причину.
Работа с реальными данными: что находит алгоритм
Журналы инцидентов всегда полны «шума». Метод ориентирован но то, чтобы не выдавать желаемое за действительное. На обычных журналах без закономерностей, даже с крупными разовыми авариями, система просто скажет: «Циклов нет».
- Как алгоритм обрабатывает особенности журналов
Сбои днём: найти дневной цикл сложнее - он тонет в естественном потоке заявок пользователей. Алгоритм подсветит его, только если сбой происходит почти в каждом цикле. Если ритм слабый, система предпочтёт промолчать.
Короткая история: если выгрузка охватывает менее 6 недель, алгоритм не будет искать циклы. Математике нужно минимум 4 повторения, чтобы отличить расписание от случайности.
Редкие события: одна заявка раз в месяц - это 12 точек за год среди тысяч других инцидентов. Для подтверждения такого цикла нужна история за несколько лет, на годовом срезе алгоритм сочтёт это случайностью.
Отсутствие времени: если журнал содержит только даты без часов и минут, анализ всё равно пройдёт, но без отдельной изоляции ночных сбоев.
Матрица решений: о чём говорит найденный цикл
| Характер цикла | Возможная причина | Действия команды |
|---|---|---|
| Каждые несколько дней, в один и тот же часнапример, раз в 10 дней в 03:00 | Автоматическое задание по расписанию: тяжёлый обмен, пересчёт, выгрузка данных | Проверить планировщик. Перенести задание на другое время, выделить больше ресурса или добавить скрипт проверки перед запуском |
| Каждые несколько дней, но в разное время | Эффект накопления: переполнение диска, утечка памяти, забитая очередь, нечищеный кэш или журнал. Ресурс исчерпывается за один и тот же период | Настроить мониторинг заполнения ресурса. Настроить автоматическую очистку или превентивный перезапуск службы по графику |
| Одни и те же дни месяцанапример, с 28-го по 30-е число | Закрытие финансового месяца, формирование регламентной отчётности, массовые выплаты | Согласовать календарь тяжёлых отчётов. Заранее выделить дополнительные мощности базы данных и поставить профильного дежурного на эти даты |
| Раз в 30, 60 или 90 дней | Срок действия: истечение SSL-сертификатов, ротация паролей, окончание лицензий или ключей доступа к API | Сверить даты выпуска и окончания. Внедрить контроль сроков или скрипты автопродления сертификатов |
Пример 1. Сбой скрипта с шагом в 10 дней
Ситуация: торговая сеть, около 1100 заявок в год. Ночной обмен 1С:ERP с сайтом периодически падает. Утром склад видит неотгруженные заказы, заявку закрывают вручную и забывают до следующего раза.
Что показал анализ: в 03:00 ночи 1С:ERP сбоит каждые 10 дней - сбой зафиксирован в 18 циклах из 37, а норма для этой системы - 2. Последний случай - 20 декабря, следующий день цикла - 9 января.
Результат: инженеры перестают тушить симптомы по утрам и идут в планировщик задач. Корректировка одного фонового процесса устраняет около 18 аварий в год и утренние простои склада.
Каждый кружок - день цикла: красный - в этот день система сбоила, пустой - день прошёл тихо. Штрихи - сбои в другие дни. Пустой красный кружок после конца выгрузки - следующий день по циклу, если ничего не менять.
Пример 2. Проблема закрытия месяца
Ситуация: бухгалтерия жалуется на зависания 1С в конце месяца. ИТ-служба считает проблему преувеличенной, не наблюдая явных подтверждений в общем потоке заявок.
Что показал анализ: в последние три дня месяца 1С:ERP сбоит в 11 месяцах из 12 - 18 сбойных дней против фоновой нормы в 6. Следующее окно риска - 29-31 января.
Результат: бесполезные споры сменяются точным расчётом. На даты закрытия месяца ИТ-отдел заранее выделяет дополнительные мощности сервера и назначает дежурного специалиста.
Итог: как применять эти данные в работе
Циклический сбой - это инцидент, который можно предсказать, а значит - предотвратить. Работа с алгоритмом поиска циклов даёт три практических результата:
- Целевые дежурстваИнженер назначается строго на даты цикла и проверяет здоровье системы накануне, а не разгребает завалы на следующее утро.
- Аргументация для руководства и техдолгаПовторяющийся сбой превращается в понятную строку в плане работ с прозрачной математикой: какая система страдает, сколько аварий происходит в год и какой эффект даст починка.
- Автоматическая проверка результатаМетод прозрачно показывает устранение проблемы: как только первопричина вычищена, отчёт фиксирует, что цикл прекратился («в последних циклах сбоя не было»).