État du DevOps en Russie 2020

Comment comprendre l'état de quelque chose ?

Vous pouvez vous fier à votre opinion, formée à partir de diverses sources d'information, par exemple, des publications sur des sites Web ou de l'expérience. Vous pouvez demander à des collègues, des connaissances. Une autre option consiste à regarder les sujets des conférences : le comité de programme est composé de représentants actifs de l'industrie, nous leur faisons donc confiance pour choisir les sujets pertinents. Un domaine distinct est la recherche et les rapports. Mais il y a un problème. Des recherches sur l'état de DevOps sont menées chaque année dans le monde, des rapports sont publiés par des entreprises étrangères et il n'y a presque aucune information sur DevOps russe.

Mais le jour est venu où une telle étude a été menée, et aujourd'hui nous parlerons des résultats. L'état de DevOps en Russie a été étudié conjointement par les entreprises "Express 42"Et"Ontico". Express 42 aide les entreprises technologiques à mettre en œuvre et à développer des pratiques et des outils DevOps et a été l'un des premiers à parler de DevOps en Russie. Les auteurs de l'étude, Igor Kurochkin et Vitaly Khabarov, sont engagés dans l'analyse et le conseil chez Express 42, tout en ayant une formation technique d'exploitation et une expérience dans différentes entreprises. Pendant 8 ans, les collègues ont examiné des dizaines d'entreprises et de projets - des startups aux entreprises - avec des problèmes différents, ainsi qu'une maturité culturelle et d'ingénierie différente.

Dans leur rapport, Igor et Vitaly ont expliqué quels problèmes étaient en cours de recherche, comment ils les ont résolus, ainsi que le principe de la recherche DevOps et pourquoi Express 42 a décidé de mener la sienne. Leur rapport peut être consulté ici.

Recherche DevOps

La conversation a été lancée par Igor Kurochkin.

Nous demandons régulièrement au public des conférences DevOps : "Avez-vous lu le rapport sur l'état de DevOps pour cette année ?" Peu lèvent la main, et notre étude a montré que seul un tiers les étudie. Si vous n'avez jamais vu de tels rapports, disons tout de suite qu'ils sont tous très similaires. Le plus souvent, il y a des phrases comme: "Par rapport à l'année dernière ..."

Ici, nous avons le premier problème, et après deux autres :

1. Nous n'avons pas de données pour l'année dernière. L'état du DevOps en Russie n'intéresse personne ;
2. Méthodologie. Il n'est pas clair comment tester des hypothèses, comment construire des questions, comment analyser, comparer des résultats, trouver des liens ;
3. Terminologie. Tous les rapports sont en anglais, une traduction est nécessaire, un cadre DevOps commun n'a pas encore été inventé et chacun propose le sien.

Voyons comment les analyses d'état DevOps ont été effectuées dans le monde.

Les informations historiques

Des recherches DevOps sont menées depuis 2011. Puppet, un développeur de systèmes de gestion de configuration, a été le premier à les réaliser. C'était à l'époque l'un des principaux outils de description de l'infrastructure sous forme de code. Jusqu'en 2013, ces études étaient simplement des enquêtes fermées et aucun rapport public.

En 2013, IT Revolution est apparu, l'éditeur de tous les principaux livres sur DevOps. En collaboration avec Puppet, ils ont préparé la première publication State of DevOps, où 4 métriques clés sont apparues pour la première fois. L'année suivante, ThoughtWorks, une société de conseil connue pour ses radars technologiques réguliers sur les pratiques et les outils de l'industrie, s'est impliquée. Et en 2015, une section avec la méthodologie a été ajoutée, et il est devenu clair comment ils effectuent l'analyse.

En 2016, les auteurs de l'étude, ayant créé leur propre société DORA (DevOps Research and Assessment), ont publié un rapport annuel. L'année suivante, DORA et Puppet publient leur dernier rapport conjoint.

Et puis quelque chose d'intéressant a commencé:

