A Microsoft megbízható rendszerek üzemeltetése a DevOps használatával

A Microsoft a kereskedelmi internet legkorábbi napjai óta összetett online platformokat üzemeltet. Az út során számos olyan gyakorlatot alakítottunk ki, amelyek biztosítják a rendszerek rendelkezésre állását, kifogástalan állapotát és biztonságát. Ezek a gyakorlatok egy nagyobb kezdeményezés részét képezik az élő webhelykultúrák fenntartására és fejlesztésére.

Élő webhelykultúra

Az élő webhelykultúra a szervezet fókuszában az élő webhely élményének és megbízhatóságának rangsorolása minden másnál. Elvégre az ügyfelek manapság meglehetősen könnyen mozoghatnak a szolgáltatók között a felhő- és internetalapú szolgáltatásokkal, ami jelentősen növeli az ügyfelek bizalmának fontosságát. Az élő webhelynek mindig elérhetőnek kell lennie, és az ügyfeleknek ígért módon kell végrehajtania.

Számos tényező járul hozzá a sikeres élő webhelykultúrához.

Elsőként élő webhely

Az élő webhely használatának első helyezése a sikeres platform szerves része. A Teams nem tudja az összes fókuszt az új, fényes funkciókra helyezni, és figyelmen kívül hagyni azt a lehetőséget, amelyben ezeket a funkciókat a felhasználók bemutatták. Megbízható üzembehelyezési eljárásokra támaszkodunk, amelyek biztosítják, hogy ügyfeleink zavartalan platformhozzáférést élvezhessenek. Ez különösen bonyolulttá teheti a verziószámozott szolgáltatásfrissítések leállási idő nélküli kiadását.

Az expozíció szabályozása funkciójelzőkkel

Ahogy a szinteken és szakaszokon keresztül helyezzük üzembe az üzembe helyezést, és a funkciójelzőkkel szabályozzuk az expozíciót, időnként felfedezünk egy problémát az éles környezetben. Az automatizálás és a felülvizsgálatok ellenére néha még mindig történnek dolgok. Ahogy mondják, nincs olyan hely, mint a termelés!

Az állapotfigyelés és a telemetriai adatok általában akkor figyelmeztetnek minket, ha valami nem megfelelő. A fejlesztő létrehozhat egy ágat, mainkijavíthatja és lekérheti.main Az általános munkafolyamat megtartása azt jelenti, hogy a fejlesztőknek nem kell környezetváltást vagy más folyamatot megtanulniuk egy másik kódmódosításhoz.

A gyorsjavítás üzembe helyezésének kezeléséhez még egy lépésre van szükség, amely a módosítás kiadási ágba való kiválasztásával érhető el. Minden hétköznap reggel futtatunk egy gyorsjavítás-telepítést az aktuális kiadási ágból, de igény szerint ezt is elvégezhetjük sürgős javítások esetén. A javítás valójában a kiadási ágon kívülre hajtja végre az éles üzemet. Mivel azonban először fejlesztünk main , tudjuk, hogy a következő futam nem fog visszafejlődni, amikor létrehozunk egy új kiadási ágat main.

A helyszíni termékek kiadásai nagyrészt megegyeznek, bár az üzembehelyezési szintek és a fázisok nélkül. Mivel a különböző konfigurációkon és adatalakzatokon több manuális tesztelést végezünk, a kiadási ág vágása és a termék ügyfelek kezébe helyezése között hosszabb a farka.

A biztonságot személyesen kell átvenni

A fókusz az, hogy a biztonsági rések valós és személyes. Ez biztosítja, hogy az emberek igazán érdekel. A háborús játékokat is széles körben használjuk a rendszer biztonsági kockázatainak megkeresésére és kezelésére, akár kódban, akár nem. Amikor a piros csapat egy párbeszédpanel fejjel lefelé történő elforgatásával meg tudja jeleníteni, hogy kódba került, valóban arra ösztönzi a kód tulajdonosát, hogy kezelje a problémát, és győződjön meg arról, hogy az nem fordul elő sehol máshol. Ez a fajta verseny sokkal valósabb és személyesebb, mint egy statikus elemzési figyelmeztetés egy lehetséges XSS-kockázattal kapcsolatban. Ezt a fajta kultúrát és dinamikusat háborús játékokkal és más biztonsági gyakorlatokkal hozzuk létre. Az emberek büszkék arra, hogy feltörik egymás kódját, vagy képesek blokkolni a kísérleteket. Ez biztonságos kódkultúrát biztosít.

