company_banner

Think SRE: смотрим на проекты глазами SRE-инженера

    В отзывах о Слёрме Kubernetes звучала фраза: «Kubernetes оказался проще, чем я думал». Сейчас уже не звучит, мифа о сложности k8s больше нет. Он перешел в разряд инструментов easy to learn, hard to master.


    Мы хотим повторить то же самое с SRE. Показать, что SRE проще и понятнее, чем кажется. Сдвинуть парадигму: дать людям посмотреть на проект глазами инженера SRE.


    Как всегда на старте, в уравнении много неизвестных. И как всегда на старте, самое интересное достанется первым.



    3-5 февраля мы проводим в Москве Слёрм SRE. Билет на трехдневный интенсив стоит 60 тысяч. Что же участник получит за свои деньги?


    Когда я рассказываю друзьям и коллегам про SRE, я встречаю здоровый скептицизм:


    • Впервые слышу про SRE, это какая-то алхимия.
    • Внедрить SRE сложно, это для гигантов вроде Гугла.
    • Это дорого и долго, не дадут времени, не выделят бюджет.
    • То, что вы описываете, слишком хорошо, чтобы быть правдой.

    Эти вопросы я хочу разобрать.


    Пора узнать, что такое SRE


    На уровне лозунгов: SRE — это одна из имплементаций DevOps. Она появилась 10+ лет назад в Google, но только недавно стала проникать на «обычный» рынок, в первую очередь благодаря книге Site Reliability Engeneering, выпущенной Google в 2016 году.


    О связи SRE и DevOps хорошо рассказано в этом видео:



    Плохо то, что лозунги — ни о чём. Ну DevOps, ну имплементация, очередное «за всё хорошее против всего плохого».


    Можно прочитать книгу (и стоит это сделать). Но читатель окажется в положении человека, изучающего каратэ по рисункам. Книга описывает концепцию без приложения к реальности. Преподаватель ведет за руку по конкретному пути и в процессе указывает на ошибки.


    В цену входит быстрый и глубокий обзор подхода и инструментов SRE.


    Внедрить SRE проще, чем кажется


    На Слёрме мы будем щупать SRE руками: выберем метрики, настроим их измерение, алерты, столкнемся с инцидентами, решим и разберем их, перестроим проект по всем канонам SRE.


    То есть дадим пошаговую инструкцию, которую можно внедрить у себя по возвращении с интенсива.


    Вру. По сути мы дадим не инструкцию, а образец, с которого можно срисовать кучу идей и решений.


    В цену входит образец для внедрения.


    Главная проблема в том, что вам предстоит убеждать тех, кто не был на Слёрме. Поэтому в идеале стоит прийти на интенсив всей командой. Поэтому мы даем большие скидки для групп.


    Хорошо бы на Слёрм прийти во главе с СТО. И СЕО тоже полезно, и об этом раздел…


    … как убедить топ-менеджмент, что SRE полезен и нужен.


    Обычно между СЕО (топ-менеджментом), СТО (IT-менеджментом), разработчиками и эксплуатацией есть конфликт задач.


    Я намеренно не говорю «конфликт интересов», это именно конфликт задач.


    СЕО нужны финансовые показатели. СТО — понятная, управляемая и по возможности комфортная ситуация. То есть понятные таски с понятным бизнес-велью, соблюдение сроков, нормальный стек, больше фич и меньше факапов. Разработчикам нужно выкатывать больше фич, а эксплуатации — обеспечить доступность (что явно конфликтует с «больше фич»).


    SRE говорит, что у всех участников процесса есть единая задача: счастье пользователя. Пользователя делает счастливым здоровый баланс между новыми фичами и надежностью сервиса. Счастливый пользователь платит больше денег. Для управления счастьем пользователя нужен специализированный инструментарий.


    Более того, SRE, будучи основан на метриках, позволяет переводить финансовые показатели в целевые показатели различных метрик, а их в свою очередь — в задачи DevOps-команд.


    Позволяет переводить — это я преувеличил. Наличие этих метрик позволяет найти взаимосвязи между состоянием метрик и финансовыми показателями. Это отдельная большая, но понятная задача.


    Есть проект DORA, DevOps Research & Assessments, он выпускает ежегодные исследования по ценности для бизнеса и ROI DevOps и его подкласса SRE. Мы сейчас переводим актуальный отчет на русский язык. Там есть оценочные формулы, которые с известной степенью точности можно применить к вашей компании.


    Резюме: SRE дает бизнесу возможность управлять финансовыми показателями, устанавливая целевые показатели метрик, а DevOps-команда, глядя на текущие значения метрик, однозначно понимает, чем сейчас нужно заниматься с максимальной пользой для финансовых показателей. Какой СЕО откажется от такого инструмента?


    Получить ресурсы на внедрение SRE вполне реально.


    В цену курса входит набор доводов в пользу перехода на SRE и DevOps.


    И даже в маленьких компаниях есть место SRE.


    SRE делится на инструменты, культуру и организационную структуру.


    Часть инструментов, например, Service Mesh, нужны для больших и сложных проектов. Но те же retry, backoff, failure injection, graceful degradation можно внедрять и в малых проектах, и дают они громадную отдачу.


    Культура тоже полезна в любой компании. Классический администратор, настраивая Prometheus, будет действовать по стандарту: включит мониторинг потребления памяти и диска, и другие привычные мониторинги. SRE-инженер сперва пойдет обсуждать с бизнесом ключевые показатели бизнес-процессов, а затем настроит их мониторинг. Сразу видно, что культура SRE-инжиниринга полезна даже в микро-стартапе.


    А вот организационная структура в маленьких компаниях, наверно, не нужна и даже вредна. Когда все сотрудники — универсалы, не надо принудительно выделять SRE-команды.


    Все, что мы описываем, уже работает


    Курс создан теми, кто давно внедрил SRE у себя в командах и давно живет в этой парадигме. Иван Круглов и Бен Тайлер, оба — Principal Developer в Booking.com. Евгений Варавва, разработчик широкого профиля в Google. Эдуард Медведев, CTO в Tungsten Labs, выросший из SRE-инженера.


    Эдуард проводит вебинар «SRE — хайп или будущее?» 12 декабря в 11:00.


    О программе


    Что касается программы. Я уже получаю фидбек экспертов, что программа «не бьётся»: она слишком широкая и местами нелогичная. Это действительно так.


    По сути у нас есть каркас программы, набор идей, которые мы хотим раскрыть. У нас впереди два месяца напряженной работы, по мере подготовки программа будет уточняться: уберем лишнее, уточним оставшееся.


    Но уже в текущем виде программа ясно показывает направление, в котором мы работаем.


    Программа Слёрма SRE

    Тема №1: Основные принципы и методы SRE


    • Что нужно чтобы стать SRE?
    • DevOps vs SRE
    • Почему разработчики ценят SRE и очень грустят, когда в проекте их нет
    • SLI, SLO и SLA
    • Error budget и его роль в SRE

    Тема №2: Дизайн распределенных систем


    • Архитектура и функционал приложения
    • Non-Abstract Large System Design
    • Operability / Design for failure
    • gRPC или REST
    • Версионирование и обратная совместимость

    Тема №3: Как принимают проект SRE


    • Лучшие практики от SRE
    • Чек-лист приема проекта
    • Логирование, метрики, трейсинг
    • Забираем CI/CD в свои руки

    Тема №4: Проектирование и запуск распределенной системы


    • Обратное проектирование — как работает система?
    • Согласовываем SLI и SLO
    • Практика capacity planning
    • Запуск трафика на приложение, наши пользователи начинают им «пользоваться»
    • Запускаем Prometheus, Grafana, Elastic

    Тема №5: Monitoring, Observability and Alerting


    • Monitoring vs. Observability
    • Настраиваем мониторинг и алертинг с Prometheus
    • Практический мониторинг SLI и SLO
    • Symptoms vs. Causes
    • Black-Box vs. White-Box Monitoring
    • Распределенный мониторинг доступности приложений и серверов
    • 4 золотых сигнала (обнаружение аномалий)

    Тема №6: Практика тестирования надежности систем


    • Работа под давлением
    • Failure-injection
    • Chaos Monkey

    Тема №7: Практика incident response


    • Алгоритм управления стрессом
    • Взаимодействие между участниками инцидента
    • Постмортем
    • Knowledge sharing
    • Формирование культуры
    • Контроль неисправностей
    • Проведение blameless разбора полетов

    Тема №8: Практика управления нагрузкой


    • Балансировка нагрузки
    • Отказоустойчивость приложений: retry, timeout, failure injection, circuit breaker
    • DDoS (создаем нагрузку) + Cascading Failures

    Тема №9: Реагирование на инциденты


    • Разбор полетов
    • Практика On-Call
    • Различные типы аварий (тестирование, изменение конфигурации, сбой оборудования)
    • Протоколы управления инцидентами

    Тема №10: Диагностика и решение проблем


    • Журналирование
    • Отладка
    • Практика анализа и отладки на нашем приложении

    Тема №11: Тестирование надежности систем


    • Нагрузочное тестирование
    • Тестирование конфигураций
    • Тестирование производительности
    • Canary release

    Тема №12: Самостоятельная работа и ревью


    Стоит ли все вышеперечисленное своих денег?


    PS. При чем тут хаб Kubernetes


    Вся практика выполняется в Kubernetes. Тем, кто владеет Kubernetes, прямая дорога в SRE-инженеры. Тем, кто не владеет — на наши курсы по Kubernetes.


    Регистрация на Слёрм SRE

    Southbridge
    352,13
    Обеспечиваем стабильную работу highload-проектов
    Поделиться публикацией

    Комментарии 0

    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

    Самое читаемое