company_banner

Слёрм SRE. Сплошной эксперимент c экспертами из Booking.com и Google.com

    Наша команда любит эксперименты. Каждый Слёрм — это не статичное повторение предыдущих, а осмысление опыта и переход от хорошего к лучшему. Но со Слёрмом SRE мы решили применить абсолютно новый формат — дать участникам условия, максимально приближённые к «боевым».


    Если кратко обрисовать, чем мы занимались на интенсиве: «Строим, ломаем, чиним,
    изучаем». SRE мало чего стоит в голой теории — только практика, реальные решения, реальные проблемы.


    Участники были поделены на команды, чтобы бодрый соревновательный дух не дал никому заснуть или запустить «Angry Birds» на iPhone по примеру Дмитрия Анатольевича.


    Проблемы, глюки, баги и задачи обеспечивали участникам четыре ментора. Иван Круглов, Principal Developer в Booking.com (Нидерланды). Бен Тайлер, Principal Developer в Booking.com (США). Эдуард Медведев, CTO в Tungsten Labs (Германия). Евгений Варавва, разработчик широкого профиля в Google (Сан-Франциско).


    Да ещё и участники поделены на команды — и соревнуются друг с другом. Интересно?



    Иван, Бен, Эдуард и Евгений с добрым ленинским прищуром смотрят на бедных участников Слёрм SRE перед началом соревнования.


    Итак задача:


    Мы наш, мы новый мир построим...


    Есть сайт-агрегатор билетов в кино. Инциденты придумывают менторы в заранее проработанном сценарии (хотя никто не исключает особо изысканную и коварную импровизацию), работоспособность сайта описывается различными метриками. Проблемы могут быть самыми разными: билеты театра «Мулен Руж» не подгружаются в базу; постеры фильмов и спектаклей подгружаются в базу более, чем за 10 секунд; описание отдельного фильма подвисает; 0,1% заказов попадают уже на зарезервированные места; периодически на сладкое отваливается на минуту-две система обработки платежей. И многое-многое-многое неприятное, что может свалиться на участника Слёрма SRE на его реальной работе.



    Мы готовы справиться со всем… и со всеми.


    Наш многострадальный сайт состоит из нескольких микросервисов. Его задача — агрегация данных о сеансах, ценах и свободных местах со всех кинотеатров, он показывает анонсы фильмов, дает выбрать кинотеатр, сеанс, зал и место, забронировать и оплатить билеты. В общем, всё, о чём зритель может только мечтать. Только вот пользователь даже не подозревает, какая титаническая борьба за стабильность и доступность сайта идёт внутри.


    Для сайта на интенсиве мы сформировали показатели SLO, SLI, SLA, разработали архитектуру и инфраструктуру, задеплоили сайт, настроили мониторинг и алертинг. И понеслось.


    SLO, SLI, SLA
    SLI — индикаторы уровня обслуживания. SLO — цели уровня обслуживания. SLA — соглашения об уровне обслуживания.

    SLA — термин методологии ITIL, обозначающий формальный договор между заказчиком услуги и её поставщиком, содержащий описание услуги, права и обязанности сторон и, самое главное, согласованный уровень качества предоставления данной услуги.

    SLO — это цель уровня обслуживания: целевое значение или диапазон значений для уровня обслуживания, который измеряется SLI. Нормальным значением для SLO является «SLI ≤ целевого значения» или «нижняя граница ≤ SLI ≤ верхняя граница».

    SLI является индикатором уровня обслуживания — тщательно определенной количественной мерой одного из аспектов предоставляемого уровня обслуживания. Для большинства сервисов в качестве ключевого SLI считают задержку запроса — сколько времени требуется для возврата ответа на запрос. Другие распространенные SLI включают частоту ошибок, часто выражаемую как долю всех полученных запросов, и пропускную способность системы, обычно измеряемую в запросах в секунду.

    Первым делом мы сломаем самолёты, ну а девушек, а девушек потом...


    Внутренние и внешние факторы с первых же минут начали «портить» SLO. Свалилось на голову админам всё — и ошибки разработчиков, и отказы инфраструктуры, и наплыв посетителей, и DDoS-атаки. Всё то, что ухудшает SLO.



    «- Дорогие участники, спешу вас порадовать, первым делом у вас падает… всё!»


    По ходу дела спикеры разбирали устойчивость, error budget, практику тестирования, управление прерываниями и операционной нагрузкой.


    Не кочегары мы, не плотники...


    Тут участники начали чинить — главное понять, за что хвататься первым.



    «- Господи, я никогда не видел, чтобы это ломалось так, в таком виде и в такой позе!»


    Итак, произошла авария. Сервис обработки платежей лег. Как действовать, чтобы восстановить работоспособность в минимальные сроки?



    Эксперты ласково поглядывая на участников готовят очередную каверзу.


    Каждая команда организует работу группы по ликвидации аварии — подключает коллег, оповещает интересантов (stakeholders). Заодно выстраиваются приоритеты. Так участники тренировались работать под давлением в условиях предельно ограниченного времени.



    «- Это что за ужас вылез?!»


    Выдохнули… и закончили упражнение


    Вместе со спикерами после каждой решённой проблемы и временно стабилизированного сайта команды изучала инциденты с точки зрение SRE. Детально анализировали проблемы — причины возникновения, ход устранения. После этого как покомандно, так и коллективно принимали решение по их дальнейшему предотвращению: как улучшить мониторинг, как грамотно изменить архитектуру, как откорректировать подход к разработке и эксплуатации, как исправить регламенты. Спикеры продемонстрировали практику проведения post-mortem.



    «- Кто ещё хочет мучений! — Я!»


    На электронном табло строго и чётко фиксировались успехи команд.



    За первые места — премия от стейкхолдеров.


    Southbridge
    Обеспечиваем стабильную работу highload-проектов

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

      0
      Классный подход и было бы интересно принять участие в таком тренинге онлайн.
        0

        А что такое Слерм?

          +2
          Впечатления довольно смешанные. По теории — всё отлично, хорошо подано и полезно. Многое знал, но это уже сам виноват :)
          По практики — отличный хакатон. Получил огромное удовольствие от решения задач, они хорошо встроены в курс, всё ломается внезапно. Но задачи наглухо синтетические и я не могу представить подобных проблем в реальных условиях.
          Не могу представить, что бы SRE/Ops команда полезла в мастер ветку править код приложения на проде, что бы починить аварию.
          В общем вся практика выглядит как набор ситуаций, которых могут произойти только при фантастически всратом IT менеджменте.
          Но, повторюсь, как хакатон — всё очень круто.
            0
            А в чем проблема залезть в мастер если это авария что уже можно говорить о нестандартной ситуации, которая не решается существующими процедурами? Это потом можно провести анализ и написать новую инструкцию для такого рода аварий, но первично они могут произойти и их как-то нужно решить, а не витать в облаках насчёт того что факапы бывают только в плохих компаниях :)
              +1
              Факапы факапам рознь. В задачах были факапы вида «вы не знаете архитектуру своего приложения, кругом чёрные ящики и один чёрный ящик ВНЕЗАПНО поменял логику взаимодействия с единственным компонентом, к которому вы имеете доступ».
              Ну и решение — править код со своей стороны.

              Моё главное недовольство тут даже не в том, ВНЕЗАПНО, а в том, что в реальности код приложения был бы не десятки строк, а сотни или даже тысячи. И не зная его, что-то там поправить было бы долго и опасно. Гораздо быстрее и правильнее — срочно пинать разработчиков, причем обоих сервисов.
                0

                Это конечно хорошо что sre на всех руки мастера но кмк откатить надо было тот чёрный ящик который внезапно поменял логику и никак иначе.

                  +1
                  Откатывать надо тоже с умом. В общем случае релизы не всегда обратно совместимы и надо уточнять у разработчиков, возможно ли откатиться.
                  А в рамках задачи — о существовании этого чёрного ящика мы узнали только когда он сломался :)
            0
            Первым делом мы сломаем самолёты, ну а девушек, а девушек потом

            И в оригинале, и в контексте тут не «сломаем».

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

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