Microsoft 365:n hakuhäiriö MO1456424: mitä tapahtui ja miten se korjattiin

Microsoftin mukaan tuore käyttöönotto aiheutti hakupyyntöjä käsittelevässä infrastruktuurissa ”resurssien käytön tehottomuuteen” liittyvän ongelman. Yksinkertaistettuna ohjelmistomuutos kuormitti kyseistä infrastruktuuria tehottomalla tavalla, minkä seurauksena osa hakukyselyistä ei käsiteltänyt normaalisti.

Julkisissa päivityksissä ei kerrota tarkemmin esimerkiksi käytetystä resurssityypistä, teknisestä koodipolusta, kuormitusrajoista tai siitä, mikä käyttöönoton yksityiskohta ongelman laukaisi. Saatavilla oleva näyttö tukee siis käyttöönottoon liittyvää resurssitehokkuusongelmaa, ei yhtä tiettyä teknisempää selitystä.

Millaisen korjauksen Microsoft otti käyttöön?

Microsoft kertoi kehittäneensä ja ottavansa käyttöön korjauksen, jonka tarkoitus oli vähentää resurssipainetta ja palauttaa hakutoiminto. Yhtiö seurasi samalla tilanteen etenemistä ja korjauksen leviämistä.

Koska häiriötiedotteessa ei ollut päättymisaikaa, toimitettu aineisto ei vahvista, milloin korjaus oli valmistunut kaikkien käyttäjien osalta. Microsoft ei myöskään kuvannut julkisesti palautusta aiempaan versioon, pysyvää arkkitehtuurimuutosta tai korjauksen tarkempaa teknistä toteutusta.

Miksi kyseessä oli incident, vaikka luokitus oli service degradation?

Microsoftin palveluterveystiedoissa MO1456424 merkittiin serviceDegradation-tapaukseksi. Luokitus tarkoittaa, ettei Microsoft 365 -kokonaisuus ollut kokonaan poissa käytöstä. Häiriö kirjattiin silti incidentiksi, koska asiakkaille näkyvä keskeinen toiminto — haku — oli osalla käyttäjistä häiriintynyt useissa tuotteissa samanaikaisesti.

Microsoft ei julkaissut erillistä perustelua luokitukselle. Siksi varovaisin tulkinta on myös selkein: kyseessä oli usean tuotteen hakutoiminnon heikkeneminen, ei kaikkien Microsoft 365 -palvelujen täydellinen käyttökatko.

Miten häiriö vertautuu muihin viimeaikaisiin katkoksiin?

Elokuun tapahtumien ajoitus voi helposti yhdistää eri häiriöt toisiinsa. Teknisten selvitysten perusteella niiden mekanismit olivat kuitenkin erilaiset.

GitHubin lähes kahdeksan tunnin häiriö oli erillinen tapaus

GitHub kärsi 17. elokuuta 2026 erillisestä häiriöstä, joka kesti kello 13.28:sta 21.15:een UTC eli 7 tuntia ja 47 minuuttia. Kohonneita virhemääriä ja viiveitä havaittiin muun muassa Issues- ja pull request -toiminnoissa, rajapinnoissa, Actions-palvelussa ja Copilotissa. Verkkosivuston ja API-rajapintojen virhemäärät nousivat pahimmillaan noin 20 prosenttiin, ja arkisto- sekä raakasisältölatauksissa noin 50 prosenttiin.

GitHubin raportoitu selitys liittyi kuormittuneisiin kuormantasaajiin, virheelliseen automaattisen skaalauksen käytäntöön ja Visual Studio Coden piilevään uudelleenyritysbugiin. Nämä ovat eri mekanismeja kuin MO1456424:n käyttöönottoon liittyvä hakuinfrastruktuurin resurssiongelma.

Microsoft 365:n hakuhäiriöitä on ollut aiemminkin

Microsoft 365:n hakutoiminnot ovat aiheuttaneet ongelmia myös aiemmin. Huhtikuussa 2025 Outlookin verkkoversion ja SharePoint Onlinen käyttäjät kohtasivat hakujen hitautta ja epäonnistumisia, jotka yhdistettiin hakupyyntöjä käsittelevien infrastruktuurikomponenttien riittämättömään suorituskykyyn.

OneDrivessa on puolestaan raportoitu tiedostohakuongelmia, joissa haku näytti tyhjää tai ei palauttanut tuloksia, vaikka käyttäjä tiesi tiedostojen olevan palvelussa. Saatavilla oleva aineisto ei osoita, että nämä aiemmat ongelmat olisivat johtuneet samasta juurisyystä kuin MO1456424.

Heinäkuun Azure-häiriö oli laajempi ja teknisesti erilainen

23. heinäkuuta 2026 tapahtunut häiriö vaikutti laajemmin Azureen ja Microsoft 365:een. Microsoftin Azure-historiassa vaikutusajaksi ilmoitetaan kello 14.44–19.41 UTC. Osa asiakkaista koki yhteyskatkoja, suurempaa viivettä tai vaikeuksia käyttää West US -alueella sijaitsevia Azure-palveluja. Häiriö koski alueelle saapuvaa tai sieltä lähtevää verkkoliikennettä, kun taas alueen sisällä pysyvä liikenne ei ollut vaikutuksen piirissä.

Microsoft yhdisti tapahtuman automaattisen verkkohuollon ongelmaan, joka poisti IP-reittejä suunniteltua useammilta laitteilta. Kyseessä oli verkon hallintatason automaatiovirhe — ei MO1456424:n kaltainen hakupalvelun heikkeneminen.

Mitä tapahtumien kokonaisuus kertoo?

Eri häiriöt osuivat eri teknisiin kerroksiin:

• MO1456424: tuore käyttöönotto johti hakua palvelevan infrastruktuurin tehottomaan resurssien käyttöön.
• GitHubin 17. elokuuta sattunut häiriö: kuormantasaajien ylikuormitus, automaattisen skaalauksen virhe ja uudelleenyrityksiin liittyvä ongelma.
• Heinäkuun Azure-tapaus: automaattinen huoltomenettely poisti liian monia IP-reittejä.

Tämä osoittaa pilvipalvelujen riskien kasaantuvan useille tasoille: ohjelmistojen käyttöönottoihin, kapasiteettiin ja automaattiseen skaalaukseen sekä verkkohallinnan automaatioon. Se ei kuitenkaan ole näyttöä yhdestä yhteisestä juurisyystä.

Aineisto ei myöskään osoita, että tekoälyyn liittyvä kysyntä olisi aiheuttanut MO1456424:n, GitHubin katkoksen tai heinäkuun Azure-häiriön. GitHub on kertonut siirtymisestä julkiseen pilveen ja monipilvistrategian rakentamisesta, mutta nämä strategiset suunnitelmat eivät yksin todista yhteyttä mihinkään tiettyyn häiriöön.

Varovaisempi johtopäätös on silti selvä: kun pilvipalveluista ja tekoälyyn liittyvistä työkuormista tulee yhä tärkeämpiä, käyttöönottojen suojaukset, kapasiteettisuunnittelu, uudelleenyritysmassojen rajoittaminen, vikasietoisuus ja verkk’automaation testaus korostuvat. Monipilvistrategia voi hajauttaa osan infrastruktuuririskistä, mutta se ei automaattisesti estä palvelun oman hallintatason sisäistä vikaa.