Как Kubernetes, Jira и Keycloak не помогли выпустить продукт

Небольшой повод похвастаться: меня начали звать на технические аудиты не только по работе, но и просто как специалиста.
Первый кейс сразу интересный. Есть команда из трёх разработчиков, больше 30 репозиториев, Kubernetes, Helm, Argo CD, Keycloak, Jira и куча другой инфраструктуры. Нет только новой версии приложения, которую заказчик может нормально открыть в браузере.
У заказчика уже есть работающий продукт примерно на 3000 активных пользователей в месяц. Пользователи покупают подписку и получают доступ к текстам, фотографиям и видео.
Заказчик решил обновить приложение и нанял отдельную команду. Прошло довольно много времени, но внятного результата он так и не увидел.
Разработчики говорят, что проблема в непонятном ТЗ. Заказчик говорит, что команда не отвечает на вопросы, не доводит решения до конца, а то, что показывает, регулярно не работает.
Меня позвали разобраться.
Первым делом я попросил доступ к коду. Код лежит в собственном GitLab. Правда, сам GitLab периодически тоже лежит, поэтому попасть туда получилось не сразу.
Когда доступ появился, меня встретила авторизация через Keycloak.
Напомню: разработчиков трое.
Спрашиваю, как деплоят. Kubernetes, Helm, Argo CD. Открываю список репозиториев, а их больше 30. Часть занята общими библиотеками и Docker images, но большая часть приходится на отдельные сервисы.
Потом выяснилось, что у команды есть собственные registry, Jira, Grafana, VictoriaMetrics и ещё пачка инфраструктурных компонентов.
Всё это работает на мощностях заказчика. Точнее, периодически работает. То GitLab недоступен, то проблемы с кластером, то ломается ещё что-нибудь. А отдельных людей, которые могли бы постоянно следить за этим зоопарком, нет.
Старая версия приложения продолжает обслуживать пользователей. У новой тоже есть production-контур, но он сильно отстаёт от dev и пока не соответствует требованиям.
Frontend вроде бы существует. Но вживую я его до сих пор не видел, только на скриншоте.
Сколько функций действительно готово, тоже непонятно. Приёмочные испытания ещё не начались, потому что критерии приёмки всё ещё согласовывают.
Получается странная картина. Инфраструктура уже сложная. Репозиториев много. Инструментов ещё больше. А общего понимания, что считается готовым продуктом, до сих пор нет.
Дело не в том, что Kubernetes, Jira или Keycloak плохие. Вопрос в том, зачем всё это понадобилось именно сейчас и кто должен это обслуживать.
Если команда из трёх человек построила инфраструктуру, за которой не успевает следить, значит, сложность уже стала проблемой. Особенно когда она не помогает быстрее выпускать продукт.
Поэтому моя первая рекомендация заказчику простая: упростить инфраструктуру до уровня, который команда реально может поддерживать. Уменьшить количество движущихся частей и сначала научиться стабильно доставлять продукт пользователям.
Забавно, что это полная противоположность истории с The Signal.
Там ребята быстро выкатились на Vercel, но забыли настроить RLS в Supabase. А когда я поднял логи и метрики, мне сказали, что это уже какой-то очень серьёзный подход.
Тут всё наоборот. Логи есть. Метрики есть. Kubernetes есть. Даже Argo CD есть. А работающий frontend пока существует для меня только на скриншоте.
Обе крайности плохие. Можно месяцами строить идеальную инфраструктуру и не выпустить продукт. А можно выкатиться за вечер, забыв про безопасность, логи и бэкапы.
Нормальный вариант где-то между ними: работающий пользовательский сценарий, понятные критерии готовности, минимальная безопасность, логи, метрики и повторяемый деплой.
А вы в какой крайности?



Комментарии