Состояние devops в россии 2020

Hello Postgres

Официальный образ Постгреса очень продвинутый и позволяет настраивать множество параметров. Для быстрого старта большинство из них можно оставить как есть, но вот пароль суперпользователя придётся задать явно:

Эта команда запустит нам контейнер PostgreSQL в фоновом (detached) режиме и присвоит ему имя habr-pg:

Контейнер с PostgreSQL, запущенный в Docker

Классно, не правда ли? А что мы можем делать с этой базой данных? К сожалению, на текущий момент не так уж и много. Через интерфейс Docker можно запустить CLI, подключиться к контейнеру и уже оттуда запустить, например, psql:

Далее я буду использовать сокращенный вариант этой команды:

И тут мы сталкиваемся с первой проблемой: что вернёт нам запрос , выполненный в консоли? Мы не указали явным образом версию БД, которую хотим использовать. Давайте это исправим:

Теперь вопросов об используемой версии БД не возникает, но работать с ней по-прежнему не очень удобно. Нам нужно сделать эту БД доступной извне, чтобы к ней могли подключаться приложения и IDE. Для этого нужно выставить наружу порт:

Отлично! С этого момента к базе данных можно подключиться, например, из IntelliJ IDEA:

Настройка подключения к БД в IntelliJ IDEA

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

psql можно запустить так:

И соответствующий compose-файл:

(издание 2018)

Miguel Grinberg

Туда Сюда

Это девятнадцатая часть серии мега-учебника Flask, в которой я собираюсь развернуть Microblog на платформе Docker.

Под спойлером приведен список всех статей этой серии 2018 года.

Примечание 1: Если вы ищете старые версии данного курса, это здесь.

Примечание 2: Если вдруг Вы захотели бы выступить в поддержку моей(Мигеля) работы, или просто не имеете терпения дожидаться статьи неделю, я (Мигель Гринберг)предлагаю полную версию данного руководства(на английском языке) в виде электронной книги или видео. Для получения более подробной информации посетите learn.miguelgrinberg.com.

В главе 17 Вы узнали о традиционных развертывании, в котором следует заботиться о каждом маленьком аспекте конфигурации сервера. После чего в главе 18 я привел вас к другой крайности, когда познакомил Вас с Heroku, сервисом, который полностью контролирует задачи настройки и развертывания. В этой главе пришло время узнать о стратегии развертывания сторонних приложений на основе контейнеров, в частности на платформе контейнеров Docker. Этот третий вариант — «золотая середина», между двумя другими.

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

Несмотря на то, что мы не разделяем ядро, уровень изоляции в контейнере довольно высок. Контейнер имеет свою собственную файловую систему и может основываться на операционной системе, отличной от той, которая используется узлом контейнера. Например, можно запускать контейнеры на основе Ubuntu Linux на узле Fedora или наоборот. Не смотря на то, что контейнеры являются технологией, которая является родной для операционной системы Linux, благодаря виртуализации можно запускать Linux контейнеры на Windows и Mac OS X хостах. Это позволяет тестировать развертывания в системе разработки, а также включать контейнеры в рабочий процесс разработки, если только оно вам надо.

Ссылки GitHub для этой главы: Browse, Zip, Diff.

Установка Docker

Рассмотрим примеры установки на базе операционных систем Red Hat/CentOS и Debian/Ubuntu.

Red Hat/CentOS

Устанавливаем репозиторий — для этого загружаем файл с настройками репозитория:

wget https://download.docker.com/linux/centos/docker-ce.repo

* если система вернет ошибку, устанавливаем wget командой yum install wget.

… и переносим его в каталог yum.repos.d:

mv docker-ce.repo /etc/yum.repos.d/

Устанавливаем docker:

yum install docker-ce docker-ce-cli containerd.io

Если система вернет ошибку Необходимо: container-selinux >= …, переходим на страницу пакетов CentOS, находим нужную версию container-selinux и копируем на него ссылку:

… с помощью данной ссылки выполняем установку:

yum install http://mirror.centos.org/centos/7/extras/x86_64/Packages/container-selinux-2.99-1.el7_6.noarch.rpm

После повторяем команду на установку докера:

yum install docker-ce docker-ce-cli containerd.io

В deb-системе ставится командой:

apt-get install docker docker.io

После установки

Разрешаем запуск сервиса docker:

systemctl enable docker

… и запускаем его:

systemctl start docker

После проверяем:

docker run hello-world

… мы должны увидеть:

