Hi ha qui fa des de dilluns que no pot cercar a Microsoft 365. Per al SLA, això no és una caiguda

Des de dilluns 17 d'agost hi ha gent que escriu una paraula a la caixa de cerca de l'Outlook, del SharePoint Online o del OneDrive i no li surt res. L'avís és al centre de missatges de Microsoft 365 amb l'identificador MO1456424, i l'últim comunicat que hem pogut llegir fixava la revisió següent per avui divendres a les 04:00 UTC. Mentrestant, aquell fitxer es continua obrint si saps on és i aquell correu es continua enviant i rebent. I aquí hi ha el detall que ens interessa: sota les definicions de caiguda que fa servir el mateix contracte de Microsoft, això no ha passat.

Què diu el comunicat, paraula per paraula

El títol de l'avís és tan literal que gairebé no cal traduir-lo: «Some users may be unable to search for content in SharePoint Online, OneDrive, Outlook on the web, or Outlook desktop». L'abast està acotat amb cura: «Impact is specific to some users served through the affected infrastructure who are attempting to search for content in SharePoint Online, OneDrive, Outlook on the web, or Outlook desktop». Llegeix-ho a poc a poc, perquè importa per al que ve després: això no els passa a tots els inquilins i depèn de quin tros d'infraestructura de Microsoft té la teva bústia.

La causa que dona Microsoft cap en una línia: «A recent deployment introduced a resource utilization inefficiency issue, leading to impact». Un desplegament propi que va deixar els sistemes d'indexació i recuperació de contingut menjant més recursos del compte. Ni atac ni tercer ni res a pedaçar al teu costat, i cal reconèixer a Microsoft que ho diu així, sense disfressar-ho d'«activitat inusual». És la mena d'avaria que al teu propi centre de dades hauries resolt revertint el canvi en vint minuts, i que aquí s'arregla quan li toca al teu clúster a la cua del desplegament de la solució. El que ve ara no va de l'avís, que està ben escrit. Va del que passa amb ell després.

Llegir, escriure, enviar, rebre: cercar no és a la llista

El SLA de serveis en línia de Microsoft no promet «que el servei funcioni». Promet un percentatge mensual de temps d'activitat, i per calcular-lo defineix, servei per servei, què compta com a Downtime. Val la pena llegir els tres que surten a l'avís, en l'edició del 10 d'agost del 2026 del document consolidat. SharePoint Online: «Any period of time when users are unable to read or write any portion of a SharePoint Online site collection for which they have appropriate permissions». Exchange Online: «Any period of time when users are unable to send or receive email with Outlook Web Access». OneDrive per a l'empresa: «Any period of time when users are unable to view or edit files stored on their OneDrive for Business».

Llegir, escriure, enviar, rebre, veure, editar. Ara posa-hi MO1456424 al costat. Els usuaris afectats poden llegir els seus documents i escriure-hi, envien correu i els arriba el correu, veuen els seus fitxers de OneDrive i els editen. L'única cosa que no poden fer és trobar, i aquest verb no apareix a cap de les tres definicions. La nostra lectura: cinc dies de cercador inútil sumen zero minuts de caiguda. El comptador de disponibilitat d'agost es queda exactament on era.

I no és un parany de Microsoft, que és el punt que sol molestar. Qualsevol SLA operable necessita una definició binària de caiguda, perquè s'ha de mesurar amb un rellotge i multiplicar-la per usuaris afectats —el mateix document compta el Downtime en user-minutes—. Tan bon punt hi admets «el servei va lent» o «el servei va, però malament», el contracte deixa de poder calcular-se i comença a discutir-se, i un contracte que es discuteix no serveix de res. El preu d'aquesta claredat és que el que es compta i el que fa mal acaben sent dues coses diferents.

I encara que comptés, el crèdit s'ha de demanar

