Направление Site Reliability Engineering становится всё более популярным. Хайп не на пустом месте: проблемы и задачи, которые решает SRE, действительно насущны для многих компаний.

Популярность SRE растёт, но знаний о нём всё ещё недостаточно. Я не буду повторять формальные определения, а вместо этого расскажу несколько историй из жизни системного инженера Лёхи. Путь выдуманного Лёхи во многом похож на путь, который прошли реальные крупные компании, где впервые и возникли SRE-инженеры (даже если назывались иначе).

Через историю Лёхи вы узнаете о задачах, которые решает SRE, и причинах, по которым для решения этих задач пришлось выделять отдельный класс инженеров.

Глава 1. Hope is not a strategy

Утро понедельника, инженеру эксплуатации Лёхе звонит разработчик Толя:

— У нас проблема! Ошибки в сервисе «Плутон».

— Подробности будут?

— Там какие-то проблемы при работе с внешними ресурсами. Надо срочно починить! У нас всё лежит в проде.

— Хорошо, сейчас посмотрим.

За пару минут Лёха выясняет, что «Плутон» — это третьестепенный сервис, который обращается во внешние ресурсы и получает от них не очень важные данные. Обработка ошибок в нём не предусмотрена, поэтому если «Плутон» недоступен, то всё ломается. Плюс выяснилось, что до одного из внешних сервисов есть потери пакетов у магистрального провайдера.

— Там потери у магистрального провайдера, часть запросов теряются.

— Ну и? Когда починишь?

— Эм, что? Это не у нас проблема, это у магистрального провайдера!

— Ну значит, звони магистральному провайдеру, пусть срочно чинят!

— Серьезно? Да им пофиг на нас. Могу позвонить в администрацию президента, толку и то больше будет…

— Ну тогда звони нашему провайдеру, пусть с магистральным разберётся, мы платим за сетевое соединение, всё должно быть доступно на 100%!

До перехода в эксплуатацию Лёха 3,5 года работал программистом. Он решил вспомнить прошлое и написал маленький патч для «Плутона» с возможностью автоматически выполнять retry в течение заданного времени.

А диалога про 100% доступность могло бы не состояться, если бы Толик понимал: рассчитывать, что хоть один сервис в мире (да что там в мире, в галактике!) имеет 100% доступность, глупо. Сколько бы ты ни платил денег, это недостижимо. В погоне за 100% доступностью можно растратить весь бюджет, но так и не достигнуть её. Куда лучше быть готовым к нестабильности и уметь с ней работать.

Леха понимает, что 100% доступность чего угодно невозможна, но он не разработчик, хоть у него и есть опыт работы разработчиком, это не его зона ответственности. Толик разрабатывает приложения и мог бы научить приложение работать стабильно в нестабильных условиях. Если приложение попадет в зону ответственности Лехи, то мы получим первого SRE. 

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

«Почему никто не стремится к 100% доступности?» — спросил Толя

100% доступность невозможна и бессмысленна. Надо исходить из предположения, что ошибки и сбои неизбежны, и также учитывать стабильность работы внешних компонентов, таких как браузер, мобильная ОС, сеть клиента, так как их надежность зачастую ниже даже 99%, и наши усилия будут незаметны для пользователя . Более того, предстоящие сбои надо учитывать при разработке и эксплуатации.

Оценивая доступность, говорят о «девятках»:

• две девятки — 99%, 

• три девятки — 99,9%, 

• четыре девятки — 99,99%, 

• пять девяток — 99,999%.

Пять девяток — это чуть больше 5 минут даунтайма в год, две девятки — это 3,5 дня даунтайма.

Стремиться к повышению доступности нормально, однако чем ближе она к 100%, тем выше стоимость и техническая сложность сервиса. В какой-то момент происходит уменьшение ROI — отдача инвестиций снижается.

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

При постановке целей учитывают также надёжность окружающих компонентов. Пользователь не заметит переход стабильности приложения от 99,99% к 99,999%, если стабильность его смартфона 99%. Грубо говоря, из 10 сбоев 8 будет приходится на сбои, связанные с работой смартфона, а не самого сервиса. Пользователь к этому привык, поэтому на один лишний раз в год не обратит внимания.

Глава 2. Нестабильность сохраняется

Прошло несколько недель. Лёха расслабился и спокойно занимался привычной работой. 

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

— Сударь, а вы осведомлены, что у вас приложение работает из рук вон плохо? Я бы даже сказал, отвратительно.

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

— Добрый вечер, Иван Эрнестович. А не могли бы вы рассказать, почему сделали такой вывод? Давайте начнём по порядку: о каком приложении речь?

— Я сожалею, что вы не осведомлены о проблемах, но коль уж так, извольте слушать. Во время обеда с партнёром решил я рассказать ему про наш новый продукт «Русь». А он в ответ: «Да слышал я, и даже заходил поглядеть, но так и не дождался загрузки главной страницы». Я ринулся проверять и тут же сам убедился в его словах (лицо Ивана Эрнестовича изобразило отчаяние).