En 2018, les entreprises se sont séparées et deux rapports indépendants ont été publiés : l'un de Puppet, le second de DORA avec Google. DORA a continué à tirer parti de sa méthodologie avec des mesures clés, des profils de performance et des pratiques d'ingénierie qui ont un impact sur les mesures clés et les performances à l'échelle de l'entreprise. Et Puppet a proposé sa propre approche avec une description du processus et de l'évolution de DevOps. Mais l'histoire n'a pas pris racine, en 2019, Puppet a abandonné cette méthodologie et a publié une nouvelle version des rapports, qui répertorie les pratiques clés et comment elles affectent DevOps de leur point de vue. Puis un autre événement s'est produit : Google a acheté DORA et, ensemble, ils ont publié un autre rapport. Vous l'avez peut-être vu.

Cette année, les choses se sont compliquées. Puppet est connu pour avoir lancé sa propre enquête. Ils l'ont fait une semaine plus tôt que nous, et c'est déjà terminé. Nous y avons participé et avons examiné les sujets qui les intéressaient. Maintenant, Puppet fait son analyse et se prépare à publier le rapport.

Mais il n'y a toujours aucune annonce de DORA et Google. En mai, au début habituel de l'enquête, on a appris que Nicole Forsgren, l'une des fondatrices de DORA, avait déménagé dans une autre entreprise. Par conséquent, nous avons supposé qu'il n'y aurait pas de recherche et de rapport de DORA cette année.

Comment ça se passe en Russie ?

Nous n'avons pas fait de recherche DevOps. Nous avons parlé lors de conférences, racontant les découvertes d'autres personnes, et Raiffeisenbank a traduit "State of DevOps" pour 2019 (vous pouvez trouver leur annonce sur Habré), un grand merci à eux. Et c'est tout.

Par conséquent, nous avons mené nos propres recherches en Russie en utilisant les méthodologies et les résultats de DORA. Nous avons utilisé le rapport de collègues de la Raiffeisenbank pour nos recherches, notamment pour la synchronisation de la terminologie et de la traduction. Et des questions pertinentes pour l'industrie ont été tirées des rapports DORA et du questionnaire Puppet de cette année.

Processus de recherche

Le rapport n'est que la partie finale. L'ensemble du processus de recherche comprend quatre étapes principales :

Au cours de la phase de préparation, nous avons interrogé des experts de l'industrie et préparé une liste d'hypothèses. Sur leur base, des questions ont été compilées et une enquête a été lancée pour tout le mois d'août. Ensuite, nous avons analysé et préparé le rapport lui-même. Pour DORA, ce processus prend 6 mois. Nous nous sommes rencontrés en 3 mois, et maintenant nous comprenons que nous avions à peine assez de temps : ce n'est qu'en effectuant l'analyse que vous comprenez quelles questions vous devez poser.

Participants

Tous les reportages étrangers commencent par un portrait des participants, et la plupart d'entre eux ne viennent pas de Russie. Le pourcentage de répondants russes fluctue entre 5 et 1 % d'une année sur l'autre, ce qui ne permet pas de tirer des conclusions.

Carte du rapport Accelerate State of DevOps 2019 :

Dans notre étude, nous avons réussi à interviewer 889 personnes - c'est beaucoup (DORA interroge environ un millier de personnes par an dans ses rapports) et ici nous avons atteint l'objectif :

Certes, tous nos participants n'ont pas atteint la fin : le pourcentage d'achèvement s'est avéré être légèrement inférieur à la moitié. Mais même cela était suffisant pour obtenir un échantillon représentatif et effectuer une analyse. DORA ne divulgue pas les pourcentages de remplissage dans ses rapports, il n'y a donc pas de comparaison ici.

Industries et postes

Nos répondants représentent une douzaine d'industries. La moitié travaille dans les technologies de l'information. Viennent ensuite les services financiers, le commerce, les télécommunications et autres. Parmi les postes figurent des spécialistes (développeur, testeur, ingénieur d'exploitation) et des cadres (responsables d'équipes, de groupes, de domaines, de directeurs) :

Un sur deux travaille pour une entreprise de taille moyenne. Une personne sur trois travaille dans de grandes entreprises. La plupart travaillent en équipes de 9 personnes maximum. Séparément, nous avons posé des questions sur les principales activités, et la majorité sont en quelque sorte liées à l'exploitation, et environ 40% sont engagées dans le développement :

Nous avons donc collecté des informations pour la comparaison et l'analyse des représentants de différentes industries, entreprises, équipes. Mon collègue Vitaly Khabarov parlera de l'analyse.

Analyse et comparaison

