Тэма 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