Русский
Русский
English
Статистика
Реклама

Lsr

Live site review. Разбираем инциденты

26.11.2020 18:13:16 | Автор: admin

Нам важно, чтобы Авито стабильно инадёжно работал. Нобывает, что несмотря нанаши усилия, что-то ломается. Это может быть железо или какой-то архитектурный компонент под высокой нагрузкой. Вэтом случае важно починить возникшую проблему как можно быстрее. Для этого унас есть развесистая система мониторинга иалертов, атакже служба круглосуточных дежурных.


Помимо того, чтобы быстро восстановить работу сервиса, важно избежать повторения проблем там, где это возможно. Атам, где предотвратить аварии совсем нельзя, минимизировать ущерб как для пользователей, так идля сотрудников.


Поэтому кроме круглосуточного мониторинга унас есть процесс разбора инцидентов. Исами пожары напроде, иработы поанализу проблем мыназываем live site review или LSR. Яотвечаю зачасть работ сLSR после пожаротушения ихочу поделиться нашими наработками.



Минутка контекста


Авито большая компания. Наноябрь 2020 года унас:


  • 1134 сервиса впродакшене.
  • 58команд разработки, вкаждой изкоторых отодной дочетырёх фиче-команд поменьше.
  • 200-250 релизов изменений вдень.

Ноядумаю, что процессы проблем-менеджмента окоторых расскажу дальше, легко адаптировать ккомпании любого размера.


Как устроен LSR-процесс


Работу сLSR вАвито начали в2017году. Процесс несколько раз менялся, исейчас выглядит так:


  1. Когда возникает проблема, дежурные видят еёвсистеме мониторинга.
  2. Дежурные сами чинят проблему или привлекают ответственных откоманд.
  3. Автоматика фиксирует вJira продолжительность инцидента, затронутую функциональность инедополученную прибыль. Это называется Auto LSR. Автоматикаже отмечает критичность инцидента вслучае больших финансовых потерь или большого количества жалоб отпользователей.
  4. Мызаводим постмортем тикет вJira cописанием проблемы, которая вызвала инцидент, если такого еще нет. Кнему линкуются Auto LSR.
  5. Проводим встречу скомандой иэкспертами идетально разбираем проблему.
  6. Выполняем все нужные действия попредотвращению подобных инцидентов вбудущем.
  7. Закрываем тикет идополняем базу знаний.

Простые ипонятные проблемы мыразбираем внутри команд или вслак-чатиках. Акросс-командные встречи проводим для серьёзных ибизнес-критичных проблем: инфраструктурных, процессных итех, которые затронули сразу несколько команд. Встречи открытые, иханонс мыпубликуем вотдельном канале, иприйти наних может любой человек вкомпании.


Как реагируем наинциденты


Заработоспособностью всего Авито следит команда сназванием Мониторинг 24/7. Она всегда доступна исмотрит завсеми сервисами. Если случается взрыв напроде, эта команда первой отправляется тушить пожар ипривлекает дежурных разработчиков при необходимости.


Когда сбой устранили, ответственная зафункциональность команда выясняет его корневые причины, илюбой участник процесса заводит постмортем тикет.



Что описываем впостмортем тикете


После того, как постмортем тикет заведен, его дополняют данными все желающие. Вописание мывносим любую информацию, которая кажется полезной. Есть единственное правило описание должно быть таким, чтобы через полгода можно было прочитать ипонять написанное. Например, если мыпишем оконкретном дне, тонужна точная дата 22сентября, аневчера. Если прикладываем ссылку награфик, тоследим, чтобы непотерялся таймстемп.


Впостмортем тикете есть фиксированный набор полей.


Summary (обязательное) это заголовок. Заголовок мыстараемся заполнять так, чтобы увидев его вкалендаре или вквартальном отчёте, можно было вспомнить, очём идёт речь.


Description (обязательное) здесь описываем суть проблемы, ключевую причину инцидента илюбую другую информацию, которая может быть полезна при разборе. Также сюда команды пишут пожелания поразбору, например обсудим сами внутри кластера или обязательно позовите навстречу Васю.


Priority (обязательное) приоритет тикета. Унас ихчетыре:


  • Critical проблема из-за которой недоступен весь Авито.
  • Major проблема свысокой вероятностью повторения, недоступна часть функциональности.
  • Normal проблема сневысокой вероятностью повторения, недоступна часть функциональности.
  • Minor проблема сневысокой вероятностью повторения, недоступна часть функциональности без значимого ущерба для пользователей.

Slack link ссылка наобсуждение инцидента вслаке. Если обсуждений было несколько вразных каналах, товполе мывносим наиболее ценное. Остальные вэтом случае добавляем вDescription.


Команда (обязательное) проставляем сюда только одну команду, которая стала виновником торжества.


Пострадавшие сервисы вэтом поле перечисляем все сервисы, которые сломались, кроме того, где была ошибка. Поле нужно для того, чтобы видеть неявные зависимости сервисов иотмечать места, где нужно поработать над graceful degradation.


Участники здесь указываем всех, кого стоит позвать навстречу сразбором инцидента. Вихкалендари потом придёт приглашение.


Былили раньше такие проблемы когда заводится новый постмортем, вполе ставим нет. Если происходит второй подобный инцидент, линкуем его тикет спостмортемом именяем описание нада.


Вероятность повторного возникновения ближайшие полгода экспертная оценка того, кто заполняет тикет.


Action items допроведения встречи пишем сюда идеи, предложения ипожелания поинциденту. Так при обсуждении LSR будет меньше шансов про них забыть. Вовремя обсуждения это поле редактируется.


Link from Helpdesk добавляет саппорт, если были обращения пользователей.


