Incident post mortem: 16 novembre 2020

Black Friday Promotion


par Drew Rothstein, directeur de l'ingénierie

Le 16 novembre, Coinbase a connu une panne qui a affecté nos applications Web et mobiles. Nous avons rapidement suspecté que la cause première était basée sur une migration en cours et avons commencé à résoudre le problème. Cet article fournit plus de détails sur ce qui s'est passé.

Demandes en production

Vers 15 h 32 HNE, nous avons commencé à voir plusieurs graphiques de services similaires à ceux ci-dessus avec une baisse marquée du trafic vers zéro. Nos premières pages ont commencé à apparaître pendant les quelques minutes suivantes. À 15 h 38 HNE, notre processus d'incident avait commencé avec l'impact initial, la gravité et nos pages de mise à jour automatisée des documents, de vidéoconférence et de statut.

Exemple de processus d'automatisation des incidents

Dans les trois minutes suivant la création de l'incident, nous avons suspecté que cela était lié à une migration que nous exécutions pour mettre à jour les certificats TLS internes entre les services. Nous avons besoin d'une validation de certificat TLS interservices et étions en train de les mettre à jour pour une expiration prochaine.

Compte tenu de nos soupçons concernant la migration des certificats TLS, nous avons commencé à préparer la restauration des services les plus importants et les plus critiques. Comme nous avions décomposé cette migration en plusieurs parties, de nombreuses demandes d'extraction (PR) devaient être annulées, et celles-ci étaient automatiquement préparées, soumises et appliquées une fois que nous avons déterminé qu'il était sûr de le faire.

Nous priorisons les restaurations dans nos applications principales et à 15 h 46. EST, ce changement a été préparé et mis en œuvre peu de temps après.

Après avoir annulé la modification du certificat, nous avons commencé à rencontrer un autre ensemble de problèmes. Nos services devaient être redémarrés. La redistribution était le moyen le plus simple et le plus sûr de le faire, car nous disposons d'outils et de processus automatisés pour vous aider. En général, nous n'autorisons pas les gens à manipuler les services manuellement.

Lorsque les services ont commencé à se déployer, ils n'ont pas pu être entièrement redémarrés. Des problèmes de connectivité ont d'abord été suspectés car nous n'avions pas complètement inversé la migration TLS et il y avait toujours une file d'attente de services en cours. Après quelques minutes d'examen des métriques, des journaux et des traces, il a été déterminé qu'il s'agissait probablement d'un problème de troupeau tonitruant, qui a été confirmé plus tard par des métriques.

HTTP 500 servi par notre backend

Nous avons pris deux mesures pour atténuer et à 16 h 48 HNE:

  1. Nous supprimons temporairement la connectivité, bloquant efficacement tout le trafic vers l'un de nos principaux services backend et vous permettant de le redéployer suffisamment.
  2. Nous avons augmenté le nombre de machines pour ce service afin que lorsque nous réactivions le trafic, il puisse gérer l'augmentation de la charge.

À 16 h 59 HNE, nous avons pu remettre ce service essentiel en ligne et nous avons pu réévaluer les erreurs restantes. Les erreurs ont disparu immédiatement et à 17 h 04 HNE, presque tous les services avaient récupéré.

La cause principale