Suposem per un moment que sí que comptés. La compensació del SLA arriba en forma de crèdit sobre la quota del servei afectat, i va per trams. Per sota del 99,9 % i fins al 99 %, un 25 %. Per sota del 99 % i fins al 95 %, un 50 %. Per sota del 95 %, el 100 %. Convé fer el càlcul un cop per no tornar-lo a fer mai: un mes de 31 dies té 44.640 minuts, així que baixar del 99,9 % demana 44 minuts i mig de caiguda mesurada, i baixar del 99 %, 446 minuts, set hores i quart llargues.

I el crèdit no cau tot sol. S'ha de reclamar amb la informació de l'incident, i hi ha termini: el mateix SLA posa com a data límit el final del mes natural següent a aquell en què va passar l'incident, i ho il·lustra amb un exemple que no deixa lloc a dubtes —«if the Incident occurred on February 15th, we must receive the claim and all required information by March 31st»—. Algú de casa teva ha de reunir les proves i obrir el cas per recuperar un percentatge de la quota d'un servei. Gairebé ningú no ho fa, i no és deixadesa: és que l'hora que costa val més que el que recuperes.

Vam escriure fa unes setmanes que un RTO no es decideix, es mesura, i que no s'hauria de signar cap número que no s'hagi cronometrat abans en un assaig. Aquí el problema és anterior: el número del contracte ni tan sols mesura la capacitat que ha caigut. Quant de temps pot estar la teva empresa sense poder cercar, i què fa durant aquest temps, és una pregunta que el crèdit de servei no respon.

La teva monitorització mesura el mateix que el SLA

Aquí és on l'assumpte deixa de ser una queixa sobre Microsoft i passa a ser un problema de casa. Gairebé totes les comprovacions sintètiques que es munten contra un SaaS pregunten el mateix que pregunta el SLA: respon? Un inici de sessió, un HTTP 200, un correu de prova que va i torna. Totes aquestes comprovacions han estat en verd tota la setmana, perquè totes aquestes coses funcionaven.

La comprovació que sí que ho hauria caçat és avorrida de muntar i per això gairebé mai no hi és: una cerca coneguda contra un contingut fix, que retorna un nombre de resultats que tu controles. Un document testimoni en un lloc de SharePoint amb una paraula rara que no apareix enlloc més, i una consulta programada que diu «això ha de retornar exactament 1». Tècnicament no té misteri, tot i que tampoc no és de franc: cal registrar una aplicació a l'Entra, donar-li permisos sobre l'API de cerca del Graph i deixar una tasca programada executant-se. El que canvia és la pregunta que li fas al sistema, que passa de «estàs viu?» a «continues sabent el que sabies ahir?».

Siguem honestos amb l'abast de tot això: assabentar-te'n abans no arregla la cerca, i una còpia de seguretat tampoc. Ningú del departament legal no es posarà a remenar un contracte a la consola d'un backup perquè el cercador vagi fluix tres dies. On la segona via sí que decideix alguna cosa és un esglaó més amunt, el dia que el problema no és l'índex sinó l'accés a l'inquilí sencer, i d'això ja en vam escriure: la còpia que Microsoft guarda de les teves dades no surt mai de Microsoft. Són dos riscos diferents i convé no barrejar-los per vendre el segon amb l'ensurt del primer.

Quan això no és el teu problema

Toca la part que no ven: per a molta gent això és una molèstia i res més. Si el teu equip treballa amb carpetes ordenades, rutes conegudes i correu dels últims trenta dies, un cercador fluix durant uns dies és incòmode i ja passarà. Muntar una plataforma de cerca alternativa per un incident de cinc dies seria llençar diners, i no ho recomanarem.

La pregunta que sí que canvia les coses és més concreta: hi ha algun procés vostre que s'aturi si ningú no pot cercar? Un departament legal que localitza contractes per client. Un servei d'atenció que busca el fil de correu de l'última comanda. Una resposta a un requeriment amb termini, on cal localitzar tot el relacionat amb una persona o un assumpte. Si la resposta és «cap», enhorabona i tanca aquesta pestanya. Si la resposta és «aquell», ja saps quin és el teu procés fràgil, i ho has esbrinat de franc mirant l'avaria d'un altre.

