Одного метода, который найдёт всё, нет: как мы складываем методы
Построили отчёт «топ-10 систем по простою», починили первую строчку, а аварии те же. Знакомо? Один отчёт отвечает на один вопрос. Где копится простой - да. Почему он копится, когда ждать следующего сбоя и не тянет ли одна поломка за собой другие - нет. Поэтому мы не ищем один «умный» метод, а складываем несколько простых, и в определённом порядке.
Главное за 30 секунд.
1. Каждый метод видит своё и слеп к остальному. Худшая система по простою может оказаться жертвой чужой аварии.
2. Сначала журнал чистят, потом считают. Ложные срабатывания, запросы и дубли меняют числа на треть.
3. Порядок важен: прогноз строится после поиска даты, с которой стало хуже, а список крупнейших аварий - после склейки дублей.
4. Итог - не набор цифр, а ответ: что чинить первым и почему.
Задача
Руководителю нужны ответы на несколько простых вопросов. На каждый отвечает свой метод:
- Где теряем больше всего времени? Какие системы и какие аварии дают основной простой.
- Как быстро чиним? Обычное время восстановления и как часто случаются долгие ремонты.
- Когда ломается? В какие часы и дни, и есть ли сбои, которые возвращаются по календарю.
- Стало ли хуже? С какой даты изменилась частота сбоев и чего ждать дальше.
- Почему? Какая поломка тянет за собой другие, какой сервер ломается снова и снова, какая метрика предупреждает заранее.
Схема 1. В каком порядке мы считаем
Каждый шаг стоит после того, от чего зависит. Переставить шаги - значит получить неверные числа.
- Одно название - одна система. Почему первым: если касса записана тремя способами («Касса», «КАССА», «касса » с пробелом), её простой делится на три части, и она выпадает из списка худших.
- Убрать то, что не сбой. Запросы на обслуживание («выдать доступ», «сбросить пароль») и записи «сбой не подтверждён». Почему до расчётов: в журнале аварий банка 210 из 802 записей оказались ложными срабатываниями. С ними медиана ремонта - 14 минут, без них - 21,5. Ремонт выглядел на треть быстрее, чем он есть.
- Убрать служебные закрытия. Заявки, которые закрыл таймер через трое суток или разом закрыли при разборе очереди. Почему: иначе отчёт напишет «VPN - 3066 дней простоя», хотя VPN работал.
- Склеить одну аварию из многих заявок. Авария канала связи в магазине открывает заявки по кассам, Wi-Fi и оплате. Почему до списка крупнейших аварий: иначе одна авария займёт в нём три места, а настоящая вторая по размеру выпадет.
- Базовые числа. Сколько сбоев, как быстро чиним, где копится простой.
- Когда: сначала неделя, потом циклы. Почему так: недельный ритм («каждый четверг ночью») уже найден. Поиск циклов его не повторяет и ищет то, что неделя не объясняет: «раз в 10 дней», «в конце месяца».
- Сначала дата, с которой стало хуже, потом прогноз. Почему так: если с августа сбоев стало вдвое больше, прогноз по среднему за год занизит их число. Если новый уровень держится дольше двух месяцев, прогноз строится только по нему.
- Почему: связи, повторы на объекте, метрика перед сбоем. Почему последними: им нужен чистый журнал и уже склеенные аварии. Иначе дубль заявки выглядел бы как «повтор через 2 минуты».
Схема 2. Кто чего не видит и кто это закрывает
У каждого метода есть слепая зона. Мы ставим рядом метод, который её закрывает.
| Метод | Что видит | Чего не видит | Кто закрывает |
|---|---|---|---|
| Где копится простой | Какие системы и аварии дают основной простой | Что система может страдать от чужой аварии | Связи между сбоями |
| Время восстановления | Обычный ремонт и долгие случаи | Какие именно аварии тянут среднее вверх | Где копится простой (список крупнейших аварий) |
| Часы и дни недели | Ночные задания, нагрузку рабочего дня | Ритм не в неделю: «раз в 10 дней», «конец месяца» | Циклы |
| Циклы | Сбой, который возвращается по календарю | Разовую перемену: «с августа стало хуже» | Дата смены частоты |
| Дата смены частоты | С какого дня сбоев стало больше или меньше | Причину перемены | Вы: сверяете дату со своими работами |
| Связи между сбоями | Какая поломка за минуты тянет за собой другие | Медленное ухудшение за часы до сбоя | Метрика перед сбоем (нужна выгрузка метрик) |
| Повторы на объекте | Сервер или магазин, который ломается снова и снова | Что беда во всей системе, а не в одном объекте | Сравнение со случаем: те же сбои, розданные объектам наугад |
| Прогноз | Сколько сбоев ждать и как часто будет долгий простой | Новые причины, которых ещё не было в журнале | Повтор разбора раз в квартал |
Пример. Худшая система - не всегда виновник
Ситуация: торговая сеть с интернет-магазином, год работы, около 1100 заявок по 12 системам. Руководство спрашивает, что чинить первым.
Один метод (где копится простой): Wi-Fi в магазинах - 23% простоя, кассы - 16%, каналы связи магазинов - только третьи, 10%. Вывод «меняем Wi-Fi» напрашивается сам.
Второй метод (связи): после аварии канала связи в течение 15 минут открываются заявки по кассам (10 раз за год, случайно ждали бы меньше одного), по Wi-Fi (9 раз) и по оплате (8 раз). Канал - источник, который в рейтинге простоя выглядит скромно.
Остальные методы: необычных часов нет, циклов нет, частота за год не изменилась (около 3 сбоев в день). Значит, дело не в расписании и не в недавнем изменении.
В чём польза: Wi-Fi остаётся худшим и сам по себе, его надо разбирать. Но резервный канал в магазинах снимет часть сбоев сразу трёх систем. Без второго метода эту часть простоя списали бы на кассы, Wi-Fi и оплату по отдельности.
Как применять это в работе
- Не чинить по одному рейтингуПрежде чем вкладываться в худшую систему, проверьте, не страдает ли она от чужих аварий. Иначе деньги уйдут на следствие.
- Сначала навести порядок в журналеЛожные срабатывания, запросы и дубли искажают любое число. Отметка «сбой не подтверждён» и тип заявки в выгрузке экономят часы споров.
- Смотреть на ответ, а не на набор цифрХороший разбор заканчивается фразой «чинить первым вот это, потому что…». Если отчёт даёт десять показателей и ни одного такого вывода, методы в нём не сложены.