Suite à notre article précédent Depuis hier, nous avons souhaité partager les actions que nous allons entreprendre sur la base de notre analyse initiale des causes profondes.

Causes profondes primaires et secondaires

En examinant notre chronologie des événements survenus pendant la panne, nous avons découvert qu'il y avait deux problèmes :

1. Notre approche de basculement pour les problèmes DNS
2. La qualité du suivi pour évaluer l'expérience client de bout en bout

Comme nous l'avons déjà évoqué, nous privilégions une architecture multi-maître plutôt qu'une architecture de basculement afin d'assurer une disponibilité continue. Cette approche, bien que nécessitant des investissements importants en conception système, présente les avantages suivants : une capacité prévisible en cas de dégradation, une automatisation accrue et des modifications progressives plus faciles et plus sûres. Cependant, nous n'avions pas d'architecture multi-maître pour nos systèmes DNS. Nous avons donc dû effectuer un basculement manuel vers un fournisseur secondaire pendant la panne.

Mesurer l'expérience client de bout en bout est toujours un défi en cas de problèmes DNS. Après tout, si un client ne peut pas communiquer avec vos systèmes, comment connaître son expérience ? Nous nous appuyons fortement sur la surveillance et les alertes pour chaque élément des services PagerDuty. Nos équipes d'ingénieurs veillent à ce que chaque aspect de l'expérience client corresponde aux attentes de nos clients. Lors de cette panne, nous n'avons pas pu diagnostiquer correctement les problèmes rencontrés par nos clients, car ceux-ci n'étaient pas en mesure d'accéder à nos systèmes. Cela a allongé le délai de résolution pour nos clients.

Actions de suivi

Dans les semaines à venir, nous envisageons d'apporter plusieurs améliorations à notre infrastructure, à nos processus et à notre automatisation. Ces améliorations contribueront à réduire le risque de panne système pour les mêmes causes profondes identifiées.

Adopter une approche multi-maître pour le DNS

Notre priorité absolue est actuellement de repenser et de mettre en œuvre une nouvelle architecture DNS permettant l'utilisation de plusieurs fournisseurs DNS dans une approche multi-maître. Nous mettons à jour nos outils et notre automatisation internes afin de garantir que nos enregistrements DNS destinés aux clients externes utilisent plusieurs fournisseurs DNS et que nos serveurs internes utilisent un système similaire.

Audit de tous les TTL DNS

Nos clients utilisent plusieurs points de terminaison pour interagir avec PagerDuty: notre site web, nos API et nos applications mobiles. Afin de garantir une expérience cohérente sur l'ensemble de ces points, nous allons auditer les TTL DNS de nos zones, y compris les enregistrements NS et SOA pour chaque zone.

Manuel d'exécution pour le vidage du cache DNS

De nombreux fournisseurs DNS publics offrent la possibilité de vider proactivement les caches lorsque des enregistrements sont modifiés. Par exemple : Google Cette fonctionnalité est disponible via une interface web. Nous examinerons les principaux fournisseurs DNS de nos clients et déterminerons les étapes à suivre pour chaque fournisseur afin de vider proactivement les caches et de fournir des enregistrements à jour plus rapidement, lorsque cela est possible.

Améliorer la surveillance des utilisateurs réels

Nous utilisons une combinaison de systèmes de surveillance internes et de fournisseurs externes. Lors de cette panne, nous avons utilisé ces systèmes pour évaluer l'impact client et déterminer la meilleure priorité pour les étapes de résolution. Malheureusement, la plupart de nos systèmes internes sont conçus pour offrir une vue d'ensemble de notre infrastructure et ne décrivent pas correctement notre expérience utilisateur de bout en bout, en particulier pour nos clients des côtes est et ouest des États-Unis. Nous investirons des ressources supplémentaires dans une surveillance globale qui offre une vue externe et client de nos systèmes et de notre offre de services globale. Cela inclut notre site web, nos API, nos expériences mobiles et notre expérience de notification.

Améliorer la priorisation des étapes de résolution

Chez PagerDuty, nous utilisons une architecture orientée services pour prendre en charge les multiples fonctionnalités utilisées par nos clients. Dans la plupart des cas, une interruption de service n'affecte qu'une partie de notre service. L'indisponibilité d'un composant central comme le DNS a impacté plusieurs de nos services. Lors de la prochaine reprise de nos services, nous devons pouvoir prioriser les services les plus critiques et les plus importants pour nos clients.

Améliorer le processus de réponse multi-équipes

Comme indiqué dans la section précédente, plusieurs équipes sont constamment d'astreinte pour assurer le bon fonctionnement de PagerDuty . Bien que nous utilisions notre propre produit pour nous aider dans nos efforts d'orchestration du personnel, nous ne disposions pas de tous les outils nécessaires pour certaines équipes concernées. Nous prévoyons de mettre en place des processus et d'améliorer nos meilleures pratiques afin que chaque équipe puisse résoudre efficacement les problèmes de ses services.

Conclusion

Vendredi dernier a été une journée difficile pour la quasi-totalité des ingénieurs d'astreinte. Chez PagerDuty, nous sommes fiers de fournir un service sur lequel des milliers de clients comptent. Nous n'avons pas répondu aux attentes élevées que nous nous étions fixées et nous prenons des mesures cruciales pour améliorer continuellement la fiabilité et la disponibilité de nos systèmes. Fort de cette expérience, je suis convaincu que nous fournirons un service encore plus fiable, disponible lorsque nos clients en auront le plus besoin.

Comme toujours, si vous avez des questions ou des préoccupations, n'hésitez pas à me contacter ou à contacter notre équipe d'assistance à support@pagerduty.com