diff --git a/avito-developer-practice.md b/avito-developer-practice.md index b14365a..5402560 100644 --- a/avito-developer-practice.md +++ b/avito-developer-practice.md @@ -2,7 +2,7 @@ - [Live Site Review (LSR)](https://github.com/avito-tech/playbook/blob/master/avito-developer-practice.md#live-site-review-lsr) — разбор инцидентов - [Архитектурный комитет](https://github.com/avito-tech/playbook/blob/master/avito-developer-practice.md#архитектурный-комитет) — ревью архитектуры приложений и сервисов -- [Team maturity model](https://github.com/avito-tech/playbook/blob/master/avito-developer-practice.md#Team-Maturity-Model) - Модель зрелости: как мы оцениваем и растим инженерные команды +- [Team maturity model](https://github.com/avito-tech/playbook/blob/master/avito-developer-practice.md#Team-Maturity-Model) — Модель зрелости: как мы оцениваем и растим инженерные команды ## Live Site Review (LSR) Нам важно, чтобы Авито стабильно и надёжно работал. Но бывает, что несмотря на наши усилия, что-то ломается. Это может быть железо или какой-то архитектурный компонент под высокой нагрузкой. В этом случае важно починить возникшую проблему как можно быстрее. Для этого у нас есть развесистая система мониторинга и алертов, а также служба круглосуточных дежурных. @@ -59,7 +59,7 @@ **Команда** (обязательное) — проставляем сюда только одну команду, которая стала виновником торжества. -**Пострадавшие сервисы** — в этом поле перечисляем все сервисы, которые сломались, кроме того, где была ошибка. Поле нужно для того, чтобы видеть неявные зависимости сервисов и отмечать места, где нужно поработать над graceful degradation. +**Пострадавшие сервисы** — в этом поле перечисляем все сервисы, которые сломались, а также, где была ошибка. Поле нужно для того, чтобы видеть неявные зависимости сервисов и отмечать места, где нужно поработать над graceful degradation. **Участники** — здесь указываем всех, кого стоит позвать на встречу с разбором инцидента. В их календари потом придёт приглашение. @@ -77,15 +77,15 @@ ### Как разбираем инциденты на встречах -Когда пожар потушен и тикет заполнен, событие переходит к ответственному из QA-команды. Тот внимательно смотрит на него и разбирается, что происходило, медленно или быстро мы нашли проблему, позвали дежурные сразу тех, кого нужно, или сначала разбудили непричастных. Ответственный проверяет, хватило ли нам графиков для анализа ситуации, что было написано в логах. +Когда пожар потушен и тикет заполнен, событие переходит к ответственному из QA-команды. Тот внимательно смотрит на него и разбирается, что происходило, медленно или быстро мы нашли проблему, сразу позвали ответственных дежурных или сначала разбудили непричастных. Ответственный проверяет, хватило ли нам графиков для анализа ситуации, что было написано в логах. После мы создаём встречу для разбора в специальном LSR-календаре. Во встречах участвуют команды, в сервисе которых возникла проблема, те, кто её устранял, и эксперты по технологиям, в которых проявилась проблема. На разборах постмортемов мы оцениваем влияние инцидента на работу компании, смотрим на проблему с разных сторон и вырабатываем по ней решение. Если предотвратить возникновение проблемы в будущем невозможно, то придумываем, как уменьшить потери от её возникновения. Обычно ответственный заранее обозначает повестку встречи, и мы идём по списку подготовленных вопросов. **Вот список типовых вопросов, которые стоит обсудить при разборе LSR:** -- В чём была проблема и какова её первопричина? Если это баг в коде, то полезно посмотреть на процессы тестирования и понять почему его не поймали. Если сбой произошёл из-за возросшей нагрузки, то стоит подумать про регулярное нагрузочное тестирование. -- Как быстро и откуда узнали о проблеме? Можно ли узнавать быстрее? Возможно, нужны дополнительные мониторинги или алерты. Или стоит отдать отдать имеющиеся команде мониторинга 24/7. +- В чём была проблема и какова её первопричина? Если это баг в коде, то полезно посмотреть на процессы тестирования и понять, почему его не поймали. Если сбой произошёл из-за возросшей нагрузки, то стоит подумать про регулярное нагрузочное тестирование. +- Как быстро и откуда узнали о проблеме? Можно ли узнавать быстрее? Возможно, нужны дополнительные мониторинги или алерты. Или стоит отдать имеющиеся команде мониторинга 24/7. - Как быстро смогли понять, в чём именно проблема? Возможно, стоит почистить Sentry или добавить логирование. - Затронула ли проблема основную функциональность сайта и можно ли уменьшить такое влияние? Например, если сломался счётчик количества объявлений, то страницы сайта ломаться не должны. Тут стоит подумать про graceful degradation. - Может ли проблема повториться в других модулях или компонентах системы? Что сделать, чтобы этого не произошло? Например, актуализировать таймауты, добавить обработку долгого ответа. @@ -115,45 +115,45 @@ ## Архитектурный комитет -Архитектурный комитет это команда экспертов Авито, которая готова провести ревью архитектуры вашего приложения или высоконагруженного сервиса. Комитет собирается по наличию заявок, но не чаще 2-х раз в неделю. Каждая встреча длится 1.5 часа. Встреча открытая, на нее может прийти любой сотрудник Авито. +Архитектурный комитет – это команда экспертов Авито, которая готова провести ревью архитектуры вашего приложения или высоконагруженного сервиса. Комитет собирается по наличию заявок, но не чаще 2-х раз в неделю. Каждая встреча длится 1.5 часа. Встреча открытая, на нее может прийти любой сотрудник Авито. ### Зачем нужен архитектурный комитет? -- Помочь командам правильно спроектировать сервис или архитектуру +- Помочь командам правильно спроектировать сервис или архитектуру. - Повысить культуру проектирования и осмысленность принятия архитектурных решений. - Обеспечить место, где - - разработчикам на примере их задач будут подсказывать правильные на текущий момент архитектурные решения - - можно провалидировать свои решения широким кругом толковых специалистов -- Снизить риски нестабильной работы Авито в будущем + - разработчикам на примере их задач будут подсказывать правильные на текущий момент архитектурные решения; + - можно провалидировать свои решения широким кругом толковых специалистов. +- Снизить риски нестабильной работы Авито в будущем. -В процессе подготовки к презентации команды часто задумаетесь над вещами, которые часто упускаются из виду при проектировании. Это помогает точнее спрогнозировать профиль использования и оценить возможные проблемы. В результате мы получаем более качественное решение, которое не придется переделывать сразу после релиза в продакшен. +В процессе подготовки к презентации команды задумываются над вещами, которые часто упускаются из виду при проектировании. Это помогает точнее спрогнозировать профиль использования и оценить возможные проблемы. В результате мы получаем более качественное решение, которое не придется переделывать сразу после релиза в продакшен. ### Как понять, что стоит обратиться в архитектурный комитет? - Идёт выпил из монолита одного сервиса или группы сервисов, входящих в один из бизнес-критичных путей: - Делается новое платформенное решение, которое будет использовать кто-то кроме вашего юнита, например: - Делается высоконагруженный сервис. Основные признаки: - - больше 500 rps или больше 100 тяжелых запросов / сек (по времени исполнения или кол-ву ресурсов) - - сложная работа с данными, обеспечение их целостности - - сложная схема масштабирования или ограничения по масштабированию - - большое кол-во внешних зависимостей и риски большого latency + - больше 500 rps или больше 100 тяжелых запросов / сек (по времени исполнения или количеству ресурсов); + - сложная работа с данными, обеспечение их целостности; + - сложная схема масштабирования или ограничения по масштабированию; + - большое количество внешних зависимостей и риски большого latency. -Техлиды отвечают за то, что все необходимые технические решения пройдут защиту архитектурного комитета. У нас действует правило - не уверен нужен комитет или нет, спроси в специальном чате. +Техлиды отвечают за то, что все необходимые технические решения пройдут защиту архитектурного комитета. У нас действует правило - не уверен, нужен комитет или нет, спроси в специальном чате. ### Чеклист перед встречей архитектурного комитета -- Нужно проработать и описать решение. Для подготовки нужно использовать один из чек-листов (Описание архитектуры приложения, чек-лист для микросервисов, чек-лист для client-side проектов) -- Когда в календаре появится приглашение на встречу, нужно переслать его всем кому важно знать детали реализации - - стейкхолдеры - - потребители - - смежные команды которые затронет решение -- За 2 рабочих дня до встречи нужно прислать слайды презентации и другие полезные документы/ссылки для ознакомления в канал в слаке -- Практика показывает, что лучше позвать на встречу отдельного члена команды, который будет только записывать фидбек, не участвуя в обсуждении +- Нужно проработать и описать решение. Для подготовки нужно использовать один из чек-листов (Описание архитектуры приложения, чек-лист для микросервисов, чек-лист для client-side проектов). +- Когда в календаре появится приглашение на встречу, нужно переслать его всем кому важно знать детали реализации: + - стейкхолдеры; + - потребители; + - смежные команды, которые затронет решение. +- За 2 рабочих дня до встречи нужно прислать слайды презентации и другие полезные документы и ссылки для ознакомления в канал в слаке. +- Практика показывает, что лучше позвать на встречу отдельного члена команды, который будет только записывать фидбек, не участвуя в обсуждении. ### После встречи архитектурного комитета -- После встречи нужно подготовить и прислать в канал слака выводы и план действий по ним -- После выводов и планов модератор прошедшей встречи в течение 1-2 рабочих дней собирает дополнительные рекомендации комитета и отправляем команде -- Если необходимо, Модератор организует дополнительную встречу комитета для обсуждения плана действий или результатов его реализации. +- После встречи нужно подготовить и прислать в канал слака выводы и план действий по ним. +- После выводов и планов модератор прошедшей встречи в течение 1-2 рабочих дней собирает дополнительные рекомендации комитета и отправляет команде. +- Если необходимо, модератор организует дополнительную встречу комитета для обсуждения плана действий или результатов его реализации. - Если архитектурный комитет не пройден, то идёт проработка замечаний и повторная встреча. ### Кто входит в состав комитета? @@ -161,18 +161,19 @@ ## Team Maturity Model -Внутри Авито под моделью зрелости мы понимаем как раз список разных инженерных и продуктовых практик. Мы хотим, чтобы разные команды находились по этим практикам на едином базовом уровне или выше. Например, чтобы мы точно понимали, что все команды стремятся к пирамиде тестирования и регулярно проводят ретроспективы. +Внутри Авито под моделью зрелости мы понимаем список разных инженерных и продуктовых практик. Мы хотим, чтобы разные команды находились по этим практикам на едином базовом уровне или выше. Например, чтобы мы точно понимали, что все команды стремятся к пирамиде тестирования и регулярно проводят ретроспективы. Чётко прописанная модель зрелости помогает быстро синхронизироваться и находить зоны роста команд. Её задача — выровнять в большом количестве инженерных команд одновременно глубину проникновения и полноту технологий и процессов, которые мы считаем нужными. ### Предпосылки к созданию инструмента Техническому директору важно понимать, в каком состоянии зрелости находятся инженерные команды компании, где нужно усиливать культуру и какие области требуют повышенного внимания. У нас есть задача системно прокачивать команды, и делать это на основе прозрачных и понятных правил. -Нам нужен был инструмент, описывающий базовые вещи по процессам, которые необходимы для работы команды, и практики, которые мы хотим сознательно внедрять. Этот инструмент также должен был помочь математически корректно измерить, насколько каждая команда близка к ожидаемому уровню зрелости. +Нам нужен был инструмент, который описывает базовые вещи по процессам необходимым для работы команды, и практики, которые мы хотим сознательно внедрять. Этот инструмент также должен был помочь математически корректно измерить, насколько каждая команда близка к ожидаемому уровню зрелости. Мы хотели создать модель, которая помогла бы избежать ряда проблем в будущем: - Развитие инженерных команд происходит, но понимание базового уровня у всех разное. -- Одни команды знают, что прокачивать, и им нужно лишь задать вектор. Другие команды считают, что они знают, что прокачивать, но качают не то, что нужно компании. - Есть и команды, которые не хотят прокачиваться, — нет времени точить пилу, потому что надо пилить. +- Одни команды знают, что прокачивать, и им нужно лишь задать вектор. Другие команды считают, что они знают, что прокачивать, но качают не то, что нужно компании. +- Есть и команды, которые не хотят прокачиваться, — нет времени точить пилу, потому что надо пилить. - Когда нет общего стандарта, одни команды могут убежать далеко вперед, а другие — стоять на месте. Через какое-то время им станет тяжело находить общий язык и скоординированно достигать результатов. - Если ничего не делать, то со временем будут увеличиваться расходы компании на качество. Внесение изменений будет становиться всё дороже и дороже. В итоге пострадает технический или продуктовый бренд. - Мало кому интересно работать в незрелой команде. Хочется использовать последние технологии и лучшие практики. @@ -186,18 +187,18 @@ В первой вкладке документа собраны секции, по которым мы оцениваем свои команды. Cекции написаны экспертами в своей области: они определяют базовые уровни и до утверждения финальной формулировки проводят фокус-группы с командами, чтобы не улететь в космос по ожиданиями. Мы оцениваем зрелость инженерных команд по шести основным блокам: -- Информационная безопасность -- Обеспечение качества -- Перформанс -- Фронтенд -- Бэкенд -- Продакт-delivery +- Информационная безопасность; +- Обеспечение качества; +- Перформанс; +- Фронтенд; +- Бэкенд; +- Продакт-delivery. Delivery — процесс от продуктового бэклога до внедрения задачи в продакшен. Когда мы запускаем новую команду, она изучает модель зрелости и сразу определяет, какие направления надо подтянуть. Уже действующим командам описания уровней дают возможность понять, как им стать круче и быстрее. -Компаниям, которые хотят адаптировать наш документ под себя, я рекомендую написать сначала от одной до трёх секций и попилотировать их в боевом режиме. Когда появится отлаженный процесс, можно будет добавить и другие секции в вашу модель. +Компаниям, которые хотят адаптировать наш документ под себя, рекомендуем сначала написать от одной до трёх секций и попилотировать их в боевом режиме. Когда появится отлаженный процесс, можно будет добавить и другие секции в вашу модель. #### Вкладка «Оценки команд» @@ -217,16 +218,16 @@ Delivery — процесс от продуктового бэклога до в Каждый квартал мы создаём новую вкладку с оценками. Команды собирает данные, заносят свои оценки в актуальную вкладку и ставят себе новые задачи по росту. Этот процесс повторяется циклично. На выходе мы получаем в таблице единую картину по всем командам и динамику по зрелости квартал к кварталу. -У нас много разных команд, и модель помогает всем, несмотря на то, что они разные. Это происходит за счёт того, что мы можем не ставить оценки по конкретным пунктам. В начале пути у нас были мнения, что для продуктовых команд и для технической платформы модели должны быть разными, но в итоге мы решили это противоречие через оценку N/A. Причём может быть так, что внутри одной секции половина пунктов к команде применима, а половина — нет. Ничего страшного в этой ситуации нет, оценка подтверждается через консультацию с экспертом, и в новых кварталах команда на такой пункт модели уже не смотрит +У нас много разных команд, и модель помогает всем, несмотря на различия. Это происходит за счёт того, что мы можем не ставить оценки по конкретным пунктам. В начале пути у нас были мнения, что для продуктовых команд и для технической платформы модели должны быть разными, но в итоге мы решили это противоречие через оценку N/A. Причём может быть так, что внутри одной секции половина пунктов к команде применима, а половина — нет. Ничего страшного в этой ситуации нет, оценка подтверждается через консультацию с экспертом, и в новых кварталах команда на такой пункт модели уже не смотрит. -Также могут быть команды, которые не хотят следовать стандартам в силу своих причин. Такие сложные ситуации должны точечно обрабатывать эксперты: их задача прийти и выяснить, почему команда считает так, а не иначе. Если стандарты действительно не подходят, то для конкретной команды модель зрелости мы не применяем. Но важно, чтобы это подтвердил эксперт, он отвечает за технологию и процесс, ведь именно он отвечает за установленные технологии и процессы. +Также могут быть команды, которые не хотят следовать стандартам в силу своих причин. Такие сложные ситуации должны точечно обрабатывать эксперты: их задача — прийти и выяснить, почему команда считает так, а не иначе. Если стандарты действительно не подходят, то для конкретной команды модель зрелости мы не применяем. Но важно, чтобы это подтвердил эксперт, так как именно он отвечает за установленные технологии и процессы. -Модель зрелости — это своего рода световой меч. Он может может быть в руках повстанцев и в руках Империи. Для нас это ориентир, который помогает командам расти. Они сами определяют, что важно прокачать в первую очередь, что во вторую, и берут эти цели себе в [OKR](https://github.com/avito-tech/playbook/blob/master/goal-setting.md). Мы надеемся, что вы тоже будете использовать модель зрелости во благо. +Модель зрелости — это своего рода световой меч. Он может может быть в руках повстанцев и в руках Империи. Для нас — это ориентир, который помогает командам расти. Они сами определяют, что важно прокачать в первую очередь, что во вторую, и берут эти цели себе в [OKR](https://github.com/avito-tech/playbook/blob/master/goal-setting.md). Мы надеемся, что вы тоже будете использовать модель зрелости во благо. ### Как не надо использовать модель -Неправильно понимать модель зрелости как способ оценить, кто в компании лучше, кто хуже, а потом составить рейтинг, плохих поставить в угол, а хороших — премировать. Мы никого не сравниваем и наказываем команды за уровни ниже базового. +Неправильно понимать модель зрелости как способ оценить, кто в компании лучше, кто хуже, а потом составить рейтинг, плохих поставить в угол, а хороших — премировать. Мы никого не сравниваем и не наказываем команды за уровни ниже базового. -Не нужно затягивать в секции модели практики, которых еще вообще нет в компании и использовать её как инструмент масштабирования процессов или практик. Это инструмент выравнивания и улучшения того, что уже есть в компании. Он не подходит для раскатки нового. +Не нужно затягивать в секции модели практики, которых ещё вообще нет в компании и использовать её как инструмент масштабирования процессов или практик. Это инструмент для выравнивания и улучшения того, что уже есть в компании. Он не подходит для раскатки нового. ### Бизнес-польза модели Основная задача технического директора — сделать так, чтобы доставка фичей до клиентов работала как часы, а команда перформила с определённой скоростью и определённым качеством. @@ -237,7 +238,7 @@ Delivery — процесс от продуктового бэклога до в Конечная цель внедрения инструмента — сильная инженерная культура. Это просто способ, который позволяет системно прокачивать команды. -Бонусы модели зрелости — коммуникация между командами становится лучше, потому что они следуют одним и тем же стандартам. Нет зоопарка в технологиях и зоопарка в плане процессов. Благодаря общим правилам всем инженерам компании комфортнее работать друг с другом. +Бонусы модели зрелости — коммуникация между командами становится лучше, потому что они следуют одним и тем же стандартам. Нет зоопарка в технологиях и зоопарка в плане процессов. Благодаря общим правилам, всем инженерам компании комфортнее работать друг с другом. ### Выученные уроки и итоги