Vitaly Khabarov : Un grand merci à tous les participants qui ont répondu à notre enquête, rempli des questionnaires et nous ont fourni des données pour une analyse plus approfondie et la vérification de nos hypothèses. Et grâce à nos clients et clients, nous avons une riche expérience qui a permis d'identifier les préoccupations de l'industrie et de formuler les hypothèses que nous avons testées dans nos recherches.

Malheureusement, vous ne pouvez pas simplement prendre une liste de questions d'un côté et des données de l'autre, les comparer d'une manière ou d'une autre, dire: "Oui, tout fonctionne comme ça, nous avions raison" et se disperser. Non, il faut une méthodologie et des méthodes statistiques pour être sûr que nous ne nous trompons pas et que nos conclusions sont fiables. Ensuite, nous pouvons construire notre travail ultérieur sur la base de ces données :

Indicateurs clés

Nous avons pris la méthodologie DORA comme base, qu'ils ont décrite en détail dans le livre "Accelerate State of DevOps". Nous avons vérifié si les indicateurs clés sont adaptés au marché russe, s'ils peuvent être utilisés de la même manière que DORA utilise pour répondre à la question : « Comment l'industrie en Russie correspond-elle à l'industrie étrangère ? »

Indicateurs clés :

1. Fréquence de déploiement. À quelle fréquence une nouvelle version de l'application est-elle déployée dans l'environnement de production (modifications planifiées, hors correctifs et réponse aux incidents) ?
2. Délai de livraison. Quel est le délai moyen entre la validation d'une modification (écriture d'une fonctionnalité sous forme de code) et le déploiement de la modification dans l'environnement de production ?
3. Le temps de récupération. Combien de temps faut-il en moyenne pour restaurer une application dans un environnement de production après un incident, une dégradation de service ou la découverte d'un bogue affectant les utilisateurs de l'application ?
4. Changements infructueux. Quel pourcentage de déploiements dans l'environnement de production entraînent une dégradation des applications ou des incidents et nécessitent une correction (annulation des modifications, développement d'un correctif ou d'un correctif) ?

DORA dans ses recherches a trouvé un lien entre ces mesures et la performance organisationnelle. Nous le testons également dans notre étude.

Mais pour vous assurer que les quatre mesures clés peuvent influencer quelque chose, vous devez comprendre : sont-elles liées d'une manière ou d'une autre ? DORA a répondu par l'affirmative avec une mise en garde : la relation entre les changements infructueux (Change Failure Rate) et trois autres métriques est légèrement plus faible. Nous avons à peu près la même image. Si le délai de livraison, la fréquence de déploiement et le temps de récupération sont corrélés (nous avons établi cette corrélation via la corrélation de Pearson et via l'échelle de Chaddock), alors il n'y a pas de corrélation aussi forte avec des changements infructueux.

En principe, la plupart des répondants ont tendance à répondre qu'ils ont un nombre plutôt faible d'incidents en production. Bien que nous verrons plus tard qu'il existe toujours une différence significative entre les groupes de répondants en termes de changements infructueux, nous ne pouvons pas encore utiliser cette métrique pour cette division.

Nous attribuons cela au fait que (comme il s'est avéré lors de l'analyse et de la communication avec certains de nos clients) il y a une légère différence dans la perception de ce qui est considéré comme un incident. Si nous parvenons à rétablir les performances de notre service pendant la fenêtre technique, cela peut-il être considéré comme un incident ? Probablement pas, car nous avons tout réparé, nous sommes géniaux. Pouvons-nous considérer cela comme un incident si nous devions relancer notre application 10 fois dans un mode normal et familier pour nous ? Il semble que non. Par conséquent, la question de la relation des changements infructueux avec d'autres paramètres reste ouverte. Nous allons l'affiner plus loin.

Ce qui est important ici, c'est que nous avons trouvé une corrélation significative entre les délais de livraison, le temps de récupération et la fréquence de déploiement. Par conséquent, nous avons pris ces trois paramètres pour diviser davantage les répondants en groupes de performance.

Combien de grammes?

Nous avons utilisé l'analyse de cluster hiérarchique :

