Megosztás a következőn keresztül:

Több-bérlős megoldások frissítésével kapcsolatos szempontok

  • Cikk

A felhőtechnológia egyik előnye a folyamatos fejlesztés és fejlődés. Szolgáltatóként frissítéseket kell alkalmaznia a megoldásra: előfordulhat, hogy módosítania kell az Azure-infrastruktúrát, a kódot/alkalmazásokat, az adatbázissémákat vagy bármely más összetevőt. Fontos megtervezni a környezetek frissítésének módját. A több-bérlős megoldásokban különösen fontos tisztában lenni a frissítési szabályzattal, mert előfordulhat, hogy egyes bérlők nem szívesen engedélyezik a környezetük módosítását, vagy olyan követelményekkel rendelkeznek, amelyek korlátozzák a szolgáltatás frissítésének feltételeit.

A megoldás frissítésére vonatkozó stratégia tervezésekor a következőket kell elvégeznie:

  • Azonosítsa a bérlők követelményeit.
  • A szolgáltatás működtetésére vonatkozó saját követelmények tisztázása.
  • Keresse meg azt az egyenleget, amelyet Ön és a bérlői is elfogadhatnak.
  • A stratégiát egyértelműen közölheti a bérlőkkel és más érdekelt felekkel.

Ebben a cikkben útmutatást nyújtunk a műszaki döntéshozóknak a bérlők szoftverének frissítéséhez megfontolható megközelítésekhez és az ezzel járó kompromisszumokhoz.

Az ügyfelek követelményei

A következő kérdéseket kell figyelembe venni:

  • Elvárások és követelmények: Az ügyfeleknek vannak elvárásaik vagy követelményeik azzal kapcsolatban, hogy mikor frissíthetők? Előfordulhat, hogy ezeket a szerződésekkel vagy szolgáltatásiszint-szerződésekkel hivatalosan közlik Önekkel, vagy nem hivatalosak.
  • Karbantartási időszakok: Elvárják az ügyfelek a szolgáltatás által meghatározott vagy akár ön által meghatározott karbantartási időszakokat? Előfordulhat, hogy kommunikálniuk kell a saját ügyfeleikkel az esetleges kimaradásokról.
  • Rendeletek: Vannak olyan szabályozási aggályai az ügyfeleknek, amelyek további jóváhagyást igényelnek a frissítések alkalmazása előtt? Ha például IoT-összetevőket tartalmazó egészségügyi megoldást ad meg, előfordulhat, hogy a frissítés alkalmazása előtt jóváhagyást kell kérnie a Egyesült Államok Food and Drug Administration (FDA) alkalmazásához.
  • Érzékenység: Vannak olyan ügyfelei, akik különösen érzékenyek vagy ellenállnak a frissítések alkalmazásának? Próbálja megérteni, miért. Ha például fizikai áruházat vagy kiskereskedelmi webhelyet futtatnak, érdemes lehet elkerülni a Black Friday körüli frissítéseket, mert a kockázatok magasabbak a lehetséges előnyöknél.
  • Történelem: Mi a sikeres frissítések sikeres befejezésének nyomon követése az ügyfelekre gyakorolt hatás nélkül? A szolgáltatáskimaradások valószínűségének csökkentése és a frissítések által bevezetett problémák gyors azonosítása érdekében kövesse a devOps, a tesztelés, az üzembe helyezés és a monitorozás megfelelő eljárásait. Ha az ügyfelek tudják, hogy gördülékenyen tudja frissíteni a környezetüket, akkor kevésbé valószínű, hogy kifogást fognak tenni.
  • Visszagurítás: Az ügyfelek vissza szeretnék-e váltani a frissítéseket, ha kompatibilitástörő változás történik?

Az Ön követelményei

A következő kérdéseket is figyelembe kell vennie a saját szemszögéből:

  • Szabályozhatja, hogy ön hajlandó-e megadni a következőket: Ésszerű az ügyfeleknek szabályozni, hogy mikor alkalmazzák a frissítéseket? Ha nagyvállalati ügyfelek által használt megoldást hoz létre, a válasz lehet igen. Ha azonban fogyasztóközpontú megoldást hoz létre, nem valószínű, hogy szabályozni fogja a megoldás frissítését vagy működtetését.
  • Verziók: A megoldás hány verzióját tudja egyszerre ésszerűen karbantartani? Ne feledje, hogy ha hibát talál, és gyorsjavításra van szüksége, előfordulhat, hogy a gyorsjavítást az összes használt verzióra alkalmaznia kell.
  • A régi verziók következményei: Milyen hatással van arra, hogy az ügyfelek túl messzire esnek a jelenlegi verziótól? Ha rendszeresen ad ki új funkciókat, a régi verziók gyorsan elavulttá válnak? Emellett a frissítési stratégiától és a módosítások típusától függően előfordulhat, hogy a megoldás minden verziójához külön infrastruktúrát kell fenntartania. Így üzemeltetési és pénzügyi költségek is felmerülhetnek, mivel továbbra is támogatja a régebbi verziókat.
  • Visszagurítás: Támogatja az üzembehelyezési stratégia a korábbi verziókra való visszaállítást? Ezt engedélyezni szeretné?

