Comment démarrer la transformation DevOps

Si vous ne comprenez pas ce qu'est DevOps, alors voici une petite feuille de triche. DevOps est un ensemble de pratiques qui réduisent les craintes des ingénieurs et réduisent le nombre d'échecs dans la production de logiciels. En règle générale, ils réduisent également le délai de commercialisation - la période allant de l'idée à la livraison du produit final aux clients, ce qui vous permet de mener rapidement des expériences commerciales .

Comment démarrer la transformation DevOps? En bref: nous sélectionnons le service à partir duquel nous allons démarrer le processus, identifions ceux qui sont liés au service, construisons le Value Stream Map, créons une équipe temporaire qui traitera la transformation pour la première fois et lui assigner une tâche. Nous répétons le cycle autant de fois que nécessaire.


Un plan de transformation DevOps détaillé avec des exemples et des instructions sous la coupe se trouve dans le décodage du rapport d' Andrei Alexandrov , ingénieur chez Express42, qui conseille sur la germination de DevOps, accélérant ce processus, car il a déjà construit une carte de râteau. S'il vous semble que vous n'avez pas besoin de la transformation, ou si vous avez des spécificités telles que les pratiques DevOps ne conviennent pas, utilisez le rapport comme une instruction pour trouver et éliminer les restrictions.

Si vous êtes préoccupé par la question de la transformation DevOps, alors vous avez une grande entreprise et vous devez progressivement étendre ce processus à l'ensemble de la structure. Tant qu'il est nécessaire de transformer l'équipe ou de supprimer une sorte de restriction, l'algorithme ci-dessous peut être répété.

Sélection des services

Nous avons défini un plan, commencez par la première étape - choisir un service. Le premier critère est la durée de vie : il existe d'anciens services - anciens et nouveaux. Vous pouvez commencer par ceux-ci et d'autres.

Il est logique de choisir un service jeune . C'est frais, il n'y a pas de processus bien établi de travailler dans une équipe qui s'en occupe. Autour de lui, il n'y a pas de montagne de dettes techniques, pas besoin de la réparer tout le temps. Nous pouvons faire tout ce que nous voulons avec lui.

Dans le cas de l'ancien service, il y a des problèmes liés au fait qu'il est toujours difficile de changer . Il existe déjà un ensemble de restrictions sérieuses, mais peut-être que les gens qui sont prêts à tout pousser le font - ils sont fatigués et veulent faire quelque chose différemment, parce que ça fait mal.

Travailler avec l'ancien service crée un puissant précédent dans votre entreprise - vous pouvez changer quelque chose. Si vous changez un nouveau service, il roule jusqu'à 100 fois par heure, et tout va bien, les gens de votre entreprise peuvent dire:

- Ceci est un nouveau service! Tout était simple là-bas, essayez de faire quelque chose avec nos choses pimpées.

Il est logique de transformer un service hérité en transformation lorsque vous le faites avec quelqu'un, par exemple, si vous avez invité un consultant externe. Soyons honnêtes, la transformation renversera tout ce qui est possible . Vous expérimentez et ne savez pas où vous viendrez, quelles technologies et pourquoi vous utiliserez, où et quels pièges se poseront dans les processus. Par conséquent, un nouveau changement est plus facile.

Si vous faites tout vous-même, mais que l'entreprise n'a pas de compétence sérieuse, nous prenons un nouveau service. Si vous connaissez un consultant externe et qu'il y a des fonds - choisissez l'ancien.

Il existe des services qui ne sont qu'une interface pour les utilisateurs, par exemple un simple site Web ou une application mobile. Mais il y a des choses sérieuses dans l'esprit de la facturation. Si quelque chose ne va pas avec la facturation, il sera difficile à comprendre. Ici, nous avons également le choix.

