Comment OpenShift transforme la structure organisationnelle des départements IT. L'évolution des modèles organisationnels lors de la transition vers le PaaS

Bien que les solutions PaaS (« Plateforme en tant que service ») ne puissent à elles seules transformer les modes d'interaction individuels et en équipe, elles servent souvent de catalyseur à des changements organisationnels en réponse à la flexibilité croissante des technologies IT.

Dans la pratique, le rendement maximal des investissements dans le PaaS n'est souvent possible qu'à condition de modifier les rôles organisationnels, les domaines de responsabilité (tâches) et les schémas de relations. Heureusement, des solutions PaaS comme OpenShift Container Platform offrent une flexibilité suffisante pour que chaque organisation IT puisse déterminer seule la vitesse et l'ampleur des transformations concernant les personnes impliquées et les processus en cours.

Au premier stade de la conteneurisation des entreprises, la priorité principale est l'implémentation d'une plateforme de conteneurs comme nouveau système de déploiement d'applications. À ce moment-là, les organisations associent les travaux habituels à des rôles familiers, afin de répondre aux demandes standard des équipes de développement sur des questions, telles que les systèmes de stockage, les environnements de déploiement, etc. Lors des étapes suivantes de la conteneurisation, il s'agit déjà d'automatisation ou de fournir aux développeurs des capacités d'auto-service pour alléger la charge des administrateurs systèmes et améliorer l'autonomie et la réactivité des développeurs. C'est ainsi que l'organisation commence à avancer vers DevOps. À l'étape finale de la conteneurisation, l'entreprise atteint un modèle DevOps plus pur et canonique, dans lequel de nombreuses anciennes tâches et travaux passent sous le contrôle d'équipes interfonctionnelles qui se regroupent non pas par plateformes ou technologies, mais en fonction de l'exploitation des applications ou des services d'application.

Dans cet article, nous présenterons un guide pour effectuer les changements organisationnels nécessaires et nous expliquerons comment les rôles informatiques traditionnels évoluent avec l'implémentation de technologies de conteneurs dans l'entreprise.

Associer de nouveaux travaux à d'anciens rôles

Dans sa forme de base, le modèle organisationnel PaaS est conçu pour attribuer de manière plus flexible et rapide des ressources informatiques aux applications comme environnement d'exécution. Bien que cela offre certains avantages aux administrateurs système, les développeurs n'en tirent généralement pas de bénéfices substantiels ni de nouvelles opportunités, car à ce stade, l'entreprise peut tout à fait se passer de commencer l'automatisation, de mettre en place l'auto-service ou d'améliorer radicalement le pipeline de déploiement. Tout en affectant miniment les processus de développement à ce stade, PaaS augmente néanmoins la dynamisme du système informatique, permettant ainsi aux administrateurs de mieux répondre aux demandes des développeurs. Par exemple, alors qu'auparavant il fallait des jours, voire des semaines, et l'implication de plusieurs administrateurs pour créer un environnement de développement à partir de plusieurs machines virtuelles et volumes de stockage, avec PaaS, tout se fait beaucoup plus rapidement et par le biais d'un seul administrateur. Autrement dit, les équipes de développement soumettent des demandes comme auparavant, mais les travaux de mise en œuvre de ces demandes sont réalisés selon un nouveau schéma.

Vers une organisation DevOps

En lançant PaaS et en transférant les spécialistes en exploitation des systèmes informatiques et les développeurs d'applications vers cette plateforme, l'organisation peut poursuivre l'implémentation de la méthodologie DevOps, qui comprend parmi d'autres les principes fondamentaux suivants :

• Diviser le travail en petites étapes, afin d'obtenir des retours d'information à un stade précoce, de réduire les risques et d'éviter le «paralysie analytique»;
• Automatiser les opérations dans une mesure suffisante, de manière à ne pas créer d'obstacles ou de goulets d'étranglement dans le processus de déploiement de l'application;
• L'échange de connaissances est la clé pour établir la confiance;
• Payer régulièrement les dettes techniques, en allouant à chaque cycle de travail un temps spécifique pour des améliorations systématiques.

