DevOps против. SRE: сходства, различия и проблемы

31 мая 2022 г.

Жизненный цикл разработки программного обеспечения прошел долгий путь — от непересекающейся модели разработки — водопадной модели до итеративной модели разработки, такой как Agile и DevOps. Интересно отметить, что до начала движения DevOps (~2007–2008 гг.) SRE родилась в Google (2003 г.) для обеспечения надежности и отказоустойчивости всей инфраструктуры Google.

В своей книге SRE Google описал, как совместные усилия инженеров DevOps, SRE и других инженеров, таких как инженеры по безопасности приложений, жизненно важны для поддержки такого продукта, как Gmail.

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

Что такое DevOps?

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

В этом процессе разработка кода проходит через итерационные этапы — Непрерывная разработка, Непрерывная интеграция, Непрерывное тестирование, Непрерывная обратная связь, Непрерывный мониторинг, Непрерывное развертывание и Непрерывная эксплуатация. Также широко известен как «7C жизненного цикла DevOps».

Что такое SRE?

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

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

SRE использует три соглашения об уровне обслуживания для измерения производительности приложения:

Соглашения об уровне обслуживания (SLA) — определяют соответствующую надежность, производительность и задержку приложения в соответствии с пожеланиями конечного пользователя.

Цели уровня обслуживания (SLO) — целевые показатели, установленные командой SRE для удовлетворения ожиданий SLA.

Индикаторы уровня обслуживания (SLI) — для измерения конкретных показателей (таких как задержка системы, пропускная способность системы, время выполнения заказа, среднее время восстановления (MTTR), частота разработки и коэффициент ошибок доступности) для соответствия SLO. .

Сходства между SRE и DevOps

Обе методологии сосредоточены на мониторинге производства и обеспечении бесперебойной работы управления операциями.

Один из их фундаментальных принципов — ломать бункеры. Он направлен на объединение всех заинтересованных сторон (команда разработчиков + команда эксплуатации) в разработке приложения. Верьте в модель «разделенной ответственности и «разделенной собственности».

Их общая цель — упростить операции в распределенной системе.

Различия и взаимосвязь между SRE и DevOps

Разработка и внедрение

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

Команды SRE сосредоточивают свое внимание на том факте, действительно ли ядро реализовано. Соответствует ли продукт ожиданиям покупателя. Он отслеживает показатели производительности приложения и дает обратную связь команде DevOps о направлении изменений, которые необходимо внедрить.

Характер навыков

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

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

Их цель — найти способы инновации в повторяющихся случаях ошибок.

Автоматизация

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

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

Цель

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

Часто встречающиеся проблемы

Вот некоторые основные области, в которых они сталкиваются с проблемами:

Управление конвейером CI/CD: Внедрение различных автоматизированных тестов на разных этапах конвейера для обеспечения безошибочного кода.

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

Управление инцидентами: Чтобы понять причину сбоев службы, серьезность ошибки или даже немедленное оповещение о том, что какие-либо запросы не выполняются, требуется оперативное сообщение.

Принимая во внимание все

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

Платформы (BuildPiper, Harness и т. д.) включение * управляемые микросервисы и управляемый Kubernetes помогают нам поддерживать жизненный цикл приложений, решая вышеупомянутые проблемы.*

Глядя на данные на размер рынка управляемых услуг, прогноз 274 миллиарда долларов к 2026 году демонстрирует их потенциал в упрощении управляемости приложений.

Благодаря тому, что мировые технологические гиганты, такие как Google, Amazon и Netflix, стали пионерами принятия DevOps и SRE, их ROI росла как на дрожжах. Кроме того, глядя на их надежную инфраструктуру, которая редко выходит из строя, становится очевидным, что эти методологии рассчитаны на долгосрочную перспективу.

Также опубликовано здесь.

Оригинал