Nous travaillons soit avec un service critique , mais souffrons déjà à cause de cela, cela crée des restrictions, ou nous travaillons avec l'interface . Il s'agit du deuxième critère de sélection. De même, il est possible d'attirer un consultant expérimenté - nous travaillons avec une option difficile.

Mais même dans ce cas, je ne conseillerais pas de le faire, car bien qu'il n'y ait pas de compréhension avec quoi travailler et comment transformer, prendre une chose critique et la secouer n'est pas une bonne idée. Par conséquent, dans ce cas, nous préférons travailler avec une interface dont la panne n'est pas critique.

Ensuite, considérez la commande de service . Avec ceux qui sont engagés dans ce service, nous devrons constamment travailler et interagir en contact très étroit.

Les membres de l'équipe sont conditionnellement divisés en deux catégories: les conservateurs - ils vivent dans le vieux monde, ou tout simplement ne savent rien de DevOps, et les innovateurs qui portent toutes les pratiques à la mode. Ces derniers ne comprennent pas toujours le sujet, mais au moins ils y sont prêts.

D'un côté, les conservateurs sont des gens expérimentés: ils sont dans l'entreprise depuis longtemps, ils le comprennent parfaitement, mais ils ne connaissent pas seulement les pratiques. D'un autre côté, il y a des innovateurs qui ont entendu quelque chose, mais très probablement ils ont travaillé pour l'entreprise il n'y a pas si longtemps. Avec lequel est-il préférable de travailler?

Dans tous les cas, vous devrez interagir avec des conservateurs, car c'est leur service. Nous devrons communiquer avec eux, découvrir les spécificités du service, ce qui peut être fait de cette façon et ce qui est différent. Nous comptons sur leurs conseils. Ils vont sûrement devoir confier quelque chose, car ils connaissent mieux leur service. Par conséquent, il est important de savoir avec quelle équipe nous aurons éventuellement des contacts.

Il est logique de choisir une équipe innovante, car les conservateurs peuvent mettre un cochon.

Dans la pratique, il arrive souvent que les conservateurs aient une expérience significative, mais ils ne savent pas comment vivre. Ils ont simplement peur qu'après la transformation et la modification du service, ils soient licenciés comme inutiles. Parfois, simplement à cause d'un manque de compréhension de ce qui se passe, ils sabotent le travail.

J'ai eu un cas où un gars d'une équipe a réparé quoi que ce soit, car c'est censé être plus critique que ce que nous faisons actuellement. Nous avons fixé la tâche: réaliser cette pièce aujourd'hui - non, il y a un feu à l'autre bout du monde, nous allons le réparer. Il est difficile de travailler avec de telles personnes.

Les membres de l'équipe conservatrice obstruent souvent les tâches ou les remettent à plus tard. Et si, John Willis vous sauve, vous avez fait une erreur et les avez suspendus avec KPI pour le nombre de tâches terminées, et pour une raison quelconque, certains d'entre eux n'étaient pas inclus dans KPI, alors ils ne feront rien du tout. En général, ils auront raison, car ils perdent alors le bonus.

C'est plus facile avec les innovateurs - ils sont plus fidèles . Ils ont déjà entendu quelque chose, ils veulent aller quelque part, alors ils vont aider. Nous avons besoin de personnes prêtes à souffrir la première fois: si le service change, tous les cônes et râteaux seront capturés par les innovateurs en tant que pionniers. Les innovateurs veulent le plus récent et le plus à la mode et souffrent.

Les conservateurs peuvent plus tard être convertis. Lorsque vous montrez que vous avez changé une pièce et que tout fonctionne bien, ils voudront probablement aussi essayer d'adopter la nouvelle religion DevOps.

Pour résumer. Si nous faisons nous-mêmes toute la transformation de notre entreprise, alors nous choisissons: un nouveau service, de préférence une interface simple, pour ne pas trop souffrir de sa panne, et une équipe d'innovateurs.

