Usar Slack para monitorear su aplicación

Todo comenzó con una visita a una pequeña startup en Denver, Colorado. Durante mi visita, comencé a escuchar un "ding" sutil y encantador en la esquina de la oficina cada pocos minutos. Cuando fui a investigar este extraño ruido, encontré un timbre de servicio conectado a una Raspberry Pi, con un pequeño martillo de metal conectado a la placa de circuito. Al final resultó que, el Pi estaba recibiendo mensajes del servidor del equipo, y movía ese pequeño martillo en la campana cada vez que un nuevo cliente se registraba .

Siempre pensé que era un gran motivador para el equipo y me hizo pensar en cómo podría usar el chat del equipo para lograr una experiencia similar y cómo podríamos analizar y visualizar los datos de registro.

Debido a que ya usábamos Slack para el chat de equipo y a que tiene una API bellamente documentada, era una opción obvia para el experimento.

Lectura adicional en SmashingMag:

• Interfaces conversacionales: ¿dónde estamos hoy? ¿A donde nos dirigimos?
• Colaboración en equipo y cierre de brechas de eficiencia en el diseño receptivo
• Lo que debe saber sobre el proceso de diseño de aplicaciones
• A las carreras: Primeros pasos con Design Sprints
  

Configurar holgura

En primer lugar, tuvimos que obtener una "URL de webhook" de Slack para publicar mensajes mediante programación en nuestro canal de Slack.

Ahora que teníamos una URL de webhook, era hora de integrar los mensajes de Slack en nuestra aplicación Node.js. Para hacer esto, encontré un práctico módulo de Node.js llamado node-slack.

Primero, instalamos el módulo Node.js:

 npm install node-slack --save

Ahora, podríamos enviar mensajes de Slack a nuestro canal de elección con unas pocas líneas de código.

 // dependency setup var Slack = require('node-slack'); var hook_url = 'hook_url_goes_here'; var slack = new Slack(hook_url); // send a test Slack message slack.send({ text: ':rocket: Nice job, I\'m all set up!', channel: '#test', username: 'MyApp Bot' });

(Puede encontrar paquetes de integración de Slack similares para Ruby, Python y casi cualquier otro idioma).

Cuando se ejecuta, este código genera el siguiente mensaje en nuestro canal #test Slack:

El código anterior es mínimo, pero es específico para la API de Slack y el módulo de holgura de nodo. No quería estar encerrado en ningún servicio de mensajería en particular, así que creé una función de módulo genérica de Node.js para ejecutar el código específico del servicio:

 // Messenger.js // dependency setup var hook_url = my_hook_url; var Slack = require('node-slack'); var slack = new Slack(hook_url); module.exports = { sendMessage: function(message, channel, username) { if (!message){ console.log('Error: No message sent. You must define a message.') } else { // set defaults if username or channel is not passed in var channel = (typeof channel !== 'undefined') ? channel : "#general"; var username = (typeof username !== 'undefined') ? username : "MyApp"; // send the Slack message slack.send({ text: message, channel: channel, username: username }); return; } } };

Ahora podemos usar este módulo en cualquier parte de la aplicación con dos líneas de código, y si alguna vez decidimos enviar mensajes a otro servicio en el futuro, podemos cambiarlo fácilmente en Messenger.js.

 var messenger = require('./utilities/messenger'); messenger.sendMessage(':rocket: Nice job, I\'m all set up!', '#test');

Ahora que teníamos los conceptos básicos configurados, estábamos listos para comenzar a enviar mensajes desde la aplicación.

Seguimiento de registros

La primera orden del día fue lograr la paridad servicio-campana. Localicé la devolución de llamada exitosa de la función de registro de usuario y agregué este código:

 messenger.sendMessage('New user registration! ' + user.email);

Ahora, cuando alguien se registraba, recibíamos este mensaje:

¡Incluso suena! Este fue un buen comienzo, y me dio esa sensación satisfactoria de campana de servicio, pero me dio sed de más.

Sumérgete más profundo

A medida que mi curiosidad crecía con cada ding, comencé a preguntarme cosas como: ¿Qué pasa si no se pudo crear un nuevo usuario? ¿Qué sucede si un usuario se registró, inició sesión pero no completó el proceso de incorporación? ¿Cuál es el resultado de nuestras tareas programadas? Ahora que el trabajo preliminar estaba en su lugar, responder a estas preguntas fue pan comido.

Supervise las excepciones y los errores críticos en el back-end

Uno de los errores más importantes que queríamos saber era si no se podía crear un nuevo usuario. Todo lo que teníamos que hacer era encontrar la devolución de llamada de error en la función de registro de usuario y agregar este código:

 messenger.sendMessage(':x: Error While adding a new user ' + formData.email + ' to the DB. Registration aborted!' + error.code + ' ' + error.message);

