Il s'agit du deuxième une série de publications en augmentant la disponibilité globale de votre service ou système.

Dans le premier message Dans cette série, nous avons défini et présenté certains concepts de disponibilité des systèmes, notamment le temps moyen entre les pannes (MTBF) et le temps moyen de récupération (MTTR). croissant MTBF et réduire Le MTTR est important, mais le réduire est sans doute plus facile. Cela ne nécessite pas des mois de travaux d'ingénierie ni d'investissements importants pour obtenir des résultats ; on peut souvent y parvenir progressivement grâce à quelques outils, procédures et processus supplémentaires.

Dans cet article, nous parlerons des mesures que vous pouvez prendre dès aujourd'hui pour réduire le MTTR et augmenter efficacement votre disponibilité.

Fais-le c'est tout!

Lors d'une panne, chaque minute compte. Selon le secteur d'activité, chaque minute supplémentaire d'indisponibilité peut entraîner des pertes de revenus, une perte de confiance des clients, voire pire. Pour éviter de gaspiller ces précieuses minutes – et ainsi augmenter directement le MTTR – il est essentiel d'encourager votre équipe à privilégier la réactivité.

En situation opérationnelle, l'expression « privilégier l'action » signifie que si vous avez une hypothèse sur la cause de votre panne et qu'une solution vous vient à l'esprit, ou si quelqu'un d'autre en trouve une, mettez-la en œuvre. Tentez le coup.

Cette attitude vous évitera d'être paralysé par l'indécision face à un problème opérationnel majeur, en l'absence de données et d'informations suffisantes pour prendre une décision éclairée et réfléchie quant à la meilleure approche à adopter. Apporter la solution parfaite deux heures après le début d'une panne est presque toujours moins avantageux qu'une solution imparfaite mais efficace mise en œuvre 15 minutes plus tard. Et qui sait ? L'une de vos premières tentatives pourrait bien résoudre le problème définitivement. Il n'y a qu'un seul moyen d'en être sûr : essayer. Une panne n'est pas le moment d'hésiter à prendre des risques.

Un facteur important pour cultiver cette attitude opérationnelle au sein de votre organisation est de pas Pénaliser les erreurs ou les prises de risques lors de la résolution d'un problème opérationnel majeur est une bonne idée. Redémarrer l'ensemble des serveurs frontaux a temporairement aggravé le problème ? Tant pis, cela valait le coup d'essayer. Nous n'opterons pas pour cette solution aussi rapidement la prochaine fois.

Bien sûr, il faut prendre des risques et expérimenter, mais il est inutile de faire preuve d'inconscience. Avant de supprimer une table de base de données, assurez-vous d'avoir une sauvegarde. Avant d'exécuter une requête de mise à jour sur 12 000 lignes, faites-la vérifier par quelqu'un et, si possible, divisez-la en plusieurs transactions. Enfin, évaluez l'ampleur du problème par rapport à la solution que vous tentez : une panne est une chose, mais si vos systèmes ne fonctionnent qu'à un rythme normal, c'est bien pire. réduit En matière de capacité ou de fonctionnalité, il est peut-être préférable d'éviter les solutions radicales dont les conséquences négatives potentielles en cas d'erreur sont très importantes, voire catastrophiques.

Connais tes ennemis, et toi-même.

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

Ennemis

Vous et votre équipe devriez bien connaître les problèmes courants – ennemis – auxquels votre service ou système est confronté au quotidien. Je ne parle pas des problèmes potentiels les plus catastrophiques et les plus exotiques que vous pourriez rencontrer. pourrait mais les modes de défaillance réels et quotidiens que votre système a rencontrés par le passé, et qu'il rencontrera presque certainement à l'avenir.

Vous savez de quels problèmes je parle : ce souci de mise à l’échelle qui n’a pas encore été résolu, ce service hérité capricieux qui plante de temps en temps, cette base de données qui a la fâcheuse tendance à se bloquer, ou encore ces circonstances particulières qui déclenchent une avalanche de messages. Quel que soit le mode de défaillance, s’il se produit fréquemment dans votre système, tout le monde Les membres de votre équipe devraient savoir (ou avoir été formés) comment gérer cela.

Oui, vous travaillez probablement à résoudre le problème à la source (et si ce n'est pas le cas, vous devriez), et vous espérez qu'il ne sera bientôt plus qu'un mauvais souvenir. Cependant, nombre de vos problèmes les plus chroniques ne peuvent être facilement et complètement éliminés – sinon, vous l'auriez fait depuis longtemps – et certains systèmes anciens sont difficiles à modifier. Il est donc essentiel de disposer de procédures documentées et détaillées pour faire face à ces problèmes, et cette documentation doit être facilement accessible à votre équipe lors de futurs incidents. Un wiki interne est idéal pour ce guide des opérations d'urgence.

Toi-même

Vous et votre équipe devez également bien connaître les outils à votre disposition pour pouvoir comprendre l'état de vos systèmes.

Pour commencer, je vais aborder le point le plus évident : Il faut savoir qu'il y a un problème pour pouvoir le résoudre. Vous avez donc besoin d'une surveillance. Beaucoup de surveillance.

Surveillez au niveau de l'hôte : processeur, mémoire libre, utilisation du swap, espace disque, IOPS disque, E/S réseau, ou tout autre attribut hôte important pour le système en question. tonne s    o f    grand t    m onitorin g    s solutions il existe des solutions pour cela.

Surveillance au niveau applicatif : configurez des moniteurs pour vérifier et signaler diverses métriques de santé de votre système, comme latence des requêtes, 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 Soyez attentif aux signes avant-coureurs. Si vous disposez d'un système exposé à l'extérieur, configurez un moniteur externe pour vérifier si votre système/site web est opérationnel, accepte les requêtes et fonctionne correctement.

Maîtrisez vos outils de surveillance. Ces outils sont des ressources précieuses en cas de panne pour identifier rapidement et visuellement le problème. Cependant, si votre équipe ne sait pas les utiliser, ni leur interface (ni même comment se connecter), ils seront quasiment inutiles. Ajoutez des liens vers les graphiques et tableaux de surveillance pertinents dans votre Guide des opérations d'urgence mentionné précédemment, pour un accès rapide.

Mais ces systèmes de surveillance ne servent pas à grand-chose si personne ne les écoute. Vous devriez – petite pub au passage ! – utiliser un système comme PagerDuty pour combler le fossé entre les systèmes de surveillance et votre personnel d'astreinte (les personnes qui résoudront concrètement le problème), ainsi que pour organiser les plannings d'astreinte et les procédures d'escalade. Une autre option, plus coûteuse, serait quelque chose comme… NOC Je ne m'attarderai pas trop sur ce point, mais il n'y a aucune raison qu'il y ait le moindre délai entre le moment où vos systèmes de surveillance détectent un problème et… toi se rendre compte qu'il y a un problème.

Je publierai bientôt un autre article détaillant quelques-unes de mes astuces préférées.