Microsoft détaille l’incident du 3 décembre affectant le service Office 365

Le rapport

L’inconvénient majeur de l’informatique dématérialisée, c’est que l’utilisateur est souvent à la merci d’une panne, et qu’il n’y a pas toujours de plan B. L’avantage, c’est que les fournisseurs de service analysent avec rapidité les problèmes, et fournissent généralement une solution rapidement. Ou du moins dans des délais qui se compareront probablement favorablement avec un incident des systèmes d’information internes.

Microsoft a publié un Post Incident Review Report for Office 365, une analyse de l’incident du 3 décembre qui a affecté l’accès aux services Office 365.

Il est disponible pour les clients sur le portail Office 365, en affichant le détail des incidents du 3 décembre 2015, puis en téléchargeant le fichier PIR_IS34796.docx. Ce document analyse les incidents IS34783, IS34796, YA34779.

L’incident

L’incident a commencé le 3 décembre 2015 à 7 h 59 (heure de Paris) est s’est terminé à 12 h 15 : une durée importante à l’échelle du nuage.

Durant cette période, certains utilisateurs européens n’ont pu utiliser les services Office 365 comme SharePoint, PowerBI, Intune, Yammer, et surtout Exchange Online. D’après Microsoft, 1 % des requêtes Outlook et 35 % des requêtes Outlook On the Web en Europe ont alors été affectées.

Une erreur de configuration d’Azure Active Directory Service (AAD), le service d’annuaire de Microsoft, tout comme une mise à jour fautive de la version en utilisation, a occasionné un routage défectueux des requêtes, et une surcharge des requêtes d’authentification sur les serveurs accessibles.

La page d’information sur la santé des services Office 365, http://status.office.com/ a bien été mise à jour durant cette période, mais les Européens n’ont pas pu lire ces mises à jour. Microsoft avait anticipé l’indisponibilité de la page d’information en cas de panne, et prévu une copie supplémentaire sur une infrastructure séparée. Malheureusement, cette page était inatteignable en raison d’une configuration erronée sur le réseau de diffusion de contenu de Microsoft Azure.

Les résolutions

Pour limiter à l’avenir les risques que l’incident se reproduise, Microsoft a procédé à des changements. Des techniques d’injections de bogues ont été ajoutées pour améliorer les procédures de tests. Des mécanismes supplémentaires de plans de secours ont été rajoutés, afin d’utiliser une version antérieure du service d’authentification au cas où la version la plus récente pose problème. Des mécanismes supplémentaires de détection et de reprise de surcharge ont été implémentés. Enfin, les extrémités des différents services sont mieux isolées les unes des autres afin de limiter l’enchaînement des pannes.

Nous tirons quatre conclusions de ce rapport :

  • Une erreur humaine (configuration erronée) est à la source de l’incident ;
  • Si l’incident a affecté Office 365, ce ne sont pas les services Office 365 eux-mêmes qui sont en cause, mais Azure Active Directory ;
  • On est étonné d’entendre parler de surcharge de la part d’un fournisseur de services dans le nuage, dans la mesure où l’élasticité est une caractéristique fondamentale de ce dernier. Les serveurs AAD ne sont-ils pas configurés en mise à l’échelle automatique ?
  • Si la durée de l’incident est notable, la disponibilité d’Office sur les quatre dernières années reste supérieure à 99,9 %.