Visitors have accessed this post 5312 times.

Появление DevOps в 2009 (хотя, по некоторым источникам, это все-таки было в 2008) в корне поменяло процесс взаимодействия между отделами разработки и эксплуатации. До этого момента это были два совершенно разные подразделения со своими целями, задачами и KPI. Как следствие, они не слишком вникали в деятельность друга и часто возникала абсолютно типичная, но очень грустная для работы компании в целом ситуация.

Разработчики выкатывали обновление или новое приложение, локально на их уровне все работало, а при запуске в эксплуатацию начинали валиться ошибки или приложение не запускалось совсем. С точки зрения разработчиков, их вины тут нет, у них все было ОК, системные администраторы же считали, что проблема в «кривом» коде. Приходилось вносить исправления, иногда не по разу, что очень замедляло выпуск релиза.

Для бизнеса цена такой ошибки может быть колоссальной. Не верите – прочитайте роман «Проект «Феникс». Роман о том, как DevOps меняет бизнес к лучшему». В нем очень живо показано, как со скоростью мысли растет и множится ворох проблем, связанный с одним неудачным запуском критически важной для компании системы, и как эта ситуация плачевно отражается на прибыльности.

Чтобы переломить эту ситуацию, и появилась методология DevOps (а ее название – это сокращение от Development + Operations). Она связала в единый процесс разработку, тестирование и эксплуатацию. И позволила обновлять ПО гораздо чаще и без потери в качестве, что не могло не пойти на пользу не только самому процессу, но и бизнес-целям компании.

Что интересно, DevOps не является конкретной технологией, продвигаемой крупным вендором. Основы DevOps родились из реальных потребностей разработчиков и системных администраторов и ими же активно развивались. С их же легкой руки начался сбор так широко используемых в DevOps сегодня best practices (лучших практик, применяемых для решения той или иной задачи) и инструментов, подходящих для решения широкого круга задач в сфере DevOps.

Как вы понимаете, стандартная цепочка разработки ПО выглядит так:

1. Разработчики пишут код.
2. Тестировщики прогоняют его через тестовые стенды, выявляя ошибки.
3. Сисадмин разворачивает приложение в продакшн.

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

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

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

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

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

• Автоматизация – автоматизируйте все, что возможно.
• Ускорение выхода релиза. Ведь чем скорей компания получит конечный продукт, тем выше будет ее эффективность и конкурентоспособность.
• Быстрая обратная связь – позволяет оперативно вносить корректировки в продукт и обновлять его.
• Стандарты и документация. Именно они – залог успеха стабильной автоматизации каждого этапа тестирования и запуска в эксплуатацию.
• Непрерывное тестирование – для контроля всего процесса и быстрой реакции на проблемы и ошибки.

В заключение

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

Если вам интересно посещать открытые онлайн-мероприятия по DevOps, Kubernetes, Docker, GitlabCI и др. и задавать вопросы в режиме реального времени, подключайтесь к каналу DevOps by REBRAIN. *Анонсы мероприятий каждую неделю

Практикумы для специалистов по инфраструктуре и разработчиков — https://rebrainme.com.
Наш Youtube-канал — https://www.youtube.com/channel/UC6uIx64IFKMVmj12gKtSgBQ.

Агентство Fevlake, проектируем и поддерживаем IT-инфраструктуры с 2012 года — https://fevlake.com.