Техдолг

Краткая заметка о том, как в команде Chrome DevTools проходила миграция с внутреннего загрузчика модулей на стандартные модули JavaScript. Рассказываем, насколько и почему затянулась миграция, о скрытых издержках миграции и расскажем о выводах команды DevTools после завершения миграции. Но начнём с истории инструментов веб-разработчика.

Введение

Как вы, возможно, знаете, Chrome DevTools это веб-приложение HTML, CSS и JavaScript. За эти годы DevTools стала многофункциональной, умной и хорошо осведомленной о современной веб-платформе. Хотя DevTools расширился, его архитектура во многом напоминает первоначальную, когда инструмент был частью WebKit.

Мы расскажем историю DevTools, опишем преимущества и ограничения решений и что мы сделали, чтобы смягчить эти ограничения. Поэтому давайте углубимся в модульные системы, в то, как загружать код и то, как мы в конечном счете использовали модули JavaScript.

Вначале не было ничего

Сейчас у фронтенда есть множество модульных систем и их инструментов, а также стандартизированный формат модулей JavaScript. Ничего этого не было, когда начинался DevTools. Инструмент построен поверх кода WebKit, написанного более 12 лет назад.

Первое упоминание о модульной системе в DevTools относится к 2012 году: это было введение списка модулей с соответствующим списком исходников. Часть инфраструктуры Python, используемой в то время для компиляции и сборки DevTools. В 2013 года модули были извлечены в файл frontend_modules.json этим коммитом, а затем, в 2014 году, в отдельные module.json (здесь). Пример module.json:

{  "dependencies": [    "common"  ],  "scripts": [    "StylePane.js",    "ElementsPanel.js"  ]}

С 2014 года module.json используется в инструментах разработчика для указания на модули и исходные файлы. Тем временем экосистема веба быстро развивалась, и было создано множество форматов модулей: UMD, CommonJS и в конечном итоге стандартизированные модули JavaScript. Однако DevTools застрял на module.json. Не стандартизированная, уникальной модульная система имела несколько недостатков:

1. module.json требовал собственные инструменты сборки.
2. Не было интеграции с IDE. Конечно же, она требовала специальных инструментов для создания файлов, понятных ей: (оригинальный скрипт генерации jsconfig.json для VS Code).
3. Функции, классы и объекты были помещены в глобальную область видимости, чтобы сделать возможным совместное использование между модулями.
4. Был важен порядок перечисления файлов. Не было никакой гарантии, что код, на который вы полагаетесь, загружен, кроме проверки человеком.

В целом, оценивая текущее состояние модульной системы DevTools и других, более широко используемых форматов модулей, мы пришли к выводу, что module.json создавал больше проблем, чем решал.

Преимущества стандарта

Мы выбрали модули JavaScript. Когда принималось это решение, модули в языке еще включались флагом в Node.js и большое количество пакетов NPM не поддерживало их. Несмотря на это, мы пришли к выводу, что модули JavaScript были лучшим вариантом.

Основное преимущество модулей в том, что это стандартизированный в языке формат. Когда мы перечислили минусы module.json, мы поняли, что почти все они были связаны с использованием не стандартизированного, уникального формата модуля. Выбор не стандартизированного формата модуля означает, что мы должны вкладывать время в построение интеграций с помощью инструментов сборки и инструментов наших коллег. Такие интеграции часто были хрупкими и не поддерживали функции, требуя дополнительного времени на техническое обслуживание, а иногда приводя к хитрым багам. Баги в конечном итоге доставались пользователям.

Поскольку модули JavaScript были стандартными, это означало, что IDE, такие как VS Code, инструменты проверки типов, похожие на компилятор Closure/TypeScript, и инструменты сборки вроде Rollup и минификаторов смогут понять написанный исходный код. Более того, когда новый человек присоединяется к команде DevTools, ему не приходится тратить время на изучение проприетарного module.json.

Конечно, когда DevTools только начинались, ни одно из вышеперечисленных преимуществ не существовало. Потребовались годы работы в группах стандартов, при реализации среды выполнения. Потребовалось время на отзывы от разработчиков пользователей модулей. Но когда модули в языке появились, у нас был выбор: либо продолжать поддерживать наш собственный формат, либо инвестировать в переход на новый формат.

Сколько стоит блеск новизны?

Несмотря на то, что модули JavaScript имели множество преимуществ, которые мы хотели бы использовать, мы оставались в мире module.json. Использование преимуществ модулей языка означало, что мы должны вкладывать значительные усилия в технический долг. Между тем, миграция могла вывести из строя функции и ввести баги регрессии.

Речь не шла о том, использовать ли мы модули JavaScript. Стоял вопрос, как дорого стоит возможность использовать модули JavaScript. Мы должны были уравновесить риск раздражения пользователей регрессиями, затратами времени инженеров на миграцию и периодом ухудшением состояния системы, в котором мы будем работать.

Последний пункт оказался очень важным. Несмотря на то, что теоретически мы могли добраться до модулей JavaScript, во время миграции мы получили бы код, который должен был бы учитывать оба типа модулей. Такое не только технически сложно, но и означает, что все инженеры, работающие над DevTools, должны знать, как работать в такой среде. Они должны были бы постоянно спрашивать себя: Что происходит в этом коде, это module.json или JS, и как я могу внести изменения?.

Скрытая стоимость миграции в смысле обучения коллег была больше, чем мы ожидали.

После анализа затрат мы пришли к выводу, что все же стоит перейти на модули в языке. Поэтому нашими основными целями были:

1. Убедиться, что стандартные модули максимально полезны.
2. Убедиться, что интеграция с существующими модулями на базе module.json безопасна и не приводит к негативному воздействию на пользователя (ошибки регрессии, разочарование пользователя).
3. Давать руководства по миграции DevTools. В первую очередь с помощью встроенных в процесс сдержек и противовесов, чтобы предотвратить случайные ошибки.

Электронная таблица, преобразования и технический долг

Цель была ясна. Но ограничения module.json оказалось трудно обойти. Потребовалось несколько итераций, прототипов и архитектурных изменений, прежде чем мы разработали удобное решение. Мы закончили тем, что написали проектный документ со стратегией миграции. В этом документе указывалась первоначальная оценка времени: 2-4 недели.

Самая интенсивная часть миграции заняла 4 месяца, а от начала до конца прошло 7 месяцев!

Первоначальный план, однако, выдержал испытание временем: мы хотели научить среду выполнения DevTools загружать все файлы, старым способом использовать перечисленные в массиве scripts module.json, в то время как все файлы, перечисленные в массиве modules должны были загружаться динамическим импортом языка. Любой файл, который будет находиться в массиве modules, может работать с import и export из ES6.

Кроме того, мы хотели мигрировать в 2 фазы. В конечном итоге мы разделили последнюю фазу на 2 подфазы: экспорт и импорт. Модули и фазы отслеживались в большой электронной таблице:


Фрагмент таблицы миграции здесь.

Фаза экспорта

Первым этапом было добавление операторов экспорта для всех сущностей, которые должны быть разделены между модулями/файлами. Трансформация автоматизировалась с помощью запуска скрипта для каждой папки. Допустим, в module.json есть такая сущность:

Module.File1.exported = function() {  console.log('exported');  Module.File1.localFunctionInFile();};Module.File1.localFunctionInFile = function() {  console.log('Local');};

Здесь Module это имя модуля. File1 имя файла. В дереве кода это выглядит так: front_end/module/file1.JS.

Код выше преобразуется в такой:

export function exported() {  console.log('exported');  Module.File1.localFunctionInFile();}export function localFunctionInFile() {  console.log('Local');}/** Legacy export object */Module.File1 = {  exported,  localFunctionInFile,};

Первоначально мы планировали переписать импорт в один файл на этом этапе. Например, в приведенном выше примере мы бы переписали Module.File1.localFunctionInFile на localFunctionInFile. Однако мы осознали, что было бы проще автоматизировать и безопаснее разделить эти два преобразования. Таким образом, перенос всех сущностей в один файл станет второй подфазой импорта.

Поскольку добавление ключевого слова export превращает файл из скрипта в модуль, большая часть инфраструктуры DevTools должна была быть обновлена соответствующим образом. Инфраструктура включала среду выполнения с динамическим импортом, а также такие инструменты, как ESLint для запуска в режиме модуля.

Одна неприятность заключалась в том, что наши тесты выполнялись в нестрогом режиме. Модули JavaScript подразумевают, что файлы работают в строгом режиме. Это влияло на тесты. Как оказалось, нетривиальное количество тестов полагалось на нестрогий режим, включая тест, в котором присутствовал оператор with.

