ChatOps : humaniser sans humains

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

Bientôt sur un réseau près de chez vous. Une initiative de l’autre économie des API.

Ces derniers temps, la communauté DevOps accorde davantage d’importance à la culture. Cela tient probablement au fait que, sans une évolution culturelle vers un environnement informatique plus ouvert et collaboratif, décloisonné entre les différentes équipes, bon nombre des avantages du DevOps ne peuvent pas être pleinement concrétisés. Le partage restreint des informations selon le principe du « besoin d’en connaître » engendre ces silos qui se dressent tels des tours défensives, protégeant les connaissances propres à chacun des domaines opérationnels qui composent ce que nous appelons affectueusement « l’informatique ».

Mais décloisonner ces silos peut être douloureux. Et gênant. Et extrêmement difficile. Nous pouvons plaisanter sur le caractère « antisocial » de presque tous les professionnels de l’informatique et tourner ces caricatures en dérision, mais la réalité est que, comme la plupart des légendes et des contes de fées, ces archétypes sont nés de comportements et de traits bien réels qui caractérisent encore de nombreuses personnes dans ce domaine.

Je suis INTJ selon le test Myers-Briggs. À chaque fois. Oui, « l’Architecte ». Je suis un Observateur réformateur sur le spectre Insights, qui n’est en réalité qu’un test jungien hyper-idéalisé prétendant être plus précis que le Myers-Briggs. Quoi qu’il en soit, je suis plutôt introverti. Aujourd’hui, les chercheurs estiment que près de 50 % de la population est introvertie. Et je suis sûr que vous ne serez pas surpris d’apprendre que beaucoup d’entre eux se sont orientés vers l’informatique, comme moi, tandis que nos incompréhensibles homologues extravertis se sont dirigés vers des postes dans le marketing et le management.

Les introvertis ne sont pas très portés sur la sociabilisation — c’est ainsi que les jeunes appellent aujourd’hui le fait d’interagir avec les autres. Ce n’est pas vous, vraiment, c’est nous. Nous traitons simplement les informations et les données différemment des extravertis, et trop d’interactions directes nous submergent. Nous savons sociabiliser, mais c’est épuisant. Nous préférons communiquer par écrit et avoir le temps de réfléchir avant de répondre. C’est pourquoi nous nous en sortons plutôt bien à l’ère numérique, où une grande partie de nos échanges se fait justement à distance et par écrit. Vous pourriez même nous prendre pour des extravertis si vous ne nous connaissez que sous notre forme numérique.

Si l’on considère le principe du changement culturel qu’exige le DevOps, on constate immédiatement un conflit. Le partage et la communication sont deux composantes essentielles du DevOps, ce qui implique d’amener tout un groupe d’introvertis non seulement à interagir avec les autres, mais aussi à le faire efficacement. Trouver un moyen d’« interagir sans avoir à sociabiliser » revient donc à chercher le trésor au pied de l’arc-en-ciel.

Il s’avère que ChatOps pourrait bien être ce fameux trésor.

ChatOps : créer du lien sans personne

Alors, qu’est-ce que le ChatOps ? Jason Hand, l’un des plus grands experts du ChatOps, nous en donne une définition concise: « Considérez le ChatOps comme une ligne de commande partagée. »

Bien sûr, le ChatOps ne se résume pas à cela, mais cette définition constitue un excellent point de départ pour en comprendre les principes fondamentaux.

Des outils comme HipChat et Slack ne sont pas conçus pour les échanges individuels, contrairement aux anciens systèmes de messagerie instantanée. C’est possible, mais la véritable force de ces plateformes de communication modernes réside dans leur capacité à créer un environnement de communication ouvert, où les informations et les actualités sont partagées instantanément avec toutes les personnes de l’organisation qui s’y intéressent. La consultation passive est encouragée, car ce qui compte, c’est la disponibilité et l’accessibilité des informations, et non la continuité des échanges.

