Продолжаем серию публикаций об услуге Managed IT. В этом посте расскажем как провайдеры managed services рассчитывают параметры SLA (Service Level Agreement) — соглашения об уровне обслуживания.
Вопрос не праздный. SLA — ключевая ценность для клиента. Это, конечно, не кредитный договор, который нужно изучать с лупой, задавая уточняющие вопросы по каждому пункту. Но все же тут есть где развернуться недобросовестному поставщику, при недостаточной внимательности клиента.
Магические девятки
В SLA прописываются детальные характеристики услуги, права и обязанности заказчика и поставщика, время простоя, время реакции и, главное, — уровень доступности сервиса. За количественную характеристику SLA обычно принимают как раз последний пункт — уровень доступности за установленный период с указанным уровнем обслуживания.
Доступность сервиса считается в процентах; за период расчета берется, как правило, месяц. Стандарт на рынке — 99,9% — подразумевает, что суммарное время простоя сервиса не будет превышать 43 минут в месяц; SLA равный 99,5% — это уже 3 часа 40 минут простоя.
Любой бизнес должен понимать стоимость простоя ключевых элементов своей ИТ-инфраструктуры — только так можно определить экономический смысл SLA для конкретного сервиса.
От простого к сложному
Размер убытка от неработоспособности сервиса напрямую зависит от его сложности. Возьмем для сравнения систему биллинга в банке, которая обрабатывает миллион транзакций в месяц, и высоконагруженный интернет-магазин. Очевидно, что стоимость часового простоя у них будет сильно отличаться, и обеспечение одного и того же уровня SLA для банка требует совсем другого подхода, чем обеспечение того же SLA для ритейлера. Соответственно, стоимость услуги на SLA для банка будет выше.
Однако простотой, или сложностью, сервиса убытки не всегда ограничиваются. К примеру, тот же интернет-магазин решил запустить распродажу в «черную пятницу». Для этого он предварительно потратился на рекламную компанию. Однако сразу же после старта распродажи веб-сервер поставщика падает и не поднимается всю ночь. К стоимости простоя сайта — в виде побочных убытков — прибавляются рекламные расходы, отток клиентов, снижение репутации бренда. То есть непрямые потери — еще один пункт, который должен держать в уме клиент при расчете SLA.
Убытки, впрочем, понятие обоюдоострое. SLA включает в себя финансовую ответственность и для поставщика. В случае простоя, выходящего за рамки соглашения, провайдер managed services (MSP) обязан выплатить компенсацию. Понятно, что сумма не сравнима с клиентскими убытками, но, тем не менее, для MSP это тоже чувствительная статья расходов: компенсации за нарушение SLA доходят до 20% от стоимости услуги.
Фокусы с цифрами
Клиенту нужно четко понимать, на что именно дает SLA поставщик. Возьмем пример того же интернет-магазина. Можно давать детальный SLA на работоспособность всего сервиса, и тогда фактическая доступность будет включать в себя массу параметров: кнопка «купить», скрипт обработки заказов, HTTPS-сертификат и т. д. Но можно давать SLA только на то, что будет доступен сайт: веб-сервер работает, сайт отдает страничку — всё ок. Но вряд ли это тот SLA, который хотел бы купить клиент.
Один из параметров SLA, на котором, бывает, спекулируют, — согласованное время поддержки (СВП). Маркетинговые материалы часто обещают СВП на уровне «24×7», умалчивая, что на самом деле здесь подразумевается согласованное время работоспособности, т. е. время, когда сервис должен нормально функционировать. В реальности СВП обычно составляет «8×5», т. е. поддержка в режиме «10:00 — 18:00, Пн-Пт». Но это не значит, что если сервис упадет ночью или в выходной, клиент останется наедине со своими проблемами. Потому что ключевой показатель SLA — фактическая доступность. Поставщик понимает, что он должен строго придерживаться SLA, и при тех же 99,9% сервис клиента не должен «лежать» более 43 минут в месяц.
Обращая внимание на эти нюансы, можно защитить себя от сделки с недобросовестным поставщиком.
SLA изнутри
Если для клиента SLA — ключевая ценность, то для провайдера Managed IT — краеугольный камень, вокруг которого строятся все его процессы и экономика. В нормальных сервисных компаниях этому документу уделяется максимально пристальное внимание. Согласование параметров SLA (или их изменений) всегда проходит несколько инстанций внутри компании-поставщика: менеджмент, инженеры, техподдержка, разработчики. Поэтому расчет параметров SLA — одинаково ответственное мероприятие как для клиента, так и поставщика. В следующем посте рассмотрим новую услугу на рынке управления ИТ-инфраструктурой — Managed DevOps, когда провайдер выступает в роли DevOps-инженера, помогающего клиенту наладить процессы CI/CD.
Предыдущая статья
