A DevOps és az IaC témája nagyon népszerű és gyorsan fejlődik. A legtöbb szerző azonban tisztán technikai problémákkal foglalkozik ezen az úton. Leírom a nagyvállalatokra jellemző problémákat. Nincs megoldásom – a problémák általában végzetesek, és a bürokrácia, az auditálás és a „puha készségek” területére vonatkoznak.
Mivel a cikk címe ilyen, az Enterprise oldalára átállt Daenerys macskaként fog viselkedni.
Kétségtelen, hogy most ütközik a régi és az új. És gyakran ezekben az ütközésekben nincs sem jó, sem rossz. Így történt. De, hogy ne legyünk alaptalanok, ezzel a képernyővel kezdjük:
Ez az úgynevezett Change Request. A kitöltendő mezők körülbelül egyharmada különböző könyvtárakból látható, a fennmaradó mezők más könyvjelzőkben vannak. Egy ilyen dokumentumot ki kell tölteni ahhoz, hogy a szkriptet az éles kiszolgálóra alkalmazzák, vagy új fájlokat töltsenek fel, vagy általában bármit módosítsanak.
A mezők száma annyi, hogy ezeknek a mezőknek a kitöltéséhez saját kis automatizálást írtam. Ráadásul ez az oldal úgy van megírva, hogy egyetlen automatizálási eszköz sem látja a mezőit, és az egyetlen lehetséges megoldás az volt, hogy az AutoIt segítségével hülyén kattintgatták az egérrel a koordinátákat. Mérje fel a kétségbeesés szintjét, hogy ezt tegye:
Tehát veszel jenkineket, séfet, terraformot, nexust stb., és boldogan telepíted a fejlesztődre. De eljön az ideje, hogy elküldjük a QA-nak, az UAT-nak és a PROD-nak. Nexus műterméke van, és levelet kap a DBA-tól a következővel:
Kedves,
Először is, a nexusod, amit magadnak szerezhetsz. Nem férek hozzá a Nexusodhoz
Másodszor, minden változtatást változtatási kérelemként kell kiadni.
Ki kell bontania az SQL-parancsfájlokat a Nexusból, és csatolnia kell őket a módosítási kérelemhez.
Ha a módosítás nem vészhelyzet, akkor ezt a megjelenés előtt 7 nappal kell megtenni (kizárólag hétvégén)
Amikor a módosítási kérelmet egy csomó ember jóváhagyja, a DBA végrehajtja a szkriptet, és még egy képernyőképet is elküld levélben az eredményről.Üdvözlettel: DBA-ja, aki a mainframe napjai óta dolgozik itt.
Tudod, mire emlékeztet ez engem? Félautomatizálás: a robot tartja a keretet, a munkás pedig kalapáccsal üti. Nos, tényleg, mi értelme van ennek a Nexusnak, ha akkor mindent teljesen manuálisan csinálnak?
De az Enterprise-t nem szabad ezért hibáztatni! Ez természetesen véres, de ez a változáskérésekkel járó bürokrácia kényszerű, és az auditoroktól származik. A vállalatnak így kell működnie, pont. Nem tudja másképp csinálni. Az auditálás pedig nagyon konzervatív dolog. Például mennyi szó esett arról, hogy a hosszú álbonyolult és gyakran cserélt jelszavak rosszak, de a vállalkozások az utolsó hely, ahol ezt megváltoztatják. A bevetésekkel és minden mással is.
Egyébként egy időben próbáltam létrehozni egy fájlt terraformhoz, de nem ment. Elakadtam a „Projektkönyvelési számlázási kód” címke jelentésében, amit soha nem sikerült megtudnom – nem volt elég soft skillem.
Nem is vállalom a passzív luddizmus témáját - ó, az automatizálásod veszélyezteti a munkahelyem biztonságát, nem akarok semmi újat tanulni, ezért csendben szabotálni fogom.
Nos, elvileg mi lehet a megoldás? Az ITSM rendszer rendkívül primitív API-val rendelkezik a dokumentumok automatikus generálásához. És általában véve ezeknek a rendszereknek a többsége a nagyszámítógépek idejéből származik. Tud valaki igazán modern ITSM rendszert? Van valakinek sikeres tapasztalata a modern DevOps és a bürokrácia integrálásával kapcsolatban? Természetesen nem tisztán értékesítési oldalakra gondolunk, ahol tulajdonképpen minden nap lehet bevetés, hanem például a bankszektorról, amely auditok alatt van, és a magasabb környezetekben nagyon erős elszigeteltségben van.
Csak ne felejtse el, hogy minden fantáziájának az audit szab határt. És ez mindent megváltoztat. Kommentben várlak!
Forrás: will.com