В конце концов, обновление самой первой папки (добавление export) заняло около недели и несколько попыток с перекладываниями.

Фаза импорта

После того как все сущности были экспортированы с помощью export-операторов, оставаясь в глобальной области видимости из-за легаси, нам пришлось обновить все ссылки на сущности, если они в нескольких файлах, чтобы использовать импорт ES. Конечная цель удаление всех устаревших объектов экспорта очисткой глобальной области видимости. Трансформация автоматизировалась с помощью запуска скрипта для каждой папки.

Например, следующие сущности module.json:

Module.File1.exported();AnotherModule.AnotherFile.alsoExported();SameModule.AnotherFile.moduleScoped();

Преобразуются в:

import * as Module from '../module/Module.js';import * as AnotherModule from '../another_module/AnotherModule.js';import {moduleScoped} from './AnotherFile.js';Module.File1.exported();AnotherModule.AnotherFile.alsoExported();moduleScoped();

Однако при таком подходе есть оговорки:

1. Не каждая сущность была названа по принципу Module.File.symbolName. Некоторые сущности были названы Modele.File или даже Module.CompletelyDifferentName. Несоответствие означало, что мы должны были создать внутреннее сопоставление от старого глобального объекта к новому импортированному объекту.
2. Иногда возникали конфликты имен moduleScoped. Наиболее заметно, что мы использовали шаблон объявления определенных типов Events, там, где каждая сущность названа просто Events. Это означало, что при прослушивании нескольких типов событий, объявленных в разных файлах, в операторе import у этих Events возникнет коллизия именования.
3. Как оказалось, между файлами существовали циклические зависимости. Это было прекрасно в контексте глобальной области видимости, так как сущность использовалась после загрузки всего кода. Однако, если вам требуется импорт, циклическая зависимость проявит себя. Такое не приводит к проблеме сразу, если только у вас нет побочных вызовов функций в коде глобальной области видимости, (они были у DevTools). В общем, потребовалось некоторое хирургическое вмешательство и рефакторинг, чтобы обезопасить трансформацию.

Дивный новый мир модулей JavaScript

В феврале 2020 года, через 6 месяцев после старта в сентябре 2019 года, были выполнены последние очистки в папке ui/. Так миграция неофициально закончилась. Когда осела пыль, мы официально отметили миграцию как законченную 5 марта 2020 года.

Теперь DevTools работают только с модулями JavaScript. Мы все еще помещаем некоторые сущности в глобальную область видимости (в файлах легаси module.js) для устаревших тестов или интеграций с другими частями инструментов разработчика архитектуры. Они будут удалены со временем, но мы не рассматриваем их как блокирующие развитие. У нас также есть руководство по стилю работы с модулями JavaScript.

Статистика

Консервативные оценки количества CL (аббревиатура changelist термин, используемый в Gerrit, аналогичное пул-реквесту GitHub), участвующих в этой миграции, составляют около 250 CL, в основном выполняемых 2 инженерами. У нас нет окончательной статистики о размере внесенных изменений, но консервативная оценка измененных строк (сумма абсолютной разницы между вставками и удалениями для каждого CL) составляет примерно 30 000 строк, то есть около 20% всего интерфейсного кода DevTools.

Первый файл с применением экспорта поддерживается в Chrome 79, выпущенном в стабильном релизе в декабре 2019 года. Последнее изменение для перехода на импорт поставляется в Chrome 83, выпущенном в стабильном релизе в мае 2020 года.

Мы знаем об одной регрессии из-за миграции в стабильном Chrome. Автозавершение фрагментов кода в меню команд сломалось из-за постороннего экспорта по умолчанию. Было и несколько других регрессий, но наши автоматизированные тестовые наборы и пользователи Chrome Canary сообщили о них. Мы исправили ошибки до того, как они могли попасть в стабильные релизы Chrome.

Вы можете увидеть всю историю, зарегистрировавшись здесь. Не все, но большинство CL привязано к этой ошибке.

Чему мы научились?

1. Принятые в прошлом решения могут оказать долгосрочное влияние на ваш проект. Несмотря на то, что модули JavaScript (и другие форматы модулей) были доступны в течение довольно долгого времени, DevTools не был в состоянии оправдать миграцию. Решение о том, когда мигрировать, а когда нет, трудно и держится на обоснованных догадках.
2. Первоначальные оценки времени недели, а не месяцы. В значительной степени это связано с тем, что мы обнаружили больше неожиданных проблем, чем ожидали при первоначальном анализе затрат. Даже при том, что план миграции был основательным, технический долг блокировал работу чаще, чем нам хотелось бы.
3. Миграция включала большое количество (казалось, не связанных между собой) очисток технического долга. Переход к современному стандартизированному формату модулей позволил нам перестроить лучшие практики кодирования на современную веб-разработку. Например, мы смогли заменить пользовательский упаковщик Python на минимальную конфигурацию Rollup.
4. Несмотря на большое влияние на нашу кодовую базу (~20% измененного кода), было зарегистрировано очень мало регрессий. Хотя было много проблем с миграцией первых двух файлов, через некоторое время у нас был надежный, частично автоматизированный рабочий процесс. Это означало, что негативное влияние на наших стабильных пользователей было минимальным.
5. Научить коллег тонкостям конкретной миграции трудно, а иногда и невозможно. Миграции такого масштаба трудно отслеживать и они требуют большого объема знаний в предметной области. Передача этих знаний другим людям, работающим в той же кодовой базе, сама по себе нежелательна для работы, которую они выполняют. Знание того, чем делиться, а чем не делиться необходимое искусство. Поэтому крайне важно сократить количество крупных миграций или, по крайней мере, не выполнять их одновременно.

Узнайте подробности, как получить востребованную профессию с нуля или Level Up по навыкам и зарплате, пройдя онлайн-курсы SkillFactory:

• Профессия Java-разработчик с нуля (18 месяцев)
• Курс по JavaScript (12 месяцев)

Eще курсы

• Обучение профессии Data Science с нуля (12 месяцев)
• Профессия Веб-разработчик (8 месяцев)
• Курс по Machine Learning (12 недель)
• Продвинутый курс Machine Learning Pro + Deep Learning (20 недель)
• Курс Математика и Machine Learning для Data Science (20 недель)
• Курс Python для веб-разработки (9 месяцев)
• Курс по DevOps (12 месяцев)
• Профессия аналитика с любым стартовым уровнем (9 месяцев)
• Профессия UX-дизайнер с нуля (9 месяцев)
• Профессия Web-дизайнер (7 месяцев)

Недавно новый сотрудник спросил меня за обедом: Какой у нас техдолг?

Услышав вопрос, я не мог не улыбнуться. Спрашивать инженеров-программистов о техническом долге компании это то же самое, что спрашивать о кредитном рейтинге. Так программисты хотят узнать о сомнительном прошлом компании и о том, с каким багажом из прошлого придётся столкнуться. К техническому багажу нам не привыкать.

Как поставщик облачных услуг, который управляет собственными серверами и оборудованием, мы столкнулись с проблемами, с которыми многие другие стартапы в новую эру облачных вычислений не сталкивались. Эти сложные ситуации в конце концов привели к компромиссу, на который нам пришлось пойти, когда компания только начала работать. И, как известно любой быстрорастущей компании, технические решения, которые вы принимаете на раннем этапе, обычно догоняют вас.

Глядя на нового сотрудника, я глубоко вздохнул и начал: Давай я расскажу о том, как у нас было 15 000 прямых подключений к БД

История, которую я рассказал нашему новому сотруднику, это история крупной технической перестройки DigitalOcean. Работала вся компания, эта работа продолжалась несколько лет и преподала нам много уроков.

---

Как всё начиналось

С самого начала DigitalOcean была одержима простотой. Стремление к простым и элегантным решениям одна из наших основных ценностей. Это касается не только продуктов, но и технических решений. Более всего этот подход выделялся в первоначальной архитектуре системы.

Как и GitHub, Shopify и Airbnb, DigitalOcean начиналась как приложение Rails в 2011 году. Внутри компании приложение называли Cloud, оно управляло всеми взаимодействиями с пользователем как в интерфейсе пользователя, так и в общедоступном API. Сервису Rails помогали два сервиса Perl: Scheduler и DOBE (DigitalOcean BackEnd). Планировщик планировал и назначал дроплеты гипервизорам, а DOBE отвечал за создание реальных виртуальных машин дроплетов. В то время как Cloud и Scheduler работали как автономные службы, DOBE работал на каждом сервере парка машин.

Cloud, Scheduler, DOBE общались друг с другом не напрямую, а через базу данных MySQL, которая выполняла две роли: хранила данные и была посредником при обмене данными. Все три службы использовали одну таблицу базы данных в качестве очереди сообщений, чтобы передавать информацию.

