Résoudre chaque problème deux fois

Je me souviens avoir lu pour la première fois un concept similaire sur le blog de Joel Spolsky, Joel on Software, où il écrivait en 2007 :

Réparez tout de deux manières

Presque tous les problèmes de support technique ont deux solutions. La solution superficielle et immédiate consiste simplement à résoudre le problème du client. Mais lorsque vous réfléchissez un peu plus, vous pouvez généralement trouver une solution plus profonde : un moyen d’éviter que ce problème particulier ne se reproduise.

Évidemment, je crois que ce principe s’applique à plus qu’au service client.

Un concept connexe sort de la Toyota, le Cinq pourquoi. Citation de Wikipédia :

Cinq Whys est une technique d’interrogation itérative utilisée pour explorer les relations de cause à effet sous-jacentes à un problème particulier. L’objectif principal de la technique est de déterminer la cause première d’un défaut ou d’un problème en répétant la question « Pourquoi ? ». Chaque réponse constitue la base de la question suivante.

Lorsque je m’attaque à un problème observé, qu’il s’agisse de code, de processus métier ou même potentiellement d’un évier qui fuit, j’aime combiner ces principes dans une technique que j’appelle « Résoudre chaque problème deux fois ».

Résoudre chaque problème deux fois

Mais comme pour les cinq pourquoi, ne prenez pas « deux fois » trop littéralement. En pratique, cette technique devrait toujours donner un strict minimum de deux solutions, mais aboutira souvent à 5 solutions pratiques ou plus.

Les étapes que je suis sont :

1. Les cinq pourquoi

Utilisez les cinq pourquoi pour déterminer les causes multiples du problème observé.

2. Résolvez chaque problème au moins une fois

Appliquez le conseil de Joel Spolsky de résoudre chaque cause au moins une fois. Chaque cause devrait avoir une solution immédiate, et la plupart auront également au moins une solution plus profonde.

3. Répétez l’opération pour le processus de résolution de problèmes

Répétez les deux premières étapes, cette fois pour le processus de résolution du problème d’origine observé.

Un exemple du monde réel

Pour illustrer la technique dans la pratique, permettez-moi de décrire un problème que j’ai rencontré récemment.

J’ai voulu faire une mise à jour sur l’un des sites Web que je possède lorsque j’ai rencontré un problème. J’héberge le code de ce site Web sur GitLab, où j’utilise GitLab-CI pour mon intégration et mon déploiement continus. J’ai configuré GitLab-CI pour créer un environnement de révision pour moi chaque fois qu’une demande de fusion est créée.

Lorsque j’ai récemment poussé un changement, j’ai découvert que l’environnement d’examen ne fonctionnait pas, avec le fameux avertissement « Votre connexion n’est pas privée » de Chrome qui se produit lorsqu’un certificat SSL est cassé.

J’utilise Let’s Encrypt pour gérer mes certificats SSL. Parfois, l’obtention d’un nouveau certificat peut prendre quelques minutes, alors j’ai été patient. Mais une demi-heure plus tard, cela ne fonctionnait toujours pas, alors je savais que j’avais un problème légitime.

En fouillant un peu dans mes journaux Kubernetes, j’ai trouvé la cause du problème :

Status:
  Acme:
    Uri:
  Conditions:
    Last Transaction Time:  2019-11-18T08:41:49Z
    Message:                Failed to verify ACME account: acme: urn:ietf:params:acme:error:rateLimited: Your ACME client is too old. Please upgrade to a newer version.
    Reason:                 ErrRegisterACMEAccount
    Status:                 False
    Type:                   Ready

J’ai ensuite regardé dans la configuration de mon cluster Kubernetes et constaté que j’avais besoin de la version 0.5.2 du package cert-manager.

    helm install stable/cert-manager 
        --name cert-manager 
        --version 0.5.2 
        --set ingressShim.defaultIssureName=letsencrypt-prod 
        --set ingressShim.defaultIssureKind=ClusterIssuer 
        --namespace kube-system 
        --tls

