Бесплатный курс «Разработчик, или от Мидла до Сеньора», старт 8 ноября
Close
На интенсиве вы познакомитесь с принципами SRE. Будете поддерживать приложение, определите для него SLI и SLO, настроите мониторинг, алертинг, поймете как действовать при авариях.

SRE. Аварии на проде: практикум для инженеров

SRE интенсив слёрм, варим SRE
3–5 декабря 2021
На интенсиве вы познакомитесь с принципами SRE. Будете поддерживать приложение, определите для него SLI и SLO, настроите мониторинг, алертинг, поймете как действовать при авариях.

SRE. Аварии на проде: практикум для инженеров

Интенсив
SRE интенсив слёрм, варим SRE
3–5 декабря 2021

Программа

День 1: знакомство с теорией SRE, настройка мониторинга и алёртинга (с 10:00 до 18:00)
В первый день вы познакомитесь с теорией SRE, научитесь настраивать мониторинг и алёртинг, а также объединитесь в команду с другими участниками интенсива.

Расскажем про метрики SLO, SLI, SLA и как они соотносятся с требованиями бизнеса. Поделимся Best Practices по настройке мониторинга и правилами для пожарной команды. Дадим первые практические кейсы.

Тема 1: Мониторинг
  • Зачем нужен мониторинг,
  • Symptoms vs Causes,
  • Black-Box vs White-Box Monitoring,
  • Golden Signals,
  • Перцентили,
  • Alerting,
  • Observability.
Практика: Делаем базовый дашборд и настраиваем необходимые алерты.

Тема 2: Теория SRE
  • SLO, SLI, SLA,
  • Durability,
  • Error budget.
Практика: Добавляем на дашборд SLO/SLI + алерты.
Практика: Первая нагрузка системы.

Практика, решение 1 кейса: зависимость downstream.

Тема 3: Управление инцидентами
  • Resiliencе Engineering,
    • Как выстраивается пожарная бригада,
    • Насколько ваша команда эффективна в инциденте,
    • 7 правил для лидера инцидента,
    • 5 правил для пожарного,
    • HiPPO — highest paid person's opinion. Communications Leader.
Практика, решение 2 кейса: зависимость upstream.

День 2: решение проблем с окружением и архитектурой (с 10:00 до 18:00)
Второй день практически полностью построен вокруг решения двух кейсов: проблемы с окружением (здесь будет подробный разбор Health Checking) и проблемы с архитектурой. Спикеры расскажут про работу с постмортерами (post mortem) и дадут шаблоны, которые вы сможете использовать в своей команде.

Тема 5: Health Checking

  • Health Check в Kubernetes.
  • Жив ли наш сервис?
  • Exec probes.
  • initialDelaySeconds.
  • Secondary Health Port.
  • Sidecar Health Server.
  • Headless Probe.
  • Hardware Probe.
Практика, решение 3 кейса: проблема с окружением, билеты купить невозможно.

Тема 6: Практика работы с постмортемами
Практика: Пишем постмортем по предыдущему кейсу и разбираем его со спикерами.

Тема 7: Решение проблем с инфраструктурой
  • Мониторинг MySQL;
  • SLO/SLI для MySQL;
  • Anomaly detection
Практика, решение 4 кейса: проблемы с базой данных.
День 3: Traffic shielding и канареечные релизы (с 10:00 до 18:00)
Тут два кейса про высокую доступность продакшена: traffic shielding и canary deployment. Вы узнаете об этих подходах и научитесь их применять. Хардкорной настройки руками не планируем, хотя кто знает.

Тема 8: Traffic shielding
  • Поведение графиков роста количества запросов и бизнес операций,
  • Понятие saturation и capacity planning,
  • Traffic shielding и внедрение rate limiting,
  • Настройка sidecar с rate-limiting на 100 запросов в секунду.
Практика, решение 5 кейса: Traffic shielding, исследуем поведение провайдера под нагрузкой, которую он не в состоянии выдержать.

Тема 9: 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 кейса: проблема с кодом.

Тема 10: SRE онбординг проекта
В крупных компаниях нередко формируют отдельную команду SRE, которая берёт на поддержку сервисы других отделов. Но не каждый сервис готов к тому, чтобы его можно было взять на поддержку. Расскажем, каким требованиям он должен отвечать.
День 1: знакомство с теорией SRE, настройка мониторинга и алёртинга ( с 10:00 до 18:00)
В первый день вы познакомитесь с теорией SRE, научитесь настраивать мониторинг и алёртинг, а также объединитесь в команду с другими участниками интенсива.

