8 mindennapi kihívás a DevOps alkalmazásában és azok megoldása (kihívások) - 1. RÉSZ

A DevOps már nem új szó az informatikai iparban; ez a 2020-as év, és szinte minden szervezet akarja, vagy megpróbálja fejleszteni kultúráját és módszereit ezen működési módok szerint. Az ilyen forradalmi változás elfogadása azonban nem könnyű, és számos kihívással kell szembenéznie mind a vezetőknek, mind az „ügyfeleknek”; A DevOps nagyon alulról felfelé és lefelé irányuló mozgás. Íme néhány közös kihívás, amelyeket megfigyeltem a terepmunkám során:

  1. Működésképtelen kultúra

Az erősen irányító és irányító, valamint a bürokratikus kultúrák nagyon motiváló munkahelyek lehetnek. Ahol az embereket büntették a problémák felmerülése miatt, vagy ha az információkat rejtették, akkor az emberek megállíthatják a megosztást és az együttműködést. Ahol a kudarcot elkerülendő, az emberek megpróbálják fedezni a hibákat, nem pedig tőlük tanulnak, és félnek új dolgokat kipróbálni.

A kultúrát nagyon nehéz meghatározni, és úgy tűnik, hogy nagyon nehéz megváltoztatni. Ez a szervezet tagjainak értékei és viselkedése, és ezzel az emberi szinttel kell foglalkozni; megköveteli, hogy az érzelmekről és az érzelmekről beszéljünk, nem csak bitről és bájtról.

2. A változásokkal szembeni ellenállás

Nem sokan szeretik megváltoztatni munkamódszereiket; megszokták a cselekedeteiket, és gyakran nem hajlandóak módosítani szokásos rutinjukat vagy folyamataikat. Sokan inkább a silókban dolgoznak, és valószínűleg nem akarnak másokkal kommunikálni, így a DevOps vezetői gyakran szembesülnek ellenállással az átalakulás során. Egyes idegtudósok, például Britt Andreatta úgy vélik, hogy az emberek alapvetően vezetékesek ahhoz, hogy evolúciós okokból ellenálljanak a változásoknak.

Íme egy példa arra, ahol a változásért felelős ügynök vagy egy szervezet ellenállást tapasztalhat: egy tesztelőt, aki hagyományosan manuális tesztelést hajtott végre, felkérhetjük a teszt forgatókönyvének vagy lépéseinek automatizálására egy folyamatos integrációs folyamatban. Lehet, hogy ellenállnak a munkamódszer megváltoztatásának, mert meg kell tanulniuk, hogyan kell automatizálni korábbi kézi tesztforgatókönyveiket, és úgy érzik, hogy ez meghaladja a képességeiket. Egy másik példa a minőségbiztosítási menedzser, aki hozzászokott ahhoz, hogy egy nagy tesztelői csapattal rendelkezzen felügyelet céljából: láthatják, hogy tesztelőiket több csoportra osztják szét a többfunkciós csapatok szervezeti átalakításának részeként, és úgy érzik, hogy fenyegetik a vezető és menedzser státus.

3. A látás egyértelműsége

Sok szervezet szeretné a DevOps ígéretes fejlesztéseit, de gyakran nem fordítanak elegendő időt a DevOps elfogadásának megfelelő megtervezésére. Lehetséges, hogy a vezetők nem fedezték fel, hogy mit kérhetnek a DevOps a szervezeti átalakítás szempontjából, vagy ellenállhatnak ennek. A szervezetek gyakran hagyják a DevOps vezetőit és támogatóit, hogy egyedül készüljenek a vezetés támogatása nélkül az igaz DevOps kultúra ápolására és gyakorlására.

A DevOps átalakításai megfelelő tervek és stratégia nélkül megnehezítik céljainak megvalósítását. A látás hiánya miatt a DevOps vezetõi számára egyértelmû terv kidolgozása nagy kihívást jelent a becslés, az útitervek és a teljesítendõ elemek eldöntésekor. Ezenkívül nagyon nehézkes a kommunikáció és a jövőkép megosztása a szélesebb szervezeten keresztül, ha nincs világos.

A DevOps váltó ügynökei néha rendelkeznek megfelelő tervvel és stratégiával a DevOps elfogadására, amelyet a menedzsmentünknek vagy a C-suite-nak javasoltak, ám ha ezek a vezetők nem nyíltan támogatják és evangelizálják a DevOps végrehajtási végrehajtási tervét, akkor megronthatják a DevOps elfogadási folyamatait.

4. A csapatok nem működnek együtt

A DevOps fő célja, hogy ösztönözze és lehetővé tegye a Dev, Ops és más csapatok együttműködését, ily módon lebontva a silók közötti akadályokat. A csapatoknak meg vannak saját céljaik; a fejlesztői csapat a változásokra, az informatikai műveleti csoport a stabilitásra összpontosít. Alapvető kihívás a csapatok közös céljainak biztosítása a DevOps bevezetőinek.

