Что с этим делать
Ясно, что нахрен вообще так жить. Надо что-то менять, но нельзя забывать с чего все началось. То есть нужна организация труда, которая не мешает программисту выкатывать код под клиентов, но не ломает весь продакшен. Как сохранить изменчивость компании, но не погрузиться в хаос?
Здесь рядом возникает еще другая ветка дискуссии: как вообще сохранять изменчивость, учитывая что время жизни требований зачастую сравнимо или меньше, чем время их имплементации. То есть, начиная писать код, мы точно знаем, что вот это мы не допишем, а допишем что-то другое.
Плюс к тому, что надо давать релизить в продакшен мимо админов, надо еще вернуть обратно программистам ощущение того, что они работают не ради чеклиста в ТЗ, а ради результата. Возникает целый пласт вопросов: а как его увидеть, если серверов уже не 1, а 1 000 и логи необозримы?
То есть:
- пишем код в прод,
- не тратим время на мелкую возню с продом,
- не ломаем прод,
- видим эффект изменений,
- радуемся ощущению востребованности работы,
- можем по итогу скорректировать планы.
Ну понятно, что мы тут говорим про agile и DevOps, причем без какого либо надрыва и истерики.
Для того, чтобы программист мог писать код в прод, надо чтобы кто-то, противостоящий хаосу, мог безболезненно откатить эти изменения. То есть откатываемость — очень важная характеристика. Поднес руку к паяльнику, убрал — плохо. Можно попробовать с другой стороны. Define «плохо».
Как понять, что код стал плохим
Чтобы понять, что код стал плохим, надо зайти немного дальше. Иногда достаточно просто констатации того, что количество эксепшенов выросло в два раза, в более взрослых проектах могут померять результаты продуктового мониторинга (об этом позже).
Но если начать мерять, то очень быстро можно понять, что на самом деле проблемы очень часто неплохо замеряются. А значит, можно доверить замеры скрипту, который примет решение: откатывать или оставлять. То есть мы научились хаос уменьшать. А как не погружаться в него?
А тут все очень просто: канареечный деплой — современная азбука. Чтобы не погружать в хаос весь проект, надо делать это маленькими шажками. Проверять все на антихрупкость. Ломать всю систему по чуть-чуть — полезно и нужно. Даже если хватает одного сервера, нужно завести три.
Выложили новый код на один из трех, померяли, что получается. Если стало не хуже, значит, можно дальше. И все, постоянно все надо регулярно по чуть-чуть ломать, проверяя устойчивость системы к настоящим поломкам. Chaos monkey, да. Спасение от хаоса лишь на границе хаоса. W40K!
Итого, мы вырастили скрипт, которому можно дать новый код, он его выложит на один сервер из списка, померяет градусником, выкатит дальше или откатит назад. Собственно, ровно так и возникает Kubernetes. Это инструмент программиста для раскатки кода.
Как же померять? Как понять, что код плохой или хороший? Здесь возникает профессия человека, который отвечает на вопросы: кому в этом проекте жить хорошо и от чего. Да-да, тот самый продакт с его метриками. На крупном проекте ошибки и 500-ки хлещут постоянно. Все на грани хаоса.
Но все, что прогается, прогается ради клиентов, ради их удобства, чтобы они как можно больше сервиса получили. Собственно, если ошибок в sentry стало больше, а график уровня сервиса не поменялся, значит, эти ошибки диагностируются ошибочно, все ок на самом деле. Продуктовая метрика.
В отличие от примитивных штук типа «сколько RPS держим» или чего-то еще подобного, метрики — это предмет ежедневной рефлексии и переосмысления. Это часть того, как бизнес сам себя на рынке ощущает. То человеческое, неосязаемое, что пытаются выразить в программировании.
Почему для программиста важны метрики
Программисту надо видеть эти метрики, иначе он идет не вместе с бизнесом и клиентами, а куда-то в другую сторону. Частью работы должен быть анализ влияния изменений на эти метрики. Смотрите, как уже поменялся подход ко всей работе:
- Я написал код по ТЗ, какие ко мне вопросы?
- Я задеплоил код (тут мы пропустили этап внедрения тестов, но это как бы уже совсем примитивно).
- Я убедился в том, что код не откатился.
- Я убедился в том, что код не сделал хуже проекту.
- Я увидел, как он сделал лучше.
Вот собственно где-то в конце этого уже и можно говорить о внедрении DevOps-подходов, потому что без них туда вообще не прийти. Чтобы не заниматься бессмысленной тряхомудией с настройкой Redis и откатом деб-пакетов, существует DevOps-машинерия. НО НЕ ДЕВОПСЕРЫ!
Все, о чем мы тут говорили, это про то, как поменять работу программистов, чтобы они перестали гробить бизнес своими косяками, но могли ежедневно вносить изменения. DevOps — это перестройка разработки с «девелоперы — эксплуатационщики» на «девелоперы + инструментарий».
Следствие всего этого: никому уже не нужны полуторалетние релиз-марафоны. Чтобы можно было обозреть изменения, увидеть их влияние, они должны быть небольшими, иначе слишком сильно их взаимное влияние друг на друга. Сделал немножко — задеплоил, проверил, померял.
То есть, внедряя скрипты для отката, мы пришли к обозримым и измеримым изменениям, которые можно сделать, только делая небольшие итерации, при наличии генерального плана. Вот вам и кусочек agile сам по себе. Еще раз рекомендую прочитать Ричарда Кука — просто азбука нашей профессии.