Megjegyzés

Fontolja meg, hogy offline állapotba kell-e helyeznie a megoldást frissítések vagy karbantartás céljából. A szolgáltatáskimaradási időszakok általában elavult gyakorlatnak minősülnek, és a modern DevOps-eljárások és felhőtechnológiák lehetővé teszik az állásidő elkerülését a frissítések és karbantartások során. A nulla állásidős üzemelő példányokat azonban ki kell terveznie, ezért a megoldásarchitektúra tervezésekor fontos figyelembe venni a frissítési folyamatot.

Még ha nem is tervez kimaradásokat a frissítési folyamat során, érdemes lehet normál karbantartási időszakot meghatároznia. Az ablakok segíthetnek kommunikálni az ügyfelekkel arról, hogy a változások adott időpontokban történnek.

A nulla állásidős üzemelő példányok eléréséről további információt az Állásidő megszüntetése verziószámozott szolgáltatásfrissítésekkel című témakörben talál.

Egyenleg keresése

Ha a szolgáltatásfrissítések ütemezését teljes egészében a bérlők saját belátása szerint hagyja, akkor dönthetnek úgy, hogy soha nem frissülnek. Fontos, hogy lehetővé tegye saját magának a megoldás frissítését, és figyelembe vegye az ügyfelek esetlegesen felmerülő ésszerű aggályait vagy korlátait. Ha például egy ügyfél különösen érzékeny a pénteki frissítésekre, mert ez a hét legforgalmasább napja, akkor egyszerűen elhalaszthatja a frissítéseket hétfőre anélkül, hogy ez hatással lenne a megoldásra?

Az egyik jól használható módszer a frissítések bérlőnkénti bevezetése az alábbi módszerek egyikével. Értesítheti az ügyfelet a tervezett frissítésekről. Lehetővé teszi az ügyfelek számára, hogy ideiglenesen lemondják, de nem örökre; ésszerű korlátot szabjon meg arra vonatkozóan, hogy mikor lesz szükség a frissítés alkalmazására.

Emellett fontolja meg a biztonsági javítások vagy egyéb kritikus gyorsjavítások minimális vagy előzetes értesítés nélküli üzembe helyezésének lehetőségét.

Egy másik megközelítés lehet, ha lehetővé teszi a bérlők számára, hogy saját frissítéseket kezdeményezhessenek a választott időpontban. Ismét meg kell adnia egy határidőt, amely időpontban alkalmazza a frissítést a nevükben.

Figyelmeztetés

Ügyeljen arra, hogy a bérlők saját frissítéseket kezdeményezhessenek. Ezt összetetten kell megvalósítani, és jelentős fejlesztési és tesztelési erőfeszítésekre lesz szükség a szállításhoz és a karbantartáshoz.

Bármit is tesz, győződjön meg arról, hogy rendelkezik a bérlők állapotának figyelésére vonatkozó folyamatokkal, különösen a frissítések alkalmazása előtt és után. A kritikus éles incidensek (más néven élő telephelyi incidensek) gyakran a kód vagy a konfiguráció frissítése után fordulnak elő. Ezért fontos, hogy proaktívan monitorozza az ügyfelek bizalmát, és válaszoljon az esetleges problémákra. A monitorozással kapcsolatos további információkért lásd a DevOps monitorozását ismertető cikket.

Kommunikáció az ügyfelekkel

A világos kommunikáció kulcsfontosságú az ügyfelek bizalmának kiépítéséhez. Fontos elmagyarázni a rendszeres frissítések előnyeit, beleértve az új funkciókat, a hibajavításokat, a biztonsági rések elhárítását és a teljesítmény javítását. A modern, felhőben üzemeltetett megoldások egyik előnye a funkciók és frissítések folyamatos kézbesítése.

A következő kérdéseket kell figyelembe venni:

  • Értesíti az ügyfeleket a közelgő frissítésekről?
  • Ha igen, implicit módon kér engedélyt egy leiratkozási folyamat megadásával, és milyen korlátok vonatkoznak a letiltásra?
  • Van ütemezett karbantartási időszaka, amelyet a frissítések alkalmazásakor használ?
  • Mi a teendő, ha vészhelyzeti frissítést, például kritikus biztonsági javítást használ? Kényszerítheti a frissítéseket ezekben a helyzetekben?
  • Ha nem tud proaktív módon értesíteni az ügyfelet a közelgő frissítésekről, megadhat visszamenőleges értesítéseket? Frissíthet például egy lapot a webhelyén az alkalmazott frissítések listájával?
  • Hány különálló verziót tart fenn a rendszer éles környezetben?

Kommunikáció az ügyfélszolgálati csapattal

