C'est le quatrième en une série de messages sur l’augmentation de la disponibilité globale de votre service ou système.

Avez-vous déjà eu paginé , et on sait tout de suite que ce problème n'est pas comme le les 15 derniers problèmes opérationnels auxquels vous avez été confrontés cette semaine ? Que ce problème est spécial et qu'il est vraiment très grave ? Vous savez, ce genre de problème qui vous préoccupe au plus profond de votre subconscient depuis des semaines et dont vous espérez qu'il ne se produira jamais ?

Et bien, que faites-vous lorsque cela se produit ? Souvent, dans ces situations de forte pression, vous aurez un très bref laps de temps (disons quelques minutes) avant qu'un problème ne passe de « assez grave, mais nos clients nous pardonneront et certains ne le remarqueront peut-être même pas » à simplement catastrophique. Scout ou scoute , il vous suffirait d'ouvrir la soupape de décharge de pression que vous avez préparée au préalable et d'empêcher le problème de devenir incontrôlable.

Construire des soupapes de décharge de pression

Lors de la création ou de la maintenance de l'un des systèmes ou services que vous possédez, vous êtes-vous déjà dit : « Vous savez, si la situation X se produisait, aussi improbable soit-elle, nous serions vraiment en difficulté » ? La situation X pourrait être n'importe quel scénario de catastrophe hypothétique pour votre système donné : les magasins de données maître et esclave tombent en panne simultanément ; tous vos clients décident de vous inonder de leurs pics de trafic théoriques en même temps ; votre fournisseur de cloud de choix subit une panne sur plusieurs zones de disponibilité ; votre système de messagerie basé sur la multidiffusion souffre d'une boucle de rétroaction ; etc.

Le problème est que si vous travaillez avec un système donné suffisamment longtemps, il y a une chance plus élevée que vous ne le souhaiteriez que la « situation X » se produise réellement.

Alors, que pouvez-vous faire ? Oui, vous pouvez essayer de concevoir un système pour essayer d'éviter complètement ces pannes catastrophiques. Mais la construction d'un tel système pourrait être prohibitive en termes de temps et d'argent et peut facilement conduire à des systèmes sur-conçus si vous allez trop loin. Passer beaucoup de temps de développement à cibler des scénarios de panne qui ont peut-être 5 % de chances de se produire au cours de votre vie n'est pas la meilleure utilisation de vos ressources ^[1] .

Au lieu de cela, créez soupapes de surpression . Vous pouvez les considérer comme une sorte de levier ou de bouton que vous pouvez ajuster en cas d'échec afin de réduire la gravité de votre problème pendant qu'il est en cours de résolution. Ils peuvent souvent prendre la forme d'un basé sur la configuration booléen ou constant qui peut être facilement modifié en cas d'urgence, mais peut également se présenter sous d'autres formes.

Vous pouvez utiliser ces valeurs de relâchement de pression pour désactiver (ou activer) facilement une fonctionnalité critique ou pour augmenter ou diminuer une valeur importante utilisée dans votre application. Je vais donner quelques exemples ci-dessous.

idée de génie

Pour concevoir ces soupapes de décharge de pression, réunissez votre équipe et réfléchissez à certaines façons (peut-être même semi-extravagantes) dont votre système ou votre service peuvent tomber en panne de manière catastrophique.

Pour chacun de ces modes de défaillance, déterminez un moyen de corriger, de rediriger, de court-circuiter ou de pirater temporairement le système pour réduire temporairement l'ampleur du problème. L'objectif serait de ramener le système à un état de fonctionnement : vous serez probablement obligé de sacrifier des fonctionnalités pour y parvenir. En général, les 1 ou 2 personnes les plus familières avec un système donné doivent concevoir ces hacks. Étant donné que ces personnes ne sont pas toujours disponibles en cas d'urgence, il est bon d'explorer ces idées à l'avance.

Après avoir créé une liste de tous les modes de défaillance catastrophiques et des hacks correspondants qui seraient nécessaires pour remettre le système dans un état de fonctionnement (semi-)actif, vous pouvez également commencer à déterminer les modèles communs dans les hacks :

• L’ajout d’une limitation sur les requêtes entrantes aiderait-il dans un grand nombre de ces situations d’échec ?
• La désactivation du widget X ou Y, coûteux en calcul, sur votre site Web réduirait-elle la charge ?
• La possibilité de rediriger toutes les demandes entrantes du centre de données A vers B transformerait-elle une panne partielle en de simples problèmes de latence ?
• L'assouplissement de vos exigences de cohérence entraînerait-il une certaine corruption des données, mais rendre votre système disponible encore?
• Quelles autres fonctionnalités de votre banque de données pouvez-vous sacrifier à la demande pour la faire fonctionner à nouveau partiellement ? La durabilité ? Les données historiques ? La possibilité d'effectuer des écritures (en utilisant un esclave en lecture seule) ?
• Le fait de désactiver certains de vos flux de travail d’arrière-plan non critiques libérerait-il de la capacité pour vos flux de travail plus importants ?
• Le sacrifice rituel d’un stagiaire apaiserait-il les dieux des opérations ? ^[2]

Il est préférable de continuer à fonctionner avec une fonctionnalité partielle plutôt qu'une panne totale, et cela soulage également le personnel de permanence pendant qu'il travaille. commencer à appliquer leur SOP méthodique pour résoudre la cause profonde du problème.

Comme je l'ai dit plus tôt, vous pourrait On peut essayer de sur-concevoir un système pour empêcher ces rares catastrophes exotiques avant qu'elles ne se produisent, mais cela n'en vaut souvent pas la peine. De plus, même dans ce cas, il y aurait probablement toujours Il existe d'autres modes de défaillance encore plus improbables mais toujours possibles qui pourraient bénéficier de ces discussions de brainstorming. Ne perdez donc pas nécessairement beaucoup de temps à concevoir des moyens pour éviter ces problèmes obscurs, mais n'ignorez pas non plus leur possibilité. Parle d'eux!

Si quelqu'un a d'autres exemples de soupapes de décharge de pression qu'il conserve dans sa propre boîte à outils d'exploitation, je serais très intéressé d'en entendre parler dans les commentaires.

[1] Ne tenez pas compte de ce conseil si vous construisez quelque chose comme un réacteur nucléaire. Faites en sorte que cette merde fonctionne.
[2] Je plaisante. Les dieux des opérations ne se lèvent pas pour rien de moins qu'un diplômé d'université nouvellement embauché à temps plein.