Кейс из практики DevOps-инженера "ITQ Group".

Привет! Меня зовут Сергей Акимов, я DevOps в ITQ Group. Сегодня хочу поделиться интересным опытом, с которым вообще может столкнуться любой DevOps инженер при автоматизации процесса у заказчика на аутсорсе или даже у In-house работодателя.

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

В этом материале вы сможете ознакомиться вот с такими темами:

• как формируется оптимальное решение для технической и бизнес среды в условиях ограниченного количества вводных данных (спойлер — плохо); 

• наши ошибки в работе над задачей;

• и главное — уроки, которые мы вынесли, получив такой опыт. 

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

Звучит все очень даже просто. Поэтому мы решили написать робота на Python, который заходит в систему и собирает нужные данные: номер планового релиза, номера задач, которые заведены в этом плановом релизе. 

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

Задача усложнилась, но решение снова, казалось, лежало на поверхности.  Мы предложили реализовать робота на Python и развернуть сервисом в Docker, с настройкой автоматизации деплоя, привязанного к GitLab CI. Робот в Docker будет собирать и подготавливать нужные для релиза файлы. 

Радостно вернулись с этим решением к заказчику и уже не столь радостно выяснили, что в их бизнес-контур уже включен Ansible. Он там используется для шаблонизации ручных процессов, которые запускают из веб интерфейса системы AWX. Выкатывать реализацию, которая будет выходить за контур принятой парадигмы, неправильно. Поэтому нашу реализацию на Python и Docker нужно было интегрировать в существующий контур с Ansible. 

В этом тоже вроде нет ничего сложного. Мы предложили очередное решение, в котором GitLab CI расширили на Ansible, с возможностью интеграции в Docker. 

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

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

Нужно придумать другую идею. Окееей, это мы могём!

Теперь решено было привязать нашу реализацию к Ansible за счет создания собственного модуля. Создаем в Ansible роль, которая отвечает за запуск процесса: сбор информации во внутренней системе заказчика, переход в среду стороннего разработчика, скачивание артефактов и перенос этих артефактов в Docker на заранее сформированную структуру релиза. Плейбук системы будет пользоваться этим модулем, чтобы проделать все вышеуказанные операции. 

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

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

Мы анализируем, как связать Python и Oracle, чтобы импортировать обновления в базу данных и автоматически их запускать. Нам думалось, что обновления представляли собой SQL запросы, с которым БД Oracle работать умеет. Но оказалось, что установка на БД проводится со специальным программным обеспечением и это ПО работает только из-под Windows. Как нам скрестить Windows и Linux чтобы запустить нашу утилиту? 

Для того, чтобы перенести артефакты с Linux хоста в Хранилище артефактов, нами было предложено использовать Nexus. 

И вот, мы теперь умеем анализировать, фильтровать, скачивать и сохранять… Кажется горизонт виден! :)

Но не тут-то было! Оказывается без Windows хоста нам просто не обойтись. Утилита установки обновлений - это windows application. И для работы нашей автоматизации нужно было докатывать туда Python с зависимостями, чтобы скрипт работал. 

Заказчику идея не понравилась, он решил, что получается слишком нагруженная реализация и попросил ее упростить. 

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

В результате у нас действительно получились два независимых этапа: 

• На первом этапе мы автоматизируем сбор артефактов для релиза в Docker

• На втором — переносим данные из Linux хоста в Windows и запускаем обновление. 

Задачи первого этапа решаются средствами Python-скрипта и хоста Linux, второй — Powershell и Windows. 

Наконец-то все сложилось! 

Теперь давайте проведем работу над ошибками и определим, что мы делали не так, что нужно было сделать иначе (ну и что ещё предстоит улучшить).

Во-первых, перед постановкой этапов задач не было приведено генеральное объяснение цели. Данные поступали сегментировано, сначала сделайте это, а теперь это и так далее.  

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

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

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

Итак, как должен выглядеть процесс работы над задачей: 

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

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

3. На первом этапе прорисовать контур решения и выяснить все ограничительные условия, которые могут повлиять на реализацию.

4. Узнавать, что делают пользователи в рамках бизнес-процесса, которые нужно автоматизировать. 

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

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

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

Даже если вы проведете встречу с держателем бизнес-процесса, скорее всего он расскажет лишь очевидные вещи, по-партизански умолчав о наличии каких-либо нюансов или подводных камней в работе. И вот только когда такой сотрудник будет загнан в узкие рамки регламента контроля над автоматизируемым процессом, а внедрённая автоматизация даст сбой — он сам придет к вам с разъяснениями и покажет, что он делал для исключения подобных инцидентов. Можно ли это предупредить? На мой взгляд, нет. К таким ситуациям просто нужно быть готовым. 

Итак, когда бизнес не знает этапов, не имеет четкой карты реализации задачи, со стороны разработки возникает широкий угол технологий, которые могут быть использованы.  Это приводит либо к недопониманию, либо к многовекторности достижения цели. Правильно поставленная и скрупулезно объясненная задача сводит пятно фокусировки к цели до 5-10% от первоначального разброса вариантов. 

Подытожим. 

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

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

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

Всем спасибо за внимание!