Operaciones de chat: Poblamiento sin pueblo

Próximamente en una red cerca de usted. Presentado por Other API Economy .

Últimamente ha habido un cambio en la comunidad DevOps hacia un enfoque más centrado en la cultura. Es probable que esto se deba a que, sin el cambio cultural hacia un entorno de TI más abierto y colaborativo, muchos de los beneficios de DevOps no se pueden aprovechar plenamente. El intercambio cerrado de información, basado en la “necesidad de saber”, conduce a silos que se erigen como torres defensivas que encierran el conocimiento tribal exclusivo de cada uno de los dominios operativos que conforman lo que cariñosamente llamamos “TI”.

Pero romper con ellas puede ser doloroso. Y torpe. Y extremadamente difícil. Si bien podemos hacer bromas sobre la naturaleza “antisocial” de casi todos los habitantes de TI y burlarnos de las caricaturas, la realidad es que, como la mayoría de las leyendas y los cuentos de hadas, esos arquetipos surgieron de comportamientos y características reales que todavía caracterizan a muchos en el campo.

Soy un INTJ en Meyers-Briggs. Cada vez. Sí, “El Arquitecto”. Soy un observador reformador en el espectro de Insights , que en realidad es simplemente una prueba junguiana hiperidealizada que afirma tener mayor precisión que Meyers-Briggs. De cualquier manera, soy bastante introvertida. Hoy en día, los investigadores estiman que casi el 50% de la población es introvertida. Y estoy seguro de que no les sorprendería saber que muchos de ellos se abrieron camino en el sector de TI, como lo hice yo, mientras que nuestros incomprensibles homólogos extrovertidos saltaron a puestos de marketing y gestión.

A los introvertidos no les gusta relacionarse con la gente (que es lo que los jóvenes llaman hoy en día a interactuar con la gente). En realidad no eres tú, somos nosotros. Simplemente procesamos la información y los datos de manera diferente a los extrovertidos y encontramos demasiada interacción activa abrumadora. Podemos, gente, pero es agotador. Preferimos texto y tiempo para pensar antes de responder. Es por eso que realmente nos va bastante bien en la era digital, donde gran parte de nuestra comunicación es precisamente eso: a distancia y mediante mensajes de texto. Incluso podrías confundirnos con extrovertidos si sólo nos conoces en nuestra forma digital.

Si consideramos la premisa del cambio cultural requerido con DevOps, veremos de inmediato que hay un conflicto. Tanto compartir como comunicarse son componentes fundamentales de DevOps, y eso significa intentar que un grupo de introvertidos no solo se relacione con la gente, sino que también sea eficaz en esa tarea. Esto significa que encontrar una manera de “pueblar sin poblar” es como encontrar la olla de oro al final del arcoíris.

Resulta que ChatOps podría ser ese tesoro de oro.

Operaciones de chat: Poblamiento sin pueblo

Entonces, ¿qué es ChatOps? Jason Hand , uno de los mayores expertos en ChatOps, nos da una definición concisa : “Piense en ChatOps como una línea de comandos compartida”.

Es más que eso, por supuesto, pero en su forma más básica este es un excelente lugar para comenzar.

Herramientas como HipChat y Slack no están diseñadas para la comunicación 1:1, como los sistemas de mensajería instantánea de la vieja escuela. Se puede hacer, pero el verdadero poder de estas modernas plataformas de comunicación es permitir un entorno de comunicaciones abierto donde la información y las actualizaciones se comparten instantáneamente con cualquier persona de la organización que esté interesada en ellas. Se fomenta el acecho, porque lo importante es la disponibilidad y accesibilidad de la información, no una conversación continua.

Los canales (como #IRC) proporcionan los medios para controlar la relación señal:ruido y, a menudo, un registro de auditoría claro de quién hizo qué y cuándo. Estas herramientas logran esto siendo más que clientes de chat. Son plataformas con la capacidad de ampliar la funcionalidad a través de API para proporcionar comunicación bidireccional no solo con personas, sino también con sistemas. Eso significa que puedo agregar un canal de #alertas al cual puedo canalizar, bueno, alertas de componentes de infraestructura.

Puedes –con relativa facilidad, debo añadir– crear una “aplicación” para Slack que consulte y devuelva información a través de sus API. Quizás sea su interruptor, o su balanceador de carga, o el clima local. Sea lo que sea, puedes invocar comandos desde estas herramientas que ejecutan tareas automáticamente. Y puedes compartir la invocación –y los resultados– sin que lo sepa todo aquel que necesite saberlo o que pueda beneficiarse de saberlo. Luego, las tareas se documentan según lo que hiciste y dejan un rastro para que otros comprendan lo que está sucediendo. Actualizaciones de estado de los sistemas de monitoreo, nuevos tickets de la mesa de ayuda, una nota de que un servidor acaba de caer y ya no está disponible. Casi cualquier cosa que puedas imaginar que pueda comunicarse a través de una API se puede compartir con otras personas, sin necesidad de que haya realmente gente.

Este proceso abre una gran cantidad de oportunidades de tutoría, capacitación y liberación de conocimiento tribal que beneficia otras áreas de TI, incluido el desarrollo. Se trata de compartir a gran escala, sin aglomeraciones en salas llenas de gente ni realizar ejercicios de formación para ingenieros noveles. También es una de las pocas herramientas que permite el cambio cultural necesario para adoptar con éxito un enfoque DevOps en “la red”.

Y debemos adoptarlo. Si aún tiene dudas, considere esta pregunta planteada por Atlassian y xMatters en su Encuesta de madurez de DevOps de 2017 :

Los autores tienen sus propias hipótesis, basadas en sus datos, pero yo tengo otra, basada en gran medida en la falacia de composición, que nos recuerda que la aplicação lanzada para su implementación no es la misma aplicação en producción . La inserción de servicios de aplicaciones y la interacción con la red cambian la composición. La verificación de dicha aplicação, a menos que se realice en una réplica exacta del entorno de producción, ya no es completamente aplicable.

Peor aún, para casi un tercio de las empresas, esos problemas no se descubren hasta que los clientes les notifican interrupciones del servicio. Esto puede deberse a la forma en que se comparte la información entre desarrollo y TI. El veintinueve por ciento dice que la información se comparte entre equipos cuando se solicita específicamente. Sólo el 16,8% hace la información “abierta a todos aportando información técnica, objetivos, planes y resultados”. 

Sin la información específica sobre el comportamiento de una aplicación en producción, a menudo es difícil discernir cuál es el problema, y mucho menos su origen. “Funciona en mi máquina” es un mantra defensivo que nace de la frustración de los desarrolladores por no poder replicar un mal comportamiento que, en la mayoría de los casos, se debe a una falta de información ambiental.

Incluso si no estamos entusiasmados por comenzar a automatizar todas las cuestiones de la red , ChatOps es una buena forma de abrir las líneas de comunicación entre TI y desarrollo y brindar una mayor comprensión de los problemas que conducen a un MTTR (tiempo medio de resolución) más rápido.  Es un medio para proporcionar una visión más completa de lo que está sucediendo "en la red" sin ser ingenieros entrometidos o microgestionadores. Ofrece a los introvertidos una manera de comunicarse con las personas sin necesidad de contactarlas, lo que los anima a compartir con más frecuencia y profundidad y, es posible que lo hagan también con entusiasmo.

Si eres nuevo en ChatOps, te recomiendo leer el libro electrónico de Jason Hand, “ChatOps for Dummies ”. Requiere que proporciones tu correo electrónico, pero vale la pena. 

Y estad atentos aquí. Habrá más sobre ChatOps en el futuro, lo puedo garantizar.