Alex.Morozov
New member
Когда-то я относился к простоям философски: «ну, полежало полчаса, зато потом всё работает». Так было, пока однажды в чёрную пятницу у нас не отвалился шлюз оплаты. Два часа и сорок минут мы смотрели на растущий график брошенных корзин, и вот тогда я впервые сел и посчитал, во что реально обходится каждая минута простоя. С тех пор у меня в голове живёт простая мысль: у сбоя есть не только техническая цена, но и вполне конкретная денежная, и её нужно знать до того, как он случится.
Считать я начал с самого очевидного — с упущенной выручки. Делим средний часовой оборот на шестьдесят минут и получаем ту сумму, которую каждая минута «съедает». У нас вышло около девяти тысяч рублей в минуту в пиковые дни, и эта цифра отрезвляет куда сильнее любых отчётов. Но это только верхушка айсберга: реальный убыток почти всегда больше.
Дальше идёт то, что бухгалтерия не любит считать. Когда сервис молчит, сотрудники не могут работать — и это оплаченное время, которое просто сгорает. У нас двенадцать человек в поддержке и разработке, час их вынужденного бездействия — это ещё несколько тысяч рублей. Добавьте сюда потерянные заказы, которые уже не вернуть, штрафы по SLA перед клиентами, переработки и ночные часы, если инцидент случился под вечер.
А ещё есть отложенный ущерб, который проявляется через недели. Часть клиентов, столкнувшихся с ошибкой, не пишет в поддержку — они просто уходят к конкурентам и не возвращаются. Я пробовал оценивать это через отток: если после крупного сбоя процент ушедших подрос хотя бы на десятый процента, за год это превращается в сумму, сравнимую с месячной выручкой. Вот почему считать только прямые потери — значит обманывать себя.
Отдельная история — репутация. В нашей сфере слухи о том, что сервис «лежит», расходятся быстрее, чем устраняется причина. Я видел, как один инцидент с полным падением на четыре часа закрыл нам доступ к крупному партнёру: переговоры просто поставили на паузу, а потом отложили на неопределённый срок. Такой убыток нельзя посчитать в таблице, но нельзя и игнорировать.
После этого я завёл привычку: у каждого критичного сервиса есть карточка, где указаны оборот в час, число задействованных людей и стоимость их простоя, а также оценочные обязательства по договорам. Умножаем одно на другое — и получаем ту сумму потерь, которая позволяет разговаривать с руководством на понятном языке. Когда ты приходишь и говоришь не «нужно больше железа», а «один час простоя стоит нам сотни тысяч, а резервирование — в десять раз меньше», решение принимается в разы быстрее.
Что бы я посоветовал читателям? Во-первых, честно посчитайте свою минуту простоя — хотя бы грубо. Во-вторых, ведите журнал инцидентов с фиксацией времени и последствий, чтобы цифры были не из головы. В-третьих, автоматизируйте всё, что можно: мониторинг, алерты, автоперезапуск, резервные каналы — иначе каждый сбой будет затягиваться из-за человеческого фактора. В-четвёртых, проверяйте восстановление на практике, а не на бумаге: учения раз в квартал экономят нервы и деньги в самый неподходящий момент. И наконец, договаривайтесь о плане действий заранее, пока паники нет.
Я честно признаюсь: подсчёт убытков сначала вгоняет в тоску. Но именно он превратил хаотичную борьбу с авариями в понятный проект с бюджетом и окупаемостью. Инциденты всё равно случались, но их становилось меньше, а простои — короче. А как у вас на форуме: кто-нибудь уже прикидывал, во сколько обходится минута простоя именно вашему проекту, и какие цифры получились?
Считать я начал с самого очевидного — с упущенной выручки. Делим средний часовой оборот на шестьдесят минут и получаем ту сумму, которую каждая минута «съедает». У нас вышло около девяти тысяч рублей в минуту в пиковые дни, и эта цифра отрезвляет куда сильнее любых отчётов. Но это только верхушка айсберга: реальный убыток почти всегда больше.
Дальше идёт то, что бухгалтерия не любит считать. Когда сервис молчит, сотрудники не могут работать — и это оплаченное время, которое просто сгорает. У нас двенадцать человек в поддержке и разработке, час их вынужденного бездействия — это ещё несколько тысяч рублей. Добавьте сюда потерянные заказы, которые уже не вернуть, штрафы по SLA перед клиентами, переработки и ночные часы, если инцидент случился под вечер.
А ещё есть отложенный ущерб, который проявляется через недели. Часть клиентов, столкнувшихся с ошибкой, не пишет в поддержку — они просто уходят к конкурентам и не возвращаются. Я пробовал оценивать это через отток: если после крупного сбоя процент ушедших подрос хотя бы на десятый процента, за год это превращается в сумму, сравнимую с месячной выручкой. Вот почему считать только прямые потери — значит обманывать себя.
Отдельная история — репутация. В нашей сфере слухи о том, что сервис «лежит», расходятся быстрее, чем устраняется причина. Я видел, как один инцидент с полным падением на четыре часа закрыл нам доступ к крупному партнёру: переговоры просто поставили на паузу, а потом отложили на неопределённый срок. Такой убыток нельзя посчитать в таблице, но нельзя и игнорировать.
После этого я завёл привычку: у каждого критичного сервиса есть карточка, где указаны оборот в час, число задействованных людей и стоимость их простоя, а также оценочные обязательства по договорам. Умножаем одно на другое — и получаем ту сумму потерь, которая позволяет разговаривать с руководством на понятном языке. Когда ты приходишь и говоришь не «нужно больше железа», а «один час простоя стоит нам сотни тысяч, а резервирование — в десять раз меньше», решение принимается в разы быстрее.
Что бы я посоветовал читателям? Во-первых, честно посчитайте свою минуту простоя — хотя бы грубо. Во-вторых, ведите журнал инцидентов с фиксацией времени и последствий, чтобы цифры были не из головы. В-третьих, автоматизируйте всё, что можно: мониторинг, алерты, автоперезапуск, резервные каналы — иначе каждый сбой будет затягиваться из-за человеческого фактора. В-четвёртых, проверяйте восстановление на практике, а не на бумаге: учения раз в квартал экономят нервы и деньги в самый неподходящий момент. И наконец, договаривайтесь о плане действий заранее, пока паники нет.
Я честно признаюсь: подсчёт убытков сначала вгоняет в тоску. Но именно он превратил хаотичную борьбу с авариями в понятный проект с бюджетом и окупаемостью. Инциденты всё равно случались, но их становилось меньше, а простои — короче. А как у вас на форуме: кто-нибудь уже прикидывал, во сколько обходится минута простоя именно вашему проекту, и какие цифры получились?