— Мониторинг молчит, но я сейчас все проверю. Изволите ожидать, или отправить результаты расследования почтой?

— Я подожду.

Быстрый обзор системы мониторинга показал, что все показатели в рамках нормы. В частности, за последние 3 часа было всего ~ 1000 неуспешных запросов (неуспешными по мнению Лехи считаются только те запросы, на которые был получен 50x код ответа).

— Проверил данные системы мониторинга, за последние часы было всего 1000 неуспешных запросов, новый сервис работает.

— Сколько? И вы смеете называть это «работает»? Это недопустимый показатель!

— Вы, как всегда, правы, Иван Эрнестович. 1000 неуспешных запросов — звучит грустно. Но это всего 1.5% от общего количества запросов. А это, согласитесь, не так уж и плохо.

— Действительно, 1.5% не так страшно, но все ж почему мы не смогли открыть приложение?

— А вы, говорите, обедали? В таком случае, проблема может быть не с нашим приложением, а с мобильным интернетом или Wi-Fi в ресторане.

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

— Конечно, я уже завёл задачу, мы проведём диагностику и пришлём отчёт.

— И прекратите пугать людей большими цифрами! Жду предложение по изменению системы мониторинга. Твоя идея с соотношением мне понравилась, надобно ее проработать.

С этими словами Иван Эрнестович удалился, а наш герой Лёха выдохнул, дооформил задачу по инциденту, передал данные ночному дежурному и тоже удалился.

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

Фактически Лёха создал то, что сейчас обязательно используется в рамках SRE подхода:

Целевые показатели: SLA, SLI, SLO

Чтобы в следующий раз Иван Эрнестович не был удивлён, узнав о 1,5% проваленных запросов, Лёха выбрал ключевые метрики, по которым можно отслеживать, насколько стабильно работает наш сервис. Также предложил сразу установить для данных метрик границы, при пересечении которых команда, отвечающая за сервис, понимает, что все стало плохо и пора сфокусироваться над стабильностью.  И даже придумал название для таких метрик: соглашение о целевом уровне обслуживания — Service-Level Objective (SLO).

Это соглашение позволяет всем в компании прийти к общему пониманию, что такое надежность (стабильность, доступность) системы. Потому что без него надёжность заботит только отдел эксплуатации. Разработчики ей пренебрегают, а для бизнеса это вообще абстракция, и цифры только путают.

В SLO закрепляют целевые показатели доступности, которые вырабатывают вместе с продакт-оунером. То есть Лёха может их предложить, но утвердить не может. Здесь нужно согласие всех лиц, принимающих решение.

Чтобы понимание было ясным, соглашение должно содержать конкретные числовые показатели — Service Level Indicator (SLI). Это может быть время ответа, количество ошибок в процентном соотношении, пропускная способность, корректность ответа — что угодно в зависимости от продукта.

SLO и SLI — это внутренние соглашения, нужные для взаимодействия команды. Обязанности компании перед клиентами закрепляются в Service Level Agreement (SLA). Это соглашение описывает работоспособность всего сервиса и штрафы за превышение времени простоя или другие нарушения.

Примеры SLA: сервис доступен 99,95% времени в течение года; 99 критических тикетов техподдержки будет закрыто в течение трёх часов за квартал; 85% запросов получат ответы в течение 1,5 секунд каждый месяц.

Среднее время между сбоями и среднее время восстановления — MTBF и MTTR 

Чтобы избежать претензий, Лёха пошёл дальше — сформулировал ещё два показателя: MTBF и MTTR.

MTBF (Mean Time Between Failures) — среднее время между сбоями.

Показатель MTBF зависит от качества кода. То есть чем меньше будет косячить разработчик Толя, тем лучше будет показатель MTBF. Но поскольку каждый косяк Толи влияет на Лёху, у Лёхи должна быть возможность делать ревью кода и, в случае совсем уж очевидных проблем, говорить «Нет!». 

По крайней мере, это предполагает подход SRE. Он же предполагает понимание со стороны команды: когда SRE блокирует какой-то коммит, он делает это не из вредности, а потому, что иначе страдать будут все.

MTTR (Mean Time To Recovery) — среднее время восстановления (сколько прошло от появления ошибки до отката к нормальной работе). 

Показатель MTTR рассчитывается на основе SLO. Инженер по SRE влияет на него за счёт автоматизации. Например, в SLO прописан аптайм 99,99% на квартал, значит, у команды есть 13 минут даунтайма на 3 месяца. В таком случае время восстановления никак не может быть больше 13 минут, иначе за один инцидент весь «бюджет» на квартал будет исчерпан, SLO нарушено.

13 минут на реакцию — это очень мало для человека, поэтому здесь нужна автоматизация. Что человек сделает за 7-8 минут, с тем скрипт справится за несколько секунд. При автоматизации процессов MTTR очень часто достигает секунд, иногда миллисекунд.

