Les lettres à l’éditeur sont une question pratique : elles nous permettent, dans la communauté des écrivains, de rester en contact avec le lectorat et de développer une idée de ce qui pourrait être intéressant » là-bas » en termes de sélection de sujets. Parfois, les lettres à l’éditeur provoquent également une véritable horreur. Récemment, par exemple, j’ai reçu un e-mail de colère en réponse à un article qui décrit les bases essentielles d’une architecture de sécurité Zero Trust : Avec les innovations hipster constantes, ça doit être bon à un moment donné, donc la teneur, on a utilisé pour l’avoir après tout, rien de tout cela n’est nécessaire.
D’autres e-mails reçoivent le même message, mais d’un point de vue différent : quelle entreprise, si oui, dans laquelle le login en tant que racine est désactivé sur les serveurs, un lecteur a récemment voulu le savoir car il souhaiterait y postuler. Ceux qui pensent qu’il s’agit de cas isolés se trompent : les journalistes reçoivent régulièrement des e-mails de ce type.
Martin Gerhard Loschwitz est journaliste indépendant et travaille régulièrement sur des sujets tels que OpenStack, Kubernetes et Ceph.
Ils sont l’expression d’un problème structurel profondément enraciné dans notre industrie : vis-à-vis du monde extérieur, toutes les entreprises n’exploitent naturellement que les services les plus récents et les technologies les plus récentes. Agilité, fonctionnement irréprochable, automatisation totale – bien sûr, on ne peut plus s’en passer de nos jours ! Et les conteneurs, Kubernetes et Cloud Ready sont autant d’obstacles, ce serait risible !
Cependant, si vous regardez de plus près, la belle image commence bientôt à se fissurer : Agilité ? Un groupe de travail étudie actuellement comment cela peut être mis en œuvre dans l’entreprise. Automatisation? Oui, bien sûr, une preuve de concept est en cours de finalisation. Et le serveur là-bas dans le rack ? Une Debian GNU/Linux 5 avec la boutique en ligne d’un client qui a finalement cessé de payer pour les mises à jour. Depuis lors, il n’a reçu qu’une assistance de base – mais on ne sait pas avec certitude si quelqu’un doit modifier la boîte de temps en temps pour la faire fonctionner, car aucun enregistrement détaillé n’est conservé à ce sujet.
La technologie moderne n’est pas l’étoffe du diable
En réalité, de nombreuses entreprises ont encore aujourd’hui des concepts d’exploitation et des approches qui rappellent davantage le début des années 2000 que l’informatique contemporaine et ses outils. On ne manque pratiquement jamais de justifications et d’excuses : on n’a tout simplement pas le temps de réduire la dette technique tant elle est complexe à exploiter. Dans les petites et moyennes entreprises en particulier, on entend régulièrement dire que l’automatisation ne vaut pas la peine. Parce que votre propre parc de serveurs est petit et clair et que vous n’effectuez la plupart des étapes de travail qu’une seule fois. Des architectures de sécurité modernes ? Le patchwork actuel a enfin fait ses preuves dans le passé ! Et les concepts agiles pour le développement de logiciels, c’est bien beau, mais malheureusement ils ne correspondent pas du tout à la structure organisationnelle de l’entreprise.
Tous ces arguments ont en commun d’être généralement faciles à réfuter. Sans aucun doute, remplacer la dette technique existante par des solutions modernes et efficaces est fastidieux ; mais personne ne remettrait sérieusement en question l’utilité ici, comme c’est souvent le cas dans de nombreux endroits. Quiconque doit constamment attraper des poulets en fuite aura tôt ou tard l’idée d’essayer une clôture. Le fait que vous ne remplissiez qu’une seule tâche dans votre travail une seule fois dans votre vie et que l’automatisation n’en vaut donc pas la peine s’avère également un non-sens à plusieurs niveaux. D’une part, la plupart des administrateurs savent de par leur propre expérience que certaines tâches reviendront tôt ou tard. Et généralement au moment le plus inopportun.
D’un autre côté, le travail peut désormais être automatisé si rapidement et facilement avec Ansible, par exemple, sans beaucoup de connaissances préalables, que cela peut difficilement être qualifié d’effort sérieux. Le problème mentionné au début avec la connexion en tant que racine via SSH, en déployant la clé SSH appropriée en combinaison avec l’entrée appropriée dans /etc/ssh/sshd_config rompre. Le playbook Ansible requis pour cela ne fait que quelques lignes et peut être trouvé complètement prêt sur le Web. Même pour les serveurs individuels, l’effort impliqué dans l’automatisation d’une tâche devrait avoir un bon sens commercial dans la plupart des cas. D’autant plus que tous les avantages bien connus de l’automatisation, tels que la réduction des erreurs humaines dans les situations de stress et un temps de récupération très court en cas de sinistre, n’ont pas encore été pris en compte.
