В итоге мне стало интересно, как выглядит всё это SRE изнутри, и я подался в Mission Control – программу ротации, позволяющую провести полгода в роли SRE, получить ценного production-опыта и, при желании, вернуться в свою прежнюю команду делиться приобретёнными знаниями. Я вместо этого остался, как и две трети моих нынешних коллег по Video Processing SRE, тоже переквалифицировавшихся из обычных инженеров. Теперь я сам пугаю SWE непонятными графиками и эвакуирую ютьюбные видео из горящих датацентров, с перерывами на мирный созидательный кодинг. Оказалось, что за пятнадцать лет внутри Гугла выросла здоровая и эффективная SRE-организация со своими практиками, принципами и методами – но о них никто не знает, потому что из тех кто попадал туда, еще никто не возвращался назад.
Решением этой проблемы исчезновения информации о дежурствах, SLO и постмортемах в чёрной дыре Google SRE стала книжка «Site Reliability Engineering», подробно описывающая как это наше SRE на самом деле работает. Собственно, весь этот пост затеян ради двух новостей:
- Две недели назад вышел русский перевод вышеупомянутой SRE book. Если вам интересно, как завести в вашей компании здоровые DevOps-практики, эта книга для вас. Если вы подозреваете в себе SRE-наклонности, то эта книга ещё более для вас.
- Вдогонку к первой книге только что вышла (пока только на английском) Site Reliability Workbook с практическими примерами из жизни Google Cloud Platform – тоже всячески рекомендую.
Комментарии (10)
Rampage
30.08.2018 09:48А кто ставят новые релизы и занимаются настройкой конвееров поставки в Google, SRE или devops инженеры? Или вторые просто отсутствуют по причине наличия первых?
Aldanur Автор
30.08.2018 10:26Вторые отсутствуют по причине наличия первых, да.
Кажется, есть разные точки зрения на что вообще такое DevOps и в каких отношениях оно состоит с SRE; вот тут коллеги топят за точку зрения "SRE implements DevOps", например.
Вообще подробнее про релизы есть вот в этой главе. В частности, распространённая практика — что на ранних стадиях жизни сервиса за релизы и пр. отвечают разрабатывающие его SWE, а когда сервис становится достаточно стабилен, он проходит production readiness review и релизы (и прочие пейджеры) переходят к SRE-команде.
Rampage
30.08.2018 11:16Спасибо, судя по этой главе, роль DevOps инженера выполняет «Релиз инжинер» определяющий практики и методологии внедрения (иногда совместно с SRE).
Почему-то складывается ощущение, что SRE не вовлечены в развитие и создание продукта. В случае если им что-то технически не нравиться, они либо это правят быстро сами, либо отдают поддержку обратно SWE, до тех пор пока не исправят… но никакого участия в создании бизнес фич, и наверное процесс передачи чего-то не всегда сопровождается передачей знаний в SRE (я даже представить не могу как это можно сделать при политике push on green)
Поправьте если, что-то не так понял.
Спасибо!Aldanur Автор
30.08.2018 11:40+1Почему-то складывается ощущение, что SRE не вовлечены в развитие и создание продукта.
Вовлечены: примерно половина времени должна уходить на разработку. Вот тут пишут, что ops часть (онколл, релизы, тикеты и прочий ручной труд) не должна занимать больше 50% рабочего времени, и в общем оно вполне удаётся. Понятно, при этом мы обычно работаем не над видными пользователю фичами, а скорее над чем-нибудь бэкендно-инфраструктурным — иногда вместе со SWE, иногда целиком внутри SRE.
Rampage
30.08.2018 13:09Есть вопрос по поводу:
«но о них никто не знает, потому что из тех кто попадал туда, еще никто не возвращался назад.»
Некоторое время назад Google опубликовал курс на Coursera — IT Support professional, где различные специалисты Google (в том числе и SRE) рассказывают про базу необходимую для эффективной поддержки приложений.
Планируете еще что-то подобное для перехода на следующий уровень и приближения знаний к SRE?
и еще один вопрос… Один из блоков курса — автоматизация на Ruby.
Есть ли у Google SRE какой-то стандарт языка скриптинга для автоматизации рутинных задач? или каждый выбирает то, что ему больше по душе?
vstaf
Со дня на день как раз жду книгу, думаю, будет интересно :)
vstaf
В общем, книга скорее не понравилась, чем понравилась. Очень мало полезной практической информации, на мой взгляд, из неё можно вынести для «среднестатистического» инженера / devops из средней по размеру IT-компании. Много воды, что в целом свойственно «западным» книгам. Понятно, что в целом написано то все про кухню внутри Google, но, думал, будет как-то больше примеров использования какого-то доступного всем ПО, практик. Но, как в книге подчеркивается, большинство стороннего ПО не подходит Google, так как не работает на таких масштабах. В результате все, по сути, пишется свое и сугубо для себя. Интересно было почитать про какие-то реальные сбои и способы их решения.
Кто-то скажет что все это было и так понятно, не зачем было покупать и я даже с этим в какой-то мере согласен, сформировал для себя изначально ложные представления о чем эта книга :) Вторая книга в этом плане выглядит поинтереснее, для меня по крайней мере.
В любом случае, заглянуть одним глазком в процессы и попытаться оценить масштабы вполне познавательно.