Téma DevOps a IaC je veľmi populárna a rýchlo sa vyvíja. Väčšina autorov sa však zameriava iba na technické problémy na tejto ceste. Ja opíšem problémy, ktoré sú charakteristické pre veľké firmy. Riešenia nemám – problémy sú v podstate fatálne a sú v oblasti byrokracie, auditu a „soft skills“.
Ak je názov článku taký, potom ako samolepku využijeme Daenerys, ktorá prešla na stranu Enterprise.
Nežne, v súčasnosti dochádza ku konfliktu medzi starým a novým. A často v týchto kolíziách nie sú ani spravodliví, ani vinní. Tak to jednoducho je. Ale aby som nebol nepresný, začneme týmto obrazovkou:
Toto je takzvaný Change Request. Vidíte približne tretinu polí, ktoré je potrebné vyplniť z rôznych príručiek, ostatné polia sú na iných záložkách. Tento dokument je potrebné vyplniť, aby sa mohol skript aplikovať na produkciu. serveru, alebo nahrať nové súbory a v podstate, čokoľvek zmeniť.
Počet polí je taký, že som napísal svoju malú automatizáciu na vyplňovanie týchto polí. A navyše, táto stránka je napísaná tak, že žiadne automatizačné prostriedky nevidia jej polia, a jediným možným riešením bolo použiť AutoIt, aby som proste klikal myšou na koordináty. Zhodnoťte úroveň beznádeje, aby ste sa odvážili na niečo také:
Takže vezmete jenkins, chef, terraform, nexus a ďalšie a s radosťou to všetko nasadíte na svoj dev. Ale nastáva čas poslať to na QA, UAT a PROD. Nexus artefakt máte a dostávate e-mail od DBA s textom približne takýmto:
Vážený,
Po prvé, váš nexus nemôžem prístupovať, pretože nemám prístup k vášmu Nexus.
Po druhé, všetky zmeny musia byť riadne zdokumentované ako Change Request.
SQL skripty musíte extrahovať z Nexus a pripojiť ich k Change Request.
Ak zmena nie je núdzová, mali by ste to spraviť do 7 dní od vydania (výhradne počas víkendov).
Keď váš Change Request schváli množstvo ľudí, DBA vykoná váš skript a dokonca pošle e-mail so screenshotom výsledku.S pozdravom, váš DBA, ktorý tu pracuje od čias mainframe.
Viete, čo mi to pripomína? Poluautomazáciu: robot drží podstavec, a robotník doňho udiera kladivom. No naozaj, aký zmysel má ten Nexus, ak sa potom všetko robí úplne ručne?
Ale netreba v tom viniť Enterprise! Samozrejme, že je krvavý, ale táto byrokracia s Change Requests je nútená a pochádza od audítorov. Enterprise musí takto fungovať a bodka. Inak to ísť nemôže. A audit je veľmi konzervatívna záležitosť. Koľkokrát, napríklad, sa hovorilo o tom, že dlhé pseudo-zložité a často menené heslá sú zlé, ale enterprise budú posledným miestom, kde to zmenia. To platí aj pre deploye a všetko ostatné.
Mimochodom, kedysi som sa snažil vytvoriť súbor pre terraform, ale nepodarilo sa mi to. Narazil som na význam tagu ‘Project Accounting Billing Code’, ktorý som sa nedozvedel — chýbali mi soft skills.
Ani nehovorím o téme pasívneho ludizmu — och, vaša automatizácia ohrozuje moju pracovnú bezpečnosť, nechcem sa učiť nič nové, preto budem ticho sabotovať.
Aké vôbec môže byť v zásade riešenie? Systém ITSM má veľmi primitívne API na automatické generovanie dokumentov. A vôbec, väčšina takýchto systémov pochádza z čias mainframeov. Možno niekto pozná skutočne moderné systémy ITSM? Možno niekto má úspešný zážitok s integráciou moderných DevOps a byrokracie? Reč určite nie je o čisto predajných stránkach, kde môže byť skutočne deploy každý deň, ale napríklad o bankovom sektore, ktorý je pod auditmi a má veľmi silnú izoláciu higher environments.
Len nezabudnite, že všetky vaše fantázie sú obmedzené auditom. A to všetko mení. Teším sa na vaše komentáre!
Zdroj: habr.com
