Контроль ≠ SLA
Три часа ночи. Упал L2-канал между ЦОД и складом. Остановилась синхронизация баз. Склад не может отгружать, 1С недоступна.
Дежурный инженер подрядчика присылает сообщение: «Кабель не порвали, лазер горит. По договору это зона ответственности вашего провайдера. Тикет передали».
У подрядчика может быть своя логика. Его оборудование отвечает, инцидент зарегистрирован, следующий шаг зависит от третьей стороны. Но у бизнеса другая задача: восстановить работу склада. Разбираться, кто первым нарушил границу ответственности, можно и позже. В договоре прописаны SLA и штрафы. Они помогают определить обязательства сторон и последствия их нарушения. Но даже самая обоснованная претензия не поднимет вам канал в три часа ночи.
Здесь видим разницу между двумя результатами: подрядчик выполнил свою часть обязательств и бизнес получил работающий сервис. Иногда это одно и то же. Иногда между ними есть участок, за который отвечает кто-то другой, а последствия достаются компании.
Сам по себе подрядчик не обязан отвечать за всю цепочку. Если договор охватывает только определённый участок инфраструктуры, требовать от него гарантии сквозного результата бессмысленно. Но и бизнесу опасно считать, что передача участка внешней команде автоматически закрывает вопрос с его надёжностью. Особенно если внутри компании больше некому оценить происходящее. Подрядчик не может подключиться сразу, провайдер разбирается со своей частью, а собственная команда не понимает, где искать костыль, чтобы просто заткнуть дыру до утра. В этот момент экономия на компетенциях превращается в чистый бардак: разгребать последствия всё равно придется вам.
Не обязательно держать внутри полную копию команды подрядчика. Но должна сохраняться способность понять, что происходит, проверить предложенное решение и оценить стоимость обходного пути, если обычный порядок не сработал.
Что стоит проверить до следующего инцидента?
Кто координирует восстановление, если проблема находится на стыке нескольких подрядчиков? Есть ли резервный маршрут и проверяли ли его в реальных условиях? Кто вправе запустить обходной сценарий, не дожидаясь согласования между компаниями? И измеряется ли результат временем восстановления сервиса или только выполнением отдельных обязательств?
Ответы могут привести к разным решениям. Где-то потребуется изменить договор. Где-то настроить эскалацию, организовать резервный канал или назначить ответственного за сквозной результат. А иногда выяснится, что резерв слишком дорог для возможных потерь, и бизнес сознательно принимает этот риск.
Штраф может компенсировать часть потерь. Контроль нужен, чтобы в три часа ночи было кому принять решение, а не только составить акт о невыполнении обязательств. Подрядчик может отвечать за нарушение SLA, но склад от этого сам не заработает.