DevOps et l organisation des DSI Les Livres Blancs de MARTE : sept questions incontournables du DG au DSI Les géants américains de l internet ont popularisé une nouvelle organisation des DSI, appelée DevOps, qui améliore significativement la réactivité et la qualité de l informatique, et pose ainsi un nouveau défi aux entreprises et aux DSI traditionnelles qui ont emprunté d autres voies. Voyons sept questions que tout DG ne manquera pas de poser prochainement à son DSI sur ce sujet d importance. Livre blanc rédigé par Alain Sacquet Septembre 2014
Comment caractériser DevOps? DevOps est un mot formé de la contraction du mot «développement» et du mot «opérations» qui correspond au mot français «production». DevOps est une approche qui prône le rapprochement des équipes de développement informatique et d exploitation dans le but d améliorer la réactivité des DSI et de diminuer la durée comprise entre la demande de la modification d un service IT et sa mise en ligne. Les méthodes agiles de développement issues de la démarche Lean d optimisation des organisations d origine japonaise sont ainsi étendues à la production informatique. La méthode Lean vise la suppression progressive et continue de tout type de gaspillage et requiert la collaboration de l ensemble des acteurs. Scrum est par exemple un mode de développement agile qui évite la réalisation de fonctionnalités inutiles, et s appuie sur des itérations courtes consacrées aux attentes prioritaires. Les gaspillages DevOps s attaque de même aux gaspillages que génèrent: Les délais de mise à disposition des infrastructures de développement ou de production Les délais dans la mise en production des applications du fait d un grand nombre de tâche manuelles Un processus de changement en production beaucoup trop long et bureaucratique, alors qu il est inutile de demander aux productions de comprendre le contenu de chaque changement applicatif lorsqu il s agit par exemple d une modification du paramétrage de règles de gestion du métier. Réactivité et stabilité Le manque de réactivité des Opérations conduit à présenter cette structure comme un silo fermé sur lui-même. Ce fonctionnement est dû selon les tenants de DevOps au fait que les opérations sont missionnées sur la «stabilité» de la production, alors que les études sont incitées au contraire à produire de nombreuses «évolutions» pour satisfaire leurs clients et à aligner ainsi en continu les fonctionnalités des services rendus par les logiciels sur les besoins des métiers. Le «build», le «run» et les «services IT» Cette divergence s explique aussi selon eux par la focalisation des études sur le service quotidiennement en ligne, alors que les productions seraient restées sur une vision basée sur les applications qui distingue leur développement (le build) et leur exploitation (le run). Les partisans de DevOps considèrent cette vision obsolète. Les solutions Les solutions reposent donc essentiellement sur : La mise à disposition des infrastructures et des environnements à la demande 2 Septembre 2014
conformément aux fonctionnements des Clouds La suppression des tâches manuelles dans les opérations, à commencer par les mises en production L acceptation automatique des changements applicatifs L accès à la supervision et aux messages d erreur applicatifs pour les équipes études DevOps est donc prôné par les «Dev». Qu en disent les «Ops»? La stabilité du fonctionnement Les productions expliquent que si leur attachement à la stabilité est bien réel, il faut l entendre comme la stabilité du fonctionnement des services IT en production, et pas du tout comme la stabilité du périmètre des services! Le problème avec la modification du périmètre des services, c est à dire avec les mises en production, vient de ce qu elle entraîne de nombreux incidents parfois dus à des erreurs lors des opérations d installations de nouvelles versions, mais aussi dus très largement à la mauvaise qualité des logiciels fournis, ou aux régressions qu une mauvaise gestion des versions entraîne. La principale raison d être de la définition d un nombre limité de dates autorisées de mise en production n est pas le besoin de tranquillité des productions, qui voient au contraire leur charge d installation concentrée sur quelques jours, mais bien d obtenir une période de rémission suffisante dans les défauts de fonctionnement des services IT après les corrections consécutives à la dernière vague d installation! De même les difficultés d installation résident souvent dans une définition erronée ou incomplète des actions à mener demandées par les études. Les logiciels inaptes à la mise en production Les livraisons de logiciels inaptes à la mise en production mettent l exploitation en défaut par rapport aux engagements qu elle prend quant à la disponibilité des services IT pour les utilisateurs et expliquent la réticence des exploitants à une augmentation de leur fréquence. Le «build», le «run» et les «services IT» Par ailleurs, l idée américaine que les productions seraient en retard dans la perception de l importance des «services» rendus aux utilisateurs est sans objet dans le cas des productions européennes qui sont beaucoup plus en avance que leurs semblables américaines sur l adoption du référentiel de bonnes pratiques d origine anglaise connu sous le nom d ITIL qui met cette notion au centre de ses préconisations. Les productions récusent en fait aussi bien le parallèle implicite entre études/production et Build/Run que celui déjà décrit entre études/production et réactivité/stabilité. En effet une production n est pas l entité en charge du «Run», alors que les études seraient en charge du Build. Les études participent à l exploitation des services à au moins deux 3 Septembre 2014
titres : Elles sont impliquées dans le diagnostic et la résolution d incidents lorsqu ils touchent la couche applicative et elles mènent souvent des vérifications quotidiennes du bon fonctionnement des traitements critiques pour le compte des métiers. Les études ne sont pas davantage l organisation exclusivement en charge de la fabrication des services (Build), puisque les productions créent, à l occasion des mises en production, les paramétrages qui permettent aux logiciels proprement applicatifs d utiliser les outils d infrastructure : paramétrages des serveurs d application, des ordonnanceurs de traitements, des outils de sauvegarde ou d archivage, de surveillance, etc. Ces paramétrages sont appelés «objets de production». Mission et organisation actuelle de la DSI En revanche, les productions ne disconviennent pas que le fonctionnement en vigueur n est pas optimal. En effet, par construction, les productions traditionnelles sont constituées des seuls personnels habilités à intervenir sur les machines de production. La raison historique de ce choix est la sanctuarisation de ressources nécessaires et suffisantes à la fourniture des services aux métiers. La mission de la DSI, qui consiste essentiellement à fournir des services alignés sur les besoins métiers et dotés d une sûreté de fonctionnement correcte, ne coïncide donc pas avec le découpage actuel entre département études et productions : Si les études sont seules en charge de l alignement fonctionnel, la sûreté de fonctionnement de la couche applicative implique assurément les deux structures. L exploitation ne peut pas être tenue seule responsable des dysfonctionnements des services IT en production du simple fait qu elle est la première à les constater et la seule à disposer des accès pour les réparer. L intérêt de DevOps est de résoudre très différemment la difficulté que cette double mission représente. Face à la pression des métiers qui menacent de recourir directement à un intégrateur et à des solutions Cloud, quels pas en direction de DevOps la DSI peut-elle faire à court terme? Des efforts peuvent être menés aussi bien du coté Etudes que Production pour se rapprocher du modèle DevOps et gagner en réactivité. Les évolutions souhaitables de la production La production peut agir sur plusieurs fronts : La constitution d un «cloud» interne pour fournir les solutions d infrastructure sous forme de services automatisés et facturés à la consommation. L automatisation des mises en production et des procédures d installation sur les différents environnements. La mise à la disposition du service de développement, d informations et de 4 Septembre 2014
procédures lui permettant de s impliquer dans la «stabilité de la production» et d améliorer, en relation avec le département d Exploitation, la sûreté de fonctionnement des services IT : o Automatisation des procédures d installation des correctifs. (La solution est celle qui automatise les MEP et pilote les arrêt/relance sans défaillance.) o Automatisation des remontées de compte rendu d exécution pour les programmes en erreur o Routage des alertes concernant les applications lorsqu on peut les distinguer des alertes d infrastructure o Partage des informations de tenue à la charge o Mise en place d une solution générique permettant de suivre l activité métier en temps réel en la comparant au fonctionnement nominal attendu (Business activity monitoring) o Mise à disposition des consommations et des besoins capacitaires constatés par application o Automatisation des consignes de reprise en cas d incident Les évolutions souhaitables des études Pour ce qui concerne le département d études, la diminution des tensions DevOps passe par la fourniture de logiciels prêts à aller en production : Amélioration des tests Mise en place de solution de gestion de version des logiciels et d intégration qui alimentent l outil d installation et de déploiement en production Augmentation de la robustesse des logiciels qui ne doivent pas défaillir lors de la réception de flux de données incorrects Emission de messages d alertes pertinents Fourniture d éléments permettant de prévoir les besoins capacitaires Conception et mise en place de messages alimentant des tableaux de bord temps réel de suivi du bon fonctionnement et du volume d activité métier. Deux équipes contribuent à l évolution vers DevOps La réactivité du processus de développement et la sûreté de fonctionnement en production poursuivies par DevOps peuvent également être approchées par le renforcement de deux équipes existantes. La première est l équipe à l articulation des études et de la production, en charge des tests et de la préparation du plan de déploiement. Cette entité supervise le flux des versions (Planification et support ; gestion des releases) et améliore le biseau entre les activités des ressources études et production. Elle fournit de la visibilité à la production sur les pics de charge et peut fournir un avis objectif sur la sûreté de fonctionnement prévisible des nouvelles versions d applications. Dans une trajectoire DevOps une telle structure est temporaire. Son rôle est d assurer la conduite du changement pour quitter le mode en silo ainsi que d être le maitre 5 Septembre 2014
d œuvre des améliorations nécessaires de l ingénierie. La seconde est l équipe d architecture et de normes, directement rattachée au DSI, qui peut légiférer sur les caractéristiques des logiciels afin qu ils puissent être déployés rapidement, surveillés, arrêtés et redémarrés sans crainte. Cette entité définit les infrastructures de référence de l entreprise. Elle veille enfin à l absence de dérive bureaucratique des procédures qui régissent les changements en production. Le principe «you build it, you run it» n est-il pas une définition organisationnelle plus radicale de DevOps? Effectivement, les améliorations précédemment décrites, pour significatives qu elles soient, ne bouleverseront pas les DSI. Les productions sont par exemple tout à fait en mesure de proposer des infrastructures sous forme de service dans leur périmètre actuel. La question clé est de savoir si l organisation habituelle des DSI permet de conduire les autres améliorations identifiées comme nécessaires depuis de nombreuses années et qui concernent essentiellement les processus situés à l articulation des études et de la production, ce que le standard des bonnes pratiques ITIL appelle la «transition des services» : gestion des mises en production (release management and deployment), gestion des changements, test et validation des services. DevOps change l organisation de la DSI La réponse DevOps à cette question est radicale : il faut changer l organisation de la DSI. La solution utilisée par les géants de l internet est basée sur un principe simple, exprimé par Werner Vogels, CTO d Amazon: We have this principal of you build it, you run it.you are responsible for what the customer sees, in short. Une seule équipe fabrique le logiciel et l exploite dans la durée. La mission majeure de la DSI étant de fournir des services alignés sur les besoins du métier et fiables, l organisation des équipes se fait tout simplement par ensemble de services IT ou groupe d applications. Le pivotement vers une organisation par couches logicielles La promesse tenue de réactivité repose sur le pivotement de l organisation d une spécialisation par les ressources : machines de développement d un coté et de production de l autre, vers une spécialisation par couches, infrastructure d un coté, puis objet de production applicatif et application de l autre. Les objets de production sont tous les paramétrages des outils d infrastructure qui permettent le fonctionnement d une application. Ils sont aujourd hui créés par la production à l occasion des MEP car ces actions nécessitent des droits sur les ressources de production. Dans la version organisationnelle de DevOps, la 6 Septembre 2014
création de ces éléments passent sous la responsabilité de l équipe applicative DevOps. Les outils eux-mêmes relèvent de l infrastructure. Une infrastructure enrichie Une équipe spécialisée sur l infrastructure fournit en interne les services à la demande que proposent les acteurs du Cloud, mais avec une infrastructure enrichie par les outils permettant d automatiser les mises en production et les installations sur l ensemble des environnements, ainsi que les outils permettant de faire du suivi du volume d activité pour le métier (BAM). Cette entité fournit évidemment le support opérationnel aux équipes applicatives DevOps dans leur mise en œuvre de ces solutions ainsi que sur les outillages habituels d ordonnancement des traitements ou de sauvegarde. Elle fonctionne comme un centre d expertise dont les ressources peuvent être réservées par les équipes applicatives selon leurs charges. Elle fabrique et exploite au quotidien l infrastructure. La sûreté de fonctionnement enfin atteignable Un aspect particulièrement vertueux de cette organisation est que la responsabilité de la sûreté de fonctionnement des applications se trouve affectée à ceux qui ont le moyen de la construire. L équipe applicative DevOps constituée pour augmenter la rapidité du processus de développement, va pouvoir fiabiliser l installation des corrections des services IT, modifier les procédures de reprises automatiques en cas d incidents, mettre en place des tableaux de bord temps réel de suivi du volume d activité et de bon fonctionnement, et même architecturer l application pour la rendre exploitable. L équipe a à la fois la mission d exploiter les logiciels dans la durée et les moyens de rendre leur fonctionnement sûr. Quels sont les apports et les limites de cette modification de l organisation de la DSI? Les grandes entreprises d internet témoignent de l atteinte effective des objectifs visés : le délai entre l expression d un besoin et la mise à disposition d une nouvelle version d un service en ligne est fortement raccourci pendant que les dysfonctionnements en production sont plus rapidement corrigés. Une organisation qui facilite la transformation du processus de développement Qualitativement, il est aisé de comprendre que ce choix organisationnel radical favorise, par exemple, l amélioration de la gestion des versions applicatives et leur déploiement. En effet, les mêmes acteurs réalisent les installations des composants logiciels sur les environnements d intégration, de qualification et de production. Ils convainquent plus facilement leur chef unique de l intérêt de l automatisation d un processus aujourd hui à cheval sur deux silos. De même, les différentes actions listées précédemment, tant du coté des départements 7 Septembre 2014
études que production, trouvent plus facilement un soutien hiérarchique sans avoir à remonter jusqu au DSI lui-même. Le support applicatif en production n existe plus à proprement parler, il est assuré par l équipe applicative DevOps. Inutile désormais d expliquer l impact du changement à une équipe mutualisée de support en production. Les nouveaux silos Cette organisation n a cependant pas que des avantages : les dysfonctionnements à réguler découlent des nouveaux silos propres à cette nouvelle organisation! En effet, lorsque l on spécialise les équipes selon qu elles ont ou non des droits sur les machines de production, la production devient un silo, et donc les développements un autre. De même, lorsque l on s organise par services IT fournis aux clients, les silos correspondent à ces ensembles de services auxquels il faut ajouter l infrastructure. Les tensions sont donc à rechercher entre les différents silos applicatifs et entre les applications et le silo d infrastructure. Pour diminuer les tensions aux frontières applicatives les interfaces doivent être convenues et leur respect gravé dans le marbre. On dit ainsi que le respect des interfaces est écrit dans les contrats de travail des informaticiens de certains géants du Net. La «dette technique» vis-à-vis de l infrastructure Les tensions vis-à-vis de l infrastructure résident dans la qualité du catalogue des versions d infrastructure proposées aux applications et inversement, dans la limitation de la «dette technique» contractée par les équipes applicatives. En effet, lorsqu une application refuse de faire les montées de versions qui dispensent la production de gérer des infrastructures obsolètes, elle augmente sa «dette technique» et le coût de fonctionnement de la structure en charge de l infrastructure. La refacturation devient alors un sujet sensible pour peu que le coût d entretien des infrastructures obsolètes soit mutualisé, car il augmente d autant le prix que le marché est susceptible de proposer pour les infrastructures à la page. Un mécanisme de concurrence faussée entre les productions internes et les offres Cloud, un peu similaire à celui qui semble prévaloir entre les cliniques privées et l hôpital public tenu d accepter toutes les pathologies peut se mettre en place. Le mécanisme de gestion des changements doit être conservé car il convient également pour réguler les dysfonctionnements des nouveaux silos dans le cas d impact d une modification applicative sur les autres domaines applicatifs, ainsi que pour les changements d infrastructures à l initiative des exploitations lorsqu ils ne sont pas transparents pour certaines applications. Une gouvernance toujours nécessaire Une gouvernance globale de l architecture applicative et de la trajectoire des infrastructures est donc à mettre en place pour éviter les effets 8 Septembre 2014
pervers prévisibles de la nouvelle spécialisation organisationnelle. Le maintien d une certaine standardisation permet de mutualiser les achats, de capitaliser sur les meilleurs pratiques ainsi que de faciliter les évolutions internes des personnels. Réactivité fonctionnelle et sûreté de fonctionnement Malgré ces défauts, il semble bien, sur le papier aussi, que cette organisation présente beaucoup plus d avantages que l organisation des équipes par environnement. L aspect le plus séduisant de ce choix est que la solution organisationnelle retenue par DevOps permet d améliorer non seulement la réactivité mais aussi la construction de la sûreté de fonctionnement. DevOps serait-il la manifestation d une autre façon de «faire de l informatique» dans l entreprise audelà même d un changement d organisation des DSI? Le bouleversement DevOps des DSI ne s arrête effectivement pas au pivotement de l organisation d une approche par machine, vers une approche par couche logicielle : Les équipes applicatives DevOps constituent non seulement un basculement de «spécialisation» organisationnelle, mais aussi un changement radical du «mode» d organisation. Le changement du «mode» d organisation Selon le vocabulaire Lean, DevOps revient en effet à organiser les équipes en Unités Autonomes de Production (encore appelées atelier flexible ou îlot autonome) qui s opposent au mode «ligne» (encore appelé taylorisé ou fordiste). Les nouvelles équipes applicatives agiles regroupent en effet en «ateliers intégrés» les différentes activités réparties jusque-là linéairement sur différentes équipes dans le modèle en cascade, depuis l expression de besoin jusqu à la mise en production et la surveillance. Le Lean management ne s interdit en effet pas de remettre en cause l organisation de la chaîne de fabrication d un processus. Seule compte la performance dans la chaîne de valeur et la réactivité. Les modes «ligne» ou en «ateliers intégrés» sont également possibles. Unités Autonomes de Production et mode «ligne» L intérêt du passage d une chaîne taylorisée à une organisation en UAP s analyse selon les critères Lean de lutte contre les gaspillages qui restent pertinents, malgré le caractère immatériel de la production logicielle : attente, effort pour communiquer d un poste à l autre, maîtrise des flux dans la chaîne, changement de produit, changement fréquent de tâche... Remarquer que DevOps correspond à un mode d organisation en atelier intégré incite à réfléchir aux modifications des aspects économiques, 9 Septembre 2014
humains, d externalisation, ou de gestion de la connaissance qu entraîne l adoption de ce modèle et à redécouvrir le coté taylorisé du fonctionnement des DSI actuelles. Fordisme du fonctionnement traditionnel Le modèle en vigueur se caractérise par un processus de développement séquentiel, de l expression des besoins, au codage, test, mise en service jusqu au décommissionnement applicatif. Il s agit bien là d un modèle fordiste, où chaque activité successive est confiée à un acteur différent quitte parfois, comme en France, à créer le nouveau métier de maîtrise d ouvrage. Lorsque la DSI recourt à l externalisation, les ruptures de responsabilités se font à deux niveaux : par la succession des fournisseurs dans le temps ainsi que par tâche opérationnelle. Les applications voient leurs développements confiés à un intégrateur externe qui sera remplacé par une société de tierce maintenance applicative, dès le projet formellement fini. Le DSI évite ainsi la critique selon laquelle l intégrateur aurait réussi à s installer chez lui en raison de sa connaissance du logiciel qu il a développé, tirant alors les prix de maintenance vers le haut. Le contrôle des fournisseurs est préféré à la connaissance de long terme sur le logiciel. Il n est pas rare non plus, pour des raisons de maîtrise comptable ou afin de limiter les risques d une externalisation, que deux équipes soient en charge du même logiciel : une pour la maintenance à court terme et les petites évolutions, l autre pour les projets. Ce découpage se prolonge jusqu à la mise en production : deux équipes distinctes sont en charge des MEP pour les maintenances courantes et pour les projets plus conséquents. Le découpage des responsabilités se fait aussi par tâche : chacune transforme les éléments transmis et ajoute sa contribution. Idéalement, les éléments transmis ne nécessitent pas la compréhension globale des travaux en cours : le codage se suffit de la description technique de la solution, elle-même issue de la transformation des exigences. Le codeur peut rapidement passer d une partie d un logiciel à une autre; d un logiciel à l autre. Le testeur, ou la société spécialisée, qui reçoit les plans de test réalise une tâche encore plus banalisée. De même pour les activités de mise en production ou de pilotage de l exploitation. Afin de limiter le coût de chaque activité, de nombreux intervenants se succèdent donc, sans connaissance globale du produit auquel ils collaborent, conformément à l optimum fordiste qui est atteint lorsque chaque tâche peut être effectuée unitairement par une personne la moins qualifiée possible. L optimisation Lean du modèle fordiste conduit à la mutualisation de chaque étape pour toutes les applications, puis à la mise en place d outils de workflow de façon à réaliser le convoyage du logiciel, d un poste de travail à l autre et à optimiser capacités de traitement et flux de travail, comme pour tout autre processus industriel ou administratif. 10 Septembre 2014
Mode «ligne», mutualisation et externalisation sélective On assiste ainsi toujours, dans les grands groupes financiers par exemple, à la mutualisation des productions informatiques pour toutes les branches de l entreprise, occasion de constituer des équipes conséquentes spécialisées dans la seule mise en production par exemple. Chaque équipe peut alors faire l objet d une externalisation. Globalement dans cette approche économique et méthodologique, la contribution des informaticiens internes est limitée, la connaissance des logiciels est diffuse et renouvelée, le recours à l externalisation recherché et l investissement technique réduit à son minimum. Les équipes applicatives DevOps sont autant d unités autonome de production au sens Lean Le modèle DevOps déjà présenté est l exact opposé de ce paradigme. Il se développe dans les sociétés telle qu Amazon où l entreprise est perçue par ses clients à travers son informatique. L informatique est inséparable du modèle d affaire de l entreprise. Amazon est autant une société de haute technologie qu un logisticien des petits colis. L atelier flexible réunit des informaticiens aux compétences multiples, vise l intelligence du produit, la réactivité et la proximité des métiers. L unité autonome de production traite durablement l ensemble des besoins d évolution du service IT dont elle s occupe en continu. La performance est obtenue par une ingénierie de haut de gamme et l investissement dans les outils de développement aux mains d ingénieurs de haut niveaux susceptibles de tirer partie de leur puissance et qui font l objet d une réelle considération dans l entreprise. L engagement collectif dans la durée contribue à la motivation des ressources dont le coût unitaire n empêche pas du tout la rentabilité d un modèle d une très grande productivité tant globale qu individuelle et permet le développement rapide de logiciels fiables, alignés sur les besoins des métiers. Il n existe cependant évidemment pas d étude quantitative probante, sur une base statistique, démontrant la supériorité d un mode sur l autre, toutes choses égales par ailleurs dans le monde du développement logiciel. L intérêt de DevOps ne peut donc être prouvé, et son adoption revient heureusement à chaque équipe dirigeante qui doit se forger sa propre opinion. Son succès chez les géants du net en fait, quoi qu il en soit, un exemple pour les sociétés qui, sans être des sociétés internet, interagissent significativement avec leurs clients par ce biais. DevOps : un nouveau paradigme des technologies numériques en entreprise L efficacité, la cohérence globale, la compatibilité avec les offres Cloud mais aussi la différence foncière de ce paradigme avec celui qui domine depuis de nombreuses années, notamment en France expliquent le choc créé et l intérêt suscité par DevOps. 11 Septembre 2014
DevOps dans sa déclinaison organisationnelle radicale apparaît comme une alternative à la manière actuelle de prendre en compte l informatique de gestion, autrement dit un nouveau paradigme des technologies numériques en entreprise. Comment introduire DevOps dans les entreprises traditionnelles? DevOps sous sa forme organisationnelle repose sur une répartition foncièrement nouvelle des responsabilités au sein d une DSI. Or les sociétés comme Amazon n ont jamais connu de transformation du modèle traditionnel vers le modèle DevOps puisqu elles sont nées en DevOps. Comment s y prendre dès lors pour obtenir le meilleur des deux mondes dans les sociétés organisées de façon traditionnelle, mais dont la performance informatique doit se rapprocher impérativement de celle qu apporte le nouveau modèle, au moins pour une partie significative de leurs applications? Une trajectoire d adoption claire Paradoxalement, bien que le fonctionnement actuel et l approche DevOps diffèrent radicalement, la trajectoire d adoption de DevOps est assez claire. Le socle du changement consiste tout d abord à fournir l infrastructure sous forme de service. Les groupes d applications candidats à un fonctionnement DevOps peuvent ensuite être déterminés et le changement s organiser, soit de façon brutale, soit de façon progressive. Dans le premier cas le changement de responsabilité précède la modification des pratiques opérationnelles et l automatisation des processus clés. Dans l autre, elle intervient après une phase de préparation qui déroule les améliorations de court terme précédemment décrites. Un transfert de responsabilité limité sur le fonctionnement des applications Une phase d évaluation initiale peut aussi montrer que l'ampleur de la tâche n'est pas forcément si grande. En effet, dans beaucoup de DSI, la production est un silo poreux : des personnels études disposent parfois même de droits permanents sur les machines de production au mépris des règles de sécurité en vigueur. En général les études ne se contentent pas d un support de haut niveau sur les applications mais s impliquent dans la surveillance des traitements quotidiens sensibles pour le métier. Cette implication découle éventuellement de la perte de la connaissance des logiciels par la production consécutive à une opération de mutualisation. En pratique, très peu de productions sont pleinement responsables de la qualité du fonctionnement applicatif vis-à-vis des clients métiers et les engagements restent portés par la partie études de la DSI. Dans tous les cas, y compris lors d externalisation de l exploitation, le décompte des incidents et le suivi de la disponibilité des services IT s organisent entre études et productions pour faire le départ entre les défauts occasionnés par les applications, le mauvais paramétrage de leur mise en œuvre et les défaillances de la couche d infrastructure. 12 Septembre 2014
Comme indiqué précédemment cette situation s explique par le fait que les productions se caractérisent par leurs droits d accès aux machines de production qui ne recouvrent absolument pas la responsabilité de la sûreté de fonctionnement des logiciels qui leur sont confiés. Le pas à franchir pour rejoindre la règle DevOps qui confie la sûreté de fonctionnement des applicatifs aux études est petit. Sur ce point, le passage en DevOps est plutôt une opération vérité. Les mises en production applicatives :un transfert de responsabilité plus délicat La question des mises en production est plus sensible. La MEP est l activité de fabrication (Build) du service IT qui revient à la production, du fait de ses droits sur les machines dans l organisation actuelle. Son automatisation présente deux avantages majeurs.. Si vous désirez télécharger la suite de ce livre blanc, cliquez sur ce lien. 13 Septembre 2014
A propos de MARTE Conseil Les DSI améliorent sans cesse leur performance opérationnelle au service des métiers et adaptent sans relâche leur fonctionnement. La société MARTE, lauréate du concours de création des entreprises de technologies innovantes, propose à ses clients d améliorer la productivité de leur direction informatique par l utilisation pragmatique des avancées du génie logiciel. La diffusion de ces avancées passe par l adoption des pratiques de référence de la profession, l évolution des procédés de développement, ainsi que l emploi d outils innovants. MARTE actionne l ensemble de ces leviers avec une prédilection pour l approche outillée : A l écoute du monde académique, elle consacre ainsi une part importante de son activité à un framework de développement par les modèles dont les items sont versionnés. Il lui permet de proposer à ses clients des solutions de gestion de configuration logicielle et de déploiement automatisé, premiers modules d une forge logicielle évolutive. La déontologie et l indépendance de MARTE vous assurent une prestation sans biais. Contact MARTE Conseil 7, rue des Huissiers, 92200 Neuilly Téléphone : 01 41 92 00 15 Site Web : www.marte.fr 14 Septembre 2014