«SRE — это не только про алертинг и постмортемы, а ещё про то, чтобы до продакшена не доходил код, который будит ночью»

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.


21 мая в «Слёрме» начнётся интенсив по 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 по Московскому времени. Будут небольшие перерывы между лекциями и обед.

Старт 21 мая. Места ещё есть.

Узнать больше и зарегистрироваться

Ниже полная программа интенсива.

День 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, и через практический кейс вы научитесь его применять.

Узнать больше и записаться
Источник: https://habr.com/ru/company/southbridge/blog/556800/


Интересные статьи

Интересные статьи

Саммари Неэффективные сотрудники в вашей команде могут и не подозревать, что у них завышенные представления о своей продуктивности. Че...
Анимация в KAPIA Добрый день! Меня зовут Павел. Я являюсь программистом и аниматором маленькой семейной команды по разработке игр. Я и моя жена делаем 3Д адвенчуру в постапокалип...
Точное предсказание будущих событий — перспективная и интересная задача во многих сферах: от прогноза погоды до финтеха (котировки акций, курсы валют). Машинное обучение уже сегодня позволяет зна...
Периодически мне в разных вариантах задают вопрос, который «в среднем» звучит так: «что лучше: заказать интернет-магазин на бесплатной CMS или купить готовое решение на 1С-Битрикс и сделать магазин на...
Здравствуйте. Я уже давно не пишу на php, но то и дело натыкаюсь на интернет-магазины на системе управления сайтами Битрикс. И я вспоминаю о своих исследованиях. Битрикс не любят примерно так,...