12 ноября в «Слёрме» начнётся интенсив по SRE. На три полных дня участники погрузятся в теорию и практику поддержки высоконагруженных сервисов. Никаких задач по работе, никаких семейных дел — только учёба. Под катом рассказываем, что вас ждёт, если решите присоединиться.
Справка об SRE
Site Reliability Engineering (SRE) — обеспечение надёжности информационных систем. Это новый подход к поддержке сайтов, сервисов и приложений с тысячами и миллионами пользователей. Подход зародился в Google, а сейчас распространяется по всему миру. В России SRE внедрили в Яндексе, Mail.ru, Сбербанке, Тинькофф, МТС, Мегафоне и других компаниях.
Инженерами по SRE становятся опытные разработчики и системные администраторы: важно глубокое знание серверных ОС, работы сети, инструментов мониторинга, а также умение программировать. На все эти хард-скиллы накладывается методология SRE — конкретные практики, которые помогают обеспечивать высокую надёжность.
«SRE — это не столько про алертинг и постмортемы. Это про то, чтобы до продакшена не доходил код, который ночью подрывает».
Из общения с инженерами, внедрившими SRE.
Долгое время основным источником знаний об SRE была одноимённая книга от Google. Сейчас есть несколько англоязычных и русскоязычных обучающих программ. Одна из них — интенсив по SRE в Слёрме.
Формат интенсива
Интенсив проходит онлайн и состоит из лекций и практических занятий. Будет трансляция в Zoom и Telegram-чат со спикерами.
Два вида практики. Практические занятия предусмотрены двух видов: настройка по образцу и работа над задачами, решение которых не определено заранее. На интенсиве они называются кейсы.
Командная работа над реальным сервисом. Для работы над кейсами участники интенсива объединяются в команды по 5-8 человек. Каждая команда получает стенд с приложением — несколько VDS, на которых размещён сайт для заказа билетов.
Имитация сбоев. В течение интенсива в работе сайта произойдёт несколько крупных сбоев, и задача команды — найти причину, устранить и предотвратить её повторение. Кейсы основаны на реальном опыте: спикеры собрали проблемы, с которыми сталкивались за свою практику SRE, и создали среду для имитации этих проблем.
Опытные спикеры. Программу интенсива разработали и будут вести:
- Иван Круглов, Staff Software Engineer в Databricks.
- Артём Артемьев, Lead SRE в TangoMe.
- Павел Селиванов, Senior DevOps Engineer в Mail.ru Cloud Solutions.
Поддержка. Объединиться в команды и организовать совместную работу помогут кураторы. В решении сложных задач поддержат спикеры и инженеры техподдержки Слёрма.
Дистанционный формат. Лекции транслируются в Zoom, обсуждение задач происходит в Slack. Все записи лекций сохранятся и будут доступны после интенсива, к ним полезно возвращаться через некоторое время, уже в более спокойной обстановке.
Три дня полного погружения. Интенсив рассчитан на три полных дня, с 10:00 до 18:00 по Московскому времени. Будут небольшие перерывы между лекциями и обед.
Старт 12 ноября. Места ещё есть.
Узнать больше и зарегистрироваться
Ниже полная программа интенсива.
День 1: знакомство с теорией SRE, настройка мониторинга и алертинга
В первый день вы познакомитесь с теорией 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 мск и уходит с ошибкой. В кейсе обсудим важность согласования метрик и научимся смотреть на качество глазами клиента.
Тема 4: SRE онбординг проекта
В крупных компаниях нередко формируют отдельную команду SRE, которая берёт на поддержку сервисы других отделов. Но не каждый сервис готов к тому, чтобы его можно было взять на поддержку. Расскажем, каким требованиям он должен отвечать.
День 2: решение проблем с окружением и архитектурой
Второй день практически полностью построен вокруг решения двух кейсов: проблемы с окружением (здесь будет подробный разбор Health Checking) и проблемы с архитектурой. Спикеры расскажут про работу с постмортерами (post mortem) и дадут шаблоны, которые вы сможете использовать в своей команде.
Тема 5: Health Checking
- Health Check в Kubernetes,
- Жив ли наш сервис?
- Exec probes,
- initialDelaySeconds,
- Secondary Health Port,
- Sidecar Health Server,
- Headless Probe,
- Hardware Probe.
Кейс 3: проблемы с окружением и правильный Healthcheck. Задача Healthcheck — обнаружить неработающий сервис и заблокировать трафик к нему, чтобы пользователи не столкнулись с проблемой. И если вы думаете, что для этого достаточно сделать рутом запрос к сервису и получить ответ, то вы ошибаетесь: даже если сервис ответит, это не гарантирует его работоспособность — проблемы могут быть в окружении. Через этот кейс вы научитесь настраивать корректный Healthcheck и не пускать трафик туда, где он не может быть обработан.
Тема 6: Практика работы с постмортемами — пишем постмортем по предыдущему кейсу и разбираем его со спикерами.
Тема 7: Решение проблем с инфраструктурой
- Мониторинг MySQL,
- SLO/SLI для MySQL,
- Anomaly detection.
Кейс 4: проблемы с БД. База данных тоже может быть источником проблем. Например, если не следить за replication relay, то реплика устареет и приложение будет отдавать старые данные. Причём дебажить такие случаи особенно сложно: сейчас данные рассогласованы, а через несколько секунд уже нет, и в чём причина проблемы — непонятно. Через кейс вы прочувствуете всю боль дебага и узнаете, как предотвращать подобные проблемы.
День 3: traffic shielding и канареечные релизы
Тут два кейса про высокую доступность продакшена: traffic shielding и canary deployment. Вы узнаете об этих подходах и научитесь их применять. Хардкорной настройки руками не планируем, хотя кто знает.
Тема 8: Traffic shielding
- поведение графиков роста кол-ва запросов и бизнес операций
- понятие saturation и capacity planning
- traffic shielding и внедрение rate limiting
- настройка sidecar с rate-limiting на 100 запросов в секунду
Кейс 5: traffic shielding. Когда падает прод? Например, когда мощности рассчитаны на 100 пользователей, а приходит 1000. Вы столкнётесь с подобным кейсом и научитесь делать так, чтобы система не падала целиком, а продолжала обслуживать то количество клиентов, на которое была рассчитана. Блокируя избыточный трафик, вы сохраните возможность системы выполнять задачи для части пользователей.
Тема 9: Canary Deployment
- стратегии деплоя в k8s (Rolling Update vs Recreate),
- canary и blue-green стратегии,
- обзор инструментов для blue-gree/canary release в k8s,
- настройка canary release в GitLab CI/CD,
- пояснение схемы работы canary release,
- внесение изменений в .gitlab-ci.yml.
Кейс 6: проблемы с кодом. Как бы хорошо новые фичи не работали на стейджинге,
всегда есть вероятность, что в продакшене что-то пойдёт не так. Снизить потенциальный ущерб можно, если выкатить обновление только на часть пользователей и предусмотреть возможность быстрого отката назад. Подобный подход называется Canary Deployment, и через практический кейс вы научитесь его применять.
Узнать больше и записаться