Ahora sabíamos instantáneamente cuándo fallaron los registros, por qué fallaron y, lo que es más importante, para quién fallaron:

Había todo tipo de lugares interesantes donde podíamos enviar mensajes (prácticamente en cualquier lugar con una devolución de llamada de error). Uno de esos lugares fue esta función genérica de error general:

 app.use(function(err, req, res, next) { var message = ':x: Generic Server Error! '+ err + '\n Request: \n' + req.protocol + '://' + req.get('host') + req.originalUrl + '\n' + JSON.stringify(req.headers) + 'Request Payload:\n' + JSON.stringify(req.body); messenger.sendMessage(message, '#server-errors'); res.status(err.status || 500); res.json({'error': true }); });

Este código nos ayudó a descubrir cómo se ve una solicitud para excepciones no controladas. Al observar la solicitud que desencadenó estos errores, pudimos rastrear las causas principales y corregirlas hasta que no hubiera más errores genéricos.

Con todas estas notificaciones de error en su lugar, ahora teníamos la tranquilidad de saber que si algo importante fallaba en la aplicación, lo sabríamos al instante.

Supervisar las finanzas

A continuación, quería enviar una notificación cuando ocurra un evento financiero en la aplicación. Debido a que nuestro producto SaaS se integra con Stripe, creamos un punto final de webhook que recibe un ping desde Stripe cuando las personas actualizan su plan, degradan su plan, agregan información de pago, cambian la información de pago y muchos otros eventos relacionados con los pagos de suscripción, todos los cuales se envían a Flojo:

Supervisar el comportamiento del usuario en el front-end

Hubo algunos casos en el front-end en los que queríamos comprender el comportamiento del usuario de formas que el back-end no podía proporcionar, por lo que creamos un punto final para enviar mensajes de Slack directamente desde el front-end. Debido a que nuestra URL de webhook de Slack está protegida detrás de un punto final POST , era un riesgo mínimo exponer el envío de mensajes de Slack a nuestro equipo a través de un punto final.

Con el punto final en su lugar, ahora podríamos enviar mensajes de Slack con una simple llamada $http.post AngularJS:

 // send Slack notification from the front end var message = ":warning: Slack disconnected by " + $scope.user.username; $http.post('/endpoint', message);

Esto nos ayuda a responder preguntas importantes sobre el negocio: ¿Las personas se registran y agregan un nombre de dominio? ¿no es así? Si alguien lo es, es para un dominio de muy alto perfil cuyo propietario nos gustaría comunicarnos personalmente poco después de que lo hayan agregado. Ahora podemos aprovechar esto:

En un momento, vimos un patrón de personas que agregaban un dominio, lo eliminaban y luego lo leían en unos minutos, lo que nos indicó un error oscuro que probablemente nunca hubiéramos descubierto de otra manera.

También hay señales de que un usuario no está satisfecho con el servicio, y es importante conocerlas. ¿Alguien eliminó un nombre de dominio? ¿Desconectaron Slack?

Estos comentarios nos brindan la oportunidad de comunicarnos de manera proactiva y ofrecer una excelente atención al cliente cuando más importa.

Supervisar tareas programadas

Una de las cosas más interesantes de ver en Slack es el resultado de las tareas programadas. Nuestro producto SaaS ejecuta tareas para notificar a las personas sobre el rendimiento de su sitio web (nuestro servicio principal), para enviar correos electrónicos transaccionales, para limpiar la base de datos y algunas otras cosas. El disparo y los resultados de estas tareas envían un mensaje a Slack:

Ahora sabemos cuándo se activa una función de tarea, cuál es el resultado de esa función (en este caso, envía varios correos electrónicos) y si falla por algún motivo.

Aplique este concepto a su aplicación

El estudio de caso anterior es un ejemplo práctico de lo que hicimos para monitorear la aplicación y el servicio GoFaster.io. Ha funcionado fantástico para nosotros, pero ¿cómo escalaría este concepto a grandes aplicaciones que envían cientos, tal vez incluso miles, de mensajes por día? Como puede imaginar, esto se convertiría rápidamente en una situación de "Slackbot que gritó lobo", y el valor se perdería en el ruido.

No trate todas las notificaciones por igual

Algunas notificaciones son más importantes que otras, y la importancia variará según el empleado y su función. Por ejemplo, es posible que la gente de desarrollo de software y operaciones de TI (DevOps) solo se preocupe por los mensajes del servidor, mientras que la gente de servicio al cliente se preocuparía más por lo que sucede con los usuarios.

Por suerte, Slack tiene una gran solución a este problema: los canales .

