Biztonságos üzembehelyezési eljárások

Néha egy kiadás nem felel meg az elvárásoknak. Az ajánlott eljárások használata és az összes minőségi kapu átadása ellenére időnként előfordulnak olyan problémák, amelyek éles üzembe helyezést eredményeznek, ami előre nem látható problémákat okoz a felhasználók számára. A problémák hatásának minimalizálása és csökkentése érdekében a DevOps-csapatoknak ajánlott olyan progresszív expozíciós stratégiát alkalmazniuk, amely egy adott kiadás expozícióját és bizonyított teljesítményét egyensúlyba hozja. Mivel egy kiadás éles környezetben bizonyítja magát, a szélesebb közönség rétegei számára is elérhetővé válik, amíg mindenki nem használja. A Teams biztonságos üzembe helyezési eljárásokat használhat a kiadások minőségének és sebességének maximalizálása érdekében az éles környezetben.

Az ügyfeleknek való kitettség szabályozása

A DevOps-csapatok különböző eljárásokat alkalmazhatnak a frissítések ügyfeleknek való kitettségének szabályozására. Korábban az A/B-tesztelés népszerű választás volt a csapatok számára, akik megtekintik, hogy a szolgáltatás vagy a felhasználói felület különböző verziói hogyan teljesítenek a célcélok szerint. Az A/B tesztelés is viszonylag könnyen használható, mivel a módosítások általában kisebbek, és gyakran csak a különböző kiadásokat hasonlítják össze egy szolgáltatás ügyféloldali peremhálózatán.

Biztonságos üzembe helyezés szinteken keresztül

Ahogy a platformok növekednek, az infrastruktúra mérete és a célközönség is növekszik. Ez egy olyan üzemi modell iránti keresletet hoz létre, amely egyensúlyba hozza az új üzembe helyezéssel járó kockázatokat az általa ígért frissítések előnyeivel. Az általános elképzelés az, hogy egy adott kiadást először csak a legnagyobb kockázattűrésű felhasználók kis csoportjának kell kibocsátani. Ezután, ha a kiadás a várt módon működik, a felhasználók szélesebb körének is közzéteheti. Ha nincsenek problémák, akkor a folyamat tovább folytatódhat a felhasználók szélesebb csoportjain vagy szintjein keresztül, amíg mindenki nem használja az új kiadást. Az olyan modern folyamatos kézbesítési platformok, mint a GitHub Actions és az Azure Pipelines, a szintekkel rendelkező üzembehelyezési folyamat létrehozása bármilyen méretű DevOps-csapat számára elérhető.

Funkciójelölők

Bizonyos funkciókat néha egy kiadás részeként kell üzembe helyezni, de kezdetben nem kell a felhasználók számára elérhetővé tenni. Ezekben az esetekben a funkciójelzők olyan megoldást nyújtanak, amelyben a funkciók engedélyezhetők a környezet, a szint vagy bármely más konkrét üzembe helyezés alapján végzett konfigurációs módosításokkal.

Felhasználói bejelentkezés

A funkciójelzőkhöz hasonlóan a felhasználói bejelentkezés lehetővé teszi az expozíció korlátozását. Ebben a modellben egy adott funkció engedélyezve van a kiadásban, de nem aktiválódik a felhasználó számára, kivéve, ha kifejezetten ezt szeretné. A kockázattűrési döntés ki van töltve a felhasználók számára, így eldönthetik, milyen gyorsan szeretnének bizonyos frissítéseket bevezetni.

Egyszerre több gyakorlatot is alkalmaznak. Előfordulhat például, hogy egy csapatnak van egy kísérleti funkciója, amely egy nagyon konkrét használati esethez készült. Mivel kockázatos, üzembe helyezik az első szinten, hogy a belső felhasználók kipróbálják. Annak ellenére, hogy a funkciók a kódban találhatók, valakinek be kell állítania egy adott üzembe helyezés funkciójelzőjét a rétegen belül, hogy a szolgáltatás a felhasználói felületen keresztül legyen elérhető. A funkciójelző akkor is csak akkor teszi elérhetővé a lehetőséget, ha egy felhasználó az új funkció használatát választja. Aki nem a rétegben, az adott üzembe helyezésben vagy nem jelentkezett be, nem lesz kitéve a funkciónak. Bár ez egy meglehetősen ellentmondásos példa, a progresszív expozíció rugalmasságának és gyakorlatiasságának szemléltetésére szolgál.

Gyakori problémák a csapatok előtt

Ahogy a csapatok az Agile DevOps-gyakorlat felé haladnak, problémákba ütközhetnek, amelyek összhangban állnak másokkal, akik a hagyományos monolitikus szállításoktól távolodtak el. A néhány havonta egyszer üzembe helyezéshez használt teams rendelkezik egy olyan gondolkodásmódkal, amely puffereli a stabilizálást. Azt várják, hogy minden egyes üzembe helyezés jelentős változást fog bevezetni a szolgáltatásban, és előre nem látható problémák lépnek fel.

