Каждое облако — своя команда: как унифицировать сопровождение

Исторически инфраструктура компании собирается как слоёный пирог. Когда то взяли VPS «по объявлению». Потом часть систем уехала в Yandex Cloud. Для международного контура остался AWS. Каждый кусок сопровождает свой подрядчик со своим чатом, своими обещаниями и своим пониманием «критичности».

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

Бизнесу в этот момент не нужна теология multi-cloud. Нужен один ответственный за сквозной результат и понятные сроки реакции.

Чем мешает зоопарк сопровождения

Разные окна реакции. Для витрины подрядчик отвечает за час, для биллинга в другом облаке — «завтра посмотрим». Бизнес процесс один, обещания разные. Клиент не обязан знать, в каком облаке лежит тормозящий кусок.

Нет сквозного мониторинга. Каждый смотрит свой кусок. Падение на стыке — сиротская зона. Именно стыки обычно кормят ночные созвоны.

Доступы и документация размазаны. Смена одного подрядчика означает риск потерять знание о связках. Новый человек честно начинает с нуля — за ваш счёт.

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

Изменения не координируются. Один подрядчик обновляет сеть, другой не знает, третий чинит следствие. Получаете эффект домино без дирижёра.

Почему так сложилось

Решения принимались локально: «этому отделу срочно нужен сервер». Сопровождение покупали вместе с площадкой. Локальная скорость породила глобальный хаос.

Боялись привязки к одному поставщику инфраструктуры и в итоге получили привязку к хаосу из людей. Люди-lock-in часто больнее platform-lock-in.

Не было роли владельца инфраструктуры целиком — были владельцы кусков. Куски зелёные, система красная.

Ошибки при попытке «просто сменить всех»

Перетянуть всё в одно облако только ради удобства сопровождения, без оценки рисков и стоимостей переноса. Иногда унификация людей важнее унификации площадок.

Назначить генподрядчика, не дав ему доступов и карты зависимостей. Он станет ещё одним чатом и ещё одним счётом.

Требовать единый SLA, не определив, что критично. Без классов систем цифры в договоре декоративны. Не всё должно восстанавливаться за пятнадцать минут — но то, что должно, обязано быть названо.

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

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

Как унифицируют сопровождение multi-cloud

Рисуют карту: какие системы где живут, какие связи, какой целевой срок восстановления, кто сейчас дежурит. Без карты переговоры о «едином партнёре» пусты.

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

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

Выбирают модель: один партнёр на все контуры или внутренний координатор плюс узкие эксперты. Главное — кто отвечает за сквозной результат числом и договором.

Стандартизируют минимумы: мониторинг, бэкапы, доступы, инфраструктура как код там, где окупается, журнал изменений. Разные облака могут остаться; разные дисциплины — не должны.

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

С чего начать унификацию уже на этой неделе

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

Второй шаг — единый канал инцидентов хотя бы для критичных систем. Пока сообщения размазаны по трём мессенджерам, сквозного SLA не будет даже на бумаге. Унификация начинается с видимости, не с массового переезда.

Договорные формулировки, которые имеют смысл

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

Отдельно зафиксируйте, что происходит на стыке облаков: кто владеет инцидентом, пока не ясно, чей кусок красный. Именно эта фраза убирает конференцию «у нас всё зелёное». Стык должен иметь хозяина по умолчанию.

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

Имеет смысл завести общий журнал изменений инфраструктуры на все облака. Без него расследование инцидента превращается в опрос «кто что делал вчера». Журнал дешевле любой постфактум конференции.

Если подрядчиков пока несколько, назначьте внутреннего владельца multi-cloud на своей стороне — человека, который сводит статусы и эскалации. Без него единый SLA снаружи не соберётся.

Что получает компания

В инцидент больше не собирают «совет облаков». Есть ответственный, есть карта, есть согласованные сроки. Руководство видит стоимость и риски целиком, а не в виде трёх несвязанных отчётов.

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

Если сейчас Yandex Cloud, AWS и «свой» VPS живут как три государства, имеет смысл собрать эксплуатацию под одну ответственность. Это ядро услуги Облачные решения: единые правила сопровождения поверх разных платформ.