Cualquier persona puede crear canales, hacerlos públicos o privados para su organización y compartirlos con cualquier persona. Una vez que se haya suscrito a un canal, puede controlar cómo le alertan las actividades de ese canal. ¿Suena un nuevo mensaje en el canal cada vez? ¿También alerta a tu teléfono? ¿Solo pone en negrita el canal? Todo esto puede ser controlado para cada canal por cada miembro del equipo para adaptarlo a sus necesidades.

Poniendo esta idea en práctica, así es como una organización más grande podría organizar notificaciones basadas en monitores en Slack a través de canales:

#Errores-críticos-del-servidor

• Qué: errores de registro, errores de inicio de sesión, errores de lectura y escritura de la base de datos
• Quién: administradores de sistemas, DevOps, CTO, CEO, desarrolladores
• Configuración de alertas: notifique siempre en el teléfono o en el escritorio.

#Errores-del-servidor-no-críticos

• Qué: errores 404, errores generales del servidor, etc.
• Quién: DevOps, desarrolladores
• Configuraciones de alerta: haz negrita pero no toques.

#Finanzas

• Qué: transacciones de pago, transacciones fallidas, actualizaciones, degradaciones, tarjetas vencidas
• Quién: director financiero, director ejecutivo
• Configuración de alertas: Haz que llueva.

#comportamiento-del-usuario

• Qué: registro, proceso de incorporación, actualización del tipo de plan, adición de información, eliminación de información, eliminación de cuenta
• Quién: atención al cliente, administradores de redes sociales, desarrolladores, director ejecutivo
• Configuración de alertas: notifique siempre en el teléfono o en el escritorio.

#Aplicación-Estadísticas

• Qué: resultados de tareas programadas, limpieza, estadísticas de correo electrónico transaccional, recuento de usuarios y métricas de crecimiento
• Quién: comerciantes de correo electrónico, administradores de sistemas, cualquier persona interesada
• Configuraciones de alerta: haz negrita pero no toques.

Conclusión

Habiendo desarrollado esta idea durante unos meses y digerido los resultados, descubrimos que es una extensión invaluable de nuestra aplicación. Sin él, nos sentiríamos desconectados de lo que sucede con el servicio y tendríamos que buscar manualmente la misma información a través del tablero, o las consultas a la base de datos serían una tarea ardua.

Cada aplicación y base de usuarios es diferente, lo que significa que este concepto no puede integrarse en un servicio y ofrecerse a las masas. Para ser valioso, requiere una pequeña inversión inicial de tiempo y recursos para integrarse profundamente en su aplicación. Una vez que esté en funcionamiento, la inversión dará sus frutos en forma de conexión de su equipo con su aplicación y sus usuarios.

En conclusión, aquí hay un resumen de los beneficios de usar el chat de equipo para monitorear su aplicación:

Obtenga una nueva perspectiva sobre el comportamiento del usuario y del servidor

Tener una transmisión en vivo en tiempo real de las métricas que más le importan a usted y a su negocio lo mantendrá estrechamente conectado con lo que hacen los usuarios y cómo responde el servidor.

Reaccionar rápidamente cuando las cosas fallan

Podrás reaccionar más rápido que nunca. Sabrás de los fallos al mismo tiempo que tus usuarios. Puede reaccionar inmediatamente a ese punto final fallido, pérdida de conexión a la base de datos o ataque DDoS.

Ofrecer un servicio al cliente excepcional

Comuníquese con ese cliente que acaba de desactivar su cuenta para ofrecerle un descuento, agradecer personalmente a los clientes que se han actualizado o simplemente hacer un seguimiento con las personas para comprender sus intenciones. Cuando sabe lo que hacen los usuarios y cuándo lo hacen, puede averiguar fácilmente por qué.

La conexión del equipo con la aplicación lo hará más eficiente

Cuando su equipo está en sintonía con la aplicación, la colaboración puede centrarse en resolver los problemas a medida que surgen, en lugar de tratar de averiguar qué sucedió, dónde sucedió o a quién le sucedió.

Las notificaciones y los canales pueden escalar con su aplicación

A medida que su aplicación y su equipo crezcan, también lo harán sus necesidades de monitoreo. Slack hace un gran trabajo al brindarle todos los permisos y controles de notificación necesarios para garantizar que la información correcta llegue a las personas adecuadas.

La búsqueda es poderosa

Al registrar un nombre de usuario en sus mensajes de Slack, puede realizar un seguimiento de cada error, mensaje de éxito o evento que un usuario haya generado mientras interactuaba con su aplicación simplemente buscando su nombre de usuario en Slack. Solo sepa que, con una cuenta gratuita de Slack, esto está limitado a los últimos 10,000 mensajes.

Espero que haya encontrado útil este concepto, y me encantaría escuchar otras historias de equipos que han implementado formas similares de monitoreo, o simplemente otras formas interesantes de usarlo y desarrollarlo.