Ceci est la dernière partie de la série décrivant comment nous augmentons la disponibilité de nos services dans Citymobil (vous pouvez lire la partie précédente
ici ). Je vais maintenant parler d'un autre type de pannes et des conclusions que nous en avons tirées, de la façon dont nous avons modifié le processus de développement, de l'automatisation que nous avons introduite.
1. Mauvaise version: bug
Il s'agit du type de panne et d'incident le plus désagréable. Le seul type qui ne présente aucun symptôme visible, à part les plaintes des utilisateurs finaux ou des utilisateurs professionnels. C'est pourquoi un tel incident, en particulier un petit, peut rester inaperçu en production pendant un certain temps.
Tous les autres types de pannes sont plus ou moins similaires à "Bad release: 500 internal server errors". La seule chose est qu'ils ne sont pas déclenchés par une version, mais plutôt par une charge de travail, une opération manuelle ou un problème de service externe.
Pour décrire la méthode de gestion de ce type de pannes, rappelons une vieille blague:
Un mathématicien et un physicien ont la même tâche: faire bouillir de l'eau. On leur donne quelques outils auxiliaires: une cuisinière, une bouilloire, un robinet avec de l'eau, des allumettes. Ils remplissent à tour de rôle la bouilloire avec de l'eau, ouvrent le gaz et commencent à chauffer la bouilloire. Ensuite, la tâche est simplifiée: on leur donne une bouilloire remplie d'eau et une cuisinière déjà allumée. La tâche est la même: faire bouillir de l'eau. Le physicien met la bouilloire sur la cuisinière. Le mathématicien vide la bouilloire, coupe le gaz et dit: "Le problème est réduit à un problème déjà résolu." © anekdotov.net
Ce type de panne doit être réduit à "Mauvaise version: 500 erreurs de serveur interne" à tout prix. Idéalement, les bogues devraient être enregistrés de la même manière que 500 erreurs. Cependant, bien sûr, vous ne pouvez pas enregistrer l'événement d'un bogue, car si vous le pouviez, vous ne feriez pas de bogue en premier lieu.
L'une des idées pour suivre un bogue est de rechercher des traces dans la base de données. Ces traces nous permettent de voir qu'il y a un bug et d'envoyer des alertes. Comment pouvons-nous y contribuer? Nous avons commencé à étudier chaque gros bogue et à trouver des solutions: quel type de surveillance / alerte SMS peut-on créer pour que ce bogue se révèle immédiatement comme une erreur 500? Voici quelques exemples.
1.1. Exemple d'une panne causée par un bogue
Tout à coup, nous recevions une énorme quantité de plaintes de nos utilisateurs: les commandes payées via Apple Pay ne pouvaient pas être fermées. Nous avons commencé notre enquête; le problème a été reproduit dans l'environnement de test. La cause première a été trouvée: nous avons mis à jour le format de la date d'expiration des cartes de crédit car il a été modifié par un service de traitement des paiements, mais nous ne l'avons pas fait correctement pour les paiements via Apple Pay; par conséquent, tous les paiements Apple Pay ont été refusés. Nous l'avons corrigé dès que nous avons eu connaissance du problème, l'avons déployé et le problème a disparu. Cependant, ce problème était en direct pendant 45 minutes.
À la suite de ce problème, nous avons surveillé un certain nombre de paiements Apple Pay infructueux et créé des alertes SMS et IVR avec un seuil différent de zéro (car certains paiements infructueux sont considérés comme normaux par le service; par exemple, si un client n'a pas d'argent sur son compte) ou sa carte de crédit est bloquée). Depuis ce moment, nous découvrions immédiatement le franchissement du seuil. Si une nouvelle version pose un problème dans le traitement d'Apple Pay, nous le découvrirons immédiatement en raison de la surveillance et de la restauration de la version dans les 3 minutes (le processus de restauration manuelle est décrit dans l'un des articles précédents). Auparavant, c'était 45 minutes de temps d'arrêt partiel, et maintenant c'est 3 minutes. Profit!
1.2. Autres exemples
Un bug dans la liste de commande. Nous avons déployé une optimisation de la liste des commandes dans l'application pilote. Le code avait un bug. En conséquence, parfois, les conducteurs ont vu la liste de commande vide. Nous avons découvert ce bogue par hasard: l'un des ingénieurs jouait avec l'application pilote et est tombé sur ce problème. Nous avons rapidement identifié la mauvaise version et elle a été immédiatement annulée. Par conséquent, nous avons créé un graphique d'un nombre moyen de commandes dans la liste sur la base des informations de la base de données. Nous avons ensuite examiné ce graphique rétrospectivement d'un mois à l'autre. Nous avons remarqué un ravin récent provoqué par ce bogue et créé une alerte SMS via une requête SQL. Il construit ce graphique lorsqu'un nombre moyen de commandes dans la liste franchit le seuil inférieur qui a été défini en fonction du minimum pour le mois en cours.
Un bug dans cachback. Nous modifions la logique de remise de cashback de l'utilisateur. Entre autres, nous l'avons envoyé au mauvais groupe de clients. Le problème a été résolu, le graphique du cashback donné a été créé; nous avons vu une augmentation drastique et nous avons également remarqué que cela ne s'était jamais produit auparavant, et avons créé une alerte SMS avec un seuil approprié.
Encore une fois, un bug dans les paiements. La nouvelle version a provoqué le bug - il faudrait une éternité pour passer une commande, le paiement par carte ne fonctionnait pas, les chauffeurs ont demandé aux clients de payer en espèces. Nous avons découvert le problème grâce aux plaintes du centre d'appels. Nous avons déployé un correctif et créé une alerte pour l'heure de clôture des commandes avec des seuils, découverte via l'analyse des graphiques historiques.
Comme vous pouvez le constater, nous utilisons la même approche pour traiter tous les incidents de ce type:
- Nous découvrons un problème.
- Nous le résolvons et trouvons un bogue dans le code.
- Nous le réparons.
- Nous identifions les traces dans la base de données (des traces peuvent également être trouvées dans les journaux du serveur Web ou Kibana) qui peuvent pointer vers les signes du problème.
- Nous construisons un graphique de ces traces.
- Nous remontons le temps et regardons les hauts et les bas du graphique.
- Nous sélectionnons un bon seuil pour une alerte.
- Lorsque le problème se pose à nouveau, nous le découvrons immédiatement via une alerte SMS.
Ce qui est bien avec cette méthode: un graphique et une alerte résolvent tout le grand groupe de problèmes (exemples de groupes de problèmes: les commandes ne peuvent pas être fermées, les bonus supplémentaires, les paiements Apple Pay ne passent pas, etc.)
Finalement, nous avons mis en place des alertes et une surveillance pour chaque gros bug dans le cadre de notre culture d'ingénierie. Afin de ne pas perdre cette culture, nous l'avons un peu formalisée. Nous avons commencé à nous forcer à créer un rapport pour chaque panne. Le rapport est un formulaire rempli de réponses aux questions suivantes: cause profonde, comment nous l'avons corrigé, impact sur les entreprises, plats à emporter. Tous les champs sont obligatoires. Nous avons donc dû conclure si cela nous plaisait ou non. Ce changement de processus était évidemment inscrit dans les choses à faire et à ne pas faire.
2. Kotan
Notre niveau d'automatisation des processus augmentait et nous avons décidé qu'il était temps de créer une interface Web qui montrerait l'état actuel du processus de développement. Nous avons appelé cette interface Web «Kotan» (du mot russe «roll», «to roll out» :-)
"Kotan" possède les fonctionnalités suivantes:
Liste des incidents . Il contient la liste de toutes les alertes déclenchées dans le passé - selon celle qui a nécessité une réaction humaine immédiate. Pour chaque incident, nous enregistrons l'heure à laquelle il a commencé, l'heure à laquelle il s'est terminé (s'il est déjà terminé), un lien vers un rapport (si l'incident est terminé et il y a un rapport) et le lien du guide d'alerte pour voir quel type d'alerte cet incident appartient à.
Le répertoire d'alertes . Il s'agit pratiquement d'une liste de toutes les alertes. Pour être plus clair, la différence entre une alerte et un incident est la suivante: l'alerte est comme une classe, tandis que l'incident - est un objet. Par exemple, "le nombre de 500 erreurs est supérieur à 1" est l'alerte. Et "le nombre de 500 erreurs est supérieur à 1 et elles se sont produites à cette date, à cette époque, ont duré aussi longtemps" - est un incident. Chaque alerte est ajoutée manuellement au système via le processus décrit ci-dessus après la résolution d'un problème spécifique qui n'a jamais été détecté par le système d'alerte auparavant. Une telle approche itérative garantit un faible risque de fausses alertes positives (qui ne nécessitent aucune action). Le répertoire contient un historique complet des rapports pour chaque type d'alerte; qui aide à diagnostiquer un problème plus rapidement: vous recevez une alerte, vous allez dans "Kotan", cliquez sur le répertoire, consultez toute l'histoire et vous faites une idée de l'endroit où plonger. La clé du succès du dépannage est d'avoir toutes les informations à portée de main. Le lien vers le code source de l'alerte (pour savoir avec certitude de quelle situation cette alerte vous signale). Une description écrite des meilleures méthodes actuelles de lutte contre cette alerte.
Rapports Ce sont tous les rapports de l'histoire. Chaque rapport contient des liens pour tous les incidents auxquels il est associé (parfois les incidents viennent en groupes; la cause première est la même, et nous créons un rapport pour tout le groupe), la date à laquelle ce rapport a été rédigé, l'indicateur de confirmation de la solution du problème et la plupart surtout: la cause profonde, comment elle a été corrigée, l'impact sur les entreprises, les plats à emporter.
Liste des plats à emporter . Chaque repas à emporter a une note indiquant si elle a été mise en œuvre, la mise en œuvre est toujours à venir, ou elle n'est pas nécessaire (avec une explication pourquoi pas).
3. Qu'est-ce qui a changé dans le processus de développement logiciel?
Un élément essentiel de l'amélioration de la disponibilité est un processus de développement logiciel. Le processus est en constante évolution. L'objectif de tels changements est de réduire les risques d'incidents. Les décisions de modifier le processus ne doivent pas être prises de manière abstraite, mais plutôt basées sur l'expérience, les faits et les chiffres. Le processus ne doit pas être construit de manière directionnelle vers le bas, mais de bas en haut avec la participation active de tous les membres de l'équipe, car de nombreux chefs de l'ensemble de l'équipe valent mieux qu'un chef de manager. Le processus doit être suivi et surveillé; sinon, cela n'a aucun sens. Les membres de l'équipe doivent se corriger mutuellement en cas de divergence: qui d'autre le ferait pour eux? Il doit y avoir une automatisation maximale en prenant soin des fonctions principales, car un être humain fait constamment des erreurs, en particulier dans le travail créatif.
Afin d'être sûr que chaque incident a des points à retenir, nous avons fait ce qui suit:
- Chaque alerte bloque automatiquement les versions.
- Lorsque nous recevons une alerte de fermeture (un message texte indiquant que l'incident est terminé), nous ne débloquons pas immédiatement les versions, mais nous proposons plutôt de créer un rapport d'accident.
- Un rapport doit contenir les informations suivantes: la cause profonde d'un accident, comment il a été résolu, l'impact sur l'entreprise, les plats à emporter.
- Le rapport est rédigé par l'équipe qui a diagnostiqué l'accident. Ceux armés des informations complètes sur l'accident.
- Les versions sont automatiquement bloquées jusqu'à ce qu'un tel rapport soit créé et approuvé. Cela motive l'équipe à se concentrer rapidement et à créer un rapport juste après la résolution d'un accident.
- Le rapport doit être approuvé par une personne qui ne fait pas partie de l'équipe, pour s'assurer qu'il contient toutes les informations nécessaires à sa compréhension.
Ce faisant, nous avons, d'une part, atteint l'autodiscipline en sauvegardant chaque incident dans l'histoire, et d'autre part - fourni un contrôle automatisé. Il est désormais impossible de ne pas tirer de conclusions ou de ne pas rédiger de rapport.
4. Au lieu d'un épilogue
Au lieu d'un épilogue, permettez-moi de résumer rapidement ce que nous avons changé dans le processus de développement logiciel afin de réduire un certain nombre de voyages perdus.
Merci d'avoir lu jusqu'à la fin. Bonne chance à votre entreprise! Je vous souhaite moins de commandes, transactions, achats, voyages perdus et tout ce qui est crucial pour vous!