• Nous distribuons les répondants sur un espace à n dimensions, où les coordonnées de chaque répondant sont leurs réponses aux questions.
• Chaque répondant est déclaré un petit groupe.
• Nous combinons les deux clusters les plus proches l'un de l'autre en un cluster plus grand.
• Nous trouvons la prochaine paire de clusters et les combinons en un cluster plus grand.

C'est ainsi que nous regroupons tous nos répondants dans le nombre de clusters dont nous avons besoin. A l'aide d'un dendrogramme (arbre de connexions entre clusters), on visualise la distance entre deux clusters voisins. Il ne nous reste plus qu'à fixer une certaine distance limite entre ces amas et à dire : "Ces deux groupes se distinguent bien l'un de l'autre car la distance qui les sépare est gigantesque."

Mais il y a un problème caché ici : nous n'avons aucune restriction sur le nombre de clusters - nous pouvons obtenir 2, 3, 4, 10 clusters. Et la première idée était - pourquoi ne pas diviser tous nos répondants en 4 groupes, comme le fait DORA. Mais nous constatons que les différences entre ces groupes deviennent insignifiantes, et nous ne pouvons pas être sûrs que le répondant appartient réellement à son groupe, et non au groupe voisin. Nous ne pouvons pas encore diviser le marché russe en quatre groupes. Par conséquent, nous nous sommes arrêtés sur trois profils entre lesquels il existe une différence statistiquement significative :

Ensuite, nous avons déterminé le profil par clusters : nous avons pris la médiane de chaque métrique pour chaque groupe et compilé un tableau des profils de performance. En fait, nous avons obtenu les profils de performance du participant moyen dans chaque groupe. Nous avons identifié trois profils d'efficacité : Faible, Moyen, Élevé :

Ici, nous avons confirmé notre hypothèse selon laquelle 4 mesures clés conviennent pour déterminer le profil de performance, et elles fonctionnent à la fois sur les marchés occidentaux et russes. Il existe une différence entre les groupes et elle est statistiquement significative. Je souligne qu'il existe une différence significative entre les profils de performance en termes de métrique des changements infructueux en termes de moyenne, même si nous n'avons pas initialement divisé les répondants par ce paramètre.

Alors la question se pose : comment utiliser tout cela ?

Comment utiliser

Si nous prenons n'importe quelle équipe, 4 mesures clés et l'appliquons au tableau, alors dans 85% des cas, nous n'obtiendrons pas un match complet - ce n'est qu'un participant moyen, et non ce qui est en réalité. Nous sommes tous (et chaque équipe) légèrement différents.

Nous avons vérifié : nous avons pris nos répondants et le profil de performance DORA, et nous avons regardé combien de répondants correspondaient à tel ou tel profil. Nous avons constaté que seulement 16 % des répondants correspondaient définitivement à l'un des profils. Tout le reste est dispersé quelque part entre les deux :

Cela signifie que le profil d'efficacité a une portée limitée. Pour comprendre où vous en êtes en première approximation, vous pouvez utiliser ce tableau : "Oh, il semble que nous soyons plus proches de Moyen ou Élevé !" Si vous comprenez où aller ensuite, cela peut suffire. Mais si votre objectif est une amélioration constante et continue, et que vous voulez savoir plus exactement où développer et quoi faire, alors des fonds supplémentaires sont nécessaires. Nous les avons appelés calculatrices :

• Calculatrice DORA
• Calculatrice Express 42* (en développement)
• Développement propre (vous pouvez créer votre propre calculateur interne).

A quoi servent-ils ? Comprendre:

• L'équipe au sein de notre organisation est-elle à la hauteur de nos normes ?
• Si non, pouvons-nous l'aider, l'accélérer dans le cadre de l'expertise dont dispose notre entreprise ?
• Si oui, peut-on faire encore mieux ?

Vous pouvez également les utiliser pour collecter des statistiques au sein de l'entreprise :

• Quelles équipes avons-nous ?
• Diviser les équipes en profils ;
• Voyez : Oh, ces commandes sont sous-performantes (elles ne tirent pas un peu), mais elles sont cool : elles se déploient tous les jours, sans erreur, elles ont un délai de moins d'une heure.

Et puis vous pouvez découvrir qu'il existe au sein de notre entreprise l'expertise et les outils nécessaires pour les équipes qui ne sont pas encore à la hauteur.