S'il est possible d'appeler un consultant externe, au lieu d'un nouveau, nous prenons l'ancien service, à cause duquel nous souffrons déjà. Les personnes qui ont été engagées dans la transformation pendant un certain temps dans différentes entreprises ont vu différents cas et savent déjà comment le faire correctement et quelle voie prendre en général.

Qui est impliqué?

Nous devons trouver en général tous ceux qui ont au moins quelque chose à voir avec le service: développeurs, testeurs, administrateurs, agents de sécurité, gestionnaires et éventuellement propriétaires de produits. Bien que les Product Owners ne soient pas des techniciens, ils sont liés au service: prendre une décision, fixer une tâche.

Tous ceux qui prennent au moins certaines décisions et influencent ce qui se passe avec le service doivent trouver, se rencontrer et discuter.

Que sont-ils pour nous? Pour savoir avec qui négocier . Lors de la transformation, lorsque le principe habituel de travailler avec le service change, il va de toute façon trembler. Il y aura des problèmes pendant un certain temps pendant que nous testons de nouvelles approches. Les gens doivent être préparés à cela et être d'accord avec cela.

Ensuite, vous devez créer une carte de flux de valeur et sans ces personnes, vous ne pouvez pas la créer, car elles seules savent toutes ensemble ce qui se passe. Une personne ne sait jamais tout ce qui se passe avec le service.

Ils conseilleront les membres de l'équipe et nous verrons plus tard pourquoi une équipe distincte est nécessaire. Il devra prendre des gens des départements existants. Ceux qui sont liés au service pourront recommander des collègues qui pensent dans notre direction, qui peuvent nous aider et qui ont la compétence dont nous avons besoin.

Ensuite, nous rassemblons toutes ces personnes de différents services dans une seule pièce et commençons à construire une carte de flux de valeur.

Création d'une carte de flux de valeur

Value Stream Map est un diagramme ou une carte qui montre le flux de valeurs vers le client . Il s'agit de tout le processus, de l'invention d'une idée à sa mise en œuvre, en passant par toutes les étapes intermédiaires et la manière dont la valeur atteint finalement nos clients.

La Value Stream Map est nécessaire pour visualiser toutes les étapes du développement , localiser les problèmes à travers des mesures qui sont dans le processus actuel, et commencer à éliminer ces problèmes et fixer un objectif initial . C'est l'endroit où nous allons vraiment commencer à faire quelque chose.

Mesures

Il existe de nombreuses mesures différentes décrites dans la littérature Value Stream Map, mais pour commencer, nous n'en avons besoin que de trois.

Délai - délai / attente - le moment où nous attendons quelque chose. Par exemple, le testeur attend que le banc d'essai soit libéré et ne peut rien faire pour le moment.

Temps à valeur ajoutée - le temps de travail utile - celui que nous avons passé à telle ou telle étape pour créer la valeur ultime pour l'utilisateur. Par exemple, un testeur a effectué son test et a commencé à tester quelque chose. C'est le moment d'un travail utile lorsque nous faisons vraiment quelque chose pour le produit. C'est ce que les clients paient - pour des logiciels de qualité.

% C / A - pourcentage du travail accepté. Nous avons une étape - le développement, la deuxième étape - les tests. Combien de fonctionnalités les testeurs ont pris aux développeurs, et il y a ce pourcentage.

Voici à quoi ressemble notre carte.



Cela peut différer selon la structure de l'organisation, le nombre de départements et ce que vous faites. Mais dans le cas général, la carte comportera deux étapes: une idée et une analyse . À ce stade, les données sont attendues, par exemple, délai de livraison 2 semaines et délai de valeur ajoutée 2 jours.

Les mesures couvrent absolument toutes les étapes.

Arriéré - combien de tâches restaient après que les analystes les aient proposées.

