Dans cet article, nous passerons en revue les tâches récurrentes de l’équipe d’exploitation. Les tâches qui doivent être effectuées régulièrement, généralement une fois par semaine, généralement le Lundi matin.

En quoi consistent-elles ?

• Vérifier l’état de santé de l’infrastructure
• Vérifier le bon déroulement des traitements du weekend
• Relever les statistiques de la semaine passée
• …

Le cas des « petits » projets

Sur certains projets, plutôt de petite taille, l’équipe d’exploitation peut être l’équipe de développement elle-même, qui endosse alors plusieurs casquettes (et je ne parle pas de devops, mais bien du cas où la personne qui fait le développement est celle qui en fera le déploiement et l’exploitation…).
Qui dit « petit projet » dit « petite équipe » (1 à 2 personnes) et face aux priorités métier, il est parfois difficile de dégager du temps pour automatiser l’exploitation de la plateforme. Alors, si l’infrastructure est également de petite taille, on se contente de réaliser ces tâches de façon manuelle, ce qui est bien entendu chronophage.
Petit ou grand projet, lorsque du temps se libère, il est primordial d’automatiser un maximum ces tâches d’exploitation, de mettre en place des systèmes d’alertes qui pousseront l’information plutôt que d’aller soi-même les récupérer.

Quand faut-il les réaliser ?

Quelque soit la tâche d’exploitation, je conseille de la réaliser au moins 1 fois / semaine.
Si la ressource concernée par la tâche est plutôt stable, évolue peu ou a un cycle de vie lent, on peut donc la réaliser 1 fois / semaine.
Si la ressource est plutôt fragile, évolue beaucoup ou a un cycle de vie rapide, il est peut-être bon de la réaliser 2-3 fois / semaine, voire 1 fois / jour si elle est nouvelle ou pas encore totalement éprouvée.

« Mieux vaut prévenir que guérir »

Il faut garder en tête que chaque tâche prend du temps, et plus on la réalise, plus on consomme du temps projet. Il faut également se dire que si on ne les réalise pas assez souvent, on risque de subir un incident (manque d’espace disque, base de données saturée, …) qui nous prendra plus de temps à le résoudre que l’on en aurait accumulé à empêcher qu’il se produise…

Quelles sont-elles et comment les réaliser ?

Vérifier l’état de la RAM

La RAM (Random Access Memory), aussi appelée mémoire vive, peut être comparée aux poumons du corps humain (et vous savez ce qu’il se passe quand vous n’avez plus d’air). Il est donc important de s’assurer que notre serveur a encore assez de cette ressource à donner à votre application, quelle qu’elle soit.

Quelques commandes Linux à retenir

Obtenir l’état de la RAM global

free -m -t

Obtenir l’état de la RAM virtuelle

vmstat

Obtenir l’état de la RAM détaillé

watch cat /proc/meminfo

Vérifier l’occupation de l’espace disque

Différentes raisons peuvent amener rapidement à une saturation de l’espace disque.

Quelques exemples

Une mauvaise gestion des fichiers de logs qui grossissent et se multiplient plus ou moins rapidement.
L’architecture JMS de WebLogic avec choix de stockage en fichiers (filestore) présente le risque de voir les messages s’empiler sur le serveur si, d’un coup, la consommation s’arrête ou ralentit.
Dans ces 2 petits exemples, si on laisse passer trop de temps avant d’agir, l’espace disque se réduira et votre application ne pourra plus continuer de vivre.

Quelques commandes Linux à retenir

Espace disque libre

df -h

Espace occupé par dossier, classé par taille (humaine)

du -skh * | sort -h

Fichiers dont la taille > 100 Mo, classé par taille (humaine)

find . -type f -size +100M | xargs ls -lrth

Vérifier l’activité

Dans le cas des Web Services comme moyen d’échange, comme c’est de plus en plus le cas de nos jours, on peut obtenir une idée précise de l’activité en analysant le journal des accès (les fichiers *access.log*).

Quelques commandes Linux à retenir

Nombre de requêtes par date

awk '{print $2}' access.log | sort | uniq -c

Vérifier l’espace disponible dans la base de données

Quand une application stocke ses informations dans une base de données (comme c’est pratiquement toujours le cas), elle y est fortement couplée. C’est le cas, par exemple, de la Oracle SOA Suite qui ne fonctionnerait pas sans base de données.
Il est alors indispensable de s’assurer qu’elle est up et qu’elle n’est pas pleine. C’est généralement le rôle de l’administrateur de bases de données (le DBA), même sur les petits projets.

Particularité des middleware

Cette liste non exhaustive des tâches d’exploitation à réaliser régulièrement concerne tout type d’application. Mais si votre application est un middleware (ex : bus de service), il serait encore plus grave qu’elle « tombe » car cela impacterait toutes les applications clientes de votre ESB et causerait un déséquilibre sur tout le SI. Ces vérifications sont alors obligatoires.
Vous devrez en plus vérifier (très) régulièrement :

• l’état des machines, des clusters, de chaque managed server
• le contenu des files JMS (nombre de messages, âge…)
• le journal des erreurs (ex : les Message Reports OSB)
• …

Aussi, il sera intéressant de relever les statistiques de la semaine qui vient de s’écouler en faisant :

• des requêtes en base de données
• des extractions à partir des fichiers de logs des serveurs

Conclusion

Mieux vaut passer du temps à surveiller votre application et ainsi être en mesure de réagir avant que les problèmes ne surviennent que de penser en gagner en délaissant la supervision et rencontrer régulièrement des incidents.