A hasznos adatok túl nagyok

A néhány havonta üzembe helyezett szolgáltatások általában sok módosítással vannak kitöltve. Ez növeli annak valószínűségét, hogy azonnali problémák lépnek fel, és megnehezíti a problémák elhárítását is, mivel olyan sok új dolog van. A gyakoribb szállításokra való áttéréssel a telepített termékek közötti különbségek kisebbek lesznek, ami lehetővé teszi a célzottabb tesztelést és a könnyebb hibakeresést.

Nincs szolgáltatáselkülönítés

A monolitikus rendszerek hagyományosan úgy vannak skálázva, hogy simítják a hardvert, amelyen üzembe helyezték őket. Ha azonban valami probléma merül fel a példánnyal, az mindenkinek problémát okoz. Az egyik egyszerű megoldás, ha több példányt ad hozzá a felhasználók terheléselosztásához. Ez azonban jelentős architekturális szempontokat igényelhet, mivel számos örökölt rendszer nem többpéldányos kialakítású. Emellett előfordulhat, hogy jelentős ismétlődő erőforrásokat kell lefoglalni olyan funkciókhoz, amelyek máshol jobban konszolidálhatók.

Az új funkciók hozzáadásakor vizsgálja meg, hogy a mikroszolgáltatás-architektúra segíthet-e a hatékonyabb szolgáltatáselkülönítésnek köszönhetően a működésben és a méretezésben.

A manuális lépések hibákhoz vezetnek

Ha egy csapat évente csak néhány alkalommal helyezi üzembe a telepítést, előfordulhat, hogy a szállítás automatizálása nem éri meg a befektetést. Ennek eredményeképpen számos üzembehelyezési folyamat manuálisan lesz felügyelve. Ez jelentős időt és erőfeszítést igényel, és hajlamos az emberi hibákra. A leggyakoribb buildelési és üzembehelyezési feladatok automatizálása hosszú utat tehet meg az elveszett idő és a ki nem kényszerített hibák csökkentése felé.

A Teams az infrastruktúrát kódként is használhatja az üzembehelyezési környezetek jobb ellenőrzése érdekében. Ez szükségtelenné teszi, hogy az operatív csapat manuális módosításokat hajtson végre, mivel új funkciók vagy függőségek jelennek meg a különböző üzembehelyezési környezetekben.

Csak az ops végezhet üzembe helyezéseket

Egyes szervezetek olyan szabályzatokkal rendelkeznek, amelyek megkövetelik, hogy az összes üzembe helyezést az operatív személyzet kezdeményezhesse és felügyelje. Bár korábban jó oka lehetett ennek, az Agile DevOps-folyamat nagy előnyökkel jár, ha a fejlesztői csapat elindíthatja és vezérelheti az üzembe helyezéseket. A modern folyamatos kézbesítési platformok részletesen szabályozhatják, hogy kik kezdeményezhetik az üzembe helyezéseket, és kik férhetnek hozzá az állapotnaplókhoz és egyéb diagnosztikai információkhoz, így a megfelelő személyek a lehető leggyorsabban hozzájuthatnak a megfelelő információkhoz.

A hibás üzemelő példányok folytatódnak, és nem állíthatók vissza

Néha az üzembe helyezés hibás, és a csapatoknak foglalkozniuk kell vele. Ha azonban a folyamatok manuálisak, és az információkhoz való hozzáférés lassú és korlátozott, nehéz lehet visszatérni egy korábbi működő üzembe helyezéshez. Szerencsére különböző eszközök és eljárások állnak rendelkezésre a sikertelen üzembe helyezés kockázatának csökkentésére.

Alapvető alapelvek

A biztonságos üzembe helyezési eljárásokat alkalmazó csapatoknak alapvető alapelveket kell meghatározniuk az erőfeszítések alapjául.

Konzisztens

Az éles környezetben való üzembe helyezéshez használt eszközöket fejlesztési és tesztelési környezetekben kell használni. Ha problémák merülnek fel, például azok, amelyek gyakran a függőségek vagy eszközök új verzióiból erednek, akkor ezeket jóval azelőtt kell elkapni, hogy a kód éles környezetben való kiadásához közeledne.

A minőségi jelek ápolása

Túl sok csapat kerül abba a közös csapdába, hogy nem igazán törődik a minőségi jelekkel. Idővel előfordulhat, hogy teszteket írnak, vagy minőségi feladatokat végeznek egyszerűen azért, hogy egy sárga figyelmeztetést zöld jóváhagyásra módosítsanak. A minőségi jelek nagyon fontosak, mivel egy projekt impulzusát képviselik. Az üzemelő példányok jóváhagyásához használt minőségi jelzéseket minden nap folyamatosan nyomon kell követni.

Az üzemelő példányoknak nulla állásidőt kell igényelniük