Каждый раз, когда пользователь создавал новый дроплет, Cloud вставлял новую запись о событии в очередь. Scheduler непрерывно, каждую секунду опрашивал БД на предмет новых событий Droplet и планировал их создание на доступном гипервизоре. Наконец, каждый экземпляр DOBE ждал создания новых запланированных дроплетов и выполнял задачу. Чтобы серверы могли обнаружить любые новые изменения, каждому нужно было опросить базу данных на предмет новых записей в таблице.


Хотя бесконечные циклы и прямое подключение каждого сервера к базе данных могли быть рудиментарными, с точки зрения проектирования системы, это было просто и работало особенно для небольшой технической команды, которая сталкивалась с жёсткими сроками, а пользователей становилось всё больше.

Четыре года очередь сообщений базы данных составляла основу технологического стека DigitalOcean. В это время мы приняли архитектуру микросервисов, для внутреннего трафика заменили HTTPS на gRPC, вместо Perl внутренние сервисы стали писать на Golang. Однако все дороги по-прежнему вели к той самой базе данных MySQL.

Важно отметить, что если код легаси, это не означает, что он не работает и его нужно переписать. У Bloomberg и IBM есть устаревшие сервисы, написанные на Fortran и COBOL, которые приносят доход больше, чем целые компании. С другой стороны, у каждой системы есть предел масштабирования. Мы собирались ударить по нашему.

С 2012 по 2016 год пользовательский трафик DigitalOcean вырос более чем на 10 000 %. Мы добавили больше продуктов в наш каталог и больше сервисов в нашу инфраструктуру. Событий в очереди базы данных стало больше. Повышенный спрос на дроплеты означал, что Scheduler, чтобы назначить их все серверам, работал с превышением штатной нагрузки. И, к сожалению для Scheduler, количество доступных серверов не было постоянным.


Чтобы не отставать от растущего спроса на дроплеты, мы добавляли всё больше и больше серверов для обработки трафика. Каждый новый гипервизор означал еще одно постоянное соединение с базой данных. К началу 2016 года у базы было более 15 000 прямых подключений, и каждое запрашивало новые события через одну-пять секунд. Если и этого было недостаточно, то SQL-запрос, который каждый гипервизор использовал для получения новых событий дроплет, также стал сложнее. Он превратился в колосс из более чем 150 строк и JOIN в 18 таблиц. Этот код впечатлял настолько же, сколько рискованно и трудно было его поддерживать.

Не удивительно, что именно тогда система треснула. Единая точка отказа с тысячами зависимостей, которые боролись за общие ресурсы, время от времени неизбежно обращалась в хаос. Таблицы блокировались и запросы не выполнялись, и это приводило к сбоям, падала производительность.

Из-за тесной связи в системе не было чёткого или простого решения проблемы. Cloud, Schedule и DOBE оказались узкими местами. Патчи только одного или двух компонентов сместили бы нагрузку на оставшиеся узкие места. Поэтому после долгих раздумий инженеры разработали план исправления из трёх пунктов:

1. Уменьшить количество прямых подключений к базе данных.
2. Переписать алгоритм ранжирования Scheduler, чтобы повысить доступность этого сервиса.
3. Освободить БД от ответственности за очередь сообщений.

Переписываем код: начало

Чтобы справиться с зависимостями базы данных, инженеры DigitalOcean создали Event Router. Маршрутизатор событий служил региональным прокси-сервером, который опрашивал базу данных от имени каждого экземпляра DOBE в каждом центре обработки данных. Вместо тысяч серверов, каждый из которых запрашивает базу данных, осталась только горстка выполняющих запрос прокси. Каждый прокси-сервер маршрутизатора событий будет извлекать все активные события в определённом регионе и делегировать каждое событие соответствующему гипервизору. Event Router также разбил гигантский опрашивающий запрос на запросы, которые проще поддерживать.


Когда Event Router был запущен, он сократил количество подключений к базе данных с более чем 15 000 до менее 100.

Затем инженеры нацелились на планировщика. Как упоминалось ранее, Scheduler был сценарием Perl и определял, в каком гипервизоре разместить дроплет. Делалось это с помощью серии запросов, чтобы сортировать и ранжировать серверы. Всякий раз, когда пользователь создаёт дроплет, планировщик обновляет строку таблицы на лучшую машину.

Хотя это звучит достаточно просто, Scheduler имел несколько недостатков. Его логика была сложной, работать с ней было непросто. Он был однопоточным, и его производительность снижалась во время пиковой нагрузки. Наконец, был только один экземпляр Scheduler и он должен был обслуживать весь парк. Это узкое место было неизбежным. Чтобы решить эти проблемы, команда инженеров разработала Scheduler V2.

В обновлённом планировщике переработали всю систему ранжирования. Вместо того чтобы запрашивать у базы данных показатели сервера, планировщик агрегировал их из гипервизоров и хранил в собственной базе данных. Кроме того, команда Scheduler применила параллелизм и репликацию, чтобы их новый сервис под нагрузкой оставался производительным.

Event Router и Scheduler v2 были большими достижениями, они устраняли многие недостатки архитектуры. Но даже с ними имела место большая препона [прим. перев. это несколько удивительно, но слово препона женского рода]. К началу 2017 года централизованная очередь сообщений MySQL всё ещё использовалась. Она обрабатывала до 400 000 новых записей в день и обновлялась 20 раз в секунду.

К сожалению, удалить очередь сообщений из базы данных было нелегко. Сначала инженеры запретили сервисам прямой доступ к базе. База нуждалась в дополнительном уровне абстракции. Слою также требовался API, чтобы агрегировать и выполнять запросы от его имени. Если какой-либо сервис захочет создать новое событие, ему нужно будет сделать это через API. Так родился Harpoon.

Достичь согласия труднее, чем вы думаете

Однако создать интерфейс очереди сообщений было легко. Труднее оказалось достичь согласия с другими командами. Интеграция с Harpoon означала, что командам пришлось бы отказываться от доступа к базе данных, переписывать куски своего кода и, в конечном счёте, изменить свои привычки. Это было нелегко.

Команда за командой и сервис за сервисом инженеры Harpoon смогли перенести всю кодовую базу на свою новую платформу. На это ушёл почти год, но к концу 2017 года Harpoon стал единственным издателем очереди сообщений базы данных.

Началась настоящая работа. Полный контроль над системой событий означал, что с Harpoon мы получили свободу переосмыслить рабочий процесс дроплета.

Первой задачей Harpoon было взять на себя обязанности по очереди сообщений из базы данных. Для этого Harpoon создал собственную внутреннюю очередь сообщений, состоящую из RabbitMQ и асинхронных воркеров. Пока Harpoon отправлял новые события в очередь с одной стороны, воркеры забирали их с другой стороны. А поскольку RabbitMQ заменил очередь базы данных, воркеры могли напрямую общаться с планировщиком и маршрутизатором событий. Таким образом, вместо того чтобы Scheduler V2 и Event Router опрашивали базу данных на предмет изменений, Harpoon отправлял обновления к ним напрямую. На момент написания этой статьи, в 2019 году, архитектура событий дроплет всё ещё работает.

Прогресс DigitalOcean

За последние семь лет мы выросли из группы в гараже до признанного провайдера облачных сервисов, которым являемся сегодня. Как и другие технологические компании, которые занимались переходной экономикой, мы постоянно работаем с устаревшим кодом и техническим долгом. Будь то дробление монолитов, создание мультирегиональных сервисов или устранение единых точек отказа, мы, инженеры, всегда работаем, чтобы создать простые и элегантные решения. Я надеюсь, что эта история окажется полезной для других разработчиков, которые ломают голову над техническим долгом.

---

• Профессия Веб-разработчик
• Профессия QA-инженер на JAVA

Весна 2020 показала, что благодаря DevOps-практикам многие бизнесы смогли быстро перестроить продукты и перейти в онлайн, сохранив работоспособность. Оказалось, что от зрелости практик DevOps зависят не только результаты бизнеса, но и само его выживание.

Наши встречи на конференции DevOpsConf концентрировались не только на инструментарии инженеров, а еще и на процессах, для которых эти инструменты нужны. Кажется, этого недостаточно, чтобы бизнес увидел, как извлечь из DevOps максимум пользы для продукта.

Поэтому мы добавили фокус на том, как людям в разных позициях определить, какой зрелости DevOps-практик удалось добиться и как сознательно выбрать цели технического развития в своей организации и команде. Иными словами, я хочу увидеть, где на поле DevOps я сейчас нахожусь, и каков мой следующий шаг.



