BLOG

Opérations de chat : Un peuplement sans peuple

Miniature de Lori MacVittie
Lori MacVittie
Publié le 4 mai 2017

Bientôt dans un réseau près de chez vous. Présenté par l' Autre Économie API .

Il y a eu récemment un changement dans la communauté DevOps qui se concentre davantage sur la culture. C’est probablement parce que sans changement culturel vers un environnement informatique inter-entreprise plus ouvert et collaboratif, de nombreux avantages de DevOps ne pourront pas être pleinement réalisés. Le partage fermé des informations « nécessaires à leur connaissance » conduit à ces silos qui se dressent comme des tours défensives enfermant les connaissances tribales propres à chacun des domaines opérationnels qui constituent ce que nous appelons affectueusement « l’informatique ».

Mais les décomposer peut être douloureux. Et gênant. Et extrêmement difficile. Bien que nous puissions plaisanter sur la nature « antisociale » de presque tous les employés du secteur informatique et nous moquer des caricatures, la réalité est que, comme la plupart des légendes et des contes de fées, ces archétypes sont issus de comportements et de caractéristiques réels qui caractérisent encore aujourd’hui de nombreuses personnes dans ce domaine.

 

les gens de la tasse

Je suis un INTJ sur le Meyers-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é qui prétend être plus précis que Meyers-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 cela ne vous surprendrait pas de découvrir que beaucoup d'entre eux se sont dirigés vers l'informatique comme moi, tandis que nos homologues extravertis et incompréhensibles ont accédé à des postes de marketing et de gestion.

Les introvertis n’aiment pas les contacts humains – c’est ainsi que les jeunes appellent interagir avec les gens, de nos jours. Ce n’est pas vraiment toi, c’est nous. Nous traitons simplement les informations et les données différemment des extravertis et trouvons trop d’interactions actives écrasantes. On peut le faire, mais c’est épuisant. Nous préférons le texte et le temps de réfléchir avant de répondre. C’est pourquoi nous nous en sortons plutôt bien à l’ère du numérique, où une grande partie de notre communication se fait uniquement à distance et par SMS. Vous pourriez même nous prendre pour des extravertis, si vous nous connaissez uniquement sous notre forme numérique.

Si vous considérez le principe du changement culturel requis avec DevOps, vous verrez immédiatement qu’il y a un conflit. Le partage et la communication sont tous deux des éléments essentiels de DevOps, et cela signifie essayer d'amener un groupe d'introvertis non seulement à être des personnes, mais aussi à être efficaces dans le domaine du peuplement. Cela signifie que trouver un moyen de « peupler sans peupler » revient à trouver le pot d’or au bout de l’arc-en-ciel.

Il s’avère que ChatOps pourrait bien être ce pot d’or.

Opérations de chat : Un peuplement sans peuple

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

C’est bien sûr plus que cela, mais dans sa forme la plus basique, c’est un excellent point de départ.

 

 

interface slack

Des outils comme HipChat et Slack ne sont pas conçus pour la communication 1:1, comme les anciens systèmes de messagerie instantanée. Vous pouvez le faire, mais le véritable pouvoir de ces plateformes de communication modernes est de permettre un environnement de communication ouvert où les informations et les mises à jour sont partagées instantanément avec toute personne de l'organisation intéressée. Il est recommandé de rester discret, car c'est la disponibilité et l'accessibilité de l'information qui sont importantes, et non une conversation continue.

