Konfigurációs hiba miatt állt az Office 365
Az autentikációs kérések egy része az Azure Active Directory tesztkörnyezetébe futott be. A hiba egyéb problémát is felszínre hozott, javítását a Microsoft decemberre ígérte.
Közel két hete, december 3-án reggel 9 órától Európa-szerte többórás üzemzavar nehezítette meg az Office 365-előfizetők életét és munkavégzését. A műszaki hiba leginkább az Outlook Web Appon (OWA) keresztül levelező felhasználókat sújtotta, de az Office 365 portfólió számos másik eleme (például Azure Management Portal, Dynamics CRM, Stream Analytics, Remote App, Visual Studio Team Services, SQL Database) is érintett volt.
A Microsoft akkor meglehetősen szűkmarkúan bánt az információval, amire rátett egy lapáttal, hogy a pont az ilyen üzemzavarok idejére tervezett Service Health Dashboard (SHD) és az Emergency Broadcast System (EBS) szolgáltatások is elestek. A megoldásra és információra vadászó üzemeltetők közül a Twitteren és a Redditen sokan az Azure Active Directoryra (AAD) gyanakodtak a hiba forrásaként, és mint kiderült, igazuk volt. Az eset nem először mutatta meg, hogy a Microsoft felhős szolgáltatáscsomagjának legkritikusabb pontja az AAD, melyre a Microsoftnak az eddigieknél is jobban oda kell figyelnie.
Ünnepi mix a bértranszparenciától a kódoló vezetőkig Négy IT karrierrel kapcsolatos, érdekes témát csomagoltunk a karácsonyfa alá.
A cég által kiadott utólagos jelentés (PIR IS34783) szerint (nem részletezett) konfigurációs hiba történt, melynek következtében az autentikációs kérések egy része a preprodukciós, azaz fejlesztői- és tesztkörnyezetnek szánt AAD-be futott be. Az persze nem teljesítette a kéréseket, továbbá a front-end szerverek is egyre nagyobb hátralékot halmoztak fel, ami végül túlterhelte a rendelkezésre álló erőforrásokat - a két probléma így egymás negatív hatását erősítette.
A helyzet érdekessége, hogy látszólag failover sem történt (legalábbis eredményes nem), manuális rendkívüli beavatkozásra volt szükség, amit a Microsoft mérnökei három óra elteltével, röviddel dél előtt tettek meg. A korábbi konfiguráció visszaállítása megoldotta a problémát, a helyzet nagyjából délután negyed kettőre normalizálódott.
Azon felül, hogy az Office 365 lelkének számító AAD egy konfigurációs frissítés miatt sikeres failover nélkül elhasalhat, a tájékoztató rendszer újbóli leszereplése szintén csökkentheti a Microsoft felhős szolgáltatásaiba vetett bizalmat. Tavaly több nagy üzemzavar is volt a cég felhőjében, és bár az üzleti SLA-kban vállalt legalább 99,9 százalékos rendelkezésre állási mutató így is bőven megvolt, az Exchange Online meghibásodásakor az SHD a mostanihoz hasonlóan azt mutatta, hogy az Office 365 háza táján minden rendben.
A sors fintora, hogy a másodlagos figyelmeztetési vonalnak tervezett EBS sem tudta teljesíteni a feladatát, mert hiába működik az SHD-tól függetlenül, tartalomszolgáltatási hiba miatt az európai ügyfelek ezt sem tudták elérni. Üzemeltetői és rendszerintegrátori visszajelzések szerint ráadásul (valószínűleg a bejelentési roham miatt) a hibajegyeket is nagyon nehézkesen lehetett beküldeni a Microsoftnak, az információs támogatás tehát kívülről nézve szinte minden fronton megbukott.
Forrás: CloudSquare
A Microsoft a jövőben további "ellenőrzőpontokat" fog bevezetni a hibás frissítések elkerülésére, valamint az SHD és EBS működését is javítani tervezi - bár az SHD másfél éve elvileg már átesett egy ilyen kezelésen.
Kis leállás is nagy port kavar
Az ügy újfent rávilágított arra, hogy a nagy felhős szolgáltatók hiába tudják teljesíteni a szerződésekben vállalt magas rendelkezésre állási mutatókat, egy esetleges komolyabb hiba órákra cégek ezreinek és felhasználók millióinak nehezítheti meg a munkát. Ezért bár az ilyen rendszerek megbízhatósága összességében általában jóval az egyedileg üzemeltetett szerverek és szolgáltatások felett van, a nagy kitettség miatt egy-egy üzemzavar hatása is ennek megfelelő méretű.