Nous constatons souvent que la taille réduite d’une organisation offre une souplesse et un dynamisme naturels autorisant des changements plus rapides tant au niveau de la technique qu’à celui de l’organisation. Notre accompagnement est par conséquent adapté à la typologie de nos clients afin d’adopter une démarche adéquate. Dans les lignes suivantes, nous allons nous attarder sur le cas des structures plus lourdes et donner quelques clés pour entamer une migration non pas vers une technologie particulière, mais plutôt sur la phase qui la précède et en quoi la philosophie DevOps peut être une réponse.
Les médias spécialisés regorgent d’articles sur les exploits techniques des acteurs incontournables de l’IT. Il n’existe pas une seule journée sans que l’on apprenne les nouvelles performances techniques ou les architectures disruptives de telles ou telles entreprises d’ailleurs souvent accompagnées de nouveaux outils, libraries, patterns, etc. Cette émulation permanente est à mon avis à double tranchant. D’une part très bénéfique puisqu’elle permet d’insuffler du dynamisme, du changement et de l’innovation. D’autre part parasite, cette agitation peut tendre à nous faire oublier un levier indispensable de progrès et de modernisation du système d’informations : l’organisation.
La DSI d’une grande entreprise ne peut pas bouleverser l’organisation mise en place depuis des années ITIL au profit d’une philosophie récente DevOps. Mais il faut tout de même savoir remettre en question son organisation pour une partie. Appliquer les méthodes d’une startup ou d’un des géants type GAFA n’est pas une solution. Il existe dans notre contexte de grandes entreprises un héritage qu’il faut prendre en considération. Néanmoins, celui-ci ne doit pas être une excuse pour encourager l’immobilisme. Voyons avant tout qu’il existe des indicateurs simples pour avoir une meilleur idée de son niveau de performance et qu’en parallèle, DevOps offre des solutions.
Le temps
Le gaspillage ainsi que la lenteur de réalisation sont deux ennemis pour le bon fonctionnement de votre SI. Pour mieux se rendre compte de leur présence, un exercice assez simple est de mesurer le temps nécessaire pour effectuer les opérations classiques que sont la création et la mise à jour d’un environnement pour un projet donné. Si vous êtes au delà de 24 heures (ce qui est déjà un temps assez important) alors vous pouvez considérer qu’il y a une souffrance sur ce facteur.
Souvent, cette lenteur ou inertie pour la réalisation de ces tâches basiques trouveront leurs origines dans un manque d’automatisation. Celui-ci se caractérise par la multiplicité des interventions manuelles et est très généralement accompagné de changements d’interlocuteurs/services. A chaque fois qu’un workflow dispose de plusieurs intervenants, vous pouvez être quasiment certains qu’il sera réalisé en plus d’une journée. Pour redonner de la rapidité et de l’agilité, les opérations doivent être automatisées, idéalement par le biais d’une API. Celle-ci permettra une plus grande fluidité dans les interactions entre services. Elle offrira aussi une remontée d’informations précieuses pour la réalisation de tableaux de bord.
La communication
Quels sont les moyens de communication entre les différentes équipes ? Est-ce que ces outils sont une invitation à la communication ou au contraire, le système n’a pas été mis à jour depuis plusieurs années ne serait-ce que d’un point de vue ergonomique. N’oubliez pas que ces dernières années ont été riches en bouleversements dans les modes de communication ( des réseaux sociaux au innombrables applications de communication). Vos employés, vos collègues, vos clients ou vos utilisateurs y sont habitués. Mesurer la différence de ce que proposent vos outils internes de communications avec ceux existants de l’autre côté des murs de l’entreprise. Est-ce que les outils de communication entre services sont les mêmes que ceux utilisés au sein des services ? L’objectif n’est pas de forcer les utilisateurs à utiliser un outil commun mais de mesurer l’engouement ou pas pour cet outil. Si tous les services utilisent en interne une autre solution, alors il y a clairement une souffrance.
Le formalisme des messages à travers les outils de communication est quelque chose qui d’un point de vue théorique peut sembler important. Notamment à travers les outils de ticketing ou assimilés, on pourrait penser que cela aide pour réaliser des KPI ou autres reportings mais la réalité montre bien souvent que ceux-ci sont mal exploités car trop compliqués, trop lourds, pas assez rapides. De plus, formaliser les informations ne présente que peu d’intérêt s’il n’y a pas d’objectif d’exploitation de la donnée.
La visibilité
Pour bien piloter son IT, vous vous devez de disposer de tableaux de bords. Sans ceux-ci, l’exercice peut s’assimiler à conduire sans phares. Si vous n’avez pas cette visibilité sur les performances de votre infrastructure ainsi que son coût, il est difficile d’envisager d’accélérer les processus qui régissent le fonctionnement de votre IT. Ces tableaux de bords doivent vous fournir une information fraîche sur les actions qui sont en cours, la performance des environnements et le coût pour chaque environnement. Ils donneront une information quasi temps réel grâce à l’exploitation des APIs disponibles au travers des outils de gestion de l’infrastructure.
La structure
On évoque souvent lorsque l’on parle de mise en place DevOps le fait de réunir les profils développeur (Dev) avec ceux plus orientés administration systèmes (Ops). Certes, ce modèle est idéal lorsque la structure comprend peu de personnes. Dans des organisations de taille plus importante, ces activités seront souvent situées dans des lieux géographiquement éloignés : étage différent, autre bâtiment, autre ville. Dans ce cas de figure, réunir ces profils n’est pas concevable sans rentrer dans des démarches sociales complexes. Il faut par conséquent redoubler d’effort sur les points mentionnés précédemment. Ces précédentes actions pourront aussi être accélérées par la mise en place d’ateliers qui auront pour objectif de confronter Dev et Ops et surtout briser une première couche de ce mur de la confusion. C’est aussi ce type d’atelier dont nous apprécions l’animation lors de nos missions d’accompagnement.
La sécurité
Toutes entreprises de taille conséquente dispose d’un service dédié à la sécurité de l’infrastructure (RSSI). Ils sont de manière générale sollicité en amont de la réalisation des projets afin de valider ou pas la “compliance” avec la politique sécurité interne. Souvent perçu comme les rabats-joies pour la mise en oeuvre de solution innovante : web services, providers Cloud, leurs activités n’en restent pas moins indispensables. Afin de ne pas bloquer votre volonté de modernisation de votre IT, vous penserez à intégrer ce service dans tous les workflows de décision et notamment, ils seront autour de la table en ce qui concerne la création des automatismes. Par exemple, les jobs de provisionning d’instances seront validés par ces derniers. On mentionne l’intégration de la sécurité dans la démarche DevOps sous le terme “DevSecOps”.
Ces quelques recommandations d’analyse de l’existant ainsi que les préconisations sont un support pour l’amélioration de votre IT et un premier pas réalisé vers une démarche DevOps. Il est à mon avis important de jouer le jeu de la transition au niveau de l’ensemble de la DSI et non pas le mettre en oeuvre de manière isolée, créer par exemple un service dédié à cette forme d’agilité reviendrait à priver l’ensemble de la DSI des bénéfices qu’offre le mouvement DevOps. Cet effort de mise en oeuvre d’une meilleur fluidité vous sera profitable lorsque vous souhaiterez évoluer techniquement vers des solutions de PaaS ou vers la conteneurisation d’applications. Sans cela, le risque serait de se retrouver avec un bel outil mal exploité par des utilisateurs insensibles aux bénéfices.