Bár nem kritikus fontosságú, hogy minden szolgáltatás mindig elérhető legyen, a csapatoknak úgy kell megközelíteniük a DevOps kézbesítési és üzemeltetési fázisait, hogy új verziókat helyezhetnek üzembe anélkül, hogy bármikor le kellene venniük őket. A modern infrastruktúra és folyamateszközök már elég fejlettek, és gyakorlatilag bármely csapat számára megvalósítható, hogy 100% üzemidőt céloznak meg.

Az üzembe helyezésnek munkaidőben kell történnie

Ha egy csapat azzal a gondolkodásmóddal dolgozik, hogy az üzemelő példányok nulla állásidőt igényelnek, akkor nem igazán számít, ha leküldi az üzembe helyezést. Emellett előnyössé válik az üzemelő példányok leküldése munkaidőben, különösen a nap elején és a hét elején. Ha valami nem sikerül, elég korán kell nyomon követni, hogy szabályozni lehessen a robbanás sugarát. Emellett mindenki már dolgozik, és a problémák megoldására összpontosít.

Rétegalapú üzembe helyezés

Az érett DevOps-kiadási eljárásokkal rendelkező csapatok képesek a rétegalapú üzembe helyezésre. Ebben a modellben az új funkciók először azokat az ügyfeleket ismertetik, akik hajlandók a legnagyobb kockázatot vállalni. Ahogy az üzembe helyezés bizonyított, a célközönség egyre több felhasználót is bevon, amíg mindenki nem használja.

Példaszintű modell

Egy tipikus rétegbeli üzemi modell úgy lett kialakítva, hogy a felhasználók és az infrastruktúra gondos szegmentálásával a lehető leghamarabb megtalálja a problémákat. Az alábbi példa bemutatja, hogyan használják a szinteket a Microsoft egyik fő csapata.

Kategória	Cél	Felhasználók	Adatközpont
0	Megkeresi az üzembe helyezés által bevezetett felhasználókat érintő hibák többségét	Csak belső, magas kockázat- és hibatűrés	USA nyugati középső régiója
1	A csapat által nem tesztelt területek	A termék szélességét használó ügyfelek	Kis adatközpont
2	Méretezéssel kapcsolatos problémák	Nyilvános fiókok, ideális esetben ingyenesek különböző funkciókkal	Közepes vagy nagy adatközpont
3	A belső fiókok skálázási problémái és a nemzetközi vonatkozású problémák	Nagy belső fiókok és európai ügyfelek	Belső adatközpont és európai adatközpont
4	Fennmaradó skálázási egységek	Mindenki más	Minden üzembehelyezési cél

Sütési idő engedélyezése

A sütési idő kifejezés azt az időtartamot jelenti, amely alatt az üzembe helyezés futtatható, mielőtt a következő szintre bővül. Egyes problémák a tünetek megjelenésének megkezdéséhez órákat vagy hosszabb időt is igénybe vehetnek, ezért a kiadásnak megfelelő ideig kell használatban lennie, mielőtt készenlétbe kerül.

Általánosságban elmondható, hogy a 24 órás napnak elegendő időnek kell lennie ahhoz, hogy a legtöbb forgatókönyv látens hibákat tegyen közzé. Ennek az időszaknak azonban tartalmaznia kell egy csúcsidőszakot, amely teljes munkanapot igényel az olyan szolgáltatások esetében, amelyek munkaidőben tetőznek.

Gyorsjavítások

Élő webhelyesemény (LSI) akkor fordul elő, ha egy hiba komoly hatással van az éles környezetre. Az LSI-k szükségessé teszik egy gyorsjavítás létrehozását, amely egy sávon kívüli frissítés, amely egy magas prioritású probléma megoldására lett kialakítva.

Ha egy hiba Sev 0, a legsúlyosabb hibatípus, a gyorsjavítást a lehető leggyorsabban üzembe helyezheti az érintett méretezési egységen. Bár kritikus fontosságú, hogy a javítás ne rontsa a dolgokat, az ilyen súlyosságú hibák annyira zavarónak minősülnek, hogy azonnal meg kell oldani őket.

Az 1. Sev besorolású hibákat a 0. szinten kell üzembe helyezni, de a jóváhagyást követően azonnal üzembe helyezhetők az érintett méretezési egységekben.

Az alacsonyabb súlyosságú hibák gyorsjavításait a tervek szerint minden szinten üzembe kell helyezni.

Főbb elvitelek

Minden csapat gyorsan és a lehető legmagasabb minőségben szeretné biztosítani a frissítéseket. A megfelelő eljárásokkal a teljesítés a DevOps-ciklus hatékony és fájdalommentes része lehet.

• Gyakran üzembe helyezhető.
• Maradjon zöld az egész futamban.
• Konzisztens üzembehelyezési eszközök használata a fejlesztésben, tesztelésben és éles környezetben.
• Használjon folyamatos kézbesítési platformot, amely lehetővé teszi az automatizálást és az engedélyezést.
• Kövesse a biztonságos üzembehelyezési eljárásokat.

Következő lépések

Megtudhatja, hogyan segítenek a funkciójelzők az új funkciók felhasználók számára való kitettségének szabályozásában.