Начнем эту увлекательную историю издалека. Во время первого локдауна, в начале 2020 года, сайт Леруа Мерлен испытал бóльшую нагрузку, чем когда-либо. Проводившие много времени дома и на даче наши пользователи взялись чинить полочки, проектировать новые кухни и всеми силами делать свой дом уютнее, воплощая в жизнь новые ремонтные проекты, а инженеры были вынуждены экстренно адаптировать системы под небывалый наплыв трафика. Тогда же стало ясно, что начатое незадолго до локдауна внедрение элементов SRE нужно ускорить.

Привет! Я Дмитрий Шувар, руководитель направления SRE Леруа Мерлен в России.

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

Мы говорим о SRE как о работе с системами с точки зрения пользователя.

Одна из задач инженеров по надежности — управление уровнем сервиса. Это помогает минимизировать влияние, частоту и вероятность повторения инцидентов.

Интересно, что одна из первых проблем, с которыми можно столкнуться при адаптации практик, — это культура разработки. Без принятия культуры и мышления, лежащих в основе SRE, у вас просто будут появляться новые процессы, сотрудники, вы даже прочтете ряд известных книг, но так, как у ребят из гугла, сделать все равно не получится — хотя бы потому, что условия другие.

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

Как клиенты используют ваши системы и что важно для них?
Каково отношение команд к инцидентам? Какие уроки извлечены? В командах доверительные отношения?
Принимаются ли решения, которые основаны на данных?

Ключевые метрики

Согласно классическому подходу, при внедрении SRE первым делом надо определить SLI, SLO и SLA. К сожалению, у нас так не получилось. Во время локдауна нам надо было сфокусироваться на системах, а не составлять документы, поэтому сначала мы потушили все пожары и масштабировали все, что только можно. Показателями занялись позже: выработали подход, подготовили шаблоны и стали ходить по командам, объяснять потребность, собирать данные.

В Леруа Мерлен более 100 команд, сфокусированных на разработке приложений и инфраструктуре для наших продуктов и сервисов, поэтому процесс идет до сих пор. Кто-то определился, а кто-то еще размышляет, что же является для их систем SLO и какие SLI они считают ключевыми.

Многие спрашивают, что эти аббревиатуры означают и зачем они.

Говорим примерно следующее:

«Как понять, что ваша система или сервис работает исправно? А как это понять вашему коллеге из соседней команды, у которого ваша система — это зависимость? Необходимо определить и зафиксировать ключевые показатели, чтобы был некий унифицированный метод определения состояния систем, когда, даже не зная архитектуры, можно однозначно понять, в порядке система или нет».

SLI — это количественные показатели, которые часто агрегируются по окну измерения и выражаются в виде доли, среднего значения или процентиля.

Обычно SLI — это отношение двух чисел: количество хороших событий, деленное на общее количество событий.

Например, вы можете посмотреть количество успешных HTTP-запросов / общее количество HTTP-запросов. Значение SLI будет варьироваться от 0% (ничего не работает) до 100% (ничего не сломано).

Чтобы помочь командам определить SLI, мы решили для начала взять подход, используемый в Google, — те самые «four golden signals» (latency, traffic, errors и saturation).

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

Traffic измеряет скорость запросов за определенный период времени.

С помощью Errors измеряют количество неудачных запросов.

Saturation измеряет количество запросов, которые система обрабатывает в данный момент.

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

К сожалению, в первые итерации получается определить лишь часть из этих показателей, и стоит зафиксировать хотя бы их. Рекомендация есть слона по кускам, а не всего за раз тут к месту. Например, нам пришлось отбросить один из сигналов. Определить показатели saturation, чтобы они отображали доступность сервиса для потребителя, — достаточно трудоемкая задача, и мы решили временно отложить ее, чтобы сконцентрироваться на оставшихся трех. Дальше мы долго говорили с командами об SLO и начали работать над процессом и инструментами для работы с нашими целями надежности.

Что дальше? Откуда брать эти SLI?

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

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

Теперь давайте поговорим про техническую часть. Это нужно, чтобы мы понимали друг друга и имели общую терминологию. Мы собираем метрики приложений, метрики обычно хранятся в TSDB, а чтобы получить общее понимание метрик в этих ваших системах хранения и мониторинга, давайте объясним, из чего оно состоит. Обычно это value, sample, metric и time series.

Value — это значение, которое на любом континенте значение, фактически это результат измерения. Например, 100500 HTTP-запросов, которые сервис получил с момента старта.

Sample — это value + timestamp. Например, 100500 HTTP-запросов, которые сервис получил с момента старта, измеренных 2022-12-31 16:30 UTC.

Metric — это уникальный идентификатор измеряемого ресурса. Он состоит из имени семейства метрик с прикрепленными к нему лейблами. Например, http_requests_total{pod="billing-1"} и http_requests_total{pod="delivery-2"} — это две разные метрики из семейства метрик http_requests_total.