Fontos, hogy a saját támogatási csapata teljes körűen átláthassa az egyes bérlőkre alkalmazott frissítéseket. Az ügyfélszolgálati képviselőknek könnyen meg kell tudniuk válaszolni a következő kérdéseket:

  • Alkalmaztak frissítéseket a bérlő infrastruktúrájára a közelmúltban?
  • Milyen jellegűek ezek a frissítések?
  • Mi volt az előző verzió?
  • Milyen gyakran alkalmazzák a frissítéseket erre a bérlőre?

Ha az egyik ügyfél egy frissítés miatt problémába ütközik, meg kell győződnie arról, hogy az ügyfélszolgálati csapat rendelkezik a változások megértéséhez szükséges információkkal.

A frissítéseket támogató üzembehelyezési stratégiák

Gondolja át, hogyan fogja telepíteni a frissítéseket az infrastruktúrán. Ezt nagy mértékben befolyásolja a használt bérlői modell . A frissítések központi telepítésének három gyakori módszere az üzembehelyezési bélyegek, a funkciójelölők és az üzembehelyezési körök. Ezeket a megközelítéseket egymástól függetlenül is használhatja, vagy kombinálhatja őket az összetettebb követelmények teljesítéséhez.

Minden esetben győződjön meg arról, hogy rendelkezik a megfelelő jelentéskészítéssel és láthatósággal, hogy tudja, az egyes bérlők melyik infrastruktúrájának, szoftverének vagy funkciójának melyik verziója, mire jogosultak a migrálásra, és hogy az adott állapotokhoz kapcsolódó, időhöz kapcsolódó adatokról is értesüljön.

Üzembehelyezési bélyegek mintája

Számos több-bérlős alkalmazás alkalmas az Üzembe helyezési bélyegek mintára, amelyben az alkalmazás és más összetevők több példányát helyezi üzembe. Az elkülönítési követelményektől függően előfordulhat, hogy minden bérlőhöz telepít egy bélyeget, vagy megosztott bélyegeket, amelyek több bérlő számítási feladatait futtatják.

A bélyegek kiválóan alkalmasak a bérlők elkülönítésére. Emellett rugalmasságot biztosítanak a frissítési folyamathoz, mivel a frissítéseket fokozatosan, másokat nem érintve helyezheti üzembe a bélyegek között.

Funkciójelölők

A funkciójelölők lehetővé teszik, hogy funkciókat adjon a megoldáshoz, miközben ezt a funkciót csak az ügyfelek vagy bérlők egy részhalmaza számára teszi közzé.

Érdemes lehet funkciójelölőket használni, ha az alábbi helyzetek valamelyike vonatkozik Önre:

  • Rendszeresen telepít frissítéseket, de el szeretné kerülni az új funkciók megjelenítését, amíg azok teljes mértékben be nem implementálva nem lesznek.
  • Ne alkalmazzon módosításokat a viselkedésben, amíg az ügyfél be nem jelentkezik.

A funkciójelölő támogatása beágyazható az alkalmazásba úgy, hogy saját maga ír kódot, vagy egy olyan szolgáltatás használatával, mint a Azure App Configuration.

Üzembehelyezési körök

Az üzembehelyezési körök lehetővé teszik a frissítések fokozatos bevezetését bérlők vagy üzembehelyezési bélyegek halmazában. A bérlők egy részhalmazát minden körhöz hozzárendelheti.

Meghatározhatja, hogy hány gyűrűt hozzon létre, és mit jelent az egyes gyűrűk a saját megoldásához. A szervezetek általában a következő köröket használják:

  • Kanári: A kanári-kör magában foglalja a saját tesztbérlőit és azokat az ügyfeleket, akik azonnal frissíteni szeretnének, amint elérhetők, azzal a megértéssel, hogy gyakrabban kapnak frissítéseket, és hogy a frissítések nem voltak olyan átfogó ellenőrzési folyamaton, mint a többi dologban.
  • Korai örökbefogadó: A korai bevezetési kör olyan bérlőket tartalmaz, akik kissé nagyobb kockázattal járnak, de még mindig készen állnak a rendszeres frissítések fogadására.
  • Felhasználók: A bérlők többsége a felhasználók köréhez fog tartozni, amely ritkábban és fokozottan tesztelt frissítéseket kap.

API-verziók

Ha a szolgáltatás külső API-t tesz elérhetővé, vegye figyelembe, hogy az ön által alkalmazott frissítések hatással lehetnek arra, ahogyan az ügyfelek vagy partnerek integrálódnak a platformmal. Különösen tisztában kell lennie az API-k kompatibilitástörő változásaival. Fontolja meg egy API-verziószámozási stratégia használatát az API frissítéseinek kockázatának mérsékléséhez.

Közreműködők

Ezt a cikket a Microsoft tartja karban. Eredetileg a következő közreműködők írták.

Fő szerző:

  • John Downs | Az Azure-hoz készült FastTrack vezető ügyfélmérnöke

Egyéb közreműködők:

A nem nyilvános LinkedIn-profilok megtekintéséhez jelentkezzen be a LinkedInbe.

Következő lépések