Table des Matières
Il y a un mois, nous étions plongés dans des problèmes de serveur qui ont causé des problèmes de données sporadiques, des pannes et des problèmes de performance pour presque tous nos clients au cours d'une semaine entière. C'était extrêmement frustrant pour notre équipe, non seulement parce que c'était un problème très difficile à résoudre, mais surtout parce que cela signifiait que nos clients ne recevaient pas le service qu'ils méritaient.
Gérer ces types de problèmes peut être délicat, surtout quand les problèmes n'affectent pas nécessairement tous les clients.
Affichez-vous un avis aux tous clients, même si seulement 50 % d'entre eux au hasard rencontrent des problèmes ? Partagez-vous tout ce qui se passe ? Ou seulement quand il y a des progrès significatifs ? Quel devrait être le ton ? Devriez-vous offrir des remboursements ?
Évidemment, il y a une multitude de variables qui pourraient entrer en jeu, voici comment nous gérons généralement les pannes et les interruptions de serveur et comment nous aimons communiquer avec nos clients pendant ces périodes.
Procédure d'escalade
Idéalement, vous disposez d'un système de surveillance en place. À un niveau basique, cela peut être fait avec un simple ping pour s'assurer qu'une URL donnée est accessible. À un niveau plus approfondi, surveiller des éléments comme la charge de la base de données, les erreurs d'application et les temps de réponse peuvent contribuer à détecter les problèmes avant que avant ce ne soit un problème notable pour vos clients.
En plus de la surveillance système, si vous avez plus d'un ingénieur, avoir un horaire de garde en vaut la peine. Alerter chaque ingénieur chaque fois qu'il y a un problème est stressant et n'est pas une bonne utilisation du temps de personne.
La combinaison de ces deux éléments vous permet de mettre en place une procédure d'escalade solide.
Étape 1 : Notification de chat général
Lorsqu'un problème potentiel arrive, que ce soit via la surveillance système ou le support client, il est d'abord signalé à notre canal #backend dans Slack, en mentionnant @ tous les ingénieurs. Comme nos ingénieurs sont répartis dans plusieurs fuseaux horaires dans différentes parties du monde, la plupart du temps quelqu'un est en ligne.
Il est préférable que quelqu'un qui est réellement réveillé traite un problème au lieu d'avoir à réveiller quelqu'un.
Si un ingénieur est en ligne, il peut confirmer s'il y a un problème ou non et faire avancer le processus.
Étape 2 : Message texte
S'il n'y a pas d'ingénieur en ligne et que le problème semble critique, la surveillance système intervient la plupart du temps et envoie un message texte à l'ingénieur de garde qui, qu'il soit réveillé ou non, se connectera et commencera à travailler sur le problème.
Étape 3 : Appel
Dans le scénario où la surveillance système n'a pas détecté le problème ou qu'un message texte n'a clairement pas fonctionné, alors quiconque a remarqué le problème (généralement quelqu'un du service client) appellera l'ingénieur de garde.
Généralement après tout cela, l'équipe quelqu'un est consciente du problème et travaille sur une solution.
Communiquer le problème
Une fois que vous avez vérifié qu'il y a effectivement un problème, publiez un message de statut. Notre approche préférée est que tout le monde voie le message de statut dès que possible au lieu d'attendre et d'essayer de notifier un petit groupe de personnes.
La raison en est qu'il est généralement trop difficile de déterminer l'étendue d'un problème au départ. Nous préférons dire à tout le monde qu'il pourrait y avoir un problème, même s'ils ne l'éprouvent pas, plutôt que de laisser un client se demander s'il se passe quelque chose. Notre règle personnelle est d'être ouvert et honnête dès le départ.
Nous trouvons que vous ne pouvez pas sur-communiquer ces choses.
Nous commençons par publier sur notre page de statut, qui publie également sur notre compte Twitter et crée un message dans le tableau de bord Baremetrics.
Support pendant une panne
Lors d'une panne ou d'une interruption, notre objectif principal est de communiquer et de répondre aux clients aussi rapidement que possible. Cela signifie que notre équipe d'assistance donne une priorité plus élevée aux tweets, emails et tickets liés à la panne.
Moins nos clients doivent passer de temps à se demander si quelque chose ne va pas et quand si cela sera réparé, mieux c'est.
Lors de notre panne il y a un mois, après une semaine presque complète de hauts et de bas sporadiques, nous avons décidé que répondre aux demandes entrantes concernant la panne ne suffisait pas. J'ai en fait envoyé une « Lettre du PDG » à tous nos clients. Assez de gens avaient connu des problèmes pour que je mette à jour tout le monde en bloc et explique ce qui s'était passé et comment nous le réparions. Encore une fois, la communication est la clé pour garder la confiance de vos clients et donc leur entreprise.
Comme vous l'avez probablement remarqué, au cours de la semaine écoulée, il y a eu un certain nombre de problèmes avec votre tableau de bord. Vous avez probablement vu des chutes dans certaines métriques (ce qui causerait des pics dans d'autres). Généralement, vous les remarqueriez le matin.
D'abord, je suis désolé. Sérieusement. Peu de choses font monter mon niveau de stress plus que nos clients ne voyant pas les données qu'ils attendent et méritent.
En fin de compte, ces problèmes se sont réduits à nos serveurs qui prenaient du retard dans les calculs alors que nous avions presque doublé le nombre de points de données que nous traitons au cours des dernières semaines.
Il y a une séquence d'événements qui se produisent pour importer, traiter et calculer une métrique donnée et quand une chose prend du retard, cela peut parfois causer un effet domino qui fait que d'autres chiffres prennent du retard.
Deuxièmement, nous travaillons jour et nuit pour résoudre ce problème et améliorer les vitesses de traitement, ainsi que pour mettre en ligne de nouveaux serveurs afin de gérer l'arriéré.
Nous avons en fait travaillé ces derniers mois sur une infrastructure entièrement nouvelle qui fonctionne de manière beaucoup plus efficace que notre système actuel et nous commencerons à la déployer au cours des deux prochaines semaines (plus d'informations à ce sujet bientôt).
Au final, vous nous faites confiance avec vos données commerciales pour vous aider à prendre des décisions commerciales précises et quand nous ne répondons pas à ces attentes, ce n'est simplement pas acceptable.
Notre espoir est d'être complètement à jour avec le traitement dans les 24 prochaines heures.
Si vous avez des questions, répondez simplement à cette note. Je serai heureux de répondre ou d'écouter toute question ou préoccupation.
Après la tempête
Une fois que vous avez dépassé la panne, rédigez une autopsie. Incluez un aperçu de ce qui s'est passé, quand cela s'est produit, comment cela s'est produit et ce que vous faites pour empêcher que cela ne se reproduise.
La réalité est que la plupart des clients ne liront pas cela. Ils ne sont tout simplement pas si intéressés par les détails importants. Cependant, pour les clients qui un entretien en tête-à-tête ? s'en soucient...ils vraiment s'en soucient vraiment et cela contribuera grandement à rétablir la confiance dans votre produit.
Qu'en est-il des remboursements pour les temps d'arrêt ?
Nous ne faisons pas de remboursements automatiques pour les temps d'arrêt. La seule fois où vous devriez émettre des remboursements préemptifs à tout le monde est si vous avez un accord de niveau de service (SLA) en place qui garantit un certain niveau de performance ou de disponibilité.
Cela dit, vous ne devriez pas non plus être avare. Si quelqu'un est clairement contrarié par le temps d'arrêt, offrez-lui un remboursement complet du mois précédent. Cela vaut sans équivoque le coup.
Porter le poids de la frustration des clients
Habituellement, vous et votre équipe vous souciez beaucoup plus d'une panne que vos clients. Oui, cela les ennuiera et les frustrera, mais le stress vous que vous ressentez est essentiellement le poids tous de la frustration de vos clients. Cela peut être assez intense.
Résistez à l'impulsion de micromanager. Concentrez-vous sur le maintien de vos clients informés et laissez votre équipe d'ingénierie faire son travail.
Nous avons constaté que la grande majorité des clients comprennent les problèmes de serveur. Cette « Lettre du PDG » que j'ai envoyée à près de 800 personnes a entraîné exactement deux personnes frustrées. Le reste des réponses a été incroyablement favorable et a donné un bon coup de pouce à moi et à l'équipe.
Outils
Voici quelques-uns des outils que nous utilisons ou avons utilisés au fil des ans pour aider à gérer chaque aspect de ce processus :
- StatusPage — Alimente notre page d'état et nos notifications dans l'application
- Honeybadger — Surveillance des erreurs et du temps de fonctionnement et notifications
- PagerDuty — Planification et procédures d'escalade à la demande
- Datadog — Surveillance de l'infrastructure et alertes
- Intercom — Email, chat et support général pendant les pannes
