Update avito-developer-practice.md

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 — процесс от продуктового бэклога до в
 
 Конечная цель внедрения инструмента — сильная инженерная культура. Это просто способ, который позволяет системно прокачивать команды. 
 
-Бонусы модели зрелости — коммуникация между командами становится лучше, потому что они следуют одним и тем же стандартам. Нет зоопарка в технологиях и зоопарка в плане процессов. Благодаря общим правилам всем инженерам компании комфортнее работать друг с другом. 
+Бонусы модели зрелости — коммуникация между командами становится лучше, потому что они следуют одним и тем же стандартам. Нет зоопарка в технологиях и зоопарка в плане процессов. Благодаря общим правилам, всем инженерам компании комфортнее работать друг с другом. 
 
 ### Выученные уроки и итоги