ChatOps: dotar de personal sin personas

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Próximamente en una red cercana. De la mano de la otra economía de las API.

Últimamente, la comunidad DevOps ha empezado a prestar más atención a la cultura. Probablemente se deba a que, sin un cambio cultural hacia un entorno de TI más abierto y colaborativo entre las distintas áreas, muchas de las ventajas de DevOps no pueden aprovecharse plenamente. Compartir la información de forma restringida, solo con quienes «necesitan saberla», da lugar a esos silos que se alzan como torres defensivas y encierran el conocimiento propio de cada uno de los ámbitos operativos que conforman lo que cariñosamente llamamos «TI».

Pero derribar esos silos puede ser doloroso. E incómodo. Y sumamente difícil. Aunque podamos bromear sobre el carácter «antisocial» de prácticamente todos los profesionales de TI y burlarnos de las caricaturas, lo cierto es que, como ocurre con la mayoría de las leyendas y los cuentos de hadas, esos arquetipos surgieron de comportamientos y rasgos reales que aún siguen caracterizando a muchos profesionales del sector.

Soy INTJ según el indicador Myers-Briggs. Siempre. Sí, «el Arquitecto». Soy un observador reformador en el espectro de Insights; en realidad, no es más que una prueba junguiana extremadamente idealizada que afirma ser más precisa que el indicador Myers-Briggs. En cualquier caso, soy bastante introvertido. Actualmente, los investigadores estiman que casi el 50 % de la población es introvertida. Y seguro que no te sorprenderá saber que muchos de ellos acabaron trabajando en TI, como yo, mientras que nuestros incomprensibles homólogos extrovertidos se lanzaron a ocupar puestos de marketing y gestión.

A los introvertidos no nos gusta demasiado socializar —que es como llaman hoy en día los jóvenes a relacionarse con otras personas—. No eres tú, de verdad, somos nosotros. Simplemente procesamos la información y los datos de forma distinta a los extrovertidos, y un exceso de interacción activa nos resulta abrumador. Podemos socializar, pero es agotador. Preferimos comunicarnos por escrito y disponer de tiempo para pensar antes de responder. Por eso se nos da bastante bien desenvolvernos en la era digital, donde gran parte de nuestra comunicación es precisamente así: a distancia y por escrito. Incluso podrías confundirnos con extrovertidos si solo nos conoces en nuestra faceta digital.

Si tenemos en cuenta la premisa del cambio cultural que requiere DevOps, enseguida veremos que existe un conflicto. Compartir y comunicarse son dos componentes fundamentales de DevOps, y eso implica conseguir que un grupo de personas introvertidas no solo socialice, sino que además lo haga de forma eficaz. Por tanto, encontrar una manera de «socializar sin tener que socializar» es como encontrar la olla de oro al final del arcoíris.

Resulta que ChatOps podría ser precisamente esa olla de oro.

ChatOps: interacción humana sin personas

Entonces, ¿qué es ChatOps? Jason Hand, uno de los mayores expertos en ChatOps, nos ofrece una definición concisa: «Podemos concebir ChatOps como una línea de comandos compartida».

Por supuesto, es mucho más que eso, pero, en esencia, este es un excelente punto de partida.

Herramientas como HipChat y Slack no están diseñadas para la comunicación individual, como los antiguos sistemas de mensajería instantánea. Aunque permiten hacerlo, el verdadero potencial de estas modernas plataformas de comunicación reside en crear un entorno de comunicación abierto, donde la información y las novedades se comparten al instante con todas las personas de la organización interesadas. Se anima a observar sin participar, porque lo importante es que la información esté disponible y sea accesible, no mantener una conversación continua.

