Tôt ou tard, dans tout projet, il est temps de travailler sur la stabilité / disponibilité de votre service. Pour certains services, au stade initial, la vitesse de développement des fonctionnalités est plus importante, en ce moment l'équipe n'est pas complètement formée et les technologies ne sont pas sélectionnées très soigneusement. Pour les autres services (souvent technologiques b2b), afin de gagner la confiance des clients, le besoin de disponibilité élevée se fait sentir dès la première version publique. Mais supposons que le moment où X est néanmoins arrivé et que vous ayez commencé à vous soucier du temps que votre service "réside" au cours de la période considérée. Sous la coupe, je suggère de regarder en quoi consiste le temps d'arrêt et comment mieux travailler pour le réduire.
Indicateurs
De toute évidence, avant d'améliorer quelque chose, vous devez comprendre l'état actuel. Par conséquent, si nous avons commencé à réduire les temps d'arrêt, c'est d'abord et il faut commencer à le mesurer.
Nous ne parlerons pas ici en détail de la façon de procéder spécifiquement, des avantages et des inconvénients des différentes approches, mais le processus de thèse ressemble à ceci:
- nous nous appuyons sur des métriques proches de l'entreprise (erreurs dans le service, temps de réponse du service, $ / seconde, inscriptions / seconde, etc.)
- déterminer ce qui est bon et ce qui est mauvais
- transition bonne-> mauvaise est le début d'un incident
- transition mauvaise-> bonne - fin de l'incident
- temps du début à la fin - la durée de l'incident (plafonnez avec nous)
- la somme de la durée des incidents pour la période (mois / trimestre / année) - temps d'arrêt
- (100 - <temps d'arrêt> / <durée de la période> * 100) = pourcentage de disponibilité pour la période
Lorsqu'ils parlent de disponibilité / temps d'arrêt, ils mentionnent souvent un autre indicateur:
MTTR (temps moyen de réparation) - le temps moyen entre le début de l'incident et sa fin.
Les problèmes avec lui commencent dès le premier mot de l'abréviation. Étant donné que tous les incidents sont différents, la moyenne de la durée ne peut rien nous dire sur le système.
Cette fois, nous ne ferons pas de moyenne, mais verrons simplement ce qui se passe pendant l'incident.
Anatomie d'un incident
Voyons quelles étapes importantes peuvent être distinguées pendant l'incident:
- détection - l'intervalle entre la première erreur que nous avons donnée à l'utilisateur avant que le préposé reçoive un SMS
- réaction - de la réception d'une notification concernant un problème au moment où une personne a commencé à résoudre ce problème (généralement à ce moment, l'événement de surveillance est transféré à l'état Accusé de réception)
- enquête - du début du travail sur un problème jusqu'au moment où la cause de l'incident est connue et nous savons ce qui doit être fait pour restaurer le travail.
- élimination - le temps de récupération, par exemple, la version de restauration, la promotion d'une nouvelle
maître serveur de base de données principal
Peut-être que notre modèle est incomplet et qu'il y a d'autres étapes, mais je propose de les introduire seulement après avoir réalisé comment cela nous aidera dans la pratique. En attendant, examinez plus en détail chaque étape.
Détection
Pourquoi passons-nous du temps à trouver une urgence? Pourquoi ne pas envoyer une notification sur la toute première erreur reçue par un utilisateur? En fait, je connais de nombreuses entreprises qui ont tenté de le faire, mais elles ont abandonné cette idée quelques heures plus tard, pour lesquelles elles ont reçu plusieurs dizaines de SMS. Je pense qu'il n'y a pas un seul service plus ou moins volumineux qui n'ait pas un flux d'erreurs "d'arrière-plan" constant. Tous ne sont pas un signe que quelque chose s'est cassé, il y a aussi des bogues dans le logiciel, des données invalides obtenues à partir du formulaire et une validation insuffisante, etc.
Par conséquent, le niveau d'erreurs (ou d'autres mesures) qui dépasse les fluctuations quotidiennes est utilisé comme critère d'ouverture d'un incident. C'est précisément ce qui conduit au fait que la notification des employés responsables survient plus tard que le début réel du problème.
Mais revenons à notre tâche initiale - réduire la durée des incidents. Comment raccourcir le temps de détection? Plus rapide à notifier? Vous venez avec une super logique pour détecter les anomalies?
Je suggère de ne rien faire encore, mais de regarder les prochaines étapes, car en réalité elles sont interconnectées.
Réaction
Ici, nous avons un facteur purement humain. Nous supposons que la surveillance a réussi à détecter le problème et nous avons réussi à réveiller l'ingénieur de service (toute l'escalade a également fonctionné à l'étape précédente).
Considérez le "pire" cas, nous n'avons pas de service de garde dédié, et l'alerte a attrapé l'administrateur dormant paisiblement. Ses actions:
- répondre aux SMS: ici, une femme avec une oreille sensible aide beaucoup, diverses applications pour le téléphone, améliorant l'effet de la réception de SMS (1-5 minutes)
- prendre une décision qu'il va néanmoins ramper hors du lit: si les alertes ne sont pas correctement paramétrées, une personne peut attendre 2 minutes "et si la résolution vient?" et s'endormir (1-15 minutes)
- accédez à l'ordinateur portable, ouvrez les yeux, réveillez-vous, accédez à la surveillance, appuyez sur Ack: (1-15 minutes)
En conséquence, dans le pire des cas, nous obtenons 35 minutes de réaction. Selon mes observations, un tel temps de réaction semble être vrai.
Étant donné qu'à ce stade, nous traitons avec des personnes, nous devons agir avec beaucoup de prudence et de réflexion. Vous n'avez en aucun cas besoin de rédiger un règlement selon lequel une personne qui vient de se réveiller doit bouger! Créons simplement les conditions.
Débarrassons-nous des doutes de l'ingénieur que le problème se terminera de lui-même. Cela se fait très simplement: rendre le critère d'alerte insensible aux problèmes mineurs et notifier si l'incident dure longtemps . Oui, nous venons d'augmenter la durée de l'étape de "détection", mais regardons un exemple:
- augmenter le temps de détection de 5 minutes
- le nombre d'incidents est réduit: toutes les courtes rafales d'erreurs tombent généralement dans la minute. Ces courts incidents doivent être enregistrés, mais sans en avertir les gens. Souvent, ils donnent un temps d'arrêt très important au total, mais vous pouvez les gérer pendant les heures ouvrables. Pour cette tâche, vous aurez besoin d'une granularité élevée dans la surveillance, car le problème est déjà résolu et les outils de diagnostic ne conservent généralement pas l'historique.
- si une personne est obligée de répondre aux alertes une fois par mois ou moins souvent, et pas tous les deux jours, elle y répondra plus adéquatement et ne traitera pas cela comme une routine
- la notification différée permet à une personne de ne pas penser: si un SMS arrive, alors tout est grave et ne sera pas corrigé lui-même
Potentiellement, cette approche réduira le temps de réaction total de 15+ minutes. Si un tel temps de réaction ne vous convient pas, vous devriez penser au service de garde.
Enquête
C'est peut-être l'étape la plus difficile d'un accident lorsque vous devez comprendre ce qui se passe et ce qu'il faut faire. En réalité, cette étape est très souvent associée à l'étape de la prise de mesures, car généralement le processus se déroule comme suit:
- nous regardons la surveillance, les journaux (si la surveillance ne suffit pas), nous lançons d'autres outils de diagnostic
- proposer des hypothèses
- nous testons des hypothèses, soit par des métriques, soit en effectuant une action (tout redémarrer :)
- évaluer les résultats des changements
- communiquer avec des collègues si votre connaissance d'un sous-système particulier ne suffit pas
et ainsi de suite jusqu'à l'illumination ou la fin de l'incident.
Cette étape est généralement la plus importante de la durée totale de l'incident. Comment le réduire?
Tout n'est pas très clair ici, il existe plusieurs vecteurs:
- Simplifiez votre infrastructure : imaginez à quelle vitesse les gens qui ont une base de données et un service tombent en panne
- diffusion des connaissances en équipe : idéale si la communication des personnes ne se déroule pas pendant l'incident, mais au cours du travail quotidien (la communication des personnes est généralement un processus très long)
- surveillance : beaucoup de gens pensent que la surveillance ne fonctionne qu'au stade de "détection", mais en fait, elle peut agir comme une optimisation du processus de test d'hypothèse ("la base de données fonctionne-t-elle correctement?", "mon service fonctionne-t-il dans les ressources?") et aussi comme un transport diffusion des connaissances en équipe. "Serge, vérifie s'il y a des erreurs dans le journal X sur les blocages?" peut être transformé en déclencheur, dont la description sera un lien vers le wiki avec des instructions .
Élimination
Comme je l'ai dit plus haut, cette étape se confond souvent avec la précédente. Mais il arrive que la raison soit immédiatement claire, mais la reprise sera très longue. Par exemple, vous avez un serveur mort avec maître primaire (je ne pourrai pas m'y habituer longtemps :) avec une base de données, et vous n'avez jamais promu une réplique, c'est-à-dire que vous lirez la documentation, déploierez une nouvelle configuration d'application, etc.
Naturellement, après chaque incident significatif, vous devez trouver un moyen d'empêcher que cela ne se reproduise ou d'accélérer considérablement la récupération. Mais voyons quelles directions nous pouvons essayer d'élaborer de manière proactive:
- outils de gestion d'infrastructure : si pour réparer tout ce dont vous avez besoin pour déployer une nouvelle configuration, mais cela se fait en au moins 20 minutes - c'est votre limite. Essayez de trouver des scénarios de ce qui pourrait arriver et un moyen d'accélérer d'urgence certains processus. Par exemple, dans ansible, vous avez défini série (parallélisme d'exécution des tâches) = 3, mais si vous mentez toujours, vous pouvez rouler avec série = 30, vous devez enseigner à tout le monde comment le redéfinir (de manière similaire à la stratégie de mise à jour continue dans kubernetes).
- exercices : si vous savez que les scénarios probables d'échec et de récupération ne sont pas automatisés, vous devriez avoir des instructions qui doivent être testées . Planifiez les temps d'arrêt (si nécessaire), effectuez des exercices. Souvent, à ce stade, de tels cas sont automatisés, car la plupart des pièges des procédures, même les plus compliquées, à première vue sont clarifiés au cours des exercices.
- interaction avec les prestataires : vous devez savoir à l'avance ce que vous ferez si votre hébergeur tombe malade. Souvent, la prise de conscience de la probabilité d'un problème et du coût de la fermeture du risque conduit à la conclusion: «nous attendons simplement la reprise». Mais d'un autre côté, les ingénieurs et les entreprises seront prêts pour un tel scénario. Par exemple, vous pouvez résoudre le problème de la conversion de votre trafic vers un talon pré-préparé, informer les utilisateurs avec une lettre pré-préparée, etc. Ou vice versa, vous faites une instruction selon laquelle nous donnons à l'hébergeur 30 minutes pour récupérer, puis nous commençons à passer à un autre DC, où il existe déjà une réplique de la base de données, mais vous devez étendre tout le reste. Et là encore, les enseignements, on note le temps de bouger, etc.
MTBF (temps moyen entre les pannes)
Une autre métrique commune mentionnée dans la discussion de disponibilité. Encore une fois, je propose de ne faire aucune moyenne, mais simplement de parler du nombre d'incidents qui se produisent sur un intervalle de temps.
Voici au premier plan la question de savoir dans quelle mesure vous avez veillé à la tolérance aux pannes de votre service:
- existe-t-il un point de défaillance unique (SPOF) dans l'infrastructure, quelle est la probabilité de défaillance?
- Dans quelle mesure êtes-vous confiant qu'il n'y a pas de SPOF que vous ne connaissiez pas? (c'est exactement le problème que le chaos singe résout)
- Les équilibreurs de charge fonctionnent-ils bien? ( mon rapport sur l'équilibrage )
- Quelle est la résilience du réseau?
- Quelle est la fiabilité du centre de données?
Parfois, pour calculer / prévoir tout cela, ils font une «carte des risques», où chaque scénario (que nous aurions pu supposer, bien sûr, il y a toujours ceux que nous ne connaissons pas encore) a une probabilité + impact (temps d'arrêt court / long, perte de données, perte de réputation) , etc.). Ensuite, ils travaillent systématiquement sur une telle carte, clôturant tout d'abord des scénarios très probables et graves en termes d'impact.
Une autre technique qui peut être utilisée est la classification des incidents passés. Il y a beaucoup de discussions maintenant qu'il est très utile d'écrire des incidents «post mortem», qui analysent les causes du problème, les actions des personnes, déterminent les actions futures possibles. Mais afin de rechercher rapidement les causes de tous les accidents survenus au cours de la période écoulée, il convient de résumer leur durée avec un regroupement par «classes de problèmes» et où le plus de temps d'arrêt est de prendre des mesures:
- erreurs humaines : réduire le nombre d'actions manuelles en production, diverses protections contre les erreurs de l'opérateur
- versions infructueuses : il vaut la peine d'améliorer les tests (y compris les tests de charge)
- erreurs d'application : réparer les fuites, les plantages et autres gels
- réseau : acheter du matériel, installer, embaucher des networkers, changer de contractant
- Bases de données : embaucher un DBA, prendre en charge la tolérance aux pannes, acheter un meilleur matériel
- DC : pensez à la sauvegarde ou à la relocalisation
- influences externes (ddos, blocage, revues de certificats, domaines): acheter des antiddos, faire le plein de procurations, surveiller la validité des domaines / certificats, disposer de plusieurs certificats de différentes autorités de certification.
Autrement dit, si vous n'essayez même pas de prédire des scénarios possibles de problèmes, cela vaut vraiment la peine de travailler avec des incidents qui se sont déjà produits.
Total
Tous les incidents sont différents:
L'algorithme de travail pour augmenter la disponibilité est très similaire à toute autre optimisation:
-> -> ->
D'après ma propre expérience, je peux dire que pour une amélioration significative du temps de disponibilité, il suffit de commencer à le suivre et à analyser les causes des incidents. Il arrive généralement que les modifications les plus simples apportent l'effet le plus significatif.
Notre service de surveillance aide non seulement à l'étape de «détection», mais réduit également considérablement «l'enquête» (les clients confirmeront)