Расскажем про метрики SLO, SLI, SLA и как они соотносятся с требованиями бизнеса. Поделимся Best Practices по настройке мониторинга и правилами для пожарной команды. Дадим первые практические кейсы.

Тема 1: Мониторинг
  • Зачем нужен мониторинг,
  • Symptoms vs Causes,
  • Black-Box vs White-Box Monitoring,
  • Golden Signals,
  • Перцентили,
  • Alerting,
  • Observability.
Практика: Делаем базовый дашборд и настраиваем необходимые алерты.

Тема 2: Теория SRE
  • SLO, SLI, SLA,
  • Durability,
  • Error budget.
Практика: Добавляем на дашборд SLO/SLI + алерты.
Практика: Первая нагрузка системы.

Практика, решение 1 кейса: зависимость downstream.

Тема 3: Управление инцидентами
  • Resiliencе Engineering,
    • Как выстраивается пожарная бригада,
    • Насколько ваша команда эффективна в инциденте,
    • 7 правил для лидера инцидента,
    • 5 правил для пожарного,
    • HiPPO — highest paid person's opinion. Communications Leader.
Практика, решение 2 кейса: зависимость upstream.

Тема 4: SRE онбординг проекта
В крупных компаниях нередко формируют отдельную команду SRE, которая берёт на поддержку сервисы других отделов. Но не каждый сервис готов к тому, чтобы его можно было взять на поддержку. Расскажем, каким требованиям он должен отвечать.

День 2: решение проблем с окружением и архитектурой (с 10:00 до 18:00)
Второй день практически полностью построен вокруг решения двух кейсов: проблемы с окружением (здесь будет подробный разбор Health Checking) и проблемы с архитектурой. Спикеры расскажут про работу с постмортерами (post mortem) и дадут шаблоны, которые вы сможете использовать в своей команде.

Тема 5: Health Checking

  • Health Check в Kubernetes.
  • Жив ли наш сервис?
  • Exec probes.
  • initialDelaySeconds.
  • Secondary Health Port.
  • Sidecar Health Server.
  • Headless Probe.
  • Hardware Probe.
Практика, решение 3 кейса: проблема с окружением, билеты купить невозможно.

Тема 6: Практика работы с постмортемами
Практика: Пишем постмортем по предыдущему кейсу и разбираем его со спикерами.

Тема 7: Решение проблем с инфраструктурой
  • Мониторинг MySQL;
  • SLO/SLI для MySQL;
  • Anomaly detection
Практика, решение 4 кейса: проблемы с базой данных.
День 3: Traffic shielding и канареечные релизы (с 10:00 до 18:00)
Тут два кейса про высокую доступность продакшена: traffic shielding и canary deployment. Вы узнаете об этих подходах и научитесь их применять. Хардкорной настройки руками не планируем, хотя кто знает.

Тема 8: Traffic shielding
  • Поведение графиков роста количества запросов и бизнес операций,
  • Понятие saturation и capacity planning,
  • Traffic shielding и внедрение rate limiting,
  • Настройка sidecar с rate-limiting на 100 запросов в секунду.
Практика, решение 5 кейса: Traffic shielding, исследуем поведение провайдера под нагрузкой, которую он не в состоянии выдержать.

Тема 9: 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 кейса: проблема с кодом.

Что будем тушить? Пожары!

Практика 1: downstream-зависимость
В большой системе существует много взаимозависимых сервисов, и не всегда они работают одинаково хорошо. Особенно обидно, когда с вашим сервисом порядок, а соседний, от которого вы зависите, периодически уходит в down.

Учебный проект окажется именно в таких условиях, а вы сделаете так, чтобы он все равно выдавал качество на максимально возможном уровне.
Практика 2: upstream-зависимость
Одно дело, когда вы зависите от сервиса с низким SLO. Другое дело, когда ваш сервис является таковым для других частей системы. Так бывает, если критерии оценки не согласованы: например, вы отвечаете на запрос в течение секунды и считаете это успехом, а зависимый сервис ждёт всего 500 мск и уходит с ошибкой.

