Я практиковал и консультировал DevOps в качестве консультанта с различными клиентами уже почти пять лет, до того, как занимать мою нынешнюю должность, я занимал должности в разработке программного обеспечения, веб-операциях и системном администрировании. По моему личному опыту DevOps поставляется во многих вкусах.
Организационные шаблоны
DevOps Antipatterns:
NoOps и NoDevs - не строго DevOps в самом строгом смысле, однако, эти команды создают и эксплуатируют программное обеспечение без разделительной линии между разработкой и эксплуатацией. Проблемы с этими командами сводятся к зрелости, команды разработчиков могут быть опытными разработчиками программного обеспечения, но начинающими операторами и наоборот.
Мост DevOps - здесь одна или несколько команд несут ответственность за то, чтобы брать работу от команд разработчиков и « производить » ее, чтобы сделать ее работоспособной. Задача сводится к тому, что теперь есть две передачи: Разработка → DevOps и DevOps → Операции.
Команда DevOps - это, возможно, может сработать, если команда несет ответственность за создание инструментов, поддерживающих операционную модель с поддержкой DevOps, однако ее, вероятно, следует называть «Команда инструментов» или «Команда платформы».
Шаблоны DevOps:
Внедренные DevOps - чаще называемые Platform Engineering, в рамках которых в команде есть кто-то, кто несет ответственность, но не несет ответственности за предоставление автоматизации, инструментов и инфраструктуры для предоставления и развертывания решения, иногда также включая управление программным обеспечением. Это последнее, что на самом деле является представителем DevOps.
Институционализированные DevOps - когда проектная команда совместно отвечает как за разработку, так и за эксплуатацию программного пакета, создающего общую собственность и циклы положительной обратной связи.
практика
Фактическая практика DevOps основана на нескольких других практиках, а именно:
Каждая из перечисленных выше практик основывается на другой, однако можно не следовать этой практике, однако это означает, что отсутствует важный цикл обратной связи, который может указывать на «упущенную возможность». Ключевым отличием между выполнением любой другой практики и DevOps является работа программного обеспечения в производстве .
Три Пути
В проекте «Феникс» Джин Ким и его соавторы описывают три способа DevOps :
Системное мышление
Первый способ подчеркивает производительность всей системы, а не производительность отдельного бункера работы или отдела - это может быть как большое подразделение (например, разработка или ИТ-операции) или так же мало, как отдельный участник (например, , разработчик, системный администратор).
Исходя из моего опыта, заставляющего разработчиков учитывать эксплуатационные проблемы и нефункциональные требования, я достиг этой цели. Это очень большая часть культурных аспектов DevOps.
Усиление петель обратной связи
Второй способ - это создание петель обратной связи справа налево. Цель практически любой инициативы по улучшению процесса - сократить и усилить петли обратной связи, чтобы можно было постоянно вносить необходимые исправления.
Обычно я достигаю этого с помощью непрерывной интеграции / доставки / развертывания и совместного мониторинга и оповещения, поэтому он очень хорошо вписывается в инструментальный компонент DevOps.
Культура непрерывных экспериментов и обучения
Третий путь заключается в создании культуры, которая поощряет две вещи: постоянные эксперименты, риск и обучение на неудачах; и понимание того, что повторение и практика являются предпосылкой для овладения.
Это очень вписывается в культурное пространство, хотя в значительной степени зависит от инструментов и процессов, позволяющих культуре расти.
