Comment gérer la communication pendant les temps d'arrêt des applications?

J'ai eu beaucoup d'expériences récemment avec les temps d'arrêt des applications, à la fois des fournisseurs et de mes propres applications. Cela m'a fait réfléchir et, du mieux que je puisse sur Google, il n'y a pas vraiment de moyen standard ou bon de gérer la communication avec les clients pendant les incidents.

J'ai vu cela gérer de nombreuses façons de l' approche "blâmer tout le monde sauf nous" à l' approche "nous avons foiré et nous sommes désolés" .

Donc, mes questions sont ... lorsque vous bousiller avec une application et provoquer des temps d'arrêt:

1. Admettez-vous la faute immédiatement? (Devriez-vous légalement?)
2. Combien d'informations donnez-vous au client concernant ce qui ne va pas? ("Un problème" par rapport à "Une erreur de syntaxe de code dans l'une de nos requêtes SQL")
3. Revenez-vous avec un plan de prévention de suivi, ou laissez-vous simplement à "cela a été résolu"?
4. Fournissez-vous des mises à jour en temps réel? À quelle fréquence? Via Twitter ou un site Web public?

Y a-t-il d'autres bonnes pratiques que vous avez trouvées réussies?

Voici ce que je fais:

• Indiquez très clairement quelles sont les conséquences (en ce moment et dans un avenir immédiat). Souligner les conséquences permanentes probables ou leur absence (perte de données, perte d'heures de travail).
• Gardez le ton très neutre. Ne dépensez pas d'énergie en blâme / culpabilité. Idéalement, cela traduit "je veux vous donner des informations mais mon attention est également nécessaire ailleurs".
• Votre notification sera transmise à un grand nombre de personnes, assurez-vous que votre PDG comprend l'essentiel dans le premier demi-paragraphe. Habituellement, je fournis un «résumé». Les détails techniques peuvent fournir des informations générales à d'autres techniciens.
• Fournissez les coordonnées (de préférence quelqu'un qui a le temps dans le feu de l'action) pour d'autres questions et demandez de la patience dans la même phrase (cela fonctionne souvent).
• Promettez des mises à jour lorsque la situation change.

Envoyez des mises à jour quand il y a de bonnes nouvelles, avant l'heure de fermeture du bureau ("tout le personnel continuera toute la nuit" - comptez les fuseaux horaires si nécessaire) et encore autour de l'heure d'ouverture du bureau.

Une fois le problème résolu (pour toute définition de ce mot), envoyez:

• Un résumé comprenant le calendrier des conséquences
• Les actions / changements pris à court terme et prévus pour l'avenir ("leçons apprises"); basé sur:
• Analyse technique des causes profondes

Gardez tous les appels pour blâme, culpabilité ou lynchage dans des courriers séparés, de préférence après un certain temps de recharge.

Ne vous engagez à rien pendant le temps d'arrêt, sauf si vous êtes vraiment, vraiment sûr de pouvoir livrer. D'une manière ou d'une autre, deux situations de «mauvaises nouvelles» distinctes sont pires qu'une longue.

Je préfère utiliser un support où une notification est poussée sur chaque message (mail, Twitter, ..)

La chose la plus importante que j'ai trouvée en tant que fournisseur de services et en tant qu'utilisateur de services est la responsabilité proactive. Il ne sait pas ce que vous dites, mais quand (combien de temps) vous le dites.

Si vous êtes averti qu'un problème est survenu et a été résolu (ou est en cours de traitement), c'est bien mieux que de découvrir le problème vous-même et d'essayer de contacter le fournisseur pour savoir ce qui se passe dans le monde. Cela aide également à blâmer le jeu et économise beaucoup de temps de dépannage (est-ce nous ou est-ce eux?).

En ce qui concerne les détails, je trouve que donner un simple résumé de ce qui s'est passé est agréable à moins que les utilisateurs ne demandent spécifiquement plus d'informations. Il y aura des gens qui veulent toujours autant de détails que possible, mais la plupart des gens veulent juste que les choses fonctionnent (même si elles sont très techniques).

Enfin, être en mesure d'expliquer les mesures que vous avez prises pour que cela ne se reproduise pas contribue grandement à la bonne volonté et à la confiance futures.

Sans en savoir beaucoup plus sur votre application particulière, comment elle est autorisée, le domaine dans lequel vous fournissez des services, etc. il est impossible de répondre à vos questions sans deviner.

1. Reconnaître ses propres erreurs est généralement la voie à suivre. Consultez votre avocat si votre domaine est celui où de nombreuses lois, SLA ou contrats méticuleux s'appliquent.
2. C'est une fine ligne entre trop et trop peu de détails. En général, suffisamment de détails pour qu'un utilisateur commun ait l'impression de comprendre.
3. S'il s'agit d'une petite erreur rapidement corrigée; ne t'y attarde pas. Si c'était une grosse erreur, vous avez un contrôle des dégâts à faire.
4. Petites erreurs, prévenez quand c'est en panne et quand c'est réparé. De grosses erreurs, prévenez lorsque des étapes importantes vers la solution ont été atteintes.

Je préfère que mes fournisseurs fournissent trop d'informations sur les temps d'arrêt. Mais de nombreuses entreprises ne peuvent tout simplement pas ou sont fermées par les avocats. Consultez votre avocat / assurance en cas de doute.