Développement - combien de semaines les développeurs ont attendu des clarifications sur les tâches, les stands ou l'équipement - cela n'a pas d'importance, mais ils attendent quelque chose. Par exemple, ils implémentent une fonctionnalité pendant 4 jours. La métrique% C / A apparaît ici. Les développeurs ont pris seulement 80% des tâches de Backlog. Ils estiment que les 20% restants n'ont pas de savoirs traditionnels clairs et les ont envoyés pour révision.

Test . Sur le schéma LT, 4 jours sont définis. Par exemple, les testeurs attendaient la sortie du banc de test, VA pendant 2 jours, ils testent vraiment quelque chose, et% C / A = 40%. - seuls 40% du code ou des fonctionnalités envoyés par les développeurs ont été jugés adéquats par les testeurs. Ils n'aimaient pas le reste pour une raison quelconque.

Je ne m'attarderai pas sur la façon d'effectuer ces mesures, à la fin de l'article, je recommanderai une littérature à partir de laquelle vous pourrez en apprendre davantage.

La seule chose que je conseille est de ne pas croire les personnes qui composeront la Value Stream Map avec vous. Ils représentent le temps que prennent les différents processus, mais ces estimations ne sont pas toujours correctes, il est donc préférable de se mesurer.

Nous avons eu un cas lorsque nous sommes arrivés au service des opérations et avons demandé combien de temps il fallait pour livrer une nouvelle fonctionnalité à la production. Ils ont répondu que 10 minutes, et nous avons pensé, pourquoi sommes-nous venus dans cette entreprise? Il s'est avéré que 10 minutes est le temps d'exécution du script, qui prend le code et le remet au serveur. Mais avant cela, la version se trouve trois jours sur le serveur et ne fait que rassembler la poussière - dans Backlog se trouve la tâche qui doit être déployée. Il s'avère qu'avant l'étape de déploiement, il y a une étape d'attente lorsque le projet se trouve simplement. Si nous n'allions pas avec un cahier, ne regardions pas une tâche à Jira et ne commençions pas à la suivre par étapes, nous considérerions que tout est merveilleux et qu'il n'y a pas de problème.

Par conséquent, les mesures devront encore être faites par vous-même, de préférence plus d'une fois, afin d'avoir une représentation proche de la réalité. En fonction de la Value Stream Map, vous déciderez par où commencer et quoi corriger en premier.

Équipe temporaire

De nombreuses entreprises qui ont décidé d'introduire DevOps créent une équipe, non seulement temporaire, mais qui existe depuis plusieurs années. Si vous accédez au service d'excuses DevOps, qui décrit les différents modèles de création d'une structure organisationnelle dans DevOps, vous comprendrez qu'il s'agit d'un contre-modèle.

Lorsque l'équipe DevOps existe en continu depuis plusieurs années, c'est une grosse erreur, car DevOps concerne la communication entre les départements, la rapidité et l'efficacité.

Si une équipe existe entre les départements, pour faire autre chose séparément et existe depuis longtemps, cela crée une barrière supplémentaire. Maintenant, au lieu d'aller directement à l'administrateur, le programmeur doit d'abord contacter le service DevOps, et il ira plus loin.

Par conséquent, pour commencer, vous devez créer une équipe temporaire . Il existera pour une période suspendue de six mois, maximum un an, selon la tâche, pour éliminer une limitation que nous avons choisie. Elle mourra ensuite. Si nous choisissons le point suivant où cela fait très mal et comprenons que nous avons également besoin d'une équipe distincte, nous le créerons à nouveau. Mais de telles équipes ne devraient pas exister sur une «base permanente» - alors elles interrompent uniquement la communication et assument des tâches distinctes en général, uniquement pour faire quelque chose. Ces tâches peuvent ne pas être liées du tout à DevOps ou à la transformation. Pourquoi ne confions-nous pas cette tâche aux départements existants?

Pourquoi vous avez besoin d'une équipe temporaire

Conflit avec les processus actuels . La transformation DevOps est un changement non seulement des technologies et des outils que nous utilisons, mais un changement dans le processus de travail, de réflexion et de valeurs. Si l'équipe fonctionne comme d'habitude, elle ne pourra pas essayer d'autres approches.

