La qualité de service TI – 3e partie

Après avoir vu comment améliorer la qualité de service en structurant son travail et son équipe dans la 2e partie, voici quelques conseils pour anticiper et concevoir des systèmes performants.

 

Les autres chapitres de cet article :

  1. Définir la qualité d’un service,
  2. Améliorer la qualité d’un service,
  3. Créer des systèmes robustes.


Partie 3 – Créer des systèmes robustes

Des bonnes pratiques à mettre en œuvre dés la conception.


1.       Introduction

La qualité de service est bien évidemment dépendante de la rigueur d’exploitation, mais également des décisions prises pendant la phase de conception.

Ainsi, de nombreuses décisions d’architecture, d’achat ou de conception logicielle vont influencer directement la qualité du service fourni. Si le niveau de disponibilité demandé est élevé, il est important de préparer au plus tôt l’application à la haute disponibilité, en introduisant diverses techniques.

 

2.       Méthodes

Nous allons maintenant passer en revue quelques-unes des techniques possibles.

a)     Créer de la redondance

Un système redondant est la base des infrastructures hautement disponibles. La redondance permet de créer des systèmes dupliqués capables d’assurer le service même si l’un des composants tombe en panne.

Deux types de redondances peuvent être distingués : La redondance active/passive (en cluster) et la redondance active/active (en load balancing). Alors que le premier nécessite que le composant doublé soit en attente d’une panne du composant principal (c’est une sécurité dite N+1), le deuxième permet une répartition de charge sur les deux composants.

Selon le niveau où la redondance est créée, il est possible d’appliquer l’un ou l’autre, parfois même pour redonder plusieurs composants avec un seul. Cette répartition de charge peut être, par exemple, une ferme de 10 serveurs utilisée à 90%. Si un serveur est indisponible, la charge sera répartie sur les 9 autres restants (passant ainsi à 100% sur l’ensemble). Le nombre de serveurs en attente dépend du niveau de tolérance de panne désiré (1 seul serveur dans l’exemple précédent).

 

b)      Prendre en compte chaque niveau

Un élément de l’architecture qui n’est pas redondé et qui pourrait mettre en péril l’ensemble du système est appelé point individuel de défaillance (SPOF – Single Point Of Failure).

Afin de mettre en place une redondance complète, il est nécessaire de prendre en compte chaque élément nécessaire à la fourniture du service, du réseau au service web, sans oublier les « couches basses », comme l’électricité ou la climatisation, afin d’éliminer les SPOF.

J’ai par exemple déjà rencontré une situation dans une PME, où l’alimentation redondante d’un serveur disposant de matériel redondant dernier cri était débranchée chaque matin par la femme de ménage qui voulait brancher son aspirateur…

Cette anecdote met en avant l’importance de raisonner sur l’ensemble des systèmes lorsque l’on met en place un service en haute disponibilité, surtout si ce système est partagé sur plusieurs serveurs étants tous situés sur le même site. Dans tous les cas, il est important de prêter attention aux contrats (SLAs) définis avec les prestataires externes qui fournissent un élément nécessaire au service.

On peut considérer la redondance à différents degrés :

  • La redondance de bas niveau (matériel) : De la fourniture de l’électricité au disque dur, ce niveau de fiabilité est courant sur les serveurs actuels. La plupart des équipements de moyenne gamme disposent en effet d’une redondance pour l’alimentation, les processeurs, la mémoire, le réseau (teaming) ou encore les disques durs (RAID).
  • La redondance de haut-niveau : Avec une redondance de haut niveau on pourra, par exemple, rendre un site web hautement disponible en l’hébergeant sur deux datacenters et en faisant de la répartition de charge au niveau du point d’entrée. Ainsi, même si les serveurs ne disposent pas de composants redondants, le service est maintenu en cas de panne.
    Ce niveau de redondance dépend des capacités de l’application hébergée à pouvoir fonctionner sur plusieurs systèmes simultanément mais permet de garantir une production continue même en cas de perte d’un des deux sites de production.
    De nombreux fournisseurs « massifs » abordent ce raisonnement, en hébergeant leurs services sur des machines à bas prix (avec le minimum de redondance physique, source de coûts supplémentaires). Le service est sécurisé grâce à une redondance de haut-niveau, rendant la perte d’un élément physique sans importance.

 

