TDR — процесс технического дизайн-ревью / Павел Лакосников (Авито) (Рубрика Architecture)
Интересный доклад Паши Лакосникова из Авито про принятие качественных технических решений в большой компании. Основные тезисы примерно следующие
- Сам Паша давно работает в Авито и сейчас занимается выстраиванием architecture governance
- По мере роста компании все сложнее принимать качественные решение из-за роста чимсла команд и усложнения иерархии
- Компании часто вводят роли техлидов и архитекторов для решения этих проблем
- Это приводит к тому, что инженеров отстраняют от принятия решения и они теряют мотивацию и ответственность за принятые без них решения
- Дальше появляется архитектурные комитеты и архревью, где рассматриваются архитектурные артефакты и принимаются решения
- Если все решения прогонять через архкомитет, то он становится бутылочным горлышком и замедляет работу, а также стоит много-много денег
- Следующий шаг - это дизайн ревью решений в асинхронном формате 😍 Для этого нужны шаблоны документов для описания технических решений + автоматическая валидация их заполнения. В документе должны быть: автор, команда, юнит, дата создания, уровень влияния (низкий, средний, высокий), сроки ревью.
- Дальше появляется реестр таких документов и возможность поиска и анализа решений
- Инициативы делятся на разные уровни, которые требуют ревью разной строгости и формата
- Уровни влияния помогают разным стейкхолдерам отслеживать только нужные им инициативы, например, техдиры могут отслеживать самые крупные изменения
- У технических инициатив есть связь с продуктовыми, что позволяет лучше понять для чего мы делаем изменения и насколько они оправданы
- У инициатив есть жизненный цикл: прототип, эксперимент, масштабирование. Каждый этап имеет свою детальность проработки. А также можно фиксировать зависимости между командами и компонентами для предотвращения ошибок.
- Так как в инициативах указываются затронутые компоненты, то их владельцы получают уведомления и могут прийти поревьювить инициативу, в которой они упоминаются
- Наличие реестра обеспечивает историчность принятия решений + позволяет настроить валидацию принятия решений, чем отдельные роли: авторы, контрибьюторы, FIY и owners
- Реестр можно связать с техническим радаром, который должен быть входной точкой в жизненный цикл технологий.
- Все это обеспечивает прозрачность появления и развития технологий, а также их depracation и миграции с EOL (end of life)
- По всей этой машиенрии можно собирать метрики: количество decision records, время их прохожджения, доля успешно доведенных до конца и так далее
- Внедренный процесс помогает решить проблему с архитектурными комитетами, а также повысить вовлеченность инженеров
P.S. Про то, как это устроено у нас было в постах
- Серия подкаста "Code of Leadership" - Interview with Anton Kosterin about Architecture Governance
- Мое выступление на ArchDays 2024 - "Архитектура в Т-Банке: вчера, сегодня, завтра"
- Серия подкаста Research Insights Made Simple про "API Governance at Scale", где мы с Даниилом Кулешовым разбирали whitepaper о том, как это устроено в Google, а также говорили про governance у нас в компании
#Architecture #Software #DistributedSystems #SystemDesign #SystemEngineering #API #Governance