◀️ 🏤 💌 Comment OpenShift modifie la structure organisationnelle d'une organisation informatique. L'évolution des modèles organisationnels lors du passage au PaaS 👲🏼 🙏 🕐

Bien que les solutions PaaS (Platform as a Service) à elles seules ne soient pas capables de changer les modes d'interaction individuelle et d'équipe, elles servent souvent de catalyseur de changement organisationnel en réponse à la flexibilité accrue des technologies informatiques.

En fait, le retour sur investissement maximal dans le PaaS n'est souvent possible que si les rôles organisationnels, les domaines de responsabilité (tâches) et les relations sont modifiés. Heureusement, les solutions PaaS, telles que la plate-forme de conteneur OpenShift, sont suffisamment flexibles pour que chaque organisation informatique puisse déterminer de manière indépendante la vitesse et l'ampleur du changement par rapport aux personnes impliquées et aux processus en cours.

Au premier stade de la conteneurisation d'entreprise, la principale priorité est la mise en œuvre de la plateforme de conteneurs en tant que nouveau système de déploiement d'applications. À ce stade, les organisations associent des tâches familières à 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. Aux étapes ultérieures de la conteneurisation, nous parlons déjà d'automatisation ou de fourniture aux développeurs de capacités en libre-service afin de réduire la charge des administrateurs système et de porter l'autonomie et l'efficacité des développeurs à un niveau supérieur. C'est ainsi que l'organisation commence à évoluer vers DevOps. Au stade final de la conteneurisation d'entreprise, il s'agit d'un modèle DevOps plus propre et canonique,dans le cadre desquelles bon nombre des tâches et travaux antérieurs sont placés sous le contrôle d'équipes interfonctionnelles, qui ne sont pas regroupées sur la base de plates-formes ou de technologies, mais en termes d'assurer le fonctionnement des applications ou des services d'application.

Dans cet article, nous fournirons des conseils sur les changements organisationnels nécessaires et décrirons comment les rôles informatiques traditionnels évoluent avec l'introduction de la technologie des conteneurs dans l'entreprise.

Lier de nouveaux emplois à d'anciens rôles

Dans sa forme initiale et de base, le modèle d'organisation PaaS est formé afin d'allouer de manière plus flexible et plus efficace les ressources informatiques aux applications en tant qu'environnement d'exécution. Et bien que cela donne certains avantages aux administrateurs système, les développeurs ici, en règle générale, ne reçoivent pas d'avantages significatifs et de nouvelles opportunités, car à ce stade, l'entreprise peut bien se passer de démarrer l'automatisation, d'introduire le libre-service ou d'améliorer radicalement le pipeline de déploiement. Affectant le moins possible les processus de développement à ce stade, le PaaS augmente néanmoins le dynamisme du système informatique, ce qui permet aux administrateurs de mieux répondre aux demandes des développeurs. Par exemple, si auparavant, la création d'un environnement de développement à partir de plusieurs machines virtuelles et volumes de stockage pouvait prendre des jours, voire des semaines,et cela a nécessité la participation de plusieurs administrateurs différents, puis en PaaS tout se fait beaucoup plus rapidement et avec l'aide d'un seul administrateur. En d'autres termes, les équipes de développement soumettent les candidatures comme auparavant, mais le travail de mise en œuvre de ces applications est déjà en cours selon le nouveau schéma.

Vers une organisation DevOps

En lançant PaaS et en y transférant des spécialistes de l'exploitation des systèmes informatiques et des développeurs d'applications, l'organisation peut continuer à mettre en œuvre la méthodologie DevOps, qui comprend, entre autres, les principes de base suivants:

Divisez le travail en petites étapes afin d'obtenir un retour d'information dès les premières étapes, de réduire les risques et d'éviter la «paralysie analytique»;
Automatisez suffisamment les opérations pour ne pas créer d'obstacles ou de goulots d'étranglement dans le processus de déploiement des applications;
Le partage des connaissances est la clé pour instaurer la confiance;
Payer régulièrement des dettes techniques , en allouant un certain temps dans chaque cycle de travail pour des améliorations systématiques.

