Комментарии 6
Не очень нравится SRE. Это срочные вызовы и "горящие" случаи, когда надо всё бросать и работать, пока не пофиксишь проблему. Хотя, может быть, в других фирмах это по-другому?
Если говорить о самой роли, то SRE-инженера отличает системный подход к решению проблем за счет устранения рудкоза, а не просто установки костыля.
Книжка "Site Reliability Engineering: Google" тут с вами не согласится. Там почти во всех главах говорится, что сервисы развиваются очень быстро, пишется много кода, библиотеки быстро устаревают и заменяются новыми, поэтому нет никакого смысла искать причину проблемы 1-2 дня, если можно за 15 минут поставить костыль. Проповедуется, что код должен сам себя восстанавливать и требовать как можно меньшего участия человека даже при появлении проблем, поэтому большинство инцидентов исправляются самим кодом, т.е. заранее приготовленными костылями на все случаи жизни. Если такого костыля не нашлось, то инцидент попадает к SRE инженеру и он тогда решает, как его исправить.
Никто не стремится исправлять все ошибки, поэтому придумали SLO и бюджет ошибок. Если инцидентов меньше определённой планки, то можно чаще выкатывать "рискованные" релизы. Если бюджет исчерпан, то выкатка новых релизов замедляется, проводится больше тестов и проверок, а всё время тратится на стабилизацию кода и ожидание появления нового бюджета ошибок.
Спасибо, что подметили, интересная точка зрения)
Понятно, что с учетом срочности, никто не будет сидеть над проблемой неделю, когда можно сразу зарелизить все с костылем. Но в статье все же немного о другом)
Можем в следующих материалах эту тему с SRE развить, если вам интересно.
Вот бы так с автомобилями, да?
С каким бэкграудом идти в SRE-инженеры: кейсы по внедрению и лайфхаки от специалистов