Los canales (como #IRC) permiten controlar la relación señal/ruido y, a menudo, ofrecen un registro de auditoría claro de quién hizo qué y cuándo. Estas herramientas lo consiguen porque son más que simples clientes de chat. Son plataformas cuya funcionalidad puede ampliarse mediante API para permitir la comunicación bidireccional no solo con personas, sino también con sistemas. Esto significa que puedo añadir un canal #alerts al que dirigir, por ejemplo, alertas de componentes de la infraestructura.

Puedes crear —con relativa facilidad, añadiría— una «aplicación» para Slack que consulte y devuelva información a través de sus API. Puede tratarse de tu conmutador, tu equilibrador de carga o el tiempo local. Sea lo que sea, desde estas herramientas puedes invocar comandos que ejecuten tareas automáticamente. Además, puedes compartir la invocación —y los resultados— con todas las personas que necesiten conocerlos o a quienes pueda resultarles útil. De este modo, las tareas quedan documentadas mediante las acciones realizadas y dejan un rastro que permite a los demás entender qué está ocurriendo. Actualizaciones de estado de los sistemas de monitorización, nuevos tickets del servicio de asistencia, un aviso de que un servidor acaba de caerse y ya no está disponible... Prácticamente cualquier cosa que se te ocurra y pueda comunicarse mediante una API puede compartirse con otras personas, sin tener que interactuar realmente con ellas.

Este proceso abre un sinfín de oportunidades para la mentoría, la formación y la difusión del conocimiento interno, lo que beneficia a otras áreas de TI, incluido el desarrollo. Permite compartir conocimientos a gran escala, sin abarrotar salas de gente ni organizar sesiones de formación para nuevos ingenieros llenos de entusiasmo. También es una de las pocas herramientas que posibilitan el cambio cultural necesario para adoptar con éxito un enfoque DevOps en «la red».

Y debemos adoptarlo. Si aún tienes dudas, plantéate esta pregunta formulada por Atlassian y xMatters en su Encuesta sobre la madurez de DevOps de 2017:

Los autores tienen sus propias hipótesis, basadas en sus datos, pero yo tengo otra, fundamentada en gran medida en la falacia de composición, que nos recuerda que la aplicación publicada para su despliegue no es la misma que la aplicación en producción. La incorporación de servicios de aplicaciones y la interacción con la red modifican la composición. La validación de esa aplicación, a menos que se realice en una réplica exacta del entorno de producción, deja de ser plenamente válida.

Peor aún, en casi un tercio de las empresas, esos problemas no se detectan hasta que los clientes les notifican interrupciones del servicio. Esto puede deberse a la forma en que se comparte la información entre los equipos de desarrollo y TI. El 29 % afirma que la información se comparte entre los equipos cuando se solicita expresamente. Solo el 16,8 % hace que la información esté «a disposición de todos, proporcionando 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 resulta difícil determinar cuál es el problema, y mucho menos su origen. «En mi máquina funciona» es un mantra defensivo fruto de la frustración de los desarrolladores al no poder reproducir un comportamiento anómalo que, en la mayoría de los casos, se debe a la falta de información sobre el entorno.

Aunque no estemos deseando empezar a automatizar todo lo relacionado con la red, ChatOps es una buena forma de abrir las vías de comunicación entre TI y desarrollo y ofrecer una mayor visibilidad de los problemas, lo que contribuye a reducir el MTTR (tiempo medio de resolución). Permite obtener una visión más completa de lo que ocurre «en la red» sin resultar intrusivo ni controlar en exceso a los ingenieros. Ofrece a las personas introvertidas una forma de relacionarse sin tener que socializar, lo que las anima a compartir información con mayor frecuencia y detalle e incluso, quizá, con entusiasmo.

Si no conoces ChatOps, te recomiendo encarecidamente que leas el libro electrónico de Jason Hand «ChatOps para Dummies». Para acceder a él, tendrás que facilitar tu correo electrónico, pero merece la pena.

Y no os perdáis las próximas novedades. Habrá más contenido sobre ChatOps en el futuro, os lo garantizo.

Sobre el autor

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Lori MacVittie es ingeniera distinguida y evangelista jefe en la Oficina del CTO de F5, y cuenta con una amplia experiencia en entrega de aplicaciones, estrategia de automatización e infraestructura. Es conocida por convertir la complejidad en claridad, ya sea definiendo mecanismos de protección para agentes de IA, analizando arquitecturas multinube frágiles o explorando los límites de los sistemas escalables. Aporta más de treinta años de experiencia en el sector en desarrollo de aplicaciones, arquitectura de TI y operaciones de redes y sistemas. Antes de incorporarse a F5, fue una galardonada editora de tecnología. MacVittie posee un máster en Informática y es una autora prolífica cuyas publicaciones abarcan la seguridad, la nube y la arquitectura empresarial. También es una apasionada de los juegos de mesa y los videojuegos, y expresa sin complejos sus firmes opiniones sobre el queso.

Más artículos de Lori Mac Vittie