Nouvelle mission chez EDF

Missions et références

Depuis juin 2012 : Architecture technique SAP chez EDF :

  • Etude de fusion des 8 instances SAP FI/CO pour la comptabilité EDF
  • Etude d’un parcours de migration vers une solution de Cloud Computing pour SAP
  • Rédaction de DATs (Document d'Architecture Technique) décrivant l'interface entre les besoins métier, les exigences de disponibilité/sécurité/confidentialité, les fonctionnalités du progiciel et les contraintes de production de l'infogérant
  • Migration de 90 instances SAP : ECC6, BW, Sap Content Server, SAP PI, SAP GRC, Solution Manager : Interface entre la MOA EDF, la DSI EDF et l'infogérant

 

De février à mai 2012 : Groupe Casino à Saint-Etienne avec les objectifs suivants :  

  • Rationaliser et améliorer les procédures de copie/refresh d'instances SAP
  • Gérer le projet de migration OS/DB de Windows/SQL Server vers Aix/DB2 de l'instance SAP orienté FI/CO
  • Mener des campagnes de mesure et d'amélioration de performances SAP
  • Qualifier et spécifier la mise en œuvre du monitoring des Business Processes avec Solution Manager
  • S'intégrer à l'équipe de support N3 et y apporter son expertise

 

Décembre2011-Janvier 2012 : OTAN CEPMA (Central Europe Pipeline Management Agency)

Mise en oeuvre d'un PRA pour la production Oracle/SAP

Réalisation technique :

  • Reprise de l’instance de production sur un serveur de secours
  • Import ZFS des volumes répliqués au niveau de la baie de disques Compellent
  • Paramétrage Oracle et SAP
  • Recette technique et fonctionnelle

 

De janvier à septembre 2011 : Tereos (Industrie du sucre et des céréales)

Définition de l'architecture technique permettant d'exécuter les nouveaux environnements de production

  • SAP ECC6 et Business Objects BI 4.0 : 40 000 SAPs
  • Autres environnements SAP : GRC, APO, TDMS
  • CI/DB Serveurs Sun M9000 + SAN HDS AMS2500

Gestion du projet de déploiement

  • Rédaction du Plan Qualité de Projet
  • Rédaction et suivi de planning
  • Coordination des intervenants

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. 

 

Disponibilité en % 

Indisponibilité par année 

Indisponibilité par mois 

90 % ("un neuf") 

36,5 jours 

72 heures 

95 % 

18,25 jours 

36 heures 

98 % 

7,30 jours 

14,4 heures 

99 % ("deux neuf") 

3,65 jours 

7,20 heures 

99,5 % 

1,83 jours 

3,60 heures 

99,8 % 

17,52 heures 

86,23 minutes 

99,9 % ("trois neuf") 

8,76 heures 

43,2 minutes 

99,95 % 

4,38 heures 

21,56 minutes 

99,99 % ("quatre neuf") 

52,56 minutes 

4,32 minutes 

99,999 % ("cinq neuf") 

5,26 minutes 

25,9 secondes 

99,9999 % ("six neuf") 

31,5 secondes 

2,59 secondes 

 

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. 

 

Écrire commentaire

Commentaires: 0