A hamis DevOps 7 árulkodó jele

Kétségtelen, hogy a DevOps sok informatikai szervezetnek segített elérni azt a célját, hogy az alkalmazásokat és szolgáltatásokat gyorsabban és jobban szállítsák, mint a hagyományos szoftverfejlesztési folyamatok. Sajnos, bár egyes IT-vezetők jól tudják hirdetni a DevOps előnyeit, csapataik rossz irányba mennek, és félresiklott vagy teljesen rossz eszközöket és gyakorlatokat alkalmaznak.

A CIO felelőssége annak biztosítása, hogy a fejlesztőcsapatok szándékosan vagy akaratlanul ne térjenek le a DevOps útról. Íme a hét figyelmeztető jelzés, amely figyelmezteti Önt, hogy hamis DevOps-ok lehetnek a szervezetében.

1. Silo DevOps

A hamis DevOps implementáció első jele egyszerűen észrevehető egy szervezeti diagram megtekintésével. “Ha a DevOps-ot a saját silóban találja, elválasztva a tervezéstől és az üzemeltetéstől, ez az első jele annak, hogy a DevOps-felelőssége nincs ott” – mondta Fernando Cuadra, az ISG technológiai kutató és tanácsadó cég fő tanácsadója. “Azáltal, hogy egy különálló DevOps csapatot hozott létre, a CIO lényegében egy újabb komplexitási réteget, egy újabb silót és egy újabb kezelési átadás-átvételt tett hozzá.”

A szervezeti diagramnak olyan felépítést kell tükröznie, amely lehetővé teszi a csapatok számára, hogy holisztikusan oldják meg a problémákat az összes releváns területen. „Válasszon teljes körű, többfunkciós csapatokat a tervezéstől a működtetésig” – tanácsolja Cuadra. „A DevOps nem a csővezetékekről és a CI/CD-ről szól; ez az értékátadás ellenőrzéséről szól, minimális súrlódással a vállalaton belül.”

Cuadra megjegyzi, hogy a DevOps csak egy eszköz a technológia emberi oldaláról szóló sokkal nagyobb beszélgetéshez. “Ehhez meg kell érteni a nagy teljesítményű csapatok kulcsfontosságú építőköveit, és azt, hogy az informatikai igazgatók hogyan tudják frissíteni a jól teljesítő csapatok képét.”

Egy olyan szervezet, amely az emberek és folyamatok helyett az eszköz- és technológiaközpontú DevOps-kultúrára koncentrál, 180 fokban nincs szinkronban. „Létfontosságú a jelenlegi üzleti gyakorlatok és igények felmérése” – mondta Mohan Kumar, a TEKsystems, egy IT-szolgáltatást kezelő cég vezető építésze.

Kumar azt javasolja, hogy a csapatokat helyezzék előtérbe. „Vegyük be a DevOps kultúrát a kommunikációba, az együttműködésbe, a visszajelzések gyűjtésébe és az elemzésekbe” – javasolja. “A kísérletezésbarát környezet, amely lehetővé teszi a fejlesztők számára, hogy gyorsan kudarcot vallanak, gyorsan felépüljenek és gyorsabban tanuljanak, bűntudatmentes kultúrát teremt a szervezeten belül.” Kumar azt is javasolja, hogy a csapatok kollektív intelligenciájának kihasználásával támogassák a kreatív ötletek folyamát.

A DevOps bevezetése iteratív folyamat, ezért a CIO-nak a fejlesztőcsapat jelenlegi állapotának értékelésével kell kezdenie, majd fokozatosan ki kell dolgoznia egy folyamatos fejlesztési stratégiát, amely magában foglalja az embereket, folyamatokat és eszközöket, amelyek a jövőbeni igények és fejlesztések függvényében változhatnak. “Végső soron a kreativitás egy olyan izom, amelyet folyamatosan edzeni kell ahhoz, hogy növekedjen” – jegyzi meg Kumar.

3. Túl kevés automatizálás

