company_banner

Google и DevOps: две книги про SRE

    Первые десять лет в Гугле я работал обычным инженером: запускал на картах общественный транспорт, улучшал поиск и отлавливал спам в ютьюбе. В какой-то момент обнаружилось, что по соседству с командами SWE (Software Engineers) существуют какие-то загадочные SRE (Site Reliability Engineers), которые живут в продакшене и всё знают про инфраструктуру, конфиги и мониторинг. Обычно они приходили к нам с непонятными графиками и настойчиво рекомендовали что-нибудь переписать в нашем сервисе, чтобы он взрывался аккуратно и по кусочкам, а не целиком и вместе со всеми соседями. Или строили какой-нибудь кусок инфраструктуры, волшебным образом решающий все наши проблемы раз и навсегда. Или сообщали, что второго релиза на этой неделе не будет, потому что один датацентр смыло ураганом, а рядом с другим хоронили лошадь и перерубили магистральный кабель. Через некоторое время стало понятно, что к этим людям можно приходить с самыми разнообразными проблемами, и уходить с решениями, найденными парой уровней абстракции ниже, чем ты ожидаешь от своего собственного продукта («вы, конечно, заплатили за нужный объем трафика, но вот здесь он у вас тупо не влезает в свитч, стоящий наверху стойки»).

    В итоге мне стало интересно, как выглядит всё это SRE изнутри, и я подался в Mission Control – программу ротации, позволяющую провести полгода в роли SRE, получить ценного production-опыта и, при желании, вернуться в свою прежнюю команду делиться приобретёнными знаниями. Я вместо этого остался, как и две трети моих нынешних коллег по Video Processing SRE, тоже переквалифицировавшихся из обычных инженеров. Теперь я сам пугаю SWE непонятными графиками и эвакуирую ютьюбные видео из горящих датацентров, с перерывами на мирный созидательный кодинг. Оказалось, что за пятнадцать лет внутри Гугла выросла здоровая и эффективная SRE-организация со своими практиками, принципами и методами – но о них никто не знает, потому что из тех кто попадал туда, еще никто не возвращался назад.

    Решением этой проблемы исчезновения информации о дежурствах, SLO и постмортемах в чёрной дыре Google SRE стала книжка «Site Reliability Engineering», подробно описывающая как это наше SRE на самом деле работает. Собственно, весь этот пост затеян ради двух новостей:

    1. Две недели назад вышел русский перевод вышеупомянутой SRE book. Если вам интересно, как завести в вашей компании здоровые DevOps-практики, эта книга для вас. Если вы подозреваете в себе SRE-наклонности, то эта книга ещё более для вас.
    2. Вдогонку к первой книге только что вышла (пока только на английском) Site Reliability Workbook с практическими примерами из жизни Google Cloud Platform – тоже всячески рекомендую.

    Google

    117,00

    Филин Лаки

    Поделиться публикацией
    Комментарии 11
      +1
      Со дня на день как раз жду книгу, думаю, будет интересно :)
        +1
        В общем, книга скорее не понравилась, чем понравилась. Очень мало полезной практической информации, на мой взгляд, из неё можно вынести для «среднестатистического» инженера / devops из средней по размеру IT-компании. Много воды, что в целом свойственно «западным» книгам. Понятно, что в целом написано то все про кухню внутри Google, но, думал, будет как-то больше примеров использования какого-то доступного всем ПО, практик. Но, как в книге подчеркивается, большинство стороннего ПО не подходит Google, так как не работает на таких масштабах. В результате все, по сути, пишется свое и сугубо для себя. Интересно было почитать про какие-то реальные сбои и способы их решения.
        Кто-то скажет что все это было и так понятно, не зачем было покупать и я даже с этим в какой-то мере согласен, сформировал для себя изначально ложные представления о чем эта книга :) Вторая книга в этом плане выглядит поинтереснее, для меня по крайней мере.
        В любом случае, заглянуть одним глазком в процессы и попытаться оценить масштабы вполне познавательно.
        +1

        А кто ставят новые релизы и занимаются настройкой конвееров поставки в Google, SRE или devops инженеры? Или вторые просто отсутствуют по причине наличия первых?

          +2

          Вторые отсутствуют по причине наличия первых, да.


          Кажется, есть разные точки зрения на что вообще такое DevOps и в каких отношениях оно состоит с SRE; вот тут коллеги топят за точку зрения "SRE implements DevOps", например.


          Вообще подробнее про релизы есть вот в этой главе. В частности, распространённая практика — что на ранних стадиях жизни сервиса за релизы и пр. отвечают разрабатывающие его SWE, а когда сервис становится достаточно стабилен, он проходит production readiness review и релизы (и прочие пейджеры) переходят к SRE-команде.

            +1
            Спасибо, судя по этой главе, роль DevOps инженера выполняет «Релиз инжинер» определяющий практики и методологии внедрения (иногда совместно с SRE).

            Почему-то складывается ощущение, что SRE не вовлечены в развитие и создание продукта. В случае если им что-то технически не нравиться, они либо это правят быстро сами, либо отдают поддержку обратно SWE, до тех пор пока не исправят… но никакого участия в создании бизнес фич, и наверное процесс передачи чего-то не всегда сопровождается передачей знаний в SRE (я даже представить не могу как это можно сделать при политике push on green)
            Поправьте если, что-то не так понял.

            Спасибо!
              +1
              Почему-то складывается ощущение, что SRE не вовлечены в развитие и создание продукта.

              Вовлечены: примерно половина времени должна уходить на разработку. Вот тут пишут, что ops часть (онколл, релизы, тикеты и прочий ручной труд) не должна занимать больше 50% рабочего времени, и в общем оно вполне удаётся. Понятно, при этом мы обычно работаем не над видными пользователю фичами, а скорее над чем-нибудь бэкендно-инфраструктурным — иногда вместе со SWE, иногда целиком внутри SRE.

          0

          [edit: промахнулся веткой]

            0
            Есть вопрос по поводу:
            «но о них никто не знает, потому что из тех кто попадал туда, еще никто не возвращался назад.»
            Некоторое время назад Google опубликовал курс на Coursera — IT Support professional, где различные специалисты Google (в том числе и SRE) рассказывают про базу необходимую для эффективной поддержки приложений.
            Планируете еще что-то подобное для перехода на следующий уровень и приближения знаний к SRE?

            и еще один вопрос… Один из блоков курса — автоматизация на Ruby.
            Есть ли у Google SRE какой-то стандарт языка скриптинга для автоматизации рутинных задач? или каждый выбирает то, что ему больше по душе?
              +1

              Про планы на Coursera ничего не знаю, к сожалению :(


              Есть ли у Google SRE какой-то стандарт языка скриптинга для автоматизации рутинных задач?

              Python, Go и немножко bash.

              0
              [edit: опять промахнулся веткой]
                +1
                Привет, в сентябре 2018 вышла еще одна книга про SRE — Seeking SRE, Conversations About Running Production Systems at Scale, ссылка shop.oreilly.com/product/0636920063964.do
                Она содержит много примеров SRE практик в других компаниях.

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

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