dev-roadmap-avito-playbook/avito-developer-practice.md

# Инженерные практики

- [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#архитектурный-комитет) - ревью архитектуры приложений и сервисов

## Live Site Review (LSR)

Мы за постоянные улучшения в нашей жизни, поэтому по крупным инцидентам всегда ищем как избежать повторения: для этого мы расследуем причины, придумываем как пофиксить корневые проблемы и так и делаем. Практика позаимствована у инженеров Google, вот ссылка на [книгу по теме](https://landing.google.com/sre/sre-book/chapters/introduction/).

### Зачем нужен LSR
Мы хотим, чтобы пользователи и сотрудники Авито испытывали меньше проблем (процессных, инфраструктурных, деградаций для пользователей). Для этого хочется сразу узнавать о том, что что-то сломалось, и очень быстро чинить то, что можно починить. А еще хочется, чтобы разные юниты не наступали на одни и те же грабли. Для этого, помимо круглосуточного мониторинга, нужен процесс разбора инцидентов (постмортем/ Post-mortem) - чтобы понять их корневые причины и договориться о том, как избегать аналогичных проблем в дальнейшем. Итогом постмортемов, должны стать улучшения используемых инструментов или процессов, предложения новых best practices и информационные рассылки на всю инженерную команду.

### С помощью каких инструментов мы отслеживаем проблемы
- мониторинг в Grafana - общий дашборд по пользовательским событиям
- сообщения в специальном канале в Slack
- алерты от синтетического мониторинга
- алерты от мониторингов сервисов

### Как реагируем на инциденты
- за работоспособностью всего Авито следит команда мониторинга, они доступны 24x7 и следят за работоспособностью переданных им сервисов
- у части команд есть свои дежурные, которые быстро реагируют на сообщения и алерты
- заводим задачу в JIRA - проект LSR, тип задачи Post-mortem, заполняет тот, кто больше всех в контексте
- AutoLSR создаётся автоматически на основании анализа деградаций, в команде есть ответственный, который линкует AutoLSR и Post-mortem

### Кто и в каких случаях заводит Post-mortem

- Был серьезный инцидент на продакшене, по причине, Post-mortemа на которую еще нет. Проверить, что Post-mortemа еще нет, можно в отдельной базе
- Серьезный инцидент на этот раз не случился, но нашли проблему, которая может его вызвать и нужно не забыть ее проработать
- Серьезный инцидент на этот раз не случился, но хочется провести разбор ситуации - есть ощущение что результаты разбора будут полезны нескольким командам
- Есть ощущение, что Post-mortem в этом случае полезен

Завести Post-mortem может любой через создание тикета с таким типом в проекте LSR или написав боту в треде в специальном канале Slack

### Что писать в Post-mortem
В Post-mortem пишем любую информацию, которая кажется полезной. Тут есть единственное правило - писать нужно так, чтобы через полгода можно было прочитать и понять написанное, т.е., если пишем о конкретном дне, пишем "22 сентября", а не "вчера", если прикладываем ссылку на график, то следим, чтобы не потерялся таймстемп.

Поля шаблона:
- Summary (обязательное) - заголовок. Пишите так, чтобы, увидев эту строчку как заголовок LSR-встречи или в квартальном отчете, вы могли вспомнить о чем тут вообще речь
- Description (обязательное) - пишем суть проблемы, сore reason и любую другую информацию, которая может быть полезна при разборе. Так же сюда можно писать пожелания по разбору, например, "обсудим сами внутри кластера" или "обязательно позови на разбор Васю П"
- Priority (обязательное) - приоритет Post-mortem. Выставляем высокий, если этот Post-mortem на ваш взгляд заслуживает особого внимания
- Slack link - ссылка на обсуждение. Лучше всего, если это будет ссылка на специальный канал для обсуждения инцидентов. Если обсуждений было несколько в разных каналах, пишем сюда наиболее ценное на ваш взгляд. Остальные в этом случае добавляем в Description.
- Unit (обязательное) - проставляем сюда только 1 юнит, в котором что-то сломалось
- Пострадавшие сервисы - перечисляем все сервисы, которые сломались, кроме того сервиса, где собственно была ошибка. В основном, поле нужно для того, чтобы видеть зависимости сервисов, а так же видеть где нужно поработать над graceful degradation
- Участники - пишем сюда всех, кого стоит позвать на разбор post-mortem. Внимание: это не участники инцидента - это именно участники post-mortem. если вы хотите чтобы вас позвали на разбор - добавьте себя в это поле
- Были ли раньше такие проблемы - когда заводится новый Post-mortem, оставляем "нет". Если 2-ой инцидент линкуется к Post-mortem, меняем на "да"
- Вероятность повторного возникновения ближайшие полгода - тут просто "экспертная оценка"
- Action items (AI) - если есть идеи/предложения/пожелания, не стесняйтесь их сюда записывать. При обсуждении LSR будет меньше шансов про них забыть
- Link from Helpdesk -  добавляет саппорт, если были обращения пользователей в HelpDesk
- HD Count - количество пользователей, которых зааффектила проблема и они обратились в HelpDesk (заполняется/обновляется автоматически, если заполнено поле Link from Helpdesk )
- Продолжительность - абсолютное значение в минутах

### Критичность (Priority)
У Post-mortem в Jira есть поле Priority - критичность проблемы. Сейчас используется следующая градация:
- Critical - проблема с высокой вероятностью повторения, характеризуется недоступностью всего Авито
- Major - проблема с высокой вероятностью повторения, характеризуется недоступностью части функционала
- Normal - проблема с невысокой вероятностью повторения, характеризуется недоступностью части функционала
- Minor - проблема с невысокой вероятностью повторения, характеризуется недоступностью части функционала без значимого ущерба для пользователей.

### Как разбирается Post-mortem
Основная ценность, которую получаем от Post-mortem - это Action Items (AI), то есть действия, направленные на то, чтобы проблема не возникала в дальнейшем или чтобы мы раньше ее замечали и быстрее чинили.

- Post-mortem заводится в статус OPEN. В этом статусе он висит какое-то время (обычно полдня или день) и его дополняют данными все желающие.
- Ответственный сотрудник из отдела QA проверяет и, при необходимости, дополняет Post-mortem и переводит его в статус PREPARED. PREPARED - значит, что Post-mortem готов к разбору.
- Часто для выработки Aсton Items (AI) собирается отдельная встреча. Возможны опции:
  - Команда, если захочет, может провести встречу по разбору Post-mortem самостоятельно - об этом достаточно написать в Post-mortem. В этом случае после встречи и заполнения AI  Post-mortem нужно не забыть перевести в статус IN PROGRESS.
  - Команда может попросить организовать встречу, указав кого точно нужно на нее позвать в тикете Post-mortem.
 - Если особых пожеланий от юнита не было,  в специальный канал в Slack публикуется предложение встречи . Все кто поставит +1 под сообщением получат приглашение на встречу в календаре. Все встречи по LSR можно найти в календаре LSR - и прийти на любую встречу, даже если приглашение не приходило.
 - Если в канале желающих присутствовать на встрече не нашлось и юнит на проведении встречи не настаивает, встреча не проводится, ограничиваемся обсуждением в слаке - обычно для этого создается отдельный чат.
 - Происходит обсуждение, на котором вырабатываются 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 человек, представляющие все важные функции и кластеры разработки. Присутствие всех членов комитета на встрече не требуется, состав подбирается модераторами дял каждого конкретного кейса. Два человека выполняют роль Модераторов.