A Microsoft 365 több mint kilencórás leállása: 5 tudnivaló
Az IT Channel 2026-ban megvizsgálja, hogy a számítási igényű mesterséges intelligencia terhelése milyen hatással lesz a felhőre.
Ezen a héten a Microsoft lett a legújabb szállító, amely hatalmas leállást tapasztalt, amely több terméket és szolgáltatást is érintett. És bár a technológiai óriáscég nem hozta összefüggésbe a kudarcot semmivel, ami a mesterséges intelligenciával kapcsolatos, a csatorna figyelemmel fogja kísérni a megnövekedett mennyiséget és az ügyfeleire gyakorolt mélyebb hatásokat, amelyek ezekből a kiesésekből származnak, mivel a vállalkozások megerőltetik a számításigényesebb munkaterhelést.
A redmondi (Washington állam) székhelyű Microsoft – amely közel 500 000 partnerrel a csatorna egyik legnagyobb ökoszisztémájával rendelkezik – legutóbbi leállásának széles körű hatásait tükrözve a DownDetector 12 380 bejelentést rögzített a Microsoft Outlook e-mail szolgáltatásának kieséséről január 22-én 15:15-kor.
A kimaradásészlelő webhely 15 745 bejelentést naplózott a Microsoft 365 Suite felhőalkalmazásainak kimaradásáról az európai idő szerint hajnali 3:17-kor, a Microsoft Store esetében pedig 2246 jelentést 3:29-kor (ET).
(Kapcsolódó: 2025 10 legnagyobb felhőszakadása: AWS, Google és Microsoft)
Microsoft leállás
Most, hogy a probléma megoldódott, a CRN felvette a kapcsolatot a Microsofttal megjegyzésért.
David Steiner, a US ITec elnöke, a CRN 2025 MSP 500 NY-ban székelő buffalói tagja, cége által az Invarosoft ITSupportPanel alkalmazást használta az ügyfelekkel való hatékony kommunikáció érdekében a kiesés során, így ez „a legstresszmentesebb kiesés, amelyet valaha tapasztaltunk”.
Steiner szerint rendkívül fontos, hogy az MSP-k proaktívan kommunikáljanak az ügyfelekkel egy kiesés során. „Régebben a telefonjaink leégtek, és az OnCall technikusaival folytatott órákon át tartó hívásaink megőrültek, mert az emberek nem voltak tudatában a kimaradásoknak” – mondta.
Májusban a szervezet kijelentette az Uptime Institute éves kimaradás-elemzési jelentésében, hogy „A mesterséges intelligencia iránti növekvő kereslet nyomást gyakorol a meglévő infrastruktúra-tervekre – különösen az energiaellátás és a hűtés terén -, miközben az elektromos hálózat korlátai és a globális kereskedelmi feszültségek új bizonytalanságot teremtenek az ellátási láncokban és a terjeszkedési tervekben.”
Az általános mesterségesintelligencia-korszak immár negyedik éve, és több projekt hagyja el a kísérleti fázist a gyártásban, az informatikai szakembereknek szem előtt kell tartaniuk, hogy ez milyen hatással lesz a felhő megbízhatóságára és stabilitására.
Itt van minden, amit a héten több mint kilenc órán át tartó Microsoft 365 kimaradásról tudnia kell.
Több Microsoft termék is eltalált
A leállás több Microsoft 365-szolgáltatást is érintett, köztük az Outlookot, az Exchange Online-t, valamint a SharePoint Online-ban, a Microsoft OneDrive-ban és a Microsoft Teams-ben végzett keresést.
A leállás a Microsoft Purview, a Microsoft Defender XDR és a Microsoft 365 Felügyeleti Központ szolgáltatási portáljához való hozzáférést is érintette.
A kimaradás során az Outlook-felhasználók „451 4.3.2 ideiglenes kiszolgálóhiba” hibaüzenetet kaptak, amikor e-maileket küldtek vagy fogadtak. Az eladó szerint a felhasználók nem tudtak e-maileket küldeni és fogadni az Exchange Online-on keresztül, beleértve a Microsoft Viva Engage értesítő e-mailjeit sem.
További felmerült problémák közé tartozik az, hogy nem lehetett Microsoft Fabric-en keresztül előfizetési e-maileket küldeni és fogadni, üzenetnyomokat gyűjteni, a SharePoint Online-on és a Microsoft OneDrive-on belül nem lehetett keresni, és nem lehetett tagokat hozzáadni csevegésekhez, értekezletekhez, csapatokhoz, csatornákhoz, illetve tagokat hozzáadni a Microsoft Teamshez.
A Teams felhasználóinak problémái voltak a jelenléti és helyadatokhoz való hozzáféréssel is. A Microsoft szerint a Fabric-felhasználók azt vették észre, hogy képtelenek alkalmazni és kezelni az érzékenységi címkéket, nem tudnak interaktív műveleteket végrehajtani a jelentésekben, és nem tudják kezelni az érzékenységi címkével ellátott műtermékeket.
Helyreállítási késleltetési probléma megoldása
A korábbi felhőkimaradásokhoz hasonlóan más gyártóknál, még azután is, hogy a Microsoft kijavította a problémákat, a felhasználóinak a normál állapotba való visszatéréshez szükséges helyreállítási erőfeszítések további időt vettek igénybe.
A technológiai óriáscég 14 óra 37 perckor vette tudomásul a kimaradást. Kelet-Csütörtök, és közzétette az X-nek, hogy „olyan lehetséges problémát vizsgál, amely több Microsoft 365-szolgáltatást is érint.” Az eladó 15 óra 17 perckor „azonosította az észak-amerikai szolgáltatási infrastruktúra egy részét, amely nem a várt módon dolgozza fel a forgalmat”.
A Microsoft az X-en 16:14-kor (ET) közzétett bejegyzésében megerősítette, hogy „az érintett infrastruktúrát (egészséges) állapotba állította vissza”, de „további terheléselosztásra van szükség a hatás minimalizálása érdekében”.
Délután 17:21-kor a Microsoft közölte, hogy „újra egyensúlyba hozza a forgalmat az összes érintett infrastruktúra között, hogy a környezet a lehető leggyorsabban visszatérjen a kiegyensúlyozott állapotba”. Ez a megközelítés lehetővé tette az eladó számára, hogy „azonosítsa a helyreállításhoz szükséges további lépéseket”.
A vállalat „a környezet egyensúlyhiányáról” számolt be 19:02-kor, „az érintett szolgáltatásokhoz való hozzáférés helyreállt”, és január 23-án 00:33-kor stabil levélforgalomról számolt be.
Akkoriban a Microsoft megjegyezte, hogy „maradt egy kis számú érintett szolgáltatás”, amely még mindig nem biztosított teljes szolgáltatási stabilitást. A társaság keleti 13 óra 29 perckor az incidens hatását „megoldottnak” nyilvánította. A Microsoft 8:20-kor újabb X-bejegyzést küldött ki, amelyben arra kérte a fennmaradó problémákat tapasztaló felhasználókat, hogy „töröljék a helyi DNS-gyorsítótárat vagy ideiglenesen csökkentsék a DNS TTL-értékeit a gyors hibaelhárítás érdekében”.
Januárban további kérdések következtek
A Microsoftnak nem ez volt az első kiesése 2026-ban: a gyártó szerdán kezelte a Teams, az Outlook és más M365-szolgáltatások hozzáférési problémáit, január 15-én egy Copilot-problémát, valamint a hónap elején egy Azure-kimaradást.
A Microsoft szerdán, 12 óra 11 perckor X-ről szóló bejegyzésében elismerte az M365 problémákat. Keleti. A társaság 13 óra 29 perckor „megoldottnak” nevezte a hozzáférési problémákat. és „harmadik fél hálózati hibájának” tulajdonította, megjegyezve, hogy „a Microsoft szolgáltatási környezet egészséges maradt”.
Január 15-én a gyártó problémákat tapasztalt a Microsoft Copilot mesterséges intelligencia alkalmazásával Észak-Amerikában. A Microsoft 19:42-kor a csendes-óceáni térségben elismerte a problémát, és 20:24-kor „megoldottnak” nevezte, a szállító pedig a szolgáltatás konfigurációjának megváltoztatását okolta a problémáért, és visszaállította a változtatást, hogy megoldja a hatást.
A január 10-én 17:50 UTC és január 11-én 1:23 UTC-ig tartó januári Azure-incidens esetében a West US 2 régió Washington állambeli felhasználói „szakaszos kapcsolódási problémákat, időtúllépéseket, megnövekedett hibaarányt vagy késéseket tapasztaltak az érintett erőforrásokon végzett műveletek során” a Microsoft első esemény utáni áttekintése (PIR) szerint.
A vállalat a fennakadást a Nyugat-USA 2 régión belüli Egységes Elérhetőségi Zóna (AZ01) infrastruktúráját érintő áramkimaradásnak tulajdonította, aminek következtében egyes infrastruktúrák átmenetileg nem elérhetők. A Microsoft január 10-én 19:51-kor (UTC) helyreállította a számítási és tárolási infrastruktúrát, de az újonnan létrehozott virtuális gépekre és virtuális gépekre gyakorolt maradék hatása az AZ-hatás időtartama alatt frissített január 11-én 1:23-ig tartott.
A leállás érintette az Azure Cache for Redis, Azure Cosmos DB, Azure Data Explorer, Azure Database for PostgreSQL, Azure Databricks, Azure Synapse Analytics, Azure Service Bus, Azure SQL Database, Azure Storage és más Azure-szolgáltatásokat.
Az incidens eredményeként a Microsoft közölte, hogy javítani fogja a riasztásokat az adatközpont-problémák által érintett konkrét rack-infrastruktúrák esetében, és javítani fogja a szabványos működési eljárásokat, hibaelhárítási útmutatókat és az eszkalációs munkafolyamatokat, hogy csökkentse a helyreállításhoz szükséges időt a fennmaradó hatások mérséklése érdekében.
A vállalat azt is ígérte, hogy javítja az érintett SLB infrastruktúra-szolgáltatások automatizált helyreállítását a helyi infrastruktúra fennakadásait követően.
A Microsoft azt is javasolja a felhasználóknak, hogy az AZ-kat használják fel a szolgáltatások fizikailag különálló helyeken történő futtatására az Azure-régión belül, hogy nagyobb ellenálló képességet kapjanak az adatközponti szintű hibákkal szemben, és fontolják meg az alkalmazások megbízhatóságának értékelését az Azure Well-Architected Framework és annak interaktív jól felépített áttekintése alapján.
„Kapacitáscsökkenés a karbantartás során” hibáztatták
A Microsoft az Admin Center frissítésében közölte, hogy a leállást „megnövekedett szolgáltatási terhelés okozta, amely az észak-amerikai infrastruktúra egy részében a karbantartás során lecsökkent kapacitás miatt következett be”.
Ezenkívül a Microsoft megjegyezte, hogy a „forgalom újraegyensúlyozására irányuló folyamatos erőfeszítések” során „célzott terheléselosztási konfigurációmódosítást vezetett be, amelynek célja a helyreállítási folyamat felgyorsítása, amely mellékesen további forgalmi egyensúlyhiányokat okozott az érintett infrastruktúra egy részének tartós hatásával.”
David Steiner, a US iTech munkatársa szerint úgy tűnik, hogy a Microsoft nem rendelkezik elegendő kapacitással a biztonsági mentési rendszerein, miközben karbantartást végzett fő rendszerein.
„Úgy tűnik, hogy a tartalék rendszer túlterhelt volt, és leállította a rendszert, miközben karbantartást végeztek a fő rendszeren” – mondta. „Ezért tartott olyan sok órába, mire újra üzembe helyezte. Ha az elsődleges rendszer karbantartás miatt leállt, és a tartalék rendszere kapacitásproblémák miatt meghibásodik, időbe telhet az elsődleges rendszer újraindítása és működése.”
a felhő még mindig király
Noha a felhőkimaradások gyakorisága arra késztethet egyes informatikai szakembereket, hogy fontolóra vegyék a munkaterhelések helyszínire való visszahelyezését, fontos emlékezni a felhőalapú alkalmazás folyamatos előnyeire, különösen mivel a felhő továbbra is az AI-termékek és -szolgáltatások népszerű módja.
Szintén az Uptime Institute májusi jelentésében, amely az AI infrastruktúrára gyakorolt hatásaira figyelmeztetett, a szervezet megjegyezte, hogy a kockázatkezelés és a megbízhatóság terén elért iparági fejlődés következtében a leállások egyre ritkábbak és kevésbé súlyosak a digitális infrastruktúra elmúlt néhány év során tapasztalt gyors növekedéséhez képest.
Az intézet megállapította, hogy az adatközpontok üzemeltetőinek 53 százaléka számolt be leállásokról az elmúlt három évben, ami jelentős visszaesés a 2022-es 60 százalékhoz, a 2021-es 69 százalékhoz és a 2020-as 78 százalékhoz képest. Ez az arány megközelítette a 2023-ban regisztrált 55 százalékot.
Ami a súlyosságot illeti, a 2024-ben jelentett incidensek 9 százalékát minősítették súlyosnak vagy kritikusnak, ami az Uptime által eddig feljegyzett legalacsonyabb szint.
A szervezet megjegyezte, hogy az AWS Outpost, az Azure Arc és más hibrid felhőplatformok, valamint a VMware Cloud Foundation és más felügyeleti keretrendszerek segíthetik a vállalatokat a felhőintegráció javításában a helyszíni infrastruktúrával.
Lydia Leong, a Gartner kiváló alelnöke és elemzője egy novemberi bejegyzésében azt mondta, hogy a felhőalapú munkaterhelések visszahelyezése a telephelyre vagy a hiperskálájú szolgáltatókról a kisebb szuverén felhőkre nem szünteti meg a kimaradás kockázatát.
A modern felhőalapú natív alkalmazásoknak például fel kell osztaniuk a munkaterhelést több rendelkezésre állási zóna között, és fel kell készülniük arra, hogy szükség esetén gyorsan átlépjenek egy másik zónába. Az egyedi felhők jobb üzemidőt és egyszerűbb műveleteket biztosítanak, mint több szolgáltató és különböző folyamatok kombinálása.
Azok a vállalkozások, amelyeknek bizonyos feladatokhoz nincs állásidő, érdemes megfontolni a kézi megkerülő megoldásokat, ha az elsődleges rendszer meghibásodik, ami kielégítheti a szabályozók igényeit, miközben alacsony IT-költségvetést biztosít. Leong is elutasította a multicloud használatát, hacsak a szabályozók nem követelik meg.
„A Gartner kutatása azt mutatja, hogy a többfelhős rugalmasság alkalmazása többe kerülhet, mint amennyit megtakarít, és technikai összetettséget eredményez anélkül, hogy ténylegesen kiküszöbölné a rendszerkockázatot” – mondta.
Megjelenési Dátum: 2026-01-23 19:35:00
Forráslink: www.crn.com