À 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 la société penche 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, de sorte que l'organisation cherche à automatiser les actions répétitives et à fournir aux développeurs des capacités en libre-service. De plus, ces capacités des développeurs dans le cadre d'une application particulière sont déterminées par les efforts conjoints des informaticiens dans le fonctionnement des plates-formes et de ceux qui sont responsables de la livraison des applications. En d'autres termes, les administrateurs système effectuant des actions à la demande des développeurs sont remplacés par les deux catégories d'employés ci-dessus qui sont responsables de la description et de l'application des politiques régissantque sont exactement autorisés les développeurs à faire par eux-mêmes. Les procédures automatisées aident à garantir le respect de ces exigences et à coordonner les actions dans les cas où la situation dépasse le cadre des politiques existantes.

Le passage à une chronologie itérative dans laquelle l'environnement informatique et le modèle d'exploitation subissent des changements itératifs au fil du temps est une étape critique en termes de construction d'un système DevOps mature dans l'entreprise. Le degré d'adoption de la méthodologie DevOps dépend de la tolérance de chaque organisation particulière au changement et des changements les plus avantageux. Par exemple, si la nécessité de créer de nouveaux environnements ou applications apparaît rarement, l'optimisation des actions appropriées sera moins importante que le renforcement du contrôle des développeurs sur le cycle de vie de l'application.

Nouveaux défis auxquels les organisations informatiques sont confrontées lors du passage à OpenShift

Dans cette section, nous examinerons les rôles et tâches que les organisations qui sont passées à OpenShift utilisent généralement pour accélérer l'automatisation et le libre-service à l'aide de la technologie et du PaaS.

Le tableau ci-dessous répertorie les principales tâches de niveau supérieur qui existent dans toute organisation qui a implémenté OpenShift, avec des exemples de travail et de compétences pertinents. Cette liste de tâches ne doit pas être confondue avec le schéma de partage du travail ou la structure organisationnelle des équipes, il s'agit simplement d'un ensemble de tâches qui doivent être fermées par les responsables de la prise en charge du ou des environnements informatiques pour la mise en œuvre réussie de la plate-forme de conteneurs. En fait, nous montrerons en outre que la mise en œuvre de technologies de conteneurs crée les conditions préalables à la formation d'une stratégie DevOps plus mature au sein de l'entreprise, qui à son tour augmente le degré de fonctionnalité croisée des équipes et réduit les risques de spécialisation étroite au niveau des employés et des équipes.

Tableau 1. Définitions des tâches OpenShift

Tâches	Compétences requises
(provisioning) - :	- Linux
OpenShift :	Linux (Ansible) Kubernetes OpenShift
(tenant provisioning), - : RBAC	Kubernetes OpenShift , ,
:	Linux runtime- middleware (application build frameworks) , imagestream
:	immutable – , . . OpenShift, buildconfigs, deploymentconfigs, services, routes, configmaps
:	(cloud native)
: ( ) -
: UI ( )	Cadre de test Modèles de conception d'application

Nouveaux rôles qui apparaissent dans les organisations informatiques lors de la migration vers OpenShift

À mesure que vous passez au modèle organisationnel basé sur DevOps, le nombre de spécialisations de rôles a tendance à diminuer et le nombre d'équipes et de rôles interfonctionnels augmente à son tour pour maximiser la collaboration. Voici, à notre avis, la liste des postes clés dans une organisation informatique utilisant OpenShift:

Ingénieur Opérations d'application OU Ingénieur fiabilité site. Auparavant, ce poste pouvait être appelé «Administrateur du serveur d'applications».
Développeur d'applications / développeur de logiciels / ingénieur logiciel.
Administrateur de cluster / plateforme d'application. Auparavant, ce rôle pouvait être appelé «Administrateur système» ou «Administrateur de plate-forme Linux».
Gestionnaire de versions logicielles (ingénieur de construction)

Matrice des rôles et des tâches RACI

Enfin, nous passons à la comparaison des positions et des tâches décrites ci-dessus pour donner une idée générale de la structure d'une organisation implémentant DevOps sur la plate-forme OpenShift. Initialement, les rôles suivants peuvent être remplis par différentes branches de l'ancienne structure organisationnelle traditionnelle. Mais au fil du temps, des consolidations ont lieu et de nouvelles équipes, construites autour des applications, apparaissent qui clôturent la plupart ou même toutes les tâches ci-dessous.

