Русский
Русский
English
Статистика
Реклама

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

Узнать больше и записаться
Источник: habr.com
К списку статей
Опубликовано: 12.05.2021 14:11:23
0

Сейчас читают

Комментариев (0)
Имя
Электронная почта

Блог компании southbridge

Программирование

It-инфраструктура

Учебный процесс в it

Devops

Слёрм

Sre

Карьера в it-индустрии

Обучение

Site reliability engineer

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru