ITIL V3 et la disponibilité

        ITIL apporte tant de progrès à la qualité des services informatiques que l’on rend à nos clients qu’il faut commencer par lui reconnaître cette avancée. C’est d’ailleurs à l’occasion de la suite de mon parcours de formation que me sont venues d’autres types de remarque.

Je viens en effet de suivre un module de formation intitulé PPO  (Planification, Protection et Optimisation). On y traite de 5 processus Itil : la gestion de la demande, la gestion de la capacité, la gestion de la disponibilité et la gestion de la continuité. Ce sont de ces deux derniers que je veux parler maintenant.

Je ne sais pas si c’est ITIL qui a inventé la notion de SLA, mais c’est sûrement l’une de ses notions clé qu’il aura réussi à populariser largement. On peut d’ailleurs en discuter certaines limites comme je l’ai fait récemment . J’attendais donc avec intérêt de rentrer dans le détail du processus de gestion de la disponibilité. De plus, d’un point de vue de ma carrière professionnelle, cela fait sans doute plus de 15 ans que j’ai eu affaire à ce genre de question. C'est-à-dire, comment ajuster au mieux le compromis entre une demande souvent excessive  (24/24 7/7), des technologies parfois défaillantes, des équipes à former et de nouvelles habitudes à prendre.

Chez Sun, comme chez d’autres sans doute, on appelait ça les 3 Ps : People, Process, Product. Et comme l’on vendait des « products », on était très fier d’insister sur le fait que c’était le moins important des 3 Ps. J’ai été heureux de retrouver cette notion dans l’introduction au livre ITIL consacré à la conception de services (Service Design). Les 3 Ps y sont maintenant 4 puisque ITIL y ajoute le Partner. Et si l’on insistait sur le People, c’est bien que les statistiques de notre support démontrait que la plupart des pannes provenait de fautes humaines ou de procédures et documentations mal rédigées ou mal comprises. Autrement dit, les défaillances matérielles ou logicielles ne représentent que 20% des causes de panne. Il m’aurait paru intéressant de décliner les 3, devenus 4Ps tout au long des différents processus du service design. Au lieu de cela, on a droit à un ensemble d’activités à mener qui n’ont rien de spécifique à la question de la disponibilité. 

Le comble est atteint par une technique décrite comme proactive, alors qu’elle est par ailleurs clairement décalquée sur la gestion de problèmes. Il s’agit de « Service Failure Analysis (SFA) dont voici un descriptif :

Difficile de faire plus vague et plus générique.  Plus loin, on nous dit aussi que les coûts grimpent avec l’exigence de disponibilité ; ce qui n’est pas une information qui aurait pu nous échapper.

On dirait que les rédacteurs ITIL, à force de vouloir rester à un niveau de généralité qui puisse se décliner dans tous les cas ont laissé en route tout ce qui fait le propre de la gestion de la disponibilité.

On ne retrouve pas les mêmes manques dans la gestion de la continuité. J’avoue que j’ai eu longtemps un peu de mal à admettre la séparation en deux processus de la disponibilité et de la continuité. Dans la pratique ce sont les mêmes personnes qui s’en occupent et la barrière entre les deux est assez mince. ITIL la justifie en définissant la gestion de la disponibilité comme le soutien  des SLAs en mode normal, et la gestion de la continuité comme la gestion de l’exception et de la reprise de l’IT après un désastre. Par ailleurs, et là encore ça paraît être une position de bon sens, le plan de continuité informatique doit être complètement aligné sur le plan global de continuité de l’entreprise, alors que la disponibilité répond techniquement à des besoins de l’entreprise, sans qu’un dispositif global de disponibilité soit défini à ce niveau, en dehors des plannings du personnel. Le mot continuité est d’ailleurs trompeur, puisque dans ITIL, cette gestion de la continuité est un plan qui ne se déclenchera qu’après rupture de cette continuité. Ceci étant dit, j’ai bien apprécié dans  la gestion de continuité ITIL un outil nommé BIA (Business Impact Analysis). Je le pratiquais de manière informelle en classifiant avec le client les applications suivant leur criticité, et donc celles qui devaient être protégées en priorité, mais je ne l’avais jamais élaboré de manière aussi précise que ce que propose ITIL. Il s’agit d’un tableau dans lequel on répertorie chaque service avec son impact décliné suivant diverses dimensions :

• Impact financier, réglementaire, en image de marque, en service au client
• Nombre d’utilisateurs en mode nominal, et nombre d’utilisateurs minimum  nécessaire au bon fonctionnement du service
• Horaires d’ouverture du service
• Existence d’une procédure manuelle de secours (retour au traitement papier)
• Interfaces avec  les autres services

De cette manière, on peut qualifier complètement la criticité du service et en définir une stratégie de continuité.

Je m’attendais donc à ce que celle-ci se donne comme objectifs essentiels des temps de retour du service et de perte de données maximales admise. Ces deux paramètres sont connus sous le nom de RTO et RPO en anglais et DIMA et PDMA en Français. Mais, à ma grande surprise, ITIL ne cite pas ces éléments essentiels d’un plan de continuité. En tous cas, pour ma part, je ne sais pas bâtir ce plan sans positionner ces valeurs centrales.

A l’issue de cette formation, je suis donc un peu frustré par ces manques de ITIL dans un domaine pourtant primordial et qui devrait constituer le fer de lance de cet ensemble de bonnes pratiques. Lors de l’examen qui clôt la session, il faut donc faire un exercice assez délicat de semi-oubli de notions qui me semblent pourtant primordiales, pour recoller à des pratiques un peu obsolètes, tout en conservant une bonne compréhension de la situation proposée dans l’exposé de la question. C’est sans doute quand on maîtrise suffisamment son sujet que l’on arrive à tirer la meilleure part de conseils génériques et de sa propre expérience.  C’est en tous cas ce que je m’efforce de faire et de proposer à mes clients.