HDcount количество пользователей, которые обратились спроблемами поинциденту вHelpDesk. Это поле заполняется иобновляется автоматически, если заполнено поле выше.


Продолжительность абсолютное значение продолжительности инцидента вминутах.


Как разбираем инциденты навстречах


Когда пожар потушен итикет заполнен, событие переходит вмою зону ответственности. Явнимательно смотрю нанего иразбираюсь, что происходило, медленно или быстро мынашли проблему, позвали дежурные сразу тех, кого нужно, или сначала разбудили непричастных. Япроверяю, хватилоли нам графиков для анализа ситуации, что было написано влогах.


После ясоздаю встречу для разбора вспециальном LSR-календаре. Вовстречах участвуют команды, всервисе которых возникла проблема, те, кто еёустранял, иэксперты потехнологиям, вкоторых проявилась проблема.


Наразборах постмортемов мыоцениваем влияние инцидента наработу компании, смотрим напроблему сразных сторон ивырабатываем поней решение. Если предотвратить возникновение проблемы вбудущем невозможно, топридумываем, как уменьшить потери отеёвозникновения. Обычно язаранее обозначаю повестку встречи, имыидём посписку подготовленных вопросов.


Вот список типовых вопросов, которые стоит обсудить при разборе LSR:
  • Вчём была проблема икакова еёпервопричина? Если это баг вкоде, тополезно посмотреть напроцессы тестирования ипонять почему его непоймали. Если сбой произошёл из-за возросшей нагрузки, тостоит подумать про регулярное нагрузочное тестирование.
  • Как быстро иоткуда узнали опроблеме? Можноли узнавать быстрее? Возможно, нужны дополнительные мониторинги или алерты. Или стоит отдать отдать имеющиеся команде мониторинга 24/7.
  • Как быстро смогли понять, вчём именно проблема? Возможно, стоит почистить Sentry или добавить логирование.
  • Затронулали проблема основную функциональность сайта иможноли уменьшить такое влияние? Например, если сломался счётчик количества объявлений, тостраницы сайта ломаться недолжны. Тут стоит подумать про graceful degradation.
  • Можетли проблема повториться вдругих модулях или компонентах системы? Что сделать, чтобы этого непроизошло? Например, актуализировать таймауты, добавить обработку долгого ответа.
  • Естьли платформенное решение, которое помогает избегать таких проблем? Возможно пора начать импользоваться? Врешении таких проблем часто помогают тестохранилка или PaaS.
  • Можетли необходимые для решения проблемы действия сделать команда или нужен отдельный проект, объединяющий несколько команд?

Основная ценность, которую мыполучаем отвстреч это action items, тоесть действия, направленные нато, чтобы проблема невозникала вдальнейшем или чтобы мыраньше еёзамечали ибыстрее чинили. Это могут быть как правки вкоде, так ипроекты поулучшения инструментов или процессов, предложения новых best practices иинформационные рассылки навсю инженерную команду.


Хорошие action items:


  • могут быть задачей или проектом, нонепроцессом;
  • всегда имеют ответственного иожидаемый срок завершения;
  • будут сделаны вближайшие полгода.

Плохие action items:


  • похожи навысказывания Капитана Очевидность, например: нужно лучше тестировать или перестать делать глупые баги;
  • точно небудут сделаны вближайшие полгода.

Мыдоговариваемся окусочках, которые надо сделать обязательно, итаких, которые сделать желательно. Когда action items сформулированы, мызаносим ихвJira это тикеты вразных проектах, слинкованные спостмортемом. Вначале описания необязательных задач ставим вопросительный знак, чтобы ихможно было сразу отличить. Поостальным считаем, что ихжелательно сделать втечение месяца. Чтобы это работало, яотдельно слежу завыполнением всех action items ипериодически прохожусь снапоминаниями полюдям, которым они назначены.


Как ведём базу знаний


Самые интересные или общественно полезные постмортемы исписок рекомендаций поним явношу вбазу знаний. Яихотбираю вручную ираз вдве недели публикую вобщем канале разработки под заголовком стенгазета LSR. Все выпуски стенгазеты также собраны вСonfluence, чтобы можно было быстро найти, как решались теили иные инциденты.


Благодаря стенгазете многие делают исправления всвоих сервисах дотого, как они сломались. Витоге LSR содними итемиже причинами вразных командах становится заметно меньше.



Аещё поLSR можно строить любопытную аналитику


Кроме того унас есть много графиков поLSR: попричинам, виновникам, пострадавшим сервисам, продолжительности, времени возникновения, времени суток. Вних яищу тренды исовпадения. Например, если какой-то сервис падает при любой неисправности любого стороннего сервиса, стоит поработать над его стабильностью: переделать, где возможно, обращения наасинхронные, добавить graceful degradation, может быть, увеличить пул ресурсов.


Лирическое заключение


Проблем-менеджемент вАвито часть контроля качества. Авконтроле качества есть два основополагающих вопроса: когда начать тестировать икогда закончить тестировать. Если поповоду того, когда начать, существует много разных подходов, тостем, когда закончить, всё ещё сложнее.


Протестировать абсолютно всё нереально, поэтому вкакой-то момент надо сказать, что мыпротестировали достаточно хорошо, иостановиться. Ачто такое достаточно хорошо? Если врелизе нашли 100 багов это достаточно? Аесли избагов 20критичных, 50средних, аостальные некритичные это достаточно хорошо или недостаточно? Проблема втом, что ответ насамом деле зависит неоттого, сколько багов нашли, аоттого, сколько ненашли тестировщики, нозаметят пользователи.


Спомощью LSR ясчитаю тебаги, которые помешали пользователям. Мыполучаем некую финальную точку вконтроле качества, скоторой видно весь цикл разработки как онесть. Исразу становится понятно, куда прийти сотверткой иподкрутить.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru