Ivan a travaillé dans une grande organisation dans un département lié à DevOps. Chaque jour, des milliers d'employés ont utilisé les outils DevOps pour créer, tester et implémenter leur logiciel.
Des milliers de distributions par jour qui ont transité par la chaîne de montage étaient une situation normale.
Cependant, là où il y a un grand pouvoir, il y a une grande responsabilité. Les difficultés inévitables des équipes ont entraîné des centaines d'appels de support technique par jour.
Naturellement, beaucoup n'aimaient pas les outils DevOps. Quelqu'un a dit qu'ils étaient trop bogués, tandis que d'autres pensaient que vous pouvez vous en passer du tout, et ce sera beaucoup plus rapide.
La direction de l'entreprise a compris que les 100% des équipes ne pouvaient pas être satisfaites de DevOps, cependant, il n'y avait pas de données exactes. Ce serait bien de voir les problèmes sur la chaîne de montage, mais même le nombre habituel de distributions le traversant par jour n'était pas connu. Que pouvons-nous dire des mesures sérieuses.
La question des mesures DevOps a été constamment soulevée - tout le monde en avait grandement besoin.
Ivan, en tant qu'employé connaissant les métriques et connaissant la technologie DevOps, a participé étroitement à la préparation du projet.
En collaboration avec les administrateurs DevOps, il a élaboré une architecture de solution possible et a également étudié une grande quantité de littérature sur les métriques DevOps. Il n'y avait pas un seul article sur Internet et pas un seul livre sur ce sujet qu'il ne lirait.
En conséquence, une solution technique complète est née, qu'Ivan a présentée à la direction.
Tout est parti
La réaction de la direction était inattendue - aucune décision sur la mise en œuvre n'a été prise.
"C'est un fiasco, mon frère", a dit le bon collègue avec un sourire, laissant Ivan de la réunion.
Malgré l'ironie, il avait raison. Si la décision n'est pas prise, alors il y avait une sorte de dissuasion qu'Ivan n'a pas vue et n'a pas prise en compte.
La direction était convaincue de la faisabilité technique de la mise en œuvre des métriques DevOps, mais en doutait toujours.
Et cela était dû à une raison très simple: la solution technique montrait que la mise en œuvre, bien que possible, nécessiterait un grand nombre de ressources humaines et techniques, c'est-à-dire sera cher. Mais s'il y aura un réel résultat utile à cela, c'est une grande question.
Lorsqu'il s'agit d'un projet coûteux, alors:
- Les présentations ne sont pas impressionnantes
- Les dispositions d'écran ne sont pas impressionnantes
- Les exemples ne sont pas impressionnants.
En général, le démarrage du projet a été reporté indéfiniment. La tâche semblait à Ivan totalement insoluble.
Cas fatidique
Tout a été décidé par hasard. Une fois, une lettre est arrivée au bureau de poste indiquant que deux étudiants avaient été emmenés au département pour un stage. L'un des étudiants était prêt à faire quelques petits travaux.
Ivan a pensé qu'il pourrait être possible de faire au moins quelque chose par des mesures - et a envoyé à l'étudiant une tâche technique pour une partie du projet qui a été réduite à l'impossibilité.
Tout ce qu'il y avait, c'était extraire les données de Jenkins et Nexus de la manière la plus simple possible.
Imaginez la surprise d’Ivan quand seulement quelques jours plus tard un étudiant l’a invité à regarder le système de travail. À la question «Comment ai-je gagné une priorité aussi élevée?» suivi de la réponse: "Vous n'aviez que des savoirs traditionnels."
Quoi qu'il en soit, mais le système a fonctionné. Elle a extrait les données de Jenkins et Nexus et les a mises dans sa propre base de données.
Ivan s'est rendu compte qu'il devait terminer le reste le plus rapidement possible. Il a utilisé la version gratuite de QlikView pour générer des rapports à partir de données brutes et le soir, la première version des métriques DevOps était prête.
Le lundi suivant a été une percée. En voyant les métriques de travail, le chef d'Ivan s'est exclamé: "Ce sont les données les plus utiles que j'ai vues récemment!"
Le problème des ressources a été résolu instantanément, et dans les prochains jours, le projet avec des mesures a été lancé à son maximum.
Ivan a agi correctement et sans se rendre compte qu'il a donné des «résultats rapides» - un système de travail avec la fonctionnalité la plus tronquée qui offre de réels avantages.
Les «résultats rapides» fonctionnent, car lorsqu'il s'agit d'un grand système coûteux, de nombreuses ambiguïtés se posent inévitablement. Avec un coût élevé important, le résultat n'est pas toujours évident.
Par conséquent, le début des travaux est constamment retardé ou le système est complètement abandonné.
Des résultats rapides permettent de tester l'hypothèse avec un minimum de moyens. L'essentiel est d'essayer de fabriquer un prototype sans attirer de ressources supplémentaires et de sorte qu'il soit porteur de valeur et d'avantages.
Quelques idées reçues par Ivan du projet:
Imaginez d'abord le résultat final dont vous avez besoin
Ivan savait exactement de quelles mesures il aurait besoin, jusqu'aux dispositions d'écran. Cela lui a permis d'éliminer rapidement les fonctionnalités inutiles et de ne laisser que ce sans quoi les métriques ont complètement perdu leur sens.
Sur les dix mesures DevOps proposées pour la mise en œuvre, Ivan n'en a laissé qu'une, et la limite à un stand et une équipe. En fait, c'était la compression la plus concentrée d'une part, et les données réelles pratiques de l'autre.
Une telle version allégée a permis de résoudre un problème tout à fait pratique: analyser la vraie équipe et comprendre si les métriques qui en résulteraient donneraient le résultat attendu.
Un schéma d'architecture simple facilite les choses
Le schéma de déploiement le plus simple avec des flux d'informations et des données a très bien aidé Ivan à comprendre où se trouve et comment il est plus facile de l'obtenir.
Jenkins: des emplois. Qu'est-ce qui est requis pour les mesures dans les travaux? Comment le retirer? Quels protocoles, à partir de quelles adresses?
Nexus: distributions. Qu'est-ce que Nexus requiert pour les mesures? Comment l'obtenir?
Systèmes d'aide: abandonner car ils ne sont pas nécessaires pour les mesures.
Comment combiner les données? Où est-il le plus facile de le faire le plus rapidement possible?
Si possible, faites sans codage. Tout à fait
Si vous pouvez le faire avec un téléchargement prêt à l'emploi sur XLS ou CSV, il est préférable de le faire et de ne pas encoder du tout.
Parfois, vous ne pouvez pas vous passer de codage, mais vous devez toujours choisir l'option la plus simple.
Par exemple, Jenkins alimente les données en RSS et JSON. Choisissez l'option la plus facile à mettre en œuvre.
Nexus ne renvoie que du XML? Eh bien, il n'y a rien à faire, vous devez coder.
N'accrochez pas trop. Nettoyez tout
Une super automatisation n'est pas nécessaire pour des résultats rapides. Vous pouvez le faire avec des codes de commande au lieu de leurs noms. Vous ne devez pas connecter des systèmes supplémentaires uniquement pour l'enrichissement des données. Ce ne sont que des fleurs et des conseils de beauté - il est préférable de s'en passer et de gagner du temps.
Au lieu d'écrire dans la base de données, vous pouvez écrire dans un fichier texte normal ou csv, si ce sera plus rapide.
Où vous pouvez commencer manuellement - commencez, ne perdez pas de temps sur le sheduler.
S'il est plus facile d'écrire dans un langage de script léger comme Python ou PHP, écrivez. Quoi qu'il en soit, vous faites le minimum, donc vous n'aurez pas à réécrire beaucoup.
Utilisez des outils qui vous permettent d'obtenir des résultats rapidement, par exemple, QlikView gratuit ou Tablue pour les mesures - ils facilitent le chargement et la combinaison des données, ainsi que la construction de tous les graphiques nécessaires.
Ivan a mis les «résultats rapides» en service et dans les projets suivants, il a toujours essayé de créer d'abord un système fonctionnant au minimum qui fournit de l'utilité, et ensuite seulement de prendre le reste. Et ça a toujours fonctionné.
Si l'histoire d'Ivan vous a semblé utile, j'en serai extrêmement heureuse.
Veuillez écrire dans les commentaires votre cas lorsque des résultats rapides auront eu un effet.