site reliability engineering что это
SRE-инженер. Что нужно знать и уметь?
Экспириенс, задачи, нагрузка
Ингредиенты
Указания
SRE на пальцах
SRE ( Site Reliability Engineering ) — набор методов, показателей и предписывающих способов обеспечения надежности систем. Слово «site» в данном контексте читается как «система» или «платформа», а не веб-сайт в привычном нам представлении. SRE — обеспечение надежности всех уровней системы: от физических до логических, это значит, что SRE — это своеобразный конгломерат из разработчика (да, SRE должны уметь в код) и системного администратора со всеми вытекающими.
Именно SRE-инженер стоит в первых рядах, когда речь идёт об обеспечении аптайма highload-сервисов, стабилизации системы после краша и вносят соответствующие поправки в код. Поэтому они часто именуются как Software-инженеры (в совковых конторах это звучало бы как инженер-программист) или инженерами по надежности обслуживания
Вообще, SRE — это своеобразное ответвление, а точнее — своя реализация направления DevOps от Google. Идейным вдохновителем стал Бен Трейнор — текущий вице-президент Google по вопросам облачной обработки данных (где-то упоминается, как вице-президент по технологиям). Так же Google издала уже три книги, где описывает нюансы направления SRE, его практики и применение в недрах компании (Site Reliability Engineering: How Google Runs Production Systems — первая из них)
Зачем нужно это направление?
SRE решает проблемы. А проблемы могут быть, как со стороны разработчиков, так и со стороны инфраструктуры. Программисты пишут код, который работает. Это их работа. Но, зачастую, они не сильно тревожатся по поводу того, насколько он оптимизирован, на какой платформе он будет работать и выдержит ли сервер n-ое количество запросов. Проблемы инфрастуктуры их не касаются.
— «Парень, который пилит фиксы и лезет в лоад балансер. А убрать, кто ты без него?»
— «Девелопер, сисадмин, интегратор, инженер»
DevOps vs SRE
Эти две сферы не зря сравнивают между собой — они смежные, т.е. часто дублируют функции друг друга. Как мы уже писали выше SRE — это сочетание DevOps и разработки, т.е. умение писать код и погружаться в недры девелопмента тут сочетается с работой по серверной части: администрирование, масштабирование и нагрузку.
Скиллы и задачи SRE-инженера
Прокачаться до уровня Senior, т.е. на все 146% будет трудно. Мы уже писали, что профессия не из легких, к тому же сочетает в себе два весьма трудоёмких направления — эксплуатации и разработки.
Девелопмент
Да, SRE-инженер должен уметь писать код на одном из языков программирования, которые используются в стеке компании. Это может быть как C#, так и гугловский Golang, т.е. для позиции SRE нормальной практикой считается не просто написание скриптов (опять же может быть и питон, а может и bash), но и погружение в процессы разработки и постоянное взаимодействие с командой. Опционально может быть: составление брифов (техническое задание), участие в спринтах и копание в бэклоге
Разработка платформы на базе Kubernetes — тоже одна из частых задач в SRE. Kubernetes — это целая экосистема из сервисов и утилит для развёртывания, автоматизации и настройки контейнеризированных приложений и микросервисов (использующие облачные вычисления). Kubernetes дает вам фреймворк для гибкой работы распределенных систем. Он занимается масштабированием и обработкой ошибок в приложении, предоставляет шаблоны развертывания и многое другое. Kubernetes отлично балансирует нагрузку трафика между контейнерами, быстро развернуть или откатить любое количество контейнеров и работает с защищенными протоколами для защиты персональных данных
Так же предстоит работа с билдами в Drone CI. Пул-реквест ты будешь делать чаще, чем оставаться наедине со своей девушкой. Причем не понятно, где интимной близости будет больше. Билд проходит через стандартный конвейер задач и тебе, скорее всего, придётся составлять его пайплайн. Drone — система непрерывной интеграции, основанная на docker-контейнерах, которая отлично работает как с гитхабом, так и с менее известными репозиториями. Каждый шаг из пайплайна обрабатывается в отдельном docker-контейнере и запускаются с помощью drone agent. Drone server, в свою очередь, играет роль координатора
Системное администрирование & автоматизация
Траблшутинг & Инцидент менеджмент
Опыт работы в технической поддержке, конечно, пригодится — но тут совсем другой уровень. SRE-инженер обязан разбираться во всех системах мониторинга системы: логи, трейсинг, алертинг. При этом работа не ограничивается на регистрации инцидента — вам необходимо найти причину и найти решение проблемы этого тикета. Саппорт может подразумевать в себе и сменную работу — поэтому, если не имеешь возможность дежурить вечером/ночью, лучше сразу об этом сказать.
Kibana — специальный дашборд для построения графиков и диаграмм этих самых логов. Как правило, используется в стеке, т.н. ELK — Elasticsearch + Logstash + Kibana
Работа с базами данных & облачной инфраструктурой
Основа основ в SRE. Все мало-мальски топовые компании переводят свою инфраструктуру в облако — это не дань моде, а вполне закономерный тренд. Поэтому приготовьтесь к миграции базы данных из MySQL в Azure или AWS, настройке бэкапов, оптимизации запросов, написанию тулз, выставление лимитов, обкатывание баз на стенде, тестированию и развертывание всего этого дела в продуктивной среде.
Плюсом будет умение работы с Microsoft Azure на уровне разработчика : разбираться в Azure Data Explorer (служба для анализа большого объема потоковых данных в реальном из приложений и/или сервис в real-time), работать и автоматизировать систему управления идентификацией и доступом (AIM), использовать Azure REST API (доступ к ресурсам службы через протокол HTTP), управлять инфраструктурой через Azure CLI (интерфейс командной строки).
Что еще? Формирование политик RBAC. Role Based Access Control — управление доступом на основе ролей, альтернатива спискам ACL. Суть подхода заключается в создании ролей, повторяющих бизнес-роли в компании, и присваивание их пользователям. На основе этих ролей проверяется возможность выполнения пользователем того или иного действия.
Софт-скиллы
Без них в сегодняшней ИТ-компании никуда. Даже сугубо техническим специалистам придётся научиться работать в команде, уметь договариваться, балансировать не только нагрузку на сервер, но и свою стрессоустойчивость, прививать себе лидерские качества прокачивать тайм-менеджмент, следовать традициям blameless culture.
Что за Blameless Сulture?
Всё чаще многие хрюши многозначительно кивают в сторону blameless culture. «Безупречная культура», которая, как говорят, первой появилась на производственных линиях Тойоты, теперь становится мейнстримом в ИТ-компаниях. Основные её постулаты гласят:
Обязанности 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». Учебный центр Слёрм работу не обещает, но спикеры могут кое-чему научить.
После DevOps: как стать SRE и устроиться на работу в Google
SRE — это Site Reliability Engineer
В IT отрасли это инженер, который отвечает за надежность очень сложных сервисов. Появилась профессия в Google и придумали методологию именно там. Оно и понятно, Гугл – это сервис, который использует весь мир. Это огромные мощности и большая сложность.
14 декабря в работе гугла был сбой, весь мир был в недоумении. Вот в таких случаях и нужен SRE-инженер. Он не должен допустить подобных промахов.
Методологию DevOps российский IT-рынок освоил раньше и теперь ведутся жаркие споры об SRE vs DevOps. Кто-то говорит, что это одно и тоже, кто-то, что SRE это нечто, что логично продолжает DevOps. В России профессия только появилась. Крупные банки, которые содержат большие мощности, стали серьезно задумываться о таких ребятах.
В общем, Пока все спорят, мы решили пообщаться об SRE и DevOps, а также о работе в Гугл и Тинькофф.
Одного SRE я нашла в Tinkoff, до этого он работал в Google – у первоисточника, так сказать. Зовут его Дима Масленников. Google мы уделили отдельное внимание, так как есть стереотип, что работать там весело. Мы выяснили, что не всем.
В статье приведен краткий и творчески переработанный текст интервью. Если хочется подробностей или лень читать, смотрите полную версию на моем youtube-канале
Фаря:
– Как ты попал в Google?
Дмитрий Масленников:
– Они меня очень долго хантили. Писали мне в LinkedIn, просили мое резюме, а я всё забывал им его прислать…
– Почему их футболил? Это же, блин, Google!
– Не знаю, мне в России было хорошо.
– А чем ты занимался в этот момент?
– Был программистом, архитектором ПО. Занимался разработкой бэкенда.
А почему именно на тебя обратили внимание, как ты думаешь?
– Понятия не имею. У меня были всякие громкие слова вписаны в профиле, потому что я работал на всякие Еbay, Samsung. И видимо, обилие этих громких имен и технологий, с которыми я работал, и сыграли роль.
– Они тебя SRE обучали? Ведь в России такого не было и нет до сих пор.
– Да, и нигде в мире такого нет. Поэтому обучение проходит в Google примерно полгода.
– Вокруг SRE идут дикие дискуссии. Что это, является ли SRE противопоставлением DevOps, является ли оно его дополнением?
– Я когда работал в eBay, я хорошо прочувствовал, что было до DevOps. Есть разработка (программисты) и есть администраторы. И они друг друга никогда не видят. Ты передал код руководителю, и он где-то лежит. Он, в свою очередь, тоже кому-то там передал. И кто-то этот код как-то эксплуатирует. DevOps же сказал, что их надо посадить вместе.
– В какой момент здесь появляется SRE?
– SRE появляется, когда софт становится чрезмерно сложным и чрезмерно нагруженным. Во-первых, сам функционал растет очень сильно. И это, порой, незаметно. Ну что поменялось в Google-поиске за последний год или за последние 5 лет? А там релизы идут каждую неделю с новым функционалом! Причем, именно с функционалом.
Когда появились гики, которые собирали машины у себя в гаражах, они были невероятно популярны и все хотели быть такими же умными как они. Но мир поменялся. Сейчас это навык, который могут иметь все и оценивается он не сильно высоко. Также будет и с программистами.
– Я вообще даже не представляю, что там можно обновлять?
– Например, ты кофе ищешь. Во-первых, геолокация. Если ты кофе ищешь в поле, то наверно ты ищешь, как его выращивают или историю. Если кофе ищешь в центре мегаполиса, то, наверное, попить. Или Хилтон. Это фамилия или отель?
– Так, а SRE тут где?
– Во-первых, растет функционал, растет сложность, растет нагрузка. То есть, мы охватываем всё больше и больше людей, интернет становится доступнее и доступнее. Например, присоединяется Индия и другие, ранее недоступные страны и местности. Всё становится географически очень широким. И соответственно люди начинают потреблять, у сервиса растет нагрузка. И это дает чрезмерную сложность.
Одно дело открыть сервис только на Москву, другое – на всю Россию. Нагрузка колоссальная. И что происходит? Чтобы обслужить такое количество людей быстро, нужно очень много серверов. Сервисы должны быть доступны 24×7. Представь, если сейчас у тебя платеж будет идти не 5 минут, а три дня?
И вопрос, что администратору с этим всем делать?
– Я предположу, что есть много администраторов. И они существуют в сложной иерархии, чтобы всё это дело поддерживать.
– Администраторами, как пишет Google, расти невыгодно. Нанимать столько людей уже невозможно. Вот поэтому и появилось SRE.
– В какой момент DevOps становится SRE?
– Очень философский вопрос. Есть задачи и есть проблемы. Их нужно решать. Например, если в банке не выполнились переводы, то что делать? Решать проблему. Называть ли это SRE или не называть – непонятно.
Ну, и это вообще просто такой спор ни о чём. «Есть ли жизнь на Марсе, нет ли жизни на Марсе?» Является ли SRE DevOps’ом, не является ли SRE DevOps’ом? И SRE, и DevOps – это про то, как делать хорошо. Значит, берём лучшее отовсюду, применяем, чтобы пользователи были довольны.
– То есть две методологии работают в связке?
– В связке, но SRE всё-таки не администраторы, у них больше упор на программирование и автоматизацию. Плюс, я постоянно топлю за то, что мы административными методами редко должны работать. А если это происходит, то значит у нас что-то не так.
– Но это не ответ на вопрос.
– Они могут быть братья, они могут перекликаться, может быть одно и тоже – как хотите. А действия-то как поменяются? Всё равно всё сводится к одному: есть софт, его надо эксплуатировать, нужны какие-то люди, которые будут решать проблемы по нагрузке. И как их назвать – дело десятое.
– SRE может стать DevOps или программист? Вообще, что нужно изучать, чтобы стать востребованным SRE?
— Мне кажется, что надо учить не программирование, не SRE и DevOps, а думать про процесс, как про инженерное дело, которое присутствует в разработке программного обеспечения и оно многофакторное.
Недавно мы митап проводили про SRE, мы много спорили, но в одном мы сошлись: программисты уже не нужны так, как раньше. Нужны всем инженеры, которые могут решать проблемы. Когда появились гики, которые собирали машины у себя в гаражах, они были невероятно популярны и все хотели быть такими же умными как они. Но мир поменялся. Сейчас это навык, который могут иметь все и оценивается он не сильно высоко. Также будет и с программистами.
Про работу SRE в Google
– Давай про Гугл. Есть легенды про плюшки в Гугл при трудоустройстве. Расскажи поподробнее.
– Во-первых, когда уходишь с прошлого места работы, они спрашивают: «Сколько премий ты потеряешь, увольняясь?». Они компенсируют эти деньги, чтобы ты не раздумывал. Потом мне сняли на 3 месяца квартиру, дали отдельного риелтора от Google, который подбирает жилье. Либо они могут компенсировать тебе все расходы по переезду.
Первую неделю работы они тебе рассказывают вообще не про работу, а про то, как жизнь в Гугле и Ирландии устроена. В компании всё очень спокойно. Там везде микрокухни – фруктики, и прочее. Общение в микрокухнях – отдельная культура. Ещё есть трехразовое питание, массажи и раз в неделю можно прийти на работу с питомцем.
И такая мантра есть от менеджера – «главное, не перегори, не переработай.»
Ещё у нас история интересная была. Парень устроился сразу после вуза, и решил сэкономить на жилье. Он купил самый дешёвый фургон, поставил туда кровать. В Google есть прачечные, аккумуляторы он заряжал в офисе, душ и полотенца тоже имеются. Фургон поставил на парковку у офиса и ходил с нее на работу.
Он хотел быстро выплатить кредит за обучение. Но потом ему так делать запретили.
– Почему?
– В СМИ пошла новость, стали обсуждать, а Google не нравится большая активность. Репутация брэнда, все дела…
– А почему ты уехал в Россию и трудоустроился в Тинькофф? Это так нетипично. Все стараются свалить, а ты вернулся.
– Не знаю, бренд интересный и я клиент очень давно. Где ещё работать в России? Ну, Яндекс, ну Тинькофф. А уехал, потому что в Дублине скучно стало.
– Почему в Дублине скучно?
– Это маленький город. Это не Шенген, чтобы поехать в Европу – надо получать визу.
По-нашему менталитету Дублин – это деревня. Когда местные говорят, что они устали от Дублина, потому что там вайб большого города, для жителей Москвы это звучит смешно.
Но плюсы там были, например, очень спокойные люди. Там вообще никто не повышает голос. В России то, что не считается повышением голоса, после Дублина выглядит контрастно.
– А почему в Google скучно? Что у Тинькофф есть такого, что нет у Google?
– В Тинькофф есть драйв и хорошая агрессивность.
«Мы хотим там расти, мы хотим захватывать рынки, мы хотим быть лучшими.»
А в Google: «Мы уже лучшие. Мы уже всё захватили. Ну, что-то мы ещё хотим дозахватить в Китае, но там политические проблемы».
Если вам понравилось, ищите подробности в полной версии интервью.
Для чего нужны «золотые сигналы» мониторинга и SRE?
Прим. перев.: То, что сегодня принято называть SRE (Site Reliability Engineering — «обеспечение надежности информационных систем»), включает в себя большой спектр мероприятий по эксплуатации программных продуктов, направленных на достижение ими необходимого уровня надежности. Мониторинг — одно из ключевых мероприятий, а «золотые сигналы» образуют главные метрики, которые должны в нём учитываться. Не найдя на Хабре ни одного материала про них, мы решили перевести небольшую заметку от авторов платформы для управления инцидентами (VictorOps), дающую представление общее представление об этом подходе.
Эффективный site reliability engineering (SRE) опирается на глубокое понимание базовой инфраструктуры сервиса и архитектуры. Повышение прозрачности состояния приложения и инфраструктуры — это только начало проактивной работы над созданием надежных систем. При этом наилучшей отправной точкой для мониторинга состояния систем считаются так называемые «четыре золотых сигнала» (four golden signals) SRE. Наладив эти четыре базовых метода мониторинга, можно переходить к дальнейшему повышению прозрачности системы.
Повышение прозрачности вкупе с эффективными методами совместной работы позволяет командам SRE оперативно отслеживать работу систем и принимать меры для устранения последствий инцидентов, повышая общую эффективность методов мониторинга и оповещения. Золотые сигналы SRE помогают командам выявлять любые потенциальные слабые места в надежности, позволяя сосредоточиться над устранением проблем в инфраструктуре. Давайте же исследуем взаимосвязь между методами мониторинга и командами SRE и посмотрим, какое влияние золотые сигналы оказывают на процесс.
Мониторинг и SRE
В III части нашего DevOps-словаря мы исследовали интернет, пытаясь найти определение SRE. Согласно соответствующей статье в Wikipedia, «Ben Treynor, основатель Site Reliability Team в Google [говорит], что SRE — „это то, что получается, когда software engineer занимается тем, что раньше называлось эксплуатацией“». SRE сочетает задачи и возможности программной инженерии с проблемами эксплуатации IT и помогает находить решения для вопросов, связанных с надежностью. Понятно, что команды SRE должны мониторить свои сервисы для выявления областей, в которых можно повысить надежность.
Именно в этом и заключается задача мониторинга применительно к командам SRE. Он занимает лишь небольшую часть в создании высокопрозрачных систем, однако это важный элемент для понимания состояния приложений и инфраструктуры. Четыре золотых сигнала мониторинга и SRE обеспечивают базовый уровень прозрачности в отношении надежности всего, что вы создаете. Достигнув комфортного уровня наблюдаемости состояния золотых сигналов, можно использовать эту дополнительную информацию для более углубленного анализа с помощью инструментов для мониторинга.
Теперь, когда мы определились с важностью мониторинга золотых сигналов SRE, давайте обратимся к реальным метрикам, составляющим их.
Четыре золотых сигнала мониторинга
В начале пути по совершенствованию усилий по мониторингу бывает непросто понять, с чего следует начинать. Четыре золотых сигнала SRE и мониторинга впервые были приведены в книге Google о SRE, и в настоящее время активно используются многими командами. С них отлично начинать, поскольку они помогают выделить основные метрики, которые следует отслеживать всегда.
Итак, давайте рассмотрим золотые сигналы и разберемся, почему их мониторинг является неотъемлемым элементом в обеспечении надежности любой системы.
1. Задержка (Latency)
Сколько времени занимает обработка запроса? Определите ориентир для задержек, типичных для успешных запросов, и сравните его с задержками для неуспешных запросов. Отслеживание задержек, вызванных ошибками, позволяет решить любые вопросы, связанные со скоростью выявления инцидента и реакции на него.
2. Трафик (Traffic)
Этот сигнал не требует особых пояснений. Какое влияние на систему оказывает количество пользователей или число транзакций, проходящих через сервис? В зависимости от функциональности сервиса измерение трафика может существенно отличаться от компании к компании. Отслеживая взаимодействие с реальными пользователями и трафик, можно лучше понять, как конечные пользователи воспринимают сервис, и получить представление о том, как системы ведут себя в условиях стресса.
3. Ошибки (Errors)
Конечно, каждая команда должна следить за ошибками. Независимо от того, вызваны ли ошибки заданной вручную логикой или автономны (вроде неудавшегося HTTP-запроса), SRE-команды должны отслеживать их. Многие SRE-команды используют специальное ПО для управления инцидентами для оповещений о критических ошибках, поиска их причин и проведения работ по устранению последствий.
4. Насыщенность (Saturation)
Каждая команда должна следить за загруженностью своей системы. Важно задать метрику для насыщенности, которая бы означала, что сервис достиг максимума своих возможностей. Большинство сервисов начинают терять производительность еще до того, как загрузка достигнет 100%, поэтому понимание функциональности вашей собственной системы важно для определения ориентира насыщенности, который имеет смысл.
Установив правила мониторинга и оповещений для четырех золотых сигналов, вы охватите большинство ключевых инцидентов в системе. Однако чтобы приступить с созданию проактивной системы для мониторинга и SRE, придется копнуть еще глубже.
Прим. перев.: Как пример иллюстрации dashboard’а с графиками «золотых сигналов» приведём результат соответствующей конфигурации мониторинга для Kubernetes из этой статьи от Sysdig:
Прим. перев.: А вот более наглядное представление о золотых сигналах от Denise Yu, которую можно использовать как удобную памятку:
Проактивный SRE выходит за рамки золотых сигналов
Мониторинг золотых сигналов — отличное начало для анализа инцидентов в сервисе, однако его не достаточно. Опытные команды SRE проактивно изучают свои системы с помощью многочисленных дополнительных методов. Проводя организованные испытания на подготовительных этапах и в production, команды SRE активно изучают свои системы и используют получаемую информацию для повышения надежности сервисов.
Chaos Engineering
Хаос-инжиниринг — это дисциплина, применяемая командами для испытания своих систем с целью упреждающего обнаружения слабых мест и уязвимостей. Вручную вводя хаос в сервис, можно посмотреть, как именно система реагирует на различные обстоятельства.
Прим. перев.: Подробнее о таком подходе читайте в статье «Chaos Engineering: искусство умышленного разрушения» (часть 1 и часть 2).
Игровые дни (Game Days)
В то время как хаос-инжиниринг направлен на понимание системы, игровые дни помогают понять персонал. Они используются для проверки устойчивости команды, когда речь идет о реагировании на инциденты и устранении их последствий. Результаты игровых дней можно использовать для разработки более эффективных процессов или определения потребности в новых инструментах, повышающих эффективность персонала.
Синтетический мониторинг
Синтетический мониторинг позволяет командам создавать искусственных пользователей и имитировать их поведение с помощью сервиса. Можно задать определенные поведенческие паттерны и понаблюдать за тем, как система ведет себя в условиях данной нагрузки. Синтетический мониторинг — отличный метод для детального тестирования и определения надежности конкретных сервисов в рамках всей системы.
Любая команда, стремящаяся визуально отслеживать состояние системы, обязана следить за золотыми сигналами SRE. Но представление о состоянии и общей надежности системы — вовсе не то же самое, что работа над повышением ее надежности. В современной экосистеме высокораспределенных систем и стремительного развертывания перед командами SRE стоит непростая задача. Золотые сигналы мониторинга и SRE могут стать той отправной точкой, с которой начнется дальнейшее совершенствование в рамках SRE.