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