Основные измеряемые характеристики DevOps это стабильность работы приложений и производительность IT-команд, от идеи до выкладки фичи на продакшн. Поэтому мы много говорим о time to market и мониторинге и продолжаем технический трек.

А ещё IT-команды состоят из живых людей, которые не только могут выдавать хорошие KPI, а ещё и делают заведомо полезную работу. Ведь если DevOps-подход завоевал популярность в мире, то, наверное, это кому-то нужно. Для вас мы повстречались с Product Owners и бизнесменами, которые не всегда знают, что такое DevOps (как будто мы знаем :D) и расспросили их о том, что же им важно получить от технарей. В чём эта самая польза.

Первым делом пришлось поменять свой словарь и способ общения. Мы говорили не нашими привычными терминами, а старались использовать язык продактов. Даже в качестве способа общения мы выбрали CustDev-интервью, как и принято в продуктовом мире. Эти интервью подтверждают или опровергают наши гипотезы о том, что же важно в работе над продуктом со стороны бизнеса.

Вот какие гипотезы мы проверяли на встречах:

• TTM важен для интересов Product Owner-а.
• Стабильность работы приложения влияет на бизнесовые показатели.
• Разработчики зачастую не согласны с мнением PO о том, что и как делать.
• TTM помогает проводить CustDev. Речь не о технике интервью, а о поиске и подтверждении потребностей клиентов и построении компании.

Я беседую через с Zoom со своей давней знакомой, которая убеждена, что человеку, который ни разу в жизни не продавал, нечего делать в профессии Product Owner. Она часто появляется в передачах на радио и ТВ, проводит семинары по своей предметной области. Как только режим самоизоляции был облегчён, они с мужем и ребёнком арендовали дом на берегу великолепного озера и на всё лето переехали жить и работать туда. Её компания почти 20 лет на рынке онлайн-услуг. На первом месте по рейтингам в своей предметной области.

Скажи пожалуйста, проводишь ли ты специальную работу по сокращению цикла разработки и запуска фич в продакшн в своей команде?

Ты знаешь, уже нет. Если в 2014 году бутылочным горлышком была производительность айтишников, как разработки с тестированием, так и команды эксплуатации, то уже несколько лет я решаю другую задачу. Как успеть подготовить эксперименты, чтобы команде было, чем заняться (смеётся). Если говорить серьёзно, то сейчас я уверена, что фича будет запущена за срок от шести часов до недели...

Погоди, 6 часов?! Это...

От первой беседы с командой до пользователя. Т.е. уже на проде.

Зачем тебе такая скорость?

Я не ставила такой цели. Скорее, я склоняюсь к мысли, что это естественное следствие тех изменений в инструментарии разработки и эксплуатации и настройки взаимодействия между командами и мной, как представителем бизнеса.

Мы продолжили беседу, и за следующие полчаса Наталья рассказала, что крупные изменения продукта сейчас проходят гораздо увереннее и спокойнее. Основным фактором такого изменения она называет её уверенность в команде и доверие команды к ней.

Следующий мой звонок на Пхукет. Игорь переехал туда несколько лет назад и для этого провел не самые простые переговоры со своим работодателем. Тогда удалённая работа была в диковинку, и все сотрудники работали в офисе в Москве. Сейчас за кадром слышны визги и возня его большой семьи. Его компания тоже лидирует на российском рынке по своему направлению.

Внезапно я стал экспертом по удалёнке этой весной! (смеётся)

Расскажи пожалуйста, какие сознательные шаги ты делал для того, чтобы увеличить стабильность работы приложения и зачем?

Когда мы с техдиром начали эту работу, ещё не были в ходу такие термины, как LTV, customer retention или unit economy. Просто мы представили, что пользователи не очень довольны падением приложения 20% времени...

Во, NPS!

Андрей, не было никакого NPS. Сейчас это технологизированный индикатор того, насколько довольны пользователи. Он не покажет мне деньги. Он не покажет, каково отношение затрат на какой-либо проект и отдачи в деньгах от его реализации.

Тебе именно это отношение важно?

Мне важен рост аудитории. Т.е. её лояльность и приверженность к моему продукту.

Что-то ещё? Как маркетинг связан с аптаймом?

Смотри, налить трафик стоит денег. Будь то прямая реклама или SEO оптимизация, органические переходы. Когда в трафик вложены ресурсы, а на стороне приложения он попадает в черную дыру, то это немножечко потери.

Т.е. для тебя сейчас важно, чтобы приложение было доступно.

Сейчас я спокоен, потому что наш аптайм 4,5 девятки. В течение месяца приложение исправно отвечает на 99,995% запросов.

DevOps сделал своё дело, DevOps может...

DevOps ещё и не это может. В какой-то момент мы посчитали, что наш способ развития, через изменения в лаборатории и проверку на фокус-группах, дороже, чем проверка на малых долях аудитории. Вместо того, чтобы разработать прототип, собрать фокус группу и получить одобрение, а потом на живых пользователях увидеть их разочарование, я могу быстро-быстро проверить трипять вариантов на 0,1% пользователей и выбрать лучший.

Т.е. разработчики наговнокодят что-то быстро на костылях, а потом ты выберешь удачный вариант.

Да, из палок и синей изоленты. (Игорь морщится, потому что я на громкой связи, а рядом дети)

Я вижу здесь две потенциальных проблемы. Во-первых, разработчики недовольны, что часть их работы будет заведомо выброшена. Во-вторых, те фичи, которые выстрелили, остаются костылями.

Поэтому для нас важно управлять техдолгом. Можно сказать, что между бизнесом и IT есть контракт: в течение года не менее 30% времени разработки идёт на разгребание долга. Причём, эти проценты мы считаем совокупно за год. Например, весной 2020 мы перекрыли работу с техдолгом полностью, потому что нам была важна скорость изменения продукта. Нам пришлось искать новые модели использования наших сервисов.

Значит ли это, что за оставшиеся полгода ребята будут уже 40% времени заниматься рефакторингом, изменением архитектуры и выпиливанием костылей, а также работать с производительностью приложения?

Абсолютно.

Дальше Игорь рассказал, что у него появилась возможность работать на опережение. Значительная часть задач направлена на освоение новых технологий и интерфейсов. Первые результаты экспериментов уже доступны пользователям, например общение на естественном языке. При этом на сегодняшний день скорее можно говорить о Research части R&D. Компания осваивает технологии заранее, чтобы использовать момент зрелости технологий искусственного интеллекта для получения конкурентного преимущества.

Если говорить об экспериментах, то настройки приложения разделили на три основные группы:

• Продуктовые. Product owner может включить или отключить фичу, а также раскатать её на заданный процент пользователей или даже конкретный список.
• Настройки взаимодействия сервисов это зона ответственности разработчиков.
• Админские, их крутит команда, которая занимается инфраструктурой.

Любопытно, что первый запрос на разделение настроек пришёл из эксплуатации, когда релизы ещё запускались вручную. 20 релизов в день для изменения настроек это не то, что радовало админов. Уже когда сервис настроек был готов, то это создало техническую готовность крутить ручки владельцам продукта.

Мы также созвонились с ребятами, которые ведут продукт в компаниях, где потенциал для развития DevOps намного больше. Они запускают стартапы или работают на крупного заказчика. Другими словами и больше через боль, они говорили о тех же ценностях для Product Owner-а, что и предыдущие собеседники.

Мы обнаружили, что находки нашего исследования подтверждают те выводы, которые есть в в отчете Google The 2019 Accelerate State of DevOps: Elite performance, productivity, and scaling (версия на русском).

Мы выделили четыре основные ценности для Product Owner-ов при использовании DevOps:

• Предсказуемость времени реализации фичи и уверенность в качестве софта это необходимая база для активных экспериментов.
• Надёжность работы прода = деньги. Когда трафик попадает на работающее приложение, то это не только позволяет рационально использовать бюджет на продвижение, но ещё и повышает лояльность пользователей, а значит и долю на рынке.
• Скорость экспериментов определяет успех как для стартапа, так и для бизнеса со зрелым продуктом. Если стартапу важно быстро обнаружить предпочтения пользователей и удачные ответы на них, то зрелому продукту нужно удержание пользователей, стабильность массовой выручки и research работа на будущее технологий.
• Доверие к разработчикам и взаимное доверие разработчиков к продакту. Партнёрские отношения между IT подразделением и бизнес юнитами, когда заключается контракт о способах взаимодействия и этот договор исполняют обе стороны. В терминах DevOps это управление техдолгом, поддержка кода в порядке и вовлечение команды в интерес своих пользователей.

