Bonjour, Habr! Et encore une fois, Alexey Pristavko est en contact.

Contrairement à mes articles précédents, nous parlerons aujourd'hui de personnes. Les héros du jour sont le service d'exploitation, dont je représente les intérêts, et le service de développement.

Le travail coordonné de ces services est la clé d'un lancement réussi et d'un «vol» fluide du service créé. Mais, comme mon expérience (et pas seulement) le montre, pratiquement aucun projet ne peut se passer de conflits et de désaccords dont la victime est un service innocent.

Dans cet article, je vais essayer de répondre aux questions suivantes:

• Comment les méthodes et processus de développement affectent-ils les opérations?
• Qu'est-ce qui motive chaque côté du conflit?
• Quelle est la cause profonde du désaccord?

Bienvenue au chat!

Quels sont les défis auxquels sont confrontés les services

Nous connaîtrons mieux les services et commencerons par le service exploitation (c'est aussi un service support). Pourquoi cette terrible bête est-elle nécessaire, quelle tâche accomplit-elle et "pour qui" fonctionne-t-elle?

La tâche principale du service d'exploitation est de gérer le niveau des services, c'est-à-dire de maintenir le fonctionnement du système informatique dans le cadre du SLA.
L'exploitation doit fournir un accès constant au service et à son bon fonctionnement dans le cadre d'un accord avec le client - généralement avec l'entreprise.

Voici la solution à ce problème:

• Gestion des incidents: restauration de la fonction métier lors d'un accident;
  
• Gestion des problèmes: s'attaquer aux causes probables d'accidents et d'incidents;
  
• Gestion de la configuration: collecte d'informations et analyse des paramètres de fonctionnement des logiciels et des infrastructures;
  
• Gestion du changement: minimiser les risques de problèmes et d'accidents lors des changements.
  

Le rôle du service de développement est également compréhensible - la création initiale d'un service informatique et l'introduction de nouvelles fonctionnalités à la demande du client.

Certes, vous avez déjà des soupçons sur les points de friction des développeurs et du support, car là où il y a des intersections de tâches, il y a des conflits. Mais ne vous précipitez pas vers des conclusions. L'éternel débat entre développeurs et administrateurs est loin d'être l'épicentre des «batailles».

Où grandissent les désaccords

La «guerre» des programmeurs et des administrateurs n'est pas une confrontation des intérêts humains, c'est une confrontation des services.



Le problème réside dans les priorités et la motivation de ces mêmes services. Dans sa forme la plus générale, cela peut être décrit comme suit:

• L'équipe de développement souhaite utiliser la technologie de première fraîcheur (développement professionnel, intérêt) et faire le travail le plus rapidement possible (motivation externe).
  

• L'opération s'intéresse aux technologies les plus stables (leurs problèmes sont connus et ont des solutions généralement acceptées) et des explications détaillées de ce qu'il faut faire en cas de problèmes dans le logiciel développé (motivation externe pour la vitesse de dépannage).
  

Dans le même temps, il est important de comprendre que non seulement les développeurs "ont vu" de nouvelles fonctionnalités et pas toujours exclusivement les administrateurs soulèvent les morts.

• Les administrateurs sont activement impliqués dans le processus de développement - dans la construction des infrastructures, les schémas de tolérance aux pannes et d'évolutivité, dans la préparation des configurations initiales et, idéalement, dans le processus de préparation des exigences logicielles. Tout cela s'appelle un processus de développement de solution (ne le confondez pas avec l'écriture directe de code!).
  

• Les programmeurs participent activement à l'opération. Ils corrigent les erreurs logicielles, effectuent des optimisations du système et des améliorations techniques pour se conformer au système SLA, c'est-à-dire qu'ils résolvent le problème d'accessibilité du service informatique final.
  

Le conflit entre programmeurs et administrateurs naît de la substitution de concepts:

• développement → codage;
  
• support → administration des services applicatifs.
  

La déformation de la structure de subordination sur une base professionnelle (plutôt que sur une base fonctionnelle) conduit toujours à des conflits. En règle générale, les administrateurs et les programmeurs travaillent dans des équipes complètement différentes, et parfois dans des départements, et sont motivés respectivement par le fonctionnement et le développement.

En conséquence, les programmeurs du département de développement qui sont «forcés» de corriger d'anciens bogues ou, Dieu nous en préserve, d'écrire de la documentation, sont mécontents. Les administrateurs de l'opération sont également indignés, à qui il est demandé de lancer rapidement un piano à queue pour élever un nouveau serveur pour les développeurs ou de les aider avec des conseils.

Chacune des parties perçoit cela non comme une solution commune au problème, mais comme une distraction par rapport à ses propres tâches, qui ne sont pas visibles même sans cette fin.

Mais il ne faut pas oublier le client, car lui, bien qu'indirectement, participe également au conflit. En règle générale, il doit obtenir un service établi et stable. Un code nu, même le meilleur, est complètement inutile pour le client en dehors du système. Il a fondamentalement une image différente du monde:



Un client standard n'a pas de tâche à créer, à écrire ou, désolé, Lord, à mettre en œuvre. Le client souhaite résoudre un problème métier à l'aide du bouton magique «Tout faire bien», tandis que l'informatique impose de proposer une solution spécifique.

Jetons un œil à tous les aspects du conflit:



Bien sûr, ce n'est que la partie la plus courante des exigences fonctionnelles et opérationnelles.

Nous avons donc découvert qu'il y avait encore trois parties au conflit : le développement, l'exploitation et le client. De plus, c'est le client qui est en grande partie un "provocateur", partageant la responsabilité entre les équipes. Ce n'est pas mauvais en soi, et sans la séparation généralement acceptée des équipes et des responsabilités entre elles, ce serait un conflit gérable.

Mais nous savons déjà que les deux services ne sont pas autosuffisants. Ils sont séparés par une barricade «de service» et en même temps ils doivent non seulement interagir entre eux sur le terrain du transfert de responsabilité en fonction des étapes de la vie du produit, mais aussi participer activement à la résolution des problèmes des uns et des autres.

Un autre aspect de l’influence du client est sa stratégie et sa méthodologie de développement commercial. Dans ce cas, je parle de ne pas comprendre à quoi ressemble le processus de développement d'une solution informatique spécifique. Sans une telle compréhension, le client exige souvent de faire d'un chat une baleine, puis d'y attacher des ailes. Et toujours, tout est urgent. Parfois, cela se justifie par la situation et l'innovation de l'idée, parfois c'est une conséquence de la course au leader du marché et de la copie hâtive. Les raisons peuvent être très différentes, mais le résultat est un.

Le problème est qu'une telle stratégie se traduit par des expériences constantes et la nécessité d'obtenir des résultats dans les plus brefs délais. Cette approche nous plonge dans l'abîme du développement continu au lieu d'un travail visant un résultat précis. En principe, le dernier problème est résolu par les architectes d'entreprise, mais vous ne trouverez pas ces gars dans l'après-midi avec le feu.

Processus de développement

Enfin, nous sommes presque arrivés au point où tout allait bien. Quelle est la clé des opérations de service?

1. Transparence des améliorations. Pour gérer le changement, vous devez comprendre quoi, comment et pourquoi cela a été fait.
   
2. Documentation sur la logique de travail et de maintenance. Idéalement, sous forme d'instructions. La clé de la conformité au SLA n'est pas seulement la fiabilité, mais aussi une compréhension claire de quoi et comment faire, qui devrait être présente pour tous les artistes. La «connaissance orale» ne convient pas ici - très souvent, les gens travaillent par roulement, et il est tout simplement impossible de tout collecter et tout expliquer. Et la mémoire dans une situation stressante (et un accident est toujours un stress) peut échouer.
   
3. Une procédure de transfert claire à l'appui de la nouvelle version avec test de ses caractéristiques opérationnelles et du bon fonctionnement du fonctionnel. D'une manière simple - régression et tests de résistance. La fonctionnalité simple de la nouvelle fonctionnalité excite le moins possible le fonctionnement: l'équipe de développement elle-même corrigera la libération de garantie échouée. Mais l'erreur introduite dans l'ancienne fonctionnalité, l'opération devrait, sinon l'éliminer d'elle-même, alors au moins traiter, prouver parfois la culpabilité du développement.
   
4. Une opportunité de transférer vos besoins au travail d'un nouveau projet. C'est le développement qui définit les caractéristiques opérationnelles les plus importantes. Par exemple, si le logiciel ne sait pas comment fonctionner dans un cluster, l'opération ne pourra pas le rendre indépendamment vraiment fiable.
   

Quel est le service d'exploitation et pourquoi est-il important pour quelqu'un de savoir comment fonctionne l'équipe de développement, nous l'avons compris. Passons à la partie la plus intéressante - nous analyserons les différentes méthodologies de développement et leur impact sur le service d'exploitation.

Commençons par les classiques: les modèles Waterfall.

Cascade

Waterfall se concentre sur la fourniture de fonctionnalités complètes et sophistiquées. Le modèle de version est cyclique. Le cycle dure de plusieurs semaines (extrêmement rare) aux trimestres et six mois. Il existe presque toujours une collection cohérente d'exigences, leur analyse, le développement d'une architecture de solution, l'évaluation de sa durée, la planification et des tests de régression à part entière à la fin.

Le respect des intérêts de l'exploitation dépend de la mise en œuvre spécifique. Étant donné que les étapes nécessaires sont généralement mises en évidence, le processus implique la prise en compte de toutes les exigences et procédures formelles de transfert à l'exploitation, y compris la documentation.

Les principaux problèmes de Waterfall pour le client sont la durée des itérations et une longue stabilisation après la sortie. Parfois, le client est obligé d'attendre plusieurs mois avant qu'un produit apparaisse dans le produit qui a besoin d'une semaine pour être créé.

Si le résultat est loin d'être attendu, le client devra endurer jusqu'à la fin d'un nouveau cycle, voire deux. Régulièrement à sa place est le service d'exploitation. Et la fonctionnalité technique est le plus souvent la dernière en ligne.

Chaque gros rejet s'accompagne d'un tas d'erreurs qui sont éliminées pendant la période de stabilisation. Habituellement, cela se transforme en enfer pour toutes les parties - le développement est obligé de se lancer dans l'exploitation, l'opération accepte les incidents et pousse leur développement pour garantir l'élimination par tous les moyens, et le client, regardant tout ce gâchis et l'argent perdu, se déchire les cheveux.

Malgré tout cela, du point de vue du fonctionnement, Waterfall est le processus méthodologique le plus uniforme et prévisible dans lequel vous pouvez vous intégrer. De manière générale, ni la durée du cycle, ni la stabilisation de l'opération ne sont particulièrement concernées. Plus le temps s'écoule entre les versions, plus vous pouvez travailler calmement - et c'est toujours un plus. De plus, lorsqu'il est certain que rien ne changera pendant encore six mois, il est beaucoup plus facile d'inscrire votre travail dans le processus.

Malheureusement, très souvent, les clients sont opposés à Waterfall et demandent d'accélérer le développement du projet. Au nom de ce désir, des méthodologies plus souples voient le jour.

Agile

Comme vous le comprenez, Waterfall est très longue, formellement et implique des tonnes de documentation, sur laquelle tout le monde triche toujours . Et le client a besoin de tout à la fois. En réponse à ces problèmes, les programmeurs ont proposé un manifeste Agile:

● Les gens et l'interaction sont plus importants que les processus et les outils.
Il est difficile de contester cela. Bien sûr, les gens sont plus importants. Mais n'oubliez pas les processus. Ce sont les processus qui normalisent et régulent l'interaction. De plus, seulement en public vous n'irez pas loin. Au minimum, les gens aiment être malades, se détendre et parfois arrêter de fumer.

● Un produit fonctionnel est plus important qu'une documentation complète.
C'est également vrai. Mais il y a une autre question: dans quelle mesure et pendant combien de temps le produit fonctionnera-t-il sans documentation? Très probablement, pas très longtemps. Mais c'est bon ou pas - ça ne marchera pas faute de source. Et puis vous devrez suivre la tactique dont beaucoup sont tombés amoureux "Je ne pouvais pas le comprendre - réécrire à partir de zéro." Mais c'est toujours long, cher, et ce n'est généralement pas un fait que le résultat sera meilleur.

● La collaboration avec le client est plus importante que la négociation des termes du contrat.
Et encore une fois, oui, plus important. Mais comment, sans accord sur les termes du contrat, nous comprendrons quoi et comment faire? Sinon, comment surmonter un malentendu mutuel, sauf comment communiquer et convenir à travers un document clairement défini? Bien sûr, le contrat n'est pas non plus une panacée, mais il est beaucoup plus fiable que la méthode des années 90:

- Vasya, tu me comprends?
- Eh bien, comme oui, frère.

● La préparation au changement est plus importante que de suivre le plan d'origine.
Mais cela n'est vrai que dans un cas: si le plan initial était un journal complet et ce qu'ils prévoyaient de construire, il s'est avéré que personne n'avait besoin. Vous donnez un architecte d'entreprise dans toutes les mains!

Le résultat de suivre aveuglément ce manifeste est que le client d'entreprise lui-même doit se transformer en architecte d'entreprise (mais le plus souvent, il se transforme en citrouille). Non seulement ce n'est pas un "fonctionnel" qui lui est inhérent, mais il faut aussi comprendre l'informatique.

Scrum

Scrum est l'une des premières tentatives d'adapter Waterfall à l'idéologie du manifeste Agile.
Les principales caractéristiques de la mêlée:

• Travaillez par petits sprints. La composition du sprint après son démarrage n'est pas modifiée;
  
• Planification en mettant des User Stories individuelles dans le journal des souhaits de sprint. Sur le propriétaire du projet - un choix dans le "journal de projet";
  
• Les intérêts du client sont représentés par le maître d'ouvrage (Product Owner);
  
• L'équipe de développement est composée de spécialistes de différents profils: programmeurs, développeurs, architectes, analystes. L'équipe est responsable du résultat dans son ensemble;
  
• Nous remplaçons la documentation et la correspondance par des discussions quotidiennes du projet par toute l'équipe.
  

En théorie, c'est une approche assez robuste, et à bien des égards, elle ressemble à une version miniature de Waterfall. Des problèmes commencent à apparaître au stade de la mise en œuvre. Malheureusement, SCRUM, en raison de son cycle plus court, provoque la décomposition de la fonction entière en pièces séparées et la livraison de la fonction en plusieurs parties, même au stade de la planification du sprint. Je suis silencieux sur le fait que pour cette raison tout peut déjà mal tourner pendant la "course". Les sprints courts ne laissent pas de temps au stock managérial et il devient extrêmement difficile d'en sortir.

En raison de la remise en priorité constante d'une fonctionnalité dans sa forme finale, elle peut très rapidement entrer dans le productif. De plus, au stade de l'écriture de UserStory, il est extrêmement difficile d'évaluer l'impact de la fonctionnalité prévue sur le système final, car son état n'est pas connu à l'avance au moment où cette fonctionnalité apparaît.

Comment cela menace-t-il l'exploitation? Il n'est pas toujours clair ce qui devrait fonctionner, ce qui ne devrait pas l'être et si cela fonctionne, alors quand. En conséquence, il existe une substitution des tests du système aux tests de fonction, car la régression normale prendra beaucoup de temps. Cela ajoute des bogues au produit et retarde leur solution.

Pour un fonctionnement normal, le fonctionnement doit:

• Participer aux réunions SCRUM;
  
• Constamment conscient des situations de travail du développement;
  
• Connaître les plans de développement et les statuts de publication.
  

Sinon, il sera impossible de gagner du temps avec l'acceptation ou de faire des commentaires. Bien sûr, l'exploitation est extrêmement rare pour suivre tous ces points, et si c'est le cas, elle conduit à une escalade du conflit. Même un propriétaire de produit lors d'une réunion SCRUM peut à court terme ignorer les intérêts du support.

Kanban

La prochaine étape dans l'évolution des méthodologies de développement est Kanban. Les cycles SCRUM déjà courts semblaient également trop longs pour l'entreprise. Vous pouvez comprendre le client: vous voulez toujours être le premier à obtenir la puce la plus cool. Oui, et changer de plan est inefficace, cela se révèle un peu trop "aérien".
Ainsi, comme le disent les constructeurs, il est plus facile de "sculpter sur place".

Kanban est une implémentation informatique de la méthodologie japonaise de lean manufacturing. Mais il y a une nuance: chez Toyota, à l'aide de Kanban, les voitures sont assemblées à partir de pièces préfabriquées, tandis que le développement est principalement conçu. En programmation, les fonctions partielles sont simplement copiées, elles n'ont pas besoin d'être constamment «produites».

Kanban va généralement de pair avec les processus CI / CD. Il n'y a pas de sprints ici, les tâches sont livrées en continu car elles sont prêtes, il y a des restrictions strictes sur la taille de ces tâches. Pour cette raison, une fonctionnalité complexe sous une forme intégrale n'est presque jamais fournie, car elle ne correspond pas à la taille de la tâche.

Dans de telles conditions, la documentation du système devient vraiment obsolète avant d'être écrite et perd tout sens, car il est impossible de fixer un état du système produit (à savoir produit, mais non développé) dans lequel il serait vrai.

Pour le fonctionnement, cela signifie l'impossibilité de fournir un SLA: il n'y a pas de documentation, et personne ne sait comment le système fonctionne et comment il devrait fonctionner.

La prévisibilité et l'assurance d'un fonctionnement continu sont le fondement de la mise en œuvre du SLA.

Cependant, avec cette approche, il n'y a généralement pas de service d'exploitation, seulement une équipe de développement qui est périodiquement distraite par les réparations et (parfois) par la «dette technique». Mais personne n'est inquiet à cause de cela, car les plans ne se cassent pas. Il est difficile de perturber ce qui ne l'est pas.

Comme indiqué par les auteurs du processus original, Kanban est idéal pour les opérations dans lesquelles la planification est remplacée par une réponse aux stimuli. Par exemple, voici à quoi ressemble le travail avec les incidents - s'il se casse, nous le corrigerons. Dans la plupart des cas, par une procédure connue. Cependant, Kanban est totalement inadapté au développement, car il implique mal le résultat final. Le choix de cette méthodologie vous condamnera à un processus sans fin - «nous avons construit, construit et construisons toujours». Ne fais pas ça!

Devops

Bien sûr, DevOps n'est pas une méthodologie de développement en tant que telle, mais je ne peux m'empêcher d'insérer mes 5 kopecks et de ne pas parler de la tentative la plus courante de résoudre un conflit de fonctionnement et de développement.

En théorie, DevOps est un ensemble de pratiques visant l'interaction active des spécialistes du développement avec les spécialistes des technologies de l'information et l'intégration mutuelle de leurs processus de travail.

DevOps est basé sur l'idée d'une étroite interdépendance du développement et de l'exploitation des logiciels et vise à aider les organisations à créer et à mettre à jour rapidement des produits et services logiciels. Encore une fois sur la création et la mise à jour rapides. Mais exploiter ces problèmes n'existe pas du tout.

En conséquence, DevOps devient un moyen de rendre l'équipe de développement indépendante du service d'exploitation en complétant le lien de développement nécessaire. De toute évidence, cette solution en soi est unilatérale et ne résout le problème que pour une seule des parties - le développement. Souvent, cela ne fait qu'exacerber le conflit, permettant au développement d'ignorer complètement l'opération de service.

En pratique, je rencontre le plus souvent deux implémentations:

• L'équipe des administrateurs des opérations est maintenue et engagée dans la productivité.
  

Les administrateurs d'automatisation apparaissent dans l'équipe de développement pour résoudre les problèmes des développeurs au lieu de l'équipe d'exploitation. Je pense qu'il est évident qu'à la suite de leurs décisions, fouettées dans des environnements de test, je ne veux pas laisser le productif, et le conflit ne fait que grandir.

• Même chose, mais l'équipe d'exploitation est abolie dans l'esprit du principe «pas d'homme - pas de problème».
  

Les tâches de gestion de la disponibilité des services sont laissées pour compte. Les gens motivés par leur décision ne restent pas du tout. Périodiquement, une équipe d'ingénieurs DevOps apparaît, mais cela ne change rien, car la priorité de leur direction est la date de sortie de la version. Toutes les autres tâches peuvent être poussées tant que personne ne le voit.

, DevOps — , , , , , . . , SLA . () .

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

?

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

DevOps — , . , , .

. !