Прим. перев.: Это перевод статьи из блога компании New Relic, где на протяжении года публикуются подобные материалы о разных ИТ-специализациях, связанных с разработкой и эксплуатацией программного обеспечения. Автором является Kevin Casey — независимый журналист и обладатель премии Azbee Award, который пишет для различных изданий и компаний (включая Red Hat).
В недавней публикации мы рассмотрели восхождение Site Reliability Engineer в современных организациях, занимающихся программным обеспечением. Но называться SRE — одно дело, а нам же хотелось бы ещё узнать, что требуется для того, чтобы преуспеть в этой должности.
Поэтому мы решили изучить характерные черты и привычки, являющиеся общими для по-настоящему успешных SRE. Как и для большинства позиций, связанных с разработкой и эксплуатацией, очевидно, что первоклассные технические навыки критичны. Для SRE эти специфичные навыки могут зависеть от того, как конкретная организация определяет или применяет должность: подход Google к Site Reliability Engineering может требовать больше опыта в software engineering и написании кода, а в другой компании большую ценность могут представлять навыки в эксплуатации или обеспечении качества (QA). Тем не менее, как выяснилось при изучении, что же делает специалистов по разработке и эксплуатации успешными, что отделяет «великих» от «достаточно хороших», так это зачастую комбинация привычек и характерных черт, которые дополняют техническую экспертизу.
Семь привычек, представленных ниже, были получены на основе подробных интервью с сотрудниками New Relic: Beth Long (Software Engineer) и Jason Qualman (Site Reliability Engineer). Давайте посмотрим:
Успешные разработчики программного обеспечения понимают, как их код помогает работать всему бизнесу. У SRE есть своя версия этой черты. «Вам нужен тот, кто действительно думает не только о повседневных задачах, но и о большей картине. Успешный SRE может понимать и объяснять вещи на более высоком уровне», — говорит Jason. Внутри New Relic мы описываем таких людей, как «тех, кто постоянно анализирует в каждом изменении возможные риски и его влияние на будущее, не только на сегодня». Что это означает для большой инфраструктуры?
Лучшие SRE выбирают прагматичный подход и оценивают, как их работа повлияет на остальную систему или команду. В таком подходе минимизируется вероятность того, что изменение «бросают через стену без понимания того, как оно может затронуть человека, сидящего по ту сторону».
«Мы принимаем решения, которые находятся на очень низком уровне всего стека. Иногда они могут задеть всех, кто находится выше. Необходимо понимать, как решение конкретной проблемы повлияет на всех остальных, кто встретится по пути», — говорит Jason.
Частью прагматичного подхода для SRE является желание отбросить процессы и операции, которые могут быть подходящими, однако в действительности не оказываются эффективными. Beth вспоминает пример, когда в New Relic меняли свои практики в области надёжности:
В конце концов, процесс CAB был выброшен в пользу более частых и маленьких релизов, которые привели к гораздо лучшим результатам.
Высококлассные SRE успешно справляются с главной сложностью: как повысить надёжность всего, чем они занимаются, без замедления возможности компании быстро поставлять программное обеспечение. Решением почти всегда является автоматизация. SRE надо быть проактивными в поиске решения трудоёмких задач, багов и т.п., с которыми осуществляется ручное взаимодействие, с помощью новых способов автоматизации или изменения процесса.
«Значительная составляющая этой должности — думать о неэффективных и трудоёмких задачах и упразднять их как можно быстрее. Вместо того, чтобы откладывать решение задач, выполняемых вручную, вы говорите: „Я найду время, чтобы автоматизировать это прямо сейчас и избавить всех от необходимости заниматься этой мучительной деятельностью“», — поясняет Jason.
Одержимый фокус на автоматизации не является уникальным для New Relic: например, в The DevOps Handbook есть целая глава, рассказывающая о парадоксальных эффектах принятия процессов, исполняемых вручную. В описаниях вакансий SRE «автоматизация» и различные её проявления встречаются чаще любых других слов. Недавняя вакансия на SRE от компании Procore Technologies в Лос-Анджелесе, занимающейся программным обеспечением для управления строительством, имеет такой второй пункт в своём описании: «Автоматизируйте, автоматизируйте, автоматизируйте и после этого… автоматизируйте!». (Хотя с момента оригинальной публикации прошло всего 4 дня, упомянутая вакансия уже была закрыта, однако по этой ссылке можно найти немало других примеров «automate» в описании обязанностей SRE по версии иных компаний — прим. перев..)
Уверенность в отстаивании конкретной задачи по автоматизации или другой SRE-инициативе — ещё один атрибут, определяющий лучших SRE. Вы должны хотеть защитить свою позицию, почему критично автоматизировать какой-то процесс, или по другой части работы. И это бывает непросто, потому что может вызвать столкновение с культурой и скоростью работы многих традиционных организаций, работающих в области программного обеспечения.
Митинг команды New Relic в Портленде
Хорошие SRE живут со своей, ориентированной на инженерную специфику, версией классики по самопомощи «How to Win Friends and Influence People». Проще говоря, в их работу входит необходимость убеждать других людей делать вещи, которых они изначально не хотят, — например, программного инженера в том, чтобы он больше сосредоточился не на возможностях продукта, а на проблемах, которые могут возникнуть при масштабировании продукта на протяжении нескольких следующих лет.
Лучшим SRE необходимо быть эффективными продавцами, способными продать своим коллегам долгосрочные выгоды автоматизации конкретного процесса или проекта, даже если может выясниться, что это принесёт сложности в краткосрочной перспективе. Итог? «Вы должны быть способны отстоять свою позицию и сказать „стоп“ или „нет, нам действительно необходимо сделать это сейчас“, что может оказаться трудным в некоторых организациях», — поясняет Beth.
Поскольку концепция SRE всё ещё нова, многие SRE раньше занимали другие должности. У некоторых SRE может быть опыт разработчика, у других — в традиционном подходе к эксплуатации. Jason и Beth отмечают, что наиболее эффективны менеджеры по найму, которые не сводят роль SRE к одному конкретному прошлому опыту. Например, хорошую подготовку для позиции SRE может иметь и традиционный QA-инженер.
Вне зависимости от имеющегося прошлого, есть шанс, что должность SRE заставит вас выйти из зоны комфорта и развить новые навыки. Например, специалисту в области эксплуатации может пригодиться изучение языка программирования или трёх, а кому-то с опытом в разработке придётся захотеть и научиться гораздо более основательно думать о процессах и сложностях эксплуатации, чем они привыкли делать в прошлом. Лучшие SRE принимают этот путь обучения и развития навыков.
Если для успешных SRE существует какая-то направляющая философия, то её можно выразить так: на самом деле, вы не преследуете священный Грааль, который предотвратит всё от каких-либо поломок. Такое редко работает. Вместо этого вы неустанно работаете над тем, чтобы видеть полную картину, внедрять автоматизацию, стимулировать здоровые паттерны, обучаться новым навыкам и инструментам и улучшать надёжность во всём, что вы делаете. Совершенства не достичь, однако постоянное стремление сделать всё лучше — это путь, которого и стоит придерживаться.
Американские инженеры New Relic на отдыхе
P.S. Все фотографии компании взяты с Glassdoor.
В недавней публикации мы рассмотрели восхождение Site Reliability Engineer в современных организациях, занимающихся программным обеспечением. Но называться SRE — одно дело, а нам же хотелось бы ещё узнать, что требуется для того, чтобы преуспеть в этой должности.
Поэтому мы решили изучить характерные черты и привычки, являющиеся общими для по-настоящему успешных SRE. Как и для большинства позиций, связанных с разработкой и эксплуатацией, очевидно, что первоклассные технические навыки критичны. Для SRE эти специфичные навыки могут зависеть от того, как конкретная организация определяет или применяет должность: подход Google к Site Reliability Engineering может требовать больше опыта в software engineering и написании кода, а в другой компании большую ценность могут представлять навыки в эксплуатации или обеспечении качества (QA). Тем не менее, как выяснилось при изучении, что же делает специалистов по разработке и эксплуатации успешными, что отделяет «великих» от «достаточно хороших», так это зачастую комбинация привычек и характерных черт, которые дополняют техническую экспертизу.
Семь привычек, представленных ниже, были получены на основе подробных интервью с сотрудниками New Relic: Beth Long (Software Engineer) и Jason Qualman (Site Reliability Engineer). Давайте посмотрим:
Привычка 1: Вы анализируете каждое изменение в контексте (гораздо) большей картины
Успешные разработчики программного обеспечения понимают, как их код помогает работать всему бизнесу. У SRE есть своя версия этой черты. «Вам нужен тот, кто действительно думает не только о повседневных задачах, но и о большей картине. Успешный SRE может понимать и объяснять вещи на более высоком уровне», — говорит Jason. Внутри New Relic мы описываем таких людей, как «тех, кто постоянно анализирует в каждом изменении возможные риски и его влияние на будущее, не только на сегодня». Что это означает для большой инфраструктуры?
Привычка 2: Вы прагматичны и дальновидны в анализе
Лучшие SRE выбирают прагматичный подход и оценивают, как их работа повлияет на остальную систему или команду. В таком подходе минимизируется вероятность того, что изменение «бросают через стену без понимания того, как оно может затронуть человека, сидящего по ту сторону».
«Мы принимаем решения, которые находятся на очень низком уровне всего стека. Иногда они могут задеть всех, кто находится выше. Необходимо понимать, как решение конкретной проблемы повлияет на всех остальных, кто встретится по пути», — говорит Jason.
Привычка 3: Вы хотите продолжать двигаться, когда что-то не помогает
Частью прагматичного подхода для SRE является желание отбросить процессы и операции, которые могут быть подходящими, однако в действительности не оказываются эффективными. Beth вспоминает пример, когда в New Relic меняли свои практики в области надёжности:
«Несколько лет назад мы проходили стадию активного роста и, чтобы препятствовать любой связанной с этим нестабильностью, мы реализовали процесс Change Acceptance Board (CAB) [совет по принятию изменений; по всей видимости, подразумевается change advisory board — прим. перев.]. Он был призван помочь нам оценивать релизы до их запуска в production, чтобы обезопасить от изменений, которые что-то ломают и вызывают инциденты в будущем. Ирония заключалась в том, что со снижением скорости цикла релизов мы начали накапливать всё большие и большие изменения, эффект которых был совершенно противоположным задуманному. Эти более крупные изменения увеличили риски для каждого релиза».
В конце концов, процесс CAB был выброшен в пользу более частых и маленьких релизов, которые привели к гораздо лучшим результатам.
Привычка 4: Вы пользуетесь каждой возможностью автоматизации
Высококлассные SRE успешно справляются с главной сложностью: как повысить надёжность всего, чем они занимаются, без замедления возможности компании быстро поставлять программное обеспечение. Решением почти всегда является автоматизация. SRE надо быть проактивными в поиске решения трудоёмких задач, багов и т.п., с которыми осуществляется ручное взаимодействие, с помощью новых способов автоматизации или изменения процесса.
«Значительная составляющая этой должности — думать о неэффективных и трудоёмких задачах и упразднять их как можно быстрее. Вместо того, чтобы откладывать решение задач, выполняемых вручную, вы говорите: „Я найду время, чтобы автоматизировать это прямо сейчас и избавить всех от необходимости заниматься этой мучительной деятельностью“», — поясняет Jason.
Одержимый фокус на автоматизации не является уникальным для New Relic: например, в The DevOps Handbook есть целая глава, рассказывающая о парадоксальных эффектах принятия процессов, исполняемых вручную. В описаниях вакансий SRE «автоматизация» и различные её проявления встречаются чаще любых других слов. Недавняя вакансия на SRE от компании Procore Technologies в Лос-Анджелесе, занимающейся программным обеспечением для управления строительством, имеет такой второй пункт в своём описании: «Автоматизируйте, автоматизируйте, автоматизируйте и после этого… автоматизируйте!». (Хотя с момента оригинальной публикации прошло всего 4 дня, упомянутая вакансия уже была закрыта, однако по этой ссылке можно найти немало других примеров «automate» в описании обязанностей SRE по версии иных компаний — прим. перев..)
Привычка 5: Вы можете убедить организацию сделать то, что необходимо
Уверенность в отстаивании конкретной задачи по автоматизации или другой SRE-инициативе — ещё один атрибут, определяющий лучших SRE. Вы должны хотеть защитить свою позицию, почему критично автоматизировать какой-то процесс, или по другой части работы. И это бывает непросто, потому что может вызвать столкновение с культурой и скоростью работы многих традиционных организаций, работающих в области программного обеспечения.
Митинг команды New Relic в Портленде
Хорошие SRE живут со своей, ориентированной на инженерную специфику, версией классики по самопомощи «How to Win Friends and Influence People». Проще говоря, в их работу входит необходимость убеждать других людей делать вещи, которых они изначально не хотят, — например, программного инженера в том, чтобы он больше сосредоточился не на возможностях продукта, а на проблемах, которые могут возникнуть при масштабировании продукта на протяжении нескольких следующих лет.
Лучшим SRE необходимо быть эффективными продавцами, способными продать своим коллегам долгосрочные выгоды автоматизации конкретного процесса или проекта, даже если может выясниться, что это принесёт сложности в краткосрочной перспективе. Итог? «Вы должны быть способны отстоять свою позицию и сказать „стоп“ или „нет, нам действительно необходимо сделать это сейчас“, что может оказаться трудным в некоторых организациях», — поясняет Beth.
Привычка 6: Вы расширяете свои навыки включением в них новых инструментов и подходов
Поскольку концепция SRE всё ещё нова, многие SRE раньше занимали другие должности. У некоторых SRE может быть опыт разработчика, у других — в традиционном подходе к эксплуатации. Jason и Beth отмечают, что наиболее эффективны менеджеры по найму, которые не сводят роль SRE к одному конкретному прошлому опыту. Например, хорошую подготовку для позиции SRE может иметь и традиционный QA-инженер.
Вне зависимости от имеющегося прошлого, есть шанс, что должность SRE заставит вас выйти из зоны комфорта и развить новые навыки. Например, специалисту в области эксплуатации может пригодиться изучение языка программирования или трёх, а кому-то с опытом в разработке придётся захотеть и научиться гораздо более основательно думать о процессах и сложностях эксплуатации, чем они привыкли делать в прошлом. Лучшие SRE принимают этот путь обучения и развития навыков.
Привычка 7: Вы доверяете процессу
Если для успешных SRE существует какая-то направляющая философия, то её можно выразить так: на самом деле, вы не преследуете священный Грааль, который предотвратит всё от каких-либо поломок. Такое редко работает. Вместо этого вы неустанно работаете над тем, чтобы видеть полную картину, внедрять автоматизацию, стимулировать здоровые паттерны, обучаться новым навыкам и инструментам и улучшать надёжность во всём, что вы делаете. Совершенства не достичь, однако постоянное стремление сделать всё лучше — это путь, которого и стоит придерживаться.
Американские инженеры New Relic на отдыхе
P.S. Все фотографии компании взяты с Glassdoor.