Ezen felül, ha egy szervezet földrajzilag szétszórt, a csoportközi együttműködés még nagyobb kihívást jelenthet. Noha a DevOps és az agilis modellek ösztönzik az együttes elhelyezkedést, ez gyakran nem praktikus vagy akár nem is lehetséges. Ezenkívül sok szervezet kiszervezi a munkát, például tesztelést vagy informatikai műveleteket, potenciálisan jelentősen eltérő földrajzi régiókba, súlyosbítva a kihívást az időzóna és a nyelvi komplikációk miatt.

5. A környezetek nincsenek szabványosítva

Több alkalmazás vagy szolgáltatási verzió kezelése a DevOps környezetben lassabb kiadásokhoz vezethet, és megnövelheti termékeink hibáinak és problémáinak előfordulását. Ha nincs szabványos környezet vagy termelési jellegű tesztkörnyezet, gyakran eseményeket okoz, mivel az inkonzisztencia kiszámíthatatlansághoz vezet. A megfelelő alkalmazáskörnyezet hiánya további fájdalmat és késést okozhat az új érték felszabadításában az ügyfelek számára, mivel a csapatok például várhatnak hozzáférést a megosztott tesztkörnyezetekhez.

6. Az eszközkészletek versenyképesek

A fejlesztési és informatikai operációs csapatok gyakran különféle eszközkészleteket használnak, de gyakran ugyanazt a dolgot próbálják meg tenni, vagy ugyanazt a munkát kezelik. A kihívás az, hogy megbizonyosodjunk arról, hogy a megfelelő eszközt megvalósítják-e, és hogy az összhangban áll-e az összes csapat és a vállalat céljaival.

Az eszközválasztás vitatott terület, mivel az emberek (gyakran érzelmi) preferenciákkal rendelkeznek. Miután kiválasztott egy szerszámot, az emberek megtanultak használni, és jelentős mennyiségű adatot vagy testreszabott munkafolyamatot tartalmaz, így nehéz megváltoztatni az eszközt - még akkor is, ha azonosítják, hogy van egy másik, amely jobban megfelel a csapatok és a társaságok céljainak.

7. A kiadáskezelés késéseket okoz

Hagyományosan, a szervezetek projekt-vezérelt megközelítést használva nagy mennyiségű funkciót bocsátottak ki. Ezeket a kiadásokat gyakran egy központosított kiadási munkacsoport koordinálja egy kiadási naptár segítségével, ahol a csapatok foglalnak résidőket (gyakran hétvégén munkát igényelnek). Ezeket a kiadásokat gyakran manuálisan vagy egy csomó szkripttel hajtják végre, csak a kiadáskezelő érti, mivel ők építették őket. Mindez azt jelenti, hogy a kibocsátások ritkán fordulnak elő, és nagy a kockázata annak, hogy problémákkal küzdjenek, amelyeket orvosolni kell. A csapatok gyakran arra koncentrálnak, hogy javítsák a problémákat, mint hogy megtanulják a probléma miért történt meglétére, és biztosítsák, hogy a tanulás visszatérjen a szervezetbe. Ugyanúgy, mint a projektcsapatokat, gyakran eloszlanak a működési dátum után, és a végrehajtást követő felülvizsgálat nem vizsgálja meg, hogy az erőfeszítés eredményezte-e a kívánt eredményeket.

8. A kézi tesztelés nehéz és időigényes

A kézi tesztelés nagyon időigényes, és gyakran külön csoportok végzik el, külön fázisokban, késleltetve az ügyfél értékének áramlását. Ezenkívül lehetetlen valós folyamatos integrációt végrehajtani anélkül, hogy legalább az egységteszt automatizálódna - ideális esetben az integrációs és a felhasználói elfogadási tesztek is automatizáltak lesznek. A tesztelés automatizálása hatalmas és lenyűgöző feladatnak tűnik, különösen akkor, ha kevés erőforrás van arra képes, hogy ezt a munkát elvégezze egy szervezetben. Az emberek gyakran úgy ítélik meg, hogy a tesztelés drága, ha sok kézi munkát igényel, és megpróbálják korlátozni a beruházást - ami a későbbiekben rossz minőséghez és állásidőhöz vezet.

Következtetés

A DevOps elfogadása jelentős időt igénylő utazás. Ez megköveteli a szervezetektől a dinamikus és folyamatos tanulást. E nyolc kulcsfontosságú kihívás nagyon korai szakaszában történő ismerete elősegíti a problémák előrejelzését és az erőfeszítések prioritásainak meghatározását. A blog sorozat 2. részében. Megvizsgálom, hogyan lehet leküzdeni ezeket a kihívásokat, és ide kattintva olvashat.