From 1c77d87518f4418e387ad4d7a55d072c2fe5f61f Mon Sep 17 00:00:00 2001 From: Mike Klyuev Date: Thu, 21 May 2020 18:17:46 +0300 Subject: [PATCH] Update avito-developer-practice.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Добавил про Архитектурный комитет --- avito-developer-practice.md | 49 +++++++++++++++++++++++++++++++++++++ 1 file changed, 49 insertions(+) diff --git a/avito-developer-practice.md b/avito-developer-practice.md index 134e7fa..59fe97e 100644 --- a/avito-developer-practice.md +++ b/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 человек, представляющие все важные функции и кластеры разработки. Присутствие всех членов комитета на встрече не требуется, состав подбирается модераторами дял каждого конкретного кейса. Два человека выполняют роль Модераторов.