Comments 11
Кто-то скажет что все это было и так понятно, не зачем было покупать и я даже с этим в какой-то мере согласен, сформировал для себя изначально ложные представления о чем эта книга :) Вторая книга в этом плане выглядит поинтереснее, для меня по крайней мере.
В любом случае, заглянуть одним глазком в процессы и попытаться оценить масштабы вполне познавательно.
А кто ставят новые релизы и занимаются настройкой конвееров поставки в Google, SRE или devops инженеры? Или вторые просто отсутствуют по причине наличия первых?
Вторые отсутствуют по причине наличия первых, да.
Кажется, есть разные точки зрения на что вообще такое DevOps и в каких отношениях оно состоит с SRE; вот тут коллеги топят за точку зрения "SRE implements DevOps", например.
Вообще подробнее про релизы есть вот в этой главе. В частности, распространённая практика — что на ранних стадиях жизни сервиса за релизы и пр. отвечают разрабатывающие его SWE, а когда сервис становится достаточно стабилен, он проходит production readiness review и релизы (и прочие пейджеры) переходят к SRE-команде.
Почему-то складывается ощущение, что SRE не вовлечены в развитие и создание продукта. В случае если им что-то технически не нравиться, они либо это правят быстро сами, либо отдают поддержку обратно SWE, до тех пор пока не исправят… но никакого участия в создании бизнес фич, и наверное процесс передачи чего-то не всегда сопровождается передачей знаний в SRE (я даже представить не могу как это можно сделать при политике push on green)
Поправьте если, что-то не так понял.
Спасибо!
Почему-то складывается ощущение, что SRE не вовлечены в развитие и создание продукта.
Вовлечены: примерно половина времени должна уходить на разработку. Вот тут пишут, что ops часть (онколл, релизы, тикеты и прочий ручной труд) не должна занимать больше 50% рабочего времени, и в общем оно вполне удаётся. Понятно, при этом мы обычно работаем не над видными пользователю фичами, а скорее над чем-нибудь бэкендно-инфраструктурным — иногда вместе со SWE, иногда целиком внутри SRE.
[edit: промахнулся веткой]
«но о них никто не знает, потому что из тех кто попадал туда, еще никто не возвращался назад.»
Некоторое время назад Google опубликовал курс на Coursera — IT Support professional, где различные специалисты Google (в том числе и SRE) рассказывают про базу необходимую для эффективной поддержки приложений.
Планируете еще что-то подобное для перехода на следующий уровень и приближения знаний к SRE?
и еще один вопрос… Один из блоков курса — автоматизация на Ruby.
Есть ли у Google SRE какой-то стандарт языка скриптинга для автоматизации рутинных задач? или каждый выбирает то, что ему больше по душе?
Про планы на Coursera ничего не знаю, к сожалению :(
Есть ли у Google SRE какой-то стандарт языка скриптинга для автоматизации рутинных задач?
Python, Go и немножко bash.
Она содержит много примеров SRE практик в других компаниях.
Google и DevOps: две книги про SRE