Traitez également votre code d’automatisation informatique comme du bétail.
L’informatique doit adopter la standardisation du code qui la fait fonctionner, sinon elle risque de créer des systèmes qui siphonnent les avantages financiers et d’efficacité de l’automatisation informatique.
J'ai passé près d'une décennie à développer des logiciels. Logiciel embarqué. Logiciel Web. Logiciel client-serveur. Logiciels middleware et mainframe. J’ai écrit du code de manière professionnelle dans neuf langages différents. Ce qui est intéressant, c’est que je ne me souviens pas d’avoir utilisé plus de deux langues dans la même organisation.
La plupart des entreprises standardisent non seulement les serveurs, les plateformes et les frameworks, mais également les langages. Il existe un objectif de maintenabilité pour les logiciels dont la durée de vie dépasse quelques minutes et se compte parfois en décennies. La maintenabilité est la caractéristique d'un logiciel qui lui permet d'être repris par quelqu'un d'autre et pris en charge tout au long de son cycle de vie, quelle que soit la manière dont cette durée de vie peut être mesurée. Cela est souvent dû au taux de rotation des développeurs et à la disponibilité sur le marché des compétences linguistiques ainsi qu’aux coûts de formation et de maintenance générale. En règle générale, les entreprises standardisent les langages de programmation.
C’est un anathème pour les tendances actuelles en matière de microservices et d’informatique sans serveur qui vantent comme un avantage leur capacité à prendre en charge un ensemble de langues très diversifié (polyglotte). Bob et son équipe peuvent écrire en Go tandis qu'Alice et son équipe développent en C, Java ou Lambda. Bien que cela soit certainement un avantage pour les développeurs (qui ont tous leur langage favori), ce n’est pas si bon pour les entreprises qui doivent maintenir ce logiciel au fil du temps. Les API permettent son intégration et son utilisation, rendant son langage d'implémentation largement inutile en termes de développement d'applications, mais dans une entreprise, le code sous-jacent doit toujours être maintenu.
En matière d’automatisation informatique (la transformation numérique interne qui se produit du côté de la production de l’entreprise), il est important pour les organisations de reconnaître non seulement les avantages de la standardisation des scripts et des systèmes créés pour la prendre en charge, mais également les pièges de ne pas le faire. Parce que vous ne construisez pas ces systèmes avec l’intention de les jeter la semaine prochaine, le mois prochain ou même l’année prochaine. Il s’agit d’un investissement à plus long terme qui soutiendra la numérisation du déploiement pour les années à venir. Cela signifie poser des bases flexibles mais solides qui s’appuient sur les meilleures pratiques apprises au fil des décennies par les développeurs d’applications dans les entreprises du monde entier, la première d’entre elles étant la normalisation.
1. Maintenabilité
Je sais que vous aimez écrire en PERL mais tout le monde utilise Python. Développer l'automatisation dans votre langage préféré en fait votre animal de compagnie, ce qui signifie que personne d'autre ne pourra la maintenir à l'avenir. C'est mauvais pour toi, parce que tu resteras coincé avec cette chose pendant des années, tout comme le poisson rouge que tu as supplié tes parents quand tu avais huit ans. C'est mauvais pour l'organisation car si vous déménagez, elle se retrouve coincée avec du code qu'elle ne peut pas maintenir et qu'elle pourrait avoir du mal à prendre en charge. Une enquête menée en 2016 par SIG et O'Reilly a révélé que « 70 % des personnes interrogées estiment que la maintenabilité est l'aspect le plus important du code à mesurer, même par rapport aux performances ou à la sécurité ».
C’est aussi important que ça. Considérez les scripts et les systèmes comme des ressources partagées qui peuvent être facilement modifiées et prises en charge par la majorité des professionnels de l’informatique, aujourd’hui et à l’avenir.
2. Compatibilité
À mesure que de plus en plus de services informatiques sont mis en œuvre sous forme de logiciels, la tâche consistant à les maintenir à jour et compatibles avec d'autres systèmes augmente. Si vous pensez que les API REST éliminent le problème de « compatibilité descendante », détrompez-vous. Les API sont des produits (ou devraient l'être) et sont donc également en constante évolution. Et c'est pire dans « le réseau » où les différences existent même au sein d'une même gamme de produits, avec des différences d'API d'une version à l'autre qui font de la standardisation une tâche de Sisyphe. Il s'agit d'un problème tellement répandu que la normalisation des API est arrivée en troisième position dans la liste des défis technologiques à résoudre dans les années à venir, selon un répondant sur quatre au rapport State of API 2016 de Smart Bear .
Et comme la plupart des langages que nous utilisons en informatique sont interprétés, les changements d’une version à l’autre peuvent détruire des scripts et des systèmes d’automatisation soigneusement conçus. Les changements d’une version de node.js à une autre peuvent avoir un impact profondément négatif, allant de la rupture d’un script à un comportement inattendu. La standardisation des versions stables des environnements et des langages de script contribuera à minimiser l’impact de ces changements.
Et vous devrez toujours gérer les correctifs et les mises à niveau pour chaque système sous-jacent alimentant cette automatisation, donc moins il y en a, mieux c'est.
3. Dépannage
Jeter la normalisation par la fenêtre signifie des problèmes de dépannage. Ceci est particulièrement important si vous passez à une mesure basée sur le temps de résolution pour les KPI informatiques . Plus il faut de temps pour trouver le problème, plus la mesure paraît mauvaise. La normalisation est un élément important pour réduire le délai de résolution. Si Bob est le seul expert Python de l'équipe et qu'il est en vacances (et injoignable) et que son script tombe en panne, celui qui est chargé du dépannage va passer une longue semaine. Lorsque vous encouragez le service informatique à utiliser son langage familier, vous limitez considérablement la capacité des autres à dépanner et à résoudre les problèmes. Même si Bob n'est pas en vacances et qu'il n'arrive pas à trouver le problème, rares sont ceux qui peuvent l'aider.
Ce n’est pas un domaine avec lequel il faut s’attaquer. Selon InitialState , il faut 30 fois plus de temps pour corriger un bug que pour écrire une ligne de code. Vous pouvez visualiser l'argent alimentant lentement le destructeur pendant que vous vous efforcez de trouver un bug dans un code que vous ne connaissez pas, puis de le corriger. Ce n'est pas une belle image. Vous ne pouvez pas éliminer le coût du dépannage, mais vous pouvez le limiter en éliminant le temps supplémentaire requis par quelqu'un qui ne connaît pas la langue en premier lieu. En production, le temps c'est de l'argent, donc tout ce que vous pouvez faire pour réduire le temps de résolution est énorme.
C'est pourquoi, à mesure que l'informatique adopte progressivement les langages de script, les outils et les systèmes, ce n'est pas une mauvaise idée de se synchroniser avec le développement d'applications. Si l'informatique se standardise sur les mêmes systèmes et langages (ou au moins sur certains d'entre eux), vous gagnez une légion d'experts capables d'aider au dépannage et à d'autres processus liés au développement, comme les révisions de code. Parce que vous implémentez des revues de code comme moyen de trouver les bugs avant qu’ils ne causent des problèmes, n’est-ce pas ? Droite?
La normalisation est citée comme un moyen de lutter contre la hausse des coûts, et elle contribue certainement de manière essentielle à ces efforts. Mais la standardisation présente également de nombreux autres avantages, notamment la réduction de la dette technique, la réduction du temps de résolution et la simplification de la maintenance opérationnelle quotidienne. Ne pas standardiser du tout a certainement l’effet inverse sur les budgets et le temps en introduisant de la complexité et des goulots d’étranglement qui annulent les avantages de l’automatisation et empêchent les entreprises de réaliser les bénéfices et la productivité dont elles ont besoin pour se développer. Lorsque vous démarrez – ou poursuivez – votre parcours d’automatisation informatique, n’oubliez pas de traiter ces scripts et systèmes davantage comme du bétail et non comme des animaux de compagnie. Parce que les animaux de compagnie nécessitent une attention constante et personnelle que l’IT ne peut pas se permettre à l’avenir.