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