…
Hello from Docker!
This message shows that your installation appears to be working correctly.
…

Цели и задачи DevOps

Поскольку процессы девопс охватывают весь цикл поставки ПО, выделяют несколько основных целей этого подхода :

• сокращение времени для выхода на рынок;
• снижение частоты отказов новых релизов;
• сокращение времени выполнения исправлений;
• уменьшение количества времени на восстановления при сбое новой версии или других случаях отключения текущей системы.

Эти цели достигаются через решение следующих задач:

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

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

Этапы девопс

Что такое Docker

Docker представляет собой систему управления контейнерами. Она позволяет «упаковать» приложение или веб-сайт со всем его окружением и зависимостями в контейнер, которым в дальнейшем можно легко и просто управлять: переносить на другой сервер, масштабировать, обновлять.

Docker был написан на языке программирования Go и выпущен в 2013 году. Изначально он работал только с Linux-системами, однако на данный момент его можно использовать также в Windows и macOS. Несмотря на то, что проект является относительно новым, Докер широко используется многими специалистами и продолжает завоевывать популярность.

Важной частью экосистемы Docker является Docker Hub – открытый репозиторий образов контейнеров. В нем можно найти десятки готовых приложений от официальных разработчиков

Среди них – nginx, MySQL, Apache, Gitlab, Redmine, Elasticsearch, Jenkins и другие.

Например, для запуска WordPress с помощью Docker достаточно выполнить следующие команды:

docker run --name wp-mysql -e MYSQL_ROOT_PASSWORD=wpmsqlpsswd -d mysql:5.7
<вывод пропущен>
docker run --name my-wordpress --link wp-mysql:mysql -d -p 80:80 wordpress

После этого откройте в браузере страницу http://12.34.56.78 (здесь укажите реальный IP-адрес вашего VDS) и приступите к настройке CMS!

Теперь расскажем о том, что представляет собой Docker. Три основных термина в экосистеме Docker:

• Образ (image) – шаблон, который используется для создания контейнеров. Представляет собой слепок файловой системы, в котором расположен код приложения и его окружение.
• Реестр (registry) – репозиторий образов. Docker Hub, о котором шла речь выше, – это публичный репозиторий, где хранится огромное количество образов.
• Контейнер (container) – запущенное приложение, т.е. совокупность процессов и образа.

Что такое Docker

Docker — инструмент, предназначенный для быстрой разработки, доставки и развёртывания приложений. Он позволяет упаковать приложение вместе со всеми его зависимостями в так называемый контейнер, а затем запустить его в любой среде.

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

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

Преимущества контейнеров:

Continuous Deployment

Не так давно (меньше года назад) 1С представила свой новый продукт: «Центр администрирования». Он позволяет автоматизировать то, что раньше делалось вручную, писались разрозненные скрипты или использовались продукты других компаний. На текущий момент Центр администрирования встроен в Центр контроля качества, который мы активно используем в качестве CMDB и системы мониторинга, поэтому сразу после появления данного продукта наши администраторы начали менять свои самописные скрипты на сценарии в данном продукте. На текущий момент уже выполнена автоматизация установки продуктивного релиза которая включает в себя блокировку базы, перезапуск служб и очистку сеансовых данных, подключение к релизному хранилищу и обновление основной и конфигурации базы данных. Участие человека сводится к запуску скрипта, которая нужна лишь для соблюдения регламента компании. 

Основные понятия

Образ — некий шаблон, на основе которого создаются контейнеры. Содержит всё необходимое для запуска приложения. Сюда относятся код, системные утилиты, библиотеки, настройки и так далее. Образ можно представить в виде набора слоёв, которые накладываются друг на друга. Каждый последующий добавляет, изменяет или удаляет файлы предыдущего слоя.

DockerfIle — текстовый файл с набором инструкций по созданию образа, каждая из которых добавляет к образу новый слой.

Контейнер  — конкретный экземпляр приложения, созданный на основе образа. Причём из одного образа можно создать сколько угодно контейнеров. Технически контейнер создаётся путём добавления к образу нового слоя, содержащего результаты работы приложения.

Утилита Docker

Все действия с контейнерами выполняются утилитой docker. Ее можно запускать от имени вашего пользователя после того, как он был добавлен в группу программы. Синтаксис утилиты очень прост:

$ docker опции команда опции_команды аргументы

Давайте сначала рассмотрим основные опции утилиты их всего несколько:

