Продакт оунер курса Слёрм «SRE: внедряем DevOps от Google», Татьяна Гребенюкова собирает интересные кейсы внедрения SRE в российских компаниях. Часть историй мы используем для развития курса, некоторыми кейсами рады поделиться со всеми.
Сергей Бухаров, SRE из Dodo Engineering, рассказал историю внедрения SRE в компании, какие практики из книжек оказались излишни и из чего состоят будни SRE-команды.
Dodo Engineering
Dodo Engineering — IT-подразделение Dodo Brands, которое создаёт и развивает собственную технологическую платформу Dodo IS, новые сервисы, сайты и мобильные приложения для ресторанных бизнесов: Додо Пиццы, Дринкита, Донера 42. Внутри системы есть трекинг, биллинг, аналитика. Всё работает на двадцати с лишним серверах. Больше 30 новых и отпиленных от монолита сервисов уже переехали в Kubernetes, переезд продолжается.
Всего в IT Dodo 200 человек, из которых 70 — С#-разработчики, 8 человек занимаются инфраструктурой — это команда SRE. В команде ребята разнопрофильные: есть люди с одинаковым опытом в разработке и администрировании, есть несколько человек с сильным опытом бизнес-разработки и с навыками администрирования.
Разработчики в продуктовых командах сами отвечают за свои сервисы: занимаются их отладкой, поддержкой, мониторингом, автоматизируют рутину, пишут пайплайны, расследуют инциденты и делают постмортемы.
Про путь к SRE
Я начинал карьеру как .NET-разработчик. Четыре года назад, когда пришёл в Dodo, опыта у меня было не очень много. Так само собой получилось, что я попал в команду инфраструктуры. Программировать я умел, а вот разбираться в администрировании пришлось по ходу дела. В то время никакого SRE ещё не было. В команде было всего три человека, и изначально мы много занимались тушением пожаров. Но бизнес стремительно рос, нужно было быстро поднимать под него инфраструктуру, решать текущие проблемы — мы не успевали, страдало качество. Через какое-то время нас стало шестеро, появился человек, который захотел построить то самое SRE, о котором он читал в книжках, но на практике ещё с ним не сталкивался.
Мы запустили проект, который назвали «Онбординг»: хотели взять опытных разработчиков и превратить их в SRE, нарастить бороду навыки вокруг инфраструктуры. Полгода занимались с ними инфраструктурными задачами, делали Infrastructure as Code, готовились к дежурству. В проект вписалось пять разработчиков — четверо остались в команде (кстати, среди них был Павел Притчин, который в прошлом году стал CTO). После онбординга один человек решил, что SRE — не его путь, и вернулся в разработку.
В команде изначально не было чёткого разделения по специализации. Все компетенции сложились естественным образом: кто лучше разбирается в Kubernetes, Rabbit или мониторинге — тот тем и занимается.
Построить SRE сразу и легко не получилось, было много проблем, а вот научить разработчиков работать с инфраструктурой и пополнить полк дежурных смогли довольно быстро.
Сейчас у нас есть обучение в формате воркшопов — они в текстовом виде, разработчики проходят всё самостоятельно. Когда мы приводили в порядок систему мониторинга, у нас появился воркшоп на тему «Как работать с нашим мониторингом, как он устроен, и что это такое». Такие же воркшопы есть и по другим темам, например, воркшоп на тему «Как считается SLO. Что это такое и для чего нужно». Недавно появился инструмент для накатки миграции — подготовили воркшоп, как им пользоваться.
Мы начали внедрять подход SRE за пределами команды: сделали чат-бота, который умел считать SLO определённых сервисов и рассылать информацию о состоянии разработчикам – это был первый шаг. В это время команда SRE уже самостоятельно собирала метрики. Ходили к разработчикам и говорили: «Тут у вас что-то всё просело, давайте посмотрим, разберёмся». Какое-то время мы жили с этим, в каких-то командах метрики прижились и буквально стали параметром того, стоит ли сейчас вкладывать в надёжность или не стоит, можно заниматься бизнесовой разработкой. Где-то они оказались не очень нужны, но это нормально. Ещё важным шагом стал переход на алерты, которые построены на burn rate.
SRE на уровне компании – это эволюционный путь, и мы ещё не прошли его до конца. Научить всех и сразу понимать и применять SRE — изначально неправильный подход. Например, нет необходимости внедрять полноценную историю с SLO в Дринкит и Донер 42 — на их масштабах это просто не нужно.
Будни SRE в Dodo
Дежурства
Дежурство — это часть работы SRE, нахождение on-call. Есть расписание, в течение недели дежурят два SRE. Один дежурный — основной дневной, работает с 9 утра до 18 вечера, другой его подстраховывает и дежурит вечером, с 18 до 9. В течение рабочего дня им поступают алерты, если с системой что-то идёт не так. Задача дежурного — обрабатывать алерты, поднимать систему, собирать для этого всех необходимых людей, чтобы решать инциденты. Если первый дежурный не отвечает на алерт, то алерт приходит второму дежурному.
Помимо алертов есть запросы от разработчиков — как правило, это рутина, от которой пока не ушли: выдать доступ, помочь разобраться с проблемой на dev-стенде. У нас есть Slack-бот, которым пользуются разработчики, это выглядит как обращение в тех. поддержку какого-нибудь внешнего сервиса. Человек описывает проблему: указывает, с каким сервисом она возникла, насколько критичная и в чём заключается. Формируется тикет на доске и дежурный с ним разбирается.
Мы считаем метрики, сколько всего обращений было за неделю, сколько времени потратили на их решение, с какими сервисами работали чаще всего. На основе этого принимаем решения, нужно ли автоматизировать работу с ними и сократить рутину.
Мы не делаем того, что обычно делают команды DevOps-инженеров: не делаем работу за разработчиков. DevOps как подход в Dodo есть, а вот DevOps-инженеров в чистом виде, скорее, нет. Разработчики часто сами поддерживают пайплайны и сервисы, а мы создаём для этого инфраструктурную платформу — технически и SRE — процессно. Можно сказать, что у нас смешанный подход: мы поддерживаем инфраструктуру как DevOps-инженеры и выполняем SRE-функции: обеспечиваем надёжность сервисов, дежурим, автоматизируем какие-то процессы и так далее. Такой переходный вариант, когда многое у нас уже есть, но и многого не хватает. Планируем продолжать обрастать SRE-практиками, делать нашу инфраструктуру лучше.
Ещё у нас в течение рабочего дня по некоторым особенно критичным сервисам разработчики дежурят самостоятельно. У них тоже есть пейджер, приходят алерты. И зачастую эти инциденты до SRE не доходят. Например, ребята что-то разрабатывали, выкатили релиз — всё сломалось, пришёл алерт, они сами релиз откатили. В том числе так происходит благодаря тому, что мы автоматизировали инцидент-менеджмент (об этом — дальше), что позволило масштабировать процесс. Используем стандартный набор — Prometheus, Grafana, PagerDuty. Ещё есть тулинг для автоматизации инцидент-менеджмента, который мы написали сами (вдохновлялись опенсорс-версией Response от Monzo), потому что на наших масштабах не всегда можно просто взять что-то готовое.
Данные и дашборды
Всё, за чем мы смотрим, делится на две части. Первая – это то, что происходит на стороне пользователей. Например, они не могут оформить заказ; деньги списались, а заказ по каким-то причинам не создался и тому подобное. Вторая часть – это то, что происходит внутри пиццерий, все стадии прохождения заказа:. приготовили, упаковали, но из-за каких-то проблем не могут отправить курьера. Обычно это выражается в пятисотках и обращениях на первую линию техподдержки, но алерт срабатывает обычно гораздо быстрее, чем запрос приходит с первой линии.
Для отображения графиков мы используем Grafana: смотрим текущую нагрузку на систему, какой у нас RPS, сколько процентов процессора используется у машин, что происходит с базами и так далее.
Самая важная для нас метрика — количество заказов в минуту. Если этот график упал – всё. Такое бывает очень редко и значит, что проблема масштабная. Источников заказов у нас несколько: мобильное приложение, сайт, пиццерии, колл-центр. График показывает распределение по всем этим источникам. Если по всем видны какие-то просадки — инцидент максимально критичный.
Метрики и мониторинг
SLO у нас определены практически для всех сервисов, для некоторых существует два уровня: более строгий — внутренний и менее строгий — внешний. Ещё есть такое понятие, как сервис критического пути — это сервис, без которого клиент не получит свой заказ. Такие сервисы имеют SLO 99,99 (допускается 52,6 минуты простоя в год), а всё остальное по нисходящей.Мониторинг стараемся делать по четырём «золотым сигналам»: latency, traffic, errors, saturation. Фокусируемся на клиентских ошибках: задержки в обработке заказов, пятисотые ошибки. На их основе строим алерты, пытаемся определять импакт во время инцидентов. Тут есть куда расти.
Пытаемся выстроить процесс вокруг бюджета ошибок, чтобы несоответствие сервиса SLO действительно приводило к конкретным действиям. Мы считаем SLI по error rate всех наших сервисов ежедневно и анализируем его каждую неделю. Наблюдает за ним частично команда SRE, частично разработчики-оунеры сервисов. Если SLI какого-то сервиса не соответствует SLO в течение 2-3 недель, то в каждой конкретной ситуации разбираемся, требует ли это каких-то действий. Чётко выстроенного процесса ещё нет: пока мы только определили уровни SLO, считаем SLI и при просадках принимаем какие-то меры.
Т.е. выглядит это примерно так: допустим, сегодня понедельник, смотрим на девятки по нашим сервисам. Видим, что где-то есть несоответствие. Идём к оунерам этого сервиса, выясняем, занимаются ли они. И зачастую на этом всё заканчивается, потому что разработчики уже в курсе. Если проблемы наблюдаются в течение нескольких недель, может быть, даже не по одному сервису, мы вправе организовать субботник. Это история о том, что бюджет ошибок закончился, и пора вкладываться в надёжность. У команды SRE есть право приостановить на какое-то время бизнесовую разработку, чтобы заняться надёжностью.
Инцидент-менеджмент
Допустим, прилетает алерт. Что происходит? Насколько алерт критичный? Страдает пользователь? Страдает пиццерия? Чтобы ответить на эти вопросы, дежурный SRE оценивает его при помощи мониторинга, своих собственных знаний и опыта решения предыдущих инцидентов.
Если алерт имеет влияние на систему, информация об инциденте публикуется в общий канал: описание, ссылка на встречу. Создаётся отдельный канал инцидента с разработчиками, продактами, первой линией техподдержки и всеми, кто может этот инцидент решить. Записи из этого канала потом попадают в постмортем.
У нас классический процесс инцидент-менеджмента, который описан в SRE Book или Workbook. Несколько ролей на инциденте:
инцидент-коммандер. Его задача — координация, т.е. собрать нужных людей на встречу, привлечь команду, ответственную за сервис, сделать всё, чтобы выяснить причины и решить инцидент. Зачастую это дежурный, но если он не уверен в своих силах или компетенциях, то может эту роль кому-то передать;
скрайбер. Он записывает всё, что происходит на инциденте — все действия, которые мы предпринимаем для расследования, починки;
комьюнити-специалист. Это человек, который работает с внешними каналами коммуникации, держит в курсе партнёров и сотрудников пиццерии о том, что происходит и когда всё починится;
эксперты, которые занимаются непосредственно починкой.
Мы считаем длительность инцидента, длительность даунтайма. Обычно собрать людей на инцидент можно за 10-15 минут или меньше, а на полный разбор уйдёт час. Также считаем количество недополученных заказов, недополученную прибыль, если не принимали заказы в этот момент.
Среднее время инцидента — один час, но это для нас много. Зачастую инцидент длится меньше. Сказать, как часто бывают инциденты, сложно. Например, на прошлой неделе алертов было больше десяти, но не каждый алерт – это инцидент. Среди этих алертов не было ни одного инцидента, и это нормально.
Для SRE важна стрессоустойчивость. Когда что-то случается нужно не раздувать конфликт, а решать проблему. Не искать виноватых, а делать так, чтобы падение больше не повторилось. Можно услышать мнения, что это больше лозунг и не получается работать без конфликтов. Но у нас проблем с этим не было. Мы считаем, что все люди ответственные, стараются делать свою работу качественно — другие к нам просто не проходят либо долго не задерживаются.
Постмортем
Завершение инцидента частично автоматизировали: в публичном канале, где мы писали про инцидент, есть кнопка закрытия. По ней открывается форма, инцидент-командер заполняет impact, который случился, предположительные причины инцидента. Генерируется драфт постмортема из того, что записал скрайбер. Потом дежурный дописывает постмортем, привлекает всех, кого нужно, для генерации решений по данному постмортему. Постмортем ревьювится, решения постепенно исполняются.
Практики, которые не подошли
Главное, о чём нужно помнить, если вы хотите построить у себя SRE: не превращайте его в культ. Это набор практик, и не все они могут подходить именно вам именно сейчас. Что-то не подходит в чистом виде, требует изменений. Я встречал где-то в статьях от Google подобное: «SRE, SLO — это всё хорошо. Но помните, что вы не Google, и возможно, как есть вам не подойдёт».
Не все практики подошли и нам.
Не взлетел уровень критичности инцидентов, когда нужно оценить, насколько инцидент А критичнее инцидента Б. Мы попробовали ввести уровень критичности инцидентов буквально так же, как это расписано в книге, и поняли, что это нам не нужно. Потому, что не понятно, как оценивать, и для чего оценивать.
SLO — тоже полезная практика, но не нужно внедрять её повсеместно. У нас была ситуация, когда выбрали слишком высокий уровень надёжности для сервиса, которому это не нужно. И получалось так, что сервис в течение долгого времени заданному SLO не соответствует, но проблем при этом нет абсолютно никаких.
Ещё в идеальном мире SRE есть ревью кода. У нас оно реализовано частично через SRE-кураторов. Они течение какого-то времени помогают команде в разработке новых сервисов, а потом проверяют на соответствие определённому набору нефункциональных требований: например, сервис должен отдавать такие-то метрики, в нём есть рекомендованные библиотеки, правильно ли записываются логи. SRE-куратор не ревьюит каждую фичу — команды занимаются этим самостоятельно.
Должен ли SRE быть разработчиком
Есть мнение, что SRE растут из разработчиков — они должны писать код и знать язык, на котором написано ПО, при необходимости что-то докодить, допушить в продакшен. В идеальном мире должно быть именно так. И мы стараемся двигаться в эту сторону. У нас есть ребята из разработки, которые могут поправить какой-то упавший код, но пока компетенций для этого мало.
В команде все программируют, но есть нюансы. Во-первых в инфраструктурной команде языки отличаются от тех, на которых пишут команды разработки. И второе — у нас есть монолит, и разбираться во всём монолите невозможно. Если в нём что-то упало, то гораздо проще и менее рискованно найти ответственную за эту часть монолита команду — она разберётся и починит самостоятельно гораздо быстрее. Так для бизнеса эффективнее. Но с микросервисами проще, поэтому и пилим.
Есть ещё нюанс: правка кода SRE — это о законченных сервисах, которые больше не разрабатываются. Быть в курсе нового кода, который продолжают писать десятки команд, невозможно. У нас всего пара сервисов в статусе завершённых, и для нашей компании эта SRE-практика не нужна.
Планы
Сейчас мы занимаемся активным внедрением бюджета ошибок, автоматизировали инцидент-менеджмент, работу по тикетам. С постмортемами тоже всё, в принципе, неплохо. Это базовые практики, которые подойдут большинству и с которых можно начать внедрять SRE.
Развитие дежурств
Планируем всё больше привлекать разработчиков к дежурствам и в формате 24/7, потому что чаще ломается код, а не инфраструктура. Дежурному инженеру приходится доставать разработчиков, и это превращается в лотерею: кто-то не дома, кто-то далеко от компьютера. И это достаточно большой стресс — быстро найти нужного человека. Несистемный подход. Это ещё не совсем SRE, это та самая надежда, что ты до кого-то дозвонишься и тебе помогут.
Вместо итогов
Для меня в работе SRE-команды особенно интересно чувство жизни. Мы часто сталкиваемся со «спецэффектами», о которых не думали, когда были в бизнесовой разработке. Нестабильная работа ресурсов в облаке, проблемы с сетью у магистральных провайдеров — всё это случается время от времени, и интересно учиться строить систему так, чтобы проблемы нас меньше касались.
Ещё мне кажется, что у разработчиков более узкая сфера деятельности и они копают больше глубину. То есть человек пишет всю жизнь на C#, на фронте использует React, работает с MySQL и PostgreSQL. А у нас сфера гораздо шире — нужно изучать много различных инструментов, технологий и заставить всё это между собой взаимодействовать. Для меня, пожалуй, это самая интересная часть.
