Mindbox 15лет развивает B2B-продукт ивырос с3до70человек вразработке. Мытестировали разные подходы кмасштабированию иготовы поделиться опытом, чтобы вам непришлось наступать натеже грабли. Ниже расскажу, как попробовали полную автономию команд ицентрализацию, роняли надежность, демотивировали команды, как врезультате сэтим справились ивыработали свою систему масштабирования.
По материалам выступления на Agile Days 2021:
Надежность как ядро разработки
Чтобы оценить, окаких масштабах разработки инагрузке пойдет речь, расскажу оразмере компании.
ВMindbox одна изсамых нагруженных разработок вРоссии, нопри этом она сохраняет высокую надежность. Когда покупатель пробивает чек накассе вБургер Кинге или аптеке Ригла, транзакция идет кнам. За200 миллисекунд мырассчитываем суммы иотвечаем кассе. Если сервис упал, томного людей повсей стране 24/7 становятся несчастны.
Запоследние 34 года бизнес растет по4050% вгод инагрузка удваивается ежегодно. Внешне всё отлично, ноуMindbox был длинный период становления, который влиял намасштабирование разработки.
Масштаб бизнеса и разработки
Эволюция разработки
Как работает автономия ицентрализация разработки
Проблема масштабирования разработки сводится кпоиску баланса между автономией ицентрализацией. Есть две организационные крайности:
- Автономия. Вомногих компаниях победили автономные инженеры инет никаких сроков. Разработка постоянно закрывает секретный техдолг, абизнес непонимает, как решать крупные задачи. Это заканчивается революцией: бизнес теряет терпение ивносит радикальные изменения впроцессы.
- Централизация. Другая крайность когда побеждает бизнес. Дедлайны спускаются наразработку сверху, задачи бизнеса решаются, нокопится техдолг. Потом процессы опять замедляются иистория заканчивается революцией: предлагают переписать код снуля или продать компанию.
Микросервис имонолит. Две архитектурные крайности микросервис имонолит напрямую несвязаны сописанными типами управления, нопохожи поэффекту. Микросервисы работают быстро, ночем ихбольше, тем больше инфраструктурных задач реализуются несколько раз вместо одного. Вмонолите, наоборот, сначала всё эффективно, нопотом замедляется из-за множества зависимостей.
Мынашли баланс между автономией ицентрализацией: дали техническую автономию продуктовым командам ввопросах сервисов ицентрализовали управление процессами, которые относятся ковсем командам. Ниже расскажем, что это означает икак мыкэтому пришли.
Как внедрили автономию
С2007 по2013 год было мало клиентов ибизнес рос медленно, потому что писали большой исложный продукт. При этом управление разработкой было простым: один главный бизнес-эксперт иглавный архитектор это я и34команды. Делал статусы раз внеделю, потом раз вдве недели ходил покомандам эффективно илегко.
Дали автономию командам. Постепенно бизнес стал прибавлять по4050% вгод, поэтому нужно было запускать больше продуктов ипродвигаться быстрее. Втоже время мыначали строить бирюзовую культуру, прочитали книгу Лалу ирешили, что нужны автономные продуктовые команды сменеджерами продуктов. Иэто заработало запустили новые продукты.
Бирюзовая компания вРоссии: открытые зарплаты, самоуправление, прозрачность иошибки
Фредерик Лалу: Открывая организации будущего
Децентрализовали инфраструктуру. Мырешили, что раз такой подход работает, надо его распространять дальше. Была команда супергероев топовые инженеры, которые поддерживали продакшен иработали над сложными задачами. Чтобы разработка стала ещё быстрее, выделили каждой команде своего эксперта поинфраструктуре, ацентрализованную инфраструктурную команду разделили надве продуктовые. Иэто тоже сработало, разработка продуктов ускорилась.
Уронили надежность. Потом появились нюансы. Большинство наших клиентов изe-commerce, поэтому проводят черную пятницу большую распродажу вконце года, когда унагрузки пиковое значение. Кроме этого, нагрузка ещё иудваивалась каждый год. Втакую черную пятницу сервис упал.
Всё лежит ивсё плохо, чрезвычайная ситуация. Провели спринт надежности иполностью остановили roadmap, чтобы вернуть сервис кжизни. Вкнигах осамоуправлении это называют остановить конвейер, когда все команды бросаются чинить надежность. Имыостановили, ноникто непобежал чинить, потому что половина людей непонимала, вчем проблема икуда бежать. Это было первое наблюдение, апотом надежность вцелом стала резко ухудшаться.
Как внедрили централизацию
Централизовали управление. Прочитали книгу оLeSS (Large Scale Scrum), сходили натренинг ирешили централизовать разработку: внедрить общий roadmap, единое управление иразгрумить эпик надежности.
Врезультате немного улучшили надежность иroadmap начал продвигаться. Мыразделили его набольшие куски, установили очередность продуктов иработали над ними силами всех шести команд.
Внедрили LeSS ироль CTO. Надежность разово починили, ноостался монолит на2миллиона строк кода. Несмотря наточто мыцентрализованно внедрили roadmap ивкаждой команде работали эксперты поинфраструктуре, техдолг ипроблема корневой надежности децентрализованно нерешались.
Так мысоздали роль CTO (chief technical officer), хотя доэтого небыло менеджмента, отвели30% ресурса натехдолг ивнедрили LeSS. Это значит, что70% разработчиков занимались roadmap бизнеса, а30% техническим roadmap, который определяет CTO. Врезультате техдолг начал сокращаться, имыувидели положительные изменения.
LeSS Scrum набольших масштабах
Создали ритуал надежности. CTO предложил, чтобы команды сами приходили ирассказывали, что ипочему они сделали или планируют сделать для надежности. Так появился ритуал надежности. Архитекторы совсех команд, CTO ипродуктовые эксперты собирались раз вдве недели или раз вмесяц иразбирали, какие выявились дефекты икритические баги, вчем была причина ичто нужно чинить наглобальном уровне, ачто решать локально. Так мыввели разумное регулирование идецентрализация заработала.
Демотивировали инженеров именеджеров попродукту. Следом случилась ещё одна черная пятница, исервис снова лег. Это было грустно, хотя мыуже видели, что есть положительные изменения. Ноэто было неглавным.
Главное, что год мыпрожили врежиме LeSS изаметили негативные эффекты для компании. Инженеры именеджеры попродукту были демотивированы. Уинженеров небыло домена ичувства собственности, как увавтономных команд: три месяца они работали над одним продуктом, потом три месяца над другим. Менеджеры попродукту загрустили, потому что roadmap планируется централизованно иtime tomarket стал огромным. Нельзя было взять ивнедрить небольшую доработку для клиента, потому что roadmap управляют централизованно.
Как нашли баланс между автономией ицентрализацией
Вернули командам автономию. Мыувидели, что регулируемая децентрализация работает для повышения надежности, поэтому решили вернуться кистокам, свернуть LeSS иразделить продуктовые команды.
Вернули команду инфраструктурной платформы. Фактически инфраструктура это тоже внутренний продукт, аCTO выполняет роль менеджера попродукту, поэтому выделили отдельную команду под инфраструктуру.
Сточки зрения бирюзы инфраструктурная команда казалась неправильным шагом, новделе это показало себя хорошо, итакая команда мотивировала всех остальных. Сначала мыбоялись, что интересные технические задачи уйдут винфраструктурную команду. Насамом деле выделили для этого отдельных экспертов иотдали задачи, которыми нехотели заниматься разработчики издругих команд.
Оставили30% ресурса команды налокальный техдолг. Мыдоговорились одвухуровневом разделении. Наверхнем уровне30% всего ресурса разработки отдали CTO наинфраструктурную команду итехнический roadmap. Ещё30% отдали натехдолг, который приоритезирует команда. Фактически смомента, когда начались проблемы снадежностью имасштабированием, почти50% всего ресурса это технические задачи.
Техдолг ~30% платформы и 30% команды
около 50% в целом
Внедрили кросс-командный рефайнмент. Это практика изLeSS, которую мымодифицировали. Прежде чем команда начинает работу над каким-то автономным эпиком, она готовит описание ивыносит наобсуждение сдругими командами. Такой подход помогает выявить риски ипонять, как изменения касаются других команд икакие зависимости вмонолите неучли.
Изначально ошибка была втом, что мывыделили автономных менеджеров попродукту, которые создавали интересные фичи, нопри этом небыли экспертами понадежности иинфраструктуре вмонолите. Ито, что они делали, ломало другие фичи из-за чрезмерной централизации. Чтобы снять эти риски, мыоставили кросс-командный рефайнмент.
Из LeSS оставили кросс-командный рефайнмент, чтобы снять риск монолита и управлять roadmap
Ввели автоматический контроль надежности. Чтобы усилить надежность, мыпосоветовались сразными компаниями исделали автоматическую метрику. Раньше клиенты жаловались накритические баги, менеджеры сообщали обэтом разработке имыиханализировали. Атеперь мысоздали автоматические уведомления, который приходят, если нарушаются определенные метрики. Иэто помогло улучшить надежность, потому что навсех статусах мыстали обсуждать формальные вопросы: нарушается SLA или нет.
Несмотря наточто впрошлый раз мыупали вчерную пятницу, было ощущение, что платформа стала надежнее имыдвижемся вверном направлении. Новая метрика доказала наши наблюдения надежность компании действительно росла.
Нарушения SLA среднего клиента вмесяц надежность повышается
Починили надежность. Следующую черную пятницу мыпережили нормально. Это стало доказательством того, что процесс работает иесть положительный эффект для бизнеса.
Создали роль Scrum-мастера. После того как разобрались срисками вдецентрализованном roadmap, справились стехдолгом инадежностью, решили повышать эффективность разработки. Для этого создали роль Scrum-мастера, который собирает весь опыт разработки (developer experience) изаносит вспециальную форму все препятствия ипричины, мешающие разработке. Потом поаналогии состатусами понадежности Scrum-мастера централизованно обсуждают сCTO задачи замесяц, приоритезируют ихичасть добавляют втехдолг.
Создали круги управления. Чтобы комплексно управлять общими аспектами разработки, мыорганизовали виртуальную команду, или круг управления, представители которого сидят вразных командах. Уэтого круга есть набор ритуалов, которые собраны надоске вTrello: встречи побюджету, демонстрации продукта или найму. Такое кросс-командное общение помогает сфокусироваться накаждом процессе инатом, как его улучшить вовсех командах сразу.
Виртуальная команда (круг) управления
Ритуалы управления
Круг управления помогает аккумулировать кросс-командные аспекты: надежность, стоимость железа, найм, developer experience. Для этого проводятся встречи ритуалы управления
Определили метрики разработки. Пока мымасштабировали разработку, нас волновал один вопрос: какие метрики позволяют оценить разработку ичто нужно оптимизировать. Это было неочевидно.
Мызнали, что скорость иroadmap нельзя измерять, потому что есть проблемы стехдолгом иэто только демотивирует разработчиков. Науровне стратегии разработки мысформулировали, что цель разработки оптимизировать непрерывный запуск продуктов (time tomarket) врамках ограничений надежности, стоимости железа ибез увеличения технического долга. Ировно такиеже ожидания сформировали для команды. Команда должна непрерывно поставлять фичи, увеличивать time tomarket, нопри этом поддерживать определенные обязательства понадежности, SLA истоимости.
Когда мысформулировали ожидания, стало легче оценивать результаты разработки. Исходя изэтого мыстроим метрики ипродолжаем оптимизировать разработку.
Показатель эффективности
врамках SLA, стоимости железа ибез увеличения техдолга
| Разработка | Команда |
| Непрерывный запуск и оптимизация time to market новых продуктов, которыми можно гордиться | Непрерывный релиз и оптимизация time to market инкрементов, которые принял клиент на продакшене |
Какую выработали систему масштабирования разработки
Продуктовые команды. Еслибы мысейчас строили разработку снуля, топоумолчанию выделили децентрализованные продуктовые команды. Желательно, чтобы укаждой был свой сервис инебыло монолита нанесколько команд. Наша реальная ситуация оказалась сложнее: есть монолит, поэтому надежность зависит отнего, есть централизованный найм ицентрализованная стоимость облачного железа.
Разумное регулирование общего. Как ядро оставили общие задачи, над которыми должны работать централизованно: roadmap монолита, надежность иинфраструктура, стоимость железа иdeveloper experience. Если нет общих знаний отом, как создаются базовые вещи, топеремещение разработчиков между командами будет затруднено, код будет дублироваться иесть риск потерять эффект масштабной разработки, когда каждая команда существует изолированно отвсех.
