Ämnet DevOps och IaC är mycket populärt och utvecklas snabbt. De flesta författare hanterar dock rent tekniska problem längs denna väg. Jag kommer att beskriva de problem som kännetecknar ett stort företag. Jag har ingen lösning - problemen i allmänhet är ödesdigra och ligger inom området byråkrati, revision och "mjuka färdigheter".
Eftersom rubriken på artikeln är så här kommer Daenerys, som har gått över till Enterprise, att fungera som katten.
Utan tvekan är det nu en kollision mellan gammalt och nytt. Och ofta i dessa kollisioner finns det varken rätt eller fel. Det blev bara så. Men för att inte vara ogrundade börjar vi med den här skärmen:
Detta är den så kallade Change Request. Du ser ungefär en tredjedel av fälten som behöver fyllas i från olika kataloger, resterande fält finns i andra bokmärken. Ett sådant dokument måste fyllas i för att kunna applicera skriptet på produktionsservern, ladda upp nya filer eller generellt ändra något.
Antalet fält är sådant att jag skrev min egen lilla automation för att fylla i dessa fält. Dessutom är den här sidan skriven 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 dumt klicka på koordinaterna med musen. Bedöm din nivå av desperation för att göra detta:
Så, du tar jenkins, kock, terraform, nexus, etc., och distribuerar gärna allt till din utvecklare. Men det är dags att skicka det till QA, UAT och PROD. Du har en Nexus-artefakt och du får ett brev från DBA med något sånt här:
Kära,
Först och främst, din nexus du kan ha själv. Jag har inte tillgång till din Nexus
För det andra måste alla ändringar skickas som en ändringsbegäran.
Du måste extrahera SQL-skripten från Nexus och bifoga dem till ändringsbegäran.
Om ändringen inte är nödsituation, bör detta göras 7 dagar före release (endast på helgen)
När din ändringsbegäran har godkänts av ett gäng människor kommer DBA att köra ditt skript och till och med skicka en skärmdump av resultatet per post.Med vänliga hälsningar, din DBA som har arbetat här sedan stordatorns dagar.
Vet du vad det här påminner mig om? Halvautomatisering: roboten håller ramen och arbetaren slår den med en slägga. Tja, egentligen, vad är poängen med denna Nexus om allt sedan görs helt manuellt?
Men Enterprise ska inte klandras för detta! Det är förstås blodigt, men all denna byråkrati med Change Requests är påtvingad och kommer från revisorer. Företag måste fungera på det här sättet, punkt. Han kan inte göra det på något annat sätt. Och revision är en mycket konservativ sak. Till exempel, hur mycket har sagts om att långa pseudokomplexa och ofta ändrade lösenord är dåliga, men företag kommer att vara den sista platsen där detta kommer att ändras. Även med utplaceringar och allt annat.
Förresten, vid ett tillfälle försökte jag skapa en fil för terraform, men det fungerade inte. Jag snubblade över innebörden av taggen 'Project Accounting Billing Code', som jag aldrig lyckades ta reda på - jag hade inte tillräckligt med mjuka färdigheter.
Jag tar inte ens upp ämnet passiv luddism - åh, din automatisering hotar min anställningstrygghet, jag vill inte lära mig något nytt, så jag ska tyst sabotera det.
Ja, vad kan lösningen vara i princip? ITSM-systemet har ett extremt primitivt API för automatisk generering av dokument. Och i allmänhet kommer de flesta av dessa system från stordatorernas tider. Är det någon som känner till några riktigt moderna ITSM-system? Har någon framgångsrik erfarenhet av att integrera moderna DevOps och byråkrati? Vi pratar givetvis inte om rena säljsajter, där det faktiskt kan bli en utplacering varje dag, utan till exempel banksektorn som är under revisorer och mycket stark isolering i högre miljöer.
Glöm bara inte att alla dina fantasier begränsas av revisionen. Och det förändrar allt. Jag väntar på dig i kommentarerna!
Källa: will.com