В первый день вы познакомитесь с теорией 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.
В большой системе существует много взаимозависимых сервисов, и не всегда они работают одинаково хорошо. Особенно обидно, когда с вашим сервисом порядок, а соседний, от которого вы зависите, периодически уходит в down.
Учебный проект окажется именно в таких условиях, а вы сделаете так, чтобы он все равно выдавал качество на максимально возможном уровне.

Тема 3: Управление инцидентами

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

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

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

Тема 4: Health Checking

• Health Check в Kubernetes
• Жив ли наш сервис?
• Exec probes
• InitialDelaySeconds
• Secondary Health Port
• Sidecar Health Server
• Headless Probe
• Hardware Probe

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

Тема 5: Практика работы с постмортемами

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

Тема 6: Решение проблем с инфраструктурой

• Мониторинг PostgreSQL
• SLO/SLI для PostgreSQL
• Anomaly detection

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

Тут два кейса про высокую доступность продакшена: traffic shielding и canary deployment. Вы узнаете об этих подходах и научитесь их применять. Хардкорной настройки руками не планируем, хотя кто знает.

Тема 7: Traffic shielding

• Поведение графиков роста количества запросов и бизнес операций
  
• Понятие saturation и capacity planning
  
• Traffic shielding и внедрение rate limiting
  
• Настройка sidecar с rate-limiting на 100 запросов в секунду

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

Тема 8: 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 кейса: проблема с кодом.
Как бы хорошо новые фичи не работали на стейджинге, всегда есть вероятность, что в продакшене что-то пойдёт не так. Снизить потенциальный ущерб можно, если выкатить обновление только на часть пользователей и предусмотреть возможность быстрого отката назад.
Подобный подход называется Canary Deployment, и через практический кейс вы научитесь его применять.

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