c)     Lors de la conception

La redondance est un moyen efficace d’augmenter la disponibilité d’une application. Cependant, d’autres bonnes pratiques peuvent améliorer l’infrastructure obtenue :

  • Simplifier l’architecture du système d’information, car chaque point complexe est une source de problème.
    En effet, plus le système prévu est complexe, plus les tests et le dépannage seront difficiles. Ce principe est appelé KISS : Keep It Simple, Stupid !
    Il ne faut pas hésiter à remettre en question l’infrastructure actuelle sur ce point.
  • Anticiper et planifier :
    Lors de la conception d’une application, il faut prévoir son expansion et les possibilités d’augmentation de la charge. Une application dont la charge arrive à saturation mais qui ne dispose pas de possibilité de répartition de charge est un cauchemar à maintenir (et gaspille souvent une infrastructure matérielle énorme, car c’est le seul moyen d’améliorer ses performances).
  • Sécuriser et remettre en question les systèmes actuels :
    La sécurité informatique est un monde en permanente évolution. Prendre quelques bonnes habitudes lors de la conception permettra de réduire le risque d’intrusion et permettra par la suite de sécuriser plus facilement une application. Ces habitudes peuvent comprendre l’utilisation systématique de comptes de services, disposant d’un accès granulaire aux systèmes et avec un mot de passe fort.
  • Utiliser des comptes  dédiés à l’administration :
    Chaque administrateur doit posséder un compte classique, et un compte d’administrateur nominatif. Les comptes d’administration génériques (Domaine\Administrateur par exemple) doivent êtres sécurisés avec un mot de passe complexe, que l’on peut obtenir via un coffre fort numérique ou un système de gestion de mots de passe. Jamais ils ne doivent être utilisés pour ouvrir des sessions ou faire tourner des applications ou des services.
  • Automatiser, pour réduire le facteur d’erreur humaine et industrialiser l’évolution et les changements en général. (Ce thème est traité dans la 2e partie.)
  • Choisir des équipements et des logiciels dans une phase mature :
    De manière générale, il faut éviter la dernière solution à la mode et attendre d’avoir des retours d’expériences sur les produits envisagés. La qualité des produits et du support en sera bien meilleure.
  • Ne pas faire de mauvaises économies :
    Trop de projets sont lancés avec un budget trop serré, rapidement explosé lors de la mise en production. De manière générale, essayer de réaliser des économies au niveau du matériel, du logiciel, ou même des RH aura des répercussions négatives à moyen ou long terme de part une fiabilité moindre.
  • Penser aux sauvegardes dés la conception :
    En fournissant aux équipes d’exploitation les éléments à sauvegarder, la fréquence et la période de rétention nécessaire, on peut s’assurer que le système sera correctement sauvegardé et restauré. Cette reflexion doit être effectuée dés la conception par des personnes connaissant bien les produits à sauvegarder.
  • Prévoir le pire, en mettant en place des plans de reprise d’activité (disaster recovery). En cas de désastre majeur, il faut être capable de disposer de sauvegardes et de plan de redémarrage de l’infrastructure. Prévoir ce type de scénario permettra sans doute de mettre en avant les points faibles dans le système de sauvegarde et de penser globalement à l’ordre de redémarrage des systèmes.
  • Tester, tout tester, et de manière régulière :
    Ce conseil peut particulièrement s’appliquer avec les sauvegardes et les DRPs (Disaster Recovery Plans), mais également avec des logiciels développés en interne. Certains tests peuvent être effectués par le système de monitoring de manière automatisée, ou lors de maintenances plus conséquentes.
  • S’appuyer sur des contrats de service, sans oublier que l’importance des SLA est aussi de pouvoir garantir un niveau de service en pouvant compter sur ses fournisseurs.

 


