Шесть лет назад: один средний проект на «живом» железе
Около шести лет назад у нас был средний по размеру проект. Он долго и относительно спокойно крутился в KVM на реальном сервере: привычная схема «взяли машину в датацентре — поставили гипервизор — живём». Пока железо не начало сдавать: память, HDD, странные симптомы, которые сначала списываешь на «временный глюк».
Пока разбирались, что именно умерло, рабочий день уже закончился. Менеджмента на связи не было — принимать решения было некому. А бизнес при этом не ждёт утра понедельника: пока пойдёт вся волокита (тикеты, согласования, «давайте созвонимся»), заказчик рискует потерять клиентов. Это уже не «инфраструктурный инцидент», а спасение проекта.
Решено — сделано
Пришлось принимать решение самому. Хорошо, что ещё на входе в проект я завернул сервисы в Docker и собрал нормальный docker-compose. Без этого ночной переезд был бы совсем другой историей — с ручной установкой рантаймов, путями, «а на том сервере PHP был другой».
Сервера настраивать умею. За ночь:
- подняли новое окружение;
- развернули стек из compose;
- накинули бэкапы;
- переключили трафик.
Омрачала только долгая синхронизация файлов — гигабайты данных не летают по воздуху, сколько ни ускоряй docker pull. Но к утру сервис снова был жив. Клиенты пользовались продуктом. Заказчик в итоге воспринял происходящее скорее как «непонятную ситуацию», чем как инженерную операцию — и это нормально: для него важно, что всё работает, а не то, что под капотом сменился хост.
Хорошо, что нагрузка тогда была заметно ниже, чем сейчас. На том объёме ночной ручной cutover ещё был реалистичен.
От «спасли на Docker» к рельсам Kubernetes
Со временем картина изменилась: микросервисов стало много, нагрузка выросла, ручной compose на паре машин перестал быть потолком амбиций. Было принято решение переходить на новые рельсы — Kubernetes.
Пока шли согласования, подготовка, доступы, выбор схемы — прошло примерно две недели. Да, после ночи героизма формальный переход занял уже «взрослые» календарные дни. Но фундамент был заложен раньше: контейнеры, понятные сервисы, привычка не держать snowflake-сервер как единственный источник правды.
Вот такой у нас был вход в K8s: сначала вынужденный спасательный прыжок на Docker, потом осознанный переезд оркестрации — с бюрократией в две недели.
Как показала практика
С выбором я не ошибся. Сейчас у нас микросервисная архитектура, разделённая по доменам: независимее релизы, понятнее границы ответственности, проще масштабировать то, что реально горит. Тот ночной инцидент научил главному заранее: если сервисы уже в контейнерах — у вас есть шанс спасти бизнес за часы. Если нет — вы будете чинить железо под давлением клиентов.
Чеклист из той истории
- Контейнеризация до кризиса — не «когда-нибудь», а до первого падения диска.
- Compose/манифесты и бэкапы должны подниматься на чистой машине без шаманства.
- Право на аварийное решение лучше заранее обсудить с бизнесом — иначе ночью вы всё равно решите сами, но с большим стрессом.
- K8s имеет смысл, когда сервисов и нагрузки уже «много»; спасать жизнь проекта можно и на Docker, если образцы готовы.
- Доменная нарезка микросервисов — следующий уровень после «просто уехали с голого KVM».
Вывод
Наш переход в Kubernetes начался не с красивой презентации, а с вечера, когда на KVM кончились память и диски, а менеджмента уже не было. Docker Compose и умение поднять сервер за ночь спасли заказчику клиентов. Потом — две недели согласований и выход на K8s. Сейчас, глядя на доменную микросервисную систему под большей нагрузкой, я вижу: ставка сыграла. Инциденты не спрашивают календарь — к ним готовят упаковку сервисов заранее.