Темата за DevOps и IaC е много популярна и напредва бързо. Въпреки това, повечето автори обсъждат изцяло техническите проблеми на този път. Аз обаче ще опиша проблемите, характерни за голяма компания. Нямам решения — проблемите, общо взето, са фатални и попадат в сферата на бюрокрацията, одита и "soft skills".
Ако заглавието на статията е такова, тогава котката ще бъде Дайнерис, преминала на страната на Enterprise.
Несъмнено, сега се получава сблъсък между старото и новото. И често в тези колизии няма нито прави, нито виновни. Просто така се е стекло. Но, за да не бъда голословен, ще започнем ето от този екран:
Това е така нареченият Change Request. Вие виждате приблизително една трета от полетата, които трябва да се попълнят от разнообразни справочници, останалите полета – в други раздели. Такъв документ трябва да бъде попълнен, за да се приложи скрипт към production. сървър, или да се качат нови файлове и изобщо да се направи каквото и да било.
Броят на полетата е такъв, че написах малка автоматизация за попълване на тези полета. Освен това, тази страница е написана така, че никакви средства за автоматизация не виждат нейните полета, и единственото възможно решение беше да използвам AutoIt, за да кликвам по координати. Оценете степента на отчаяние, за да се реши на такова:
Е, вие взимате jenkins, chef, terraform, nexus и още много, и радостно деплойвате всичко това на своя dev. Но идва моментът да го изпратите на QA, UAT и PROD. Artifakt от Nexus имате и получавате имейл от DBA с текст подобен на този:
Уважаеми,
На първо място, вашият nexus е с ограничен достъп и нямам достъп до вашия Nexus.
На второ място, всички промени трябва да бъдат оформени като Change Request.
SQL скриптовете трябва да извлечете от Nexus и да ги прикачите към Change Request.
Ако промяната не е спешна, трябва да го направите в рамките на 7 дни от релиза (изключително през уикенда).
Когато вашият Change Request бъде одобрен от много хора, DBA ще изпълни вашия скрипт и дори ще изпрати имейл със скрийншот на резултата.С уважение, вашият DBA, който работи тук от времена на mainframe.
Знаете ли какво ми напомня това? Полуавтоматизация: робот държи станината, а работник удря с чук по нея. Наистина, каква е ползата от този Nexus, ако всичко след това се прави напълно ръчно?
Но не бива да се обвинява Enterprise! Той, разбира се, е жесток, но цялата тази бюрократия с Change Requests е непременно и произтича от аудиторите. Enterprise е длъжен да работи по този начин, и точка. Няма как да бъде иначе. Аудитът е изключително консервативен процес. Колко, например, се говори за това, че дългите псевдо-комплекси и често променящи се пароли са лоши, но предприятията ще бъдат последните, които ще направят промяна. Същото важи и за деплойments и всичко останало.
Между другото, някога се опитах да създам файл за terraform, но не успях. Затрудних се с значението на таг ‘Project Accounting Billing Code’, което така и не успях да разбера — не достигнаха ми soft skills.
Дори не споменавам темата за пасивния луддизъм — ох, вашата автоматизация заплашва моята работна сигурност, няма да уча нещо ново, така че ще саботирам тихо.
Какво може да бъде в принцип решение? Системата ITSM има изключително примитивен API, за да генерира автоматично документи. И изобщо, повечето от тези системи произлизат от времето на мейнфреймовете. Може би някой знае наистина съвременни системи ITSM? Може би има някой с успешен опит в интегрирането на съвременен DevOps и бюрокрация? Става дума не толкова за чисто търговски сайтове, където действително може да има деплой всеки ден, а, например, за банковата сфера, която е под наблюдение на аудитори и с много силна изолация на по-високите среди.
Само не забравяйте, че всички ваши фантазии са ограничени от аудита. И това променя всичко. Очаквам ви в коментарите!
Източник: habr.com