Ou, si vous comprenez que vous vous sentez bien au sein de l'entreprise, que vous êtes meilleur que beaucoup, alors vous pouvez regarder un peu plus loin. Il ne s'agit que de l'industrie russe : pouvons-nous obtenir l'expertise nécessaire dans l'industrie russe pour nous accélérer ? La calculatrice Express 42 vous aidera ici (elle est en cours de développement). Si vous avez dépassé le marché russe, alors regardez Calculatrice DORA et au marché mondial.

Bien. Et si vous êtes dans le groupe Elit sur la calculatrice DORA, que devez-vous faire ? Il n'y a pas de bonne solution ici. Vous êtes très probablement à la pointe de l'industrie, et une accélération et une fiabilité supplémentaires sont possibles grâce à la R&D interne et à la dépense de plus de ressources.

Passons au plus doux - comparaison.

Comparaison

Nous avons d'abord voulu comparer l'industrie russe à l'industrie occidentale. Si on compare directement, on voit qu'on a moins de profils, et qu'ils sont un peu plus mélangés entre eux, les frontières sont un peu plus floues :

Nos interprètes d'élite sont cachés parmi les interprètes de haut niveau, mais ils sont là - ce sont l'élite, des licornes qui ont atteint des sommets significatifs. En Russie, la différence entre le profil Elite et le profil Haut n'est pas encore assez significative. Nous pensons qu'à l'avenir cette séparation se fera en raison d'une montée en puissance de la culture d'ingénierie, de la qualité de mise en œuvre des pratiques d'ingénierie et de l'expertise au sein des entreprises.

Si nous passons à une comparaison directe au sein de l'industrie russe, nous pouvons voir que les équipes de haut niveau sont meilleures à tous égards. Nous avons également confirmé notre hypothèse selon laquelle il existe une relation entre ces mesures et la performance organisationnelle : les équipes de haut niveau sont beaucoup plus susceptibles non seulement d'atteindre les objectifs, mais aussi de les dépasser.
Devenons des équipes de haut niveau et ne nous arrêtons pas là :

Mais cette année est spéciale, et nous avons décidé de vérifier comment les entreprises s'en sortent en cas de pandémie : les équipes de haut niveau s'en sortent beaucoup mieux et se sentent mieux que la moyenne du secteur :

• 1,5 à 2 fois plus susceptibles de lancer de nouveaux produits,
• 2 fois plus susceptibles d'améliorer la fiabilité et/ou les performances de l'infrastructure applicative.

C'est-à-dire que les compétences qu'ils possédaient déjà les ont aidés à se développer plus rapidement, à lancer de nouveaux produits, à modifier des produits existants, conquérant ainsi de nouveaux marchés et de nouveaux utilisateurs :

Quoi d'autre a aidé nos équipes ?

Pratiques d'ingénierie

Je vais vous parler des résultats significatifs pour chaque pratique que nous avons testée. Peut-être que quelque chose d'autre a aidé les équipes, mais nous parlons de DevOps. Et au sein de DevOps, nous constatons une différence entre des équipes de profils différents.

Plateforme en tant que service

Nous n'avons pas trouvé de relation significative entre l'âge de la plateforme et le profil de l'équipe : les plateformes sont apparues à peu près au même moment pour les équipes basses et les équipes hautes. Mais pour ce dernier, la plate-forme fournit, en moyenne, plus de services et plus d'interfaces de programmation pour le contrôle via le code de programme. Et les équipes de plate-forme sont plus susceptibles d'aider leurs développeurs et leurs équipes à utiliser la plate-forme, à résoudre plus souvent leurs problèmes et incidents liés à la plate-forme et à éduquer les autres équipes.

Infrastructure en tant que code

Tout est assez standard ici. Nous avons trouvé une relation entre l'automatisation du travail du code d'infrastructure et la quantité d'informations stockées dans le référentiel d'infrastructure. Les commandes High profile stockent plus d'informations dans les référentiels : il s'agit de la configuration de l'infrastructure, du pipeline CI/CD, des paramètres d'environnement et des paramètres de construction. Ils stockent ces informations plus souvent, fonctionnent mieux avec le code d'infrastructure et automatisent davantage de processus et de tâches pour travailler avec le code d'infrastructure.

