Téma DevOps a IaC je veľmi populárna a rýchlo sa rozvíja. Väčšina autorov sa však touto cestou zaoberá čisto technickými problémami. Popíšem problémy charakteristické pre veľkú spoločnosť. Nemám riešenie - problémy sú vo všeobecnosti fatálne a spočívajú v oblasti byrokracie, auditu a „mäkkých zručností“.
Keďže názov článku je takýto, Daenerys, ktorá prešla na stranu Enterprise, bude pôsobiť ako mačka.
Nepochybne teraz dochádza ku kolízii starého a nového. A často v týchto kolíziách nie je ani správne, ani nesprávne. Stalo sa to tak. Aby sme však neboli neopodstatnení, začneme s touto obrazovkou:
Ide o takzvanú žiadosť o zmenu. Z rôznych adresárov vidíte asi tretinu polí, ktoré je potrebné vyplniť, zvyšné polia sú v iných záložkách. Takýto dokument musí byť vyplnený, aby bolo možné použiť skript na produkčný server alebo nahrať nové súbory alebo vo všeobecnosti niečo zmeniť.
Počet polí je taký, že som napísal vlastnú malú automatizáciu na vyplnenie týchto polí. Táto stránka je navyše napísaná tak, že jej polia nevidia žiadne automatizačné nástroje a jediným možným riešením bolo použiť AutoIt na hlúpe klikanie na súradnice myšou. Posúďte úroveň svojho zúfalstva, aby ste to urobili:
Takže si vezmete jenkins, chef, terraform, nexus atď., a šťastne to všetko nasadíte do svojho vývojára. Ale prichádza čas poslať to do QA, UAT a PROD. Máte artefakt Nexus a dostanete list od DBA s niečím takýmto:
Drahá,
Po prvé, váš nexus, ktorý môžete mať pre seba, nemám prístup k vášmu zariadeniu Nexus
Po druhé, všetky zmeny musia byť vydané ako žiadosť o zmenu.
Musíte extrahovať skripty SQL zo zariadenia Nexus a pripojiť ich k žiadosti o zmenu.
Ak zmena nie je núdzová, mala by sa vykonať 7 dní pred vydaním (výhradne cez víkend)
Keď vašu žiadosť o zmenu schváli veľa ľudí, DBA spustí váš skript a dokonca pošle snímku obrazovky s výsledkom poštou.S pozdravom váš DBA, ktorý tu pracuje od čias mainframe.
Viete, čo mi to pripomína? Poloautomatizácia: robot drží rám a pracovník ho udiera kladivom. No, naozaj, aký zmysel má tento Nexus, ak sa potom všetko robí úplne ručne?
Ale Enterprise by za to nemala byť obviňovaná! Je to, samozrejme, krvavé, ale všetka táto byrokracia so žiadosťami o zmenu je vynútená a pochádza od audítorov. Podnik musí fungovať týmto spôsobom, bodka. Nemôže to urobiť inak. A auditing je veľmi konzervatívna vec. Napríklad, koľko sa toho popísalo o tom, že dlhé pseudokomplexné a často menené heslá sú zlé, ale podniky budú posledným miestom, kde sa to bude meniť. Aj s nasadením a všetkým ostatným.
Mimochodom, naraz som sa pokúsil vytvoriť súbor pre terraform, ale nefungovalo to. Narazil som na význam značky 'Kód účtovania účtovníctva projektu', ktorý sa mi nikdy nepodarilo zistiť - nemal som dostatok mäkkých zručností.
Neberiem ani tému pasívneho ludizmu - ach, vaša automatizácia ohrozuje moju istotu zamestnania, nechcem sa učiť nič nové, tak to potichu sabotujem.
Aké by mohlo byť v princípe riešenie? Systém ITSM má mimoriadne primitívne API na automatické generovanie dokumentov. A vôbec, väčšina týchto systémov pochádza z čias mainframov. Pozná niekto nejaké skutočne moderné ITSM systémy? Má niekto úspešnú skúsenosť s integráciou moderného DevOps a byrokracie? Nehovoríme samozrejme o čisto predajných stránkach, kde skutočne môže dôjsť k nasadeniu každý deň, ale napríklad o bankovom sektore, ktorý je vo vyšších prostrediach pod audítormi a veľmi silnou izoláciou.
Len nezabudnite, že všetky vaše fantázie sú obmedzené auditom. A to všetko mení. Čakám na vás v komentároch!
Zdroj: hab.com