Инцидент за рубли. Как мы научились считать настоящую цену сбоев

Привет! Это Антон Скутин, руководитель отдела обеспечения доступности ИТ-сервисов в “Петрович-Техе”. Сегодня хочу рассказать о том, как мы научились считать настоящую цену сбоев. В этой статье расскажу историю эволюции управления инцидентами в «Петрович-Техе» - от Excel-файла одного подразделения до системы метрик, которой пользуются и IT, и бизнес. Как это происходило, какие ошибки мы совершили и что из этого можно забрать себе.

Когда бизнес говорит: «У нас все тормозит, показатели падают, клиенты страдают», ИТ не должно доказывать, что «технически все нормально». Его задача - разобраться, какой сервис или цепочка сервисов мешает бизнес-процессу работать.

Проблема в том, что мониторинг может не показывать явной аварии, тогда как последствия уже заметны бизнесу: не проходят заказы, растет нагрузка на продающие подразделения, сотрудники дольше выполняют операции, а клиенты уходят.

В Петровиче мы давно стремимся оцифровывать бизнес-процессы и понимать их реальную стоимость. Со временем менялись масштаб компании, критичность цифровых сервисов и доступные инструменты, поэтому подход к оценке влияния инцидентов тоже развивался.

Отдельно фиксировать технические события было уже недостаточно: хотелось видеть, как сбои отражаются на клиентах, сотрудниках и ключевых бизнес-показателях.

За несколько лет мы прошли путь от хаотичного учета отдельных сбоев в Excel до системы, в которой влияние инцидентов выражается сначала в условных единицах, а затем и в рублях. При этом главным результатом оказалась не сама формула. Намного важнее было то, как вместе с метриками менялись процессы, приоритеты и отношения между ИТ и бизнесом.

От Excel к управленческой метрике. Как развивался подход

Наш подход не появился сразу в готовом виде. Мы развивали его постепенно - вместе с ростом зрелости процессов управления инцидентами, мониторинга и взаимодействия с бизнесом.

2020 год. Мы начали с базового учета: фиксировали количество и длительность инцидентов в Excel, собирали информацию из разных источников и вручную готовили сводки. 

[2021–2023 годы]. Мы унифицировали классификацию инцидентов и договорились о минимальном наборе данных для анализа: затронутые сервисы, длительность, масштаб воздействия, повторяемость, время восстановления. Это позволило перейти от разрозненной статистики к сопоставимым данным.

[2024–2025 годы]. Следующим шагом стала первая версия метрики влияния в рублях. Она была неидеальной и не претендовала на абсолютную точность, зато позволила обсуждать приоритеты, риски и инвестиции с бизнесом на общем языке.

[2025–2026 годы]. Мы развиваем модель дальше: уточняем веса, накапливаем исторические данные и связываем оценку ущерба с практиками управления надёжностью - SLO, error budget, incident review и планированием улучшений.

Главный вывод этого пути: зрелость здесь не в “идеальной формуле”. Она в способности регулярно улучшать модель, объяснять ее ограничения и использовать результаты при принятии решений.

С чего все начиналось

На старте у нас не было единого процесса управления инцидентами.

Одно из продающих подразделений заметило, что его KPI начали проседать. Чтобы объяснить ситуацию руководству, сотрудники завели собственный Excel-файл и начали фиксировать сбои, которые непосредственно мешали их работе.

В таблицу попадали, например, проблемы с 1С и Naumen - системами, которыми пользовался контакт-центр.

С точки зрения подразделения все было логично: если система мешает выполнять KPI, проблему нужно зафиксировать и показать руководству, но для компании в целом такая картина почти ничего не давала.

У каждого подразделения могла быть своя статистика, а единой картины не существовало. Мы не понимали, что происходит с другими бизнес-процессами, какие сбои действительно критичны для компании и куда в первую очередь направлять ресурсы.

В результате приоритизация во многом опиралась на экспертную оценку, срочность конкретной ситуации и доступный на тот момент контекст. Этого не всегда хватало, чтобы быстро и прозрачно сопоставить между собой влияние разных инцидентов на бизнес. 

В таких условиях командам приходилось тратить много времени на синхронизацию: уточнять масштаб влияния, сопоставлять техническую картину с последствиями для процессов и договариваться о приоритетах. Это замедляло принятие решений в момент, когда скорость особенно важна. 

Почему локального Excel оказалось недостаточно? Проблема была не в самом Excel. Для небольшого подразделения это вполне рабочий инструмент. Проблема заключалась в том, что он описывал только одну точку зрения.

У компании не было:

• общей картины по инцидентам;

• понятного распределения ответственности;

• прозрачной приоритизации;

• способа сравнить два разных сбоя;

