SRE-инженер: кто такой и как им стать?

Кто такой SRE-инженер

Активный интерес к этой позиции появился в 2016 году, когда Google рассказала, кого у них в компании называют Site Reliability Engineer. По их словам, на этой позиции специалисты постоянно сталкиваются с вопросами окружающих о том, чем они занимаются.

Суть в том, что в разработке большую часть времени все фокусируются на создании программных систем. О том, что происходит после создания программы — говорят мало. Хотя именно на этот период приходится 40-90% усилий и затрат. Отсюда появляется потребность в дисциплине, которая рассматривает весь жизненный цикл программных объектов: от создания до развертывания и эксплуатации, доработки и до мирного вывода из эксплуатации. Эту дисциплину компания и назвала проектированием надёжности сайта.

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

Направления работы SRE

1. Проектирование, создание и обслуживание инфраструктуры 

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

Также SRE может оптимизировать расходы на инфраструктуру. Реже такой специалист отвечает ещё и за соответствие инфраструктуры требованиям, таким как GDPR и SOC2. 

Чаще всего работать предстоит не с частным облаком, а с публичным: AWS или Google Cloud. Для управления и описания инфраструктуры сейчас многие выбирают подход IaC — инфраструктура как код. Например, в Pinterest, Oracle и Reddit. 

2. Поддержание надёжности производственных систем

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

* SLO это цель уровня обслуживания, то есть те обещания, которые вы даёте клиенту по конкретным показателям. В таких соглашениях прописаны ожидания клиентов, что даёт чёткое понимание командам разработчиков и DevOps, чего они должны достичь и на какие критерии ориентироваться.

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

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

3. Мониторинг и алерты

Определив SLO, нужно следить за тем, чтобы они соблюдались. Это делается с помощью мониторинга и SLI. 

Мониторинг может охватывать пики использования процессора и памяти, аптайм сервиса, его производительность. Для этого можно взять такие инструменты, как Prometheus и Grafana, или популярные SaaS, вроде Datadog и Sentry.

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

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

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

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

5. Новые инструменты и автоматизация 

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

Как обстоят дела с SRE в Украине

В Украине эта область пока не сильно насыщенна предложениями. Но SRE нужны в таких компаниях как Intellias, Infopulse и Raiffeisen Bank

Чтобы стать SRE-инженером, нужен опыт:

  • В администрировании и настройке Linux. Это основа, без нее никак.
  • Глубокое знание и опыт с публичными облачными платформами. Чаще речь идет о Microsoft Azure или AWS.
  • С технологиями предоставления инфраструктуры — Terraform. 
  • Контейнерными технологиями и оркестровкой — Docker, Kubernetes.
  • Использования инструментов IaC и инструментов управления конфигурацией, например, Ansible и Puppet.
  • В мониторинге, например, Prometheus.

Дальше есть несколько вариантов: 

  1. Если вы, читая эти пункты, в голове проговаривали: “ага, это есть, и это есть…”, то можете стать SRE-инженером уже сейчас. 
  2. Если вам интересно развиваться в этом направлении, но пока в чем-то не дотягиваете — мы поможем приблизиться к первому варианту. У нас вы можете подобрать курс по любой теме выше.

Добавить комментарий

Спасибо, что поделились