/13269514/i_800.jpg)
Почти любой бизнес сегодня завязан на ИТ-сервисы. Через них проходят продажи, платежи, складские операции, работа сотрудников и взаимодействие с клиентами. Поэтому сбой в системе редко остается только технической проблемой. Если перестал работать сайт, CRM, платежный шлюз или складская программа, компания теряет деньги уже в первые минуты простоя. Но полную стоимость такого сбоя обычно никто не видит. У ИТ-службы есть сумма, потраченная на восстановление: работа инженеров, запчасти, лицензии, логистика. Финансовый департамент считает недополученную выручку и штрафы. Операционный блок фиксирует простой сотрудников и сдвинутые сроки. Коммерческий департамент сталкивается с претензиями клиентов и отмененными заказами.
Все подразделения видят последствия одного инцидента, но каждое считает только свою часть. Общая стоимость сбоя обычно нигде не собирается. Поэтому ИТ-директор знает сумму в счете подрядчика, но редко может ответить, сколько авария на самом деле стоила бизнесу. Дело не в недостатке компетенций. Цена простоя складывается за пределами ИТ-бюджета. Для ее расчета нужны данные из финансов, продаж, логистики, эксплуатации и клиентского сервиса. Пока компания не свела их в одну модель, она выбирает уровень поддержки почти вслепую.
Сколько на самом деле стоит шестичасовой сбой
Возьмем интернет-магазин с годовой выручкой 240 млн руб. Ее средняя выручка за календарный час составляет около 27 тыс. руб., однако продажи распределяются неравномерно. Если основная активность приходится на период с 10:00 до 22:00, стоимость рабочего часа приближается к 55-60 тыс. руб. Допустим, сайт перестал принимать заказы на шесть часов в субботу. В этом случае потеря выручки составит примерно 330-360 тыс. руб.
На этом расчет часто заканчивается, хотя это только самая заметная часть ущерба. Во время сбоя простаивают сотрудники офиса и склада, часть операций останавливается, часть выполняется вручную, часть переносится на следующие смены. Если инцидент затронул 10-15 человек, а полная стоимость их рабочего часа составляет 800-1000 руб., компания потеряет еще 50-90 тыс. руб.
Добавим штрафы, срочную доставку уже оплаченных заказов, претензии со стороны партнеров и маркетплейсов. В зависимости от модели бизнеса это еще 50-150 тыс. руб. Техническое восстановление тоже требует денег. Инженеры проводят диагностику, меняют компоненты, привлекают дополнительные ресурсы, заказывают срочную доставку оборудования. Допустим, подрядчик выставил счет на 100-120 тыс. руб.
После запуска сайта работа не заканчивается. Нужно проверить целостность данных и резервных копий, обработать накопившиеся заказы, перенести плановые работы, провести расследование и подготовить отчет. Эти расходы могут добавить еще 50-100 тыс. руб.
Таким образом, прямо измеримые потери уже достигают 600-800 тыс. руб. Если часть покупателей ушла к конкурентам, компания также теряет будущие покупки и деньги, которые ранее потратила на привлечение этих клиентов. С учетом отложенного эффекта полная стоимость шестичасового сбоя может приблизиться к 900 тыс. или даже 1,5 млн руб.
На этом фоне счет подрядчика в 100-120 тыс. руб. выглядит значимой, но далеко не главной статьей. Сокращение затрат на техническую поддержку на 20% даст экономию в несколько десятков тысяч рублей. Но лишний час простоя может стоить в несколько раз больше.
Почему реактивный сервис оказывается дорогим
Реактивная модель кажется экономной, пока ничего не ломается. Компания не оплачивает постоянную поддержку, не формирует запас критических компонентов и не тратит время на регламенты восстановления. После аварии она вызывает инженера и оплачивает выполненные работы. Цена такого подхода проявляется во время первого серьезного инцидента.
Сначала заявку принимает первая линия. Затем ее передают профильному инженеру, архитектору или производителю оборудования. После диагностики выясняется, что нужной детали нет на складе. Начинаются поиск поставщика, согласование закупки и срочная доставка. Каждое звено добавляет время, а вместе с ним растет стоимость простоя.
Отдельный риск связан с документацией и знаниями об инфраструктуре. Во многих компаниях критические сведения держатся в голове одного или двух сотрудников. Когда такой специалист недоступен, даже простая диагностика занимает больше времени. Инженеры заново восстанавливают схему системы, ищут актуальные пароли, проверяют зависимости между компонентами и выясняют, какие действия уже предпринимались.
После восстановления сервис снова работает, но данные об инциденте часто остаются в переписке или системе заявок. Компания не считает полную стоимость аварии, не анализирует время обнаружения и восстановления, не понимает, какой запас компонентов действительно нужен. Следующий сбой начинается с той же точки.
Базовый сервисный договор частично сокращает эти риски. У компании появляется понятный канал связи с подрядчиком, фиксированные ставки и согласованное время реакции. Но наличие договора само по себе не делает восстановление управляемым. Если нет рассчитанного ЗИП, сценариев эскалации и регламентов под конкретные бизнес-сервисы, модель остается реактивной.
Управляемый сервис строится иначе. Сначала компания определяет критичные процессы и допустимое время их остановки. Затем под эти требования формируются мониторинг, запас компонентов, схема дежурств, маршруты эскалации и регламенты восстановления. Инциденты разбираются с точки зрения потерь бизнеса, а не количества закрытых заявок.
Плановые затраты на такую поддержку выше, зато снижаются расходы на экстренную логистику, срочную закупку запчастей и длительный простой. В наших расчетных моделях переход от реактивного подхода к управляемому сервису может сократить совокупную стоимость владения системой за пять лет на 15-25%. Конкретный результат зависит от отрасли, критичности сервисов и исходного состояния инфраструктуры.
Экономика здесь довольно прямолинейна. Компания заранее покупает готовность к отказу вместо того, чтобы оплачивать аварию по максимальной ставке.
Как продлить жизнь EOSL-оборудования без постоянного аврала
Один из наших проектов был связан с поддержкой систем хранения данных в региональном медицинском ЦОДе. В инфраструктуре использовались EMC VNX5400, HPE 3PAR 8200 и HP P2000 G3. Вендорская поддержка этого оборудования закончилась, оригинальные запчасти стали дефицитными, а сроки поставки перестали быть предсказуемыми.
При этом системы продолжали работать круглосуточно и хранили медицинские данные. Контракт предусматривал жесткий SLA, включая реакцию на критический инцидент в течение 15 минут. За нарушение сроков заказчику грозили штрафы, а фиксированная цена государственного контракта не оставляла возможности увеличить бюджет после аварии.
Сразу заменить оборудование организация не могла. Финансирование модернизации еще не было утверждено, поэтому инфраструктура должна была проработать около двух лет.
Раньше запчасти закупали после отказа. При EOSL такой сценарий особенно опасен: нужный компонент приходится искать на вторичном рынке, цены зависят от наличия, а срок поставки может растянуться на недели. Даже правильно проведенная диагностика не помогает быстро восстановить систему, если замены нет поблизости.
Мы проанализировали состав оборудования, историю отказов и требования по времени восстановления. На этой основе сформировали запас критических компонентов, определили места их хранения, подготовили резервные каналы поставок и регламенты замены. Параллельно появилась дорожная карта вывода устаревших систем из эксплуатации.
За период сопровождения расходы сократились на 40% по сравнению с предыдущим периодом, нарушений SLA не было. Организация получила 18 месяцев для подготовки плановой замены оборудования. Сервис в этом проекте обеспечил непрерывность работы на время перехода, когда быстрая модернизация была невозможна.
SLA должен начинаться с бизнес-процесса
Компании часто выбирают параметры SLA по привычке. В договор попадает круглосуточный режим, реакция в течение часа или четырех часов, хотя никто не проверял, соответствует ли такой уровень поддержки реальным потерям. Из-за этого многие системы оказываются перестрахованы: компания оплачивает круглосуточную поддержку сервиса, который может без серьезных последствий подождать до следующего рабочего дня. Другие системы, напротив, получают слишком слабый SLA, хотя каждый час их простоя напрямую сокращает выручку или нарушает обязательства перед клиентами.
Начинать нужно с бизнес-сервиса. Формулировка «Поддержка системы оформления заказов» дает больше информации для расчета, чем «Поддержка сервера № 14». Один сервер может обслуживать несколько процессов разной критичности, а один процесс может зависеть от десятков инфраструктурных компонентов.
После определения сервисов бизнес присваивает им классы критичности. Для систем уровня Critical могут потребоваться доступность 99,95%, круглосуточная реакция в течение 15 минут и восстановление за два часа. Для High требования будут мягче: доступность 99,9%, реакция в течение часа и восстановление за четыре часа. Системам классов Medium и Low часто достаточно поддержки в рабочее время и восстановления на следующий рабочий день.
Это пример классификации, а не универсальный шаблон. Параметры зависят от цены простоя. Кассовая система ретейлера, производственная линия и внутренний портал сотрудников требуют разных уровней защиты, даже если используют похожее оборудование.
Отдельно нужно различать время реакции и время восстановления. Реакция означает, что инженер принял заявку и начал работу. Однако она ничего не говорит о том, когда сервис вернется в эксплуатацию. Resolution Time, RTO и RPO также описывают разные обязательства. Если стороны используют эти показатели как взаимозаменяемые, спор при первом же инциденте почти неизбежен.
Штрафы в SLA тоже должны отражать реальный риск. Условный 1% от месячной стоимости поддержки не меняет поведение подрядчика и не компенсирует ущерб, если простой критичного сервиса обходится компании в миллионы рублей. Размер санкций нужно соотносить с ожидаемыми потерями и зоной ответственности каждой стороны.
SLA следует пересматривать минимум раз в год. Бизнес запускает новые продукты, меняет каналы продаж, переносит процессы в другие системы. Сервис, который год назад был второстепенным, может стать критичным. Обратная ситуация тоже возможна: компания продолжает оплачивать жесткую поддержку системы, значение которой давно снизилось.
Что можно изменить уже на следующей неделе
Первый шаг состоит в расчете стоимости часа простоя для двух или трех ключевых сервисов. ИТ-служба не сможет сделать это одна. Понадобятся данные финансового департамента, владельцев процессов, продаж и операционного блока. В расчет должны войти выручка за час, стоимость труда затронутых сотрудников, штрафы, расходы на восстановление и последствия для клиентов. Даже приблизительная цифра полезнее полного отсутствия оценки. Она сразу показывает, где компания переплачивает за избыточный SLA, а где экономия на поддержке создает неприемлемый риск.
Второй шаг: разбор инцидентов за последний год. Считать нужно не общее количество заявок, а десять самых дорогих сбоев. По каждому стоит определить время обнаружения, передачи в работу, диагностики и восстановления. Такой анализ покажет, где возникает основная задержка: в мониторинге, маршруте эскалации, нехватке запчастей, документации или компетенциях команды.
Третий шаг: классификация сервисов по их влиянию на бизнес. После нее можно пересмотреть параметры SLA и сервисный бюджет. Круглосуточная поддержка останется там, где простой действительно дорог. Для менее критичных систем требования можно смягчить без заметного риска.
Пока цена простоя неизвестна, обсуждение сервиса сводится к тарифам подрядчика. После расчета полной стоимости инцидентов вопрос меняется. Руководство начинает выбирать, какие риски компания готова принять и сколько имеет смысл потратить на их сокращение. В этот момент ИТ-сервис перестает быть строкой расходов, которую каждый год пытаются уменьшить. Он становится управляемой частью экономики бизнеса.
Автор — Владимир Кудряшов, директор сервисного отдела компании «ГИГАНТ — Компьютерные системы»
