SRE — это не сферический конь в вакууме.
Три дня будем учиться на практических кейсах, решать горящие проблемы своими руками.
Будем работать в командах по 6 человек.
Вы сможете обменяться опытом с коллегами из других компаний.
После интенсива будут доступны все записи, практические задания и презентации.
На интенсиве вы будете:
Строить:
Сформулируете SLO, SLI, SLA для сайта, состоящего из нескольких
микросервисов, разработаете архитектуру и инфраструктуру, которая их обеспечит.
Ломать:
Рассмотрите внутренние и внешние факторы ухудшения SLO: ошибки разработчиков, отказы инфраструктуры, наплыв посетителей, DDoS-атаки. Разберетесь в устойчивости, error budget, практике тестирования, управлении прерываниями и операционной нагрузкой.
Чинить:
Поймете, как организовать работу группы по ликвидации аварии в минимальные сроки. Пока вы будете искать решение, вам будут звонить директор и бухгалтер, компания будет терять деньги. Всё как в жизни!
Изучать:
Разберете подход к сайту с точки зрения SRE. Проанализируете инциденты (причины возникновения, ход устранения), напишете postmortem. Примете решения по дальнейшему предотвращению аварий: улучшить мониторинг, изменить архитектуру, подход к разработке и эксплуатации, регламенты. Автоматизируете процессы.
Требования к участникам:
- Свободное владение Linux;
- Любой язык программирования: уровень Junior;
- GitLab: навыки автоматизации;
- Prometheus: навыки мониторинга;
- Kubernetes: навыки работы в кластере.
Для обучения необходимы:
- SSH-клиент,
- наличие Docker у себя локально,
- текстовый редактор/IDE.
Программа
Первый день (21 мая, пятница с 10:00 до 18:00)
День знакомства с теорией SRE, настройки мониторинга и алертинга. А еще это день, когда вы станете командой с другими студентами интенсива.
Будут метрики SLO, SLI, SLA и как они соотносятся с требованиями бизнеса. Best Practiсes по настройке мониторинга. Правила для пожарной команды. И конечно же первые КЕЙСЫ. По отзывам студентов предыдущих потоков, метрики для многих оказались важной и сложной темой.
Тема №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 мая, суббота с 10:00 до 18:00)
Второй день практически полностью построен вокруг решения двух кейсов: проблемы с окружением и проблемы с архитектурой. В рамках первого кейса подробно разберем тему 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 мая, воскресенье с 10:00 до 18:00)
Тут два кейса про отказоустойчивость и высокодоступность продакшена: 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 кейса: проблема с кодом.