• -D — включить режим отладки;
• -H — подключиться к серверу, запущенному на другом компьютере;
• -l — изменить уровень ведения логов, доступно: debug,info,warn,error,fatal;
• -v — показать версию;
• —help вывести справку по команде или утилите в целом;

Команд намного больше, ниже приведены все команды, которые вы можете использовать в своих программах:

• attach — подключиться к запущенному контейнеру;
• build — собрать образ из инструкций dockerfile;
• commit — создать новый образ из изменений контейнера;
• cp — копировать файлы между контейнером и файловой системой;
• create — создать новый контейнер;
• diff — проверить файловую систему контейнера;
• events — посмотреть события от контейнера;
• exec — выполнить команду в контейнере;
• export — извлечь содержимое контейнера в архив;
• history — посмотреть историю изменений образа;
• images — список установленных образов;
• import — создать контейнер из архива tar;
• info — посмотреть информацию о системе;
• inspect — посмотреть информацию о контейнере;
• kill — остановить запущенный контейнер;
• load — загрузить образ из архива;
• login — авторизация в официальном репозитории Docker;
• logout — выйти из репозитория Docker;
• logs — посмотреть логи контейнера;
• pause — приостановить все процессы контейнера;
• port — подброс портов для контейнера;
• ps — список запущенных контейнеров;
• pull — скачать образ контейнера из репозитория;
• push — отправить образ в репозиторий;
• restart — перезапустить контейнер;
• rm — удалить контейнер;
• run — выполнить команду в контейнере;
• save — сохранить образ в архив tar;
• search — поиск образов в репозитории по заданному шаблону;
• start — запустить контейнер;
• stats — статистика использования ресурсов контейнером;
• stop — остановить контейнер;
• top — посмотреть запущенные процессы в контейнере;
• unpause — проложить выполнение процессов в контейнере.

В этой статье мы будем часто использовать команду run, рассмотрим ее опции:

• -e — переменные окружения для команды;
• -h — имя хоста контейнера;
• -i — интерактивный режим, связывающий stdin терминала с командой;
• -m — ограничение памяти для команды;
• -u — пользователь, от имени которого будет выполнена команда;
• -t — связать tty с контейнером для работы ввода и вывода;
• -v — примонтировать директорию основной системы в контейнер.

Теперь, когда мы рассмотрели все основы, приведем несколько примеров работы с контейнерами. Это очень просто.

Инструменты для работы

Для того, чтобы добиться успехов в выбранном направлении, а также получать хорошую зарплату, пользователю предстоит постоянно изучать что-то новое. В стандартных требованиях к DevOps специалистам имеются запросы относительно используемых инструментов. Это – приложения, без которых справляться с поставленными компанией задачами невозможно.

Начинающий и хороший специалист использует:

• Jenkins;
• системы контейнеризации Docker;
• оркестраторы контейнеров;
• платформы организации воркфлоу под названием GitLab;
• приложения для управления инфраструктурой;
• платформенные облачные сервисы;
• утилиты мониторинга и оповещений.

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

Подключаемся к контейнеру Docker

Существует два способа подключения к запущенному контейнеру через SSH: с помощью attach и exec. Это две команды, позволяющие выполнять команды в контейнере. Первая не предназначена для запуска нового процесса в контейнере и позволяет запустить только один экземпляр shell.

Если требуется воспользоваться новым терминалом, то здесь нам поможет команда exec. Она полезна, когда нужно выполнить новую команду или создать новый процесс. Attach же соединяет стандартный ввод, вывод или ошибку основного процесса внутри контейнера с соответствующим стандартным вводом, выводом или ошибкой терминала.

Для подключения к докер-контейнеру с помощью вышеупомянутых команд, нам потребуется воспользоваться командой docker ps. Она позволяет найти имя, ID конкретного контейнера и прочие атрибуты. В результате ее выполнения мы увидим следующее:

Присоединиться с помощью attach можно следующей командой:

docker container attach my_nginx

Вы можете скопировать ее в буфер обмена и вставить в консоль PuTTY простым кликом правой кнопкой мыши.

Чтобы отсоединиться от контейнера без его остановки, мы можем воспользоваться комбинацией клавиш «CTRL+P» или «CTRL+Q». Для его остановки достаточно зажать «CTRL+C».

Подключение через exec происходит при выполнении команды:

docker exec -i -t «CONTAINER ID» bash 

Container ID – это номер контейнера, который мы узнали при запросе данных о докер-контейнерах. В нашем случае строчка кода преобразится в следующий вид:

docker exec -it 9f5fcale0d22 bash

