Au cours des dix dernières années, nombreux sont les cas d’infrastructures dites sensibles, que ce soit pour des raisons de sécurité ou de disponibilité que j’ai du auditer, définir ou mettre en place. Le résultat de ces dix ans d’expérience est sans appel : la haute disponibilité passe par la simplicité.

Dans bien des cas, lorsqu’un projet nécessitant une haute disponibilité est nécessaire, c’est une infrastructure complexe (multiples load balancers en cascades, serveurs en chaine répliqués, structure pouvant basculer automatiquement sur ses secours en cas de panne, etc…) qui est généralement conseillée ou mise en place. Or avec l’amélioration technologique dont nous profitons, il n’est pas toujours nécessaire de déployer tout cela.

La principale erreur que font les responsables de telles architectures, c’est de ne pas se concentrer sur la réalité du but à atteindre dans son ensemble : concentrés sur la disponibilité et la performance, ils en oublient les probabilités de taux de panne, ainsi que les temps de rétablissement en accord avec la probabilité précédente.

Or ce dernier point est très important : en cas de problème grave (et non d’une coupure bête et méchante du service) s’ajoute un temps de diagnostic, temps qui croit de manière exponentielle avec la complexité de l’infrastructure. On se rend compte en étudiant les cas réels, que les problèmes (les vrais) sont rarement simples, ainsi, un fichier effacé sur un disque se réplique sur un RAID, une erreur ou corruption de base de données, peut se répliquer en temps réel sur des serveurs en réplications, etc… La redondance et le backup sont 2 points totalement différents à aborder, mais les paramètres entrant en ligne de compte sur la globalité de l’infrastructure sont très nombreux.

Avec le temps, je constate que dans 99% des cas, tous les points importants correspondant à la réalité pratique, et non à la théorie, ne sont quasiment jamais étudiés. C’est l’une des causes pour laquelle il y a encore aujourd’hui des pannes longues et lourdes sur les infrastructures les plus importantes, et disposant pourtant du plus de moyens.

Aller droit au but, et éviter ces pièges : la société au sein de laquelle j’occupe le poste de directeur technique s’en est fait une spécialité, notamment dans le domaine des infrastructures hébergées. Malgré cette spécificité, j’étudie la sortie à moyen terme d’un rapport basé sur toute cette expérience, avec une méthode de calcul permettant de réellement cibler le problème dans son ensemble. Ainsi 4H00 de panne 1 jour et 5 min par semaines, n’ont pas les mêmes conséquences, alors que le taux annuel reste le même, etc… Ce sont des centaines de paramètres qui doivent rentrer en compte dans une étude. La suite… peut être un de ces jours.