Update avito-developer-practice.md

Добавил про Архитектурный комитет

avito-developer-practice.md

@@ -1,5 +1,8 @@
 # Инженерные практики
 
+- [Live Site Review (LSR)](https://github.com/avito-tech/playbook/blob/master/avito-developer-practice.md#live-site-review-lsr)
+- [Архитектурный комитет]()
+
 ## Live Site Review (LSR)
 
 Мы за постоянные улучшения в нашей жизни, поэтому по крупным инцидентам всегда ищем как избежать повторения: для этого мы расследуем причины, придумываем как пофиксить корневые проблемы и так и делаем. Практика позаимствована у инженеров Google, вот ссылка на [книгу по теме](https://landing.google.com/sre/sre-book/chapters/introduction/).
@@ -66,3 +69,49 @@
  - Происходит обсуждение, на котором вырабатываются Action Items (AI). После того как обсуждение закончено и все AI зафиксированы - Post-mortem переводится в статус IN PROGRESS. IN PROGRESS - значит про AI договорились и они взяты в работу. Команды планируют AI в рамках 20% рабочего времени на "Engineering Excellence".
 - Если AI в работу взять не получается в ближайшие 2 недели, Post-mortem переводится в статус PAUSED с обязательным указание причины и срока когда команда вернется к AI. PAUSED - значит что AI проработаны и согласованы, но ближайшее время ими никто заниматься не будет.
 - После того как все AI выполнены Post-mortem закрывается и переходит в статус DONE. Каждые 2 недели Post-mortem, которые перешли в статус DONE, просматривает сотрудник QA и самые интересные AI публикует в "стенгазету"(канал в Slack) в рубрику "что хорошего сделали".
+
+## Архитектурный комитет
+
+Архитектурный комитет это команда экспертов Авито, которая готова провести ревью архитектуры вашего приложения или высоконагруженного сервиса. Комитет собирается по наличию заявок, но не чаще 2-х раз в неделю. Каждая встреча длится 1.5 часа. Встреча открытая, на нее может прийти любой сотрудник Авито.
+
+### Зачем нужен архитектурный комитет?
+
+- Помочь командам правильно спроектировать сервис или архитектуру
+- Повысить культуру проектирования и осмысленность принятия архитектурных решений.
+- Обеспечить место, где
+  - разработчикам на примере их задач будут подсказывать правильные на текущий момент архитектурные решения
+  - можно провалидировать свои решения широким кругом толковых специалистов
+- Снизить риски нестабильной работы Авито в будущем
+
+В процессе подготовки к презентации команды часто задумаетесь над вещами, которые часто упускаются из виду при проектировании. Это помогает точнее спрогнозировать профиль использования и оценить возможные проблемы. В результате мы получаем более качественное решение, которое не придется переделывать сразу после релиза в продакшен.
+
+### Как понять, что стоит обратиться в архитектурный комитет?
+
+- Идёт выпил из монолита одного сервиса или группы сервисов входящих в один из бизнес-критичных путей:
+- Делается новое платформенное решение которое будет использовать кто-то кроме вашего юнита, например:
+- Делается высоконагруженный сервис. Основные признаки::
+  - больше 500 rps или больше 100 тяжелых запросов / сек (по времени исполнения или кол-ву ресурсов)
+  - сложная работа с данными, обеспечение их целостности
+  - сложная схема масштабирования или ограничения по масштабированию
+  - большое кол-во внешних зависимостей и риски большого latency
+
+Техлиды отвечают за то что все необходимые технические решения пройдут защиту архитектурного комитета. У нас действует правило - не уверен нужен комитет или нет, спроси в специальном чате.
+
+### Чеклист перед встречей архитектурного комитета
+
+- Нужно проработать и описать решение. Для подготовки нужно использовать один из чек-листов (Описание архитектуры приложения, чек-лист для микросервисов, чек-лист для client-side проектов
+- Когда в календаре появится приглашение на встречу, нужно переслать его всем кому важно знать детали реализации
+  - стейкхолдеры
+  - потребители
+  - смежные команды которые затронет решение
+- За 2 рабочих дня до встречи нужно прислать слайды презентации и другие полезные документы/ссылки для ознакомления в канал в слаке
+- Практика показывает, что лучше позвать на встречу отдельного члена команды, который будет только записывать фидбек, не участвуя в обсуждении
+
+### После встречи архитектурного комитета
+- После встречи нужно подготовить и прислать в канал слака выводы и план действий по ним
+- После выводов и планов модератор прошедшей встречи в течение 1-2 рабочих дней собирает дополнительные рекомендации комитета и отправляем команде
+- Если необходимо Модератор организует дополнительную встречу комитета для обсуждения плана действий или результатов его реализации.
+- Если архитектурный комитет не пройден, то идёт прорабатка замечаний и повторная встреча.
+
+### Кто входит в состав комитета?
+Состав участников комитета заранее определён и периодически обновляется, в него входит около 40 человек, представляющие все важные функции и кластеры разработки. Присутствие всех членов комитета на встрече не требуется, состав подбирается модераторами дял каждого конкретного кейса. Два человека выполняют роль Модераторов.