Бюджет на ошибки

Как мы выяснили, пытаться достичь 100% стабильности не самая лучшая идея, потому что это дорого, технически сложно, а часто и бесполезно — скорее всего, пользователь не оценит старания из-за проблем в «соседних» системах. 

Поэтому Лёха предложил ввести еще одно понятие — бюджет ошибок. Это степень риска, которая допустима для данного сервиса, и ее можно прописать в SLO. 

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

Если бюджет на ошибки содержит 43 минуты даунтайма в месяц, и 40 минут из них сервис уже лежал, то очевидно: чтобы оставаться в рамках SLO, надо сократить риски. Как вариант, остановить выпуск фич и сосредоточиться на баг-фиксах.

Если бюджет на ошибки не исчерпан, то у команды остаётся пространство для экспериментов. 

Чтобы не выйти за рамки, Error budget делят на несколько частей в зависимости от задач. Каждая команда должна оставаться в пределах своего бюджета на ошибки.

Если это все будет внедрено, можно будет получить объективную картину, насколько стабильно работает наш сервис. Но остается одна серая зона: что делать, если бюджет на ошибки был исчерпан. 

Лёха посчитал, что очень важно договориться об этом заранее и оформить в виде документа — Error budget policy. Для примера он решил зафиксировать, что при исчерпании бюджета на ошибки останавливается вся разработка бизнес-функционала и вся команда работает над повышением стабильности. Лёха уверен: этот документ позволит избежать конфликтных ситуаций в и без того напряженной ситуации.

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

Глава 3. Post mortem 

Придя в понедельник в офис, первым делом Лёха открыл результаты расследования инцидента. Увиденное не радовало. Небольшая цитата:

«В период с 14-00 до 18-00 наблюдались проблемы с сервисом “Русь”. Они были связаны с тем, что сервис “Плутон”, от которого зависит наш сервис, переезжал в другой ДЦ и были потери пакетов. Написали служебку на запрет проведения работ в рабочее время для команды разработки и эксплуатации сервиса “Плутон!”»

Лёха грустно вздохнул: от такого расследования проку мало, и принялся писать свой отчет для Ивана Эрнестовича.

«Иван Эрнестович, наши отчеты об инцидентах, как и система мониторинга, деструктивны. Я подготовил собственный отчет, предлагаю данный вид документа сделать стандартным и назвать его, допустим, post-mortem. Цель этого документа не найти виноватых, а понять, в каких процессах есть проблемы и как можно их улучшить!»

Что и когда произошло

16.10. 2015 19.45 поступила жалоба от Генерального директора о недоступности сервиса Русь, примерно в 16 часов.

16.10. 2015 19.55 Инженер по эксплуатации Анатолий по данным системы мониторинга зафиксировал 1000 неудачных запросов в период с 14 до 17 часов. В момент поступления жалобы инцидент уже был разрешен. 

Причины и факторы

Нетехническая причина:

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

Техническая причина:

Отсутствие механизма повтора запросов у сервиса «Русь».

Обнаружение

Жалоба генерального директора.

Решение

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

Что прошло хорошо

В системе мониторинга присутствовали все необходимые графики.

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

Что можно улучшить

Разработать единую библиотеку, которая реализует функционал повтора запросов в случае кратковременной недоступности внешних сервисов. Данное решение было опробовано в рамках сервиса «Русь» и показало хорошие результаты.

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

Внедрить метрики на основе соотношения успешных и неуспешных запросов.

Где нам повезло

Количество неуспешных запросов было 1.5%, и большинство пользователей не заметили проблему.

Задачи

RUS-347 — доработка системы мониторинга. Добавление метрик соотношения неуспешных запросов к общему числу запросов.

RUS-354 — разработка библиотеки для реализации механизма повтора неуспешных запросов.

Лёха сложил два документа в одно письмо и отправил их курьером Ивану Эрнестовичу, так как тот больше любил бумажные письма.

Прошло несколько недель, наш инженер Леха уже отчаялся получить хоть какую-то обратную связь, и уже даже почти перестал расстраиваться из-за зря потраченного времени. И тут раздается звонок от Ивана Эрнестовича:

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

P. S. история может показаться утрированной, таковой она и является. Примерно такой путь прошли компании, которые придумали SRE. 

Так чем же будет заниматься инженер по SRE Лёха

1. Формировать целевые показатели надёжности системы и поддерживать их.

2. Проверять и оптимизировать код, опираясь на знания о надёжности системы.

3. Анализировать возникающие ошибки. Делать выводы, писать скрипты автоматизации для разрешения проблем.

И это только малая часть обязанностей SRE-инженера. Если вам интересны подробности, то прочтите обзорную статью по SRE от Слёрма (выдержки из неё вошли в этот текст). В конце обзорной статьи вы найдёте ещё массу полезных ссылок.

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

Узнать подробности и записаться

Автор статьи: Владимир Гурьянов — архитектор решений Southbridge, Certified Kubernetes Administrator.