Что такое СРЭ? Как это связано с DevOps?

SRE расшифровывается как Site Reliability Engineering. Он основан на принципах DevOps, чтобы привнести инженерный подход к ИТ-операциям. SRE использует программное обеспечение для автоматизации работы системы, выявления проблем и принятия решений.

Концепция SRE разработана в Google. Он основан на идее, что код и программное обеспечение являются наиболее эффективным способом управления крупномасштабными системами. Ручные процедуры, инициированные отдельной командой, несут в себе риск недосмотра и непоследовательности.

В этой статье вы узнаете, что такое SRE и как он помогает оптимизировать облачные операции. Мы также объясним, где SRE пересекается с DevOps, а также чем они отличаются.

Какое место SRE занимает в доставке программного обеспечения?

SRE касается управления операциями. Он вступает в процесс доставки программного обеспечения после того, как код был разработан, проверен и развернут. Инженеры по надежности сайта обычно наблюдают, поддерживают и оптимизируют эти развернутые службы, взяв на себя обязанности администраторов.

Отличительной чертой SRE по сравнению с традиционными операциями является акцент, который он делает на автоматизации. Управление инфраструктурой, управление изменениями, аудиты и реагирование на инциденты должны быть автоматизированы в рамках модели. Практик SRE сосредотачивается на предоставлении и запуске программных инструментов, которые решают эти задачи, вместо того, чтобы напрямую взаимодействовать с самой системой.

SRE объединяет разрозненные аспекты опыта управления операциями. Использование процесса, управляемого инструментами, означает, что проблем может возникнуть меньше. Это помогает повысить стабильность по мере роста систем, даже если размер команды SRE остается неизменным.

Что на самом деле делают инженеры SRE?

Инженеры SRE обычно являются разработчиками программного обеспечения, которые также имеют опыт эксплуатации производственных услуг. Это дает им целостное представление о процессе доставки, от фиксации кода до разрешения инцидентов. Они будут использовать эти знания для разработки и реализации механизмов развертывания и мониторинга реальных сред.

Поскольку «надежность» буквально заложена в названии, команды SRE также несут ответственность за измерение времени безотказной работы и разработку способов его улучшения. Инженеры SRE устанавливают цели уровня обслуживания (SLO), которые обеспечивают целевые показатели надежности для организации. Они устанавливают и наблюдают за индикаторами уровня обслуживания (SLI), которые информируют о достижении целей, таких как частота ошибок, пропускная способность запросов и количество билетов. SRE будут участвовать в написании соглашений об уровне обслуживания (SLA), которые также предоставляются клиентам.

Инженеры SRE являются эффективными привратниками вокруг новых развертываний. Их внимание к сохранению стабильности означает, что иногда они провоцируют зависание развертывания, если SLO или SLA вот-вот будут нарушены. Команда SRE может дать разработчикам указание сосредоточиться на устранении причин инцидентов вместо того, чтобы продолжать развертывание новой работы.

Ни один сервис не может работать со 100% надежностью. SRE признает это, предоставляя разработчикам «бюджет ошибок», который они могут «расходовать». Как только этот бюджет превышен из-за новых ошибок, заявок или простоев, решение проблем становится всеобщим приоритетом до тех пор, пока бюджет ошибок и SLO не будут восстановлены.

Это может быть инженер SRE, который завершает эту корректирующую работу, написав новый код. Поскольку команда SRE имеет опыт разработки программного обеспечения, они способны решать проблемы по собственной инициативе. Когда служба работает хорошо, люди в ролях SRE снова становятся обычными разработчиками. Ожидается, что инженеры Google SRE будут тратить не менее половины своего времени на разработку.

Этот уникальный баланс разработки и эксплуатации помогает сохранить способность SRE-инженера контролировать процесс поставки. Их уровень видимости бесценен, когда речь идет об обнаружении рисков, которые могут привести к инциденту. Это также побуждает инженеров минимизировать время, затрачиваемое на операционные задачи, путем внедрения новых инструментов и автоматизированных процедур. Это может создать самоподдерживающийся цикл: более высокая степень автоматизации обычно делает сервис более надежным, снижая рабочую нагрузку на команду SRE. В свою очередь, инженеры освобождаются, чтобы вернуться к разработке, увеличивая пропускную способность.

Как SRE согласуется с DevOps?

DevOps — это далеко идущий термин, описывающий использование современных технологий и методологий для более быстрой доставки более качественного программного обеспечения. Это достигается за счет сокращения разрыва между командами разработки и эксплуатации, а затем внедрения автоматизации над процессом доставки программного обеспечения.

