Téma DevOps a IaC je velmi populární a rychle se rozvíjí. Většina autorů se však zaměřuje pouze na technické problémy na této cestě. Já se zaměřím na problémy, které jsou charakteristické pro velkou společnost. Nemám žádné řešení — problémy jako takové jsou fatální a leží v oblasti byrokracie, auditu a „soft skills“.
Pokud je název článku takový, pak jako maskot vystupuje Daenerys, která přešla na stranu Enterprise.
Nepochybně nyní dochází ke střetu starého a nového. A často v těchto kolizích nejsou žádní praví ani viníci. Tak to prostě je. Ale abych nebyl bez argumentů, začneme tímto obrazovkou:
Toto je takzvaný Change Request. Vidíte přibližně třetinu polí, která je třeba vyplnit z různých příruček, ostatní pole se nacházejí v jiných záložkách. Tento dokument je nutné vyplnit, abyste mohli aplikovat skript na produkci. serveru, nebo nahrát nové soubory a vůbec jakoukoli změnu provést.
Počet polí je tak vysoký, že jsem napsal svoji malou automatizaci pro vyplnění těchto polí. A tato stránka je napsána tak, že žádné automatizační nástroje nevidí její pole, a jediným možným řešením bylo použít AutoIt, aby jsem mohl prostě klikat myší na souřadnice. Oceněte míru zoufalství, abyste se k takovému kroku odvážili:
Takže vezmete Jenkins, Chef, Terraform, Nexus a další a radostně to všechno nasadíte na svém dev. Ale nastává čas poslat to na QA, UAT a PROD. Artifact Nexus máte a dostáváte e-mail od DBA přibližně s takovýmto textem:
Vážený,
Za prvé, váš Nexus si nemůžu nechat, nemám přístup k vašemu Nexus.
Za druhé, všechny změny musí být zformulovány jako Change Request.
SQL skripty musíte extrahovat z Nexus a připojit je k Change Request.
Pokud změna není nouzová, je třeba to udělat do 7 dnů od vydání (výhradně o víkendu).
Když váš Change Request schválí spousta lidí, DBA provede váš skript a dokonce vám pošle screenshot výsledku e-mailem.S pozdravem, váš DBA, který tu pracuje od dob mainframe.
Víš, na co mi to připomíná? Poloviční automatizaci: robot drží základnu, zatímco dělník na ni mlátí kladivem. No opravdu, jaký má smysl mít Nexus, když se nakonec všechno dělá úplně ručně?
Ale nemělo by se to dávat za vinu Enterprise! Samozřejmě, že je krvavý, ale celá ta byrokracie se žádostmi o změnu je nutná a vychází od auditorů. Enterprise musí fungovat takto, a tečka. Jinak to prostě nejde. A audit je velmi konzervativní záležitost. Kolik bylo například řečeno o tom, že dlouhá pseudo-složitá a často měněná hesla jsou špatná, ale podniky budou posledním místem, kde se to změní. To samé platí pro nasazení a vše ostatní.
Mimochodem, kdysi jsem se snažil vytvořit soubor pro terraform, ale nepodařilo se mi to. Narazil jsem na význam tagu 'Project Accounting Billing Code', který jsem se nedozvěděl - chyběly mi soft skills.
Ani se nezmiňuji o tématu pasivního luddismu - ach, vaše automatizace ohrožuje mou pracovní bezpečnost, nechci se učit nic nového, takže budu tiše sabotovat.
A jaké může být v zásadě řešení? Systém ITSM má extrémně primitivní API, aby mohl automaticky generovat dokumenty. A vůbec, většina takových systémů pochází z dob mainframů. Možná někdo zná skutečně moderní systémy ITSM? Možná někdo má úspěšnou zkušenost s integrací moderního DevOps a byrokracie? Samozřejmě nemluvím o čistě prodejních stránkách, kde může být skutečné nasazení každý den, ale například o bankovním sektoru, který podléhá auditorům a má velmi silnou izolaci vyšších prostředí.
Jen nezapomeňte, že všechny vaše fantazie jsou omezeny auditem. A to všechno mění. Těším se na vaše komentáře!
Zdroj: habr.com