Time series (чаще «series») — это Metric + любое количество связанных Sample с этим id. Например, http_requests_total{pod="billing-1"} с семплами 700@16:30:00 UTC, 800@16:30:15 UTC, 900@16:30:15 UTC и т. д.

Active time series (чаще «active series») — это Metric, которая записала хотя бы один семпл за последние 20 минут.

Теперь давайте вернемся к более простым вещам.

SLO — это четко определенные, конкретные цели или обещания для доступности системы.

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

Мы считаем, что SLO — это внутреннее обещание уровня качества системы, которое должно быть достигнуто. Раз это обещание, то оно может быть приватным и публичным. Но мы считаем хорошей практикой публиковать его для соседних команд. Это помогает понимать зависимости и помогает в планировании работы в будущих спринтах на основе данных.

Но для абстрактного счастья пользователей недостаточно просто собирать данные, дальше потребуется определиться с Error budget и Burn rate.

Бюджет ошибок — это количество ошибок (обусловленных SLI), которые вы можете иметь за определенный период времени, это зависит от выбранных значений SLO, если вам лень считать в голове, есть калькулятор (https://uptime.is/).

Burn rate — это скорость расходования бюджета ошибок. Мы используем это как один из подходов к оповещению для работы по управлению нашими SLO как обещаниями и уровнем сервиса, который мы пообещали. От скорости, с которой вы расходуете свой бюджет ошибок, зависит, что планировать на следующий спринт и на чем должен быть фокус команды.

Вообще, справедливо говорят, что истории из книг по SRE работают только в Google. На бумаге все выглядит красиво, но на практике оказывается, что это работает только у них. И тем не менее это отличная идея, которую они продвигают: вам не нужно выставлять сотни показателей на дашборд, для начала хватит и одного значения SLO по доступности.

Если недостаточно 4 золотых сигналов, то можно использовать и другие индикаторы.

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

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

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

Как еще повысить надежность приложений, независимо от их языка или платформы?

Для приложений некоторые из распространенных методов включают изоляцию компонентов, реализацию стратегий самовосстановления, а также выполнение периодических проверок.

Классическая история: пользователь жалуется на доступность сервиса, конечно же, выясняется, что у всех в команде «все работает! вот же зашел, все открывается!». Однако пользователя не волнует, что у конкретной команды одного из микросервисов все работает. У него не работает, он не получает сервис. Доступность сервиса у пользователей — это главный приоритет с точки зрения SRE. Это очень важный момент, и он требует перестройки образа мышления.

Чтобы наблюдать систему «глазами пользователя», обычных систем мониторинга недостаточно. Всегда можно поднять условный мониторинг и увидеть, что поды рестартятся или оперативная память занята на 90%, но это обычно не имеет никакого значения, если пользователь не может заказать товар, например елку на Новый год, или видит заглушку, которая просит его выключить впн. Если поды рестартятся — это нормально, если память занята за 90% — это тоже нормально. Пользователи этого даже не заметят, ведь это не является ситуацией отказа. А вот если у пользователя недоступна корзина — это проблема.

Чтобы помочь коллегам легче ориентироваться в многообразии инструментов Observability стека и избавить от нужды поднимать свой собственный «внутрикомандный» комплект сервисов, еще в самом начале пути мы зафиксировали конкретный стек таких инструментов (https://leroymerlin-tech.ru/stack/table/), чтобы причесать достаточно разнообразный набор то тут, то там используемых продуктов. Для сбора метрик мы используем комбинации из white-box и black-box мониторинга, синтетические проверки, системы real using и application Performance мониторинга, системы сквозных трассировок и множество других систем, которые помогают нам минимизировать влияние инцидентов, найти корневые причины и снизить все четыре MTTR*.

R в данном случае может означать решение (repair), реагирование (respond), устранение (resolve) или восстановление (recovery), в зависимости от контекста.

Запросы на изменения

Давайте поговорим об изменениях и о том, как ими управлять. Мы любим и ценим процесс RFC (request for change) — запросов на изменения.

*Термином «RFC» мы называем одновременно и процесс, и артефакт в виде документа.

Когда команда одного сервиса хочет внести изменение в продакшен, она должна получить одобрение от команд зависимых сервисов. Например, кто-то говорит: «Наша команда хочет выкатить изменение, которое затронет изменение API контракта с другим сервисом». Его зависимости отвечают: «Нет, в это время у нас трафик, давай перенесем». Они договариваются о подходящем времени и только тогда вносят изменения. RFC — неотъемлемая часть SRE.

В разных командах в процессе участвуют разные люди. Это может быть как разработчик, так и деливери-менеджер, который заинтересован, чтобы его сервис соответствовал обещаниям. Считаем, что управление уровнем сервиса начинается с прозрачности и планирования изменений, это означает, что ты подробно описал в документе, какие изменения будут произведены, какие соседи будут затронуты, сколько времени планируется, сколько времени потребуется на откат. Особенно интересно происходит выбор окна для изменений, так как у нас трафик есть всегда за счет того, что наши магазины расположены во всех часовых поясах, от Владивостока до Калининграда.

Каждое изменение должно быть согласовано, но это в идеальном мире. У нас запрета на деплой без согласования нет, кроме времени, когда у нас фриз, обычно это новогодние и майские праздники. Например, в классическом подходе SRE-инженеры внедрены в продуктовые команды, проводят код-ревью и могут наложить на релиз или любое другое изменение вето.

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

Чек-листы

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

Production readiness — это вновь и процесс, и документ, позволяющие начать проектирование надежности сервисов в продакшене. Результатом работы является документ со списком выявленных проблем, что в долгосрочной перспективе должно уменьшить трудозатраты и риски, с которыми может столкнуться продукт.

Хорошо составленный чек-лист является важным компонентом readiness'ов.
Надо не пытаться сделать идеальный чек-лист, а с помощью здравого смысла и прошлого опыта определить важные темы для обсуждения. Цель состоит в том, чтобы заполнить пробелы, которые могут представлять значительный риск, а не в том, чтобы разработать чек-лист, который может покрыть все.

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

Применяемые лучшие практики и состояние продуктов должны учитываться при создании чек-листа, который дает конкретную, полезную информацию, развивающую обратную связь. Слишком большое увлечение лучшими практиками и рекомендациями (например, обсуждение используемых шаблонов проектирования кода) может стать скользкой дорожкой, медленно превращая readiness'ы в обзор архитектуры с несколькими практическими предложениями.

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

Такие подходы повсеместно используются в Google, Spotify, Ringcentral, Grafana, Weaveworks и в других технологичных компаниях.

Чек-листы — это база для будущей автоматизации.

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

Инциденты, много их, а я храбрый апельсин

Управление инцидентами — наверное, главный столп, из которого выросла культура SRE. Что важно: устранить влияние и после обсудить, как не допустить повторения поведения системы в будущем для этой или других систем, поделиться своим опытом и наблюдениями с коллегами.

Например, влияние (impact) может быть внутренним, или инфраструктурным, а может и оказывать негативный эффект на опыт пользователей.

Если произошел инцидент, инженер должен ответить на 3 вопроса.

Что случилось?
Какое влияние?
Какие следующие шаги?

После этого следует принять несколько решений.

Открывать инцидент или это не инцидент вовсе?
Какие шаги предпринять, чтобы смягчить воздействие, это временные или долговременные шаги?
Возможно, выделить больше ресурсов (привлечь другие команды/экспертов)?

В Леруа Мерлен мы также следуем процессу управления инцидентами. Мы начали с определения приоритета уровня инцидентов и назвали их p1/p2 или major/minor соответственно, но если вам нравится определять приоритет цветами, размерами футболок или применить любую другую шкалу для изменения, вам никто этого не запретит. После мы подошли к определению ролей, таких как координатор, инцидент-менеджер. Важно заметить, что наш процесс управления инцидентами плавно перетекает в расследование и составление постмортема, в результате чего образуется план действий, о котором расскажем дальше.

Постмортемы — это хорошо

Как известно, хороший постмортем — это заполненный постмортем.

Postmortem (или root cause analysis report) — это снова и процесс, и документ для исследования инцидента и определения причин его возникновения. Он помогает выявить слабые места в системе и разработать меры по их устранению, чтобы избежать повторения подобных ситуаций в будущем.

Postmortem является частью процесса управления надежностью системы и обычно включает в себя следующие шаги.

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

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

Пусть это будет дружеским напоминанием: если у вас нет процесса и подробных документов, то самое время попробовать их в своих командах. Это весело!

И ретроспективы тоже

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

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

Базовое правило для ретро и постмортемов — это безобвинительная риторика. Это позволяет взрастить доверие ваших котанов.

Внутри Леруа Мерлен у нас есть периодические факап-митапы. Мы проводим их вживую и используем пиццу и интересные истории об инцидентах как точку притяжения. Цель митапа — показать, что ошибаются все человеки, понять, какие выводы мы сделали после каждого из происшествий, как действовали во время. Это помогает показать, что инциденты — это нормально, не стоит их бояться, но нужно быть к ним готовым.

Колесо неудачи

Следующая лучшая практика, которая поможет вашим инженерам быть выше, сильнее и сеньернее, это проведение мысленных экспериментов. «Что?! — скажите вы. — Работы на полгода вперед, а он тут мысленные эксперименты предлагает!» Но это вовсе не шутка.

Wheel of Misfortune (https://github.com/dastergon/wheel-of-misfortune) — это хороший повод собраться вместе ~~и порисовать графики~~.

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

Тренировка инженеров — это в первую очередь весело…и полезно.

Саммари

Спасибо, что посмотрели мемы с котами. За один раз сложно описать весь объем работы, который был проделан за несколько лет инженерами и менеджерами в Леруа Мерлен. Мы активно развиваем SRE-практику в компании, проводим внутренние обучения, улучшаем процессы и сервисы, управляем уровнем наших сервисов на основе SLO, RFC, Production readiness аудитов, истории наших инцидентов и детальных постмортемов, а также ищем и нанимаем талантливых инженеров.

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

Data driven SRE