В результате выполнения команды произойдет защищенное подключение к контейнеру Docker. Вот еще некоторые команды для управления контейнером:

• docker ps -a — позволяет посмотреть, какие контейнеры находятся в системе;
• docker ps -l — показывает последние созданные контейнеры;
• docker start «CONTAINER ID» — запуск остановленного контейнера;
• docker stop peaceful_minsky — выключение активного контейнера;
• docker stop «CONTAINER ID» && docker start «CONTAINER ID» — перезагрузка контейнера без его отключения;
• docker-compose up -d —no-deps –build — запуск compose контейнера;
• docker rm «ID OR NAME CONTAINER» — удаление контейнера.

На этом наша статья подходит к концу. Сегодня мы разобрали такие команды, как docker exec и docker attach, с помощью которых можно подключиться к контейнеру Docker. Для получения интерактивной оболочки стоит использовать exec, для присоединения терминала к контейнеру – attach.

Команда запуска Docker

Команда имеет следующий вид:

Имя образа, из которого должен быть создан контейнер, является единственным обязательным аргументом для команды . Если образ отсутствует в локальной системе, он извлекается из реестра.

Если команда не указана, команда, указанная в инструкциях или выполняется при запуске контейнера.

Начиная с версии 1.13, интерфейс командной строки Docker был реструктурирован. Все команды сгруппированы по объекту, с которым они взаимодействуют.

Поскольку команда взаимодействует с контейнерами, это подкоманда . Синтаксис новой команды следующий:

Старый синтаксис до 1.13 все еще поддерживается. Под капотом команда — это псевдоним для . Пользователям рекомендуется использовать новый синтаксис команд.

Интеграция команд

Начнем с определения взятого с википедии: 

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

Бизнес заводит Запрос на изменение в специальной системе, так называемый RFC. RFC поступает к владельцу продукта. Все приложение поделено на 5 условных частей и есть соответственно 5 scrum-команд: 

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

Администраторы, кстати не относятся ни к какой команде, а привлекаются по мере необходимости. Затем уже прогрумленные задачи включаются в спринт. Таким образом в спринт может, например войти – «провести анализ по RFC», следовательно над задачей уже работают, но в релиз она не войдет. По окончании разработки, но до передачи задачи в тестирование проводится УАТ, приемочное тестирование, на котором заказчик смотрит, что сделали именно то, что он хотел. В УАТ обязательно участвует сотрудник технической поддержки и как раз вот этот момент – это чистый DevOps. Сотрудник техподдержки так же как и заказчик может сразу высказать свои замечания, например сообщить, что вот эти моменты нужно переделать, здесь обязательно добавить логирование, уточнить по планируемой нагрузке на систему в условных попугаях и дать предположение о необходимости оптимизации решения ДО его выпуска в продуктив. 

Каждые две недели выполняется так называемый грумминг, когда RFC делятся на мелкие задачи, которые можно поручить одному человеку, будь то бизнес-аналитик, разработчик, тестировщик или администратор. Администраторы, кстати не относятся ни к какой команде, а привлекаются по мере необходимости. Затем уже прогрумленные задачи включаются в спринт. Таким образом в спринт может, например войти – «провести анализ по RFC», следовательно над задачей уже работают, но в релиз она не войдет. По окончании разработки, но до передачи задачи в тестирование проводится УАТ, приемочное тестирование, на котором заказчик смотрит, что сделали именно то, что он хотел. В УАТ обязательно участвует сотрудник технической поддержки и как раз вот этот момент – это чистый DevOps. Сотрудник техподдержки так же как и заказчик может сразу высказать свои замечания, например сообщить, что вот эти моменты нужно переделать, здесь обязательно добавить логирование, уточнить по планируемой нагрузке на систему в условных попугаях и дать предположение о необходимости оптимизации решения ДО его выпуска в продуктив. 

Перед выпуском релиза команда сообщает список задач, которые готовы к выпуску в релиз и помещает весь готовый к выпуску в продуктив код в релизное хранилище

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

Начинается регрессионное тестирование. На текущий момент оно длится около полутора дней и состоит примерно из 240 регрессионных тестов. По окончании регрессионного тестирования принимается решение о выпуске релиза. После выпуска релиза свою работу начинает техподдержка, анализируются основные показатели работоспособности системы, такие как APDEX, нагрузка на систему, анализ технологического журнала на количество эксепшенов, время ожиданий на блокировках и еще несколько десятков параметров. Кроме того внимательно изучаются все поступающие инциденты. На основании полученных данных заводятся дефекты с критичностью от 1 до 4, где 1 – полная остановка системы в результате дефекта, а 4 – есть ошибка на неосновном функционале имеющая обходное решение. 

