Что вообще за SRE, что это значит?

SRE (Site Reliability Engineering) — это сфера обеспечения бесперебойной работы высоконагруженных сервисов. Соответственно, SRE-инженер — это специалист по надёжности.

Термин SRE придумали в Google, в этой компании появились первые разработчики, которые затачивают свою работу на безотказность и быстрое исправление ошибок. Это направление стало очень популярно, сегодня SRE-инженеры есть в любом мощном сервисе — и в Яндексе в том числе.

А что, до SRE безотказности сервисов не было?

Была — но её обеспечивали иначе. Представим большой и популярный онлайн-кинотеатр. Это сложный сервис, который должен показывать сериалы и фильмы 24/7 с минимальной задержкой.

Предположим, что в пятницу у сервиса два важных события: вечером выходит финальный эпизод сериала «Игры у стола» и тем же вечером разработчики апдейтят бэк. Тесты проходят, всё работает, «Игры» летят — разработчики уходят в бар отмечать долгожданный релиз. А в субботу утром десятки тысяч людей не могут нормально посмотреть сериал: вместо 20 мс сайт работает с задержкой 100500 мс.

При традиционном подходе к надёжности первыми о ситуации узнают сотрудники поддержки, ведь расстроенные зрители заполнят все чаты. Специалист поддержки не может восстановить работу сервиса — он эскалирует проблему, передав её в технический хелп. Там увидят, что случилась большая беда, и начнут вызванивать разработчиков. Не факт, что все они на связи в субботу, ведь у всех нас есть свои дела по выходным. В итоге через несколько часов соберётся консилиум программистов и будет решать, что делать: откатывать апдейт или попытаться пофиксить текущий билд. На восстановление нормальной работоспособности уйдут часы или даже дни — а такой простой очень дорого обходится бизнесу.

А что в такой ситуации сделает SRE-инженер?

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

В компаниях с командой из 10–15 человек можно обойтись без SRE: обычно разработчики дежурят по очереди. А вот большому высоконагруженному сервису, например банку, без такого специалиста не обойтись: в случае проблем счёт идёт на минуты.

У нас в Readymag небольшая команда разработчиков и отдельного SRE нет. Но есть дежурства, по неделе на каждого специалиста. Во время дежурства разработчик должен быть доступен всегда — даже в бар ходит с ноутбуком. Ну и конечно, на время дежурства приходится ограничивать активности, пойти на балет или уехать за город не всегда получается.
Анна Шишлякова, фулстек в Readymag

А как SRE узнает, что что-то случилось?

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

Но обычного письма или пуша для SRE-инженера мало. Алерт в его случае работает многоступенчато. Например, сперва разработчик получает уведомление через телеграм-бота. После этого он должен быстро отметить в мониторинговой админке, что увидел проблему. Если этого не сделать, мониторинг начнёт звонить SRE-специалисту по телефону, вызывая на бой с багами. Многоступенчатость важна, ведь сервис может упасть и ночью, а во сне можно случайно пропустить вызов или машинально отменить его, как будильник.

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

Получается, SRE-специалист — это такой сисадмин-девопс-программист?

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

Чтобы работать очень быстро, в SRE используют парадигму «инфраструктура как код». Инженеры могут управлять инфраструктурой и настраивать её через процедуры в коде — так они работают со всеми компонентами в одной среде и не отвлекаются на ручное «накликивание» настроек серверов.

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

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

В инфраструктуре мы стараемся придерживаться как общепринятых подходов к проектированию и эксплуатации сервисов, так и делать упор на важные для нас аспекты обеспечения надежности. У нас есть мониторинг, алертинг, дежурства, репликация, шардирование сервисов, плавные выкладки в production, тестовые и приемочные стенды. Где-то больше, где-то меньше, но в целом — достаточно для обеспечения бесперебойности работы инфраструктуры. Тут хочется обратить внимание на одну из проблем обеспечения надежности инфраструктуры — человеческий фактор. Пару лет назад коллега обнаружил замечательный пост в блоге. Наверняка каждый кто занимается эксплуатацией различных сервисов сталкивался со всеми описанными там проблемами в том или ином виде.

If you determine «human error» as the root cause, then you’re doing it wrong. И, действительно, это так. Надежные системы должны проектироваться и эксплуатироваться с оглядкой на то, что люди ошибаются и нельзя предугадать когда будет совершена ошибка которая приведет к даунтайму, поэтому лучше считать что люди ошибаются всегда. Считая так, при проектировании систем мы встраиваем на всех уровнях различные механизмы автоматической защиты от человеческих ошибок и валидации как входных данных так и результатов выполнения каких-либо изменений. В разработке инфраструктурных сервисов предпочитаем использовать языки со статической типизацией и для дополнительной защиты утилизировать возможности системы типов этих языков так, чтобы невозможно было выполнять противоречивые действия над сущностями в коде. Как результат такого подхода к проектированию и эксплуатации сервисов мы автоматически получаем высокий уровень автоматизации эксплуатации инфраструктурных сервисов и наши дежурные спокойно спят по ночам. Инциденты происходят, но у «автора» инцидента всегда есть инструмент для диагностики проблем и отката ломающих изменений без необходимости вмешательства дежурного от инфраструктурного сервиса.
Антон Суворов, руководитель группы эксплуатации внутреннего облака

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

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

Бюджет ошибки. SRE-команды считают так называемый бюджет ошибки — допустимый период, в течение которого сервис может работать ниже целевых уровней. С помощью бюджета можно измерять серьёзность инцидентов. Если, например, инцидент истратил 30% бюджета, его можно считать серьёзным. Это помогает SRE-инженерам не отвлекаться на минорные проблемы, которые регулярно возникают даже в самых оттестированных проектах.

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