С 2016 года вышло немало статей, разборов, мнений о книге Google «Site Reliability Engineering». Книги – это мощь, поэтому мы не будем однобокими – поищем хорошее и не очень.
А на проблемы внесём конструктивное предложение и расскажем об одном из возможных вариантов во вселенной: практическом офлайн-интенсиве «SRE» от Слёрм.
О книжке
В 2016 году Google опубликовал книгу «Site Reliability Engineering». В ней собран опыт, который можно назвать практической реализацией DevOps парадигмы в конкретной компании. Для IT-сообщества этот опыт стал подходом к обеспечению надежности систем, который можно копировать, внедрять у себя. Отличие подхода и в том, что поддержка проекта неразрывна связана с копанием в коде проекта. Осторожно: на первых порах администраторов это может шокировать.
Чем интересна книжка
Однозначно одной из заслуг авторов книги является то, что она раскрывает связь Dev и Ops, то есть как можно внедрить DevOps, с точки зрения инструментов. Отвечает на вопрос, кто должен решать структурные проблемы и как.
Из полезняшек, которые на слуху, это история о метриках SLx. Подход SRE раскрывает, что реально важно в проекте. Оптимизация затрат в облаке, обновление железа – вторично, если не третично. На передний план выходит обсуждение бизнес-целей по которым потом определяются метрики. Сюда же плюсуем «Четыре золотых сигнала мониторинга».
В целом книжка – большой объём теории и кейсы на примере Google. Есть примеры, когда компании даже внедряли SRE, оттолкнувшись от книги.
Интересен в этом плане опыт Додо Пиццы, рассказанный на DevOpsConf, они 5 месяцев (по плану 4) формировали SRE-команду, оставив на этот срок 3 из 12 человек прикрывать тылы, а остальные погружались в обучение (3 часа в день) и занимались IaC. Здорово, что всё у ребят успешно получилось.
В чём книжка не помощник
Из предыдущего абзаца можно сделать вывод, что на книжке можно даже клятву давать, но есть пара весьма обсуждаемых моментов.
Книга не поможет продвинуть идею, не даёт плана с чего начать. Известное дело, что тяжелее всего, когда ты ещё один. Никто не говорит, что в одиночку нельзя
В целом, всё, что написано в книге, это опыт Google. Поэтому и примеры неразрывно связаны с масштабами, до которых среднестатистической IT-компании как до Китая… И программные инструменты в основном применяются не сторонние, которые +- доступны всем, а внутренние.
Сегодня есть уже несколько книг по SRE, которые неплохо закрывают теоретическую базу, но вот главное чего нет в книгах – практика. Тяжело перейти от чтения букв к практической реализации. Это же два разных процесса.
Наверно практику внедрения можно получить у себя на проде, но предполагаем, что это дорогой вариант для первых проб. Поэтому мы предложим наш вариант.
Практический офлайн-интенсив «SRE» от Слёрм
21–23 мая 2021 мы в третий раз проведём интенсив «SRE». И это будет практика. На три дня вы станете частью SRE-команды, почувствуете, что такое — быть SRE-инженером.
SRE – это огромный пласт знаний и за три дня SRE не стать. Мы сделаем вместе первые шаги, покажем куда идти, что нужно. Дальше вам предстоит долгий тернистый путь пожарника, дебагера и копания в коде. Но вы будете точно знать, что вас ждёт, к чему вы идёте и зачем.
Мы рекомендуем покупать билеты если не всей команде, то хотя бы нескольким. Это упростит будущее внедрение SRE. Желательно, чтобы это были спецы с разным опытом и ролями в текущей команде. Поэтому мы даём скидку от трёх участников.
Посмотреть информацию об интенсиве на сайте: slurm.club/sreticket
Что будет на интенсиве
SRE-команда получит свой проект: сайт-агрегатор билетов в кино, состоящий из нескольких микросервисов. Он агрегирует данные о сеансах, ценах и свободных местах со всех кинотеатров, показывает анонсы фильмов, дает выбрать кинотеатр, сеанс, зал и место, забронировать и оплатить билеты. И вы будете работать с проектом в режиме реальном времени.
Вас ждет работа с незнакомым кодом, проблемы синхронизации распределенных систем, нетривиальные отказы систем, взятые из реальной жизни, сложности коммуникации с коллегами.
Программа по дням
День знакомства с теорией SRE, настройки мониторинга и алертинга. А еще в этот день, когда вы станете командой с другими студентами интенсива.
Будут метрики SLO, SLI, SLA и как они соотносятся с требованиями бизнеса. Лучшие практики по настройке мониторинга. Правила для пожарной команды. И первые кейсы. По отзывам студентов предыдущих потоков, метрики для многих оказались важной и сложной темой.
Тема №1: Мониторинг
– Зачем нужен мониторинг,
– Symptoms vs Causes,
– Black-Box vs White-Box Monitoring,
– Golden Signals,
– Перцентили,
– Alerting,
– Observability.
Практика: делаем со студентами базовый дашборд и настраиваем необходимые алерты
Тема №2: Теория SRE
– SRE vs DevOps;
– SLO, SLI, SLA;
– Durability;
– Error budget.
Практика: добавляем на дашборд SLO/SLI + алерты
Практика: первая нагрузка системы
Тема №3: SRE онбординг проекта
Тема №4: Управление инцидентами
– Введение в управление инцидентами,
– Resiliencе Engineering.
Практика, решение 1 кейса: зависимость downstream
– Как выстраивается пожарная бригада.
– Насколько ваша команда эффективна в инциденте?
– 7 правил для лидера инцидента.
– 5 правил для пожарного.
– HiPPO – highest paid person's opinion. Communications Leader.
Практика, решение 2 кейса: SLO в опасности, зависимость upstream
Второй день практически полностью построен вокруг решения двух кейсов: проблемы с окружением и проблемы с архитектурой. В рамках первого кейса подробно разберем тему Health Checking. Помимо примеров отказа системы, спикеры расскажут про работу с постмортерами (post mortem) и дадут примеры, которые вы сможете использовать в своей команде. Оба кейса злободневные и могу возникнуть в реальном проекте SRE специалиста.
Тема №5: Концепция контекст запроса
Тема №6: Health Checking
– Health Check в Kubernetes.
– Жив ли наш сервис?
– Exec probes.
– initialDelaySeconds.
– Secondary Health Port.
– Sidecar Health Server.
– Headless Probe.
– Hardware Probe.
Практика, решение 3 кейса: проблема с окружением, билеты купить невозможно
Тема №7: Практика работы с постмортемами
Практика: пишем постмортем по предыдущему кейсу и разбираем его со спикерами
Тема №8: Решение проблем с инфраструктурой
– Мониторинг MySQL;
– SLO/SLI для MySQL;
– Anomaly detection.
Практика, решение 4 кейса: проблема с БД
В этот день два кейса про отказоустойчивость и высокодоступность продакшена: traffic shielding и canary deployment. Оба кейса — важные практики SRE. Они нужны для разного: traffic shielding позволит допустить до прода только ту часть трафика, которую он выдержит. Такая ситуация может случиться скорее из-за ошибки разработки при неверном перенаправлении трафика, чем из-за злоумышленников. В теме Canary deployment спикеры расскажут, как выкатить обновления на часть пользователей, а не на всех сразу — даже если тесты на стейджинге прошли, остается вероятность, что обновление сломает прод.
Мы полагаем, что третий день будет больше для того, чтобы посмотреть «какие подходы бывают и как их применять». Прямо хардкорной настройки руками не планируем.
Тема №9: Traffic shielding
– Поведение графиков роста количества запросов и бизнес операций,
– Понятие saturation и capacity planning,
– Traffic shielding и внедрение rate limiting,
– Настройка sidecar с rate-limiting на 100 запросов в секунду.
Практика, решение 5 кейса: traffic shielding, исследуем поведение провайдера под нагрузкой, которую он не в состоянии выдержать
Тема №10: Canary Deployment
– Стратегии деплоя в k8s (RollingUpdate vs Recreate);
– Canary и blue-green стратегии;
– Обзор инструментов для blue-gree/canary release в k8s;
– Настройка canary release в GitLab CI/CD;
– Пояснение схемы работы canary release;
– Внесение изменений в .gitlab-ci.yml.
Практика, решение 6 кейса: проблема с кодом
Первый день: 21 мая, пятница
День знакомства с теорией SRE, настройки мониторинга и алертинга. А еще в этот день, когда вы станете командой с другими студентами интенсива.
Будут метрики SLO, SLI, SLA и как они соотносятся с требованиями бизнеса. Лучшие практики по настройке мониторинга. Правила для пожарной команды. И первые кейсы. По отзывам студентов предыдущих потоков, метрики для многих оказались важной и сложной темой.
Тема №1: Мониторинг
– Зачем нужен мониторинг,
– Symptoms vs Causes,
– Black-Box vs White-Box Monitoring,
– Golden Signals,
– Перцентили,
– Alerting,
– Observability.
Практика: делаем со студентами базовый дашборд и настраиваем необходимые алерты
Тема №2: Теория SRE
– SRE vs DevOps;
– SLO, SLI, SLA;
– Durability;
– Error budget.
Практика: добавляем на дашборд SLO/SLI + алерты
Практика: первая нагрузка системы
Тема №3: SRE онбординг проекта
Тема №4: Управление инцидентами
– Введение в управление инцидентами,
– Resiliencе Engineering.
Практика, решение 1 кейса: зависимость downstream
– Как выстраивается пожарная бригада.
– Насколько ваша команда эффективна в инциденте?
– 7 правил для лидера инцидента.
– 5 правил для пожарного.
– HiPPO – highest paid person's opinion. Communications Leader.
Практика, решение 2 кейса: SLO в опасности, зависимость upstream
Второй день: 22 мая, суббота
Второй день практически полностью построен вокруг решения двух кейсов: проблемы с окружением и проблемы с архитектурой. В рамках первого кейса подробно разберем тему Health Checking. Помимо примеров отказа системы, спикеры расскажут про работу с постмортерами (post mortem) и дадут примеры, которые вы сможете использовать в своей команде. Оба кейса злободневные и могу возникнуть в реальном проекте SRE специалиста.
Тема №5: Концепция контекст запроса
Тема №6: Health Checking
– Health Check в Kubernetes.
– Жив ли наш сервис?
– Exec probes.
– initialDelaySeconds.
– Secondary Health Port.
– Sidecar Health Server.
– Headless Probe.
– Hardware Probe.
Практика, решение 3 кейса: проблема с окружением, билеты купить невозможно
Тема №7: Практика работы с постмортемами
Практика: пишем постмортем по предыдущему кейсу и разбираем его со спикерами
Тема №8: Решение проблем с инфраструктурой
– Мониторинг MySQL;
– SLO/SLI для MySQL;
– Anomaly detection.
Практика, решение 4 кейса: проблема с БД
Третий день: 23 мая, воскресенье
В этот день два кейса про отказоустойчивость и высокодоступность продакшена: traffic shielding и canary deployment. Оба кейса — важные практики SRE. Они нужны для разного: traffic shielding позволит допустить до прода только ту часть трафика, которую он выдержит. Такая ситуация может случиться скорее из-за ошибки разработки при неверном перенаправлении трафика, чем из-за злоумышленников. В теме Canary deployment спикеры расскажут, как выкатить обновления на часть пользователей, а не на всех сразу — даже если тесты на стейджинге прошли, остается вероятность, что обновление сломает прод.
Мы полагаем, что третий день будет больше для того, чтобы посмотреть «какие подходы бывают и как их применять». Прямо хардкорной настройки руками не планируем.
Тема №9: Traffic shielding
– Поведение графиков роста количества запросов и бизнес операций,
– Понятие saturation и capacity planning,
– Traffic shielding и внедрение rate limiting,
– Настройка sidecar с rate-limiting на 100 запросов в секунду.
Практика, решение 5 кейса: traffic shielding, исследуем поведение провайдера под нагрузкой, которую он не в состоянии выдержать
Тема №10: Canary Deployment
– Стратегии деплоя в k8s (RollingUpdate vs Recreate);
– Canary и blue-green стратегии;
– Обзор инструментов для blue-gree/canary release в k8s;
– Настройка canary release в GitLab CI/CD;
– Пояснение схемы работы canary release;
– Внесение изменений в .gitlab-ci.yml.
Практика, решение 6 кейса: проблема с кодом
Как будет организовано обучение
Вы будете работать с кейсами в небольших командах по 4–6 человек, в каждой команде будут собраны специалисты с разным опытом и компетенциями. При этом разделять участников из одной компании не будем.
У каждой команды будет свой фасилитатор, помогающий организовать обучение и взаимодействие в рамках задач по проекту. Спикеры будут взаимодействовать со всеми командами, отвечать на вопросы. Помогать командам на месте улучшить процессы.
Место проведения и стоимость
Информация запоминается лучше когда сопровождается яркими впечатлениями. Офлайн обеспечивает их по полной программе. Да и от работы проще отвлечься.
Проводить офлайн-интенсив будем в конференц-зале отеля «Севастополь»:
Москва, Большая Юшуньская улица, 1А, корпус 5.
Онлайн тоже можно участвовать. Но тогда кофе и плюшки за свой счёт.
При оплате до 1 мая: 70 000 рублей.
Командой 3+: 50 000 рублей за участника.
Оформить билеты: slurm.club/sreticket
