Pourquoi le SLA ne suffit plus

Dans la pratique,  le SLA tend à se confondre avec un niveau de disponibilité exprimé en pourcentage de temps.  Et l’on parle de 99,xxx avec le plus de « neuf » possibles. Les derniers « neuf » sont les plus difficiles à atteindre. 

En théorie, un SLA recouvre plus que la simple disponibilité de l’application, puisqu’il faudrait définir dans quelles conditions on accède à l’application (temps de réponse, propreté et sécurité des données, niveau de support, etc..) De plus, une application n’est jamais toute seule dans son coin. Elle a toujours besoin de données en entrée qui dépendent d’autres secteurs du paysage applicatif ; elle a aussi besoin de pouvoir  exporter ses propres données. Un exemple classique est le système d’impression qui, s’il est défaillant, ne permet plus d’imprimer de bon de livraison. L’application elle-même est opérationnelle, mais le système d’impression bloque la livraison physique des marchandises, et donc l’activité métier. À quoi sert alors cette application si la sortie physique du processus n’est plus assurée ? De proche en proche, on en viendrait à gérer un taux de disponibilité pour toute l’entreprise, et au-delà,  pour l’entreprise et ses partenaires. Comme ça n’est pas possible, on se contente, dans la pratique, de se concentrer sur une application critique, considérée comme autonome, et pour laquelle il s’agit de pouvoir garantir un certain taux de disponibilité.

Supposons donc que l’on ait réduit le périmètre à une application critique de l’entreprise. D’où vient cette notion de SLA ?

D’après ce graphique, récupéré sur le site d’Orsyp, la notion de SLA est apparue au cours des années 1990. Après les années 80 qui voient éclore les projets de migration de Mainframe vers les architectures ouvertes, client-serveur Unix, les années 1990 sont les années de diffusion ITIL, de la préoccupation du service client et donc de la contractualisation des niveaux de service : notre SLA.

Arrivent les périodes de crise et l’explosion de la bulle Internet qui voient les financiers reprendre la main et le contrôle des coûts. Après quelques années d’euphorie et de croissance à deux chiffres pour l’industrie informatique, l’atterrissage est brutal.  Une entreprise comme SunMicroSystems voit son chiffre d’affaire chuter de 40% en un an.

« In the manic late 1990s and just beyond, Sun's revenue soared past $5 billion per quarter as the company profited from products well-suited to the Internet boom. But Sun has had to grapple with the bust that followed, which combined a gray market of used equipment, a recession, deep price cuts, increasingly capable servers using Intel processors, and reinvigorated competition from IBM. Its revenue now is about $3 billion per quarter. »

En regardant ce graphique, il est frappant de constater comment les tendances de l’informatique sont ainsi corrélées aux grands mouvements qui orientent les économies occidentales. Car l’euphorie Internet s’est assez vite retournée, les réseaux se sont mis au service de la finance et du trading, avec les résultats que l’on sait, et dont on paie les conséquences aujourd’hui.

Mais il n’y a pas que ça, et pour revenir à notre sujet, les entreprises se sont aperçues que la course au troisième, au quatrième, voire au cinquième « neuf » oblige à mettre en ligne des infrastructures de plus en plus lourdes, de plus en plus chères. En plus, les infrastructures ne suffisent pas, puisque ces architectures à haute et très haute disponibilité demandent également des équipes extrêmement bien formées pour les maîtriser et les opérer. Les logiciels de haute disponibilité, de gestion de cluster ne sont pas eux-mêmes exempts de bugs et, en dehors de leur complexité intrinsèque, amènent parfois une fragilité parasite. Et QUI a vraiment besoin d’avoir une durée d’arrêt maximum de quelques minutes plutôt que de quelques heures ? En tous cas, on peut s’interroger sur la réelle valeur ajoutée de ce temps  gagné.

Dit différemment, on pourrait dire que la décennie 1990-2000 sont les années du toujours plus : de croissance, de technologie, de disponibilité. Les années 2000-2010 sont les années finance ; et peu importe les besoins, la qualité et l’adéquation de la solution avec le métier.  L’important c’est le chiffre en bas à droite, pour qu’il soit le moins élevé possible. Nous voici bientôt au milieu des années 2010 avec une croissance qui s’essouffle, qui, très probablement, ne sera plus jamais aussi rapide qu’auparavant. Et les contraintes financières sont toujours présentes. Dans un système fini comme la terre, qui atteint ses limites physiques, une croissance infinie est impossible et butera sur la clôture  de l’environnement. Et comme  le tout-finance nous a menés dans l’impasse, voici venues les années du développement durable, de la fin du gaspillage et des énergies renouvelables.

L’informatique est en telle symbiose avec le monde environnant qu’elle ne peut pas échapper à ces tendances.

Si bien que le niveau de service ne peut plus se définir en termes de disponibilité pure et de nombre de « neuf ». Il faut prendre en compte les moyens qui permettent d’atteindre le niveau de service attendu ; celui-ci étant vraiment en adéquation avec les besoins, et non plus positionné au maximum de la  technologie comme auparavant. On entre dans le monde de l’efficience, c’est-à-dire que l’on va mesurer si la bonne quantité de ressources a été utilisée, pour un processus, un service ou une activité. Un processus efficient atteint ses objectifs avec un minimum de temps, d’argent, de personnes ou d'autres ressources.

Chacun connaît les 24h du Mans. Il y a celui qui arrive au bout des 24 heures de course en ayant parcouru le plus de kilomètres. Et peu importe les moyens utilisés, la cylindrée et la puissance du moteur. Et puis, il existe aussi l’indice énergétique  qui est déterminé par le rapport entre la vitesse moyenne d’une voiture, hors arrêts au stand, et la consommation moyenne de carburant pendant toute la durée de la course.

Aujourd’hui le vrai vainqueur, même s’il ne fait pas les grands titres de la presse, ce devrait être celui qui remporte l’indice de rendement énergétique. Et pour une informatique moderne et efficiente, c’est bien ce calcul, plus complexe que le simple SLA, qui va devenir déterminant.