Fait intéressant, nous n'avons pas constaté de différence significative dans les tests d'infrastructure. J'attribue cela au fait que les équipes de haut niveau ont plus d'automatisation des tests en général. Peut-être ne devraient-ils pas être distraits séparément par les tests d'infrastructure, mais plutôt par les tests avec lesquels ils vérifient les applications, et grâce à eux, ils voient déjà quoi et où ils ont cassé.

Intégration et livraison

La section la plus ennuyeuse, car nous avons confirmé que plus vous avez d'automatisation, mieux vous travaillez avec le code, plus vous avez de chances d'obtenir de meilleurs résultats.

Architecture

Nous voulions voir comment les microservices affectent les performances. En vérité, ils ne le font pas, car l'utilisation de microservices n'est pas associée à une augmentation des indicateurs de performance. Les microservices sont utilisés à la fois pour les commandes à profil élevé et les commandes à profil bas.

Mais ce qui est significatif, c'est que pour les High-teams, le passage à une architecture microservice leur permet de développer et de déployer leurs services en toute autonomie. Si l'architecture permet aux développeurs d'agir de manière autonome, sans attendre quelqu'un d'extérieur à l'équipe, alors c'est une compétence clé pour gagner en rapidité. Dans ce cas, les microservices aident. Et juste leur mise en œuvre ne joue pas un grand rôle.

Comment avons-nous découvert tout cela ?

Nous avions un plan ambitieux pour reproduire entièrement la méthodologie DORA, mais nous manquions de ressources. Si DORA utilise beaucoup de parrainage et que leurs recherches prennent six mois, nous avons fait nos recherches en peu de temps. Nous voulions construire un modèle DevOps comme DORA, et nous le ferons à l'avenir. Jusqu'à présent, nous nous sommes limités aux cartes thermiques :

Nous avons examiné la répartition des pratiques d'ingénierie entre les équipes de chaque profil et avons constaté que les équipes de haut niveau, en moyenne, étaient plus susceptibles d'utiliser des pratiques d'ingénierie. Vous pouvez en savoir plus sur tout cela dans notre rapport.

Pour changer, passons des statistiques complexes aux simples.

Qu'avons-nous découvert d'autre ?

Outils

On observe que la plupart des commandes sont utilisées par les OS de la famille Linux. Mais Windows est toujours à la mode - au moins un quart de nos répondants ont noté l'utilisation de l'une ou l'autre de ses versions. Il semble que le marché ait ce besoin. Par conséquent, vous pouvez développer ces compétences et faire des présentations lors de conférences.

Parmi les orchestrateurs, ce n'est un secret pour personne, Kubernetes est en tête (52%). Le prochain orchestrateur en ligne est Docker Swarm (environ 12 %). Les systèmes CI les plus populaires sont Jenkins et GitLab. Le système de gestion de configuration le plus populaire est Ansible, suivi de notre bien-aimé Shell.

Amazon est actuellement le premier fournisseur d'hébergement cloud. La part des nuages ​​russes augmente progressivement. L'année prochaine, il sera intéressant de voir comment les fournisseurs de cloud russes se sentiront, si leur part de marché augmentera. Ils sont, ils peuvent être utilisés, et c'est tant mieux :

Je passe la parole à Igor, qui donnera quelques statistiques supplémentaires.

Diffusion des pratiques

Igor Kurochkin : Séparément, nous avons demandé aux répondants d'indiquer comment les pratiques d'ingénierie considérées sont réparties dans l'entreprise. Dans la plupart des entreprises, il existe une approche mixte, consistant en un ensemble différent de modèles, et les projets pilotes sont très populaires. Nous avons également constaté une légère différence entre les profils. Les représentants du profil élevé utilisent plus souvent le modèle «Initiative d'en bas», lorsque de petites équipes de spécialistes modifient les processus de travail, les outils et partagent les pratiques réussies avec d'autres équipes. Chez Medium, il s'agit d'une initiative descendante qui touche toute l'entreprise à travers la création de communautés et de pôles d'excellence :

Agile et DevOps

La question de la connexion entre Agile et DevOps est souvent discutée dans l'industrie. Cette question est également soulevée dans le rapport State of Agile pour 2019/2020, nous avons donc décidé de comparer la manière dont les activités Agile et DevOps sont connectées dans les entreprises. Nous avons constaté que DevOps sans Agile est rare. Pour la moitié des répondants, la diffusion d'Agile a commencé beaucoup plus tôt, et environ 20% ont observé le démarrage simultané, et l'un des signes d'un profil bas sera l'absence de pratiques Agile et DevOps :

