5 основных различий между DevOps и SRE, о которых вы должны знать
Опубликовано: 2021-02-22В мире информационных технологий и разработки программного обеспечения DevOps часто объединяется с SRE, что означает одно и то же. Однако между ними есть огромные различия. В то время как технология Site Reliability Engineering (SRE) набирает обороты в последние годы, DevOps существует гораздо дольше (даже до появления термина DevOps).
Проще говоря, DevOps и SRE — это методы, применяемые для более быстрой доставки программного обеспечения. Единственная разница между ними заключается в их подходах; DevOps ориентирован на сокращение жизненного цикла разработки программного обеспечения, а SRE — на устранение слабых мест системы для достижения той же цели.
В этой статье мы рассмотрим основные отличия DevOps и SRE друг от друга. Прежде чем мы это сделаем, давайте начнем с понимания того, что такое DevOps и SRE.
Оглавление
Что такое DevOps?
По словам Джина Кима, автора «Руководства по DevOps» и «Проекта Феникс»,
«DevOps — это [набор] культурных норм и технологических практик, который [обеспечивает] быстрый переход запланированной работы, в том числе от разработки, через тестирование к эксплуатации, сохраняя при этом надежность, эксплуатацию и безопасность мирового уровня. DevOps — это не то, что вы делаете, а то, каковы ваши результаты».
Таким образом, DevOps в основном ориентирован на преобразование культурных практик внутри организации для ускорения жизненного цикла разработки программного обеспечения (SDLC). Он не нацелен на человека, группу или должность. DevOps направлен на укрепление сотрудничества между подразделениями информационных технологий и командами разработки программного обеспечения.
Что он делает и как он это делает, не важно; признается только результат процесса.
DevOps использует набор принципов, чтобы усилить взаимодействие групп разработчиков программного обеспечения с производственными системами и позволяет группе ИТ-эксплуатаций более эффективно сообщать о несоответствиях команде разработчиков. На самом деле SRE играет решающую роль в организации DevOps, способствуя упреждающему тестированию, скорости, обеспечивая наблюдаемость и повышая надежность обслуживания. DevOps призывает каждую организацию, ориентированную на DevOps, действовать в соответствии с культурными принципами, изложенными в ее модели CALMS.
Что такое СРЭ?
SRE, сокращение от Site Reliability Engineering, — это термин, придуманный старшим вице-президентом Google Беном Трейнором, отвечающим за надзор за техническими операциями.
Дрю Фарнсворт (из Green Lane Design) объясняет: «Мне обычно нравится думать о SRE как о системе, в которой разработка управляет операциями. Это система, в которой среда разбита на самые основные компоненты ИТ-стека и развернута с использованием лучших практик, встроенных в оборудование».
По сути, команда SRE с опытом разработки программного обеспечения отвечает за решение проблем в производстве системы, поддерживая баланс между скоростью доставки и надежностью системы. Таким образом, подход SRE объединяет сотрудников по разработке программного обеспечения в соответствии с операционными ролями для применения структурированных инженерных методов для поддержки политик организации.
Они обеспечивают постоянную доступность и эффективную работу систем, чтобы группы разработчиков программного обеспечения могли разрабатывать технические услуги для повышения надежности системы. Обязанностью SRE является выявление любой потенциальной слабости до того, как она перерастет в серьезную проблему.
DevOps против SRE: основные различия между DevOps и SRE
На практике DevOps и SRE следует рассматривать как взаимодополняющие дисциплины, где SRE как часть ориентированной на DevOps структуры сосредоточены на повышении надежности своих технических услуг. Таким образом, по сути нет такого понятия, как DevOps против SRE.
Поэтому то, что мы делаем в этом разделе, — это оценка фундаментальных различий между DevOps и SRE.
Внедрение изменений
Чтобы обновления происходили часто, а пользователи имели доступ к более новым и актуальным технологиям, как DevOps, так и SRE намерены работать быстро. Тем не менее, DevOps продвигается вперед постепенно, с осторожностью, в то время как SRE учитывает цену неспособности двигаться быстрее.
Оба внедряют автоматизацию и используют инструменты для достижения этой цели.
Отношение к неудачам как к нормальному
DevOps умеет принимать неудачи и относиться к ним как к подавлению обучения. По этой причине он поощряет безупречную культуру, признавая, что сбои являются частью процесса, и не сосредотачивается на том, чтобы сделать системы на 100% отказоустойчивыми. Примером этого является Netflix с его обезьяньей армией.
SRE, с другой стороны, поддерживает безупречное вскрытие. Цель этого состоит в том, чтобы определить причину сбоя, назначить ответственность и работать над тем, чтобы избежать подобных сбоев в будущем. Сколько отказов может произойти в системе, включено в бюджет ошибок. Метрики SLI, SLO и SLA определяют это для снижения себестоимости продукции. По сути, SRE применяет методы упреждающего мониторинга и оповещения, чтобы предотвратить потенциальный сбой.
Изучайте онлайн-курсы по разработке программного обеспечения в лучших университетах мира. Участвуйте в программах Executive PG, Advanced Certificate Programs или Master Programs, чтобы ускорить свою карьеру.
Автоматизация против инноваций
DevOps придает первостепенное значение автоматизации. В среде, ориентированной на DevOps, это приводит к максимально возможной автоматизации систем, что приводит к скучным выпускам. После того, как разработчик зафиксировал код, большинство из следующих действий, если не все, должны быть автоматизированы.
Таким образом, причина DevOps для использования CI / CD заключается в разработке высококачественных систем с более высокой скоростью.
Причины, по которым SRE использует CI/CD, иные: они направлены на снижение цены отказа. Любые общие, общие или повторяющиеся задачи в таких операциях, как развертывание и резервное копирование, считаются менее заслуживающими внимания. Поэтому SRE выделяют определенное количество времени, чтобы избежать тяжелого рабочего дня. Это делается для того, чтобы они могли выполнять более привлекательные задачи, такие как внедрение или внедрение новых технологий или деятельность, связанная с архитектурой.
Оформление заказа: проекты DevOps для начинающих
Разрушение организационных барьеров
Разработчики и операторы вступают в конфликт, когда дело доходит до процесса развертывания. В то время как разработчики выиграют от развертывания функций, как только они будут закодированы, специалисты по эксплуатации сосредоточены на том, чтобы сделать системы доступными, что затрудняет процесс развертывания.
И DevOps, и SRE различаются тем, как они устраняют разрозненность в организации.
DevOps, как поясняется в Руководстве по DevOps, решает эту проблему, включая такие методы, как работа с меньшими партиями и более эффективное управление конфигурациями.
SRE нацелены не только на оптимизацию взаимодействия между командами, но и на помощь системам в работе. Они делают это, интегрируясь в команды в качестве консультантов и поддерживая разработчиков, разделяя ответственность за эксплуатацию систем. Вот как SRE преодолевают разрозненность в организации.
Измерение успешной реализации
Показатели DevOps связаны со скоростью операций; это включает в себя, как часто происходят развертывания, время, затрачиваемое на это, и как часто они сталкиваются с проблемами.
Согласно отчету Puppet и DORA за 2017 год, оценка успешного внедрения DevOps зависит от следующего:
- частота, с которой происходят развертывания
- продолжительность времени между фиксацией кода и его развертыванием
- частота неудачных развертываний
- время, необходимое для восстановления после сбоя развертывания
Эти циклы обратной связи созданы, чтобы помочь DevOps улучшить качество системы, облегчая экспериментирование.
SRE, с другой стороны, работает над улучшением систем, не забывая при этом об их надежности. Для определения успешного внедрения учитываются следующие ключевые показатели:
- цель уровня обслуживания (SLO)
- индикатор уровня обслуживания (SLI)
- соглашение об уровне обслуживания (SLA)
Вышеупомянутые метрики являются индикаторами надежности системы. Эти метрики заранее определяют, будет ли выпуск для изменений запущен в производство.
В SRE эти показатели скорости и качества пригодятся при построении бюджета ошибок и повышении надежности систем, а не при работе над новыми функциями.
Читайте: Заработная плата инженера DevOps в Индии
Заключение
Google опубликовал электронную книгу о том, как они внедряют проектирование надежности сайта в свои производственные системы, в которой Трейнор объяснил SRE следующим образом:
«SRE — это то, что происходит, когда вы просите инженера-программиста спроектировать операционную группу».
Когда дело доходит до различий между DevOps и SRE, все, что вам нужно помнить, это то, что SRE управляется разработчиками, а не рабочей группой. Как обслуживание, так и мониторинг в основном находятся под контролем разработчиков. Это то, что в первую очередь отличает две дисциплины.
Если вам интересно узнать больше о больших DevOps, разработке полного стека, ознакомьтесь с программой Executive PG upGrad и IIIT-B по разработке программного обеспечения — специализация в разработке полного стека , которая предназначена для работающих профессионалов и предлагает более 500 часов тщательного обучения, Более 9 проектов и заданий, статус выпускника IIIT-B, практические практические проекты и помощь в трудоустройстве в ведущих фирмах.