Ces personnes doivent vivre selon des règles différentes: ignorer tous les KPI de l'entreprise, car ils essaient de travailler différemment. Les équipes temporaires ne rempliront pas les demandes pour obtenir un serveur, mais iront directement au service qui les gère, exigeant qu'elles soient les premières à donner ce dont elles ont besoin, car c'est une tâche prioritaire et parce qu'elles essaient de vivre différemment. L'équipe est en conflit complet avec tous les processus en cours. Afin que les méthodes de travail existantes n'interfèrent pas avec eux maintenant et qu'ils n'interfèrent pas avec les autres, nous isolons ces personnes en les distinguant en tant qu'équipe distincte.

Éviter la bureaucratie dans les expériences . Il n'y a pas de bureaucratie dans les équipes temporaires; elles ne remplissent pas de rapports sur les heures de travail; elles ne relèvent pas des managers. Il s'agit d'un monde complètement séparé dans lequel les gens vivent et pensent différemment et font des choses complètement différentes. Ne les dérangez pas encore.

Travail continu sur le service . Dans le premier paragraphe, nous avons choisi quelque chose à expérimenter. Il est bon d'expérimenter et de trouver des moyens de mieux travailler, mais nous voulons également faire des fonctionnalités. Si toute l'équipe s'engage dans la transformation au lieu des fonctionnalités, alors nous commencerons à perdre des revenus, les bugs se bloqueront longtemps - nous n'en avons pas besoin. La création d'une équipe temporaire vous permet d'expérimenter sans arrêter le travail sur le produit.

Ne perdez pas de temps sur les tâches de travail . Il s'agit encore une fois du produit. Il faut beaucoup de temps à l'équipe pour essayer d'autres outils et d'autres trucs. Pour que les gens maîtrisent les outils, commencent à les mettre en œuvre et à les utiliser normalement, cela prendra au moins six mois. S'ils traitent également avec le produit - six mois s'étendent cosmiquement. Si les gens sont engagés dans un produit, ils travaillent à nouveau avec d'anciens processus - nous n'en avons pas besoin.

Par conséquent, nous séparons les personnes de différents départements en une équipe distincte qui s'occupera de la transformation du service. En conséquence, le service fonctionne, continue de se développer et, en même temps, nous y mettons des expériences.

L'équipe temporaire n'est impliquée que dans la transformation DevOps - éliminant la restriction que nous avons trouvée, et rien de plus.

L'équipe est composée de personnes universelles . Cela signifie que nous avons pris non seulement des développeurs. Nous ne sommes pas venus au service et n'avons pas pris de demi-équipe à partir de là - non, nous avons pris des gens de différents départements . Il y a quelques points, nous avons trouvé différents départements et différents employés liés au service de transformation. Parmi ceux-ci, nous recrutons une équipe, car elle doit être universelle - nous allons changer le processus de test, le processus de développement et le processus de service. Différentes compétences sont nécessaires.

Habituellement, nous prenons conditionnellement un développeur, un testeur et un ingénieur - chacun à la fois, et avec eux, nous trouvons une solution qui vous permet de vivre différemment.

Il est souhaitable que ces personnes aient autorité dans l'organisation . Vous devrez peut-être prendre un conservateur, même si vous ne le souhaitez pas. Si nous avons une grande entreprise, tout le monde ne croira pas à notre entreprise, et quelqu'un peut mettre des bâtons dans les roues, par exemple, ne pas mettre en valeur un stand. Ici, vous aurez besoin de "l'autorité" - une personne respectée avec une vaste expérience, qui mérite une bonne attitude de ses collègues. L'autorité de l'employé dans l'équipe simplifiera la tâche et le travail de l'équipe temporaire. Les gens penseront:

