Mi a DevOps és milyen feladatokat végez a DevOps mérnöke
A DevOps (fejlesztési műveletek vagy belüli műveletek) kifejezés
A gyakorlatok gazdag arzenálja közelebb hozza a DevOps-ot másokhozaz IT szférában népszerű az Agile módszerrel. Ez egy iteratív tervezési megközelítés, amely lehetővé teszi, hogy alkalmazkodjon a változó követelményekhez. Ennek megfelelően a DevOps szakembere megpróbálja jobbá tenni a terméket, kiszámíthatóbbá és átláthatóbbá tenni az üzleti folyamatokat. Javítja az üzleti mutatókat is, például lerövidíti a Time-to-Market időt. Ez az időtartam a termékfejlesztés kezdetétől a piaci bevezetésig. Azok a tényezők, amelyek meghosszabbítják a szoftver létrehozásának idejét, és a rendszerszemlélet lehetővé teszi, hogy a DevOps mérnöke folyamatos és gyors termelést nyújtson. Annak érdekében, hogy világosabb legyen, felhívhat egy hasonlatot egy futószalaggal az autók összeszereléséhez. Minden alkatrészt előre megterveztek, hogy tökéletesen illeszkedjenek egymáshoz az összeszerelés során. A motort tervező mérnökök átgondolják annak működését a kerekekkel, a fékrendszerrel stb. A DevOps ugyanezt teszi: több felelősséget vállal a termékért, mint a fejlesztő, biztosítva, hogy minden csapat együttműködjön.
Pink Pony World: Verseny a divatfilozófiaért
Azonban nem minden vállalatnak van szüksége DevOps-ra.Például a már meglévő informatikai részleg nélküli csapatokban, amelyek nem vesznek részt egy digitális termék gyártásában, a DevOps filozófiája egyáltalán nem érvényes. Ezek a területek közé tartoznak azok a vállalatok, amelyek profitja nem közvetlenül attól függ, hogy az ügyfelek mennyire elégedettek azzal az informatikai termékkel, amellyel kölcsönhatásba lépnek. Ezenkívül gyakran nem alkalmas kisvállalkozások számára. A módszertan számos bevált üzleti folyamatban és még a vállalati kultúrában is változtatásokat igényel. A kisvállalkozások egyszerűen nem tűrik az ilyen változásokat a projekt-gazdaságtan szempontjából.
A digitális átalakulás divatos betegsége gyakranaz ilyen társaságok vezetőit érinti. A végtelen optimalizálás érdekében elfelejtik az üzletet befolyásoló egyéb tényezőket. Ennek eredményeként a vállalatok elveszítik a pénzt, a hatékonyságot, a legrosszabb esetben pedig az évek során kiépített üzleti folyamatokat. Az informatikai óriások, a bankok, a nagy kereskedelmi és ipari események már más kérdés. Számukra a DevOps nagyon hasznos lehet. Így az Alfa-Bank 2017. évi éves jelentése szerint a módszertan bevezetése lehetővé tette számunkra, hogy 60-szor gyorsítsuk fel a fejlesztést és a megvalósítást.
Stakhanovite-mnogostanochnik az alkalmazottak műhelye helyett
Természetesen ilyen kiterjedt funkcionalitás nehézegy alkalmazottnak kell elvégeznie, így ideális esetben egy egész funkciós csoport vesz részt a DevOps-ban. Magában foglalja a szerepkörök és a folyamat- és termékmenedzserek szakembereit, az infrastruktúra-kódok fejlesztőjét, a mérnököket és sok más szerepet. Az orosz gyakorlatban azonban a DevOps szakembere gyakran divatos módszerré válhat, hogy pénzt takarítson meg a termék létrehozásával. Jellemzően ez a helyzet azután következik be, hogy a vállalat felső vezetője úgy dönt, hogy eljött az ideje a digitális átalakulásnak. A vállalat sürgősen toboroz új szakembereket, vagy kibővíti a meglévő fejlesztők és rendszergazdák felelősségi körét. Ennek eredményeként a toborzási szolgáltatások nem a DevOps mérnökeinek kínálnak állást, hanem a több állomáson dolgozóknak.
Az ilyen alkalmazott egyénileg kötelezhetőszerverek beállítása, kábelezés lefektetése, majd a hibák nyomon követése, adatbázisok beállítása és projektek tárolása stb. Ez a példa szélsőséges, de valóságos. Ennek eredményeként az alkalmazottak gyorsan kiégnek, és a módszertan megvalósítása a vállalat munkájában kudarcot vall. Ha a DevOps szakemberét bűvészként kezeljük, aki egyszerre képes nagyszámú feladatot kezelni, a teljes rendszer működésének figyelemmel kísérésével, az nem hoz profitot az üzlet számára.
Egy másik gyakori probléma aa csapatot két csoportra osztva, amelyek nem tudnak kijönni egymással. Képzelje el, hogy egy informatikai vállalat rendelkezik DevOps részleggel, amely megváltoztathatja a szokásos munkamódszereket. Ezek a szabályok azonban továbbra is kötelezőek más fejlesztőkre. Természetesen ebben az esetben nem kell az együttműködésről és a munka "zökkenőmentességéről" beszélni. A két csapat összecsapni kezd, és csökken a termelékenység.
Lőpor tartásban: A DevOps nemcsak képességek
A DevOps osztály egyik feladata a létrehozáskommunikáció a vállalat különböző informatikai szakemberei között. A DevOps mérnökeinek nemcsak technológiákat kell bevezetniük és hibakeresési folyamatokat kell végrehajtaniuk, hanem bele kell meríteniük a fejlesztői csapatot az üzleti életbe - meg kell osztaniuk a felelősséget, elősegíteni a kompetenciák növelését. Ennek ellenére az ilyen szakemberek gyakran pusztán technikai feladatokkal foglalkoznak, általában a banális időhiány miatt, mind számukra, mind azok számára, akiknek kompetenciáját növelni kell.
Ennek eredményeként annak a ténynek köszönhető, hogy a bevezetett divatosMindenki használja a technológiákat, és az ismeretek és készségek egy osztályon belül koncentrálódnak, problémás helyzetek adódnak, beleértve a katasztrofális helyzeteket is. A DevOps mérnökei által létrehozott új megoldások, a különböző részlegek összehangolt munkája nélkül, annyi problémát okozhatnak, amennyit eredetileg meg kellett volna oldaniuk, ami nem azt jelenti, hogy a DevOps szakembereinek a semmiből kellene megteremteniük a vállalati kultúrát, ahogyan a háziak gyakran úgy gondolják, hogy vezetők. A digitális gyártási folyamat egységét, valamint az új készségek és kommunikáció átadásának ösztönzését a vállalat vezetőinek kell meghozniuk. Enélkül még a DevOps csapata is gyengén fejlődik, és nem osztja meg az ismereteket a csapattal.
Sem a DevOps kiszervezése, sem pedigkívülről érkező szakemberrel való konzultáció. Az első esetben a külső csapatot nem az ügyfélcég igényei, hanem a piacon jegyzett szabványos technológiai készlet vezérli. Az ügyfél számára ez egy lottó: a kihelyezett alkalmazottak homályos megértést alkalmaznak a DevOps-ról a piacon. Ennek eredményeként az üzleti folyamatok egyre összetettebbé válnak, de ez nem hoz semmilyen előnyt az üzlet számára. A vállalatok gyakran maguk is ösztönzik ezt a megközelítést - például arra kérik őket, hogy ne változtassák meg fejlesztési folyamataikat. Nyilvánvaló, hogy ez ellentétes a DevOps koncepciójával.
Hosszú, drága, problémás: durva DevOps orosz nyelven
Ahelyett, hogy a DevOps filozófiát aminden üzleti folyamat szempontjából a hazai vállalatok gyakran szívesebben dolgoznak olyan eszközökön, amelyek nem befolyásolják a munka sebességét. Az egyik eredmény például a "téglafal" - a műveletek, vagyis a rendszergazdák csapata elkülönülve marad, és a fejlesztők csak dobják rájuk az alkalmazásokat. Természetesen ennek eredményeként az eszköztár még mindig javul. Alapvető változások azonban nem történnek, az átláthatóság nem növekszik, és az informatikai csapatok együttműködése sem javul.
Újabb gubanc, amibe belebotlanakvezetők a DevOps bevezetésekor - a vállalati tudásbázisok hiánya. A DORA 2019-es jelentése szerint a belső vállalati információforrásokat használó csapatok 1,73-szor hatékonyabbak voltak, mint mások. Ez a probléma ismét sok orosz vállalat zárt kultúrájára vezethető vissza, amelyben a csapat nem osztja meg a tudást. E zártság miatt a cégek technikai adósságot halmoznak fel. Az eszközök elavulnak, a műtermékeket nem távolítják el, a dokumentációt nem frissítik.
Az objektív üzleti igény a termelés stabilitására, így a profitra, valamint az elavult technológiai bázis és a technikai adósság a DevOps sikertelen használatához vezet.
Mindez gyakran oda vezet, hogy hosszú gyötrelem után a DevOps csapata által kínált új megoldásokat egyszerűen eldobják, és a folyamatokat "visszagörgetik".
Minden vállalatnak megvan a maga útja a digitális átalakuláshoz.A legtöbb esetben ez valóban megváltoztatja a kód fejlesztésének és jobb telepítésének módját. Ez azt jelenti, hogy a DevOps továbbra is létezik Oroszországban: havonta rengeteg, ezzel a módszertannal kapcsolatos álláshely jelenik meg a piacon. A másik dolog az, hogy a szakterület és a gyakorlati feladatok mögött különböző definíciók állnak. A vállalatoknak azonban abba kell hagyniuk a kísérteties ideális informatikai rendszerek üldözését, és kritikusan kell viszonyulniuk egy trendi, de nem feltétlenül jövedelmező filozófiához, saját szükségleteiket előtérbe helyezve.
Lásd még:
A fekete lyukakban univerzumok lehetnek. Mesélünk az új felfedezésről
A betegség 3. napján a legtöbb COVID-19 beteg elveszíti szaglásérzetét, és gyakran orrfolyástól szenved
Kutatás: 15 millió tonna mikroműanyagot találtak az óceán fenekén