-
Prévoit de publier, le premier mercredi de chaque mois, un rapport de disponibilité récapitulant les incidents survenus, avec explications techniques et mesures correctives
-
L’objectif est de tout partager en toute transparence, non pas comme un simple rapport d’erreur, mais pour que chacun puisse tirer des enseignements de cette expérience
-
La réponse de GitHub face aux erreurs de site qui se multiplient récemment
-
5/5 (panne de 2 min 24 s)
Provoquée par le dépassement de la valeur maximale du type Integer par l’ID auto-incrémenté d’une table MySQL spécifique
Envoi d’une alerte lorsque la taille de la PK dépasse 70 %, et ajout d’un linter pour que le framework de test vérifie les types int/bigint
- 5/22 (panne de 5 min 09 s)
Pendant une maintenance planifiée, le nouveau serveur MySQL Primary lancé est tombé en panne. Le trafic a été redirigé en urgence vers le Primary d’origine, mais comme il avait reçu du trafic d’écriture pendant les 6 secondes où il était indisponible, il a fallu 4 heures pour restaurer depuis un réplica, puis 1 heure pour reconfigurer le cluster.
Des tests d’automatisation du failover sont en cours afin de minimiser le temps de reprise.
- 6/19 (panne de 51 min)
Incident causé par une modification introduite pour améliorer les tests A/B, qui a créé une dépendance à un fichier d’une autre application généré dynamiquement. Pendant le déploiement, la génération de ce fichier a échoué, entraînant l’activation d’une limitation de débit.
Modification pour que la configuration des tests A/B et multivariés soit mise en cache en interne
1 commentaires
Depuis le rachat par MS, il y avait des soupçons croissants sur une hausse notable des erreurs.
(Cela menait aussi à des remarques du genre : « Azure ne serait pas instable ? », donc ils ont peut-être été piqués au vif.)
En réponse, ils ont annoncé une mesure assez directe : publier en toute transparence un rapport de disponibilité.
Je pense que les entreprises coréennes devraient elles aussi s’inspirer de ce type de réaction.
C’est un peu un autre sujet, mais quand on compare les « rapports de transparence » des entreprises étrangères et de celles du pays, il existe une différence très importante, tant sur le plan qualitatif que quantitatif.
Rapport de transparence (Transparency Report) : partage de données montrant l’impact des politiques et des mesures des gouvernements et des entreprises sur la protection de la vie privée, la sécurité et l’utilisation des informations
Rapport de transparence de Google : https://transparencyreport.google.com/?hl=ko
Rapport de transparence de Facebook : https://transparency.facebook.com/
Rapport de transparence de Naver : https://privacy.naver.com/transparency/transparency_report_statistic/…
Rapport de transparence de Kakao : https://privacy.kakao.com/transparency/statistic
Il ne faut pas se contenter d’aligner des données ;
je pense qu’il faut aussi concevoir le rapport lui-même de manière à bien faire ressortir les convictions de l’entreprise.