Недавно у Яндекса случилась неприятная история с дата‑центрами: несколько площадок пришлось остановить, и Yandex Cloud какое‑то время работал в ограниченном режиме. Что произошло и что крутилось на этих площадках, я подробно разбирал в отдельной статье.

Здесь хочу про другое. Клиентов у Yandex Cloud около 64 000, и тем, чьи ресурсы стояли на затронутых площадках, пришлось поднимать свою инфраструктуру заново, внутри облака или у другого провайдера. Во многих компаниях эту работу делает DevOps‑команда.

Кто что восстанавливает

Сами серверы, питание, охлаждение и здания восстанавливают инженеры дата‑центров. У Яндекса этим занимается отдельная команда: она проектирует, строит и обслуживает все дата‑центры компании, где стоит около 150 000 серверов. Сроки здесь считают в месяцах: Эльдар Муртазин из Mobile Research Group оценивает поставку нового серверного оборудования в 2–3 месяца.

Поверх железа работает платформа Yandex Cloud: Compute, Managed Databases, Object Storage, Managed Service for Kubernetes. Её поднимают инженеры облака. На эти два слоя клиент не влияет, ему остаётся следить за статус‑страницей.

Всё, что клиент развернул в облаке сам — ВМ, кластеры, базы, пайплайны, секреты, DNS, — облако за него поднимать не будет. Эта работа сейчас и идёт во многих компаниях.

Облако даёт инструменты, делает клиент

Со своей стороны Yandex Cloud дал клиентам инструменты. Управляющие компоненты региональных кластеров Kubernetes разрешили переносить в другие зоны, а хосты недоступной зоны — удалять из отказоустойчивых кластеров Managed Databases. Группы узлов в других зонах и перенос нагрузки на них остались на клиенте. Чтобы было из чего восстанавливаться, всем выделили небольшой запас квот сверх текущего потребления, в том числе под перенос на другие площадки.

Ещё Яндекс договорился с Selectel, K2Cloud и VK Cloud об ускоренном приёме клиентов: выделены дополнительные команды специалистов, подключение упростили, финансовые условия сделали гибкими. Цель в заявлении сформулирована так: чтобы клиенты могли перенести свою инфраструктуру без лишней бюрократии.

Переносят при этом клиенты. Переписать Terraform‑модули с провайдера yandex под другого провайдера, перенести образы из Container Registry и секреты из Lockbox, выгрузить бакеты из Object Storage, развернуть дампы и переключить DNS — всё это делает команда клиента.

Почему это работа DevOps

Каждая из этих задач по отдельности — обычная работа DevOps: инфраструктура как код, CI/CD, Kubernetes, секреты, сеть, мониторинг. В аварии меняются темп и цена ошибки.

Сложность в том, что задачи идут одной цепочкой. Трафик не переключить, пока не развёрнуты данные. Данные некуда разворачивать, пока не поднят кластер, а кластер не поднять, пока не переписаны модули. Держать эту цепочку в голове целиком должна одна команда.

Разработчик знает своё приложение, но не обязан знать, где лежит state и почему кластер из трёх узлов в трёх зонах не переживает потерю двух. С базами DevOps работает в паре с DBA: развернуть дамп, проверить консистентность и решить, с какой точки восстанавливаться, — это их общая задача.

Что это говорит о профессии

Спрос на DevOps был и до этого. История с Яндексом показала другое: за что этим людям платят.

Managed‑сервисы продают как способ не думать об инфраструктуре, и это работает, пока авария укладывается в модель облака, то есть в потерю одной зоны. С одной зоной Yandex Cloud справился сам: нагрузку он перевёл примерно за семь часов. Когда зон выпадает больше, думать об инфраструктуре снова приходится клиенту, и думает о ней DevOps.

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

У нас инфраструктура не в облаке, так что этот переезд прошёл мимо нас. Но примеров вокруг хватает.

8 октября Циан сообщил о сбое сайта и приложения «в связи с инцидентом на объекте инфраструктурного партнёра», восстановлением занималась техническая команда сервиса. 11 октября перебои были у маркетплейсов, служб доставки и ретейлеров, и компании объясняли одинаково: их IT‑команды восстанавливают работу вместе с облачными провайдерами. Кто‑то на время перешёл на ручной режим: в «Делимобиле» так стали регистрировать новых пользователей.

Глава TelecomDaily Денис Кусков, у которого сайт и приложение на Яндексе, с трудом поднял их к пятнице, а потом восстанавливать всё пришлось ещё раз. Дважды за три дня.

Тем, кто только входит в профессию: знания консоли одного облака мало, она не поможет, если поднимать систему надо в другом месте. Ценятся люди, которые понимают механизм — репликацию, кворум, DNS, сеть — и поэтому могут поднять систему где угодно.

Источники

Yandex Cloud Alerts — обновления по инцидентам
Статус Yandex Cloud — ограниченный режим платформы
Код.ру: Яндекс договорился с другими провайдерами о переезде клиентов
Команда дата‑центров Yandex Infrastructure
Фонтанка: эксперты о последствиях

Железо чинят инженеры ЦОДа, остальное поднимает DevOps