В кейсе обсудим важность согласования метрик и научимся смотреть на качество глазами клиента.
Практика 3: правильный Healthcheck
Задача Healthcheck — обнаружить неработающий сервис и заблокировать трафик к нему. И если вы думаете, что для этого достаточно сделать рутом запрос к сервису и получить ответ, то вы ошибаетесь: даже если сервис ответит, это не гарантирует его работоспособность — проблемы могут быть в окружении.

Через этот кейс вы научитесь настраивать корректный Healthcheck и не пускать трафик туда, где он не может быть обработан.
Практика 4: проблемы с БД
База данных тоже может быть источником проблем. Например, если не следить за replication relay, то реплика устареет и приложение будет отдавать старые данные. Причём дебажить такие случаи особенно сложно: сейчас данные рассогласованы, а через несколько секунд уже нет, и в чём причина проблемы — непонятно.

Через кейс вы прочувствуете всю боль дебага и узнаете, как предотвращать подобные проблемы
Практика 5: traffic shielding
Когда падает прод? Например, когда мощности рассчитаны на 100 пользователей, а приходит 1000. Вы столкнётесь с подобным кейсом и научитесь делать так, чтобы система не падала целиком, а продолжала обслуживать то количество клиентов, на которое была рассчитана.

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

Подобный подход называется Canary Deployment, и через практический кейс вы научитесь его применять.



Требования к участникам:
Свободное владение Linux;
Любой язык программирования: уровень Junior;
GitLab: навыки автоматизации;
Prometheus: навыки мониторинга;
Kubernetes: навыки работы в кластере.

Для обучения необходимы:
- SSH-клиент,
- наличие Docker у себя локально,
- текстовый редактор/IDE.

Слабые навыки работы в Kubernetes – не проблема. Вы сможете найти решение вместе с командой. Также можно предварительно пройти курс Kubernetes База.
Спикеры практикума
Иван Круглов
Staff Software Engineer в Databricks

Владеет искусством управления перегруженными базами данных и canary deployment. Имеет опыт в enterprise компаниях по:
— распределенной доставке и обработке сообщений;
— BigData и web-stack;
— поиску;
— построению внутреннего облака;
— service mesh.
Павел Селиванов
Архитектор в Mail.ru Cloud Solutions

Разбирается в контроле трафика и создании сложных систем:
— На счету десятки выстроенных инфраструктур и сотни написанных пайплайнов CI/CD;
— Сертифицированный администратор Kubernetes;
— Автор нескольких курсов по Kubernetes и DevOps;
— Регулярный докладчик на Российских и международных IT-конференциях.
Артём Артемьев
Lead SRE в Tango me

Знает, как помочь команде встретиться с SLI и жить дружно.
Имеет успешный опыт в:
— Инцидент-менеджменте и мониторинге сложных решений;
— Performance-тестировании и борьбе за каждый RPS.
О формате
Практика. Вы будете разбирать горящие проблемы своими руками и решать практические кейсы (хотя немного теории все же будет).
Работа в команде. Будем работать в командах по 6 человек. Вы сможете обменяться опытом с коллегами из других компаний.
Запись лекций и доступ к практическим заданиям. После интенсива будут доступны все записи, практические задания и презентации.
Рабочее приложение. Специально для практикума написано боевое приложения, подготовлены виртуальные сервера и проблемы.
О формате
1
Практика
Вы будете разбирать горящие проблемы своими руками и решать практические кейсы (хотя немного теории все же будет).
2
Приложение
Рабочее приложение. Специально для практикума написано боевое приложения, подготовлены виртуальные сервера и проблемы.
3
Команда
Будем работать в командах по 6 человек. Вы сможете обменяться опытом с коллегами из других компаний.
Что говорят прошлые участники
Стоимость практикума
90 000 ₽
3 дня по 8 часов.
Старт 3 декабря
Оставить заявку
3 дня по 8 часов.
70 000 ₽
для команд от 5 человек
Заявка на команду
Оплатить как юр.лицо
Мы свяжемся с вами, ответим на вопросы и отправим счёт
Рассрочка
Процесс оформления:
1. Оставляете заявку и получаете на почту анкету для оформления рассрочки.
2. Банк принимает решение в течение нескольких минут.
3. Заключаете сделку с банком онлайн.
4. Мы отправляем кассовый чек на эл. почту
и предоставляем доступ к курсу.

Условия рассрочки:
Срок: 4 месяца
Первый платеж: от 0 руб.
Переплата: 0 руб. Вы оплачиваете только стоимость курса, без процентов.
Предоставляется только физическим лицам.