Пока это звучит похоже на SRE. Однако SRE преследует единственную цель — надежность, тогда как DevOps также учитывает второстепенные проблемы, такие как эффективность разработчиков и скорость доставки. Примечательно, что DevOps часто рассматривают как мост между разработкой и эксплуатацией, в то время как SRE объединяет их вместе. В SRE задачи разработки и эксплуатации выполняются одними и теми же людьми, при этом основное внимание уделяется разработке.

По этим причинам SRE можно рассматривать как конкретную реализацию DevOps. Хотя общие цели схожи и строго согласованы, SRE описывает метод их достижения: используйте бюджеты ошибок, SLO и SLI для защиты сервисов от ошибок, а затем внедряйте средства защиты, которые позволяют сместить акцент на работу в сторону разработки.

Бенджамин Трейнор Слосс, инженер Google, придумавший термин SRE, утверждает, что SRE можно рассматривать как «конкретную реализацию DevOps с некоторыми своеобразными расширениями». В качестве альтернативы вы можете инвертировать модель и подойти к DevOps «как к обобщению нескольких основных принципов SRE для более широкого круга организаций, структур управления и персонала».

Одним из существенных отличий SRE от DevOps является зависимость от данных. DevOps часто рассматривается как набор принципов для эффективного переноса кода с рабочих станций разработчиков в рабочие среды. Это означает работу с коммитами, мерж-реквестами, пайплайнами и контейнерами. SRE — это стратегия развертывания изменений с максимальной надежностью и сниженной вероятностью регрессии. Эффективный SRE требует постоянного наблюдения и анализа, чтобы выяснить, где произошли ошибки и как они могут повториться в будущем. Это более исследовательский и самосознательный подход, чем обычная реализация DevOps.

Является ли SRE хорошим шагом в карьере?

SRE только недавно начал привлекать к себе всеобщее внимание. Найти роль SRE может быть сложно, потому что многие организации еще не осознали преимущества этой модели. В некоторых случаях внутри организации может присутствовать форма SRE, но это может не отражаться в ролях, которые они рекламируют.

Несмотря на свой специализированный характер, SRE, как правило, является хорошим карьерным ходом. Это требует пересечения навыков, начиная от разработки программного обеспечения и заканчивая обслуживанием и реагированием на инциденты, с хорошей степенью глубины в каждом из них. Есть несколько кандидатов, которые могут предложить это, а это означает, что роли SRE, как правило, являются прибыльными позициями.

Анализ, проведенный GitLab в апреле 2022 года, выявил только 21 000 вакансий SRE при 104 000 вакансий DevOps. Однако данные Glassdoor указывают на диапазон заработной платы до 300 000 долларов США за работу SRE, в отличие от 234 000 долларов США для DevOps.

Переход на должность SRE может стать полезной возможностью для тех, кто хочет остаться в сфере разработки, получая при этом практический опыт эксплуатации сервисов. Это особенно подходит для людей, которые считают традиционные роли администратора слишком повторяющимися и практичными. От SRE ожидается, что вы будете автоматизировать операции, искать возможности для повышения качества обслуживания и вносить свой вклад в регулярные разработки после того, как пейджер происшествий замолчит.

Заключение

Site Reliability Engineering использует методы, обычно связанные с разработкой программного обеспечения, для автоматизации сервисных операций. Инженеры SRE — это опытные разработчики, которые также знакомы с проблемами запуска и масштабирования сервисов в производственной среде. Они создают цепочку инструментов для измерения и оптимизации надежности, взяв на себя задачи, которые раньше выполнялись специальными системными администраторами.

SRE можно рассматривать как реализацию принципов DevOps. Назначение инженеров SRE должно привести к повышению отказоустойчивости службы, способной принимать быстрые изменения. Это позволяет достичь цели DevOps по ускорению развертывания программного обеспечения без ущерба для качества. SRE излагает конкретную стратегию, направленную на достижение этой цели, уделяя особое внимание измерению данных, а также объединению талантов разработчиков и операторов.

В то время как DevOps в настоящее время широко понимается в сообществе, SRE остается новой областью внимания для многих организаций. Открытия может быть труднее найти, но они, как правило, более прибыльны, когда они появляются. Это отражает разнообразный набор навыков, которыми должны обладать инженеры SRE. Спрос, вероятно, будет быстро расти в течение следующих нескольких лет, поэтому кандидатам и организациям пора обратить внимание на сдвиг в сторону SRE.