Isens sång (blodig Enterprise) och eld (DevOps och IaC)

Ämnet DevOps och IaC är mycket populärt och utvecklas snabbt. Men de flesta författare berör enbart de tekniska problemen på denna väg. Jag kommer istället att beskriva de problem som är typiska för stora företag. Jag har inga lösningar — problemen är i stort sett fatala och ligger inom områdena byråkrati, revision och "soft skills".

Om artikeln har ett sådant namn, så kommer Daenerys, som har gått över till Enterprise, att agera katt.

Utan tvekan sker det nu en kollision mellan gammalt och nytt. Och ofta finns det ingen som har rätt eller fel i dessa kollisioner. Så har det blivit. Men för att inte bara prata ska vi börja med denna skärm:

Detta är så kallad Change Request. Du ser ungefär en tredjedel av fälten som måste fyllas i från olika register, medan de andra fälten finns på andra flikar. Detta dokument måste fyllas i för att kunna tillämpa skriptet på production. servern, eller för att ladda upp nya filer och överhuvudtaget förändra något.

Antalet fält är sådant att jag har skrivit min egen lilla automatisering för att fylla i dessa fält. Denna sida är utformad på ett sådant sätt att inga automatiseringsverktyg kan se dess fält, och den enda möjliga lösningen var att använda AutoIt för att helt enkelt klicka med musen på koordinater. Bedöm graden av desperation för att våga göra något sådant:

Så du tar jenkins, chef, terraform, nexus och annat och jublar över att du distribuerar allt detta på din dev. Men det kommer en tid att skicka detta till QA, UAT och PROD. Du har artefakten i Nexus och får ett meddelande från DBA med ungefär följande text:

Bästa hälsningar,

För det första, din nexus har jag inte tillgång till er Nexus.
För det andra, alla ändringar måste dokumenteras som en Change Request.
SQL-skripten måste du extrahera från Nexus och bifoga till Change Request.
Om ändringen inte är en nödsituation, bör detta göras inom 7 dagar efter releasen (exklusivt under helgen).
När din Change Request har godkänts av en massa människor kommer DBA att köra ditt skript och till och med skicka en skärmdump av resultatet via e-post.

Med vänlig hälsning, din DBA som har jobbat här sedan mainframe.

Vet ni vad detta påminner mig om? Halvautomatisering: roboten håller fast maskinen medan arbetaren slår på den med en slägga. Ja, vad är egentligen vitsen med Nexus om allt sedan görs helt manuellt?

Men man ska inte skylla på Enterprise! Det är självklart blodigt, men all denna byråkrati med Change Requests är nödvändig och kommer från revisorer. Enterprise är tvunget att arbeta så här, och punkt slut. Det finns inget annat sätt. Revision är en oerhört konservativ sak. Hur mycket som helst har sagts om att långa, pseudokomplexa och ofta förändrade lösenord är dåligt, men företag kommer att vara den sista platsen där detta ändras. Detsamma gäller för deployment och allt annat.

För övrigt försökte jag en gång skapa en fil för terraform, men jag misslyckades. Jag snubblade på betydelsen av taggen 'Project Accounting Billing Code', vilken jag aldrig lyckades ta reda på — jag saknade soft skills.

Jag tar inte ens upp ämnet passiv ludditism — åh, er automatisering hotar min jobbsäkerhet, jag vill inte lära mig något nytt, så jag kommer att tysta sabotera.

Och vad kan det egentligen finnas för lösning? ITSM-systemet har en extremt primitiv API för att automatiskt generera dokument. Och överhuvudtaget kommer de flesta sådana system från mainframe-eran. Kanske någon vet om verkligen moderna ITSM-system? Kanske någon har framgångsrik erfarenhet av integration av moderna DevOps och byråkrati? Det handlar självklart inte om rena säljwebbplatser, där det verkligen kan finnas en deployment varje dag, utan, exempelvis, banksektorn som står under revisorer och har en mycket stark isolering av högre miljöer.

Men glöm inte att alla era fantasier är begränsade av revisionen. Och det förändrar allt. Jag ser fram emot era kommentarer!

Källa: habr.com