tl; dr: L'un des centaines de certificats mis à jour se trouvait sur un équilibreur de charge externe où il n'aurait pas dû être appliqué. Cela a entraîné des problèmes de validation de certificat (les services n'attendaient pas ce certificat) et une série de pannes de connectivité de service.

Nous utilisons des équilibreurs de charge basés sur les services et des équilibreurs de charge AWS. Les deux types d'équilibreurs de charge utilisent le service AWS ACM pour fournir des certificats pour les applications internes.

Le processus jusqu'à présent impliquait de mettre à jour le codage de notre infrastructure (dans notre transpilateur Terraform) et de tester une série de propriétés Web qui ont traversé le processus de migration. Jusqu'à présent, tout cela a réussi.

Un PR a été préparé pour chaque groupe de services afin qu'ils puissent être examinés et apparaissent comme des centaines de lignes d'ajouts à la même référence de certificat que nous avions planifiée et attendue.

YAML qui compile vers Terraform

Nos outils automatisés qui écoutent les webhooks ont exécuté chaque PR via un ensemble automatisé de tests et de validations. Cela comprend l'exécution d'un plan Terraform sur le changement et la production de résultats à examiner.

Exemple de sortie de plan Terraform pour ce changeset

Dans l'un des nombreux RP, une erreur d'origine humaine s'est produite: une ligne a été ajoutée à un équilibreur de charge externe qui aurait dû être ignorée. Comme mentionné ci-dessus, c'était pour les certificats internes.

Cela n'a pas été facilement identifié, car le changement lui-même était syntaxiquement correct et le plan Terraform correct.

Tous nos équilibreurs de charge externes sont également dotés d'une propriété supplémentaire que nous appelons externe. S'il est défini, il active le trafic de notre périphérie vers l'équilibreur de charge. Dans le cas de cette modification, cette propriété a été définie correctement, mais la différence Git n'indiquait pas clairement qu'elle était définie car elle n'était pas visible. Cela est en partie dû à la façon dont GitHub affiche 3 lignes avant et publie sur la ligne modifiée dans l'interface Web.

PR ne montrant aucune propriété externe dans diff

Un réviseur aurait dû étendre la zone environnante pour mieux comprendre le contexte de ce changement spécifique et confirmer qu'il ne s'agissait pas d'un équilibreur de charge externe et qu'il était en fait interne.

Lorsque cette modification a été fusionnée, cet équilibreur de charge particulier s'est avéré être un équilibreur de charge externe et cette rotation de certificat particulière n'aurait pas dû être appliquée. Cela a empêché les services en aval de valider le certificat attendu car ils s'attendaient à une chaîne de certificats complètement différente. Cela a empêché les services de se connecter correctement et de servir le trafic.

Regard vers le futur

En réponse à ces événements, nous travaillons sur un certain nombre d'améliorations. Nous avons déjà écrit du code pour analyser nos 700+ équilibreurs de charge pour détecter les écarts entre le codage de l'infrastructure et la configuration en cours. Nous testons activement la version en nous concentrant davantage sur les revues de relations publiques lorsque cela pourrait se produire. Nous avons automatisé les PR de changement de configuration et cela filtre automatiquement les équilibreurs de charge externes qui empêchent que cela se produise.

Après avoir effectué une série d'autopsies formelles au cours des prochains jours, nous identifierons et discuterons probablement de nombreux efforts à court et à long terme pour prévenir ce problème et les conditions connexes que nous avons appris grâce à cet incident, comme le problème du troupeau que nous n'avions pas connu auparavant. avec ce service particulier.

Nous nous engageons à faire de Coinbase l'endroit le plus simple et le plus fiable pour acheter, vendre et gérer votre crypto-monnaie. Si vous souhaitez travailler sur des problèmes de disponibilité difficiles et construire l'avenir de la crypto-économie, rejoignez-nous!

Ce site Web contient des liens vers des sites Web tiers ou d'autres contenus à des fins d'information uniquement («Sites tiers»). Les sites tiers ne sont pas sous le contrôle de Coinbase, Inc. et de ses sociétés affiliées («Coinbase»), et Coinbase n'est pas responsable du contenu de tout site tiers, y compris, mais sans s'y limiter, les liens contenus dans un tiers. Site tiers, ou tout changement ou mise à jour d'un site tiers. Coinbase n'est pas responsable de la transmission Internet ou de toute autre forme de transmission reçue d'un site tiers. Coinbase vous fournit ces liens uniquement à titre de commodité, et l'inclusion de tout lien n'implique pas l'approbation, l'approbation ou la recommandation par Coinbase du site ou de l'association avec ses opérateurs.

Toutes les images fournies dans ce document proviennent de Coinbase.


Incident post-mortem: le 16 novembre 2020 a été initialement publié sur le blog Coinbase sur Medium, où les gens poursuivent la conversation en soulignant et en répondant à cette histoire.

Black Friday Promotion

Cours Crypto
Logo
Enable registration in settings - general