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

Dans le premier poste Dans cette série, nous avons défini et introduit certains concepts de disponibilité du système, notamment le temps moyen entre pannes (MTBF) et le temps moyen de récupération (MTTR). en augmentant MTBF et réduire Les MTTR sont importants, mais il est sans doute plus facile de les réduire. Il ne faut pas des mois de travail d'ingénierie et de dépenses d'investissement pour obtenir des résultats, mais ils peuvent souvent être obtenus progressivement avec des outils, des procédures et des processus supplémentaires.

Dans cet article, nous parlerons des choses que vous pouvez faire aujourd'hui pour aider à réduire le MTTR et à augmenter efficacement votre disponibilité.

Fais-le c'est tout!

Dans tout scénario de panne, chaque minute compte. Selon l'entreprise, chaque minute d'indisponibilité supplémentaire peut entraîner une perte de revenus, une perte de confiance des clients ou pire. Pour éviter de gaspiller ces précieuses minutes (et d'augmenter directement le MTTR), une attitude de « tendance à l'action » doit être cultivée au sein de votre équipe.

Ce que signifie « préjugé pour l'action » dans une situation opérationnelle : si à un moment donné vous avez une hypothèse sur la cause de votre panne et que vous ou quelqu'un d'autre avez une idée de solution qui pourrait aider à résoudre le problème, faites-le. Essayez, tout simplement.

Cette attitude vous aidera à éviter de vous retrouver paralysé par l'indécision lorsque vous êtes confronté à un problème opérationnel vraiment grave et que vous n'avez pas suffisamment de recherches et de données pour prendre une décision complètement éclairée et bien réfléchie sur l'approche à adopter. Trouver la solution parfaite deux heures après le début d'une panne est presque toujours moins gagnant que de trouver une solution imparfaite mais utile 15 minutes après. Et qui sait : l'une des premières choses que vous essayez pourrait en fait résoudre complètement le problème. Il n'y a qu'une seule façon d'en être sûr : essayez. Une panne n'est pas le moment d'être réticent au risque.

Un facteur important pour cultiver cette attitude opérationnelle au sein de votre organisation est de pas pénaliser les gens qui font des erreurs ou prennent des risques en essayant de résoudre un problème opérationnel de grande ampleur. Le fait de faire rebondir l'ensemble de la flotte de frontends a aggravé le problème pendant un certain temps ? Tant pis, ça valait la peine d'essayer. Nous n'essaierons pas cette solution aussi rapidement la prochaine fois.

Bien sûr, même si vous devez prendre des risques et essayer des choses, il ne sert à rien d'être stupide à ce sujet. Avant de tronquer cette table de base de données, assurez-vous d'avoir une sauvegarde. Avant d'exécuter cette instruction de mise à jour sur 12 000 lignes, demandez à quelqu'un de vérifier le SQL pour vous et de le diviser en plusieurs transactions si vous le pouvez. Et évaluez l'ampleur du problème par rapport à la solution que vous essayez de mettre en œuvre : les pannes sont une chose, mais si vos systèmes ne fonctionnent qu'à réduit En ce qui concerne la capacité ou la fonctionnalité, vous devriez peut-être attendre avant d'effectuer des correctifs radicaux, car les risques potentiels d'erreurs sont très importants, voire catastrophiques.

Connaissez vos ennemis et vous-même

On dit que si vous connaissez vos ennemis et vous-même, vous pouvez gagner cent batailles sans une seule défaite. Sun Tzu

Ennemis

Vous et votre équipe devez être très familiers avec les problèmes courants : ennemis – auxquels votre service ou votre système est confronté au quotidien. Je ne parle pas des problèmes potentiels les plus catastrophiques et exotiques auxquels vous êtes confronté. pourrait face, mais les modes de défaillance réels et quotidiens que votre système a rencontrés dans le passé et rencontrera presque certainement à l'avenir.

Vous savez de quel genre de problèmes je parle : ce problème de mise à l'échelle qui n'a pas encore été résolu, ce service hérité capricieux qui tombe parfois en panne, cette base de données qui a la fâcheuse habitude de se bloquer, ou ces ensembles de circonstances spécifiques qui déclenchent une tempête de messages. Quel que soit le mode de défaillance, s'il s'agit d'un problème qui survient fréquemment dans votre système, tout le monde Les membres de votre équipe doivent savoir (ou être formés) comment le gérer.

Oui, vous travaillez probablement à résoudre la cause profonde du problème (et si ce n'est pas le cas, vous devriez le faire), et vous espérez qu'il ne sera bientôt plus qu'un lointain souvenir. Mais bon nombre de vos problèmes les plus chroniques ne peuvent pas être facilement et complètement résolus (ou vous l'auriez fait depuis longtemps) et certains systèmes existants sont difficiles à modifier. Vous devez donc toujours disposer de procédures documentées et détaillées sur la façon de faire face à ces problèmes, et cette documentation doit être facilement accessible à votre équipe lors d'incidents futurs. Un wiki interne est un excellent endroit pour ce guide des opérations d'urgence.

Toi-même

Vous et votre équipe devez également être très familiers avec les outils dont vous disposez pour pouvoir comprendre l’état de vos systèmes.

Pour commencer, je vais commencer par le plus évident : il faut savoir qu'il y a un problème pour pouvoir le résoudre. Il faut donc une surveillance. Et une surveillance importante.

Surveillez au niveau de l'hôte : CPU, mémoire libre, utilisation du swap, espace disque, IOPS disque, E/S réseau ou tout autre attribut au niveau de l'hôte qui est important pour le système en question. Il existe tonne m    ou F    génial t    m onitorine g    m solutions il existe des outils disponibles pour cela.

Surveiller au niveau de l'application : Configurez des moniteurs pour vérifier et générer des rapports sur diverses mesures de santé au niveau du système de votre système, telles que latence de la demande, débit , délais de traitement, tailles des files d'attente, taux d'erreur, performances de la base de données , de bout en bout    performance , etc. Configuration analyses de journaux qui continuellement surveillez vos journaux de service à la recherche de mauvais signes. Si vous avez un système orienté vers l'extérieur, configurez un moniteur externe pour vérifier si votre système/site Web est opérationnel, accepte les demandes et est en bon état.

Apprenez à utiliser vos outils de surveillance. Ces outils sont des ressources formidables en cas de panne pour déterminer rapidement et visuellement ce qui ne va pas, mais si votre équipe ne sait pas comment les utiliser ou comment utiliser leur interface utilisateur (ou même comment se connecter), ils ne seront pas d'une grande utilité. Ajoutez des liens vers des graphiques et tableaux de surveillance intéressants/utiles dans votre guide des opérations d'urgence mentionné ci-dessus, pour un accès rapide.

Mais ces systèmes de surveillance ne servent pas à grand-chose si personne ne les écoute. Vous devriez – sans vergogne ! – utiliser un système comme PagerDuty pour combler le fossé entre les systèmes de surveillance et votre personnel d'astreinte (les personnes qui vont réellement résoudre le problème) ainsi que pour organiser les horaires d'astreinte et les politiques d'escalade. Une autre option, plus coûteuse, serait quelque chose comme un CNO . Je n'insisterai pas trop sur ce point, mais il n'y a aucune raison pour qu'il y ait un quelconque délai entre le moment où vos systèmes de surveillance se rendent compte qu'il y a un problème et celui où ils le font. toi se rendre compte qu'il y a un problème.

Je reviendrai bientôt sur un autre article détaillant encore plus de mes conseils préférés.