0 added
0 removed
Original
2026-01-01
Modified
2026-02-19
1
<blockquote>12 ноября в "Слёрме" начнётся<a>интенсив по SRE</a>. На три полных дня участники погрузятся в теорию и практику поддержки высоконагруженных сервисов. Никаких задач по работе, никаких семейных дел - только учёба. Под катом рассказываем, что вас ждёт, если решите присоединиться.</blockquote><h2>Справка об SRE</h2>
1
<blockquote>12 ноября в "Слёрме" начнётся<a>интенсив по SRE</a>. На три полных дня участники погрузятся в теорию и практику поддержки высоконагруженных сервисов. Никаких задач по работе, никаких семейных дел - только учёба. Под катом рассказываем, что вас ждёт, если решите присоединиться.</blockquote><h2>Справка об SRE</h2>
2
Site Reliability Engineering (SRE) - обеспечение надёжности информационных систем. Это новый подход к поддержке сайтов, сервисов и приложений с тысячами и миллионами пользователей. Подход зародился в Google, а сейчас распространяется по всему миру. В России SRE внедрили в Яндексе, Mail.ru, Сбербанке, Тинькофф, МТС, Мегафоне и других компаниях.<p>Инженерами по SRE становятся опытные разработчики и системные администраторы: важно глубокое знание серверных ОС, работы сети, инструментов мониторинга, а также умение программировать. На все эти хард-скиллы накладывается методология SRE - конкретные практики, которые помогают обеспечивать высокую надёжность.</p>
2
Site Reliability Engineering (SRE) - обеспечение надёжности информационных систем. Это новый подход к поддержке сайтов, сервисов и приложений с тысячами и миллионами пользователей. Подход зародился в Google, а сейчас распространяется по всему миру. В России SRE внедрили в Яндексе, Mail.ru, Сбербанке, Тинькофф, МТС, Мегафоне и других компаниях.<p>Инженерами по SRE становятся опытные разработчики и системные администраторы: важно глубокое знание серверных ОС, работы сети, инструментов мониторинга, а также умение программировать. На все эти хард-скиллы накладывается методология SRE - конкретные практики, которые помогают обеспечивать высокую надёжность.</p>
3
<blockquote>"SRE - это не столько про алертинг и постмортемы. Это про то, чтобы до продакшена не доходил код, который ночью подрывает".</blockquote>Из общения с инженерами, внедрившими SRE.<p>Долгое время основным источником знаний об SRE была одноимённая книга от Google. Сейчас есть несколько англоязычных и русскоязычных обучающих программ. Одна из них - интенсив по SRE в Слёрме.</p>
3
<blockquote>"SRE - это не столько про алертинг и постмортемы. Это про то, чтобы до продакшена не доходил код, который ночью подрывает".</blockquote>Из общения с инженерами, внедрившими SRE.<p>Долгое время основным источником знаний об SRE была одноимённая книга от Google. Сейчас есть несколько англоязычных и русскоязычных обучающих программ. Одна из них - интенсив по SRE в Слёрме.</p>
4
<h2>Формат интенсива</h2>
4
<h2>Формат интенсива</h2>
5
Интенсив проходит онлайн и состоит из лекций и практических занятий. Будет трансляция в Zoom и Telegram-чат со спикерами.<p><strong>Два вида практики.</strong> Практические занятия предусмотрены двух видов: настройка по образцу и работа над задачами, решение которых не определено заранее. На интенсиве они называются <em>кейсы</em>.</p>
5
Интенсив проходит онлайн и состоит из лекций и практических занятий. Будет трансляция в Zoom и Telegram-чат со спикерами.<p><strong>Два вида практики.</strong> Практические занятия предусмотрены двух видов: настройка по образцу и работа над задачами, решение которых не определено заранее. На интенсиве они называются <em>кейсы</em>.</p>
6
<p><strong>Командная работа над реальным сервисом.</strong> Для работы над кейсами участники интенсива объединяются в команды по 5-8 человек. Каждая команда получает стенд с приложением - несколько VDS, на которых размещён <strong>сайт для заказа билетов</strong>.</p>
6
<p><strong>Командная работа над реальным сервисом.</strong> Для работы над кейсами участники интенсива объединяются в команды по 5-8 человек. Каждая команда получает стенд с приложением - несколько VDS, на которых размещён <strong>сайт для заказа билетов</strong>.</p>
7
<em>Сервис заказа билетов, стабильную работу которого будут обеспечивать участники интенсива</em><p><strong>Имитация сбоев.</strong> В течение интенсива в работе сайта произойдёт несколько крупных сбоев, и задача команды - найти причину, устранить и предотвратить её повторение. Кейсы основаны на реальном опыте: спикеры собрали проблемы, с которыми сталкивались за свою практику SRE, и создали среду для имитации этих проблем.</p>
7
<em>Сервис заказа билетов, стабильную работу которого будут обеспечивать участники интенсива</em><p><strong>Имитация сбоев.</strong> В течение интенсива в работе сайта произойдёт несколько крупных сбоев, и задача команды - найти причину, устранить и предотвратить её повторение. Кейсы основаны на реальном опыте: спикеры собрали проблемы, с которыми сталкивались за свою практику SRE, и создали среду для имитации этих проблем.</p>
8
<p><strong>Опытные спикеры.</strong> Программу интенсива разработали и будут вести:</p>
8
<p><strong>Опытные спикеры.</strong> Программу интенсива разработали и будут вести:</p>
9
<ul><li>Иван Круглов, Staff Software Engineer в Databricks.</li>
9
<ul><li>Иван Круглов, Staff Software Engineer в Databricks.</li>
10
<li>Артём Артемьев, Lead SRE в TangoMe.</li>
10
<li>Артём Артемьев, Lead SRE в TangoMe.</li>
11
<li>Павел Селиванов, Senior DevOps Engineer в Mail.ru Cloud Solutions.</li>
11
<li>Павел Селиванов, Senior DevOps Engineer в Mail.ru Cloud Solutions.</li>
12
</ul><strong>Поддержка.</strong> Объединиться в команды и организовать совместную работу помогут кураторы. В решении сложных задач поддержат спикеры и инженеры техподдержки Слёрма.<p><strong>Дистанционный формат. </strong>Лекции транслируются в Zoom, обсуждение задач происходит в Slack. Все записи лекций сохранятся и будут доступны после интенсива, к ним полезно возвращаться через некоторое время, уже в более спокойной обстановке.</p>
12
</ul><strong>Поддержка.</strong> Объединиться в команды и организовать совместную работу помогут кураторы. В решении сложных задач поддержат спикеры и инженеры техподдержки Слёрма.<p><strong>Дистанционный формат. </strong>Лекции транслируются в Zoom, обсуждение задач происходит в Slack. Все записи лекций сохранятся и будут доступны после интенсива, к ним полезно возвращаться через некоторое время, уже в более спокойной обстановке.</p>
13
<p><strong>Три дня полного погружения.</strong> Интенсив рассчитан на три полных дня, с 10:00 до 18:00 по Московскому времени. Будут небольшие перерывы между лекциями и обед.</p>
13
<p><strong>Три дня полного погружения.</strong> Интенсив рассчитан на три полных дня, с 10:00 до 18:00 по Московскому времени. Будут небольшие перерывы между лекциями и обед.</p>
14
<p>Старт 12 ноября. Места ещё есть.</p>
14
<p>Старт 12 ноября. Места ещё есть.</p>
15
<p><a>Узнать больше и зарегистрироваться</a></p>
15
<p><a>Узнать больше и зарегистрироваться</a></p>
16
<p>Ниже полная программа интенсива.</p>
16
<p>Ниже полная программа интенсива.</p>
17
<h2>День 1: знакомство с теорией SRE, настройка мониторинга и алертинга</h2>
17
<h2>День 1: знакомство с теорией SRE, настройка мониторинга и алертинга</h2>
18
В первый день вы познакомитесь с теорией SRE, научитесь настраивать мониторинг и алертинг, а также объединитесь в команду с другими участниками интенсива.<p>Расскажем про метрики SLO, SLI, SLA и как они соотносятся с требованиями бизнеса. Поделимся Best Practices по настройке мониторинга и правилами для пожарной команды. Дадим первые практические кейсы.</p>
18
В первый день вы познакомитесь с теорией SRE, научитесь настраивать мониторинг и алертинг, а также объединитесь в команду с другими участниками интенсива.<p>Расскажем про метрики SLO, SLI, SLA и как они соотносятся с требованиями бизнеса. Поделимся Best Practices по настройке мониторинга и правилами для пожарной команды. Дадим первые практические кейсы.</p>
19
<p><strong>Тема 1: Мониторинг</strong></p>
19
<p><strong>Тема 1: Мониторинг</strong></p>
20
<ul><li>Зачем нужен мониторинг,</li>
20
<ul><li>Зачем нужен мониторинг,</li>
21
<li>Symptoms vs Causes,</li>
21
<li>Symptoms vs Causes,</li>
22
<li>Black-Box vs. White-Box Monitoring,</li>
22
<li>Black-Box vs. White-Box Monitoring,</li>
23
<li>Golden Signals,</li>
23
<li>Golden Signals,</li>
24
<li>Перцентили,</li>
24
<li>Перцентили,</li>
25
<li>Alerting,</li>
25
<li>Alerting,</li>
26
<li>Observability.</li>
26
<li>Observability.</li>
27
</ul>Практика: Делаем базовый дашборд и настраиваем необходимые алерты.<p><strong>Тема 2: Теория SRE</strong></p>
27
</ul>Практика: Делаем базовый дашборд и настраиваем необходимые алерты.<p><strong>Тема 2: Теория SRE</strong></p>
28
<ul><li>SLO, SLI, SLA,</li>
28
<ul><li>SLO, SLI, SLA,</li>
29
<li>Durability,</li>
29
<li>Durability,</li>
30
<li>Error budget.</li>
30
<li>Error budget.</li>
31
</ul>Практика: Добавляем на дашборд SLO/SLI + алерты.Практика: Первая нагрузка системы.<blockquote>Кейс 1: downstream-зависимость. В большой системе существует много взаимозависимых сервисов, и не всегда они работают одинаково хорошо. Особенно обидно, когда с вашим сервисом порядок, а соседний, от которого вы зависите, периодически уходит в down. Учебный проект окажется именно в таких условиях, а вы сделаете так, чтобы он все равно выдавал качество на максимально возможном уровне.</blockquote><strong>Тема 3: Управление инцидентами</strong><ul><li>Resiliencе Engineering,</li>
31
</ul>Практика: Добавляем на дашборд SLO/SLI + алерты.Практика: Первая нагрузка системы.<blockquote>Кейс 1: downstream-зависимость. В большой системе существует много взаимозависимых сервисов, и не всегда они работают одинаково хорошо. Особенно обидно, когда с вашим сервисом порядок, а соседний, от которого вы зависите, периодически уходит в down. Учебный проект окажется именно в таких условиях, а вы сделаете так, чтобы он все равно выдавал качество на максимально возможном уровне.</blockquote><strong>Тема 3: Управление инцидентами</strong><ul><li>Resiliencе Engineering,</li>
32
<li>Как выстраивается пожарная бригада,</li>
32
<li>Как выстраивается пожарная бригада,</li>
33
<li>Насколько ваша команда эффективна в инциденте,</li>
33
<li>Насколько ваша команда эффективна в инциденте,</li>
34
<li>7 правил для лидера инцидента,</li>
34
<li>7 правил для лидера инцидента,</li>
35
<li>5 правил для пожарного,</li>
35
<li>5 правил для пожарного,</li>
36
<li>HiPPO - highest paid person's opinion. Communications Leader.</li>
36
<li>HiPPO - highest paid person's opinion. Communications Leader.</li>
37
</ul><blockquote>Кейс 2: upstream-зависимость. Одно дело, когда вы зависите от сервиса с низким SLO. Другое дело, когда ваш сервис является таковым для других частей системы. Так бывает, если критерии оценки не согласованы: например, вы отвечаете на запрос в течение секунды и считаете это успехом, а зависимый сервис ждёт всего 500 мск и уходит с ошибкой. В кейсе обсудим важность согласования метрик и научимся смотреть на качество глазами клиента.</blockquote><strong>Тема 4: SRE онбординг проекта</strong>В крупных компаниях нередко формируют отдельную команду SRE, которая берёт на поддержку сервисы других отделов. Но не каждый сервис готов к тому, чтобы его можно было взять на поддержку. Расскажем, каким требованиям он должен отвечать.<h2>День 2: решение проблем с окружением и архитектурой</h2>
37
</ul><blockquote>Кейс 2: upstream-зависимость. Одно дело, когда вы зависите от сервиса с низким SLO. Другое дело, когда ваш сервис является таковым для других частей системы. Так бывает, если критерии оценки не согласованы: например, вы отвечаете на запрос в течение секунды и считаете это успехом, а зависимый сервис ждёт всего 500 мск и уходит с ошибкой. В кейсе обсудим важность согласования метрик и научимся смотреть на качество глазами клиента.</blockquote><strong>Тема 4: SRE онбординг проекта</strong>В крупных компаниях нередко формируют отдельную команду SRE, которая берёт на поддержку сервисы других отделов. Но не каждый сервис готов к тому, чтобы его можно было взять на поддержку. Расскажем, каким требованиям он должен отвечать.<h2>День 2: решение проблем с окружением и архитектурой</h2>
38
Второй день практически полностью построен вокруг решения двух кейсов: проблемы с окружением (здесь будет подробный разбор Health Checking) и проблемы с архитектурой. Спикеры расскажут про работу с постмортерами (post mortem) и дадут шаблоны, которые вы сможете использовать в своей команде.<p><strong>Тема 5: Health Checking</strong></p>
38
Второй день практически полностью построен вокруг решения двух кейсов: проблемы с окружением (здесь будет подробный разбор Health Checking) и проблемы с архитектурой. Спикеры расскажут про работу с постмортерами (post mortem) и дадут шаблоны, которые вы сможете использовать в своей команде.<p><strong>Тема 5: Health Checking</strong></p>
39
<ul><li>Health Check в Kubernetes,</li>
39
<ul><li>Health Check в Kubernetes,</li>
40
<li>Жив ли наш сервис?</li>
40
<li>Жив ли наш сервис?</li>
41
<li>Exec probes,</li>
41
<li>Exec probes,</li>
42
<li>initialDelaySeconds,</li>
42
<li>initialDelaySeconds,</li>
43
<li>Secondary Health Port,</li>
43
<li>Secondary Health Port,</li>
44
<li>Sidecar Health Server,</li>
44
<li>Sidecar Health Server,</li>
45
<li>Headless Probe,</li>
45
<li>Headless Probe,</li>
46
<li>Hardware Probe.</li>
46
<li>Hardware Probe.</li>
47
</ul><blockquote>Кейс 3: проблемы с окружением и правильный Healthcheck. Задача Healthcheck - обнаружить неработающий сервис и заблокировать трафик к нему, чтобы пользователи не столкнулись с проблемой. И если вы думаете, что для этого достаточно сделать рутом запрос к сервису и получить ответ, то вы ошибаетесь: даже если сервис ответит, это не гарантирует его работоспособность - проблемы могут быть в окружении. Через этот кейс вы научитесь настраивать корректный Healthcheck и не пускать трафик туда, где он не может быть обработан.</blockquote><strong>Тема 6: Практика работы с постмортемами</strong> - пишем постмортем по предыдущему кейсу и разбираем его со спикерами.<p><strong>Тема 7: Решение проблем с инфраструктурой</strong></p>
47
</ul><blockquote>Кейс 3: проблемы с окружением и правильный Healthcheck. Задача Healthcheck - обнаружить неработающий сервис и заблокировать трафик к нему, чтобы пользователи не столкнулись с проблемой. И если вы думаете, что для этого достаточно сделать рутом запрос к сервису и получить ответ, то вы ошибаетесь: даже если сервис ответит, это не гарантирует его работоспособность - проблемы могут быть в окружении. Через этот кейс вы научитесь настраивать корректный Healthcheck и не пускать трафик туда, где он не может быть обработан.</blockquote><strong>Тема 6: Практика работы с постмортемами</strong> - пишем постмортем по предыдущему кейсу и разбираем его со спикерами.<p><strong>Тема 7: Решение проблем с инфраструктурой</strong></p>
48
<ul><li>Мониторинг MySQL,</li>
48
<ul><li>Мониторинг MySQL,</li>
49
<li>SLO/SLI для MySQL,</li>
49
<li>SLO/SLI для MySQL,</li>
50
<li>Anomaly detection.</li>
50
<li>Anomaly detection.</li>
51
</ul><blockquote>Кейс 4: проблемы с БД. База данных тоже может быть источником проблем. Например, если не следить за replication relay, то реплика устареет и приложение будет отдавать старые данные. Причём дебажить такие случаи особенно сложно: сейчас данные рассогласованы, а через несколько секунд уже нет, и в чём причина проблемы - непонятно. Через кейс вы прочувствуете всю боль дебага и узнаете, как предотвращать подобные проблемы.</blockquote><h2>День 3: traffic shielding и канареечные релизы</h2>
51
</ul><blockquote>Кейс 4: проблемы с БД. База данных тоже может быть источником проблем. Например, если не следить за replication relay, то реплика устареет и приложение будет отдавать старые данные. Причём дебажить такие случаи особенно сложно: сейчас данные рассогласованы, а через несколько секунд уже нет, и в чём причина проблемы - непонятно. Через кейс вы прочувствуете всю боль дебага и узнаете, как предотвращать подобные проблемы.</blockquote><h2>День 3: traffic shielding и канареечные релизы</h2>
52
Тут два кейса про высокую доступность продакшена: traffic shielding и canary deployment. Вы узнаете об этих подходах и научитесь их применять. Хардкорной настройки руками не планируем, хотя кто знает.<p><strong>Тема 8: Traffic shielding</strong></p>
52
Тут два кейса про высокую доступность продакшена: traffic shielding и canary deployment. Вы узнаете об этих подходах и научитесь их применять. Хардкорной настройки руками не планируем, хотя кто знает.<p><strong>Тема 8: Traffic shielding</strong></p>
53
<ul><li>поведение графиков роста кол-ва запросов и бизнес операций</li>
53
<ul><li>поведение графиков роста кол-ва запросов и бизнес операций</li>
54
<li>понятие saturation и capacity planning</li>
54
<li>понятие saturation и capacity planning</li>
55
<li>traffic shielding и внедрение rate limiting</li>
55
<li>traffic shielding и внедрение rate limiting</li>
56
<li>настройка sidecar с rate-limiting на 100 запросов в секунду</li>
56
<li>настройка sidecar с rate-limiting на 100 запросов в секунду</li>
57
</ul><blockquote>Кейс 5: traffic shielding. Когда падает прод? Например, когда мощности рассчитаны на 100 пользователей, а приходит 1000. Вы столкнётесь с подобным кейсом и научитесь делать так, чтобы система не падала целиком, а продолжала обслуживать то количество клиентов, на которое была рассчитана. Блокируя избыточный трафик, вы сохраните возможность системы выполнять задачи для части пользователей.</blockquote><strong>Тема 9: Canary Deployment</strong><ul><li>стратегии деплоя в k8s (Rolling Update vs Recreate),</li>
57
</ul><blockquote>Кейс 5: traffic shielding. Когда падает прод? Например, когда мощности рассчитаны на 100 пользователей, а приходит 1000. Вы столкнётесь с подобным кейсом и научитесь делать так, чтобы система не падала целиком, а продолжала обслуживать то количество клиентов, на которое была рассчитана. Блокируя избыточный трафик, вы сохраните возможность системы выполнять задачи для части пользователей.</blockquote><strong>Тема 9: Canary Deployment</strong><ul><li>стратегии деплоя в k8s (Rolling Update vs Recreate),</li>
58
<li>canary и blue-green стратегии,</li>
58
<li>canary и blue-green стратегии,</li>
59
<li>обзор инструментов для blue-gree/canary release в k8s,</li>
59
<li>обзор инструментов для blue-gree/canary release в k8s,</li>
60
<li>настройка canary release в GitLab CI/CD,</li>
60
<li>настройка canary release в GitLab CI/CD,</li>
61
<li>пояснение схемы работы canary release,</li>
61
<li>пояснение схемы работы canary release,</li>
62
<li>внесение изменений в .gitlab-ci.yml.</li>
62
<li>внесение изменений в .gitlab-ci.yml.</li>
63
</ul><blockquote>Кейс 6: проблемы с кодом. Как бы хорошо новые фичи не работали на стейджинге,</blockquote><blockquote>всегда есть вероятность, что в продакшене что-то пойдёт не так. Снизить потенциальный ущерб можно, если выкатить обновление только на часть пользователей и предусмотреть возможность быстрого отката назад. Подобный подход называется Canary Deployment, и через практический кейс вы научитесь его применять.</blockquote><a>Узнать больше и записаться</a>
63
</ul><blockquote>Кейс 6: проблемы с кодом. Как бы хорошо новые фичи не работали на стейджинге,</blockquote><blockquote>всегда есть вероятность, что в продакшене что-то пойдёт не так. Снизить потенциальный ущерб можно, если выкатить обновление только на часть пользователей и предусмотреть возможность быстрого отката назад. Подобный подход называется Canary Deployment, и через практический кейс вы научитесь его применять.</blockquote><a>Узнать больше и записаться</a>