Lors de la deuxième étape de la mise en œuvre des technologies de conteneurs, les équipes de développement commencent naturellement à voir des opportunités d'amélioration, et l'entreprise s'oriente vers un modèle DevOps plus canonique. Le mécanisme traditionnel de soumission et d'exécution des demandes de service est désormais perçu comme un goulot d'étranglement, c'est pourquoi l'organisation cherche à automatiser les actions répétitives et à offrir aux développeurs des capacités de libre-service. Ces possibilités pour les développeurs, dans le cadre d'une demande donnée, sont définies par les efforts conjoints des spécialistes IT en exploitation des plateformes et de ceux qui sont responsables de la livraison des applications. En d'autres termes, les administrateurs systèmes qui exécutaient les actions demandées par les développeurs sont remplacés par deux catégories de personnel susmentionnées, qui sont responsables de la définition et de l'application des politiques régissant ce que les développeurs sont autorisés à faire par leurs propres moyens. Les procédures automatisées aident à garantir le respect de ces exigences et à coordonner les actions lorsque la situation dépasse les politiques en vigueur.

La transition vers un calendrier itératif, où l'environnement IT et le modèle opérationnel subissent des modifications itératives au fil du temps, est une étape critique dans la formation d'un système DevOps mature au sein de l'entreprise. Le niveau d'adoption de la méthodologie DevOps dépend de la tolérance de chaque organisation aux changements et des changements qui apportent le plus de bénéfices. Par exemple, si le besoin de créer de nouveaux environnements ou applications se manifeste rarement, alors l'optimisation des actions correspondantes sera moins critique que le renforcement du contrôle des développeurs sur le cycle de vie des applications.

Nouvelles tâches qui apparaissent dans les organisations IT lors de la transition vers OpenShift

Dans cette section, nous examinerons les rôles et les tâches que les organisations ayant migré vers OpenShift appliquent généralement pour accélérer l'automatisation et le libre-service en utilisant des technologies et PaaS.

Le tableau ci-dessous répertorie les principales tâches de haut niveau qui existent au sein de toute organisation ayant mis en œuvre OpenShift, avec des exemples de travaux et de compétences correspondants. Cette liste de tâches ne doit pas être confondue avec le diagramme de répartition des travaux ou la structure organisationnelle des équipes ; il s'agit simplement d'un ensemble de tâches qui doivent être prises en charge par les personnes responsables de la gestion de l'environnement IT pour assurer la réussite de l'implémentation de la plateforme conteneurisée. En réalité, nous allons montrer plus loin que l'implémentation des technologies conteneurées crée les conditions préalables à l'établissement d'une stratégie DevOps plus mature au sein de l'entreprise, ce qui, à son tour, renforce le niveau de transversalité des équipes et réduit les risques de spécialisation étroite tant au niveau des individus que des équipes.

Tableau 1. Définition des tâches OpenShift

Objectifs
Compétences requises

Automatisation et préparation (provisioning) des infrastructures IT

Travaux :

• Conception et construction de solutions matérielles
• Organisation et accompagnement de l'automatisation de la configuration initiale
• Conception et automatisation de la préparation des VM et des hôtes

• Conception et mise en œuvre des centres de données
• Administration système Linux
• Scénarios d'automatisation
• Connaissance des systèmes de stockage
• Connaissances en conception et mise en œuvre de réseaux
• Sécurité

Installation et gestion de la plateforme OpenShift

Travaux :

• Exécution de l'installation du cluster
• Gestion des services d'infrastructure
• Gestion de l'évolutivité de la plateforme
• Vérification de l'authentification et de l'autorisation au niveau de la plateforme

• Administration système Linux
• Connaissances en technologies réseau
• Scénarios d'automatisation (Ansible)
• Connaissance des systèmes de stockage
• Connaissance des technologies et architectures conteneurisées
• Connaissance des architectures Kubernetes et OpenShift
• Sécurité des plateformes
• Intégration de la surveillance

Gestion de la préparation des environnements clients (tenant provisioning) et de l'isolation par les ressources IT

Travaux :

• Création d'utilisateurs et d'équipes au sein de la plateforme
• Conception et gestion des quotas
• Conception et mise en œuvre de RBAC

• Connaissance des architectures Kubernetes et OpenShift
• Connaissance des technologies et architectures conteneurisées
• Scénarios d'automatisation
• Bons niveaux de connaissances en matière de projets, de quotas, d'attribution de rôles et de gestion des planificateurs

Assemblage et gestion des images de base

Travaux :

• Développement de workflows de modification des images
• Développement d'images basées sur des normes

