Visitors have accessed this post 1453 times.

Основы DevOps

4
0
1453
25 сентября 2020 9:46
Автор: Rebrain Me
DevOps

Visitors have accessed this post 1453 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.

Комментарии (3)
Введено символов из возможных
Не отвечать

Вам также может понравится

Упрощаем работу с оповещениями в zabbix — настраиваем  теги
array(1) { [0]=> object(WP_Term)#11800 (16) { ["term_id"]=> int(7) ["name"]=> string(6) "DevOps" ["slug"]=> string(6) "devops" ["term_group"]=> int(0) ["term_taxonomy_id"]=> int(7) ["taxonomy"]=> string(8) "category" ["description"]=> string(0) "" ["parent"]=> int(0) ["count"]=> int(19) ["filter"]=> string(3) "raw" ["cat_ID"]=> int(7) ["category_count"]=> int(19) ["category_description"]=> string(0) "" ["cat_name"]=> string(6) "DevOps" ["category_nicename"]=> string(6) "devops" ["category_parent"]=> int(0) } } DevOps

Автор - Евгений Генеральчик

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

Как же...

1
0
14 августа 2020
Как узнать, сколько места занимают файлы и директории в Linux
array(1) { [0]=> object(WP_Term)#976 (16) { ["term_id"]=> int(6) ["name"]=> string(5) "Linux" ["slug"]=> string(5) "linux" ["term_group"]=> int(0) ["term_taxonomy_id"]=> int(6) ["taxonomy"]=> string(8) "category" ["description"]=> string(0) "" ["parent"]=> int(0) ["count"]=> int(28) ["filter"]=> string(3) "raw" ["cat_ID"]=> int(6) ["category_count"]=> int(28) ["category_description"]=> string(0) "" ["cat_name"]=> string(5) "Linux" ["category_nicename"]=> string(5) "linux" ["category_parent"]=> int(0) } } Linux

Для того, чтобы через интерфейс командной строки узнать, сколько места занимают файлы и директории, в Linux используется команда du. 

du расшифровывается как disk usage (использование диска).

Синтаксис команды du:

du ...

Если запустить du без указания параметров, то она выведет все директории и поддиректории текущей директории....

6
0
21 августа 2020
Чем HighLoad отличается от DevOps
array(1) { [0]=> object(WP_Term)#11800 (16) { ["term_id"]=> int(9) ["name"]=> string(8) "HighLoad" ["slug"]=> string(8) "highload" ["term_group"]=> int(0) ["term_taxonomy_id"]=> int(9) ["taxonomy"]=> string(8) "category" ["description"]=> string(0) "" ["parent"]=> int(0) ["count"]=> int(3) ["filter"]=> string(3) "raw" ["cat_ID"]=> int(9) ["category_count"]=> int(3) ["category_description"]=> string(0) "" ["cat_name"]=> string(8) "HighLoad" ["category_nicename"]=> string(8) "highload" ["category_parent"]=> int(0) } } HighLoad

Если вы зайдете на hh и напишите в поисковой строке HighLoad или «высокие нагрузки», результаты поиска вас удивят. «Чистых» вакансий по высоким нагрузкам практически нет. Как правило, задачи HighLoad упоминаются в обязанностях DevOps-инженеров (правда, чаще это матерые спецы уровня Senior) или backend-разработчиков. Поэтому очень часто происходит...

0
1
4 декабря 2020