Tâches	Les rôles
Tâches	Ingénieur Opérations d'application / Ingénieur fiabilité site	Développeur d'application / Développeur logiciel / Ingénieur logiciel	Administrateur de cluster / plateforme d'application	Responsable des versions logicielles / ingénieur assembleur
Automatisation et provisionnement des infrastructures informatiques	je	je	R / a	C
Installation et gestion de la plate-forme OpenShift	C	je	R / a	C
Concevoir et gérer des pipelines de déploiement	C	C	je	R / a
Gérer le provisionnement, l'isolement et les capacités informatiques des locataires	C	je	R / a	je
Créez et gérez des images de base	R	C	R / a	C
Développement d'applications et de tests	C	R / a	je	je
Surveillance opérationnelle et gestion des applications	R / a	C	C	je
Test d'acceptation personnalisé	C	R	je	je

Conventions dans la matrice RACI
Source: Wikipedia

Responsable - Un exécuteur testamentaire est celui qui fait le nécessaire pour accomplir une tâche.
Accountable – – , ; , .
Consulted – – , , ; .
Informed – – , (, ); .

DevOps-

Le schéma traditionnel d'obtention de ressources est, en règle générale, une série de demandes d'allocation de ressources, qui sont ensuite exécutées par plusieurs commandes. En fin de compte, toutes les ressources nécessaires sont allouées et confirmées par le demandeur. Souvent, ces processus sont partiellement ou même complètement exécutés manuellement et nécessitent des interactions fréquentes et nombreuses entre les équipes pour traiter avec succès chaque demande.

Figure 1. Organisation informatique traditionnelle

Le diagramme ci-dessus illustre les relations typiques entre les équipes d'une organisation informatique traditionnelle. Dans le cadre de ce dispositif, certaines équipes se tournent vers d'autres équipes pour leur demander d'effectuer les travaux nécessaires à l'aide de moyens de communication plus ou moins formalisés, comme un système de ticket ou un e-mail. Ensuite, ces demandes tombent dans la file d'attente et attendent dans les coulisses, et une longue attente entraîne souvent une détérioration, voire une aggravation des relations entre les équipes. La tension est exacerbée par le fait que les membres des différentes équipes se rencontrent rarement personnellement et, en règle générale, ne partagent que le minimum d'informations nécessaires.

Figure 2. Organisation informatique DevOps

Ce diagramme montre le fonctionnement de la collaboration dans une organisation DevOps. Ici, les mêmes équipes du diagramme précédent ont abandonné les communications inefficaces, ce qui a accru la désunion et les a remplacées par des contacts personnels, créant ainsi des canaux d'interaction permanents entre les équipes. Ces canaux aident à créer un ensemble de compétences hybrides qui aide les employés à mieux comprendre et représenter les besoins, les défis et les capacités des équipes qu'ils représentent. Les équipes se donnent la possibilité d'effectuer le travail nécessaire via des portails en libre-service automatisés au lieu de traiter manuellement les demandes de modification de quelqu'un d'autre, comme c'était le cas auparavant. Et grâce à la présence de canaux d'interaction, ces systèmes en libre-service sont capables de s'adapter rapidement aux besoins des équipes,pour lesquels ils sont créés. Pour parvenir à une compréhension mutuelle et à un partage des connaissances encore plus importants au sein de l'organisation, les membres de l'équipe changent périodiquement de rôle pour acquérir de l'expérience dans l'interaction avec diverses équipes et mieux comprendre l'image globale des systèmes informatiques qu'ils servent, augmentant ainsi leur niveau de fonctionnalité et d'utilité croisées.

Résumer

Dans cet article, nous avons expliqué comment la mise en œuvre de solutions PaaS peut encourager l'organisation à mettre en œuvre la méthodologie DevOps, et les rôles et tâches traditionnels sont susceptibles de changer dans le cadre de ce processus. Par conséquent, nous avons répertorié les principales tâches informatiques qui surviennent dans l'organisation avec la transition vers OpenShift, ainsi que les compétences nécessaires à leur mise en œuvre. Nous avons également présenté l'ensemble principal des rôles organisationnels qui se produisent lors de la création d'équipes DevOps interfonctionnelles et la matrice RACI reliant les nouveaux rôles aux nouvelles tâches. Enfin, nous avons expliqué comment la plate-forme OpenShift et sa méthodologie DevOps associée peuvent changer la structure organisationnelle d'une organisation lors du passage d'une hiérarchie traditionnelle et de systèmes de traitement d'applications à des équipes interfonctionnelles avec un niveau plus élevé de communications personnelles.

Comment OpenShift modifie la structure organisationnelle d'une organisation informatique. L'évolution des modèles organisationnels lors du passage au PaaS