À l’époque, c’était 0,11.0, donc clairement, une mise à niveau était de mise. Une fois les causes immédiates et fondamentales déterminées, passons en revue les étapes décrites ci-dessus.

Les cinq pourquoi

Le problème observé était que le certificat SSL est cassé, ce qui nous amène à notre premier pourquoi :

1. Pourquoi le certificat SSL est-il cassé ?

La raison, comme découvert ci-dessus, est que j’utilisais une ancienne version non prise en charge du package cert-manager. Cela conduit au deuxième pourquoi :

2. Pourquoi dois-je mettre à niveau le gestionnaire de certificats ?

Comme vous vous en souvenez peut-être ci-dessus, je demandais explicitement la version 0.5.2 du cert-manager emballer. Il serait peut-être raisonnable de toujours installer la dernière version.

Résoudre chaque problème au moins une fois

Maintenant, je peux passer en revue les deux problèmes que j’ai identifiés ci-dessus et résoudre chacun au moins une fois.

1. Installez la dernière version du gestionnaire de certificats

Cela résoudra le problème immédiat et superficiel et permettra à mon site Web de fonctionner à nouveau.

2. Ne nécessite plus une version spécifique, et installez toujours la dernière

Cela évitera que le problème ne se reproduise à l’avenir. Bien sûr, cela peut ouvrir mon système à un nouveau risque, au cas où une nouvelle version de cert-manager casse quelque chose d’une manière ou d’une autre, mais cela peut être un risque qui vaut la peine d’être pris.

Répétez l’opération pour le processus de résolution de problèmes

Mais n’oubliez pas la dernière étape ! Répétez l’opération pour le processus de résolution de problèmes lui-même. Dans mon exemple, j’ai trouvé deux domaines où je pense que j’aurais pu améliorer le processus de résolution du problème.

1. J’aurais dû remarquer le problème plus tôt

Je ne mets pas à jour MinimalPairs.net très souvent. Pour autant que je sache, ce problème a peut-être attendu pendant des semaines avant que je tente une mise à jour et que je le remarque. Deux solutions possibles viennent à l’esprit pour ce problème. La première consiste à utiliser un simple service de surveillance pour m’alerter lorsque le certificat SSL du site Web ne fonctionne plus.

Deuxièmement, et de manière plus proactive, je pourrais utiliser les mêmes journaux d’erreurs que ceux que j’ai utilisés pour déboguer le problème et les envoyer à un service tel que Sentry.io, qui peut m’avertir immédiatement chaque fois qu’un problème survient.

Dans l’esprit de résoudre chaque problème deux fois, je devrais faire les deux.

2. Il aurait dû être plus facile de trouver les journaux d’échec

Une fois le problème identifié, le débogage a pris plus de temps qu’il n’aurait dû être nécessaire. Cela était en grande partie dû au fait que Kubernetes ne conserve pas tous les journaux dans un emplacement centralisé. Cela pourrait être résolu en mettant en place un système de journalisation centralisé. J’utilise déjà Loggly pour la plupart de mes journaux, je peux donc simplement le configurer pour suivre mes journaux Kubernetes également.

Conclusion

En utilisant ma technique, j’ai proposé cinq solutions potentielles à un simple problème de certificat SSL :

1. Mettre à niveau le gestionnaire de certificats
2. Ne dépendez pas d’une version spécifique du gestionnaire de certificats
3. Mettre en place une surveillance pour le site Web
4. Configurer l’alerte d’erreur
5. Configurer une meilleure journalisation

En appliquant ces cinq solutions, je peux m’assurer que non seulement j’ai résolu le problème immédiat, mais que la santé globale de l’ensemble de mon système s’améliore, et le prochain problème, peu importe où il se produit dans la pile technologique, sera c’est beaucoup plus facile à résoudre.