Релизная политика против хаоса
Костя так переживал за результат релиза, что решил контролировать процесс его запуска прямиком с собственной свадьбы. Это было эпично, и привело к мысли, что в жизни пора что-то менять. Причём как можно скорее. Из всех возможных вариантов он выбрал самый интересный и решил поменять нашу релизную политику.
Нельзя сказать, что без этого всё работало плохо. Работало хорошо. Но достаточно долго. Новые фичи выходили не чаще раза в месяц, но в какой-то момент мы поняли, что нужно укладываться в две недели максимум. У нас появились такие важные показатели, как частота поставок и Time to Market.
А потом начала работать омниканальная платформа, на которой двенадцать команд одновременно разрабатывали одно приложение, каждая — свою часть. Тогда появился запрос на стандартизацию процесса.
Меня зовут Михаил Щеголев, мы вместе с Константином Дерешевым занимаемся релизной политикой в одном из крупных российских банков. Мы любим свою работу, а дедлайны не любим.
Особенно, если дело касается еженедельных релизов.
Мы написали с нуля регламенты, которые упростили жизнь разработчикам и уменьшили количество аварий после внедрения. А ещё бонусом презентовали наш проект на ИТ-конференции «Импульс Т1» как кейс по покорению хаоса. Сегодня мы расскажем о своей релизной политике и о том, как уже четвёртый год уменьшаем энтропию Вселенной в рамках одной отдельно взятой компании.
Как прошли первые три месяца работы омниканальной платформы
Релизная политика началась в сентябре 2020 года с Кости Дерешева. Это человек, про которого можно сказать: «И швец, и жнец, и на дуде игрец». Он пришёл в компанию в качестве ИТ-лида одной из команд на отдельном направлении, а сегодня уже стал лидером целого стрима (это двенадцать продуктовых команд и три — инфраструктурные), занимается надёжностью, производительностью и качеством создаваемого продукта. Релизная политика стала для него практически жизненной необходимостью, чтобы выровнять, синхронизировать и стандартизировать все происходящие в компании процессы.
Он был заказчиком, исполнителем и одним из первопроходцев этого проекта. Подобного опыта ни у кого не было, опереться было не на что, так что история создавалась с нуля.
Задачу при этом осложняла специфика отрасли. Например, Mission critical system — это понятие, которое обозначает, что уровень доступности системы в банке — 99,99, то есть программа имеет полное право не работать 52 минуты в год, а всё остальное время должна быть в полном доступе хоть днём, хоть ночью. А значит, ни одна фича не должна её положить ни на секунду, и вариант всё сломать и построить заново категорически не подходит.
Костя засучил рукава и начал методично изучать работу каждой команды: кто чем занимается, что внедряет и от кого зависит, как устроены бизнес-процессы и что происходит под капотом. На тот момент у нас было около 80 сервисов, и гарантировать, что все разработчики понимают все тонкости зависимостей, было невозможно.
Пришлось делать полное извлечение архитектуры и погружаться во многие процессы сразу: и в DevOps, и в инфраструктуру. Команды были обособлены, многие не понимали, на что обращать внимание в первую очередь. При этом новый стек в части производственного процесса банка нужно было полностью синхронизировать.
Для того чтобы в новых условиях омниканальности выпустить первый релиз, понадобилось три месяца. Он вышел в декабре 2020 года, и руководить запуском Косте пришлось с собственной свадьбы: личная ответственность обязывала.
Кадр из мультсериала «Том и Джерри», 1-й сезон, 58-я серия
Первое, что он придумал, чтобы как-то собрать процессы и команды воедино, — синхронизирующие встречи. На них обсуждали, что и как будет внедряться, а также кто от кого и каким образом зависит. Для того чтобы адаптироваться к непривычной системе, командам зачастую требовалось несколько итераций и дополнительных встреч.
Примерно в этот момент, в апреле 2022 года, направление подхватил я. Мы вместе смогли его сформировать и доработать, структурировать все процессы и расширить bus factor. Сейчас можно зайти и посмотреть, кто и за какой этап у нас отвечает: есть чёткое описание регламентов и разделение ответственности. Костя отслеживает ситуацию в целом и отшлифовывает частности.
Какие подводные камни мы встретили на своём пути…
Регламент — это не каменные скрижали, а живой процесс, который очень быстро меняется.
Поначалу я переписывал его по нескольку раз в день, чтобы удержать всю актуальную информацию. И если всё начиналось с одной странички, то через некоторое время релизная политика превратилась в огромный манускрипт, который нужно было очень чётко структурировать.
С инструментами тоже не всё было гладко: чтобы получить необходимую автоматизацию, приходилось выкручиваться всеми возможными способами, а кое-какие вещи придумывать с нуля.
… и как к нашим идеям отнеслись в команде
Поначалу пришлось пробиваться через непонимание, зачем менять существующие порядки: «работает — не трогай». Мы разработали чёткие и грамотные инструкции, но не все коллеги были заинтересованы в их изучении. Это было ожидаемо: выстраивать новые процессы иногда непросто.
Учитывая, что изначально мы общались в основном с ИТ-лидами, которые не находились у нас в подчинении, работать приходилось в очень слабой матрице.
Мы отлично прокачали свои soft skills, доказывая, убеждая и объясняя на пальцах, почему всем так важно перейти на сторону релизной политики. Мы продавали эту историю как что-то необходимое каждому сотруднику, что поможет избавиться от монотонных скучных обязанностей и освободить побольше времени для интересной работы с фичами.
В итоге после титанической работы нам удалось донести до каждой команды, что мы просто упорядочили процессы, через которые они и так каждый день проходят, и сделали это для общего блага.
Зачастую мнения разных команд об одном и том же процессе расходились, но нужно было собирать всё это воедино. Порой с головной болью и плясками с бубном. Иногда собрания ИТ-лидов были похожи на групповую терапию: вроде как все хотели и просили изменений, но нужно было выговориться, чтобы избежать недопонимания. Кстати, тогда большую часть мы успешно утвердили.
Главный вывод, который мы сделали: что бы мы ни пытались изменить, недовольство всё равно будет. Важно его «правильно приготовить».
В конце концов нам удалось создать рабочую схему.
Что это за схема и как она функционирует
Сейчас мы отвечаем за канальное приложение и вокруг нас работает около 700 человек. Мы структурировали весь процесс, составили чёткий график релизов и прописали, какие ветки куда отводятся и какие команды к чему идут:
- Расписали по мелочам все регламенты, чтобы каждый участник чётко понимал, что он делает, как и зачем. А мы, в свою очередь, в случае чего могли ему показать и напомнить.
- Благодаря системе сводных таблиц мы создали шаблоны для release notes.
- Автоматически сформировали сводную страницу по всем релизам.
- Написали реально много автоматизации, благодаря которой процессы, занимавшие раньше несколько часов, стали укладываться в несколько минут.
- Ввели некоторые практики, которые позволяют предотвращать проблемы и аварии.
- Обеспечили определённую прозрачность для смежных стримов, которые могут зайти на наши странички и получить информацию по всем нашим релизам.
Для анализа текущего состояния мы используем тестовые таблицы.
Примерно вот такие
Все понимают, что, когда и почему должно произойти. Появилось чёткое разделение ответственности, кто и за какой этап отвечает.
С помощью таблиц мы в любой момент можем понять, где находятся команды, причём совершенно на всех уровнях. Релиз-менеджеры используют таблицы, чтобы видеть, кто и какие артефакты подготовил. Команда сопровождения, которая приходит по выходным, выясняет, кто пока тестирует свои фичи, а кто уже подготовил их к внедрению.
То есть таблицы используются поголовно всеми и на каждом этапе работы. Даже у руководителей они тоже есть (правда, в упрощённой версии). И эта информация очень помогает жить.
Для чего в каждом стриме нужен свой релиз-менеджер, и как мы облегчили его участь
Менеджер релиза — это человек, который помогает команде ускорять процессы и решать проблемы. Он сродни дирижёру, у которого нет в руках ни одного музыкального инструмента, и всё же именно он отвечает за каждую сыгранную оркестром ноту.
Релиз-менеджер полностью отвечает за весь цикл подготовки, разбирается, как работает программа, и знает, кто и на каком этапе находится. Он связующее звено между разработкой и сопровождением. И если команда попадает в какой-то тупик и не знает, куда постучаться, то менеджер релиза может подсказать, к кому идти. Он знает, что нужно изменить, закрыть или исправить, чтобы продукт прошёл приёмо-сдаточные испытания и отправился на следующий этап.
При этом менеджерами релиза в разных командах могут быть очень разные люди с очень разными правами. Кто-то просто двигает странички по статусам, а кто-то (например, Костя) работает скорее как delivery-менеджер или рroblem-менеджер: он полностью знает путь каждого релиза, может включиться в любую чрезвычайную ситуацию и понимает все тонкости разработки.
Выражаясь фигурально, он знает, как устроен «звездолёт», вплоть до болтика, и поэтому к нему нельзя прийти и сказать: «Космический корабль. Мы его когда-нибудь построим». Придётся объяснять, как именно вы это сделаете и почему архитектура решения именно такая.
Я же нахожусь где-то посередине между этими двумя понятиями. С одной стороны, не настолько глубоко, чтобы суметь предотвратить аварию. Но, с другой, вполне достаточно, чтобы взаимодействовать со всеми командами и разруливать большинство проблем, связанных с подготовкой к релизу и согласованию по безопасности.
Когда наступает время внедрять очередную фичу, релиз-менеджер перестаёт есть и спать, а только «тащит состав в гору». Пока релизы выпускались один раз в 30–35 дней и каждая команда готовила свою фичу по три месяца, потерпеть было ещё можно. Сейчас релизы случаются каждую неделю, продолжать работать по-старому было бы просто невозможно.
Я автоматизировал большой кусок, и теперь можно за пятнадцать минут, не выходя из кабинета, оценить, что происходит на текущей неделе и что будет запущено в ближайшие выходные во время внедрения, сделать срез по всем командам и получить чёткое понимание, кто прямо сейчас готов, а кто — нет, что нужно подсветить и какие процессы ускорить. Есть возможность подвинуть по срокам опаздывающую команду на неделю, а затем ещё сформировать единый стандартизованный отчёт для руководства.
Таким образом, у нас появляется некий бесконечный конвейер, который еженедельно приносит клиенту ценность. А значит, мы научились управлять этим хаосом.
И ещё чуть подробнее — про регламенты
Мы составили чек-листы с описанием процессов и чёткими указаниями. Чтобы было ещё понятнее, создали огромную наглядную таблицу со схемами всех жизненных процессов: процесса внедрения, плана внедрения, процесса заведения работ и т. д. Это было долго, сложно и довольно больно (я правил шаблон около 300 раз), но мы сделали!
Вот такие там схемы
И оказалось, что этот регламент — именно то, что нужно, чтобы ребята стали лучше ориентироваться и быстрее реагировать на проблемы. На каждом этапе можно заглянуть в чек-лист и посмотреть, кто за что отвечает и к кому можно обратиться с вопросом. Тут главное — не пытаться помочь коллегам и не заниматься с ними совместным чтением. Задокументировано буквально всё. А если где-то появляется пробел, то всегда можно прийти к нам, и мы допишем.
Шаблон сначала адаптировался, потом стабилизировался, и последние полгода он более-менее статичен. За это время накопилось некоторое количество доработок, и сейчас мы планируем выйти на новую итерацию.
Что изменилось в нашей работе после доклада на «Импульс Т1»
В прошлом году мы сделали доклад о релизной политике на нашей внутренней масштабной IT-конференции «Импульс Т1», и это дало новый толчок к развитию.
Во-первых, о ней узнало сразу много людей. Кое-кто даже приходил подсматривать и перенимать опыт.
Во-вторых, «Импульс Т1» позволил участвовать во внутренних проектах. Это интересно и прикольно.
В-третьих, к нам стали чаще заглядывать коллеги за технологическим советом. Они и раньше приходили, но после конференции «Импульс Т1» их стало гораздо больше. Иногда к нам на огонёк заглядывает весь руководящий состав. Но в целом мы продолжили работать так же, как работали раньше.
Краткие итоги за год практики внедрения менеджмента релиза
Спустя год после того, как мы пересмотрели все имеющиеся у нас регламенты, доработали своды и привели в порядок всё, до чего сумели дотянуться, можно подвести некоторые итоги:
- Процесс доставки фич ускорился. Если раньше Time to Market у нас занимал 45 дней, то сейчас — 25. Поставки вместо 35 дней стали происходить за 14, а некоторые фичи доставляются и вовсе за неделю по быстрому процессу. И его можно сократить ещё сильнее, потому что есть понимание схемы и круг ответственных, которые могут принять решение о сокращении пути. Например, если нужно доставить фичу за два дня, то мы можем собрать встречу и обсудить, за счёт чего это сделать: где занят стенд, какая сейчас идёт поставка и под какие задачи, куда и что можно подвинуть по критичности и т. д. Везде, где это возможно, процессы разделились на атомарные составляющие, которые идут параллельно.
- Каждая команда стала выходить в релиз раз в две недели вместо трёх месяцев. Команд двенадцать, значит, каждую неделю мы запускаем по шесть релизов.
- В 3,2 раза уменьшилось количество аварий. Раньше из-за того, что раз в месяц мы внедряли огромную поставку, вероятность того, что мы где-то чего-то не предусмотрели, был велик. Но чем чаще идут поставки и чем понятнее регламент, тем меньше инкремент и тем легче прогнозировать и оценивать риски. Если в цифрах, то за последний год мы сделали 520 внедрений, а аварий, вызванных внедрением, за этот период было всего 11. Т. е. число аварий снизилось с 50 до 2% относительно количества внедрений, и это аварии лёгких категорий.
- За счёт уменьшения количества аварий удалось хорошо замотивировать людей и сократить количество их выходов во внедрение.
- Структурировали команды. Они перестали забывать к концу месяца, что сделали в его начале. Здесь нам очень помогли инкремент и возможность выгружать срезы и отчёты о происходящем.
Со стороны банка за это время ужесточились требования по форматам. Сейчас появились чёткие стандарты, по которым нужно оформлять документы. У нас есть порядка 20 информационных систем, за которые мы отвечаем. Собрать руками под каждую из них свой пакет документов в правильной комбинации и по нужной форме просто нереально, особенно если учесть, что это должно происходить раз в неделю. Мы наладили автоматизацию этого процесса.
Каждую пятницу мы формируем большую поставку. Релизы выходят в основном в выходные.
Этот участок работы сейчас полноценно взял на себя я. Константин приходит на определённом этапе, чтобы сделать срез и понять, что готово, а что — нет.
А что дальше?
Многие процессы мы сейчас проходим «по верхам», поэтому дальше хотим заняться ретроспективами внедрения и запустить написание Post-mortem-историй о том, что происходило с «аварийными» фичами. То есть буквально поминутно расписывать тайминги: кто, когда, где и что делал. Когда-то Костя работал в процессинге крупного банка, где такая система сильно помогала предотвращать новые аварии.
Также мы готовим план раскатки-накатки, чтобы перестать релизиться по выходным и делать это в будние дни вечером. Нам очень хочется «расщепить» этот процесс на неделю.
Ведём вычитку планов работ. Стандартизируем планы внедрения для сокращения количества ошибок прикладным сопровождением.
Унифицируем процессы. Сейчас у нас — двенадцать команд, и каждая может написать одну и ту же строчку по-своему, а нужно, чтобы человек чётко понимал, что обозначает каждый символ.
Работы впереди ещё много, и она очень интересная!
