post mortems
1.0.0
Allegro. Le site de commerce électronique a baissé après une pic de circulation soudaine causé par une campagne de marketing. La panne a été causée par une erreur de configuration dans la gestion des ressources de cluster qui a empêché davantage d'instances de service de démarrer, même si des ressources matérielles étaient disponibles.
Cloudflare. Une mauvaise configuration (règle du routeur) a provoqué le plantage de tous leurs routeurs de bord, éliminant tout CloudFlare.
Cloudflare. Lors d'une maintenance de son réseau d'épine dorsale privé, un ingénieur a fait une faute de frappe dans la configuration du réseau de données de Datacenter d'Atlanta, provoquant tout le trafic provenant d'Amérique et d'Europe qui coule vers ce seul centre de données, l'écrasant.
Cloudflare. Une commande incorrecte des préfixes annoncés par BGP désactivés a provoqué un dysfonctionnement sur 19 centres de données.
Cloudflare. Une modification de notre système de cache à plusieurs niveaux a provoqué l'échec de certaines demandes pour les utilisateurs avec le code d'état 530. L'impact a duré près de six heures au total. Nous estimons qu'environ 5% de toutes les demandes ont échoué au pic. En raison de la complexité de notre système et d'un angle mort dans nos tests, nous n'avons pas repéré cela lorsque le changement a été libéré dans notre environnement de test.
Cloudflare. Plusieurs services CloudFlare sont devenus indisponibles pendant 121 minutes le 24 janvier 2023 en raison d'une erreur de libération du code qui gère les jetons de service. L'incident a dégradé un large éventail de produits CloudFlare, y compris des aspects de notre plateforme de travailleurs, de notre solution Zero Trust et des fonctions de plan de contrôle dans notre réseau de livraison de contenu (CDN).
Cloudflare. Le 4 octobre 2023, CloudFlare a connu des problèmes de résolution DNS à partir de 07h00 UTC et se terminant à 11h00 UTC. Certains utilisateurs de 1.1.1.1 ou de produits comme Warp, Zero Trust ou des résolveurs DNS tiers qui utilisent 1.1.1.1 peuvent avoir reçu des réponses DNS Servfail aux requêtes valides. Nous sommes vraiment désolés pour cette panne. Cette panne était une erreur logicielle interne et non le résultat d'une attaque. Dans ce blog, nous allons parler de l'échec, pourquoi cela s'est produit et de ce que nous faisons pour nous assurer que cela ne se reproduit plus.
Datadog. Une mauvaise configuration de découverte de service dans l'un des clients a fait baisser la découverte de service à l'échelle mondiale lorsqu'un client dépendant a baissé.
ENOM. Le 15 janvier 2022, à 9 h 00 HE, l'équipe d'ingénierie de TucoCows a commencé les travaux de maintenance prévus pour migrer la plate-forme ENOM vers une nouvelle infrastructure cloud. En raison de la complexité de la couverte, l'équipe a rencontré de nombreux problèmes entraînant des retards continus. La fenêtre de maintenance a été prolongée plusieurs fois pour résoudre les problèmes liés à la réplication des données, au routage du réseau et aux problèmes de résolution DNS impactant l'accessibilité du site Web et la livraison des e-mails.
Etsy. L'envoi de trafic de multidiffusion sans configurer correctement les commutateurs a provoqué une panne mondiale ETSY.
Facebook. Les modifications de configuration aux routeurs de la colonne vertébrale de Facebook ont provoqué une panne mondiale de toutes les propriétés Facebook et des outils internes.
Facebook. Une mauvaise configuration a abattu Facebook et Instagram.
Firefox. Le 13 janvier 2022, un chemin de code spécifique dans la pile réseau de Firefox a déclenché un problème dans l'implémentation du protocole HTTP / 3. Cela a bloqué la communication réseau et a rendu Firefox qui ne répond pas, incapable de charger le contenu Web pendant près de deux heures.
GOCARDSUSS. Une mauvaise configuration combinée avec un ensemble de défaillances rares a conduit à une panne d'un cluster de base de données, en prenant l'API et le tableau de bord hors ligne.
[Google] (https://cloud.google.com/blog/products/infrastructure/details-of-google-cloud-gcve-incident). L'approvisionnement initial de GCVE a été effectué avec une option héritée, ce qui a conduit à un contrat à «durée déterminée» avec la suppression automatique à la fin de cette période.
Google. Une mauvaise configuration (AutoGenerated) a supprimé tous les blocs IP de moteur Google Compute à partir des annonces BGP.
Google. Une mauvaise configuration (autoogénérée) a éliminé la plupart des services Google.
Google. Une mauvaise configuration a provoqué l'échec d'un service de quota, ce qui a provoqué l'échec des services (y compris Gmail).
Google. / a été enregistré dans la liste noire de l'URL, provoquant un avertissement de chaque URL.
Google. Un bug dans le déploiement de configuration à un équilibreur de charge entraîne une augmentation des taux d'erreur pendant 22 minutes.
Google. Un changement de configuration destiné à répondre à une augmentation de la demande de stockage de métadonnées, qui a surchargé une partie du système de recherche BLOB, ce qui a provoqué une défaillance en cascade avec un impact sur le service visible par l'utilisateur sur Gmail, Google Photos, Google Drive et d'autres services GCP dépendant du stockage Blob.
Google. Deux erreurs de configuration, ainsi qu'un bogue logiciel, ont provoqué une défaillance massive du réseau cloud Google sur la côte est des États-Unis.
Google. Le service d'équilibrage de la charge frontale de Google a connu des échecs expérimentés entraînant un impact sur plusieurs services de cloud Google en aval en Europe. D'après l'analyse préliminaire, la cause profonde du problème a été causée par une nouvelle fonctionnalité d'infrastructure déclenchant un problème latent dans le code d'équilibrage de charge de réseau interne.
Google. Google Cloud Networking Problèmes expérimentés avec Google Cloud Load Balancing (GCLB) Service entraînant un impact sur plusieurs services Google Cloud en aval. Les clients touchés ont observé des erreurs Google 404 sur leurs sites Web. D'après l'analyse préliminaire, la cause profonde du problème était un bogue latent dans un service de configuration de réseau qui a été déclenché pendant le fonctionnement du système de routine.
Google. Google Cloud Networking a connu une capacité réduite à un trafic prioritaire plus faible tel que les opérations par lots, en streaming et en transfert de 19h30 américain / Pacifique le jeudi 14 juillet 2022 à 15h02 US / Pacific le vendredi 15 juillet 2022. Le trafic de haute priorité des utilisateurs n'a pas été affecté. Cette perturbation de service résulte d'un problème rencontré lors d'une combinaison de travaux de réparation et d'un déploiement de mise à niveau du logiciel de réseau de routine. En raison de la nature des capacités de perturbation et de résilience des produits Google Cloud, les régions touchées et les fenêtres à impact individuel variaient considérablement.
Heroku. Un changement de configuration à distance automatisé ne se propageait pas complètement. Web Dynos n'a pas pu être démarré.
Heroku. Un processus de déploiement incorrect a provoqué l'utilisation de nouvelles variables de configuration lorsque le code les exigeait.
KeepTheScore. Les ingénieurs ont supprimé la base de données de production par accident. La base de données est une base de données gérée de DigitalOcean avec des sauvegardes une fois par jour. 30 minutes après la catastrophe, il est revenu en ligne, mais 7 heures de données sur le tableau de bord ont disparu pour toujours.
Microsoft. Une mauvaise configuration a abattu Azure Storage.
NPM. Le changement de configuration rapide a provoqué un problème de routage backend. Pour être exact, le problème est que nous définissons le req.backend dans une fonction VCL_FETCH, puis appelions Restart pour reconstituer les règles. Cependant, l'appel Restart réinitialisera le req.backend au premier soutien de la liste, qui dans ce cas se trouvait être Manta, plutôt que les serveurs CouchDB équilibrés de charge.
Owasa. La mauvaise poussée d'un bouton entraîne une fermeture d'une usine de traitement de l'eau en raison de niveaux trop élevés de fluor.
Pagerduty. Le 15 décembre 2021 à 00:17 UTC, nous avons déployé un changement de configuration DNS dans l'infrastructure de PagerDuty qui a eu un impact sur notre cluster d'orchestration de conteneurs. Le changement contenait un défaut, que nous n'avons pas détecté dans nos environnements de test, ce qui a immédiatement fait que tous les services exécutés dans le cluster d'orchestration de conteneur ne sont pas en mesure de résoudre le DNS.
Razorpay. Une défaillance du matériel RDS a mis en évidence une configuration MySQL incorrecte qui a entraîné une perte de données majeure dans un système financier.
Rust-Lang. Mercredi, 2023-01-25 à 09:15 UTC, nous avons déployé des modifications apportées à l'infrastructure de production pour Crates.io. Pendant le déploiement, le dossier DNS pour static.crates.io n'a pas réussi à se résoudre pendant environ 10 à 15 minutes. Cela était dû au fait que les certificats et les enregistrements DNS ont été recréés pendant les temps d'arrêt.
Rust-Lang. Le 2023-07-20 entre 12h17 et 12h30 UTC Tous les téléchargements Crate à partir de Crates.io ont été cassés en raison d'un déploiement qui contenait un bug dans la génération d'URL de téléchargement. Pendant ce temps, nous avons eu en moyenne 4,71 000 demandes par seconde à Crates.io, ce qui a entraîné des demandes d'échec d'environ 3,7 millions, y compris les tentatives de réessayer de la cargaison.
Stack Overflow. Une mauvaise configuration de pare-feu a bloqué StacKexchange / StackOverflow.
Sentinelle. Les mauvais paramètres Amazon S3 sur les sauvegardes entraînent une fuite de données.
Travisci. Un problème de configuration (rotation de mot de passe incomplète) a conduit à des machines virtuelles "qui fuisent", conduisant à des temps de file d'attente élevés.
Travisci. Un problème de configuration (le travail automatisé de nettoyage de l'image VM en moteur de calcul basé sur l'âge automatisé) a provoqué la suppression des images VM de base stables.
Travisci. Une modification de configuration a fait que les builds commencent à échouer. Rollback manuel s'est cassé.
Travisci. Les tests de la variable accidentelle ont fait des tests de données de production tronquées.
Tui. Avant le vol incident, le système de réservation à partir duquel la feuille de charge a été produite avait été améliorée. Une faute du système a fait compter les passagers féminins avec le titre «Miss» comme des enfants. Le système les a alloués au poids standard d'un enfant de 35 kg par opposition au poids standard féminin correct de 69 kg. Par conséquent, avec 38 femmes vérifiées de manière incorrecte et mal identifiée en tant qu'enfants, la masse de décollage G-TAWG de la feuille de charge était de 1 244 kg sous la masse réelle de l'avion.
TURSO. Les identificateurs de sauvegarde DB mal configurés ont conduit à des fuites de données pour les clients de niveau gratuit, et le correctif ultérieur a entraîné une éventuelle perte de données.
Soupape. Bien qu'il n'y ait pas de post-mortem officiel, il ressemble à la connexion d'une mauvaise configuration BGP coupée au niveau 3, Telia et Abovenet / Zayo, qui a abouti à une panne de vapeur mondiale.
Amazone. Un événement inconnu a fait échouer un transformateur. L'un des PLC qui vérifie que la puissance du générateur est en phase a échoué pour une raison inconnue, ce qui a empêché un ensemble de générateurs de sauvegarde de se mettre en ligne. Cela a affecté EC2, EBS et RDS dans l'UE West.
Amazone. Le mauvais temps a provoqué des échecs de puissance dans les États-Unis Aws East. Un seul générateur de sauvegarde n'a pas réussi à fournir une alimentation stable lorsque l'alimentation est passée à la sauvegarde et que le générateur a été chargé. Ceci en dépit d'avoir réussi un test de charge deux mois plus tôt et de passer des tests hebdomadaires de puissance.
Amazone. À 22h25, le PDT le 4 juin, la perte de puissance dans une installation AWS Sydney résultant de temps graves dans cette zone entraîne une perturbation d'un nombre important de cas dans une zone de disponibilité. En raison de la signature de la perte de puissance, les disjoncteurs d'isolement de puissance ne se sont pas engagés, ce qui a entraîné des réserves d'énergie de sauvegarde s'écoulant dans le réseau électrique dégradé.
Arpanet. Un dysfonctionnement des données de routage corrompues IMP (Processeur de messages d'interface), des sommes de contrôle recalculées logicielles propagant les mauvaises données avec de bonnes sommes de contrôle, des numéros de séquence incorrects ont provoqué des tampons à remplir, des tampons complets ont provoqué une perte de paquets et de nœuds Keepalive du réseau. À partir de 1980.
Cloudflare. Une mauvaise conduite de commutation partielle a provoqué une défaillance byzantine en cascade qui a eu un impact sur la disponibilité de l'API et du tableau de bord pendant six heures et 33 minutes.
Cloudflare. Panne de puissance du centre de données flexétude. Ce message décrit les événements qui ont causé cet incident.
FirstEnergy / General Electric. FirstEnergy a connu une défaillance locale lorsque certaines lignes de transmission ont atteint le feuillage non raccordé. Le processus normal consiste à faire disparaître une alarme, ce qui fait que les opérateurs humains redistaient l'énergie. Mais le système GE qui surveillait cela avait un bogue qui a empêché l'alarme de se déclencher, ce qui a finalement provoqué une défaillance en cascade qui a finalement affecté 55 millions de personnes.
Github. Le 28 janvier 2016, Github a connu une perturbation du pouvoir de leur principal centre de données.
Google. Des coups de foudre successifs sur leur centre de données européen (Europe-West1-B) ont provoqué une perte d'énergie à Google Compute Systèmes de stockage du moteur dans cette région. Des erreurs d'E / S ont été observées sur un sous-ensemble de disques persistants standard (DHDD) et une perte de données permanente a été observée sur une petite fraction de celles-ci.
Google. Le mardi 19 juillet 2022 à 06h33 US / Pacific, une défaillance simultanée de multiples systèmes de refroidissement redondants dans l'un des centres de données qui héberge la zone Europe-West2-A a eu un impact sur plusieurs services de Google Cloud. Cela a abouti à certains clients de l'indisponibilité des services pour les produits touchés.
Pythonanywhere. Une panne de volume de stockage sur l'un des serveurs de stockage a provoqué un certain nombre de pannes, en commençant par le site Pythonanywhere et également avec les programmes de nos utilisateurs (y compris les sites Web) qui dépendaient de ce volume, puis se propageant plus tard à d'autres sites hébergés.
Soleil. Le soleil n'a pas inclus ECC dans quelques générations de pièces de serveur. Cela a entraîné la corruption et le crash des données. Après le MO typique de Sun, ils ont fait des clients qui ont signalé un signe de bogue un NDA avant d'expliquer le problème.
Jeux CCP. Une faute de frappe et un conflit de noms ont fait supprimer parfois le fichier boot.ini sur l'installation d'une extension pour Eve en ligne - avec conséquences.
Github. Une partition de réseau de 43 secondes pendant la maintenance a provoqué un basculement MySQL Master, mais le nouveau maître n'avait pas plusieurs secondes d'écritures qui lui sont proportées en raison de la latence croisée. Plus de 24 heures de restauration pour maintenir l'intégrité des données.
GOCARDSUSS. Toutes les requêtes sur une table postgreSQL critique ont été bloquées par la combinaison d'une migration de base de données extrêmement rapide et d'une requête de lecture de longue durée, provoquant 15 secondes de temps d'arrêt.
Google. De nombreux changements à un équilibreur de charge rarement modifié ont été appliqués par un chemin de code très lent. Cela a gelé tous les modifications publiques pendant environ 2 heures.
Google. Une défaillance d'un composant sur un chemin de fibre de l'un des campus de la passerelle américaine centrale dans la squelette de production de Google a entraîné une diminution de la bande passante du réseau disponible entre la passerelle et les emplacements de bord multiples, provoquant une perte de paquets tandis que le squelette déplacée automatiquement le trafic sur les chemins restants.
Knight Capital. Une combinaison de versions déployées en conflit et de réutilisation d'un bit précédemment utilisé a entraîné une perte de 460 millions de dollars. Voir aussi un article plus long.
Référentiel de code webkit. Le référentiel WebKit, un référentiel de subversion configuré pour utiliser la déduplication, est devenu indisponible après que deux fichiers avec le même hachage SHA-1 ont été vérifiés comme données de test, avec l'intention d'implémenter un contrôle de sécurité pour les collisions. Les deux fichiers avaient des sommes MD5 différentes et donc un paiement échouerait à une vérification de cohérence. Pour le contexte, la première collision publique de hachage SHA-1 avait été annoncée très récemment, avec un exemple de deux fichiers en collision.
Azuré. Des certificats valables pendant un an ont été créés. Au lieu d'utiliser une bibliothèque appropriée, quelqu'un a écrit du code calculé un an pour être la date actuelle plus un an. Le 29 février 2012, cela a abouti à la création de certificats avec une date d'expiration du 29 février 2013, qui a été rejetée en raison de la date non valide. Cela a provoqué une panne mondiale Azure qui a duré la majeure partie d'une journée.
Cloudflare. Le flux de temps en arrière du suivi du 27e saut deuxième le 2016-12-31T23: 59: 60Z a provoqué la sélection pondérée du Round-Robin de DNS Resolvers (RRDNS) pour paniquer et échouer sur certaines recherches CNAME. GO'S time.Now() était incorrectement supposé être monotone; Cela a injecté des valeurs négatives en appels à rand.Int63n() , qui panique dans ce cas.
Linux. Le deuxième code du LEAP a été appelé à partir du gestionnaire d'interruption de la minuterie, qui contenait xtime_lock . Ce code a fait un printk pour enregistrer le saut deuxième. printk réveille klogd , qui peut parfois essayer d'obtenir le temps, qui attend sur xtime_lock , provoquant une impasse.
Linux. Lorsqu'une seconde de saut s'est produite, CLOCK_REALTIME a été rembobin d'une seconde. Cela n'a pas été fait via un mécanisme qui mettrait à jour hrtimer base.offset . Cela signifiait que lorsqu'une interruption de la minuterie s'est produite, TIMER_ABSTIME COLLYTHITIME TIMERS a été expirée une seconde plus tôt, y compris les minuteries fixées pendant moins d'une seconde. Cela a provoqué des applications qui utilisaient le sommeil pendant moins d'une seconde dans une boucle à Spinwait sans dormir, provoquant une charge élevée sur de nombreux systèmes. Cela a fait baisser un grand nombre de services Web en 2012.
Mozilla. La plupart des modules complémentaires de Firefox ont cessé de fonctionner vers le 4 mai 2019 lorsqu'un certificat a expiré. Firefox nécessite une chaîne de certificat valide pour empêcher les logiciels malveillants. Environ neuf heures plus tard, Mozilla a poussé un module complémentaire privilégié qui a injecté un certificat valide dans le magasin de certificats de Firefox, créant une chaîne valide et débloquant des modules complémentaires. Cet a désactivé efficacement tous les modules complémentaires, environ 15 000, et la résolution a pris environ 15-21 heures pour la plupart des utilisateurs. Certaines données utilisateur ont été perdues. Auparavant, Mozilla a publié sur les détails techniques.
Github. La plate-forme GitHub a rencontré un nouveau mode de défaillance lors du traitement d'une migration de schéma sur une grande table MySQL. Les migrations de schéma sont une tâche courante chez Github et prennent souvent des semaines. La dernière étape d'une migration consiste à effectuer un renommée pour déplacer le tableau mis à jour au bon endroit. Au cours de la dernière étape de cette migration, une partie importante de nos répliques de lecture MySQL est entrée dans une impasse du sémaphore. Nos clusters MySQL sont constitués d'un nœud principal pour le trafic d'écriture, des répliques de lecture multiples pour le trafic de production et plusieurs répliques qui desservent le trafic de lecture interne à des fins de sauvegarde et d'analyse. Les répliques de lecture qui ont frappé le blocage sont entrées dans un état de récupération de collision provoquant une charge accrue sur les répliques de lecture saines. En raison de la nature en cascade de ce scénario, il n'y avait pas suffisamment de répliques de lecture actives pour gérer les demandes de production qui ont eu un impact sur la disponibilité des services de base GitHub.
Heroku. À 15h05 UTC le 8 juin 2023, une erreur de base de données s'est produite lorsqu'une clé étrangère a utilisé un type de données plus petit que la clé principale qu'elle a référencée. Cette erreur a provoqué un débordement lorsque la clé primaire a dépassé la valeur autorisée, ce qui a entraîné une incapacité à créer de nouvelles autorisations au sein d'Heroku. Cette erreur a également empêché les clients de créer de nouveaux déploiements. Les opérations OnCall ont ensuite déclenché la panne complète de l'API Heroku.
Allegro. La plate-forme Allegro a subi l'échec d'un sous-système responsable du traitement des tâches distribué asynchrones. Le problème a affecté de nombreux domaines, par exemple, les fonctionnalités telles que l'achat de nombreuses offres via le montage et l'édition des offres en vrac (y compris l'édition de liste de prix) n'ont pas fonctionné du tout. De plus, il n'a pas réussi à envoyer un newsletter quotidien avec de nouvelles offres. Certaines parties du panel d'administration interne ont également été affectées.
Amazone. Erreur humaine. Le 28 février 2017 à 9h37 PST, l'équipe Amazon S3 déboguait un problème mineur. Malgré l'utilisation d'un livre de jeu établi, l'une des commandes qui l'intention de supprimer un petit nombre de serveurs a été publiée avec une faute de frappe, ce qui a provoqué par inadvertance un plus grand ensemble de serveurs. Ces serveurs ont pris en charge les systèmes S3 critiques. En conséquence, les systèmes dépendants ont nécessité un redémarrage complet pour fonctionner correctement, et le système a subi des pannes répandues pour US-East-1 (Virginie du Nord) jusqu'à la résolution finale à 13 h 54 PST. Étant donné que les propres services d'Amazon tels que EC2 et EBS s'appuient également sur S3, cela a provoqué une vaste échec en cascade qui a affecté des centaines d'entreprises.
Amazone. La corruption des messages a fait submerger la fonction de l'état du serveur distribué sur la flotte de traitement de la demande S3.
Amazone. L'erreur humaine lors d'une mise à niveau de réseautage de routine a conduit à un resserrement des ressources, exacerbée par des bogues logiciels, ce qui a finalement entraîné une panne dans toutes les zones de disponibilité des États-Unis East ainsi qu'une perte de 0,07% des volumes.
Amazone. L'incapacité à contacter un serveur de collecte de données a déclenché un bug de fuite de mémoire latente dans l'agent de déclaration sur les serveurs de stockage. Et il n'y a pas de manipulation gracieuse de dégradation, donc l'agent de déclaration a contacté continuellement le serveur de collecte d'une manière qui a lentement consommé la mémoire du système. De plus, le système de surveillance n'a pas réussi à alarmer la fuite de mémoire de ce serveur EBS, les serveurs EBS sont également généralement très dynamiques de toutes les mémoire. Lundi matin, le taux de perte de mémoire est devenu assez élevé et confus suffisamment de mémoire sur les serveurs de stockage affectés qui ne peuvent pas rester avec le processus de gestion de la demande. Cette erreur a été encore rompue par l'incapacité de faire le basculement, ce qui a entraîné la panne.
Amazone. L'équilibreur de charge élastique a rencontré des problèmes lorsqu'un "processus de maintenance qui a été exécuté par inadvertance contre les données de l'état ELB de production".
Amazone. Une «perturbation du réseau» a fait en sorte que les services de métadonnées éprouvent des charges qui ont provoqué des délais de réponse, ce qui a fait que les nœuds de stockage se réunissent. Les nœuds qui se sont abattus ont continué à réessayer, garantissant que la charge sur les services de métadonnées ne pouvait pas diminuer.
Amazone. La mise à l'échelle de la flotte de cache frontale pour la kinésis a provoqué que tous les serveurs de la flotte dépassent le nombre maximum de threads autorisés par une configuration du système d'exploitation. Plusieurs services critiques en aval affectés, de Cognito à Lambda à CloudWatch.
Amazone. À 7 h 30 PST, une activité automatisée pour évoluer la capacité de l'un des services AWS hébergés dans le réseau AWS principal a déclenché un comportement inattendu à partir d'un grand nombre de clients à l'intérieur du réseau interne. Cela a entraîné une grande augmentation de l'activité de connexion qui a submergé les dispositifs de réseautage entre le réseau interne et le réseau AWS principal, entraînant des retards de communication entre ces réseaux. Ces retards ont augmenté la latence et les erreurs pour les services communiquant entre ces réseaux, ce qui entraîne encore plus de tentatives et de tentatives de connexion. Cela a conduit à des problèmes de congestion et de performances persistants sur les appareils reliant les deux réseaux.
Appnexus. Un double libre révélé par une mise à jour de la base de données a provoqué un plan des serveurs "Bus d'impression" simultanément. Cela n'a pas été pris dans la mise en scène et a été mis en production car un délai est nécessaire pour déclencher le bug, et la période de mise en scène n'avait pas de retard intégré.
AT&T. Une mauvaise gamme de code C a introduit un danger de course qui, en temps voulu, a effondré le réseau téléphonique. Après une panne prévue, les messages de reprise de QuickFire ont déclenché la course, provoquant davantage de redémarrages qui ont reculé le problème. "Le problème s'est répété de manière itérative tout au long des 114 commutateurs du réseau, bloquant plus de 50 millions d'appels au cours des neuf heures qu'il a fallu pour stabiliser le système." À partir de 1990.
Atlassian. Le mardi 5 avril 2022, à partir de 7:38 UTC, 775 clients Atlassian ont perdu accès à leurs produits Atlassian. La panne s'est déroulée jusqu'à 14 jours pour un sous-ensemble de ces clients, le premier ensemble de clients restaurés le 8 avril et tous les sites clients progressivement restaurés d'ici le 18 avril.
Basecamp, voir aussi. Le réseau de Basecamp a été soumis à une attaque DDOS lors d'une fenêtre de 100 minutes le 24 mars 2014.
Basecamp, voir aussi. En novembre 2018, une base de données a atteint la limite des entiers, laissant le service en mode en lecture seule.
BBC en ligne. En juillet 2014, BBC Online a connu une très longue panne de plusieurs de ses services en ligne populaires, notamment la BBC iPlayer. Lorsque le backend de la base de données a été surchargé, il avait commencé à faire progresser les demandes de divers services. Les services qui n'avaient pas mis en cache les réponses de la base de données ont commencé à synchroniser et ont finalement échoué complètement.
Cage de sauterelle. En juillet 2017, plusieurs forfaits Maven malveillants ont été inclus dans JCenter avec une attaque d'identité. Ces packages vivent dans JCenter pendant plus d'un an et ont soi-disant affecté plusieurs applications Android qui ont abouti à un code de logiciel malveillant injecté par ces dépendances de JCenter.
Bitly. Le repo de code source hébergé contenait des informations d'identification accordant l'accès aux sauvegardes bitly, y compris les mots de passe hachés.
Browserstack. Une ancienne machine prototype avec la vulnérabilité ShellShock toujours active avait des clés secrètes qui ont finalement conduit à une violation de sécurité du système de production.
BuildKite. La dégradation de la capacité de la base de données dans le but de minimiser les dépenses AWS a entraîné un manque de capacité à soutenir les clients BuildKite à PEAK, ce qui entraîne un effondrement en cascade des serveurs dépendants.
Bungie. Les effets secondaires d'une correction de bogue pour les mauvais horodatages provoquent une perte de données; La mauvaise configuration du serveur pour le hotfix provoque une réapparition de la perte de données dans plusieurs serveurs dans une mise à jour suivante.
Jeux CCP. Un canal de journalisation problématique a provoqué des nœuds de cluster qui se sont éteints pendant la séquence de démarrage du cluster après avoir déployé un nouveau patch de jeu.
Jeux CCP. Documents Un bug de réutilisation de la mémoire Python sans pile qui a mis des années à retrouver.
Chef.io. Le supermarché du site de la communauté des recettes s'est écrasé deux heures après le lancement en raison de la non-réponse intermittente et de la latence accrue. L'une des principales raisons de l'échec identifiée dans l'après-mortem a été des délais de vérification de la santé très faibles.
Circleci. Une panne de github et une récupération ont provoqué une charge entrante inattendue. Pour des raisons qui ne sont pas spécifiées, une charge importante fait ralentir le système de file d'attente de Circleci, dans ce cas, pour gérer une transaction par minute.
Circleci. Le 4 janvier 2023, notre enquête interne avait déterminé la portée de l'intrusion par le tiers non autorisé et le chemin d'entrée de l'attaque. À ce jour, nous avons appris qu'un logiciel malveillant à effet de levier non autorisé non autorisé était déployé sur un ordinateur portable d'un ingénieur de Circleci afin de voler une session SSO valide et soutenue par 2FA. Cette machine a été compromise le 16 décembre 2022. Le malware n'a pas été détecté par notre logiciel antivirus. Notre enquête indique que les logiciels malveillants ont pu exécuter le vol de cookies de session, leur permettant d'identifier l'employé ciblé dans un endroit éloigné, puis de dégénérer l'accès à un sous-ensemble de nos systèmes de production.
Cloudflare. Un bogue d'analyseur a provoqué la mémoire des serveurs CloudFlare Edge qui contenaient des informations privées telles que les cookies HTTP, les jetons d'authentification, les corps de publication HTTP et d'autres données sensibles.
Cloudflare. Un épuisement du processeur a été causé par une seule règle de WAF qui contenait une expression régulière mal écrite qui a fini par créer un retour en arrière excessif. Cette règle a été déployée rapidement en production et une série d'événements mènent à un temps d'arrêt mondial de 27 minutes des services CloudFlare.
Datadog. Après une mise à niveau automatique, toutes les règles de réseau ont été supprimées et ont provoqué une sortie de durée de 24h de tous leurs clusters Kubernetes protégés par le cil dans toutes leurs régions et fournisseurs de cloud.
Discorde. Un service battant a conduit à un troupeau tonitruant qui s'y reconnecte une fois qu'il est apparu. Cela a conduit à une erreur en cascade où les services Frontend ont manqué de mémoire en raison du remplissage des files d'attente internes.
Discorde. "Vers 14:01, une instance redis agissant comme principale pour un cluster hautement disponible utilisé par les services d'API de Discord a été migrée automatiquement par la plate-forme cloud de Google. Cette migration a provoqué la baisse incorrectement hors ligne, forçant le cluster vers la rééquilibre et déclenchez les problèmes connus avec la façon dont les instances API de disque ont été provoquées. Le système en temps réel de Discord.
Dropbox. Ce post-mortem est assez mince et je ne sais pas ce qui s'est passé. Il semble que, peut-être, une mise à niveau du système d'exploitation planifié en quelque sorte provoqué la sortie de certaines machines, ce qui a supprimé certaines bases de données.
Duo. Échec en cascade en raison d'une file d'attente de demande surchargeant la capacité de base de données insuffisante existante. Une planification et un suivi inadéquats de la capacité pourraient également être attribués.
Jeux épiques. La charge extrême (un nouveau pic de 3,4 millions d'utilisateurs simultanés) a entraîné un mélange de perturbations de service partielle et totale.
Agence spatiale européenne. Un débordement s'est produit lors de la conversion d'un nombre 16 bits en un nombre 64 bits dans le système de guidage intertial Ariane 5, provoquant une écrasement de la fusée. Le débordement réel s'est produit dans le code qui n'était pas nécessaire pour l'opération mais qui s'exécutait de toute façon. Selon un compte, cela a fait imprimer un message d'erreur de diagnostic, et le message d'erreur de diagnostic a été interprété en quelque sorte comme des données valides réelles. Selon un autre compte, aucun gestionnaire de pièges n'a été installé pour le débordement.
Élastique. Des clients du cloud élastique avec des déploiements dans la région AWS EU-West-1 (Irlande) ont connu un accès gravement dégradé à leurs grappes pendant environ 3 heures. Au cours de cette même période, il y a eu une période d'environ 20 minutes au cours de laquelle tous les déploiements de cette région n'étaient pas totalement indisponibles.
Élastique. Des clients Elastic Cloud avec des déploiements dans la région AWS US-East-1 ont connu un accès dégradé à leurs grappes.
Eslint. Le 12 juillet 2018, un attaquant a compromis le récit du NPM d'un mainteneur d'Eslint et a publié des forfaits malveillants dans le registre du NPM.
Etsy. Tout d'abord, un déploiement qui était censé être un petit déploiement de bugfix a également provoqué la mise à niveau de bases de données en direct sur l'exécution des machines de production. Pour s'assurer que cela n'a pas provoqué de corruption, Etsy a cessé de servir le trafic pour effectuer des vérifications d'intégrité. Deuxièmement, un débordement en IDS (INTS 32 bits signé) a fait échouer certaines opérations de base de données. Etsy n'a pas confiance que cela n'aurait pas entraîner la corruption des données et a enlevé le site pendant que la mise à niveau a été poussée.
Rapide. Orche de panne mondiale en raison d'un bogue logiciel non découvert qui a fait surface le 8 juin lorsqu'il a été déclenché par un changement de configuration client valide.
Flowdock. La messagerie instantanée à flux n'était pas disponible pendant environ 24 heures entre le 21 et le 22 avril 2020. La pandémie Covid-19 a provoqué une augmentation soudaine et drastique du travail à domicile, ce qui a provoqué une utilisation plus élevée de Flowdock, ce qui a provoqué une forte utilisation du CPU, ce qui a provoqué la suspension de la base de données d'applications. Certaines données d'utilisateurs ont été perdantes en permanence.
Foursquare. MongoDB est tombé sous charge lorsqu'il a manqué de mémoire. L'échec était catastrophique et non gracieux en raison du modèle de requête AA qui impliquait une charge de lecture avec de faibles niveaux de localité (chaque enregistrement de l'utilisateur a provoqué une lecture de tous les enregistrements pour l'historique de l'utilisateur, et les enregistrements étaient de 300 octets sans localité spatiale, ce qui signifie que la plupart des données tirées de chaque page étaient inutiles). Un manque de surveillance sur les instances MongoDB a provoqué une charge élevée non détectée jusqu'à ce que la charge devienne catastrophique, provoquant 17 heures de temps d'arrêt couvrant deux incidents en deux jours.
Gentoo. Une entité a eu accès à l'organisation Gentoo Github, a supprimé l'accès à tous les développeurs et a commencé à ajouter des commits dans divers référentiels.
Github. Le 28 février 2018, Github a connu une attaque DDOS, frappant le site Web avec 1,35 Tops de trafic.
Gitlab. Après le primaire verrouillé et redémarré, il a été soulevé avec le mauvais système de fichiers, provoquant une panne mondiale. Voir aussi Discussion HN.
Gitlab. L'afflux de demandes a surchargé la base de données, a provoqué une retard de réplication, l'administrateur fatigué a supprimé le mauvais répertoire, six heures de données perdues. Voir également le rapport antérieur et la discussion HN.
Google. Un système de courrier a envoyé un e-mail aux gens plus de 20 fois. Cela s'est produit parce que le courrier a été envoyé avec un travail par lots qui a envoyé du courrier à tous ceux qui ont été marqués comme un courrier. Il s'agissait d'une opération non atomique et le travail par lots n'a pas marqué les gens comme n'attendant pas que tous les messages aient été envoyés.
Google. FileStore applique une limite globale des demandes d'API pour limiter l'impact dans les scénarios de surcharge. La panne a été déclenchée lorsqu'un service Google interne gérant un grand nombre de projets GCP a mal fonctionné et a surchargé l'API FileStore avec des demandes, provoquant la limitation globale de l'API FileStore. Cela s'est poursuivi jusqu'à ce que le service interne soit interrompu manuellement. À la suite de cet accès API en lecture seule à la lecture, n'était pas disponible pour tous les clients. Cela a affecté les clients dans tous les endroits, en raison d'un quota mondial qui s'applique à FileStore. La console, le gcloud et l'accès à l'API (liste, getOperation, etc.) appelle tous les échecs pour une durée de 3 heures, 12 minutes. Mutate operations (CreateInstance, UpdateInstance, CreateBackup, etc.) still succeeded, but customers were unable to check on operation progress.
Google. The Google Meet Livestream feature experienced disruptions that caused intermittent degraded quality of experience for a small subset of viewers, starting 25 October 2021 0400 PT and ending 26 October 2021 1000 PT. Quality was degraded for a total duration of 4 hours (3 hours on 25 October and 1 hour on 26 October). During this time, no more than 15% of livestream viewers experienced higher rebuffer rates and latency in livestream video playback. We sincerely apologize for the disruption that may have affected your business-critical events. We have identified the cause of the issue and have taken steps to improve our service.
Google. On 13 October 2022 23:30 US/Pacific, there was an unexpected increase of incoming and logging traffic combined with a bug in Google's internal streaming RPC library that triggered a deadlock and caused the Write API Streaming frontend to be overloaded. And BigQuery Storage WriteAPI observed elevated error rates in the US Multi-Region for a period of 5 hours.
GPS/GLONASS. A bad update that caused incorrect orbital mechanics calculations caused GPS satellites that use GLONASS to broadcast incorrect positions for 10 hours. The bug was noticed and rolled back almost immediately due to (?) this didn't fix the issue.
Healthcare.gov. A large organizational failure to build a website for United States healthcare.
Heroku. Having a system that requires scheduled manual updates resulted in an error which caused US customers to be unable to scale, stop or restart dynos, or route HTTP traffic, and also prevented all customers from being able to deploy.
Heroku. An upgrade silently disabled a check that was meant to prevent filesystem corruption in running containers. A subsequent deploy caused filesystem corruption in running containers.
Heroku. An upstream apt update broke pinned packages which lead to customers experiencing write permission failures to /dev .
Heroku. Private tokens were leaked, and allowed attackers to retrieve data, both in internal databases, in private repositories and from customers accounts.
Heroku. A change to the core application that manages the underlying infrastructure for the Common Runtime included a dependency upgrade that caused a timing lock issue that greatly reduced the throughput of our task workers. This dependency change, coupled with a failure to appropriately scale up due to increased workload scheduling, caused the application's work queue to build up. Contributing to the issue, the team was not alerted immediately that new router instances were not being initialized correctly on startup largely because of incorrectly configured alerts. These router instances were serving live traffic already but were shown to be in the wrong boot state, and they were deleted via our normal processes due to failing readiness checks. The deletion caused a degradation of the associated runtime cluster while the autoscaling group was creating new instances. This reduced pool of router instances caused requests to fail as more requests were coming in faster than the limited number of routers could handle. This is when customers started noticing issues with the service.
Homebrew. A GitHub personal access token with recently elevated scopes was leaked from Homebrew's Jenkins that allowed access to git push on several Homebrew repositories.
Rayon de miel. A tale of multiple incidents, happening mostly due to fast growth.
Rayon de miel. Another story of multiple incidents that ended up impacting query performance and alerting via triggers and SLOs. These incidents were notable because of how challenging their investigation turned out to be.
Rayon de miel. On September 8th, 2022, our ingest system went down repeatedly and caused interruptions for over eight hours. We will first cover the background behind the incident with a high-level view of the relevant architecture, how we tried to investigate and fix the system, and finally, we'll go over some meaningful elements that surfaced from our incident review process.
Rayon de miel. On July 25th, 2023, we experienced a total Honeycomb outage. It impacted all user-facing components from 1:40 pm UTC to 2:48 pm UTC, during which no data could be processed or accessed. The full details of incident triage process is covered in here.
incident.io. A bad event (poison pill) in the async workers queue triggered unhandled panics that repeatedly crashed the app. This combined poorly with Heroku infrastructure, making it difficult to find the source of the problem. Applied mitigations that are generally interesting to people running web services, such as catching corner cases of Go panic recovery and splitting work by type/class to improve reliability.
Indian Electricity Grid. One night in July 2012, a skewed electricity supply-demand profile developed when the northern grid drew a tremendous amount of power from the western and eastern grids. Following a series of circuit breakers tripping by virtue of under-frequency protection, the entire NEW (northern-eastern-western) grid collapsed due to the absence of islanding mechanisms. While the grid was reactivated after over 8 hours, similar conditions in the following day caused the grid to fail again. However, the restoration effort concluded almost 24 hours after the occurrence of the latter incident.
Instapaper. Also this. Limits were hit for a hosted database. It took many hours to migrate over to a new database.
Intel. A scripting bug caused the generation of the divider logic in the Pentium to very occasionally produce incorrect results. The bug wasn't caught in testing because of an incorrect assumption in a proof of correctness. (See the Wikipedia article on 1994 FDIV bug for more information.)
Joyent. Operations on Manta were blocked because a lock couldn't be obtained on their PostgreSQL metadata servers. This was due to a combination of PostgreSQL's transaction wraparound maintenance taking a lock on something, and a Joyent query that unnecessarily tried to take a global lock.
Joyent. An operator used a tool with lax input validation to reboot a small number of servers undergoing maintenance but forgot to type -n and instead rebooted all servers in the datacenter. This caused an outage that lasted 2.5 hours, rebooted all customer instances, put tremendous load on DHCP/TFTP PXE boot systems, and left API systems requiring manual intervention. See also Bryan Cantrill's talk.
Kickstarter. Primary DB became inconsistent with all replicas, which wasn't detected until a query failed. This was caused by a MySQL bug which sometimes caused order by to be ignored.
Kings College London. 3PAR suffered catastrophic outage which highlighted a failure in internal process.
Launchdarkly. Rule attribute selector causing flag targeting web interface to crash.
Mailgun. Secondary MongoDB servers became overloaded and while troubleshooting accidentally pushed a change that sent all secondary traffic to the primary MongoDB server, overloading it as well and exacerbating the problem.
Mandrill. Transaction ID wraparound in Postgres caused a partial outage lasting a day and a half.
Moyen. Polish users were unable to use their "Ś" key on Medium.
Metrist. Azure published a breaking change that affected downstream systems like Metrist's service without warning them, the post covers how to identify the issue and how to recover from it.
NASA. A design flaw in the Apollo 11 rendezvous radar produced excess CPU load, causing the spacecraft computer to restart during lunar landing.
NASA. Use of different units of measurement (metric vs. English) caused Mars Climate Orbiter to fail. There were also organizational and procedural failures[ref] and defects in the navigation software[ref].
NASA. NASA's Mars Pathfinder spacecraft experienced system resets a few days after landing on Mars (1997). Debugging features were remotely enabled until the cause was found: a priority inversion problem in the VxWorks operating system. The OS software was remotely patched (all the way to Mars) to fix the problem by adding priority inheritance to the task scheduler.
Netflix. An EBS outage in one availability zone was mitigated by migrating to other availability zones.
North American Electric Power System. A power outage in Ohio around 1600h EDT cascaded up through a web of systemic vulnerabilities and process failures and resulted in an outage in the power grid affecting ~50,000,000 people for ~4 days in some areas, and caused rolling blackouts in Ontario for about a week thereafter.
Okta. A hackers group got access to a third-party support engineer's laptop.
OpenAI. Queues for requests and responses in a Redis cache became corrupted and out of sequence, leading to some requests revealing other people's user data to some users, including app activity data and some billing info.
Pagerduty. In April 2013, Pagerduty, a cloud service proving application uptime monitoring and real-time notifications, suffered an outage when two of its three independent cloud deployments in different data centers began experiencing connectivity issues and high network latency. It was found later that the two independent deployments shared a common peering point which was experiencing network instability. While the third deployment was still operational, Pagerduty's applications failed to establish quorum due to to high network latency and hence failed in their ability to send notifications.
PagerDuty. A third party service for sending SMS and making voice calls experienced an outage due to AWS having issues in a region.
Parité. $30 million of cryptocurrency value was diverted (stolen) with another $150 million diverted to a safe place (rescued), after a 4000-line software change containing a security bug was mistakenly labeled as a UI change, inadequately reviewed, deployed, and used by various unsuspecting third parties. See also this analysis.
Platform.sh. Outage during a scheduled maintenance window because there were too much data for Zookeeper to boot.
Reddit. Experienced an outage for 1.5 hours, followed by another 1.5 hours of degraded performance on Thursday August 11 2016. This was due to an error during a migration of a critical backend system.
Reddit. Outage for over 5 hours when a critical Kubernetes cluster upgrade failed. The failure was caused by node metadata that changed between versions which brought down workload networking.
Roblox. Roblox end Oct 2021 73 hours outage. Issues with Consul streaming and BoltDB.
Salesforce. Initial disruption due to power failure in one datacenter led to cascading failures with a database cluster and file discrepancies resulting in cross data center failover issues.
Salesforce. On September 20, 2023, a service disruption affected a subset of customers across multiple services beginning at 14:48 Coordinated Universal Time (UTC). As a result, some customers were unable to login and access their services. A policy change executed as a part of our standard security controls review and update cycle to be the trigger of this incident. This change inadvertently blocked access to resources beyond its intended scope.
Sentinelle. Transaction ID Wraparound in Postgres caused Sentry to go down for most of a working day.
Shapeshift. Poor security practices enabled an employee to steal $200,000 in cryptocurrency in 3 separate hacks over a 1 month period. The company's CEO expanded upon the story in a blog post.
Skyliner. A memory leak in a third party library lead to Skyliner being unavailable on two occasions.
Mou. A combination of factor results in a large number of Slack's users being disconnected to the server. The subsequent massive disconnection-reconnection process exceeded the database capacity and caused cascading connection failures, leading to 5% of Slack's users not being able to connect to the server for up to 2 hours.
Mou. Network saturation in AWS's traffic gateways caused packet loss. An attempt to scale up caused more issues.
Mou. Cache nodes removal caused the high workload on the vitness cluster, which in turn cased the service outage.
Spotify. Lack of exponential backoff in a microservice caused a cascading failure, leading to notable service degradation.
Carré. A cascading error from an adjacent service lead to merchant authentication service being overloaded. This impacted merchants for ~2 hours.
Stackdriver. In October 2013, Stackdriver, experienced an outage, when its Cassandra cluster crashed. Data published by various services into a message bus was being injested into the Cassandra cluster. When the cluster failed, the failure percolated to various producers, that ended up blocking on queue insert operations, eventually leading to the failure of the entire application.
Stack Exchange. Enabling StackEgg for all users resulted in heavy load on load balancers and consequently, a DDoS.
Stack Exchange. Backtracking implementation in the underlying regex engine turned out to be very expensive for a particular post leading to health-check failures and eventual outage.
Stack Exchange. Porting old Careers 2.0 code to the new Developer Story caused a leak of users' information.
Stack Exchange. The primary SQL-Server triggered a bugcheck on the SQL Server process, causing the Stack Exchange sites to go into read only mode, and eventually a complete outage.
Strava. Hit the signed integer limit on a primary key, causing uploads to fail.
Bande. Manual operations are regularly executed on production databases. A manual operation was done incorrectly (missing dependency), causing the Stripe API to go down for 90 minutes.
Suède. Use of different rulers by builders caused the Vasa to be more heavily built on its port side and the ship's designer, not having built a ship with two gun decks before, overbuilt the upper decks, leading to a design that was top heavy. Twenty minutes into its maiden voyage in 1628, the ship heeled to port and sank.
Tarsnap. A batch job which scans for unused blocks in Amazon S3 and marks them to be freed encountered a condition where all retries for freeing certain blocks would fail. The batch job logs its actions to local disk and this log grew without bound. When the filesystem filled, this caused other filesystem writes to fail, and the Tarsnap service stopped. Manually removing the log file restored service.
Telstra. A fire in a datacenter caused SMS text messages to be sent to random destinations. Corrupt messages were also experienced by customers.
Therac-25. The Therac-25 was a radiation therapy machine involved in at least six accidents between 1985 and 1987 in which patients were given massive overdoses of radiation. Because of concurrent programming errors, it sometimes gave its patients radiation doses that were thousands of times greater than normal, resulting in death or serious injury.
trivago. Due to a human error, all engineers lost access to the central source code management platform (GitHub organization). An Azure Active Directory Security group controls the access to the GitHub organization. This group was removed during the execution of a manual and repetitive task.
Twilio. In 2013, a temporary network partition in the redis cluster used for billing operations, caused a massive resynchronization from slaves. The overloaded master crashed and when it was restarted, it started up in read-only mode. The auto-recharge component in This resulted in failed transactions from Twilio's auto-recharge service, which unfortunately billed the customers before updating their balance internally. So the auto-recharge system continued to retry the transaction again and again, resulting in multiple charges to customer's credit cards.
Twilio. Twilio's incident of having high filtering on SMS towards AT&T Network In United States.
Soupape. Steam's desktop client deleted all local files and directories. The thing I find most interesting about this is that, after this blew up on social media, there were widespread reports that this was reported to Valve months earlier. But Valve doesn't triage most bugs, resulting in an extremely long time-to-mitigate, despite having multiple bug reports on this issue.
Yeller. A network partition in a cluster caused some messages to get delayed, up to 6-7 hours. For reasons that aren't clear, a rolling restart of the cluster healed the partition. There's some suspicious that it was due to cached routes, but there wasn't enough logging information to tell for sure.
Zerodha. The Order Management System (OMS) provided to Zerodha, a stock broker, collapsed when an order for 1M units of a penny stock was divided into more than 0.1M individual trades against the typical few hundreds, triggering a collapse of the OMS, which was not encountered prior by its provider - Refinitiv (formerly Thomson Reuters), a subsidiary of the London Stock Exchange.
Zerodha. A failure of the primary leased line to a CTCL between a stock broker and a stock exchange led to the activation of a backup leased line that was operating sporadically over the following hour, affecting bracket and cover orders. Subsequently, the process of placing and validating orders had been modified to incorporate the unreliability of the CTCL's leased lines, but the reliability of the primary and the backup leased lines was not fundamentally improved by the providers.
Unfortunately, most of the interesting post-mortems I know about are locked inside confidential pages at Google and Microsoft. Please add more links if you know of any interesting public post mortems! is a pretty good resource; other links to collections of post mortems are also appreciated.
AWS Post-Event Summaries
Availability Digest website.
Postmortems community (with imported archive from the now-dead G+ community).
John Daily's list of postmortems (in json).
Jeff Hammerbacher's list of postmortems.
NASA lessons learned database.
Tim Freeman's list of postmortems
Wikimedia's postmortems.
Autopsy.io's list of Startup failures.
SRE Weekly usually has an Outages section at the end.
Lorin Hochstein's list of major incidents.
Awesome Tech Postmortems.
Nat Welch's parsed postmortems is an attempt to build a database out of this markdown file.
Postmortem Templates is a collection of postmortem templates from various sources.
How Complex Systems Fail
John Allspaw on Resilience Engineering
