Серверы — одна из тех вещей, о которых бизнес вспоминает в тот день, когда они подводят.
До этого никто особенно не интересуется, сколько у приложения свободной памяти и как устроено резервное копирование. Пока сайт работает, инфраструктура кажется чем-то вроде электричества: нажал кнопку, свет есть, идём дальше.
А потом выходит реклама.
Трафик становится в пять раз выше обычного.
Или база начинает отвечать медленнее.
Или разработчик выпускает новую версию, после которой один сервис перестаёт запускаться.
Кто вообще понимает, что происходит
И тут оказывается, что вопрос был не «какой у нас Kubernetes», а гораздо более простой: кто вообще понимает, что сейчас происходит?
Мы начинаем с него.
Сначала смотрим на сам продукт и нагрузку. Что у вас происходит в обычный день? Где бывают пики? Что случится, если один сервис выйдет из строя? Какие данные критичны? Как сейчас выпускаются версии? Есть ли понятный способ откатить изменение? И самое неприятное: если завтра всё исчезнет, вы знаете, как это поднять обратно?
Только после этого появляется разговор о конкретных технологиях.
Иногда ответом действительно становится Kubernetes. Когда сервисов много, нагрузка меняется, нужны разные окружения и автоматическое масштабирование, он сильно упрощает эксплуатацию. Но для небольшого проекта Kubernetes может быть просто дорогим способом сделать простую работу. В таких случаях мы скорее предложим не усложнять.
Воспроизводимость вместо модности
Для зрелой инфраструктуры важна не модность, а воспроизводимость. Настройки серверов и окружения не должны существовать только в памяти одного системного администратора. Поэтому используем Terraform и храним описание инфраструктуры в Git. Если завтра понадобится новый стенд или переезд в другое облако, не приходится вспоминать, что именно было настроено три года назад.
Мониторинг нужен по той же причине. Нам неинтересно знать только то, что сервер включён. Хотим видеть, как чувствует себя приложение, где растёт нагрузка, какой сервис начал выдавать ошибки и не превращается ли обычный вечерний пик в проблему. Prometheus, Grafana, логи, трассировка — инструменты разные, задача одна: узнать о проблеме раньше клиента.
С резервными копиями ещё проще. Они должны не просто существовать, а восстанавливаться. Мы поэтому не любим ситуацию, когда заказчик говорит: «Да, бэкапы у нас есть», а на вопрос «когда вы последний раз из них восстанавливались?» наступает пауза.
После запуска
После запуска смотрим на реальные цифры и подстраиваем систему. Может оказаться, что автомасштабирование начинается слишком рано. Или наоборот, слишком поздно. Что один сервис потребляет неожиданно много ресурсов. Что часть уведомлений создаёт только шум и отвлекает инженеров.
Это нормальная эксплуатационная работа.
Новый инфраструктурный контур обычно занимает три-шесть недель. Иногда больше, если речь идёт о миграции действующего продукта.
Но конечная цель здесь вообще не в том, чтобы у вас появился модный кластер. Хорошая инфраструктура должна перестать быть ежедневной темой разговора.
Вы запускаете кампанию, и сайт просто выдерживает её. Вы выпускаете новую версию, и у команды есть понятный способ откатить её. Системный администратор уезжает на неделю, и никто не открывает его ноутбук в надежде найти там единственный пароль от продакшена.
Вот это уже похоже на нормальную инфраструктуру.