mirror of
https://github.com/avito-tech/playbook.git
synced 2026-03-13 21:53:21 +03:00
80 lines
5.8 KiB
Markdown
80 lines
5.8 KiB
Markdown
# Tech design Review в Авито
|
||
|
||
## Что такое TDR
|
||
Tech Design Review — это процесс описания изменений в дизайне, архитектуре, сервисе или продукте и запрашивания фидбэка у коллег-разработчиков. Похож на ревью Pull Request.
|
||
|
||
## Жизненный цикл TDR
|
||
Процесс TDR строится по такому алгоритму:
|
||
- Формулирование проблемы.
|
||
- Создание дашборда для TDR.
|
||
- Создание дизайн-документа.
|
||
- Начало ревью.
|
||
- Сбор оценок и отзывов.
|
||
|
||
После этого начинается доработка продукта по фидбэку, и ревью проводится заново. Если доработок больше нет, можно приступать к реализации.
|
||
|
||
## Когда стоит делать TDR
|
||
Мы рекомендуем проводить TDR в следующих случаях:
|
||
- **Портфельный продукт.** Если продукт находится в продуктовом портфеле, то до наступления Gate 2 должен быть проведен TDR.
|
||
- **Высокий уровень влияния.** Если решение затрагивает более одного юнита, то обязательно проведение ревью и участие в нём представителей от юнитов.
|
||
- **Значительные инвестиции в разработку.** Если суммарно нужно потратить больше 3 "человеко-месяцев" на работу по задаче.
|
||
- **Возрастание тех. долга.** Если разрабатываемое решение (например, MVP) может значительно увеличить тех. долг.
|
||
- **Передача сервиса или модуля в другую команду.** Коллегам будет легче поддерживать и развивать решение, если обсудить его архитектуру в формате TDR.
|
||
- **Внедрение новой технологии/продукта.** Рассмотренные причины внедрения, альтернативы, будет обоснование и согласованно с архитектурой.
|
||
|
||
## Шаблон TDR
|
||
Для проведения TDR нужно создать дизайн-документ. У всех дизайн-документов единая структура.
|
||
|
||
- **Проблема**
|
||
|
||
Опишите, какая проблема с точки зрения продукта или бизнеса решается предлагаемым изменением.
|
||
|
||
- **Описание**
|
||
|
||
Опишите, что вы планируете сделать и как это будет работать на решение описанной выше проблемы.
|
||
|
||
- **Схема зависимостей**
|
||
|
||
Создайте схему зависимостей и прикрепите её в дизайн-документ.
|
||
|
||
- **Компромиссы**
|
||
|
||
Опишите, на какие компромиссы в решении мы идём и почему, опишите планируемый тех.долг, когда и как он будет устранён.
|
||
|
||
- **Альтернативы**
|
||
|
||
Если рассматривались какие-то альтернативы, зафиксируйте их здесь.
|
||
|
||
- **FAQ**
|
||
|
||
В этой секции фиксируются вопросы, которые возникают в процессе проектирования и ответы на них.
|
||
|
||
- **Нагрузка:** в этом блоке собран список вопросов, на которые нужно ответить и сделать описание расчёта.
|
||
- Какая нагрузка в RPM ожидается на сервис?
|
||
- Какое количество реплик нужно на каждый DC?
|
||
- Отношение нагрузки на чтение и запись.
|
||
|
||
- **Ресурсы:** в этом блоке собран список вопросов, на которые нужно ответить.
|
||
- Есть ли похожие по потреблению ресурсов сервисы? Если да, то сколько они потребляют?
|
||
- Закладывались ли ресурсы под этот сервис во время планирования ресурсов?
|
||
- Если нужна база данных, какую конфигурацию вы выбрали?
|
||
- Нужно ли хранилище на ceph для этого сервиса?
|
||
- Нужны ли специфичные ресурсы: например, GPU?
|
||
- Нужно ли хранить дополнительные поля в айтеме?
|
||
- Нужно ли хранить картинки или файлы?
|
||
|
||
- **Структура баз данных**
|
||
|
||
Опишите структуру базы данных и планируемый способ хранения.
|
||
|
||
- **Информационная безопасность:** обсудите ответы на эти вопросы с безопасниками и покажите им результаты моделированя угроз.
|
||
- Предполагает ли решение добавление публичного API?
|
||
- Предполагается ли хранение или обработка персональных данных?
|
||
|
||
- **Метрики**
|
||
|
||
Соберите список ключевых бизнесовых, продуктовых и технических метрик.
|
||
|
||
|
||
|