Важно было не ограничиваться восстановлением сервиса, а использовать каждый значимый инцидент как источник улучшений: разбирать причины, фиксировать выводы и доводить профилактические меры до результата.

Первый шаг. Начать хотя бы что-то считать

На тот момент у нас не было отдельной команды, которая занималась бы надежностью и процессами управления инцидентами. Ресурсы были ограничены. Поэтому мы решили не пытаться сразу построить идеальную SRE-функцию и не начинать со сложных практик.

Первый шаг оказался гораздо проще: начать считать количество инцидентов и их продолжительность без попытки сразу оценить влияние на бизнес. Если система не работала - фиксировали. Если проблема продолжалась два часа - фиксировали два часа.

Цель была не в том, чтобы получить красивую статистику. Наоборот - нам нужно было увидеть реальную картину. Если она окажется плохой, значит, мы должны показать ее именно такой.

Создаем основу для оценки стоимости инцидентов 

Количество инцидентов + длительность, без попытки сразу оптимизировать все на свете.

Мы собирали статистику примерно полгода и увидели то, что ожидали: инцидентов было много, и они были долгими. Регулярно показывая эту статистику руководству IT и бизнесу, удалось сделать задачу приоритетной. Руководство сформулировало новую стратегическую цель: IT необходимо разобраться с надежностью систем.

Казалось бы, задача поставлена, но тут возникла следующая проблема - «Когда будет хорошо?» и «Сколько это стоит?». Как только мы показали руководству красную картину, появились вполне закономерные вопросы.

Для управления инцидентом нам нужно было быстро понимать:

• Что именно затронуто и каков масштаб проблемы?

• Как это влияет на ключевые бизнес-процессы и показатели?

• Как оценить последствия, чтобы обоснованно выбрать приоритет и дальнейшие меры?

У нас были количество инцидентов и их продолжительность. Но не было понимания, насколько один инцидент важнее другого и сколько компания теряет из-за каждого из них.

Последний вопрос тоже оказался полезным - «Почему вы раньше этого не делали?»

Потому что раньше бизнес ставил перед нами другую задачу: быстрее двигаться вперед и внедрять изменения. Теперь задача изменилась - нужно было одновременно научиться смотреть назад и понимать последствия уже произошедшего.

Шаг второй. Организуем восстановление сервисов

Когда стало понятно, что проблемы действительно есть, мы перешли к следующему этапу: научились хотя бы оперативно тушить пожары. Проблема была в том, что приоритетов все еще не существовало, если одновременно возникало несколько инцидентов, команда бросалась туда, где проблема казалась наиболее важной в данный момент. 

Только наиболее важной она часто становилась потому, что кто-то из бизнеса приходил и говорил: «У нас ключевое подразделение, нам нужно прямо сейчас», через полчаса приходило другое подразделение с тем же аргументом.

В результате команда металась между задачами, а приоритеты определялись эмоциями и административным влиянием и это создавало еще одну проблему - выгорание.

Рост цифрового ландшафта увеличивал нагрузку на команды, участвующие в восстановлении сервисов: наряду с плановой работой им требовалось оперативно подключаться к инцидентам. Мы увидели, что для устойчивости недостаточно рассчитывать на личную вовлеченность экспертов - нужны единые роли, прозрачная координация, автоматизация и накопление знаний.

Поэтому следующим шагом стало развитие процесса управления инцидентами и практик, которые помогают снижать трудозатраты на повторяющиеся ситуации.

Нам понадобился способ ответить на простой вопрос - «какой инцидент важнее другого?»

Метрика негативного влияния 1.0

Так появилась наша первая версия метрики негативного влияния. Изначально формула была очень простой:

Формула версии 1.0
NI = t × dt × scw, где:

• t - продолжительность инцидента;

• dt - тип недоступности;

• scw - важность сервиса для бизнеса.

Каждый показатель оценивался по шкале - здесь мы и совершили важную ошибку: все веса определили сами, без согласования с бизнесом. Мы решили за бизнес, какой сервис для него важнее, какой тип недоступности должен иметь больший вес и так далее. 

На тот момент казалось: мы технические специалисты, мы лучше знаем, как это посчитать. Оказалось - нет.

Почему даже простая формула оказалась полезной?  Возьмем два условных инцидента:

Инцидент №1 - Основная продающая система 1С полностью недоступна один час

• t = 1;

• dt = 10 - полная недоступность;

• scw = 10 - ключевой сервис для продаж.

Получаем: NI = 1 × 10 × 10 = 100

Инцидент №2 - Сервис начисления клиентских баллов не работает три часа

• t = 3;

• dt = 10;

• scw = 6.

Получаем: NI = 3 × 10 × 6 = 180

