Het lied van ijs (bloedige Enterprise) en vuur (DevOps en IaC)

Het thema DevOps en IaC is erg populair en ontwikkelt zich snel. Toch behandelen de meeste auteurs uitsluitend technische problemen op deze weg. Ik zal de problemen beschrijven die kenmerkend zijn voor een groot bedrijf. Ik heb geen oplossingen — de problemen zijn over het algemeen dodelijk en liggen op het gebied van bureaucratie, audits en ā€˜soft skills’.

Het lied van ijs (bloedige Enterprise) en vuur (DevOps en IaC)
Als de titel van het artikel zo is, dan zal Daenerys, die aan de kant van Enterprise is gekomen, als de kat fungeren.

Zeker, op dit moment vindt er een botsing plaats tussen het oude en het nieuwe. En vaak zijn er in deze botsingen geen rechtvaardigen noch schuldigen. Zo is het gewoon gelopen. Maar om niet vrijblijvend te zijn, beginnen we met dit scherm:

Het lied van ijs (bloedige Enterprise) en vuur (DevOps en IaC)

Dit is het zogenaamde Change Request. U ziet ongeveer een derde van de velden die u moet invullen vanuit verschillende documenten, de overige velden bevinden zich op andere tabbladen. Dit document moet worden ingevuld om een script op de productie toe te passen. server, of om nieuwe bestanden te uploaden en in het algemeen iets te wijzigen.

Het aantal velden is dusdanig dat ik mijn eigen kleine automatisering heb geschreven voor het invullen van deze velden. Bovendien is deze pagina zo geschreven dat geen enkel automatiseringsmiddel haar velden kan zien, en de enige oplossing was om AutoIt te gebruiken om simpelweg met de muis op coƶrdinaten te klikken. Bedenk de wanhoop die nodig is om tot zoiets te besluiten:

Het lied van ijs (bloedige Enterprise) en vuur (DevOps en IaC)

Dus, je neemt Jenkins, Chef, Terraform, Nexus en meer, en blij ga je dit allemaal op je dev-deployen. Maar dan komt het moment om dit naar QA, UAT en PROD te sturen. Je hebt het Nexus-artifact en je ontvangt een e-mail van de DBA met ongeveer de volgende tekst:

Geachte,

Ten eerste, uw Nexus heeft u, maar ik heb geen toegang tot uw Nexus.
Ten tweede, alle wijzigingen moeten als Change Request worden ingediend.
SQL-scripts moet u uit uw Nexus halen en bij de Change Request voegen.
Als de wijziging geen noodsituatie is, moet dit binnen 7 dagen na de release worden gedaan (uitsluitend in het weekend).
Wanneer uw Change Request door veel mensen is goedgekeurd, zal de DBA uw script uitvoeren en zelfs een screenshot van het resultaat per e-mail sturen.

Met vriendelijke groet, uw DBA die hier werkt sinds de mainframe.

Weet je wat me dit doet denken? Een halfautomatisering: een robot houdt de machine vast, terwijl een werknemer er met een hamer op slaat. Nou, wat heeft Nexus voor zin als alles vervolgens helemaal handmatig gebeurt?

Maar je moet Enterprise hier niet de schuld van geven! Het is inderdaad bloederig, maar al deze bureaucratie rond Change Requests is onvermijdelijk en komt van accountants. Enterprise moet zo werken, en dat is dat. Het kan niet anders. En audit is een uiterst conservatieve kwestie. Hoe vaak is er bijvoorbeeld gesproken over het feit dat lange pseudo-complexe en vaak veranderende wachtwoorden slecht zijn, maar ondernemingen zullen de laatste zijn die dit veranderen. Dit geldt ook voor deploys en alles wat daarbij komt kijken.

Overigens heb ik ooit geprobeerd een bestand voor terraform te maken, maar het is me niet gelukt. Ik stuitte op de betekenis van de tag ā€˜Project Accounting Billing Code’, die ik nooit heb kunnen achterhalen — ik had niet genoeg soft skills.

Ik zal het idee van passieve luddisme niet eens aansnijden — oh, jullie automatisering bedreigt mijn werkzekerheid, ik wil niets nieuws leren, dus ik zal stilletjes saboteren.

Wat kan in principe de oplossing zijn? Het ITSM-systeem heeft een extreem primitieve API om documenten automatisch te genereren. En over het algemeen zijn de meeste van zulke systemen afkomstig uit de tijd van mainframes. Misschien weet iemand echt moderne ITSM-systemen? Heeft iemand succesvolle ervaring met de integratie van moderne DevOps en bureaucratie? Het gaat hier natuurlijk niet om puur commerciƫle sites, waar daadwerkelijk elke dag een deploy plaatsvindt, maar bijvoorbeeld om de banksector, die onder auditors valt en een zeer sterke isolatie van hogere omgevingen heeft.

Vergeet niet dat al jullie fantasieƫn beperkt zijn door de audit. En dat verandert alles. Ik kijk uit naar jullie reacties!

Bron: habr.com

Koop betrouwbare webhosting met bescherming tegen DDoS, VPS VDS servers šŸ”„ Koop betrouwbare webhosting met bescherming tegen DDoS, VPS VDS servers | ProHoster