Введение

В 2016 году Google выпустила ту самую книгу о SRE (Site Reliability Engineering). Эта практика решала важную задачу компании — поддержание высокой надёжности сервисов Google. За годы практика широко распространилась среди разработчиков по всему миру. Теперь во многих стартапах и крупных корпорациях есть должность SRE-инженера.

Так менялся интерес работодателей к SRE-инженерам с течением времени.

Тренд поиска SRE-инженеров
Тренд поиска SRE-инженеров

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

Мы решили проанализировать 30 объявлений о вакансиях SRE-инженеров от следующих компаний: Google, Gitlab, Instacart, Oracle, Twitter, Slack, Coindesk, Fastly, Reddit, Datadog, Frame.io, Doordash, Coinbase, MongoDB, Patreon, Box, Away, Adyen, Pinterest, Figma, Apple, Twilio, Airbnb, Squarespace, Robinhood, Mastercard, Spotify, Peloton, Duolingo, Tiktok

Результаты аналитики

Мы выделили несколько основных обязанностей:

  • Деплой и обслуживание инфраструктуры (84% объявлений).

  • Определение и контроль SLO, SLI и бюджетов на ошибки (34% объявлений).

  • Настройка мониторинга и алертов (47% объявлений).

  • Дежурство, реагирование на инциденты, постмортемы (47% объявлений).

  • Создание инструментов и автоматизация (56% объявлений).

Комментарий Евгения Бутырина, технического редактора Слёрм

В вакансиях Российских компаний эти обязанности также присутствуют, в тех или иных формулировках. С упоминанием обязанностей в процентом соотношении всё не так прозрачно. Зачастую в вакансиях пишут где-нибудь в требованиях: уметь в мониторинг. А в обязанностях ни слова, но мы понимаем, что раз нужно знать, значит понадобится. Та же история с SLO и бюджетом на ошибки, будучи одними из основных практик, по умолчанию подразумевается, что это надо знать и уметь. А про дежурства может быть написано: обеспечивать работоспособность сервисов 24/7.

Деплой и обслуживание инфраструктуры

Одна из главных задач SRE-инженера — проектировать, создавать и обслуживать инфраструктуру, в которой работают продукты и сервисы компании. Это может быть частное облако, но все чаще публичное, например AWS или Google Cloud. Сейчас популярно писать инфраструктуру как код (IaC), используя синтаксис YAML и HCL (для продуктов Hashicorp, вроде Terraform).

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

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

Определение и контроль SLO, SLI и бюджетов на ошибки

Поддерживать надёжность производственных систем — важная обязанность SRE-инженера. Все-таки R в SRE означает reliability. Нужно понимать, как достичь корректной работы сервиса и соблюсти внутренние стандарты.

Для этого SRE-инженер определяет SLO и SLI. SLO — это показатели целевого уровня обслуживания для сервиса, а SLI — индикаторы, которые измеряют эти уровни. SLO можно определить вместе с коллегами на основе ожиданий клиентов и обязательств перед клиентами, сформулированных в виде SLA.

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

Комментарий Павла Селиванова, Архитектора VK Cloud Solutions, спикера Слёрм

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

Настройка мониторинга и алертов

Когда SLO определены, можно следить за их соблюдением с помощью SLI и мониторинга. Обычно мониторинг охватывает инфраструктуру (пики использования процессора и памяти), аптайм сервиса (веб-сайта или API), производительность (скорость загрузки страницы) и т. д. Можно использовать локальные инструменты, вроде Prometheus и Grafana, или популярные SaaS, например Datadog и Sentry.

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

Дежурство, реагирование на инциденты, постмортемы

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

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

Комментарий Павла Селиванова, Архитектора VK Cloud Solutions, спикера Слёрм

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

Создание инструментов и автоматизация

Один из принципов SRE — устранение ручного труда. Google SRE определяет тяжелый труд как выполняемые вручную, повторяющиеся и нетактические задачи, которые можно автоматизировать. Эти задачи отнимают время разработчиков и SRE и мешают другим важным проектам. Автоматизировать повторяющиеся задачи — одна из важных обязанностей SRE-инженера. Это может быть автоматическое реагирование на распространённые алерты, настройка процесса CI/CD, чтобы команда работала быстрее, или создание продуктов, с помощью которых разработчики могут сами выполнять рутинные запросы.

Другие обязанности

В некоторых компаниях SRE-инженеры могут выполнять и другие задачи:

  • Отладка проблем в продакшене. Может затрагивать все уровни стека.

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

  • Хаос-инжиниринг. Впервые применен Netflix, а сейчас внедряется и в других компаниях. Это метод, при котором мы стараемся сломать систему изощрёнными способами, чтобы проверить ее устойчивость.

Заключение

Как видите, SRE-инженер должен не просто обслуживать инфраструктуру или помогать с CI/CD. Поддержание нормальной работы сервисов затрагивает разные области эксплуатации и разработки программного обеспечения.


Евгений Бутырин

Над материалом работала команда курса «SRE: внедряем DevOps от Google». Учебный центр Слёрм работу не обещает, но спикеры могут кое-чему научить.

Комментарии (9)


  1. aleks_raiden
    24.11.2021 12:27

    А можете (отдельно, наверное) рассказать про платформы управления инцидентами - за ссылку в этой статье спасибо, но хотелось бы посмотреть сравнение еще других решений, и может что полностью открытое self-hosted есть?


    1. geniyoctober Автор
      25.11.2021 04:31

      Спасибо за интересный вопрос, спрошу у спикеров курса, а так сходу могу сказать, что есть Response от Monzo, инженеры из Dodo рассказывали, что допиливали этот опенсорс, а в Wargaming`е переписывали Jira.


  1. ppl2scripts
    24.11.2021 17:52

    стоит избегать зависимости от вендора — так дешевле и надёжнее

    Скорее это "преждевременная оптимизация". Кто-то прочитал в газете, без реального опыта.


  1. questor
    24.11.2021 20:55

    Ну вообще, если вы разработчик - то лучше идти SWE, а не SRE (иногда некоторые путают, да). И не раскрыта тема "нужно SRE ли фигачить литкод и как им вообще готовиться к собесам".


    1. geniyoctober Автор
      25.11.2021 04:33

      По собесам точно могу посоветовать посмотреть запись уже нашего недавнего вебинара, там в целом о работе SRE в разных компаниях и в том числе о собесах говорили немного: https://youtu.be/Cj9yKoF6hd0.


  1. whitehat
    24.11.2021 22:44

    Самая печаль - если нет инсайдера знакомого, вы никогда не узнаете чем на самом деле занимается команда SRE, пока не поработаете в компании. На собесе будут рассказывать сказки и спрашивать как красно-чёрные деревья переворачивать, а на деле - будете мышкой ec2 создавать потом


    1. stitrace
      25.11.2021 04:23

      Это лишь означает, что в команде нет SRE инженера.


    1. vitaly_il1
      25.11.2021 11:04

      будете мышкой ec2 создавать потом

      Со строгим запретом делать это другими способами? :-)


  1. usv_usv
    25.11.2021 04:23
    +1

    SRE — «Servers Reboot Engeneers» =)