Les canaux (comme #IRC) fournissent les moyens de contrôler le rapport signal/bruit, et souvent une piste d'audit claire de qui a fait quoi et quand. Ces outils y parviennent en étant plus que de simples clients de chat. Ce sont des plateformes, avec la possibilité d’étendre les fonctionnalités via des API pour fournir une communication bidirectionnelle non seulement avec les personnes, mais également avec les systèmes. Cela signifie que je peux ajouter un canal #alerts vers lequel je pourrais canaliser, eh bien, les alertes des composants de l'infrastructure.

Vous pouvez – relativement facilement, devrais-je ajouter – créer une « application » pour Slack qui interroge et renvoie des informations via leurs API. C’est peut-être votre commutateur, votre équilibreur de charge ou la météo locale. Quoi qu'il en soit, vous pouvez invoquer des commandes à partir de ces outils qui exécutent automatiquement des tâches. Et vous pouvez partager l’invocation – et les résultats – sans que tous ceux qui ont besoin de le savoir ou qui pourraient en bénéficier. Les tâches sont ensuite documentées en fonction de ce que vous avez fait et laissent une trace permettant aux autres de comprendre ce qui se passe. Mises à jour de statut des systèmes de surveillance, nouveaux tickets du service d'assistance, une note indiquant qu'un serveur vient de tomber en panne et n'est plus disponible. À peu près tout ce à quoi vous pouvez penser et qui peut être communiqué via une API peut être partagé avec d’autres personnes – sans vraiment les peupler.

Ce processus ouvre une multitude d’opportunités de mentorat, de formation et de libération des connaissances tribales qui profitent à d’autres domaines de l’informatique, y compris le développement. Il s’agit de partager à grande échelle, sans s’entasser dans des salles pleines de monde ou sans organiser d’exercices de formation pour les nouveaux ingénieurs aux yeux brillants. C’est également l’un des rares outils qui permettent le changement culturel nécessaire pour adopter avec succès une approche DevOps dans « le réseau ».

Comment l'information circule dans l'enquête Atlassian

Et nous devons l’adopter. Si vous êtes encore méfiant, considérez cette question posée par Atlassian et xMatters dans leur enquête DevOps Maturity Survey 2017 :

Si tant d’organisations surveillent les infrastructures, les applications et les services, pourquoi 50 % des répondants signalent-ils des problèmes de production après la publication du code ?

Les auteurs ont leurs propres hypothèses, basées sur leurs données, mais j’en ai une autre – basée en grande partie sur l’ erreur de composition qui nous rappelle que l’application publiée pour le déploiement n’est pas la même application en production . L’insertion de services d’application et l’interaction avec le réseau modifient la composition. La vérification de cette application, à moins qu’elle ne soit effectuée dans une réplique exacte de l’environnement de production, ne s’applique plus complètement.

Pire encore, pour près d’un tiers des entreprises, ces problèmes ne sont découverts que lorsque les clients les informent des interruptions de service. Cela peut être dû à la manière dont les informations sont partagées entre le développement et l’informatique. Vingt-neuf pour cent déclarent que les informations sont partagées entre les équipes lorsque cela est spécifiquement demandé. Seuls 16,8 % rendent l’information « ouverte à tous ceux qui fournissent des informations techniques, des objectifs, des plans et des résultats ». 

Sans les informations propres au comportement d’une application en production, il est souvent difficile de discerner quel est le problème, et encore moins sa source. « Cela fonctionne sur ma machine » est un mantra défensif né de la frustration des développeurs de ne pas pouvoir reproduire un mauvais comportement qui découle le plus souvent d’un manque d’informations environnementales.

Même si nous ne sommes pas encore prêts à automatiser tous les éléments du réseau , ChatOps est un bon moyen d'ouvrir les lignes de communication entre l'informatique et le développement et de fournir un meilleur aperçu des problèmes qui contribuent à un MTTR (temps moyen de résolution) plus rapide.  C'est un moyen de fournir une vue plus complète de ce qui se passe « dans le réseau » sans être envahissant ni microgérer les ingénieurs. Il offre à vos introvertis un moyen d'entrer en contact avec des gens sans peuplement, ce qui les encourage à partager plus fréquemment et plus en profondeur et, vous pourriez le constater, avec enthousiasme.

Si vous êtes nouveau dans ChatOps, je vous recommande vivement de lire le livre électronique de Jason Hand, « ChatOps pour les nuls ». Cela nécessite de renoncer à votre e-mail, mais cela en vaut la peine. 

Et restez à l’écoute ici. Il y aura plus d’informations sur ChatOps à l’avenir, je peux vous le garantir.