Lorsque vous introduisez un nouvel outil, un nouveau langage de programmation ou une nouvelle dépendance dans votre environnement, quelles étapes suivez-vous pour l'évaluer ? Dans cet article, je vais parcourir un cadre en six questions que j'utilise pour prendre ces décisions.
Quel problème est-ce que j'essaie de résoudre ?
Nous sommes tous pris dans les détails du problème immédiat à résoudre. Une évaluation honnête et critique aide à divulguer des causes profondes plus larges et empêche les micro-optimisations.
[ Vous pourriez également aimer : Six étapes de déploiement pour les services Linux et leurs outils associés ]
Supposons que vous rencontriez des problèmes avec votre système de gestion de configuration. Les tâches opérationnelles quotidiennes prennent plus de temps qu'elles ne le devraient et il est difficile de travailler avec la langue. Un nouveau système de gestion de la configuration pourrait atténuer ces inquiétudes, mais assurez-vous de jeter un regard plus large sur le contexte de ce système. Peut-être que le passage de machines virtuelles à des conteneurs immuables atténue ces problèmes et bien plus encore dans votre environnement tout en représentant une quantité de travail équivalente. À ce stade, vous devriez également explorer la faisabilité de solutions plus complètes. Vous pouvez décider qu'il ne s'agit pas d'un projet réalisable pour l'organisation pour le moment en raison d'un manque de connaissances organisationnelles sur les conteneurs, mais accepter consciencieusement ce compromis vous permet de mettre les conteneurs sur une feuille de route pour le prochain trimestre.
Cet exercice intellectuel vous aide à explorer les causes profondes et à résoudre les problèmes fondamentaux, et non les symptômes de problèmes plus importants. Ce ne sera pas toujours possible, mais soyez intentionnel lorsque vous prenez cette décision.
Cet outil résout-il ce problème ?
Maintenant que nous avons identifié le problème, il est temps de procéder à une évaluation critique de nous-mêmes et de l'outil sélectionné.
Une technologie particulière peut sembler attrayante parce qu'elle est nouvelle parce que vous lisez un article de blog intéressant à ce sujet ou vous voulez être celui qui donne une conférence. Les cloches et les sifflets peuvent être agréables, mais l'outil doit résoudre les principaux problèmes que vous avez identifiés dans la première question.
Qu'est-ce que j'abandonne ?
L'outil résoudra en fait le problème, et nous savons que nous résolvons le bon problème, mais quels sont les compromis ?
Ces considérations peuvent être purement techniques. Le manque d'outils d'observabilité empêchera-t-il un débogage efficace en production ? La nature fermée de cet outil rend-elle plus difficile la recherche de bogues subtils ? La gestion d'une autre dépendance vaut-elle les avantages opérationnels de l'utilisation de cet outil ?
De plus, incluez les contextes organisationnels, commerciaux et juridiques plus larges dans lesquels vous opérez.
Cédez-vous le contrôle d'un flux de travail d'entreprise critique à un fournisseur tiers ? Si ce fournisseur double le coût de son API, est-ce quelque chose que votre organisation peut se permettre et est prête à accepter ? Êtes-vous à l'aise avec les outils à source fermée qui gèrent une partie sensible des informations exclusives ? Les licences logicielles rendent-elles cela difficile à utiliser commercialement ?
Bien qu'il ne s'agisse pas de questions simples à répondre, prendre le temps d'évaluer cela dès le départ vous évitera beaucoup de douleur plus tard.
Le projet ou le fournisseur est-il sain ?
Cette question est accompagnée de l'addendum "pour le reste de vos besoins". Si vous n'avez besoin que d'un outil pour amener votre équipe sur une période de quatre à six mois jusqu'au Projet X est terminée, cette question devient moins importante. S'il s'agit d'un engagement pluriannuel et que l'outil gère un flux de travail métier critique, cela pose problème.
Lors de cette étape, utilisez toutes les ressources disponibles. Si la solution est open source, parcourez l'historique des commits, les listes de diffusion et les discussions du forum à propos de ce logiciel. La communauté semble-t-elle communiquer efficacement et bien travailler ensemble, ou y a-t-il des divisions évidentes entre les membres de la communauté ? Si une partie de ce que vous achetez est un contrat de support, utilisez ce support pendant la phase de preuve de concept. Est-il à la hauteur de vos attentes ? La qualité de l'assistance en vaut-elle le coût ?
Assurez-vous de faire un pas au-delà des étoiles et des fourches GitHub lors de l'évaluation des outils open source également. Quelque chose pourrait apparaître sur la première page d'un agrégateur de nouvelles et attirer l'attention pendant quelques jours, mais un examen plus approfondi pourrait révéler que seuls quelques développeurs principaux travaillent réellement sur un projet et qu'ils ont eu du mal à trouver des contributions extérieures. Peut-être qu'un outil est open source, mais une équipe financée par l'entreprise dirige le développement de base, et le support cessera probablement si cette organisation abandonne le projet. Peut-être que l'API a changé tous les six mois, causant beaucoup de douleur aux personnes qui ont adopté des versions antérieures.
Quels sont les risques ?
En tant que technologue, vous comprenez que rien ne se passe jamais comme prévu. Les réseaux tombent en panne, les disques tombent en panne, les serveurs redémarrent, les lignes du centre de données perdent leur alimentation, des régions AWS entières deviennent inaccessibles ou les détournements BGP redirigent des centaines de téraoctets de trafic Internet.
Demandez-vous comment cet outil pourrait échouer et quel en serait l'impact. Si vous ajoutez un produit de fournisseur de sécurité à votre pipeline CI/CD, que se passe-t-il si le fournisseur tombe en panne ?
Cela soulève à la fois des considérations techniques et commerciales. Les pipelines CI/CD expirent-ils simplement parce qu'ils ne peuvent pas atteindre le fournisseur, ou l'ont-ils "échoué" et permettent-ils au pipeline de se terminer avec un avertissement ? Il s'agit d'un problème technique, mais finalement d'une décision commerciale. Êtes-vous prêt à passer en production avec une modification qui a contourné l'analyse de sécurité dans ce scénario ?
Évidemment, cette tâche devient plus difficile à mesure que l'on augmente la complexité du système. Heureusement, des sites comme k8s.af regroupent des exemples de scénarios de panne. Ces post-mortem publics sont très utiles pour comprendre comment un logiciel peut échouer et comment planifier ce scénario.
Quels sont les coûts ?
Les principales considérations ici sont le temps des employés et, le cas échéant, le coût du fournisseur. Cette application SaaS est-elle moins chère que plus d'effectifs ? Si vous économisez deux heures par jour à chaque développeur de l'équipe avec ce nouvel outil CI/CD, est-il rentabilisé au cours du prochain exercice ?
Certes, tout ne doit pas nécessairement être une proposition de réduction des coûts. Peut-être que cela ne sera pas neutre en termes de coûts si vous faites gagner quelques heures par jour à l'équipe de développement, mais vous supprimez un énorme obstacle dans leur flux de travail quotidien, et ils en seraient beaucoup plus heureux. Ce bonheur vaut probablement le coût financier. L'intégration de nouveaux développeurs est coûteuse, alors ne sous-estimez pas la valeur d'une rétention accrue lors de ces calculs.
[ Un guide gratuit de Red Hat :5 étapes pour automatiser votre entreprise. ]
Récapitulez
J'espère que vous avez trouvé ce cadre perspicace et je vous encourage à l'intégrer à vos propres processus décisionnels. Il n'y a pas de cadre unique qui fonctionne pour chaque décision. N'oubliez pas que, parfois, vous devrez peut-être suivre votre instinct et porter un jugement. Cependant, avoir un processus standardisé comme celui-ci aidera à différencier les moments où vous pouvez analyser une décision de manière critique et ceux où vous devez faire ce saut.