Téma DevOps a IaC je velmi oblíbené a rychle se rozvíjející. Většina autorů se však touto cestou zabývá čistě technickými problémy. Popíšu problémy charakteristické pro velkou společnost. Nemám řešení – problémy jsou obecně fatální a leží v oblasti byrokracie, auditu a „soft skills“.
Vzhledem k tomu, že název článku je takový, bude Daenerys, která přešla na stranu Enterprise, vystupovat jako kočka.
Nyní nepochybně dochází ke střetu starého a nového. A často v těchto kolizích není ani správné, ani špatné. Tak se to stalo. Ale abychom nebyli neopodstatnění, začneme touto obrazovkou:
Jedná se o tzv. Žádost o změnu. Vidíte asi třetinu polí, která je potřeba vyplnit z různých adresářů, zbývající pole jsou v jiných záložkách. Takový dokument musí být vyplněn, aby bylo možné aplikovat skript na produkční server, nahrát nové soubory nebo obecně cokoliv změnit.
Počet polí je takový, že jsem si napsal vlastní malou automatiku pro vyplňování těchto polí. Navíc je tato stránka napsána tak, že její pole nevidí žádné automatizační nástroje a jediným možným řešením bylo pomocí AutoIt hloupě klikat myší na souřadnice. Zhodnoťte svou míru zoufalství, abyste to udělali:
Takže vezmete jenkins, chef, terraform, nexus atd. a šťastně to všechno nasadíte do svého vývojáře. Ale nadešel čas poslat to QA, UAT a PROD. Máte artefakt Nexus a dostanete dopis od DBA s něčím takovým:
Vážení
Za prvé, váš nexus, který můžete mít pro sebe, nemám přístup k vašemu zařízení Nexus
Za druhé, všechny změny musí být vydány jako žádost o změnu.
Je třeba extrahovat skripty SQL ze zařízení Nexus a připojit je k požadavku na změnu.
Pokud změna není nouzová, měla by být provedena 7 dní před vydáním (výhradně o víkendu)
Když váš požadavek na změnu schválí spousta lidí, DBA spustí váš skript a dokonce pošle snímek obrazovky s výsledkem poštou.S pozdravem váš DBA, který zde pracuje od dob sálových počítačů.
Víte, co mi to připomíná? Poloautomatizace: robot drží rám a pracovník do něj udeří perlíkem. No, popravdě, k čemu je tento Nexus, když se pak vše dělá kompletně ručně?
Ale Enterprise by za to neměla být obviňována! Je to samozřejmě krvavé, ale veškerá tato byrokracie s požadavky na změnu je vynucená a pochází od auditorů. Podnik musí fungovat tímto způsobem, tečka. On to ani jinak neumí. A audit je velmi konzervativní záležitost. Například, kolik toho bylo řečeno o tom, že dlouhá pseudosložitá a často měněná hesla jsou špatná, ale podniky budou posledním místem, kde se to bude měnit. Také s nasazením a vším ostatním.
Mimochodem, najednou jsem se snažil vytvořit soubor pro terraform, ale nefungovalo to. Narazil jsem na význam tagu 'Project Accounting Billing Code', který se mi nikdy nepodařilo zjistit - neměl jsem dostatek měkkých dovedností.
Nezabývám se ani tématem pasivního ludismu - ach, vaše automatizace ohrožuje moji jistotu práce, nechci se učit nic nového, tak to tiše sabotuji.
No, jaké by mohlo být principiální řešení? Systém ITSM má extrémně primitivní API pro automatické generování dokumentů. A vůbec, většina těchto systémů pochází z dob sálových počítačů. Zná někdo nějaké skutečně moderní ITSM systémy? Má někdo úspěšnou zkušenost s integrací moderních DevOps a byrokracie? Nemluvíme samozřejmě o čistě prodejních stránkách, kde skutečně může docházet k nasazení každý den, ale například o bankovním sektoru, který je ve vyšších prostředích pod auditory a velmi silnou izolací.
Jen nezapomeňte, že všechny vaše fantazie jsou omezeny auditem. A to vše mění. Těším se na vás v komentářích!
Zdroj: www.habr.com