Формально второй инцидент оказывается «хуже», хотя за первый час падения 1С продажи полностью остановились. 

Это хороший пример того, почему метрику нельзя воспринимать как истину только потому, что она выглядит математически аккуратно, но даже такая несовершенная формула дала нам кое-что важное. Мы впервые получили возможность сравнивать инциденты между собой.

«Деревянные рубли»: метрика, которая работала внутри IT

Внутри IT система заработала, Мы могли сказать: «Этот инцидент получил такое влияние, а этот - другое».

Появился язык для приоритизации, теперь можно было объяснить, почему команда сначала занимается одной проблемой, а не другой.

Вместо: «Это P1» мы постепенно переходили к: «Это инцидент с таким-то уровнем влияния на бизнес». Мы называли получившиеся значения «деревянными рублями».

Это были не деньги. Это была условная шкала и некоторое время мы надеялись, что бизнес тоже начнет ею пользоваться, но этого не произошло.

Метрика 2.0. Добавляем бизнес-контекст

В следующей версии мы добавили несколько новых множителей, в частности:

• pop - влияние момента возникновения инцидента: пик продаж, обычное время, ночь, выходной;

• i - кого затронул инцидент: клиентов, сотрудников;

• s - масштаб воздействия;

• rp - повторяемость проблемы.

Получилась формула: NI = t × dt × scw × pop × i × s × rp

И здесь произошло важное изменение - мы начали учитывать не только то, что сломалось, но и в каком контексте это произошло.

Один час недоступности критичной продающей системы в пиковое время - совсем не то же самое, что три часа недоступности сервиса ночью, а повторный инцидент должен весить больше первого такого же сбоя. Если проблема уже возникала вчера и снова появилась сегодня, значит, мы недостаточно хорошо с ней разобрались.

От «тушить быстрее» к «не допускать повторения». Важный перелом

На первом этапе наша задача была простой - быстрее тушить пожары. Теперь появилась другая - сделать так, чтобы пожары не возникали снова.

Мы начали смотреть на повторяемость, проводить регулярные разборы критичных инцидентов и ставить задачи на предотвращение и стабилизацию. В том числе появился порог - если негативное влияние инцидента превышало определенное значение, его нужно было обязательно разбирать.

Например, договорились, что инциденты с влиянием выше 1000 требуют отдельного внимания, это дало командам понятные правила игры. Не каждый сбой означает, что нужно бросать все, но действительно значимые инциденты нельзя оставить без внимания.

Но одной метрики все равно оказалось мало, мы получили более точную модель влияния, однако появилась новая проблема - бизнес не воспринимал эти цифры как свои.Решение было очевидным: нужно переводить влияние в деньги.

Переходим от условных единиц к рублям

Сначала мы попытались сделать все идеально, хотелось учесть:

• недополученную выручку;

• простой сотрудников;

• репутационные потери;

• другие косвенные эффекты.

На бумаге это выглядело правильно, на практике мы несколько раз приходили к финансовому блоку, пытались собрать модель и каждый раз упирались в сложность расчетов и отсутствие необходимых данных.

Поэтому важно сразу оговориться: мы пока не считаем полную стоимость инцидента. Мы считаем его финансовое влияние через потенциально недополученную выручку.

В итоге пришлось отказаться от идеи идеальной модели. Мы выбрали более простой показатель - среднюю стоимость чека. И вместе с финансовым блоком встроили его в расчет.

И это оказалось гораздо полезнее.

При этом мы не стали отказываться от метрики негативного влияния, она хорошо работала внутри IT и уже стала частью процессов и KPI.

Поэтому мы оставили две метрики:

1. негативное влияние - для оперативной работы и IT;

2. финансовое влияние - для разговора с бизнесом.

Один инцидент - два языка

Возьмем те же два примера.

В первом случае:

• полная недоступность 1С;

• один час;

• пик продаж;

• проблема повторилась.

Негативное влияние - 20 000 условных единиц, финансовое влияние - около 3 млн рублей потенциальной недополученной выручки.

Во втором случае:

• сервис начисления баллов недоступен три часа;

• ночь;

• прямых потерь выручки нет.

Негативное влияние - 3 600, финансовое влияние - 0 рублей прямых потерь выручки.

И вот здесь разговор с бизнесом стал эффективнее. Не нужно долго объяснять, что такое 20 000 условных единиц. Можно сказать: «За час простоя продающей системы в пик продаж мы потенциально недополучили около 3 млн рублей».

Это уже понятный аргумент для обсуждения инвестиций.

Что изменилось после появления денег в отчетности?  

Изменилось не только содержание отчетов - изменилось поведение.