• Administration système Linux
• Scénarios d'automatisation
• Configuration des composants runtime des applications et des middleware
• Connaissance des architectures conteneurisées
• Frameworks de construction d'applications (application build frameworks)
• Bons niveaux de connaissances en matière d'images, d'imagestream et de modèles

Conception et gestion des pipelines de déploiement

Travaux :

• Conception et documentation des standards de pipeline
• Développement de guides rapides et de modèles
• Formation des développeurs

• Gestion du code source
• Conception et mise en œuvre d'applications
• Scénarios d'automatisation
• Tests automatisés
• Tests de qualité du code
• Connaissance des architectures conteneurisées
• Connaissance des infrastructures immuables
• Sécurité - gestion des accès aux étapes du pipeline, approbation des workflows, etc.
• Bonne connaissance des modèles OpenShift, des composants buildconfigs, deploymentconfigs, services, routes, configmaps

Développement d'applications et de tests

Travaux :

• Codage des applications
• Développement de tests automatisés
• Réaction aux échecs de tests durant le pipeline de déploiement
• Réaction aux pannes d'applications
• Tests d'acceptation utilisateur

• Conception et mise en œuvre d'applications
• Tests automatisés
• Gestion du code source
• Surveillance des applications
• Connaissance des architectures d'applications cloud natives

Surveillance opérationnelle et gestion des applications

Travaux :

• Conception des applications dans le contexte de la performance
• Surveillance des performances des applications en cours d'exécution
• Mise à l'échelle des applications (ou auto-scaling)
• Gestion de la disponibilité des applications
• Quotas de requêtes et limites de gestion des ressources
• Tests de performance et capacités informatiques

• Conception et mise en œuvre des performances des applications
• Surveillance des performances des applications
• Tests de performance et tests de charge

Tests d'acceptation utilisateur

Travaux :

• Tests UI (design et interactions utilisateur)
• Développement de tests automatisés

• Conception et vérification des interfaces utilisateur
• Modèles de tests automatisés
• Frameworks de test
• Modèles de conception d'applications

Nouveaux rôles qui émergent dans l'organisation informatique lors de la transition vers OpenShift

À mesure que l'on passe à un modèle organisationnel axé sur DevOps, le nombre de spécialisations de rôles diminue généralement, tandis que le nombre d'équipes et de rôles cross-fonctionnels augmente pour maximiser l'efficacité de la collaboration. Voici, selon nous, la liste des postes principaux dans une organisation informatique utilisant OpenShift :

• Ingénieur des opérations applicatives (Application Operations Engineer) OU Ingénieur en fiabilité de site (Site Reliability Engineer). Auparavant, ce poste pouvait être appelé « Administrateur de serveur d'applications ».
• Développeur d'applications / développeur de logiciels / ingénieur logiciel.
• Administrateur de cluster / plateforme d'applications. Auparavant, ce rôle pouvait être appelé « Administrateur système » ou « Administrateur de plateformes Linux ».
• Responsable de publication de logiciels (Release Manager) / Ingénieur de builds (Build Engineer).

Matrice des rôles et tâches RACI

Enfin, nous passons à l'appariement des postes et des tâches examinés ci-dessus, afin de donner une vue d'ensemble de ce à quoi devrait ressembler la structure organisationnelle mettant en œuvre DevOps sur la plateforme OpenShift. Initialement, les rôles énumérés ci-dessous peuvent être exercés par différentes branches de l'ancienne structure organisationnelle traditionnelle. Cependant, avec le temps, une consolidation se produit et de nouvelles équipes, centrées autour des applications, émergent, prenant en charge la plupart, voire la totalité, des tâches énumérées ci-dessous.

Objectifs
Rôles

Ingénieur en exploitation des applications / Ingénieur de fiabilité des sites
Développeur d'applications / Développeur logiciel / Ingénieur en programmation
Administrateur de cluster / plateforme d'applications
Responsable de publication de logiciels / Ingénieur de builds

Automatisation et préparation (provisioning) des infrastructures IT
I
I
R/A
C

Installation et gestion de la plateforme OpenShift
C
I
R/A
C

Conception et gestion des pipelines de déploiement
C
C
I
R/A

Gestion de la préparation des environnements clients (tenant provisioning), de l'isolation et des capacités informatiques
C
I
R/A
I

Assemblage et gestion des images de base
R
C
R/A
C