Поэтому на конференции поговорим как о важных технических темах, так и о новых. Например, про доверие расскажет Алексей Пикулев, который готовит воркшоп по диагностике и развитию доверия. Продолжим исследовать инженерные практики и инструменты, а также организацию процессов. Коммуникацию бизнеса с командой и между командами будем обсуждать на уже традиционном процессном треке конференции.

Ребята, не беспокойтесь о том, будет ли на конференции по-прежнему много технических докладов. Потому что мы, члены программного комитета, любим системных администраторов и DevOps-инженеров, которых нет. И даже сами ими являемся.

Большинство активностей на конференции сделаем интерактивными, потому что говорящих голов достаточно в интернете. Ведь каждый сознательный инженер может не только найти видео докладов по нужной ему тематике, но и прочитать статьи (например, статьи по следам всех DevOpsConf в профиле Александра Титова).

Наша цель этой осенью дать каждой компании возможность высадить виртуальный десант из Product Owner-ов, техлидов и инженеров всех мастей. Так, чтобы IT-спецназ сориентировался на местности и вернулся в работу с разработанным планом захвата Вселенной!

В следующих статьях расскажем про CTO, разработчиков и безопасников зачем конференция им.

DevOps Live пройдет онлайн 29-30 сентября и 6-7 октября 2020. В онлайне будет всё, за что сообщество любит наши конференции, и при этом мы вместе исследуем новые возможности онлайна.

Пока до конференции есть немного времени подписывайтесь на рассылку: будем присылать письма с новостями о программе, анонсами докладов (и расшифровками с прошлых конференций), а также с разными сюрпризами. И подавайте заявки на доклады или мастер-классы, если хотите повлиять на развитие DevOps в России. А если вы продакт, которому весь этот DevOps только мешает, напишите в комментариях, как вам удается держаться на плаву.

DevOps обычно рассматривается в двух ипостасях:

1. Инструментарий техника, tooling, технические процессы, CI/CD и прочие штуки авто-всё, всё как код и т.д.
2. Культура это как отдельным разработчикам прийти всем вместе к мир, дружба, жвачка.

На стыке этого у людей происходит некоторый слом, и они не понимают ОК, есть DevOps, есть автоматизация, у нас всё это есть. Но, ребята, у нас команда из 10 человек мы не можем, например, пилить процессинг на банк, или сервис для нашего биллинг-оператора, или что-то еще такое. 10 человек та самая Scrum-команда, которой предлагается всё это сделать, не могут этого технически.

У таких команд, помимо мы так не умеем, потому что так раньше не делали, есть и другие вызовы. Михаил Бижан рассказал на конференции DevOps Conf 2019 о тех, с которыми встретилась его команда в Райффайзенбанке, и как они это решали. Михаил отвечает за автоматизацию в банке, вместе с командой внедряя инженерные практики и поддерживая инструменты автоматизации.

Раньше Михаил уже внедрял культуру DevOps в Сбербанке. Но до этого, работая на стороне интегратора (в основном на госов) наловил кучу анти-паттернов. Потому что чем характерны госзаказчики? Годовалыми проектами, невообразимыми бюджетами и полным отсутствием намека на Agile и DevOps. Там все строго. Сначала ты пишешь ТЗ, чтобы стопка бумаги была метр от пола. Если меньше, это не ТЗ (и даже не проект) это несерьёзно. Потом ты разрабатываешь, а если что-то не получается виноват ты и денег не получаешь (хотя госзаказчик, скорее всего, все равно счастлив, потому что бюджет освоен и что-то формальное достигнуто).

Так что у Михаила большой опыт в том, как делать не надо. А как делать можно понимает из чтения книг и общения с сообществом и коллегами. Как системный аналитик, Михаил не старается решить всё методами разработки, а анализирует проблему, чтобы понять её root cause и сделать так, чтобы она больше никогда не повторялась. На этом сочетании и построен доклад.



Сегодня поговорим о том, что болит у всех и всегда, и что иногда кажется невозможным о кросс-функциональности в энтерпрайзе. Энтерпрайз это любая компания, которая разрабатывает более, чем один IT- продукт. Если у вас языковая школа, и вы пилите в целом всё для неё, у вас вряд ли энтерпрайз. А если у вас, например, универсальный банк, где есть розничное кредитование, факторинг, кэш-менеджмент, и все это legacy, спагетти-код и прочее, скорее всего, у вас энтерпрайз. Или если вы системный интегратор, у вас тоже может быть энтерпрайз, потому что вы пилите для большого количества заказчиков всякое счастье и используете все виды технологий, процессов в ежедневной деятельности.

Поэтому в энтерпрайзе задача создания и развития кросс-функциональных команд кажется мало выполнимой.

Разберемся с матчастью

Что вообще такое продуктовая команда?

Есть мнение, что DevOps летает только там, где есть Agile. С одной стороны это так, с другой стороны необязательно. Но суть Scrum-, Agile-, DevOps-, каких угодно продуктовых команд в том, что одна группа людей создает один продукт под ключ. Это может быть сложносоставная группа из нескольких feature-teams, которых объединяет только единый бэклог, но в любом случае это единый продукт. У продуктовой команды единые цели, структура прибыли, структура затрат и один продукт:



Такое описание продуктовой команды это краеугольный тезис, который толкает вас в дебри невозможности кросс-функциональности, потому что у любого адекватного человека начинается смех и истерика, когда ему говорят: Ребята, вы теперь будете делать всё. У вас 20 человек в команде, делайте розничное кредитование, например. Скорее всего, после такой постановки задачи вы поинтересуетесь у коллег, где скачать заявление на увольнение, потому что неохота от руки писать.

Но вам говорят; Спокойно, мы будем делать из вас кросс-функциональную команду, вас всему научим, всё вам дадим! И получается примерно так:



Кросс-функциональностью что только не называют. Я встречал мнение, что это система, при которой какой-то огромный департамент с индусами каждой продуктовой команде разрабатывает всё, что не относится к логике работы самого продукта. Если нужно что-то ещё, команды опять прибегают к этому огромному департаменту. Но, по сути, это внутренний аутсорс, когда вы примерно половину своей работы передаете какому-то дежурному терапевту.

Все-таки обычно под кросс-функциональностью понимают тестирование, плюс разработку (иногда безопасность, если вы совсем крутые) и обязательно сопровождение (внедрение). И всё это происходит внутри одной команды, которая должна уметь заменить любого своего участника в случае чего.

С точки зрения продуктовой разработки, одним из базовых является принцип You build you run it. Только пока ты сам сопровождаешь то, что накодил только тогда ты понимаешь все проблемы, которые твои клиенты, пользователи и смежные команды испытывают при работе с твоим продуктом. Об этом очень важно не забывать.

Маленький экскурс в Википедию
Обычно все говорят, что кросс-функциональность это про t-shape. Давайте определимся с терминами:

• Монофункциональность (i-shape). От греческого один. Допустим, я разработчик Java: я умею писать на Java и больше ничего не умею и уметь не хочу (причем очень воинственно). Даже если умею, ни за что об этом не расскажу, потому что мне платят за то, что я пишу код на Java. Я i-shaped, узконаправленный моноспециалист, я творец, пишу код, если вы против до свидания!
• Полифункциональность (t-shape). От древнегреческого многочисленный. Это когда я становлюсь менее агрессивным Java-кодером и говорю: ОК, я могу еще тесты написать. Не себе, потому что это будет странно, а, например, тебе Или, например, я понимаю, как работает инфраструктура, на которой мой продукт функционирует, и могу там скрипты позапускать, пописать, повидоизменять. То есть я в целом имею представление о том, как работает весь ландшафт, в котором мой код существует, и в случае чего хотя бы пойму, что там не так работает. А если я совсем крут, то я могу еще что-нибудь поправить.
• Омнифункциональность (-shape). От латинского omnis каждый, всякий. Это достаточно новая в нашей индустрии штука. Ее называют -shape, расческа-shape, как угодно-shape. Суть в том, что у вас вертикальных палочек с core-экспертизой становится больше ты не просто крутой Java-разработчик, но ты еще крутой DevOps-инженер. Например, ты очень хорошо представляешь, как работает твой CI/CD, в идеале ты его еще и сам создал под свой Java-проект, ты молодец, ты -shaped!

Это не значит, что все умеют всё

Очень важный момент. Если мы из нашего -shaped специалиста будем делать расческу, добавляя много ключевых экспертиз, то его госпитализируют в Кащенко (потому что он сойдет с ума). А если не сойдёт, то его экспертиза будет не такой уж глубокой, потому что человеческой жизни не хватит на то, чтобы стать экспертом во всем:



