Тема DevOps и IaC очень популярна и развивается быстро. Однако большинство авторов касаются сугубо технических проблем на этом пути. Я же опишу проблемы, характерные для большой компании. Решения у меня нет — проблемы, в общем, фатальны и лежат в области бюрократии, аудита, и «soft skills».
Раз название статьи такое, то в качестве котика выступит Дайнерис, перешедшая на сторону Enterprise
Несомненно, сейчас происходит столкновение старого и нового. И часто в этих коллизиях нет ни правых, не виноватых. Так уж получилось. Но, чтобы не быть голословным, мы начнем вот с этого экрана:
Это так называемый Change Request. Вы видите примерно треть полей, которые надо заполнить из разнообразных справочников, остальные поля — в других закладках. Такой документ надо заполнить, чтобы применить скрипт к production серверу, или залить новые файлы и вообще, что-либо поменять.
Количество полей таково, что я написал свою маленькую автоматизацию по заполнению этих полей. Причем эта страница написана так, что никакие средства автоматизации не видят ее полей, и единственным возможным решением было использовать AutoIt, чтобы тупо бить мышкой по координатам. Оцените степень отчаяния, чтобы решиться на такое:
Так вот, берете вы jenkins, chef, terraform, nexus и прочее, и радостно деплоите все это на своем dev. Но настает время отправить это на QA, UAT и PROD. Nexus артефакт у вас есть и вы получаете письмо от DBA примерно с таким текстом:
Но не следует в этом винить Enterprise! Он, конечно, кровавый, но вся эта бюрократия с Change Requests вынужденная и идет от аудиторов. Enterprise обязан так работать, и точка. Нельзя ему иначе. А аудит очень консервативная вещь. Сколько, например, говорилось про то, что длинные псевдо-сложные и часто меняемые пароли — плохо, но энтерпрайзы будут последним местом, где это поменяют. Также с деплоями и со всем остальным.
Кстати, в свое время я пытался создать файл для terraform, но у меня не получилось. Споткнулся на значении тега 'Project Accounting Billing Code', который мне так и не удалось узнать — не хватило soft skills.
Я даже не беру тему пассивного луддизма — ой, ваша автоматизация угрожает моей job security, учиться ничему новому я не хочу, поэтому буду тихо саботировать.
Ну и какое может быть в принципе решение? У системы ITSM крайне примитивный API чтобы автоматически генерить документы. Да и вообще, большинство таких систем идет из времен мейнфреймов. Может кто знает действительно современные системы ITSM? Может кто имеет успешный опыт интеграции современных DevOps и бюрократии? Речь, конечно же, идет не про чисто продажные сайты, где реально может быть деплой каждый день, а, например, банковскую сферу, которая под аудиторами и очень сильной изоляцией higher environments.
Только не забывайте, что все ваши фантазии ограничены аудитом. И это все меняет. Жду вас в комментариях!
Раз название статьи такое, то в качестве котика выступит Дайнерис, перешедшая на сторону Enterprise
Несомненно, сейчас происходит столкновение старого и нового. И часто в этих коллизиях нет ни правых, не виноватых. Так уж получилось. Но, чтобы не быть голословным, мы начнем вот с этого экрана:
Это так называемый Change Request. Вы видите примерно треть полей, которые надо заполнить из разнообразных справочников, остальные поля — в других закладках. Такой документ надо заполнить, чтобы применить скрипт к production серверу, или залить новые файлы и вообще, что-либо поменять.
Количество полей таково, что я написал свою маленькую автоматизацию по заполнению этих полей. Причем эта страница написана так, что никакие средства автоматизации не видят ее полей, и единственным возможным решением было использовать AutoIt, чтобы тупо бить мышкой по координатам. Оцените степень отчаяния, чтобы решиться на такое:
Так вот, берете вы jenkins, chef, terraform, nexus и прочее, и радостно деплоите все это на своем dev. Но настает время отправить это на QA, UAT и PROD. Nexus артефакт у вас есть и вы получаете письмо от DBA примерно с таким текстом:
Уважаемый,Знаете что мне это напоминает? Полуавтоматизацию: робот держит станину, а рабочий лупит по ней кувалдой. Ну действительно, какой толк в этом Nexus, если потом все делается полностью вручную?
Во-первых,ваш nexus вы можете себеу меня нет доступа вашему Nexus
Во-вторых, все изменения должны быть оформлены как Change Request.
SQL скрипты вам надо вычленить их Nexus, и приаттачить к Change Request.
Если изменение не Emergency, сделать это следует за 7 дней то релиза (исключительно в Weekend)
Когда ваш Change Request заапрувит куча народу, то DBA выполнит ваш скрипт и даже пришлет по почте скриншот результата.
С уважением, ваш DBA который тут работает со времен mainframe.
Но не следует в этом винить Enterprise! Он, конечно, кровавый, но вся эта бюрократия с Change Requests вынужденная и идет от аудиторов. Enterprise обязан так работать, и точка. Нельзя ему иначе. А аудит очень консервативная вещь. Сколько, например, говорилось про то, что длинные псевдо-сложные и часто меняемые пароли — плохо, но энтерпрайзы будут последним местом, где это поменяют. Также с деплоями и со всем остальным.
Кстати, в свое время я пытался создать файл для terraform, но у меня не получилось. Споткнулся на значении тега 'Project Accounting Billing Code', который мне так и не удалось узнать — не хватило soft skills.
Я даже не беру тему пассивного луддизма — ой, ваша автоматизация угрожает моей job security, учиться ничему новому я не хочу, поэтому буду тихо саботировать.
Ну и какое может быть в принципе решение? У системы ITSM крайне примитивный API чтобы автоматически генерить документы. Да и вообще, большинство таких систем идет из времен мейнфреймов. Может кто знает действительно современные системы ITSM? Может кто имеет успешный опыт интеграции современных DevOps и бюрократии? Речь, конечно же, идет не про чисто продажные сайты, где реально может быть деплой каждый день, а, например, банковскую сферу, которая под аудиторами и очень сильной изоляцией higher environments.
Только не забывайте, что все ваши фантазии ограничены аудитом. И это все меняет. Жду вас в комментариях!
