A DevOps és IaC téma rendkívül népszerű és gyorsan fejlődik. Azonban a legtöbb szerző kizárólag a technikai problémákkal foglalkozik ezen az úton. Én azonban a nagyvállalatokra jellemző problémákat fogom leírni. Nincs megoldásom — a problémák alapvetően fatálisak és a bürokrácia, az auditálás és a „soft skills” területén rejlenek.
Ha már ilyen a cikk címe, akkor Daenerys lesz a cica, aki az Enterprise oldalára állt.
Kétségtelen, hogy most az új és a régi összecsapása zajlik. Ezekben a konfliktusokban gyakran nincs igazság és nincs bűnös. Így alakult. De hogy ne legyek alaptalan, kezdjük ezzel a képernyővel:
Ez a szokásos Change Request. Látja körülbelül a mezők egyharmadát, amelyeket különféle jegyzékekből kell kitölteni, a többi mező más fülekben található. Ezt a dokumentumot ki kell tölteni, hogy a scriptet alkalmazhassa a production környezetben. szerverhez, vagy új fájlokat töltsön fel, és egyáltalán bármit megváltoztasson.
A mezők száma oly nagy, hogy írtam egy kis automatizálást ezen mezők kitöltésére. Ráadásul ezt az oldalt úgy írták meg, hogy semmilyen automatizáló eszköz nem látja a mezőit, és az egyetlen lehetséges megoldás az AutoIt használata volt, hogy egyszerűen az egérrel kattintsak a koordinátákra. Értékelje a kétségbeesés szintjét, amely arra késztetett, hogy ilyesmire vállalkozzak:
Szóval, vegyen egy jenkins-t, chef-et, terraform-ot, nexus-t és egyebeket, és boldogan telepítse ezeket a dev környezetbe. De elérkezik az idő, amikor ezt QA, UAT és PROD környezetbe kell küldeni. Van egy Nexus artefaktja, és kap egy e-mailt a DBA-tól, körülbelül ilyen szöveggel:
Tisztelt,
Először is, a nexus-ában nincs hozzáférésem az Ön Nexus-ához.
Másodszor, minden változtatást Change Request-ként kell elkészíteni.
A SQL scriptjeit ki kell emelnie a Nexus-ból, és csatolnia kell a Change Request-hez.
Ha a változás nem sürgős, ezt 7 napon belül kell elvégezni a kiadás után (kizárólag hétvégén).
Amikor a Change Request-jét jóváhagyja egy rakás ember, akkor a DBA végrehajtja a scriptjét és még a képernyőfotót is elküldi e-mailben.Tisztelettel, az Ön DBA-ja, aki itt dolgozik a mainframe óta.
Tudja, mire emlékeztet ez nekem? Félautomatikus rendszer: a robot tartja a gépet, a munkás pedig ütögeti. Valóban, mi értelme van ennek a Nexus-nak, ha utána minden teljesen manuálisan történik?
De nem szabad a Vállalatot ezért hibáztatni! Persze véres, de az ilyen bürokrácia a Change Requests-szel kényszerű, és a auditoroktól származik. A Vállalatnak így kell működnie, és kész. Másképp nem teheti. Az audit pedig rendkívül konzervatív dolog. Például mennyit beszéltek arról, hogy a hosszú, ál-bonyolult és gyakran megváltoztatott jelszavak rosszak, de a vállalatok lesznek az utolsó helyek, ahol ez megváltozik. Ugyanez vonatkozik a telepítésekre és minden másra is.
Egyébként valaha próbáltam Terraform fájlt készíteni, de nem sikerült. Megakadtam a 'Project Accounting Billing Code' címkén, aminek a jelentését sosem tudtam meg — nem volt elég soft skill-em.
Még a passzív luddizmust sem említem — ó, a te automatizációd fenyegeti a munkabiztonságomat, nem akarok semmi újat tanulni, ezért csendben bojkottálni fogok.
Nos, mi lehet a megoldás elvileg? Az ITSM rendszernek rendkívül primitív API-ja van ahhoz, hogy automatikusan dokumentumokat generáljon. És egyáltalán, a legtöbb ilyen rendszer a mainframe korszakból származik. Van valakinek tudomása valóban modern ITSM rendszerekről? Van valakinek sikeres tapasztalata a modern DevOps és a bürokrácia integrációjában? Természetesen nem a tisztán értékesítési webhelyekről van szó, ahol valóban lehet napi szintű telepítés, hanem például a banki szféráról, amely auditok alatt áll, és nagyon erős elszigeteltséggel bír a magasabb környezeteknél.
Csak ne felejtsétek el, hogy minden fantáziátokat az audit korlátozza. És ez mindent megváltoztat. Várom a hozzászólásaitokat!
Forrás: habr.com