Бизнес начал видеть потери в рублях и понимать, зачем нужны инвестиции в стабильность. IT, в свою очередь, получила более сильный аргумент для обсуждения ресурсов, архитектурных изменений и capacity.

На этом фоне начали появляться отдельные направления, связанные с мониторингом и наблюдаемостью, единый центр компетенций, дежурные инженеры и ответственные за сервисы, т. е. метрика стала не просто способом считать инциденты - она стала инструментом принятия решений.

Метрики меняют культуру, однако, сами по себе цифры ничего не исправляют.

Если команда не доверяет метрикам, если разные подразделения используют разные правила и каждый раз спорят о приоритетах, новая формула просто добавляет еще один источник конфликтов.

Нам пришлось одновременно работать с культурой - мы договорились о порогах, правилах эскалации и регулярных разборах. Появились процессы, в которых метрики использовались постоянно, а не только во время отчетности.

В результате команды начали понимать, почему конкретный инцидент требует внимания, почему другой может подождать и почему после определенного сбоя нужно не только восстановить сервис, но и сделать так, чтобы он не повторился.

Инциденты → метрики → приоритезация → действия → снижение ущерба

Так появилась «управляемость» и прогнозируемость вместо хаоса.

Что в итоге изменилось в поведении бизнеса и IT? 

Бизнес начал понимать, что не все инциденты одинаково важны. Стало проще соглашаться на инвестиции, когда их можно связать с конкретными потерями.

IT получила возможность аргументировать приоритеты фактами, а не эмоциями, стало проще защищать технические решения в конфликтных ситуациях.

Инциденты как экосистема

К 2026 году мы перестали рассматривать управление инцидентами только как задачу “починить то, что сломалось”, скорее это замкнутый цикл:

Инцидент → метрика → приоритизация → действие → снижение ущерба → новые данные → следующая версия метрики. Именно здесь появляется управляемость.

Мы не просто быстрее восстанавливаем сервис, мы понимаем:

• какие инциденты наиболее болезненны;

• какие сервисы критичны;

• какие проблемы повторяются;

• где нужны инвестиции;

• какие действия действительно уменьшают ущерб.

Что бы я посоветовал тем, кто только начинает

Если бы нам пришлось повторить путь, который мы начали в 2020 году, я бы не пытался сразу построить идеальную модель. Начал бы с трех вещей.

1. Считайте хотя бы количество и длительность (даже если сначала это Excel). Важно получить общую картину и перестать спорить на уровне ощущений.

2. Введите простую метрику влияния, не ждите идеальной формулы - версия 1.0 с несколькими параметрами лучше, чем отсутствие любых данных. Но сразу договоритесь с бизнесом о том, что означает каждый вес.

3. Зафиксируйте правила игры - если метрика появилась, она должна использоваться регулярно. Нужно договориться:

• какой порог требует реакции;

• какие инциденты обязательно разбираются;

• кто принимает решение о приоритете;

• как результаты попадают в планирование.

И только после этого постепенно расширять модель.

Куда двигаться дальше? 

В 2026 году модель остается развивающейся. После нескольких итераций мы видим следующий шаг - связать ее с практиками SRE/DevOps: error budget, SLO, incident review и другими механизмами управления надежностью.

Отдельное направление - дальнейшая работа с финансовой моделью. Постепенно учитывать не только прямую недополученную выручку, но и косвенные эффекты. Это снова означает, что формула будет меняться и это нормально.

Главное, что мы поняли

1. Просто чинить инциденты недостаточно - нужно считать их влияние.

2. Необязательно начинать с идеальной модели. Даже грубая метрика может изменить поведение команд.

3. Формула будет эволюционировать. Версии 1.0 и 2.0 - нормальный путь, а не признак того, что предыдущая работа была бесполезной.

4. Деньги - универсальный язык для бизнеса. Переводя влияние инцидента в рубли, мы сильно упрощаем разговор об инвестициях.

5. Метрика без культуры не работает. Но и культура без цифр быстро превращается в споры о том, кто громче.

В конечном счете задача здесь не в том, чтобы придумать красивую формулу. Задача - сделать так, чтобы цифрам доверяли, ими пользовались и на их основе принимали решения.

И если после внедрения метрики ваши инциденты все еще стоят дорого, а бизнес по-прежнему не выделяет ресурсы на их устранение, возможно, проблема уже не в самих инцидентах. Возможно, ваша метрика пока еще недостаточно понятна бизнесу.

А как вы считаете стоимость инцидентов у себя? Есть ли у вас единая метрика влияния, как вы определяете приоритеты и удается ли переводить технические показатели в понятные для бизнеса деньги?

Буду рад обсудить ваш опыт в комментариях. Особенно интересно сравнить подходы и понять, какие модели действительно работают в разных компаниях.