Le problème des clés d'API qui n'expirent jamais
Une clé émise il y a des années, jamais renouvelée et toujours valide aujourd'hui n'est pas une commodité. C'est un risque que personne n'a vraiment examiné depuis des années.
Pour une page d'état publique honnête
Une page de statut existe pour répondre rapidement à une question précise : le service dont je dépends fonctionne-t-il en ce moment, et sinon, le fournisseur est-il déjà au courant ? C'est un objectif restreint et utile, qui ne fonctionne que si la page reflète la réalité d'assez près pour qu'on puisse s'y fier le jour où cela compte vraiment, c'est-à-dire le jour où quelque chose est cassé. Une page de statut restée entièrement verte pendant deux ans d'affilée décrit soit un système réellement sans faille, ce qui est rare, soit une page mise à jour selon un calendrier qui n'a pas grand-chose à voir avec ce que vivent réellement les clients.
La valeur d'une page de statut se concentre presque entièrement dans les moments où il est le moins commode de la mettre à jour honnêtement : pendant un incident en cours, lorsque l'instinct pousse à attendre de voir si le problème se résout vite avant de le reconnaître publiquement. Cet instinct est compréhensible, et il va aussi exactement à l'encontre de ce qui rend une page de statut utile. Un développeur qui consulte une page de statut pendant une panne de son côté veut savoir, le plus tôt possible, si le problème vient de chez lui ou de chez le fournisseur. Une page qui attend, pour confirmer un incident, qu'il soit entièrement compris et résolu répond à cette question trop tard pour être d'une grande utilité.
Nous pensons que l'approche honnête consiste à traiter une page de statut comme un outil opérationnel mis à la disposition des clients, et non comme un support marketing. Cela signifie publier un véritable incident lorsqu'un véritable incident se produit, même avant d'en connaître tous les détails, et le mettre à jour à mesure que la situation s'éclaircit, plutôt que de garder la page verte jusqu'à ce qu'un résumé propre et entièrement résolu soit prêt à être publié. Une reconnaissance précoce et approximative est plus utile à quelqu'un qui débogue son propre système en temps réel qu'une reconnaissance soignée mais tardive.
Cela rejoint une réflexion que nous menons sur l'ensemble du produit, pas seulement sur la communication en cas d'incident : donner aux développeurs des informations sur lesquelles ils peuvent agir, aussi près du temps réel que possible. Les en-têtes de quota présents dans chaque réponse existent pour la même raison qu'une page de statut doit être honnête pendant un incident. Dans les deux cas, il s'agit de ne pas faire attendre quelqu'un jusqu'après coup pour apprendre une chose qui aurait changé ce qu'il faisait sur le moment.
Une page de statut qui affiche de temps en temps une entrée jaune ou rouge ne joue pas contre le fournisseur. Elle prouve que la page est réellement reliée à quelque chose de concret. La page qui devrait davantage inquiéter un client potentiel est celle qui ne montre jamais le moindre défaut, car un système sans aucun incident sur une période significative est si rare que cette absence en dit généralement plus sur la page que sur le système.