Привет, меня зовут Всеволод, я разработчик в Мир Plat.Form.
Хочу рассказать о том, как можно делать непрерывную поставку кода «снизу»: как это делали мы при разработке платежных сервисов, и какие ошибки при этом совершили.
Наша команда ведет несколько значимых ИТ-проектов: обеспечивает бесперебойность и доступность операций по картам всех международных платежных систем в России, а также платежной системы «Мир». А еще мы являемся технологическим «двигателем» для Системы быстрых платежей (СБП).
Оглавление
О команде и процессе разработки
Я работаю в одной из команд Мир Plat.Form, пишем на java и kotlin микросервисы для одной из наших систем.
Работаем по Large Scale Scrum (LeSS):
1 общий Бэклог Продукта
1 Владелец Продукта
4 мультифункциональные фиче-команды (на момент публикации уже 5 команд)
Также у нас есть команда сопровождения, которая осуществляет развёртывание, поддержку, мониторинг и решение инцидентов в продуктивной среде.
Процесс релиза
У нас более 50 микросервисов. Релиз может содержать изменения нескольких микросервисов.
В среднем задача (product backlog item) порождает 1 релиз. Так как у нас 4 фиче-команды, то у нас за один спринт готово до 4 релизов. В среднем за последние 3 месяца у нас 3.25 релиза в спринт (2 недели).
Релизы устанавливаются на прод независимо.
Работа над задачей выглядит приблизительно так:
На планировании спринта фиче-команда берет из Бэклога задачу.
Разработчики изменяют код в одном или нескольких сервисах
Разработчики дорабатывают end2end тесты, запускают их
Команда сопровождения заводит заявку на обновление ПО(релиз), заранее определяя дату работ исходя из:
Размера очереди релизов, ожидающих установки
Загруженности команды сопровождения
Доступных для релиза временных окон(желательно не обновлять ПО во время больших инфраструктурных работ)
Команда сопровождения обновляет сервисы на проде
Отметим, что мы не считаем текущее состояние идеальным. Наша цель – автоматизированные безопасные релизы, которые устанавливаются на прод силами разработчиков с помощью «большой зеленой кнопки».
Проблема: долгий релизный цикл
И, возможно, всех бы устраивал процесс релиза, если бы не занимал в среднем 20 дней. При этом такая длительность не меняется уже в течение года.
Такой срок поставки кода не комфортен – если появился баг, который нужно срочно поправить, то не получится поправить его быстро.
Решение «в лоб»
Как ускорить поставку кода?
Это простой вопрос для каждого, но сложный вопрос для коллектива:
кто-то скажет, что нужно установить дженкинс
кто-то – переписать скрипты деплоя
кто-то – нужно считать метрики DORA
кто-то – нужно ускорить end2end тесты
Можно еще скопировать передовые практики в сфере DevOps. Например, прочесть книгу Continuous Delivery и применить все рекомендации.
При этом мы можем делать правильные вещи в неправильном порядке.
Пример:
Стив Смит в докладе "Continuous Delivery and the Theory of Constraints" описывает, как его коллектив поставил себе цель уменьшить время поставки новой строчки кода до прода с 30 дней до 14. В 2 раза, амбициозная цель!
Большой коллектив работал над улучшениями полгода, однако получилось ускорить всего лишь до 28 дней. Жалкие 6 %!
Стив Смит объясняет это тем, что они ускоряли неподходящий участок конвейера поставки кода: он и без улучшения был значительно быстрее другого участка.
Затем упоминает, что есть еще теории ограничений, которая может помочь. Рассмотрим ее детально.
Решение: теория ограничений
Область применения ТОС
Теория ограничений (theory of constraints, TOC) – набор практик, нацеленных на увеличение прибыльности производств, схожих с конвейером: продукт проходит несколько стадий обработки и лишь после этого готов к продаже покупателю.
Ранее мы описали процесс поставки кода у нас – он же крайне похож на конвейер! Какая удача! Рассмотрим этот инструмент подробнее.
Что такое TOC?
Упрощенно теория ограничений состоит из нескольких частей:
Пять фокусирующих шагов: алгоритм поиска и устранения «ограничений»
Мыслительные процессы: рекомендации по построению и проверке логических цепочек
Принятие управленческих решений на основе метрик потока, а не метрик материальных запасов
Пять фокусирующих шагов
Рассмотрим «Пять фокусирующих шагов» подробнее.
Техника «Пять фокусирующих шагов» отвечает на вопрос «как увеличить пропускную способность конвейера?».
Попробуем без подсказок ускорить работу вымышленного конвейера.
Предположим, что отдельные участки конвейера работают с разной скоростью. И есть участок, работающий с наименьшей скоростью.
Проведем мысленный эксперимент:
Ускорим участок конвейера «слева» от самого слабого – тогда перед самым слабым участком будет увеличиваться очередь незавершенной работы. Но общая пропускная способность не изменится.
Ускорим участок конвейера «справа» от самого слабого – увеличенная мощность участка будет простаивать, ведь самый слабый участок и раньше не мог загрузить участок «справа» на 100%. Опять общая пропускная способность не изменится.
Следствие: любые попытки ускорить конвейер не в самом узком месте – пустая трата ресурсов.
Вернемся к технике «Пять фокусирующих шагов».
Будем называть ранее упомянутый участок, работающий с наименьшей скоростью, ограничением.
Тогда алгоритм увеличения пропускной способности конвейера будет выглядеть так:
Найти ограничение
Оптимизировать ограничение – до того, как «покупать более производительные станки», стоит поискать способ более полного использования уже существующих. Придумать изменения, которые увеличат производительность «ограничения» без использования дополнительных ресурсов.
Подчинить ограничению работу всей системы – все остальные участки конвейера работают так, чтобы максимизировать не свою производительность, а производительность «ограничения».
Расширить ограничение – если предыдущие шаги не дали достаточного эффекта, то найти способ увеличения производительности уже с привлечением дополнительных ресурсов
Повторить цикл. После того как мы исправили существующее ограничение, уже другой участок ограничивает пропускную способность конвейера.
Применение TOC для процесса поставки кода
Начинаем поиск «ограничения» в конвейере доставки кода.
Сначала мы в экселе разметили старые релизы, чтобы понять, как выглядит стандартный релиз – есть ли изменения базы данных, какие из сервисов меняются…
Затем создали в джире новый набор статусов (dev -> e2e тесты -> ожидание установки на прод -> обновление сервисов на проде) и вручную меняли статус задачи при прохождении каждого этапа. Нашего терпения хватило на 4 релиза, но и этого оказалось достаточно, чтобы понять общую картину – самым долгим этапом является ожидание релиза в очереди на установку.
Мы долго пытались понять, почему же ожидание установки релиза такое долгое: несколько раз брали интервью у команды сопровождения , рисовали «дерево текущей реальности» (методика из "мыслительных процессов" теории ограничений). И, наконец, смогли найти ответ на вопрос.
Оказалось, что у нас три причины, действующие одновременно:
Очередь релизов в последний день спринта
Чаще всего все 4 команды подготавливают релиз в последний день спринта. Наверное, это связано с размером задач: если задача большая, то мы либо не успеваем ее сделать за спринт, либо заканчиваем в последний момент.20 из 26 релизов нужно устанавливать ночью
У нас есть один важный сервис, который «хрупкий»: его обновления устанавливают по ночам. И 20 из 26 релизов содержат изменения этого сервисаНе каждую ночь можно делать релиз
Очевидно, что не стоит делать релиз по пятницам, в праздники, предпраздники, выходные, во время инфраструктурных работ. Кроме того, о ночном выходе нужно уведомлять сотрудника заранее
Мы решили, что надо решать проблему «20 из 26 релизов нужно устанавливать ночью» – надо всего лишь адаптировать архитектуру «хрупкого» сервиса для безопасного деплоя. Заодно можно и код написать)
Но есть небольшой нюанс – сервис большой, сложный, важный и высоконагруженный, поэтому сходу такую задачу не решить. Нужно какое-то предварительное обсуждение.
Подходящим местом обсуждения является архитектурное сообщество (кружок) – каждые 2 недели мы коллективом обсуждаем идеи изменения архитектуры, которые затем превращаются в элементы беклога. Подробнее об этой практике координации - LeSS Сообщества.
Идея отправилась в архитектурное сообщество.
Провал
Идея отправилась в архитектурное сообщество (в середине мая), однако спустя полгода (декабрь) ее так и не обсудили. Хотя встречи проходят каждый спринт (2 недели).
Стоит отметить, что архитектурный кружок делает много важных вещей: решает, как реализовывать новый функционал, как решать проблемы нагрузки, как менять существующую архитектуру, чтобы решить завтрашние проблемы...
Однако, тот факт, что идея, которая может кратно увеличить скорость поставки кода, затерялась в списке будущих улучшений, вызывает бурю эмоций:
Бессилие, грусть, тоска
Никто не любит девопс, кроме меня!
Никто не читает книги по девопс!
Все неучи, а я Д’Артаньян!
Провал, это конечно, грустно, но как надо было делать?
На старте предполагалось, что самое сложное в подобном – показать Владельцу Продукта ценность от выполнения технической задачи, и понять, как будем мерить результат еще до старта работы по задаче. Однако оказалось, что убедить коллег в ценности подобного улучшения тоже важно.
Попробуем понять, почему у нас не получилось применить теорию ограничений.
Ошибка 1 – Не следовали алгоритму «5 фокусирующих шагов»
Если посмотреть на алгоритм улучшения (5 фокусирующих шагов), то можно заметить, что мы, возможно, пропустили шаг «подчинить систему ограничению» и сразу перешли к шагу расширения.
Кроме того, возможно, мы нашли не самое простое решение проблемы, а довольно трудоемкое – нужно заново обдумать архитектуру и написать какое-то количество кода. Вместо этого, например, можно было повлиять на «Очередь релизов в конце спринта» - уменьшить длину спринта
О шаге «подчинить систему ограничению» можно думать, как о проверке бизнес-гипотез – мы допускаем, что наше предположение о местонахождении ограничения может быть неверным, поэтому проводим небольшое изменение, не требующее ресурсов:
если пропускная способность конвейера увеличилась, то мы нашли ограничение.
если пропускная способность не изменилась, то мы ошиблись и ограничение находится в другом месте конвейера.
Соответственно, если результатов шага «подчинить систему ограничению» будет недостаточно, то шаг «расширение ограничения», требующий инвестиций, уже не будет «прыжком веры».
Ошибка 2 – Механистическое понимание ТОС
Мы применили «наивную теорию ограничений» - использовали только алгоритм улучшения (5 фокусирующих шагов) и «мыслительный процессы теории ограничений». Но, оказывается, в теории ограничений есть и кое-что ещё: в книге Theory of Constraints by Eliyahu Goldratt упоминается несколько сложностей при попытке начать организационные изменения: сопротивление изменениям, утверждения вроде «это не моя проблема».
И как один из основных способов справиться с этим Голдрат предлагает использовать «сократовский метод» убеждения – не говорить людям как решить проблему, а задавать вопросы, размышления над которыми, приведут к пониманию решения проблемы. Тем самым вы делаете собеседника соавтором идеи, а соавтор идеи вряд ли будет сопротивляться реализации своего творения.
Таким образом, диалоги Ионы и Алекса (героев книги «Цель») – это не только художественный прием, но и иллюстрация применения «сократовского метода».
Ошибка 3 – Выход из зоны применимости TOC
Возможно, мы вышли из зоны применимости ТОС.
С одной стороны, будучи руководителем, наверное, можно задавать вопросы, следуя «сократовскому методу», своим подчиненным (которые не могут убежать), но что делать простым программистам?
Планы
Мы живем в рамках плоской организационной структуры LeSS, поэтому работа выполняется с большой степенью прозрачности, что подсвечивает проблемы, которые в иерархичной структуре были бы незаметны.
Например, в иерархичной структуре некий техлид мог бы «протащить» решение проблемы «20 из 26 релизов нужно устанавливать ночью», не убеждая в пользе такой доработки. Но сколько было бы задач, улучшающих состояние всей системы, а не улучшающих выполнение KPI конкретного человека/отдела? Даже если и большая часть, то, как бы определялось в каком порядке делать такие технические улучшение? Ведь порядок выполнения задач тоже имеет значение – как отмечалось в начале статьи «мы можем делать правильные вещи в неправильном порядке».
Поэтому несмотря на неудачу, мы продолжаем искать пути ускорения поставки. Если у вас есть идеи – пишите в комментариях)
Выученные уроки
Теория ограничений – инструмент, позволяющий проводить ускорение поставки кода итеративным способом без больших трат ресурсов, благодаря акценту на мысленных и производственных экспериментах.
При применении можно легко ошибиться – неверно интерпретировать алгоритм «5 фокусирующих шагов».
Минусы теории ограничений – она ориентирована на формальное лидерство, так как из инструментов убеждения/доказательства необходимости изменений предлагает лишь «сократовский метод».
Ссылки
Теория ограничений
Про "мыслительные процессы" теории ограничений: Теория ограничений Голдратта. Системный подход к непрерывному совершенствованию
Теория ограничений в IT
