Update avito-developer-practice.md

avito-developer-practice.md

@@ -4,71 +4,113 @@
 - [Архитектурный комитет](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 и информационные рассылки на всю инженерную команду.
+Поэтому кроме круглосуточного мониторинга у нас есть процесс разбора инцидентов. И сами пожары на проде, и работы по анализу проблем мы называем live site review или LSR. Практика позаимствована у инженеров Google, вот ссылка на [книгу по теме](https://landing.google.com/sre/sre-book/chapters/introduction/).
 
-### С помощью каких инструментов мы отслеживаем проблемы
-- мониторинг в Grafana - общий дашборд по пользовательским событиям
-- сообщения в специальном канале в Slack
-- алерты от синтетического мониторинга
-- алерты от мониторингов сервисов
+### С помощью каких инструментов отслеживаем проблемы
+- Мониторинг в Grafana — общий дашборд по пользовательским событиям.
+- Сообщения в специальном канале в Slack.
+- Алерты от синтетического мониторинга.
+- Алерты от мониторингов сервисов.
+
+### Как устроен LSR-процесс
+
+Работу с LSR в Авито начали в 2017 году. Процесс несколько раз менялся, и сейчас выглядит так:
+1. Когда возникает проблема, дежурные видят её в системе мониторинга.
+1. Дежурные сами чинят проблему или привлекают ответственных от команд.
+1. Автоматика фиксирует в Jira продолжительность инцидента, затронутую функциональность и недополученную прибыль. Это называется Auto LSR.
+1. Автоматика же отмечает критичность инцидента в случае больших финансовых потерь или большого количества жалоб от пользователей.
+1. Мы заводим постмортем тикет в Jira c описанием проблемы, которая вызвала инцидент, если такого еще нет. К нему линкуются Auto LSR.
+1. Проводим встречу с командой и экспертами и детально разбираем проблему.
+1. Выполняем все нужные действия по предотвращению подобных инцидентов в будущем.
+1. Закрываем тикет и дополняем базу знаний.
+
+Простые и понятные проблемы мы разбираем внутри команд или в слак-чатиках. А кросс-командные встречи проводим для серьёзных и бизнес-критичных проблем: инфраструктурных, процессных и тех, которые затронули сразу несколько команд. Встречи открытые, их анонс мы публикуем в отдельном канале, и прийти на них может любой человек в компании.
 
 ### Как реагируем на инциденты
-- за работоспособностью всего Авито следит команда мониторинга, они доступны 24x7 и следят за работоспособностью переданных им сервисов
-- у части команд есть свои дежурные, которые быстро реагируют на сообщения и алерты
-- заводим задачу в JIRA - проект LSR, тип задачи Post-mortem, заполняет тот, кто больше всех в контексте
-- AutoLSR создаётся автоматически на основании анализа деградаций, в команде есть ответственный, который линкует AutoLSR и Post-mortem
 
-### Кто и в каких случаях заводит Post-mortem
+За работоспособностью всего Авито следит команда с названием «Мониторинг 24/7». Она всегда доступна и смотрит за всеми сервисами. Если случается «взрыв на проде», эта команда первой отправляется тушить пожар и привлекает дежурных разработчиков при необходимости.
 
-- Был серьезный инцидент на продакшене, по причине, Post-mortemа на которую еще нет. Проверить, что Post-mortemа еще нет, можно в отдельной базе
-- Серьезный инцидент на этот раз не случился, но нашли проблему, которая может его вызвать и нужно не забыть ее проработать
-- Серьезный инцидент на этот раз не случился, но хочется провести разбор ситуации - есть ощущение что результаты разбора будут полезны нескольким командам
-- Есть ощущение, что Post-mortem в этом случае полезен
+Когда сбой устранили, ответственная за функциональность команда выясняет его корневые причины, и любой участник процесса заводит постмортем тикет.
 
-Завести Post-mortem может любой через создание тикета с таким типом в проекте LSR или написав боту в треде в специальном канале Slack
+![](https://habrastorage.org/webt/5m/s9/tj/5ms9tjgpmpxml61etvg5krb1giy.png)
 
-### Что писать в 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 )
-- Продолжительность - абсолютное значение в минутах
+После того, как постмортем тикет заведен, его дополняют данными все желающие. В описание мы вносим любую информацию, которая кажется полезной. Есть единственное правило — описание должно быть таким, чтобы через полгода можно было прочитать и понять написанное. Например, если мы пишем о конкретном дне, то нужна точная дата — «22 сентября», а не «вчера». Если прикладываем ссылку на график, то следим, чтобы не потерялся таймстемп.
 
-### Критичность (Priority)
-У Post-mortem в Jira есть поле Priority - критичность проблемы. Сейчас используется следующая градация:
-- Critical - проблема с высокой вероятностью повторения, характеризуется недоступностью всего Авито
-- Major - проблема с высокой вероятностью повторения, характеризуется недоступностью части функционала
-- Normal - проблема с невысокой вероятностью повторения, характеризуется недоступностью части функционала
-- Minor - проблема с невысокой вероятностью повторения, характеризуется недоступностью части функционала без значимого ущерба для пользователей.
+В постмортем тикете есть фиксированный набор полей.
 
-### Как разбирается Post-mortem
-Основная ценность, которую получаем от Post-mortem - это Action Items (AI), то есть действия, направленные на то, чтобы проблема не возникала в дальнейшем или чтобы мы раньше ее замечали и быстрее чинили.
+**Summary** (обязательное) — это заголовок. Заголовок мы стараемся заполнять так, чтобы увидев его в календаре или в квартальном отчёте, можно было вспомнить, о чём идёт речь.
 
-- 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) в рубрику "что хорошего сделали".
+**Description** (обязательное) — здесь описываем суть проблемы, ключевую причину инцидента и любую другую информацию, которая может быть полезна при разборе. Также сюда команды пишут пожелания по разбору, например «обсудим сами внутри кластера» или «обязательно позовите на встречу Васю».
+
+**Priority** (обязательное) — приоритет тикета. У нас их четыре:
+— Critical — проблема из-за которой недоступен весь Авито.
+— Major — проблема с высокой вероятностью повторения, недоступна часть функциональности.
+— Normal — проблема с невысокой вероятностью повторения, недоступна часть функциональности.
+— Minor — проблема с невысокой вероятностью повторения, недоступна часть функциональности без значимого ущерба для пользователей.
+
+**Slack link** — ссылка на обсуждение инцидента в слаке. Если обсуждений было несколько в разных каналах, то в поле мы вносим наиболее ценное. Остальные в этом случае добавляем в Description.
+
+**Команда** (обязательное) — проставляем сюда только одну команду, которая стала виновником торжества.
+
+**Пострадавшие сервисы** — в этом поле перечисляем все сервисы, которые сломались, кроме того, где была ошибка. Поле нужно для того, чтобы видеть неявные зависимости сервисов и отмечать места, где нужно поработать над graceful degradation.
+
+**Участники** — здесь указываем всех, кого стоит позвать на встречу с разбором инцидента. В их календари потом придёт приглашение.
+
+**Были ли раньше такие проблемы** — когда заводится новый постмортем, в поле ставим «нет». Если происходит второй подобный инцидент, линкуем его тикет с постмортемом и меняем описание на «да».
+
+**Вероятность повторного возникновения в ближайшие полгода** — экспертная оценка того, кто заполняет тикет.
+
+**Action items** — до проведения встречи пишем сюда идеи, предложения и пожелания по инциденту. Так при обсуждении LSR будет меньше шансов про них забыть. Во время обсуждения это поле редактируется.
+
+**Link from Helpdesk** — добавляет саппорт, если были обращения пользователей.
+
+**HD count** — количество пользователей, которые обратились с проблемами по инциденту в HelpDesk. Это поле заполняется и обновляется автоматически, если заполнено поле выше.
+
+**Продолжительность** — абсолютное значение продолжительности инцидента в минутах.
+
+### Как разбираем инциденты на встречах
+
+Когда пожар потушен и тикет заполнен, событие переходит к ответственному из QA-команды. Тот внимательно смотрит на него и разбирается, что происходило, медленно или быстро мы нашли проблему, позвали дежурные сразу тех, кого нужно, или сначала разбудили непричастных. Ответственный проверяет, хватило ли нам графиков для анализа ситуации, что было написано в логах.
+
+После мы создаём встречу для разбора в специальном LSR-календаре. Во встречах участвуют команды, в сервисе которых возникла проблема, те, кто её устранял, и эксперты по технологиям, в которых проявилась проблема.
+
+На разборах постмортемов мы оцениваем влияние инцидента на работу компании, смотрим на проблему с разных сторон и вырабатываем по ней решение. Если предотвратить возникновение проблемы в будущем невозможно, то придумываем, как уменьшить потери от её возникновения. Обычно ответственный заранее обозначает повестку встречи, и мы идём по списку подготовленных вопросов.
+
+**Вот список типовых вопросов, которые стоит обсудить при разборе LSR:**
+- В чём была проблема и какова её первопричина? Если это баг в коде, то полезно посмотреть на процессы тестирования и понять почему его не поймали. Если сбой произошёл из-за возросшей нагрузки, то стоит подумать про регулярное нагрузочное тестирование.
+- Как быстро и откуда узнали о проблеме? Можно ли узнавать быстрее? Возможно, нужны дополнительные мониторинги или алерты. Или стоит отдать отдать имеющиеся команде мониторинга 24/7.
+- Как быстро смогли понять, в чём именно проблема? Возможно, стоит почистить Sentry или добавить логирование.
+- Затронула ли проблема основную функциональность сайта и можно ли уменьшить такое влияние? Например, если сломался счётчик количества объявлений, то страницы сайта ломаться не должны. Тут стоит подумать про graceful degradation.
+- Может ли проблема повториться в других модулях или компонентах системы? Что сделать, чтобы этого не произошло? Например, актуализировать таймауты, добавить обработку долгого ответа.
+- Есть ли платформенное решение, которое помогает избегать таких проблем? Возможно пора начать им пользоваться? В решении таких проблем часто помогают тестохранилка или PaaS.
+- Может ли необходимые для решения проблемы действия сделать команда или нужен отдельный проект, объединяющий несколько команд?
+
+Основная ценность, которую мы получаем от встреч — это action items, то есть действия, направленные на то, чтобы проблема не возникала в дальнейшем или чтобы мы раньше её замечали и быстрее чинили. Это могут быть как правки в коде, так и проекты по улучшения инструментов или процессов, предложения новых best practices и информационные рассылки на всю инженерную команду.
+
+Хорошие action items:
+- могут быть задачей или проектом, но не процессом;
+- всегда имеют ответственного и ожидаемый срок завершения;
+- будут сделаны в ближайшие полгода.
+
+Плохие action items:
+- похожи на высказывания Капитана Очевидность, например: «нужно лучше тестировать» или «перестать делать глупые баги»;
+- точно не будут сделаны в ближайшие полгода.
+
+Мы договариваемся о кусочках, которые надо сделать обязательно, и таких, которые сделать желательно. Когда action items сформулированы, мы заносим их в Jira — это тикеты в разных проектах, слинкованные с постмортемом. В начале описания необязательных задач ставим вопросительный знак, чтобы их можно было сразу отличить. По остальным считаем, что их желательно сделать в течение месяца. Чтобы это работало, отдельный человек следит за выполнением всех action items и периодически проходится с напоминаниями по людям, которым они назначены.
+
+### Как ведём базу знаний
+
+Самые интересные или общественно полезные постмортемы и список рекомендаций по ним мы вносим в базу знаний. Ответственный из QA-команды отбирает их вручную и раз в две недели публикует в общем канале разработки под заголовком «стенгазета LSR». Все выпуски стенгазеты также собраны в Сonfluence, чтобы можно было быстро найти, как решались те или иные инциденты.
+
+Благодаря стенгазете многие делают исправления в своих сервисах до того, как они сломались. В итоге LSR с одними и теми же причинами в разных командах становится заметно меньше.
+
+![](https://habrastorage.org/webt/ss/ti/ov/sstiov8uuw5x0wegwp__1qlyuao.png)
 
 ## Архитектурный комитет