Песен от лед (Кърваво предприятие) и огън (DevOps и IaC)

Темата за DevOps и IaC е много популярна и се развива бързо. Повечето автори обаче се занимават с чисто технически проблеми по този път. Ще опиша проблемите, характерни за голяма компания. Нямам решение - проблемите като цяло са фатални и са в сферата на бюрокрацията, одита и "меките умения".

Тъй като заглавието на статията е такова, Дейнерис, която премина на страната на Ентърпрайз, ще играе ролята на котката.

Несъмнено сега има сблъсък на старо и ново. И често в тези сблъсъци няма нито правилно, нито грешно. Така и стана. Но за да не бъдем голословни, ще започнем с този екран:

Това е така наречената заявка за промяна. Виждате около една трета от полетата, които трябва да бъдат попълнени от различни директории, останалите полета са в други отметки. Такъв документ трябва да бъде попълнен, за да приложите скрипта към производствения сървър или да качите нови файлове, или като цяло да промените нещо.

Броят на полетата е такъв, че написах моя собствена малка автоматизация за попълване на тези полета. Освен това тази страница е написана по такъв начин, че никакви инструменти за автоматизация не могат да видят нейните полета и единственото възможно решение беше да се използва AutoIt за глупаво кликване върху координатите с мишката. Оценете нивото си на отчаяние, за да направите това:

И така, вие вземате jenkins, chef, terraform, nexus и т.н. и щастливо ги разгръщате на вашия разработчик. Но идва моментът да го изпратите до QA, UAT и PROD. Имате артефакт на Nexus и получавате писмо от DBA с нещо подобно:

Уважаеми,

Първо, вашият Nexus можете да имате за себе си. Нямам достъп до вашия Nexus
Второ, всички промени трябва да бъдат издадени като заявка за промяна.
Трябва да извлечете SQL скриптовете от Nexus и да ги прикачите към заявката за промяна.
Ако промяната не е спешна, това трябва да се направи 7 дни преди освобождаването (изключително през уикенда)
Когато вашата заявка за промяна бъде одобрена от куп хора, DBA ще изпълни вашия скрипт и дори ще изпрати екранна снимка на резултата по пощата.

Най-добри пожелания, вашият DBA, който работи тук от дните на мейнфрейм.

Знаете ли на какво ми напомня това? Полуавтоматизация: роботът държи рамката, а работникът я удря с чук. Е, наистина, какъв е смисълът от този Nexus, ако тогава всичко се прави напълно ръчно?

Но Enterprise не трябва да бъде обвиняван за това! Разбира се, че е кърваво, но цялата тази бюрокрация с Change Requests е принудителна и идва от одитори. Предприятието трябва да работи по този начин, точка. Той не може по друг начин. А одитът е много консервативно нещо. Например, колко много е казано за факта, че дългите псевдо-сложни и често променяни пароли са лоши, но предприятията ще бъдат последното място, където това ще бъде променено. Също така с внедрявания и всичко останало.

Между другото, по едно време се опитах да създам файл за terraform, но не се получи. Случайно попаднах на значението на тага 'Project Accounting Billing Code', което така и не успях да разбера - нямах достатъчно soft skills.

Дори не се занимавам с темата за пасивния лудизъм - о, вашата автоматизация застрашава сигурността на работата ми, не искам да научавам нищо ново, така че тихо ще го саботирам.

Е, какво може да е принципното решение? Системата ITSM има изключително примитивен API за автоматично генериране на документи. И като цяло повечето от тези системи идват от времето на мейнфреймите. Някой знае ли наистина модерни ITSM системи? Някой има ли успешен опит с интегрирането на модерни DevOps и бюрокрация? Разбира се, не говорим за чисто търговски сайтове, където всъщност може да има внедряване всеки ден, а например за банковия сектор, който е под одитори и много силна изолация в по-високи среди.

Само не забравяйте, че всички ваши фантазии са ограничени от одита. И това променя всичко. Очаквам ви в коментарите!

Източник: www.habr.com