Topologies de commande

A la fin de l'année dernière, le livre "Topologies d'équipe», qui propose un cadre pour décrire les topologies de commande. Il est devenu intéressant pour nous de savoir si cela s'applique aux entreprises russes. Et nous avons posé la question : « Quels modèles trouvez-vous ? ».

Des équipes d'infrastructure sont observées dans la moitié des répondants, ainsi que des équipes distinctes pour le développement, les tests et l'exploitation. Des équipes DevOps distinctes ont noté 45 %, parmi lesquelles les représentants de High sont plus courants. Viennent ensuite les équipes interfonctionnelles, qui sont également plus courantes chez High. Des commandes SRE distinctes apparaissent dans les profils Haut, Moyen et sont rarement vues dans le profil Bas :

Ratio DevQaOps

Nous avons vu cette question sur FaceBook du chef d'équipe de l'équipe de la plateforme Skyeng - il s'intéressait au ratio de développeurs, de testeurs et d'administrateurs dans les entreprises. Nous lui avons posé la question et examiné les réponses en fonction des profils : les représentants de haut niveau ont moins d'ingénieurs de test et d'exploitation pour chaque développeur :

Plans pour l'année 2021

Dans les plans pour l'année prochaine, les répondants ont noté les activités suivantes :

Ici vous pouvez voir l'intersection avec la conférence DevOps Live 2020. Nous avons soigneusement examiné le programme :

• L'infrastructure en tant que produit
• Transformation DevOps
• Distribution des pratiques DevOps
• DevSecOps
• Clubs de cas et discussions

Mais le temps de notre présentation n'est pas suffisant pour couvrir tous les sujets. Laissé dans les coulisses :

• Plateforme en tant que service et en tant que produit ;
• Infrastructure en tant que code, environnements et nuages ;
• Intégration et livraison continues ;
• Architecture;
• Modèles DevSecOps ;
• Plate-forme et équipes interfonctionnelles.

Rapport nous avons un volumineux 50 pages, et vous pouvez le voir plus en détail.

Résumant

Nous espérons que nos recherches et notre rapport vous inciteront à expérimenter de nouvelles approches de développement, de test et d'exploitation, ainsi qu'à vous aider à naviguer, à vous comparer aux autres participants à l'étude et à identifier les domaines dans lesquels vous pouvez améliorer vos propres approches.

Résultats de la première étude sur l'état du DevOps en Russie :

• Métriques clés. Nous avons constaté que les métriques clés (délai de livraison, fréquence de déploiement, temps de récupération et échecs de modification) conviennent à l'analyse de l'efficacité des processus de développement, de test et d'exploitation.
• Profils haut, moyen, bas. Sur la base des données collectées, il est possible de distinguer statistiquement différents groupes d'Elevé, Moyen, Faible avec des caractéristiques distinctives en termes de métriques, pratiques, processus et outils. Les représentants du profil élevé affichent de meilleurs résultats que les faibles. Ils sont plus susceptibles d'atteindre et de dépasser leurs objectifs.
• Indicateurs, pandémie et plans pour 2021. Un indicateur particulier cette année est la manière dont les entreprises ont fait face à la pandémie. Les représentants de High s'en sont mieux sortis, ont connu un engagement accru des utilisateurs, et les principales raisons du succès étaient des processus de développement efficaces et une forte culture d'ingénierie.
• Pratiques, outils DevOps et leur développement. Les principaux plans des entreprises pour l'année à venir comprennent le développement de pratiques et d'outils DevOps, l'introduction de pratiques DevSecOps et des changements dans la structure organisationnelle. Et la mise en œuvre et le développement efficaces des pratiques DevOps sont réalisés à l'aide de projets pilotes, de la formation de communautés et de centres d'excellence, d'initiatives aux niveaux supérieur et inférieur de l'entreprise.

Nous aimerions entendre vos commentaires, histoires, commentaires. Nous remercions tous ceux qui ont participé à l'étude et attendons avec impatience votre participation l'année prochaine.

Source: habr.com