Développement d'applications et de tests
C
R/A
I
I

Surveillance opérationnelle et gestion des applications
R/A
C
C
I

Tests d'acceptation utilisateur
C
R
I
I

Symboles dans la matrice RACI
Source : Wikipedia

• Responsible – Exécutant – celui qui fait le nécessaire pour accomplir la tâche.
• Accountable – Responsable – l'employé qui est finalement responsable de l'exécution correcte et précise de la tâche ou de l'atteinte des résultats ; et le seul qui peut déléguer le travail aux exécutants.
• Consulted – Consultant – en général, ce sont des experts dans le domaine, dont le conseil est sollicité ; une communication bilatérale leur est maintenue.
• Informed – Informé – les personnes qui sont tenues au courant des événements (et parfois seulement à la fin de la tâche ou de l'atteinte des résultats) ; elles reçoivent des informations de manière unidirectionnelle.

Comment s'organise la collaboration des équipes dans une organisation DevOps

Le schéma traditionnel d'attribution des ressources consiste généralement en un cycle de demandes d'attribution de ressources, qui sont ensuite exécutées par plusieurs équipes. En fin de compte, toutes les ressources nécessaires sont attribuées et confirmées par la partie demandeuse. Souvent, ces processus sont partiellement, voire totalement, réalisés manuellement et nécessitent de fréquentes et multiples interactions entre les équipes pour le traitement réussi de chaque demande.

Figure 1. Organisation informatique traditionnelle

Le diagramme ci-dessus illustre les relations typiques entre les équipes dans une organisation informatique traditionnelle. Dans ce schéma, certaines équipes demandent à d'autres d'effectuer les travaux nécessaires, en utilisant des moyens de communication plus ou moins formalisés, comme un système de tickets ou des courriels. Ensuite, ces demandes sont mises en attente et attendent leur tour, un long temps d'attente entraînant souvent une détérioration, voire une aggravation des relations entre les équipes. La tension est également exacerbée par le fait que les membres des différentes équipes se rencontrent rarement en personne et, en général, ne partagent que les informations minimales nécessaires.

Figure 2. Organisation IT DevOps

Ce diagramme montre comment le travail collaboratif est organisé dans DevOps. Ici, les mêmes équipes du diagramme précédent ont abandonné les communications inefficaces qui renforçaient la séparation et les ont remplacées par des contacts personnels, créant ainsi des canaux de communication permanents entre les équipes. Ces canaux favorisent une hybridation des compétences, aidant les employés à mieux comprendre et appréhender les besoins, les problèmes et les opportunités des équipes qu'ils représentent. Les équipes s'offrent mutuellement la possibilité d'effectuer les travaux nécessaires via des portails d'auto-service automatisés, au lieu de traiter manuellement les demandes de changements des autres, comme cela se faisait auparavant. Et grâce à ces canaux de communication, ces systèmes d'auto-service peuvent rapidement s'adapter aux besoins des équipes pour lesquelles ils ont été créés. Pour favoriser encore plus la compréhension mutuelle et l'échange de connaissances au sein de l'organisation, les membres des équipes effectuent périodiquement une rotation des rôles afin d'acquérir une expérience d'interaction avec différentes équipes et de mieux comprendre l'ensemble des systèmes informatiques qu'ils gèrent, augmentant ainsi leur niveau de transversalité et d'utilité.

En résumé

Dans cet article, nous avons expliqué comment l'implémentation de solutions PaaS peut inciter une organisation à adopter la méthodologie DevOps, entraînant ainsi des changements dans les rôles et responsabilités traditionnels. Nous avons donc dressé une liste des principales tâches informatiques qui émergent dans une organisation lors de la transition vers OpenShift, ainsi que les compétences nécessaires pour les accomplir. Nous avons également présenté l'ensemble des rôles organisationnels principaux qui apparaissent lors de la mise en place d'équipes DevOps interfonctionnelles, ainsi qu'une matrice RACI associant ces nouveaux rôles aux nouvelles tâches. Enfin, nous avons discuté de la manière dont la plateforme OpenShift et la méthodologie DevOps peuvent transformer la structure organisationnelle d'une entreprise en passant d'une hiérarchie traditionnelle et de systèmes de traitement des demandes à des équipes interfonctionnelles favorisant des communications plus personnelles.

Source : habr.com