És la mateixa idea que vam defensar parlant d'una altra cosa completament diferent: l'alta disponibilitat no evita la caiguda, l'escurça. Cap arquitectura et promet que no passi res. El que es decideix per endavant és quant dura i què fas mentre dura.

La pregunta que no es fa a la renovació

A les taules de renovació es pregunta sempre «quin SLA teniu?», i sempre es contesta un número amb tres nous que no diu res per si sol. La pregunta útil és incòmoda justament per això: què defineix exactament el teu proveïdor com a caiguda, i quines degradacions queden fora d'aquesta definició? Val per a Microsoft i val per a qualsevol que et vengui un servei gestionat, nosaltres inclosos. Ningú no reescriurà un SLA per tu; el que sí que pots fer és saber on és el forat abans de necessitar-lo, i decidir amb el cap fred si el cobreixes o l'assumeixes.

Què faríem aquesta setmana

• Mirar el centre de missatges, no la premsa. Si algú de casa es queixa que «l'Outlook no cerca», el lloc on confirmar si t'ha tocat és l'estat del servei del teu propi inquilí. MO1456424 no afecta tots els inquilins, i saber si hi ets dins o fora canvia la resposta que dones als teus usuaris.
• Escriure la resposta abans de la propera vegada. Dues línies per al servei d'assistència: què està passant, què es pot fer mentrestant (filtres de carpeta, ordenar per data, la ruta directa al lloc de SharePoint) i què no cal que provin. Estalvia la meitat dels tiquets.
• Afegir una comprovació de resultat, no de resposta. Un document testimoni amb una paraula única, una consulta programada contra l'API de cerca i una alerta si el nombre de resultats deixa de ser l'esperat. És una tarda de feina comptant el registre de l'aplicació i els permisos, i és l'única manera d'assabentar-te'n abans que la persona que obre el tiquet.
• Llistar els processos que depenen de cercar. No els sistemes: els processos. Mitja hora amb les persones que els executen i sabràs si això era una molèstia o un risc. A la majoria de llocs el resultat és tranquil·litzador; als que no, ja saps per on continuar.
• Desar l'avís. Si algun procés amb termini s'ha vist afectat, el comunicat de Microsoft amb el seu identificador i les seves dates és la prova que la causa va ser del proveïdor. Costa zero desar-lo avui i no es pot reconstruir al novembre.

Amb sort, quan llegeixis això el cercador ja torna a trobar coses i MO1456424 està tancat. El forat entre el que promet el contracte i el que necessita la teva gent continua exactament on era.

Fonts (verificades el 21 d'agost del 2026): l'identificador MO1456424, el títol de l'avís, la frase sobre l'abast i la causa «A recent deployment introduced a resource utilization inefficiency issue, leading to impact», de l'avís de degradació de servei republicat pel suport de NHSmail i de la cobertura de BleepingComputer del 18 d'agost. L'inici dels avisos el dilluns 17 d'agost, la confirmació que no es tracta d'un ciberatac i l'hora del següent comunicat (divendres 21 d'agost, 04:00 UTC), de Cyber Security News. Les tres definicions de Downtime (SharePoint Online, Exchange Online i OneDrive per a l'Empresa), el mesurament en user-minutes, els trams de crèdit de servei, el termini de reclamació i el seu exemple del 15 de febrer, del SLA consolidat de serveis en línia de Microsoft, edició del 10 d'agost del 2026 (enllaç directe al document; l'índex de descàrregues llista també la resta d'idiomes). La lectura que una cerca trencada no encaixa en cap d'aquestes definicions és nostra i es declara com a tal al text; l'aritmètica dels 44 minuts i mig i els 446 minuts surt d'aplicar els percentatges als 44.640 minuts d'un mes de 31 dies. Les citacions es deixen en anglès, el seu idioma original, perquè es puguin verificar paraula per paraula.