Sre что это такое

Обязанности SRE-инженера в зарубежных вакансиях

Введение

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

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

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

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

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

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

Деплой и обслуживание инфраструктуры (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». Учебный центр Слёрм работу не обещает, но спикеры могут кое-чему научить.

Источник

Think SRE: смотрим на проекты глазами SRE-инженера

В отзывах о Слёрме Kubernetes звучала фраза: «Kubernetes оказался проще, чем я думал». Сейчас уже не звучит, мифа о сложности k8s больше нет. Он перешел в разряд инструментов easy to learn, hard to master.

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

Как всегда на старте, в уравнении много неизвестных. И как всегда на старте, самое интересное достанется первым.

3-5 февраля мы проводим в Москве Слёрм SRE. Билет на трехдневный интенсив стоит 60 тысяч. Что же участник получит за свои деньги?

Когда я рассказываю друзьям и коллегам про SRE, я встречаю здоровый скептицизм:

Эти вопросы я хочу разобрать.

Пора узнать, что такое SRE

На уровне лозунгов: SRE — это одна из имплементаций DevOps. Она появилась 10+ лет назад в Google, но только недавно стала проникать на «обычный» рынок, в первую очередь благодаря книге Site Reliability Engeneering, выпущенной Google в 2016 году.

О связи SRE и DevOps хорошо рассказано в этом видео:

Плохо то, что лозунги — ни о чём. Ну DevOps, ну имплементация, очередное «за всё хорошее против всего плохого».

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

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

Внедрить SRE проще, чем кажется

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

То есть дадим пошаговую инструкцию, которую можно внедрить у себя по возвращении с интенсива.

Вру. По сути мы дадим не инструкцию, а образец, с которого можно срисовать кучу идей и решений.

В цену входит образец для внедрения.

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

Хорошо бы на Слёрм прийти во главе с СТО. И СЕО тоже полезно, и об этом раздел…

… как убедить топ-менеджмент, что SRE полезен и нужен.

Обычно между СЕО (топ-менеджментом), СТО (IT-менеджментом), разработчиками и эксплуатацией есть конфликт задач.

Я намеренно не говорю «конфликт интересов», это именно конфликт задач.

СЕО нужны финансовые показатели. СТО — понятная, управляемая и по возможности комфортная ситуация. То есть понятные таски с понятным бизнес-велью, соблюдение сроков, нормальный стек, больше фич и меньше факапов. Разработчикам нужно выкатывать больше фич, а эксплуатации — обеспечить доступность (что явно конфликтует с «больше фич»).

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

Более того, SRE, будучи основан на метриках, позволяет переводить финансовые показатели в целевые показатели различных метрик, а их в свою очередь — в задачи DevOps-команд.

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

Есть проект DORA, DevOps Research & Assessments, он выпускает ежегодные исследования по ценности для бизнеса и ROI DevOps и его подкласса SRE. Мы сейчас переводим актуальный отчет на русский язык. Там есть оценочные формулы, которые с известной степенью точности можно применить к вашей компании.

Резюме: SRE дает бизнесу возможность управлять финансовыми показателями, устанавливая целевые показатели метрик, а DevOps-команда, глядя на текущие значения метрик, однозначно понимает, чем сейчас нужно заниматься с максимальной пользой для финансовых показателей. Какой СЕО откажется от такого инструмента?

Получить ресурсы на внедрение SRE вполне реально.

В цену курса входит набор доводов в пользу перехода на SRE и DevOps.

И даже в маленьких компаниях есть место SRE.

SRE делится на инструменты, культуру и организационную структуру.

Часть инструментов, например, Service Mesh, нужны для больших и сложных проектов. Но те же retry, backoff, failure injection, graceful degradation можно внедрять и в малых проектах, и дают они громадную отдачу.

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

А вот организационная структура в маленьких компаниях, наверно, не нужна и даже вредна. Когда все сотрудники — универсалы, не надо принудительно выделять SRE-команды.

Все, что мы описываем, уже работает

Эдуард проводит вебинар «SRE — хайп или будущее?» 12 декабря в 11:00.

О программе

Что касается программы. Я уже получаю фидбек экспертов, что программа «не бьётся»: она слишком широкая и местами нелогичная. Это действительно так.

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

Но уже в текущем виде программа ясно показывает направление, в котором мы работаем.

Тема №1: Основные принципы и методы SRE

Тема №2: Дизайн распределенных систем

Тема №3: Как принимают проект SRE

Тема №4: Проектирование и запуск распределенной системы

Тема №5: Monitoring, Observability and Alerting

Тема №6: Практика тестирования надежности систем

Тема №7: Практика incident response

Тема №8: Практика управления нагрузкой

Тема №9: Реагирование на инциденты

Тема №10: Диагностика и решение проблем

Тема №11: Тестирование надежности систем

Тема №12: Самостоятельная работа и ревью

Стоит ли все вышеперечисленное своих денег?

PS. При чем тут хаб Kubernetes

Вся практика выполняется в Kubernetes. Тем, кто владеет Kubernetes, прямая дорога в SRE-инженеры. Тем, кто не владеет — на наши курсы по Kubernetes.

Источник

SRE-инженер и системный администратор: в чем разница и кто нужен вашей компании

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

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

Кто такой системный администратор, что он делает и за что отвечает

Если смотреть глобально, то этот специалист следит за инфраструктурой, чтобы она работала стабильно и быстро. Если конкретнее, то системный администратор:

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

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

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

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

Кто такой SRE-инженер и чем он отличается от системного администратора

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

Можно выделить 4 ключевых направления, отличающих SRE-инженера от системного администратора.

SRE-инженер — это программист с навыками администрирования. Однако он пишет код не для реализации бизнес-логики, а для повышения стабильности и производительности системы. Написание кода не основная задача SRE-инженера, а один из способов достижения целей.

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

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

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

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

Также SRE-инженер может еще на старте разработки определить критерии, которые должны выполнить программисты. Например, приложение должно писать логи в определенное место или интегрироваться с общей системой мониторинга. Без выполнения этих требований SRE-инженер может не принять приложение на поддержку.

Он оценивает стабильность системы не по своим ощущениям, а по конкретным показателям. Есть две основные метрики, которые используют внутри команд:

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

Традиционные администраторы уходят в прошлое, а на замену приходят SRE-инженеры?

Возможно, что да. Это не дань моде, а естественное развитие технологий и процессов разработки:

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

Кто нужен компании: системный администратор или SRE-инженер

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

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

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

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

Источник

«Цель SRE — надёжная система». Обзор основных метрик SRE

Site Reliability Engineering (SRE) — это одна из форм реализации DevOps. SRE-подход возник в Google и стал популярен в среде продуктовых IT-компаний после выхода одноимённой книги в 2016 году.

В статье опишем, как SRE-подход соотносится с DevOps, какие задачи решает инженер по SRE и о каких показателях заботится.

От DevOps к SRE

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

Цели команд противоречат друг другу. Чтобы разрешить эти противоречия, была создана методология DevOps. Она предполагает уменьшение разрозненности, принятие ошибок, опору на автоматизацию и другие принципы.

Проблема в том, что долгое время не было чёткого понимания, как воплощать принципы DevOps на практике. Редкая конференция по этой методологии обходилась без доклада «Что такое DevOps?». Все соглашались с заложенными идеями, но мало кто понимал, как их реализовать.

Ситуация изменилась в 2016 году, когда Google выпустила книгу «Site Reliability Engineering». В этой книге описывалась конкретная реализация DevOps. С неё и началось распространение SRE-подхода, который сейчас применяется во многих международных IT-компаниях.

DevOps — это философия. SRE — реализация этой философии. Если DevOps — это интерфейс в языке программирования, то SRE — конкретный класс, который реализует DevOps.

Цели и задачи SRE-инженера

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

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

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

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

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

В задачи инженера по SRE входит ревью кода. Нужно, чтобы на каждый деплой SRE сказал: «OK, это не повлияет на надёжность, а если повлияет, то в допустимых пределах». Он следит, чтобы сложность, которая влияет на надёжность работы системы, была необходимой.

Хороший SRE блокирует любой коммит, деплой или пул-реквест, который повышает сложность системы без необходимости. В крайнем случае SRE может наложить вето на изменение кода (и тут неизбежны конфликты, если действовать неправильно).

Во время ревью SRE взаимодействует с оунерами изменений, от продакт-менеджеров до специалистов по безопасности.

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

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

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

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

Показатели доступности вырабатываются вместе с продакт-оунером и закрепляются в соглашении о целевом уровне обслуживания — Service-Level Objective (SLO). Оно становится гарантом, что в будущем разногласий не возникнет.

Специалисты по SRE рекомендуют указывать настолько низкий показатель доступности, насколько это возможно. «Чем надёжнее система, тем дороже она стоит. Поэтому определите самый низкий уровень надёжности, который может сойти вам с рук, и укажите его в качестве SLO», сказано в рекомендациях Google. Сойти с рук — значит, что пользователи не заметят разницы или заметят, но это не повлияет на их удовлетворенность сервисом.

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

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

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

Почему никто не стремится к 100% доступности

SRE исходит из предположения, что ошибки и сбои неизбежны. Более того, на них рассчитывают.

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

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

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

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

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

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

Для работы с надёжностью, ошибками и ожиданиями в SRE применяют ещё два показателя: MTBF и MTTR.

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

Показатель MTBF зависит от качества кода. Инженер по SRE влияет на него через ревью и возможность сказать «Нет!». Здесь важно понимание команды, что когда SRE блокирует какой-то коммит, он делает это не из вредности, а потому что иначе страдать будут все.

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

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

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

В идеале инженер по SRE должен полностью автоматизировать свою работу, потому что это напрямую влияет на MTTR, на SLO всего сервиса и, как следствие, на прибыль бизнеса.

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

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

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

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

Поэтому команды всегда принимают некоторую степень риска и прописывают её в SLO. На основе SLO рассчитывается бюджет на ошибки (Error budget).

Бюджет на ошибки помогает разработчикам договариваться с SRE.

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

Если бюджет на ошибки не исчерпан, то у команды остаётся пространство для экспериментов. В рамках SRE подхода Error budget можно тратить буквально на всё:

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

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

Эксперименты в продакшене — это важная часть SRE в больших командах. С подачи команды Netflix её называют Chaos Engineering.

В Netflix выпустили несколько утилит для Chaos Engineering: Chaos Monkey подключается к CI/CD пайплайну и роняет случайный сервер в продакшене; Chaos Gorilla полностью выключает одну из зон доступности в AWS. Звучит дико, но в рамках SRE считается, что упавший сервер — это само по себе не плохо, это ожидаемо. И если это входит в бюджет на ошибки, то не вредит бизнесу.

Chaos Engineering помогает:

Post mortem вместо поиска виноватых

В SRE придерживаются культуры blameless postmortem, когда при возникновении ошибок не ищут виноватых, а разбирают причины и улучшают процессы.

Предположим, даунтайм в квартал был не 13 минут, а 15. Кто может быть виноват? SRE, потому что допустил плохой коммит или деплой; администратор дата-центра, потому что провел внеплановое обслуживание; технический директор, который подписал договор с ДЦ и не обратил внимания, что его SLA не поддерживает нужный даунтайм. Все понемногу виноваты, значит, нет смысла возлагать вину на кого-то одного. В таком случае организуют постмортемы и правят процессы.

Мониторинг и прозрачность

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

В стандартном случае есть три уровня событий:

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

С мониторингом связан критерий прозрачности (Observability). Это метрика, которая оценивает, как быстро вы можете определить, что именно пошло не так и каким было состояние системы в этот момент.

С точки зрения кода: в какой функции или сервисе произошла ошибка, каким было состояние внутренних переменных, конфигурации. С точки зрения инфраструктуры: в какой зоне доступности произошел сбой, а если у вас стоит какой-нибудь Kubernetes, то в каком поде, каким было его состояние при этом.

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

SRE для небольших компаний и компаний без разработки

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

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

Внедрять принципы SRE можно с малого: определить SLO, SLI, SLA и настроить мониторинг. Если компания не занимается ПО, то это будут внутренние SLA и внутренние SLO. Обсуждение этих соглашений приводит к интересным открытиям. Нередко выясняется, что компания тратит на инфраструктуру или организацию идеальных процессов гораздо больше времени и сил, чем надо.

Кроме того, для любой компании полезно принять, что ошибки — это нормально, и начать работать с ними. Определить Error budget, стараться тратить его на развитие, а возникающие проблемы разбирать и по результатам разбора внедрять автоматизацию.

Что почитать

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

Где поучиться

Одно дело читать о новых практиках, а другое дело — внедрять их. Если вы хотите глубоко погрузиться в тему, приходите на онлайн-интенсив по SRE от Слёрма. Он пройдет 11–13 декабря 2020.

Научим формулировать показатели SLO, SLI, SLA, разрабатывать архитектуру и инфраструктуру, которая их обеспечит, настраивать мониторинг и алёртинг.

На практическом примере рассмотрим внутренние и внешние факторы ухудшения SLO: ошибки разработчиков, отказы инфраструктуры, наплыв посетителей, DoS-атаки. Разберёмся в устойчивости, Error budget, практике тестирования, управлении прерываниями и операционной нагрузкой.

Источник