Таким образом можно сказать, что в имеющихся условиях (например мы по закону не имеем права предоставлять разработчикам доступ в продуктивную систему, а так же сотрудник, который пишет код – не имеет права самостоятельно его тестировать), так вот, в имеющихся условиях мы смогли обеспечить максимальную интеграцию всех участников процесса. Ставим Check. 

«К 2027 году дефицит составит около 2 млн человек»

Юлия Санина
Директор по персоналу и работе с университетами SAS Россия/СНГ

— Дефицит кадров, безусловно, есть, и он был всегда, поскольку на рынке труда в ИT спрос всегда превышал предложение. Сейчас российские вузы ежегодно выпускают около 60 000 молодых специалистов по ИT-специальностям, а для восполнения дефицита требуется на 40 000 больше — и это если считать, что называется, «по головам», без учета квалификации. А с ней тоже не все так просто, потому что в вузах нередко делается упор на теоретическую составляющую, а с практикой студенты почти не имеют дела. В результате их сложно считать готовыми специалистами после получения диплома. Но даже в чисто количественном плане — если ничего не предпринимать, то, по нашим подсчетам, к 2027 году дефицит составит около 2 млн человек:

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

Но проблема заключается не только в том, чтобы найти подходящего специалиста, — его нужно удержать. Поскольку спрос высок, конкуренты могут переманивать сотрудников. Если речь идет о высококлассном специалисте, то, как правило, финансовый фактор здесь не будет играть серьезной роли: по умолчанию предполагается, что уровень оплаты достаточно высок независимо от конкретной компании

Поэтому очень важно предложить интересные задачи, создать в компании благоприятную атмосферу, придать работе социальную значимость и так далее

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

Работодателям нужно быть готовыми предложить специалисту что-то помимо высокой зарплаты.

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

Фото: lenta.ru

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

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

Поэтому мы приходим в вузы — например, в НИУ ВШЭ на факультете компьютерных наук работает базовая кафедра SAS. Сотрудничаем с МГУ, РУДН, Российской экономической школой, Томским политехническим университетом и другими ведущими вузами. Тем самым мы стараемся усилить программы подготовки специалистов в области анализа данных и привнести накопленную компанией бизнес-экспертизу в учебный процесс.

Ops’ы такие разные

Мы двигаемся дальше и вновь наличие большого круга обязанностей и недостаток квалифицированных кадров толкает нас на жесткую специализацию, как грибы после дождя, появляются различные Operations:

• TechOps — системные администраторы эникеи aka HelpDesk Engineer
• LiveOps — системные администраторы, преимущественно отвечающие за продуктивные среды
• CloudOps — системные администраторы специализирующиеся на публичных «облаках» Azure, AWS, GCP, etc.
• PlatOps/InfraOps/SysOps — системные администраторы инфраструктуры.
• NetOps — сетевые администраторы
• SecOps — системные администраторы специализирующиеся на информационной безопасности — PCI compliance, CIS compliance, patching, etc.

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

Для выполнения подобного рода работ и обязанностей данная персона должна иметь средства управления не только процессами разработки, тестирования, но и управления инфраструктурой продукта, а также планирования ресурсов. DevOps в данном понимании не может находится ни в IT, ни в R&D, ни даже в PMO, он должен иметь влияние во всех этих областях — технический директор компании, Chief Technical Officier.

Так ли это в вашей компании? — Сомневаюсь. В большинстве случаев это или IT, или R&D.

Недостаток средств и возможности влияния хотя бы на одно из этих трех направлений деятельности произведет смещение веса проблем в сторону где эти изменения проще применить, как например применение технических ограничений на релизы в связи с «грязным» кодом по данным систем статического анализатора. То есть когда PMO устанавливает жесткий срок на выпуск функционала, R&D не может выдать качественный результат в эти сроки и выдает его как может, оставив рефакторинг на потом, DevOps относящийся к IT, техническими средствами блокирует релиз. Недостаток полномочий на изменение ситуации, в случае с ответственными сотрудниками ведет к проявлению гиперответственности за то, на что они не могут повлиять, тем паче если эти сотрудники понимают и видят ошибки, и как их исправить — «Счастье в неведении», и как следствие к выгоранию и потери этих сотрудников.