Каждый новый скилл, который вы приобретаете, и каждая новая экспертная область, с которой вы знакомитесь, должна позволять вам более эффективно выполнять свои текущие задачи. Если вы прочитали на Хабре, что ML это круто, и решили на досуге выучить Python, то это ваше хобби. Когда у вас появятся задачи, связанные с Python или с ML, за которые вам будут платить тогда можно говорить, что вы наращиваете горизонтальные навыки. Например, я люблю играть на гитаре, но за это в банке мне не доплачивают (к сожалению). То есть я не могу сказать, что я -shaped в сторону игры на гитаре.

В энтерпрайзе команда должна уметь делать неочевидные вещи

Когда мы говорим про энтерпрайз (банки, телеком и пр.), есть ряд неочевидных штук, про которые все либо никогда не задумывались, либо задумывались, но не придавали им значения до тех пор, пока им не сказали: Ребята, вы теперь продуктовая кросс-функциональная команда!

Взаимодействие с клиентом

Продукт это то, за что клиенты платят вашей компании. У продукта всегда есть P&L (Profits and Losses). Он отчуждаемый. Например, кредитная карта это продукт, потому что за нее вы платите деньги банку. А банк несет за неё какие-то расходы: он ее запрограммировал, создал бизнес-модель, как-то её рекламирует, печать пластика, доставка, логистика и пр. Банку может казаться, что супер-крутая карта, сделанная из чистого золота с гравировкой лица вашей мамы или бабушки это супер-свежая бизнес-модель, которая прямо сейчас взорвет рынок, и все придут к нему, отключившись от всех остальных банков. Но это может оказаться не так, если банк предварительно не спросит об этом у вас клиента.

Это кажется банальностью, но очень многие продуктовые команды (и даже компании) не знают, чего хотят их клиенты. Они делают то, что хочет, например, их CEO. Вы сами можете вспомнить 100500 таких примеров:



При создании продукта вы должны не просто понимать, что нужно вашему клиенту. Вы должны знать, что хочет ваш клиент сегодня, завтра, послезавтра и в любой другой день. Специфика банковского рынка такова, что наша прибыль не будет расти, если мы будем повышать цены на услуги или наращивать комиссии. Единственный рабочий драйвер рост клиентской базы. Но это справедливо и наоборот демпинг не сработает. Условно, ипотека везде стоит плюс-минус 10%. Но если сегодня мы сделаем ипотеку 5%, у нас будет очень много клиентов, но у ЦБ будут серьезные вопросы. Поэтому вместо этого мы вкладываемся в маркетинг и даем клиентам какие-то другие плюшки, например хороший сервис или скидки на другие продукты. Причем давать нужно именно то, что хочет клиент это поможет выбрать именно наш ипотечный продукт.

Механизмы взаимодействия с клиентом, которые позволят вам слушать и слышать его голос это то, что любая продуктовая команда должна уметь и иметь возможность сделать by design. Это важная штука.

Горячая линия 24/7

Ещё до Сбербанка, работая проектным менеджером, я, как и многие айтишники, дежурил по выходным. И это был отстой! Я ничего не умел делать с кодом и чувствовал себя максимально тупым и бесполезным в это время. Я сидел перед монитором с графиками только для того, чтобы в случае аварии взять такси и доехать до дома моего разработчика и позвонить в дверь, потому что он телефон не слышит. Не рекомендую!



Если бы тогда я знал то, о чём сейчас рассказываю, мы бы на берегу договорились с командой о правильной организации поддержки. Обычно в энтерпрайзе есть отдельная выделенная линия поддержки 24/7, колл-центр где-нибудь не в Москве. И любая команда должна иметь возможность с ним работать.

Как это сделать?
Допустим, я product owner той же кредитной карты. Я могу написать условный скрипт (инструкцию в Word), отдать в 24/7 и сказать, что если на горячую линию банка будут звонить по таким-то вопросам, то звоните Пете, если по таким то Коле, а все остальное не наше. Это я уже наполовину молодец.

Чтобы мне стать полностью молодцом, нужно еще при каждом изменении функционала моего продукта оповещать об этом службу 24/7. Если Коля заменился на Аллу, функциональность добавилась или убавилась, колл-центр должен об этом узнавать.

Почему это важно?
Клиент это тот, кто платит. У нас для продуктовой разработки специфично и характерно то, что все клиенто-центрично, а не IT- или CEO-центрично. Клиент хочет быстро получать всё, что ему нужно. И если у него есть проблема, он должен максимально быстро получить решение, просто позвонив или написав. Никто этого сейчас, наверное, нормально делать не умеет, но это то, к чему нужно стремиться.

Технологический долг и инциденты

Технологический долг это то, с чем каждый из нас работает так или иначе. Это может быть автоматизацией регресса, рефакторингом старого кода, разработкой API для чужого кода и т.д. Это понятие очень широко трактуют. Я знаю компании, в которых под технологическим долгом понимают исключительно архитектурные несоответствия спецификации, но это очень узко и на мой взгляд некорректно.

Инциденты, баги, аварии прода и так далее это то, что случается у всех. Но когда это начинает случаться часто и по одним и тем же причинам, это вызывает серьёзное раздражение. Тем не менее, мы не должны заливать эту проблему человеческими или какими угодно другими ресурсами (На 20 падений сервисов ответим наймом 20 новых DevOps-инженеров!), нужно сесть и подумать, почему сервис падает и как сделать так, чтобы он не падал. Тогда наши инженеры могут заниматься новыми более классными штуками, например, попилотировать CI/CD инструменты, которые они еще не трогали, чтобы потом к нам прийти и сказать: Чувак, я нашел что-то круче Jenkins:



То есть root cause работа с технологическим долгом, который не всегда будет вашим, кстати. Продуктовая команда в энтерпрайзе иногда вынуждена менять не свой код (например, в случае сервисной шины) для того, чтобы внедрить фичу в продакшн, изменение в функциональности и выкатить его на рынок.

Взаимодействие со смежными сервисами

Представим, что мы разрабатываем функционал выдачи кредитов в мобильном приложении. Я product owner в розничном кредитовании с отличным отделяемым P&L. И есть ряд каналов, через которые я этот продукт продаю сайт, iOS и Android приложения, мобильное рабочее место операциониста.

В мобильном приложении банков, как вы знаете, какой только функциональности нет от переводов между картами до выпуска новых карт, погашения ипотек, алиментов, оплаты ЖКХ и прочего. Это круто, это XXI век:



Но я, как product owner, отвечаю только за свой продукт за розничное кредитование. А если в мобильном приложении, например, iOS, которым пользуются миллионы людей, вдруг сбойнул текущий счет и человек просто свой баланс не видит? Он не будет, заходя в приложение, даже думать о том, чтобы взять кредит. Он скажет: О! Где мои сто тысяч рублей?! и будет звонить в банк и спрашивать: Доколе?!

Поэтому взаимодействие со смежными сервисами это та часть жизни вашей продуктовой команды, который может вам как сильно помочь в чем-то, так и сильно помешать.

В чем он может вам помочь? Если вы делаете какие-то смежные маркетинговые компании и продвигаете их через единый канал (например, мобильное приложение), вы можете получить синергию. Например, я выпускаю функционал по розничному кредитованию и могу предложить кредит на супер-условиях для молодых семей. А команда ипотеки то же самое делает, но для пенсионеров и лиц пожилого возраста. Мы можем прекрасно скооперироваться и вывести единый релиз под эгидой социальной защищенности.

Или если вы имеете внутренний опенсорс, то часть компонентов, которые вы используете со смежными сервисами, можно переиспользовать. Например, API или графические интерфейсы. Это вообще true никто давно уже не переписывает фронт или элементы дизайна каждый себе. Так вы сможете а) сэкономить, б) потенциально не потерять аудиторию (если что-то пойдет не так) или не вызвать волну хейта именно к вашему продукту.
Также потенциально вы можете получить совершенно неочевидные бенефиты, если будете более плотно дружить и общаться не только с клиентом, который вам платит, но и с теми людьми, которым он платит тоже. Это люди, которые сидят на тех же каналах с вами, в одном банке.

И наоборот. Они могут у нас увести активную аудиторию, сломать приложение, которое является каналом продажи наших услуг. Синхронизация релиз трейнов, расписания поставок, или чего угодно, что вы используете важно.

Прикладные платформы

Это частный случай смежных сервисов. Ранее упомянутая шина одна из них.

В банках это чаще всего DWH и АБС автоматизированные банковские системы. АБС это монструозная конструкция, в которой делается собственно банкинг. Там происходят основные финансовые операции, генерируется отчетность ЦБ. Это мозг зверя по имени банк. А все остальные его органы с АБС так или иначе взаимодействуют. Обычно АБС в банке ровно одна, потому что больше не надо. Есть исключения, например, при объединении банков какое-то время они живут с двумя, а то и тремя АБС, но обычно это нерационально. Так же, как и в случае с процессингом.

