Откуда берётся вопрос
В команде из двенадцати человек Kubernetes редко появляется в планах — чаще в разговорах. Обычно его приносит дискомфорт: выкатка ручная и страшная, сервер один, ночью что-то падает и будит дежурного — и в какой-то момент кто-то из инженеров говорит: «нам нужен кубернетес». Руководителю предлагают не решение проблемы, а рецепт, и проверить рецепт нечем: спор быстро съезжает во вкусовщину. «Все так делают» и «нам ещё рано» — это не аргументы, это настроения.
Мы предлагаем считать. Не вообще, а на ваших числах: для команды из двенадцати ответ определяется не количеством людей, а соотношением двух величин — сколько часов вы сейчас тратите на эксплуатацию и сколько часов кластер будет требовать сам. Обе измеримы до перехода, а не после него.
Тупик: первым делом открывают прайс
Сравнить managed-кластер с текущей виртуалкой — самый естественный ход для руководителя, отвечающего за бюджет. Две цифры, разница налицо, решение «очевидно».
Это не тот расчёт. Обе строчки — про железо, а главная строка сметы — зарплатные часы людей, которые будут всем этим заниматься: цена перехода и часы еженедельного обслуживания. Хостинг здесь мелочь; выбирать по нему — всё равно что выбирать квартиру по цене домофона: число реальное, решение оно не определяет.
Второй частый первый ход — поднять минимальный кластер и «присмотреться». Пилот честно покажет цену сборки и боль переноса, но не покажет главного: налога на эксплуатацию. Налог проявляется на горизонте обязательных обновлений — устаревающие API, ротация сертификатов, обновления всего, что стоит поверх кластера. В короткий пилот этот горизонт не помещается. Пилот отвечает на вопрос «сколько стоит зайти», а решающий вопрос — «сколько стоит остаться».
Модель: подставьте свои значения
Считайте в часах; в деньги переведёте в конце, умножив на свою цену инженерного часа. Модель симметричная: в ней есть цена нынешней жизни и цена кластера, чтобы расчёт не подгонял ответ под желаемый.
Сначала честно о том, что кластер даёт: выкатки без простоя из коробки, самовосстановление упавших процессов, декларативное описание инфраструктуры в репозитории, горизонтальное масштабирование под всплески и общий язык — новому инженеру не надо объяснять ваш самописный конвейер, стандартный он уже знает. Выгоды настоящие. Вопрос не в их подлинности, а в том, превышают ли они цену для вашей конфигурации.
Пожарная нагрузка Э — часы в обычную неделю на то, что кластер мог бы снять:
- выкатки: число выкаток за неделю, умноженное на часы одной, включая разбор того, что сломалось после;
- поддержание серверов: патчи, сертификаты, место на дисках, починка мониторинга;
- восстановление после падений, усреднённое по неделям.
Оговорка: кластер снимает не всю Э. Часть пожарной нагрузки живёт в самом приложении и переедет с вами куда угодно. Считайте только то, что связано с железом и выкладкой.
Налог кластера Н — часы, которые кластер будет требовать сам:
- плановые обновления узлов, а без managed — ещё и контрольной плоскости;
- обновление всего, что вы обязаны поставить поверх: контроллер входящего трафика, менеджер сертификатов, мониторинг, сбор логов, реестр образов;
- разбор инцидентов, в которых подозреваемых стало больше — планировщик, сеть узла, контроллеры: время поиска растёт, пока команда не выучит слои;
- поддержка конвейера деплоя.
Ключевое свойство Н: он не зависит от размера команды, он зависит от кластера. Крупная организация раскладывает его на много команд, у двенадцати человек он ляжет на одного-двух.
Цена перехода П — разовая, и в ней легко забыть два пункта:
- обучение двух человек, а не одного: кластер, который знает один, превращает конвейер деплоя в заложника его отпуска и увольнения;
- период двойной эксплуатации: старое и новое работают параллельно, фичи не останавливаются, значит, платите вы здесь не деньгами, а скоростью.
Сравнение. Кластер окупается, если сэкономленная пожарная нагрузка за ваш горизонт планирования покрывает цену перехода: (Э − Н), умноженное на длину горизонта в неделях, больше П. Отсюда два честных «нет». Если Э меньше Н — вы подписываетесь на проблему, которой у вас нет, и никакой горизонт не поможет. Если разница положительная, но горизонт короткий, не окупится даже удачный переход.
Поправка на рост. Если планируете расти числом сервисов и людей, у кластера появляется вторая выгода — унификация. Каждый новый сервис на самописных скриптах — это чьи-то часы на очередной велосипед; на общей платформе он разворачивается по накатанному. Прикиньте, сколько выкатываемых единиц появится на горизонте и сколько часов каждая съела бы на самодельном конвейере, — и прибавьте это к выгоде кластера.
Поправка на managed. Managed убирает из Н работу с контрольной плоскостью. Узлы, нагрузки, права доступа, входящий трафик, хранилища, календарь обновлений остаются вашими. Н уменьшается, но в ноль не обращается — не верьте тому, кто обещает обратное.
Как оценить Н без опыта. Это самая честная трудность модели: своих замеров у вас нет. Обходной путь — взять список из блока выше и для каждой позиции прикинуть своё время на плановое обновление и типовой инцидент, а потом заложиться на главное: у кластера обновления происходят не «когда удобно», а «когда надо». Устаревающие API создают дедлайны, которых в вашем графике релизов не было. Для руководителя, отвечающего за сроки, это, возможно, самый неприятный сюрприз: кластер приносит чужие дедлайны.
Позиция редакции
Мы считаем, что для команды из двенадцати человек ответ по умолчанию — нет. Это не вкус, это арифметика: выгода кластера растёт с числом выкатываемых единиц, частотой выкладок и планами роста, а налог Н от размера команды не зависит. Двенадцать человек — это, как правило, немного выкатываемых единиц и никакой базы, на которую можно разложить Н. Налог станет чьей-то побочной обязанностью, а побочная обязанность — первое, что умирает под дедлайном. Кластер, который держат в свободное время, хуже честных скриптов на виртуалке: он обещает самовосстановление и отказоустойчивость, которые перестаёт обеспечивать по мере накопления долга по обновлениям, а сложность из сметы никуда не девается.
Наша позиция неверна, если ваши собственные числа говорят обратное. Явное условие: замеренная пожарная нагрузка Э стабильно превышает Н плюс долю цены перехода, приходящуюся на неделю, — тогда кластер нужен вам уже сейчас, и двенадцать человек не аргумент. Позиция не работает и в двух других случаях: если нагрузка у вас рваная и всплески приходится обслуживать руками — встроенное масштабирование дешевле самодельного; и если платформенная роль уже существует, то есть кто-то занимается инфраструктурой как основной работой, — налог уже кем-то оплачен, и маржинальная цена кластера ниже. Когда такой человек появляется у команды — тема нашего материала «Платформенная команда: когда её заводить».
Если модель сказала «нет»
Боль, которая породила вопрос, никуда не делась: выкатка и правда страшная, сервер и правда один. Но лечится это без кластера. Выкатку сделать скриптовой и скучной. Подстраховаться вторым сервером с переключением. Проверить бэкап не наличием, а реальным восстановлением. Поставить мониторинг, который будит раньше пользователей. Что из этого набора живо без кластера и в каком виде — мы разбирали в споре «Деплой без кластера: что осталось живым»; налог у этого набора ниже кластерного, а собирается он из тех же часов пожарной нагрузки, которые вы и так платите.
Возвращаться к вопросу стоит не по календарю, а по событию: добавился новый сервис, инциденты стали регулярными, в команде появилась платформенная роль. Событие меняет переменные — пересчитайте модель, она у вас теперь есть. И сам вопрос «нужен ли Kubernetes маленькой команде» мы считаем плохо поставленным: правильная формулировка — «когда он окупится», и ответ на неё — не настроение, а ваша арифметика.