Nem tudunk minden támadási vektort megtervezni, de azt feltételezzük, hogy incidens lesz, és megtervezzük, hogy milyen gyorsan tudunk reagálni a támadásra. Sok biztonsági munka történt a csapataink számára.

Végül az emberek hibáznak. Néha lusták, és olyan műveleteket végeznek, mint a jelszavak tárolása a fájlmegosztásokon. Megmondhatjuk nekik, hogy ne, és elküldhetjük őket a biztonsági képzésre, és mindenféle más dolgot is el tudunk végezni. A legtöbben tanulnak, de csak egy személynek kell feltörnie a rendszert. Sokféle ajánlott eljáráslistával rendelkezhet, de ha nem teszi ezt valóssá, feltételeznie kell, hogy az emberek hibázni fognak. Ez bizonyos szintű felügyeletet igényel a kritikus folyamatok követésének biztosításához.

A mérnöki munka több mint ops-partner

Korán megtanultuk, hogy az élő helyszín a mérnöki csapat feladatainak fontos része legyen. Ez óriási volt számunkra, mert a múltban egy személy üzembe helyezhetett valamit, elment a hétvégére, és hétfőn visszatérhetett, hogy 900 ügyfélproblémát találjon, amelyekkel az ügyfélszolgálat és az ops csapatok az egész hétvégén foglalkoztak. Fontos, hogy a mérnöki munka megfizesse az élő webhelyekkel kapcsolatos problémák árát. Ellenkező esetben nem érdemes olyan rendszereket létrehozni, amelyek elkerülik ezeket a problémákat. Amikor hajnali 2-kor felhívnak, hogy kijavítsa, amit eltört, emlékszel.

Ahogy továbbfejlesztettük ezt a felelősséget, az élő webhely a legfontosabb dolog, hogy mi lettünk az egész csapat mantra. Ez az ügyfélélmény, amit most tapasztalnak, és ez nem csak egy adó. Ez valójában olyasmi, amire az emberek számítanak tőlünk, és büszkék vagyunk rá. A termék megkülönböztető funkciójának kell lennie.

Az éles telemetria a szolgáltatás szívverése

Ahhoz, hogy túléljük a gyors ütemű világban, ahol gyakorlatilag bármi elromlhat, nagy riasztási rendszerekre van szükségünk. A nem végrehajtható riasztások, redundáns riasztások vagy túlterhelt riasztási kötetek miatt figyelmen kívül hagyhatja az összes riasztást. Könnyű túl sok riasztást létrehozni, így a folyamat valójában egy egyszerű kérdésre vezethető vissza: Alkalmazható-e ez a riasztás? Ez biztosítja, hogy a megfelelő ügyfelekkel kapcsolatos problémákat a lehető leggyorsabban kezeljük.

Ahogy a mérnöki csapat nullázott a végrehajtható riasztásokon, észrevette, hogy sok, különösen az éjszaka közepén felmerülő probléma általában hasonló javításokkal rendelkezik, legalábbis ideiglenesen. Ez azt eredményezte, hogy olyan rendszerekre összpontosítottak, amelyek jobbak voltak a feladatátvételben és az öngyógyításban. A problémák most már előfordulnak, riasztásokat emelnek ki, majd elég jól kijavítják magukat ahhoz, hogy a mérnöki csapat reggelig várjon a javításra. Ez nem történt volna meg, ha a mérnöki csapat csak leküldi azokat a biteket, amelyek másokat éjszaka tartanak fenn. Most már azon dolgoznak, hogy kiegyensúlyozza ezeket a fejlesztéseket, nem csupán a funkciók sebességének, hanem a mérnöki fejlődés sebességének részeként.

Összefoglalás

Az élő webhelykultúra bevezetése hatással volt arra, ahogyan a Microsoft szoftvereket készít és szállít. Azáltal, hogy a mérnöki csapatokat a biztonság és a műveletek kulcsfontosságú részévé tette, a kód minősége és a végfelhasználói élmény jelentősen javult. A műveletek teljes résztvevőjeként a mérnöki munka kulcsfontosságú szerepet játszik, ami jobb üzemeltetésre tervezett rendszereket eredményezett.