SRE Evangelist
Original: Ross Brodbeck, https://hross.substack.com/p/sre-evangelist
За последний год я перестроил команду SRE. Это заставило меня задуматься о том, что такое SRE и, что еще более важно, что это такое конкретно в GitHub.
Что, черт возьми, такое — инженер по надежности?
К сожалению, я не думаю, что кто-то на самом деле знает, кто такой SRE. Я точно не знаю, хотя это написано в описании моего блога, и я только что сказал, что создал команду из них.
В зависимости от компании это может быть что угодно: от Ops+, до Developer+, до дежурного, 24x7 реагирующего на инциденты (последнее я не рекомендую). Это может быть централизованная роль во многих командах или отдельная роль в конкретной команде. Более подробно о различных способах организации SRE здесь.
На самом деле, самое страшное для меня в том, что я называю себя SRE — это гадать, будут ли люди делать неверные предположения о моем наборе навыков, потому что их представления о том, что такое SRE, отличаются от моих собственных.
Но что я точно знаю о SRE, так это то, что они специализируются на надежности и, по крайней мере в GitHub, являются разработчиками.
Что делает SRE успешным?
Независимо от того, что это за работа, я твердо верю в одно:
Чтобы действительно хорошо выполнять свою работу, SRE должны быть великими евангелистами.
Хорошие SRE могут быть хороши во многих других вещах: написании кода, отладке сетевого стека, развертывании приложений, понимании системы сборки… но чтобы быть по-настоящему великим, вам обязательно нужно быть великим проповедником.
Может быть, не совсем как этот парень, но с определенной коммуникацией и страстью.
Доступность — это скучно
Будучи выходцем из мира функциональной разработки, я могу сказать вам не понаслышке, что в повышении надежности нет особого блеска и гламура. Как бы нам ни хотелось, чтобы наши менеджеры по продуктам сосредоточились на влиянии низкой надежности на бизнес, реальность такова, что даже если у вас есть хорошие метрики, чтобы оправдать повышение надежности продукта, во многих случаях погоня за функционалом просто интереснее.
Как часто вы устраиваете вечеринку в честь успешного месяца доступности? Обычно обеспечение доступности включает в себя написание постмортема об инциденте или какую-то другую бумажную работу и встречи. Звучит… здорово.
Одна из основных задач SRE в подобных ситуациях — сделать надежность более интересной. Для тех, кто уже работает в этой сфере это на самом деле интересно, но мы должны уметь распространять (осмелюсь сказать, “проповедовать”?) это чувство.
SRE должны быть множителями силы
В большинстве случаев ваша среднестатистическая команда разработчиков не будет в восторге от повышения надежности. Даже когда есть какая-то важная и очевидная работа по улучшению надежности, требующая приоретизации, команда разработки может столкнуться с большим количеством других внешних факторов, вынуждающих гнаться за функционалом продукта в ущерб остальному.
Более того, обычно отношение SRE и других членов команды очень мало. Может быть, есть один SRE на команду (если вам действительно очень повезет), но, скорее всего, есть один SRE для множества команд. Один SRE никак не сможет выполнить работу по обеспечению надежности, необходимую для высокодоступных крупномасштабных сервисов.
И вот тут-то и начинается евангелизм…
Настоящий фокус заключается не в том, чтобы выполнить работу самому (даже если вы в этом великолепны), а в том, чтобы убедиться, что остальные члены команды/организации/компании осознают ценность надежности, чтобы они тоже начали работать над ней (и, возможно, даже подумали, что это круто?).
Разработчики обычно плохо проповедуют
Хорошо, но первой книгой, которую вы прочитали в учебной программе по информатике для первокурсников, вероятно, была не «Как завоевывать друзей и оказывать влияние на людей». Некоторым людям от природы хорошо удается работать с другими людьми (и мотивировать их), но большинство из них не выбирают профессию, состоящую в том, чтобы каждый день спокойно сидеть перед компьютером.
Работа с командами в организации, понимание их мотивации и помощь в подталкивании их в правильном направлении — это приобретаемый навык. И вполне вероятно, что вы потерпите неудачу в первый раз, когда попробуете.
Тем не менее, SRE должны обладать способностями в этой области больше, чем большинство других технических должностей.
Примеры проповедей
Разбор инцидента. Безусловно, работать с командой над написанием постмортема — это искусство. Это может быть так же просто, как помочь им понять цель написания (подсказка: это не просто бумажная работа), или настолько сложно, как заставить их самих предложить правильный ход действий для устранения инцидента, чтобы они чувствовали себя хозяевами положения.
Эскалация руководству. Реальность работы SRE такова, что будут времена, когда все пойдет настолько плохо и все сломается настолько сильно, что вам придется иметь дело с руководством (или выяснить, как передать проблему руководителю). Это не «обычный» навык разработчика. На самом деле, я думаю, что это одно из преимуществ работы SRE. Вы общаетесь с гораздо большим количеством людей вне команды, чем при обычной разработке программного обеспечения.
Дебаг сложных аварий. Многие из самых сложных для решения проблем надежности связаны со сложными системами (rate limits, взаимодействие нескольких систем, с пересекающимися отказами, непонятной конкуренцией за ресурсы). В таких случаях, скорее всего, вам понадобится возможность собрать в одной конференции несколько человек из разных команд (иногда между этими командами могут быть не самые лучшие отношения) и разобраться во всем.
Внедрение SLO. Понимает ли команда, почему они это делают? Рассматривают ли они правильные сценарии со стороны клиентов? Знают ли они о последствиях нарушения SLO (получают ли они уведомления об этом? Просматривает ли отчет или дашбоард руководство?)? Эти виды коммуникаций — больше искусство, чем наука.
Во всех этих (и многих других) сценариях, чтобы быть по-настоящему успешным SRE, вам постоянно нужно понимать, как работать с людьми в организации, как формировать ожидания и как повышать уровень понимания людьми надежности.
Обучение евангелистов
Очень вероятно, что не все в команде SRE будут евангелистами или что у них будет разный уровень навыков чтения проповедей. Конечно, даже у самого лучшего евангелиста всегда есть возможность совершенствоваться.
Для SRE (и для их руководителя) это означает помощь в их обучении, предоставление им возможности попрактиковаться. Это означает безопасное пространство для отработки навыков общения (и неудач). Независимо от того, являетесь ли вы менеджером, ищущим способы помочь своей команде повысить уровень, или SRE, стремящимся стать лучше, я рекомендую:
Получение возможности выступления перед группами (технические презентации или небольшие беседы отлично подходят для этого). Обязательно получите обратную связь.
Выполнение более мягкой работы с «безопасными» командами. В вашей организации будут команды, которым вы доверяете больше. Работайте с «безопасной» командой над более мягким проектом (меньше технических деталей, больше общения) и обязательно получайте обратную связь.
Посещение совещаний с руководителями. Даже если вы просто наблюдаете, наблюдение за несколькими встречами с руководителями может быть чрезвычайно поучительным с точки зрения ожиданий и того, как проходят эти встречи. Бонусные баллы, если вы посетите предварительную встречу (такое почти всегда бывает).
Работа с хорошими евангелистами. Может быть, это немного более очевидно, но объединение двух SRE и предоставление возможности евангелисту подавать пример — еще один хороший способ приобрести привычки и техники.
В конце концов, вы можете обнаружить, что в евангелизме существует потолок. По моему опыту, это связано с… желанием не быть евангелистом. Люди, которые не являются евангелистами, определенно могут быть очень успешными SRE, но я думаю, что их успех всегда будет ограничиваться этой ролью из-за ее уникальных требований.