Hamis DevOps akkor fordulhat elő, ha a csapatvezetők nem rendelkeznek automatizálási gondolkodásmóddal, különösen nem képesek időt és erőforrásokat fektetni egy erős architektúra felépítéséhez automatizált kódszállítással.

Gondosan fontolja meg a fejlesztési igényeket, a meglévő szerződéseket és a jelenlegi projektcsapatokat, mielőtt továbblépne egy automatizálási kezdeményezéssel. “Nézze meg, hogy a szervezet képességei azon a szinten állnak-e, ahol automatizálni tudja az infrastruktúrát” – mondta Ian Fogarty, az Accenture Federal Services tanácsadó cég technológiai és műveleti vezérigazgatója.

Az automatizálás azonban kétélű fegyver is lehet. Kumar megjegyzi, hogy túlságosan könnyű véletlenül átváltani a hibás kézi folyamatokról a hibás automatizált folyamatokra. Azt tanácsolja, hogy álljon ellen az automatizálás késztetésének, amennyire csak lehetséges. Ehelyett automatizálja, amennyire ésszerű. Kumar megjegyzi, hogy a végső cél a szoftverkiadások megismételhető és megbízható automatizált telepítési folyamattá alakítása kell, hogy legyen.

4. Véletlenszerű automatizálás

Bár az automatizálás nagyon hasznos, sok szervezet megfelelő elemzés és tervezés nélkül ugrik a DevOps automatizáláshoz. „Láttuk, hogy a szervezetek előnyben részesítik az automatizálást anélkül, hogy más szempontokat, például az irányítást, az embereket, a folyamatokat és a technológiát figyelembe vették volna” – mondta Aaron Oh, a Deloitte Risk & Financial Advisory DevSecOps vezérigazgatója. Az ilyen szervezetek általában sok időt pazarolnak az automatizálási munkák felülvizsgálatára és javítására.

Mielőtt közvetlenül az automatizálásba lépne, Oh erős irányítás kialakítását, valamint a követelmények és folyamatok szabványosítását javasolja. „Az üzleti egységek közötti együttműködés a DevOps elengedhetetlen része” – jegyzi meg. Szüntesse meg a szervezeti akadályokat. „A vezetői útmutatás fontos lesz az alaphang megadásához” – mondja Oh. “Ezenkívül használjon intelligens hangszerelési eszközöket a silók további eltávolításához és a hatékony kommunikáció érdekében.”

5. Irreális elvárások tartása

A vezető technológiai vezetőknek olyan elkötelezettségre kell összpontosítaniuk, amely túlmutat az új technológiai eszközök és gyakorlatok bevezetésén. “Prioritásként kell kezelniük a változó alkalmazotti kultúrát és gondolkodásmódot” – mondta Tim Potter, a Deloitte Consulting igazgatója. “Reális ütemtervet is meg kell határozniuk ahhoz, hogy az átalakulás gyökeret eresszen a szervezetben.”

Az a szervezet, amely egyszerűen több automatizált szerszámot telepít, és a meglévő alkalmazáscsapatokat “DevOps csapatokká” nevezi át, és elkötelezett a termelési problémák teljes körű kezelése mellett, valószínűleg csalódni fog az eredményekben, magyarázza Potter.

A technológiai vezetőknek fel kell készülniük arra is, hogy elfogadják, hogy a DevOps telepítése után a teljesítmény csökkenhet, mielőtt javulna. „Fel kell készülniük arra, hogy „légfedést” biztosítsanak alkalmazási csapataik számára, hogy tesztelhessék, tanulhassanak, és megismerkedhessenek az új modellben való munkavégzéssel” – tanácsolja Potter. „Ha nem megfelelő elvárásokat támasztanak, és nem adunk elég időt az átalakításra, a szervezetek csak név szerint alkalmazhatják a DevOps-ot.”

6. A múltban ragadt csapatok