Любая платформа это, по сути, черепаха, на которой стоит мир. Клиенты пользуются вашими услугами они покупают кредитку, скачивают мобильное приложение, отправляют друг другу стикеры и чатятся. Но если у вас где-нибудь умрет процессинг, всё пойдет насмарку:



С процессингом вы можете общаться, либо выпиливая из него некоторые сервисы, микросервисы и другие абстракции, либо попросить свои платформы, чтобы они сделали унифицированный канал общения всех сервисов с ними. Тогда случай, происходящий с одним продуктом, не будет аффектить на платформу, и как следствие, на другой продукт.

Это базовая безопасность, которая позволит вам не упасть в случае падения платформы. Если в вашей компании упадет сервисная шина, ваш продукт упадет и не будет работать тоже. Если в банке упадет процессинг, через 5 часов вам позвонят из ЦБ, а через сутки заберут лицензию, каким бы банк ни был, даже 1. Это недопустимо.

Когда вы дизайните вашу кросс-функциональную (продуктовую) команду, платформа это то, что вы должны держать в поле зрения. Вы должны уметь безопасно работать с платформой, а платформа должна уметь безопасно работать с вами.

Инфраструктура

Инфраструктурный департамент это те обслуживающие подразделения, которые представляют сервисы командам для того, чтобы они могли пилить свои продукты железо, сети, и так далее. При этом, сама по себе инфраструктура это адский ад сложностей. Потому что никто снаружи не понимает, как она устроена и какие есть планы ее развития. Они говорят: Друзья, у вас сейчас голый Docker, мы пилотируем ванильный Kubernetes, еще в январе у нас будет Tanzu, еще где-то там рядом Openshift. А потом: Все, это мы больше не поддерживаем, переезжай вон туда. Когда и чем всё это кончится, непонятно:



Вы всегда должны понимать, что происходит и будет происходить с вашей инфраструктурой, причем под инфраструктурой я понимаю и hardware, и базовые middleware штуки, и те самые оркестраторы всего на свете, которые вы используете при работе. Вы должны знать в моменте, как их использовать, как их точно не использовать и что с ними будет дальше. Потому что это даст вам возможность не только не допустить ошибку (классика), но и потенциально получить гешефт.

Хороший пример: у нас недавно появилась новая команда, которой нужна помощь в настройке CI/CD. У нас в банке CI/CD тулой сейчас является Atlassian Bamboo. Мы могли им сказать: Друзья, вот Atlassian Bamboo, вот SDK, вот человек, который вам поможет это настроить. Мы готовы отправить вас на наш курс CI/CD, где вам расскажут основные паттерны взаимодействия наслаждайтесь.

Но прямо сейчас мы в банке пилотируем другие альтернативные инструменты, так как нас во многом не устраивает Bamboo. Этой команде мы объяснили, что расклад такой прямо сейчас есть Bamboo, есть пилоты такого и такого инструментов: Не хотите ли вы попробовать сделать на них? Риски понятны: если пилот не пойдет, им придется все это перевезти на тот, который будем внедрять. Но мы гарантируем поддержку и поможем им перепилить, чтобы безопасно перейти на тот, который будет выбран целевым.

То есть мы им дали информацию о том, какие минусы есть у текущего инструмента и какие плюсы у потенциально будущего. И дали информацию о том, как работает наша инфраструктура, чтобы они сделали осмысленный выбор. Они сказали: Да, кайф, и выбрали тот пилот, в котором им было бы интересно поучаствовать. Без этой информации, просто выбрав линию партии и продолжив на Bamboo, через пару месяцев мы бы получили волну негатива, когда поменяли бы наш CI/CD-оркестратор: Ребята, мы два месяца назад приходили...

Танцуем от цели

Очень часто команды изобретают велосипед. Например, мне нужно выбрать инструмент оркестрации контейнеров. Я смотрю в Google какой-нибудь рейтинг от Gartner и вижу там K8S: Нам нужен Кубер прямо сейчас! Почему именно Кубер? Да потому что я нагуглил, и он в каком-то рейтинге первый.

Но такой способ выбора решения не самый оптимальный. Нужно танцевать от цели. Какая у нас цель, зачем мне вообще оркестрация контейнеров? Зачем мне в принципе контейнеры? Затем, что я не хочу, чтобы каждая из команд, которые я обслуживаю (которым я служу есть такой термин servant leadership, лидерство как служение), тратила по неделе рабочего времени одного человека на то, чтобы заполучить базовые образы, которые они потом будут в своем CI/CD конвейере использовать. Я хочу создать централизованно полный набор образов, которые будут безопасны, всех удовлетворять и прочее. Куда-то их положить, чтобы всем было хорошо, комфортно и удобно, и пусть юзают.

Поэтому целесообразно спросить тех, кто ими пользоваться будет. Клиенты это мои команды: Ребята, у вас какие ожидания? Если они будут называть названия оркестраторов это не то, что мне нужно. Мне интересны принципы, по которым они выбирают.

Один скажет, что ему нужно, чтобы работало быстро: быстро писалось и быстро читалось. Второму важно, чтобы на рынке была экспертиза представлена, потому что он ноль в этом, а ему надо брать с рынка джуниоров, которые в этом быстро разберутся (т.е. чтобы было просто). Третьему нужно, чтобы какой-нибудь PCI DSS проходил (стандарты по работе с картами Visa, Mastercard и НСПК) особенные требования к безопасности должен прийти аудитор и кадилом помахать: Ваше управление контейнерами удовлетворяет требованиям PCI DSS.

Я выписываю эту критериальную таблицу и на ее основе принимаю решение, какой оркестратор мне нужен. У любой команды-потребителя сервиса должна быть возможность влиять на тот стек инструментов, который вы ей предлагаете. Я за то, чтобы люди сами определяли, что им нужно и как они хотят решать свои проблемы. А я предлагаю те решения, которые на мой взгляд удовлетворяют этим потребностям.

Конечно, у меня сбоку будет своя критериальная таблица типа: сколько это стоит, насколько просто это поддерживать, модель лицензирования и т.д. Но команды всегда дают input, что они хотят от своей инфраструктуры. Они хотят быстро, дешево, гибко ОК, это их право. Они имеют право это требовать от нас, как от сервисных подразделений.

Как все это сделать?

Вы можете сказать: Молодец, рассказал очевидные вещи спасибо, кэп! а что с этим делать? Ответ очень простой: создать в вашей компании такую среду, чтобы работать неправильно было некомфортно, слишком дорого, сложно и т.д.:

Взаимодействие с клиентом

Как заставить, побудить, продать (какие угодно слова можно использовать) наши команды взаимодействовать с клиентом, чтобы они начали его слышать и слушать? Вы должны включить им голос клиента в какой-то мониторинг, либо в цели. Хоть радио в офисе повесьте с записями из отделений банка, как бабушки кричат том, что полчаса не могут пенсию снять.

Как это сделано у нас. Мы безальтернативно проводим опрос клиентов по основным банковским услугам, потом безальтернативно всем его показываем. Например, вы продаете кредитные карты, а вы дебетовые: вами довольны, а вами нет. Люди видят результаты друг друга и понимают, что происходит не так. Их никто за это не наказывает, просто им стыдно. Когда один продукт любят, а второй нет, то вторые придут к первым и попросят рассказать секрет что я делаю не так, что ты делаешь так, почему так происходит? Со временем эта история всегда выравнивается, потому что системы (а корпорация это конечно система) склонны к равновесию.

Это очень долго, если у вас инертная компания, но, если вы молодые и энергичные ребята это будет быстро. Если вам не все равно, процесс можно ускорить ходить и пальчиком тыкать: Смотри, у них хорошо, у тебя плохо. Не хочешь присмотреться? Мы так делаем.

Резюме

Кросс-функциональная команда умеет:

1. Измерение клиентского опыта

Давать тут какие-то советы на мой взгляд не нужно, потому что литературы написано более чем достаточно. Просто перестаньте додумывать за клиента, и попробуйте любым способом узнать, что он на самом деле хочет.

2. Поддержка продукта 24/7

Помните, как раньше учили детей плавать? Вывозишь на лодке на середину реки и бросаешь в воду: Давай, встретимся на берегу! В переводе на нормальный язык с языка метафор это значит, что пусть команда пострадает.

Вы им говорите: Вас 10 человек. Есть возможность работать с горячей линией 24/7, но для этого нужны скрипты, которые вы должны дать. Но вы можете этим не пользоваться живите, как хотите!, а потом все звонки на горячую линию, когда какая-нибудь кредитка умерла, роутить прямо на product owner. В субботу ночью? ОК! В воскресенье ночью? ОК! В понедельник примерно к 5 утра он задумается о том, что же он делал в этой жизни не так, и к обеду скрипт будет в службе 24/7 готовый и со всеми нюансами.

3. Технологический долг и инциденты

Тут несколько вариантов решения. Можно использовать тот же самый метод тотальной открытости, когда все видят, что одни перформят, другие нет и смотрите, почему. А можно попытаться обосновать, что устранение технологического долга дает им измеримый бенефит.

Например, у вас и у соседней команды плюс-минус похожие продукты, но у вас стремный legacy-код, а у соседней команды нет. В результате у вас есть некий постоянный уровень аварийности (допустим, 10 аварий в год), в отличие от той команды. Тут очень важный момент нужно найти человека, который согласится исправить что-то один раз. Найдите конкретный legacy-фрагмент в коде и поймите, на что это влияет. Потом убедите команду это изменить и покажите цифры: Вот у тебя было 10 аварий в год, теперь их 8! Давай сделаем дальше, и будет у тебя еще все более круто.

4. Взаимодействие с прикладными платформами

В структуре организаций частенько встречается некая платформенная команда, которая сидит, отгородившись отрядом лучников, скелетов, черных драконов, и никого к себе не подпускает: Вам нужна доработка приходите через 9 месяцев.

В этом случае мы задаём вопрос что я могу сделать, чтобы я получил быстрее то, что я хочу? У продуктовой команды в целом таким и должно быть мышление если вам что-то нужно, но говорят НЕТ, то узнайте, что нужно сделать, чтобы было ДА. То есть узнать, что нужно сделать, чтобы прикладная платформа внедрила изменения на своей стороне, которые нужны вам, быстрее (например, через месяц) должны вы, как идеологи DevOps. Например, давайте сделаем API, или давайте продуктовая команда сделает изменения в платформенном коде, только чтобы все это было безопасно и т.д.

5. Взаимодействие со смежными сервисами

Аналогично никаких секретов, просто человеческое общение, поиск взаимовыгодных условий совместной работы и ad hoc решение задач.

6. Инфраструктура

Как это бывает: приходит новая команда и говорит, что им нужны среды: Нам нужен продакшн-сервак, у нас релиз через месяц. Хорошо, вот заполни Excel, что конкретно ты хочешь, там всего 120 строчек. Я смотрю в эту таблицу и понимаю оттуда от силы 20 строчек, а для остальных мне нужен переводчик человек, который знает, как их заполнять. Когда мы первый раз сказали нашей инфре, что это странно, даже мы в этом не шарим, то они дали нам образец, как это заполняется. С образцом я стал уметь заполнять 40 строчек из 120.

Я как потребитель постоянно говорю, что именно мне неудобно до тех пор, пока сервис не станет идеальным. Это один из принципов Agile делаем не сразу идеально, а движемся постепенно к тому, чтобы стало хорошо, постоянно делаем лучше и лучше. Сейчас наша инфраструктура понимает, что она в первую очередь сервис, и теперь думает, как сделать жизнь своих клиентов легче.

Это шесть основных моментов, на которые, как показал опыт моей команды, нужно обращать внимание.

Если вы знаете еще какие-то вещи, которые кросс-функциональная продуктовая команда должна уметь делать со своим окружением пишите, обсудим.

Вместо заключения: это будет непросто

Это невероятно сложная и неблагодарная работа всё это провернуть и претворить в жизнь. Вам будет очень тяжело, если вы встанете на этот скользкий путь. Нам было очень тяжело:



Каждый раз, когда вы говорите, что будете менять среду таким образом, чтобы она побуждала людей сделать что-то, чего они раньше не делали, это будет дико демотивировать вас и ваших людей. Вы будете выгорать и ненавидеть весь мир. Но потом (через пару лет), люди, у которых стало хорошо, скажут: Я красавчик, я всё сделал. Ты мне помогал, я помню. Но это фигня, а вот я красавчик!

У нас две важных новости о конференции HighLoad++ 2020. Во-первых, готово расписание конференции. Оно будет дополняться, но планировать дни 9 и 10 ноября уже возможно.

Во-вторых, HighLoad++ 2020 переезжает из Сколково в большее помещение в Крокус Экспо. Это ещё одна мера безопасности большая площадка позволит нам дополнительно разрядить пространство и рассредоточить слушателей.

В программе доклады от разработчиков, CTO и основателей технологических компаний. Узнаем, какие технологии применяют в Badoo, Сбере, Tinkoff, Яндексе, Юле, Erlyvideo и в других компаниях-лидерах рынка.

Официальный телеграм-канал конференции поможет вам быть в курсе событий и изменений, а неформально обсудить можно в этом. Забронировать билет на HighLoad++ 2020 можно здесь. Встречаемся 9 и 10 ноября в Крокус Экспо!

Если бизнес идет вверх, тозапросы инагрузка наразработку увеличиваются вразы. Рано или поздно каждый управленец сталкивается свыбором издвух крайностей: встать насторону бизнеса, двигать продукт идемотивировать разработчиков бесконечным техдолгом или дать свободу разработке ипотерять контроль над задачами бизнеса.

Mindbox 15лет развивает B2B-продукт ивырос с3до70человек вразработке. Мытестировали разные подходы кмасштабированию иготовы поделиться опытом, чтобы вам непришлось наступать натеже грабли. Ниже расскажу, как попробовали полную автономию команд ицентрализацию, роняли надежность, демотивировали команды, как врезультате сэтим справились ивыработали свою систему масштабирования.

По материалам выступления на Agile Days 2021:

Надежность как ядро разработки

Чтобы оценить, окаких масштабах разработки инагрузке пойдет речь, расскажу оразмере компании.

ВMindbox одна изсамых нагруженных разработок вРоссии, нопри этом она сохраняет высокую надежность. Когда покупатель пробивает чек накассе вБургер Кинге или аптеке Ригла, транзакция идет кнам. За200 миллисекунд мырассчитываем суммы иотвечаем кассе. Если сервис упал, томного людей повсей стране 24/7 становятся несчастны.

Запоследние 34 года бизнес растет по4050% вгод инагрузка удваивается ежегодно. Внешне всё отлично, ноуMindbox был длинный период становления, который влиял намасштабирование разработки.

Масштаб бизнеса и разработки

Эволюция разработки

Как работает автономия ицентрализация разработки

Проблема масштабирования разработки сводится кпоиску баланса между автономией ицентрализацией. Есть две организационные крайности:

1. Автономия. Вомногих компаниях победили автономные инженеры инет никаких сроков. Разработка постоянно закрывает секретный техдолг, абизнес непонимает, как решать крупные задачи. Это заканчивается революцией: бизнес теряет терпение ивносит радикальные изменения впроцессы.
2. Централизация. Другая крайность когда побеждает бизнес. Дедлайны спускаются наразработку сверху, задачи бизнеса решаются, нокопится техдолг. Потом процессы опять замедляются иистория заканчивается революцией: предлагают переписать код снуля или продать компанию.

Микросервис имонолит. Две архитектурные крайности микросервис имонолит напрямую несвязаны сописанными типами управления, нопохожи поэффекту. Микросервисы работают быстро, ночем ихбольше, тем больше инфраструктурных задач реализуются несколько раз вместо одного. Вмонолите, наоборот, сначала всё эффективно, нопотом замедляется из-за множества зависимостей.

Мынашли баланс между автономией ицентрализацией: дали техническую автономию продуктовым командам ввопросах сервисов ицентрализовали управление процессами, которые относятся ковсем командам. Ниже расскажем, что это означает икак мыкэтому пришли.

Как внедрили автономию

С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, стоимости железа ибез увеличения техдолга

Какую выработали систему масштабирования разработки

Продуктовые команды. Еслибы мысейчас строили разработку снуля, топоумолчанию выделили децентрализованные продуктовые команды. Желательно, чтобы укаждой был свой сервис инебыло монолита нанесколько команд. Наша реальная ситуация оказалась сложнее: есть монолит, поэтому надежность зависит отнего, есть централизованный найм ицентрализованная стоимость облачного железа.

Разумное регулирование общего. Как ядро оставили общие задачи, над которыми должны работать централизованно: roadmap монолита, надежность иинфраструктура, стоимость железа иdeveloper experience. Если нет общих знаний отом, как создаются базовые вещи, топеремещение разработчиков между командами будет затруднено, код будет дублироваться иесть риск потерять эффект масштабной разработки, когда каждая команда существует изолированно отвсех.