Pour savoir où on va, il faut savoir d'où l'on vient

Vous avez
une question ?
Un projet ?

Contactez nous !
 

Contactez-nous

Vous avez une question ? un projet ? 
Vous souhaitez plus d'informations sur un produit ? sur notre offre ? 
Contactez-nous, on vous répond sous 4H.

retour

Bonnes pratiques

Bonnes pratiques

Quelques bonnes pratiques de la haute disponibilité

 

Un technicien sera peut être là sous 4 heures, mais 4 heures c’est très long, et de plus il est probable qu’il ne pourra réparer immédiatement.

Il faut donc a minima disposer de tous les composants de secours sur place. On peut en revanche, compter sur un certain niveau de mutualisation des composants de secours, et à ce titre, plus la plateforme est grande, moins le secours coûte cher.

Il convient également de disposer d’une gestion de configurations virtualisées, permettant d’installer n’importe quel serveur sur n’importe quel hardware en quelques minutes.

Enfin, on peut considérer que, à partir d’une dizaine de serveurs, la panne doit être considérée comme un événement anodin, avec un secours totalement transparent.

Pannes logicielles

 

Et pourtant il est courant que l’on investisse davantage sur la redondance matérielle que sur les process assurant la qualité du logiciel. Typiquement, on prévoira un serveur de secours, mais on trouvera trop coûteux de disposer d’une plateforme de préproduction. De sorte que les nouvelles versions d’applications ne seront pas testées dans un environnement suffisamment représentatif, ce qui causera des anomalies et indisponibilités. Redisons-le : il est souvent plus important d’investir pour se prémunir des défauts logiciels que des pannes matérielles. D’autant que lorsqu’une panne logicielle survient, la redondance le plus souvent ne sert à rien car le même logiciel est déployé sur les composants de secours.

 

Enfin, en matière de haute disponibilité comme ailleurs, la simplicité doit prévaloir. Il arrive couramment qu’une configuration visant la disponibilité au prix d’une complexité trop grande subisse des arrêts à cause même de cette complexité ou mauvaise maîtrise.

C’est pourquoi il faut le redire, le marteler : 9 fois sur 10 les interruptions de service proviennent du logiciel et non du matériel. Certes, à l’intérieur de ces 9 fois, une bonne part correspondra à une mauvaise réaction du logiciel à un incident d’origine matérielle ou un événement extérieur exceptionnel. Ce pourra être typiquement un fichier de log devenu trop gros, ou un administrateur qui lance un job, disons de purge par exemple, qui va bloquer la base de données.

Exploitation

Beaucoup d’organisations ont des processus d’exploitation qui portent encore la marque d’une époque ancienne, où l’on pouvait arrêter le service, la nuit vers 3 heures du matin, de manière à mettre en place différents travaux batch, et à l’occasion, relancer les serveurs. A l’évidence, le web a changé la donne. Non seulement parce qu’il y a toujours des internautes en ligne, à toute heure de la nuit, mais aussi parce que la plateforme web sert des internautes du monde entier, y compris des internautes pour lesquels il est 9h du matin. Tout cela semble évident, et pourtant on rencontre encore trop souvent des sites qui ferment une demi-heure chaque nuit, ou bien une fois par semaine.

 

Changements de version

La règle générale en informatique est que ce qui a marché continue de marcher, du moins tant qu’on ne touche à rien, et qu’il n’y a pas d’événement extérieur nouveau.

 

Il est extrêmement difficile de valider une version pour le monde réel. Les scénarios de test, même si l’investissement est important, n’auront parcouru que quelques centaines de cas de figure, et d’un seul coup l’application sera confrontée à quelques centaines de milliers, voire millions de cas de figure. Il y a là un saut quantique auquel peu d’applications résistent.

Nous ne pouvons pas donner ici toutes les bonnes pratiques de validation du logiciel, mais trois points essentiels seulement :

  • Pour une plateforme qui est vivante, et reçoit régulièrement de nouvelles versions, la pratique de l’intégration continue et des tests automatisés est déterminante pour assurer la non-régression.
  • La validation n’étant jamais assez complète, une bonne pratique est la mise en service progressive, que ce soit sur une typologie d’utilisateurs, sur une région, sur une courte période.
  • Il faut pour cela concevoir des mises en service avec possibilité de retour arrière, et si possible faire une distinction entre les changements techniques et les changements visibles.