Die onderwerp van DevOps en IaC is baie gewild en groei vinnig. Die meeste skrywers hanteer egter suiwer tegniese probleme langs die pad. Ek sal die probleme spesifiek vir 'n groot maatskappy beskryf. Ek het nie 'n oplossing nie - probleme, oor die algemeen, is noodlottig en lΓͺ in die veld van burokrasie, oudit en "sagte vaardighede".
Aangesien die titel van die artikel so is, sal Daenerys as 'n kat optree, nadat hy oorgegaan het na die kant van Enterprise
Ongetwyfeld is daar nou 'n botsing van oud en nuut. En dikwels in hierdie botsings is daar nie reg of verkeerd nie. Dit het net so gebeur. Maar om nie ongegrond te wees nie, begin ons met hierdie skerm:
Dit is die sogenaamde veranderingsversoek. Jy sien ongeveer 'n derde van die velde wat ingevul moet word uit verskeie gidse, die res van die velde is in ander oortjies. So 'n dokument moet ingevul word om die skrif op die produksiebediener toe te pas, of nuwe lΓͺers op te laai en in die algemeen iets te verander.
Die aantal velde is sodanig dat ek my klein outomatisering geskryf het om hierdie velde in te vul. Boonop is hierdie bladsy so geskryf dat geen outomatiseringsinstrumente sy velde sien nie, en die enigste moontlike oplossing was om AutoIt te gebruik om dom koΓΆrdinate met die muis te slaan. Evalueer die mate van desperaatheid om hieroor te besluit:
So, jy neem jenkins, sjef, terraform, nexus ensovoorts, en ontplooi dit alles met vreugde op jou dev. Maar dit is tyd om dit na QA, UAT en PROD te stuur. Jy het 'n Nexus-artefak en jy ontvang 'n brief van DBA met iets soos hierdie:
Geagte,
Eerstens, jou nexus, jy kan jou voorstel ek het nie toegang tot jou nexus nie
Tweedens moet alle veranderinge as 'n veranderingsversoek ingedien word.
Jy moet die SQL-skrifte van Nexus isoleer en dit aan die veranderingsversoek heg.
As die verandering nie 'n noodgeval is nie, moet dit binne 7 dae na die vrystelling gedoen word (uitsluitlik op die naweek)
Wanneer jou veranderingsversoek deur 'n klomp mense goedgekeur word, sal die DBA jou skrif uitvoer en selfs 'n skermskoot van die resultaat per pos stuur.Die uwe, jou DBA, wat sedert die hoofraam hier werk.
Weet jy waaraan dit my herinner? Semi-outomatisering: die robot hou die raam vas, en die werker slaan dit met 'n voorhamer. Wel, regtig, wat is die nut van hierdie Nexus, as alles dan heeltemal met die hand gedoen word?
Maar moenie Enterprise hiervoor blameer nie! Dit is natuurlik bloederig, maar al hierdie burokrasie met Change Requests word gedwing en kom van die ouditeure. Onderneming moet so werk, punt. Hy kan dit nie anders doen nie. En oudit is 'n baie konserwatiewe ding. Hoeveel is daar byvoorbeeld al gesΓͺ oor die feit dat lang pseudo-komplekse en gereeld veranderde wagwoorde sleg is, maar ondernemings sal die laaste plek wees om dit te verander. Ook met ontplooiings en alles anders.
Terloops, ek het op 'n tyd probeer om 'n lΓͺer vir terraform te skep, maar ek het nie daarin geslaag nie. Ek het gestruikel oor die betekenis van die 'Project Accounting Billing Code'-etiket, wat ek nooit kon uitvind nie - ek het nie genoeg sagte vaardighede gehad nie.
Ek neem nie eers die onderwerp van passiewe Luddisme aan nie - o, jou outomatisering bedreig my werksekerheid, ek wil niks nuuts leer nie, so ek sal rustig saboteer.
So, wat kan die oplossing wees? Die ITSM-stelsel het 'n uiters primitiewe API om dokumente outomaties te genereer. En oor die algemeen kom die meeste van hierdie stelsels uit die dae van hooframe. Miskien ken iemand werklik moderne ITSM-stelsels? Miskien het iemand 'n suksesvolle ervaring met die integrasie van moderne DevOps en burokrasie? Dit gaan natuurlik nie oor suiwer korrupte terreine, waar dit werklik elke dag ontplooi kan word nie, maar byvoorbeeld die banksektor, wat onder ouditeure en baie sterk isolasie van hoΓ«r omgewings is.
Moet net nie vergeet dat al jou fantasieΓ« beperk is tot ouditering nie. En dit verander alles. Wag vir jou in die kommentaar!
Bron: will.com