Szembenállás helyett együttműködés

Technológiai kuriózumból egy szűk fél évtized alatt a nagyvállalati informatika megkerülhetetlen összetevője lett a DevOps, amely új szintre emeli az együttműködést az IT két nagy csapata, a fejlesztők és az üzemeltetők között.

A fejlesztés és az üzemeltetés érdekei hagyományosan ellentétesek egymással. Előbbi csapat (a Dev) minél hamarabb szeretné új funkciókkal ellátni az üzleti felhasználókat, és nem érti, miért akadékoskodnak az üzemeltetők; utóbbi (az Ops) viszont a rendszerek megbí­zhatóságában, zavartalan működésében érdekelt, amit (szerintük) csak veszélyeztetnek a folyamatosan érkező új verziók.

Ezt az érdekellentétet igyekszik feloldani és eszközökkel, folyamatokkal hatékony együttműködéssé formálni a DevOps – mondta az ITB Club novemberi rendezvényén Dr. Hasznics Milán, a Qualysoft szoftverfejlesztési üzletágának vezetője. A DevOps alig öt-hat éve tűnt fel a szí­nen, de mára megkerülhetetlenné vált a nagyvállalati backend- és frontend-fejlesztések esetében. A Qualysoft értelmezésében a DevOps egyszerre technológia, eszközkészlet és kultúra, amelyek együttesen új minőséget hoznak a fejlesztők és az üzemeltetők együttműködésébe.

 

Technológia a megbí­zhatóságért

Nem vált volna nélkülözhetetlenné a DevOps, ha nem nyújtana kézzelfogható előnyöket. Dr. Hasznics Milán ezek közül a magasabb minőségű szoftverek gyorsabb szállí­tásának lehetőségét, illetve a DevOps-szal fejlesztett rendszerek magas fokú méretezhetőségét emelte ki.

Előbbit az egyik legfontosabb technológiai komponens, az úgynevezett CI/CD pipeline biztosí­tja. Ez a fejlesztéstől a használatba vételig tartó folyamat egyfajta automatizált gyártósor szemléletű megvalósí­tása.

Egy jól kialakí­tott CI/CD környezetben az utolsó manuális tevékenység az, amikor a fejlesztő feltölti a forráskódot a repositoryba. Onnantól kezdve a rendszer gondoskodik a fordí­tásról, a futtathatóvá tételről, a különféle tesztek lefuttatásáról és magáról a telepí­tésről is. így nem csak gyorsabb lesz a teljes folyamat, de a minőségbiztosí­tás is magasabb szintre lép, miközben a teljes folyamat dokumentált, í­gy könnyen auditálható is.

A méretezhetőségről a mikroszerviz architektúra gondoskodik. A mikroszerviz architektúrában a szemantikailag egybetartozó funkciókat önállóan futtatható entitásokká csomagolják (ez a konténerizáció). A konténerbe zárt alkalmazásokat egy orkesztrációs mechanizmus révén bí­rják együttműködésre, í­gy a felhasználó felé számos komponens lazán csatolt együttműködése mentén születik meg a nagy teljesí­tményű szolgáltatás, miközben úgy látja, hogy egyetlen nagy rendszerrel dolgozik.

Mindezeknek köszönhetően kevesebb ember is elég lehet az üzemeltetéshez, ami a szakemberhiányos időkben rendkí­vül fontos – tette hozzá Gazdag Ferenc, az MVM Digitalizációs Transzformációs Központ vezetője. Az előny ROI-szinten is kimutatható: a korábbi üzleti teljesí­tményt kevesebb erőforrással is el lehet érni, vagy ugyanannyi erőforrással nagyobb lehet a leszállí­tott teljesí­tmény.

 

Az emberek meggyőzhetők

A technológia önmagában azonban nem sokat ér, ha nem sikerül a fejekben, a kultúrában változást elérni, és a már emlí­tett szembenállást megszüntetni a fejlesztők és üzemeltetők között. Ez nem is olyan nehéz, mint gondolnánk, mondta Dr. Hasznics Milán. Mindkét csapatot meg kell ismertetni a másik fájdalompontjaival, nehézségeivel, és képbe kell helyezni a nagyobb, stratégiai üzleti cél kapcsán is. Ha felismerik, hogy közösek az érdekeik, akkor motiválttá válnak, nyitottak lesznek a csapatként történő együttműködésre, és közös lehet a felelősség vállalása a rendszerek fejlesztése és üzemeltetése terén.

Gazdag Ferenc szerint a DevOps szemléletet egyébként eszközök nélkül is be tudja hozni a szervezetbe egy informatikai vezető, csak be kell vonni a csapatokat egymás munkájába. Az üzemeltetőt a fejlesztési projekt elejétől hí­vják meg az értekezletekre, és a fejlesztőknek is szóljanak jó előre, ha változást terveznek a szoftvereiket futtató infrastruktúrában.

Más veszélyek is akadályozzák a sikeres DevOps bevezetést. Az egyik, ha szigorúan ragaszkodunk a korábbi folyamatokhoz és menetrendekhez. Hiába szállí­tunk le három nap alatt egy újabb release-t, ha annak jóváhagyása két hétig tart, érzékeltette a problémát a Qualysoft szakembere. Ehhez pedig nem csak a beosztott munkatársak, hanem a vezetők gondolkodásmódjának is változnia kell. (Lásd a keretet!)

Nem is tanácsolják a szakértők, hogy egyszerre, big bang formájában valósí­tsák meg a cégnél a DevOps-ot. Kicsiben kell kezdeni, egy-két kisebb rendszeren kipróbálni, és kialakí­tani az automatizmusokat. Akkor lehet újabb és újabb területekre kiterjeszteni, ha már kiforrottak a mechanizmusok. Gazdag Ferenc ugyanakkor emlékeztetett arra, hogy vannak olyan infrastrukturális területek, amelyek esetén nem érdemes a DevOps-ot alkalmazni. Ilyennek tartja mindazokat a rendszereket, amelyeket nem lehet nyí­ltan programozni: hálózat, tűzfalak stb.