- Oui, ce mec cool que nous connaissons et aimons tous, s'intègre là-dedans - apparemment, DevOps a quelque chose à voir!

Nous nous fixons un objectif

Nous avons rassemblé des gens, choisi un service, examiné les restrictions, déterminé quelles personnes nous allions influencer. Maintenant, vous devez définir un objectif et il devrait être exact sur SMART - c'est tout ce que nous aimons.

Spécifique - spécifique .

Mesurable - mesurable . C'est un point très important de SMART. Si vous ne pouvez pas mesurer quelque chose, vous ne pouvez pas le changer et comprendre quoi et comment vous avez fait mieux ou pire.

Atteignable est réalisable . Ajustez selon vos spécificités. Si vous êtes une entreprise avec une longue histoire et une lourde charge de responsabilités, qui publie une version de produit une fois par an, vous ne pourrez pas obtenir la sortie de nouvelles versions de produit toutes les heures en six mois. Cela ne fonctionnera pas de cette façon. Par conséquent, fixez-vous un véritable objectif réalisable dans une période acceptable.

Pertinent - Pertinent. Nous éliminons seulement la limitation qui poursuit vraiment nos objectifs actuels.

Temps limité - temps limité . S'il n'y a pas de délai, l'équipe fera n'importe quoi: essayez 15 technologies au lieu de 3, rédigez d'énormes rapports, menez des recherches inutiles, léchez sa mise en œuvre lorsque le but est déjà atteint.

Nous atteignons l'objectif à l'aide de la Value Stream Map - encore une fois, nous rassemblons toutes les personnes et dessinons. Mais seulement maintenant, sur la base de la carte de flux de valeur précédente, nous dessinons ce que nous voulons obtenir.



Nous mettons en évidence une limitation que nous éliminerons dès maintenant - c'est ce que l'équipe fera. À titre d'exemple, j'ai pris l'attente d'une version finale à son déploiement en production - c'est la limitation la plus courante que les gens se tournent vers des consultants.

Sur cette base, nous avons fixé la tâche: nous voulons que l'attente entre une version prête et l'entrée en action soit au maximum d'une heure.

Exemples de tâches.

• Réduisez le délai d'exécution de 4 jours à 1 heure.
• Réduisez le temps de valeur ajoutée pour les tests de 2 jours à 3 heures.
• Réduisez le déploiement du délai de 5 heures à 10 minutes.
• Augmentez le C / A de 50% à 95%, c'est-à-dire augmentez le nombre de fonctionnalités acceptées par les testeurs, en d'autres termes, améliorez la qualité des développeurs.

Des exemples de tâches ne sont pas pris de la tête - ils sont basés sur les mesures que nous avons faites lors du développement de la Value Stream Map.

Nous avons fixé une tâche similaire à notre équipe et un délai. , , . , , , .

, , , . — : - , , .

, moving-moving , , , . : , , , , , .

.

- : , , , — ? , , : , - . 1-2 .

- , — , - . : , DevOps, . , .

Pourquoi? , , , , , , , DevOps. , .

, , — , ! , , - . , , , , . , , , - .

, — . , - .

, — , . , - Value Stream Map , , .

, . Value Stream Map , , . , . SMART — , , .

, .

.

, DevOps .

«»

— «The Phoenix Project: A Novel about It, Devops, and Helping Your Business Win». DevOps — , , . :

— , , .

« “”. , DevOps » — , , . , — . , .

DevOps

. «The DevOps Handbook How to create world‑class agility, reliability, and security in Technology organizations», . handbook — : , Value Stream Map , , . , . , .

, , Value Stream Map , , , , . , , , , . : Value Stream Map , .

Accelerate

: «Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations». — . , . — Nicole Forsgren, Jez Humble Gene Kim — , , .

, , Value Stream Map, , , , . . , , , . , «Accelerate». , , , , , — , .

— DevOps . - , , DevOpsConf , – QaulityConf . ++ Whale Rider — . 27 28 , .