J’espère que cet article sur la qualité de service vous a plu !

Si vous êtes intéressés par ce sujet, voici quelques livres et documents qui m’ont aidés lors de la rédaction de cet article :

Sources et références :

  • Livre ITIL et la gestion des services : méthodes, mise en œuvre et bonnes pratiques
    Par Thierry Chamfrault et Claude Durand, Chez Dunod
    Un livre complet qui étudie en détail chaque processus ITIL.
  • Livre blanc ITIL pour les PME/PMI
    Par BMC Software :
    http://documents.bmc.com/products/documents/07/50/70750/70750.pdf
    Un article détaillant bien les interactions entre les processus.
  • Livre Blueprints for High Availability
    Par Evan Marcus & Hal Stern, Chez Wiley
    Ce livre détaille les solutions et techniques possibles pour concevoir des systèmes à haute-disponibilité.
  • Livre High Availability and Disaster Recovery
    Par Klaus Schmidt, Chez Springer
    Un autre livre sur la haute-disponibilité, plus tourné sur la gestion de crise et la reprise sur incident.
  • Livre The Visible Ops Handbook
    Par IT Process Institute : http://www.itpi.org/?page=Visible_Ops
    Un « must-have » : Ce livre détaille comment mettre en place ITIL avec des exemples concrets.
par .

5 Commentaires

  1. hik3 dit :

    Merci beaucoup pour ces 3 articles de qualité ! Est-ce que vous connaissez des outils / logiciels qui permettent d’intégrer la : gestion des incidents (ticketing system), gestion des assets (inventory system), gestion des changement (change DB), base de connaissances (KB), surveillance proactive (monitoring), gestion des templates (outil de déploiement / patch management) ? c’est dur de trouver un bon logiciel qui fasse tout cela en même temps sur le marché, en plus il faut que ce soit simple d’utilisation et efficace … j’ai eu beau chercher j’ai trouvé que des logiciels qui ne font pas TOUT ce que je veux, soit ils en font trop …

    • David dit :

      Hello,
      Ravi de voir que ces articles t’ont plu !

      HP et Microsoft ont des suites complètes de gestion de service IT (respectivement IT Performance Suite et System Center), qui sont très complètes, mais coutent un gros billet en licences et en déploiement.
      Il n’y a malheureusement pas de produits miracle (complet et pas chère), et la solution consiste souvent en une imbrication de produits. Les produits libres ont l’avantage d’une communauté permettant de demander des évolutions.

      Quelques références en vrac :
      Spiceworks (monitoring + ticketing + inventaire), Zabbix (supervision), OCS Inventory (inventaire) et GLPI (ticketing). Côté industrialisation, j’ai fait beaucoup de déploiement scripté avec Active Directory, qui reste un outil puissant pour une petite quantité de postes ou de serveurs (- de 2000).

      En espérant que cela t’aide !
      David.

      • hik3 dit :

        Hello,

        Merci pour ta réponse :). Je suis toujours plongé dans mes recherches / évaluation mais effectivement ceux qui font de tout (un bon gros CMDB bien complet) coûtent une fortune. Pour l’instant j’arrive à peu près à un tandem : GLPI (ticketing / KB) + Whatsup Gold (monitoring) + Desktop Central 8 (inventaire / patch management / app deployment) + .

        Voilà peut-être que mon commentaire donnera des idées à certains. En tout cas je suis preneur de ce genre d’article ^^.

  2. jt dit :

    linkbynet utilise quel outil de ticketing svp monsieur

    • David dit :

      Bonjour !
      Linkbynet utilise « Idefix » un outil de gestion IT développé en interne, adapté aux particularités du métier de LBN.
      David.

Laisser un commentaire

*