Statut
Tous les systèmes sont opérationnels.
Une page de statut ne vaut quelque chose que si elle accepte de dire quelque chose de mauvais. Celle ci est mise à jour pendant l'incident et non après, ce qui veut dire que tu verras parfois la mention en cours d'investigation à côté d'un composant alors que nous ne savons toujours pas pourquoi.
Composants
| Composant | État | Objectif | En ce moment |
|---|---|---|---|
| API | Opérationnel | 99,9 pour cent de disponibilité | Aucune erreur au dessus du niveau de référence sur les 24 dernières heures |
| Provisionnement | Opérationnel | 99,5 pour cent des commandes payées aboutissent à un profil fonctionnel | L'heure glissante est au dessus de l'objectif, installation médiane en 41 secondes |
| Paiements | Opérationnel | Autorisation et remboursement automatique en moins de 60 secondes | Le prestataire signale un fonctionnement normal et les remboursements partent à l'heure |
| Données de couverture | Opérationnel | Chiffres publiés rafraîchis chaque jour, plancher de 25 mesures respecté | Le dernier rafraîchissement est terminé et aucun pays n'est masqué pour cause de données trop anciennes |
| Support | Opérationnel | Première réponse en moins de 60 secondes, 24 heures sur 24 | La file est dans l'objectif dans toutes les langues couvertes |
Opérationnel veut dire que le composant tient son objectif sur l'heure glissante. Ce n'est pas une promesse sur l'heure suivante.
99,5 %
objectif de réussite du provisionnement
60 s
remboursement automatique quand le provisionnement échoue
30 min
durée d'incident qui déclenche un post mortem public
72 h
délai pour publier ce post mortem
Ce que signifie chaque état
| État | Ce que cela signifie | Ce que nous faisons |
|---|---|---|
| Opérationnel | Le composant tient son objectif sur l'heure glissante | Rien. C'est l'état normal et ce n'est pas une promesse sur l'avenir |
| Performances dégradées | Cela fonctionne, mais plus lentement ou moins bien que l'objectif | Nommé sur cette page, clients touchés contactés, avoirs appliqués sans demande |
| Panne partielle | En échec pour un groupe identifiable, par exemple un opérateur ou une région | Le groupe est nommé, les achats sont bloqués là où ils échoueraient, les remboursements partent automatiquement |
| Panne majeure | En échec de façon générale | Un responsable d'incident est désigné et une mise à jour tombe au moins toutes les 30 minutes jusqu'à la résolution |
| Maintenance | Travaux prévus avec une fenêtre connue | Annoncés au moins 72 heures à l'avance et programmés sur l'heure la moins chargée |
Il n'existe aucun état qui veuille dire ça va, sans doute. Soit le composant tient son objectif, soit il est nommé sur cette page.
La politique en cas d'incident
Deux engagements portent l'ensemble, et les deux sont inconfortables à dessein. Le premier : nous prévenons les clients touchés avant qu'ils s'en rendent compte. Le second : tout ce qui dépasse 30 minutes donne lieu à un post mortem écrit et publié sous 72 heures.
Le post mortem nomme des systèmes et des décisions, pas des salariés, et il est rédigé par la personne qui était d'astreinte, pas par un manager qui raconte quelqu'un d'autre.
Si nous allons dépasser le délai de 72 heures, nous publions le retard et sa raison dans les 72 heures, parce qu'un délai manqué et annoncé tard, cela fait deux échecs.
- La détection est automatique à partir des taux de réussite du provisionnement et d'autorisation des paiements, donc un incident commence quand les chiffres bougent, pas quand quelqu'un se plaint
- L'état du composant sur cette page change dans les cinq minutes qui suivent la déclaration, avant que la cause soit connue
- Un responsable d'incident pilote la réponse et une autre personne s'occupe de la communication, pour qu'aucune des deux tâches n'étouffe l'autre
- Les clients touchés sont identifiés et contactés, avec un avoir déjà appliqué là où le service était dégradé, plutôt que proposé sur demande
- Les achats sont bloqués sur tout parcours dont nous savons qu'il échouerait, parce qu'encaisser un paiement que nous devrons rembourser est pire que perdre la vente
- Pendant une panne majeure, une mise à jour tombe au moins toutes les 30 minutes, même quand la mise à jour dit que nous ne savons toujours pas
- Dans les 72 heures après la résolution, un post mortem est publié avec une chronologie, l'impact client en chiffres, la cause, et chaque correctif avec un responsable et une date
Pourquoi l'objectif n'est pas cent pour cent
Parce qu'un réseau est dans la boucle et que cent pour cent serait un mensonge. Un objectif de provisionnement de 99,5 pour cent dit tout haut qu'environ cinq commandes sur mille échoueront quelque part entre le paiement et le profil fonctionnel.
Ce qui compte, c'est que le chemin de ces cinq là soit conçu. Le remboursement part en moins de 60 secondes sans ticket, le message explique ce qui s'est passé et quoi essayer à la place, et personne n'a à décider si le client le mérite.
La même logique vaut pour la couverture. Quand un réseau partenaire est saturé dans un territoire que nous couvrons avec plusieurs opérateurs, nous te déplaçons plutôt que d'ouvrir un incident, et la note indique quel changement a été fait.
Quand il n'y a qu'un seul réseau et qu'il passe une mauvaise journée, nous le disons sur la page pays. Nos pages de couverture publient la médiane, le dixième le plus lent et le nombre de mesures exactement pour cette raison.
Historique des incidents
Aucun incident de plus de 30 minutes n'a été déclaré sur la période couverte.
Cette phrase vaut exactement ce que vaut notre volonté de la changer, et c'est pour cela que la politique ci dessus est écrite avec autant de détail. Chaque post mortem passé reste publié définitivement au lieu de disparaître au bout de quatre vingt dix jours.