Les canaux (comme #IRC) permettent de maîtriser le rapport signal/bruit et offrent souvent une piste d’audit claire indiquant qui a fait quoi et quand. Ces outils y parviennent en étant bien plus que de simples clients de messagerie instantanée. Ce sont des plateformes dont les fonctionnalités peuvent être étendues via des API afin d’assurer une communication bidirectionnelle non seulement avec des personnes, mais aussi avec des systèmes. Je peux ainsi ajouter un canal #alerts vers lequel acheminer, justement, les alertes provenant des composants de l’infrastructure.

Vous pouvez – assez facilement, dois-je ajouter – créer une « application » pour Slack qui interroge ses API et renvoie des informations. Il peut s’agir de votre commutateur, de votre répartiteur de charge ou de la météo locale. Quoi qu’il en soit, vous pouvez lancer, depuis ces outils, des commandes qui exécutent automatiquement des tâches. Et vous pouvez partager la commande – ainsi que ses résultats – avec toutes les personnes qui doivent être informées ou auxquelles ces informations pourraient être utiles. Les tâches sont ainsi documentées par vos actions et laissent une trace permettant aux autres de comprendre ce qui se passe. Mises à jour d’état provenant des systèmes de supervision, nouveaux tickets du service d’assistance, notification indiquant qu’un serveur vient de tomber en panne et n’est plus disponible : pratiquement tout ce qui peut être communiqué via une API peut être partagé avec d’autres personnes – sans vraiment avoir à interagir avec elles.

Ce processus ouvre une multitude de possibilités en matière de mentorat et de formation, tout en permettant de décloisonner les connaissances informelles au profit d’autres domaines de l’informatique, notamment le développement. Il s’agit d’un partage à grande échelle, sans avoir à entasser des personnes dans des salles ni à organiser des sessions de formation pour de jeunes ingénieurs enthousiastes. C’est également l’un des rares outils qui permettent d’opérer le changement culturel nécessaire à l’adoption réussie d’une approche DevOps au sein du « réseau ».

Et nous devons l’adopter. Si vous avez encore des réserves, réfléchissez à cette question posée par Atlassian et xMatters dans leur enquête 2017 sur la maturité DevOps :

Les auteurs ont leurs propres hypothèses, fondées sur leurs données, mais j’en ai une autre, qui repose en grande partie sur le sophisme de composition, qui nous rappelle que l’application mise à disposition pour être déployée n’est pas la même que celle qui se trouve en production : l’ajout de services applicatifs et l’interaction avec le réseau en modifient la composition. L’évaluation de cette application, à moins d’être effectuée dans une réplique exacte de l’environnement de production, n’est donc plus entièrement valable.

Pire encore, dans près d’un tiers des entreprises, ces problèmes ne sont découverts que lorsque les clients les informent d’interruptions de service. Cela peut être dû à la manière dont les informations sont partagées entre les équipes de développement et l’informatique. Vingt-neuf pour cent indiquent que les informations sont partagées entre les équipes lorsqu’elles en font expressément la demande. Seules 16,8 % rendent les informations « accessibles à tous, notamment les informations techniques, les objectifs, les plans et les résultats ».

Sans les informations propres au comportement d’une application en production, il est souvent difficile de déterminer la nature du problème, et encore moins son origine. « Ça marche sur ma machine » est un mantra défensif né de la frustration des développeurs qui ne parviennent pas à reproduire un dysfonctionnement, lequel découle le plus souvent d’un manque d’informations sur l’environnement.

Même si nous ne sommes pas particulièrement enthousiastes à l’idée de commencer à tout automatiser sur le réseau, ChatOps est un bon moyen d’ouvrir les voies de communication entre les équipes informatiques et de développement, et de mieux comprendre les problèmes afin de réduire le MTTR (temps moyen de résolution). Il permet d’avoir une vue plus complète de ce qui se passe « sur le réseau », sans être intrusif ni surveiller les ingénieurs dans les moindres détails. Il offre à vos collaborateurs introvertis un moyen d’interagir sans avoir à sociabiliser, ce qui les encourage à communiquer plus souvent, de manière plus approfondie et, peut-être même, avec enthousiasme.

Si vous découvrez ChatOps, je vous recommande vivement de lire l’e-book de Jason Hand, « ChatOps pour les Nuls ». Vous devrez fournir votre adresse e-mail, mais cela en vaut la peine.

Et restez à l’écoute. Nous reparlerons de ChatOps à l’avenir, je peux vous le garantir.

À propos de l’auteur

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.

Autres articles de Lori Mac Vittie