Темата DevOps и IaC е многу популарна и брзо се развива. Сепак, повеќето автори се занимаваат со чисто технички проблеми на овој пат. Ќе ги опишам проблемите карактеристични за една голема компанија. Немам решение - проблемите, генерално, се фатални и лежат во областа на бирократијата, ревизијата и „меките вештини“.
Бидејќи насловот на статијата е вака, Денерис, која отиде на страната на Ентерпрајз, ќе се однесува како мачката.
Несомнено, сега има судир на старо и ново. И често во овие судири нема ниту правилно ниту погрешно. Така се случи. Но, за да не бидеме неосновани, ќе започнеме со овој екран:
Ова е таканареченото барање за промена. Гледате околу една третина од полињата што треба да се пополнат од различни директориуми, останатите полиња се во други обележувачи. Таков документ мора да се пополни за да се примени скриптата на продукцискиот сервер, или да се прикачат нови датотеки или генерално да се промени нешто.
Бројот на полиња е таков што напишав сопствена мала автоматизација за пополнување на овие полиња. Покрај тоа, оваа страница е напишана на таков начин што ниту една алатка за автоматизација не може да ги види нејзините полиња, а единственото можно решение беше да се користи AutoIt за глупаво кликнување на координатите со глувчето. Проценете го вашето ниво на очај да го направите ова:
Значи, земате џенкинс, готвач, тераформ, нексус, итн., и среќно го распоредувате сето тоа на вашиот развој. Но, дојде време да го испратиме до QA, UAT и PROD. Имате артефакт на Nexus и добивате писмо од DBA со вакво нешто:
Мил,
Како прво, вашата врска што можете да ја имате за себе, јас немам пристап до вашиот Nexus
Второ, сите промени мора да бидат издадени како барање за промена.
Треба да ги извадите SQL скриптите од Nexus и да ги прикачите на барањето за промена.
Ако промената не е итна, тоа треба да се направи 7 дена пред објавувањето (исклучиво за викенд)
Кога вашето барање за промена ќе биде одобрено од еден куп луѓе, DBA ќе ја изврши вашата скрипта, па дури и ќе испрати скриншот од резултатот по пошта.Со почит, вашиот DBA кој работи овде од деновите на мејнфрејм.
Знаеш ли на што ме потсетува ова? Полуавтоматизација: роботот ја држи рамката, а работникот ја удира со чекан. Па, навистина, што е поентата на овој Nexus ако тогаш сè е направено целосно рачно?
Но, Enterprise не треба да се обвинува за ова! Тоа е, се разбира, крваво, но сета оваа бирократија со Барањата за промена е изнудена и доаѓа од ревизори. Претпријатието мора да работи на овој начин, точка. Тој не може да го направи тоа на друг начин. А ревизијата е многу конзервативна работа. На пример, колку е кажано за фактот дека долгите псевдокомплексни и често менувани лозинки се лоши, но претпријатијата ќе бидат последното место каде што ќе се менува. Исто така со распоредувања и се останато.
Патем, едно време се обидов да создадам датотека за terraform, но тоа не функционираше. Наидов на значењето на ознаката „Проект за сметководство за наплата“, што никогаш не успеав да го дознаам - немав доволно меки вештини.
Јас дури и не се занимавам со темата за пасивен лудизам - ох, вашата автоматизација ја загрозува мојата безбедност на работа, не сакам да научам ништо ново, па тивко ќе го саботирам.
Па, што би можело да биде решението во принцип? Системот ITSM има исклучително примитивен API за автоматско генерирање документи. И воопшто, повеќето од овие системи потекнуваат од времето на големите компјутери. Дали некој знае некој навистина модерни ITSM системи? Дали некој има успешно искуство со интегрирање на модерни DevOps и бирократија? Ние, се разбира, не зборуваме за чисто продажни места, каде што всушност може да има распоредување секој ден, туку, на пример, за банкарскиот сектор, кој е под ревизори и многу силна изолација во повисоките средини.
Само не заборавајте дека сите ваши фантазии се ограничени со ревизија. И тоа менува сè. Ве чекам во коментари!
Извор: www.habr.com