A régi szokásokat nehéz elsajátítani. A szoftverfejlesztés évtizedeken át a hagyományos vízesés módszertant követte, a követelmények előzetes összegyűjtését, a funkciók kiépítését, és végül az eredményeket a minőségbiztosítási és más csapatok számára, hogy kiadják, mondja Ashish Kakran, a Thomvest IT kockázati tőketársaság elnöke. . „Régebben hónapokba telt, mire az ügyfelek új funkciókat láttak” – jegyzi meg.

Amikor a fejlesztőcsapatok nem tudják teljesen kihúzni magukat a vízesésből, a folyamatok furcsa kombinációihoz jutnak, amelyeket “agilefall”-nak nevezhetnénk – mondja Kakran. “Ez azt jelzi, hogy nem történt teljes lépés a szoftverfejlesztés legújabb fejlesztéseinek kihasználása érdekében.”

Kakran azt javasolja, hogy a küzdő csapatok gyors és egyszerű módja a DevOps „Epics” és „Stories” kutatása.

„Gyakran egy folyamatban lévő projekt teljes kontextusát rögzítik ezek a feladatok” – magyarázza. „Ha úgy érzed, hogy egy hónapos projektet már olyan feladatokra bontottak, amelyeknél kevés vagy semmilyen folyamatos ügyfél-visszajelzés, ez annak a jele, hogy a csapat kudarcra készül, legyen szó akár a projekt határidőiről, akár a hasznos felhasználói élmények hiányáról. “

7. Rugalmatlanság

A DevOps nem egy mindenkire érvényes módszer. A maximális hatékonyság érdekében a DevOps folyamatokat és eszközöket a szervezet sajátos igényeihez kell igazítani, amelyek mérettől, alkalmazástípustól és fejlesztési szakértelemtől függően igen eltérőek lehetnek.

A DevOps soha nem lehet statikus. A folyamatoknak és eszközöknek alkalmazkodniuk kell a szervezet növekedésével és a folyamatos fejlesztésre irányuló törekvésének követésével. Ezekhez a célokhoz rugalmas eszközökre és a KPI-k elemzésének képességére van szükség a fejlesztési lehetőségek feltárása érdekében – mondta Wing To, a mesterségesintelligencia-alapú DevOps platformot forgalmazó Digital.ai mérnöki részlegének alelnöke. Az informatikai vezetőknek figyelembe kell venniük azt a kulturális változást is, amely a fejlesztési és üzemeltetési csapatok összehozásához szükséges. Ahelyett, hogy külön DevOps részleget építenénk, ami csak több silót és folyamat szűk keresztmetszetet hoz létre, a módszertant minden üzleti területbe be kell építeni.

A DevOps valójában az emberekről és a folyamatokról szól. Az IT-vezetőknek meg kell érteniük, hogy ezeknek az erőforrásoknak kontextus-specifikusaknak kell lenniük. „Az eszközök és folyamatok használatának optimális módja az idő múlásával változik, dinamikus, nem statikus, és az eszközök és folyamatok megfelelő használatához gondos coaching szükséges” – jegyzi meg To.

Az egyensúly elérése

A sikeres DevOps átalakítás elindításakor a push és pull egyensúlyt kell elérni. “Ha szerencséd van, lelkes csapatok jelentkeznek, és önként jelentkeznek, hogy az elsők között legyenek, akik örökbe fogadnak” – mondja Potter. „Fontos támogatni ezeket a csapatokat – jutalmazzuk bátorságukat és ünnepeljük sikereiket, miközben a hangsúlyt a szélesebb szervezeti átalakulási ütemtervre helyezzük.”

Ne feledje azonban, hogy az előnyök korlátozottak és késedelmesek lesznek, ha az egész szervezet nem fogadja el az átalakítást. „Elkerülhetetlenül lesznek olyan kölcsönös függőségek, amelyek lelassítják az alkalmazási csapatot, ha a szervezet nem változtatja meg a szélesebb kört” – mondja Potter.

Leave a Comment

%d bloggers like this: