Gestión de incidencias para más de 10 equipos interfuncionales

Este artículo apareció originalmente en el Mews Blog de desarrolladores.

Al ampliar nuestra organización tecnológica, el mayor cambio de paradigma se produjo en torno a los 20 desarrolladores. Antes, teníamos un único equipo técnico que se ocupaba de todo. Las únicas distinciones en este equipo eran por funcionalidad: desarrolladores de backend, desarrolladores de frontend, etc. Las diferentes funciones tenían métodos distintos de registro, informes de errores y supervisión del rendimiento. Algunas herramientas eran compartidas, otras eran especializadas. Sin embargo, la gestión de esta pila era bastante sencilla debido a su naturaleza finita y fija. Con la transformación en múltiples equipos interfuncionales (actualmente 13), ya no se trata sólo de construir la "máquina" (el producto), sino de construir una "máquina" que construya "máquinas" (equipos de construcción que construyan productos).

Una parte importante de esta "máquina" de orden superior es el marco de gestión de incidencias. Para mí, es uno de los indicadores de madurez de la organización técnica y es una de mis preguntas favoritas para las entrevistas. Por incidentes, me refiero a todas las excepciones no gestionadas, errores, interrupciones, problemas de rendimiento, problemas de seguridad y cualquier otra cosa que se te ocurra. No sólo directamente en el producto, sino también en el utillaje que lo rodea. Nos enfrentamos a varios problemas típicos, como muchas otras empresas:

• No captar todas las incidencias, ser ciego ante ellas y esperar a que los clientes las informen.
• Captar los incidentes pero ignorarlos por diversas razones.
• No actuar a tiempo ante los incidentes en función de su gravedad.
• Generando muchos falsos positivos.
• Disponer de múltiples herramientas para buscar incidentes.
• No disponer de suficientes datos y conocimientos sobre la magnitud real del problema.

En este artículo, describiré cómo diseñamos nuestro nuevo proceso de gestión de incidencias, abordamos todos esos problemas e implementamos la solución técnica.

Requisitos

Al diseñar el nuevo flujo de trabajo, definimos varios requisitos y limitaciones basándonos en nuestra experiencia previa y en los problemas a los que nos habíamos enfrentado. Nuestro primer objetivo era que la entrega de incidentes fuera extremadamente selectiva, es decir, que los problemas se entregaran al grupo de personas con más probabilidades de ser responsables de ellos y con poder y conocimientos para resolverlos. Si esto no ocurriera, se produciría el efecto espectador. Por lo tanto, cada incidente necesitaba el equipo propietario y su función dentro del equipo especificado. Eso redujo los destinatarios de toda la organización a unas pocas personas.

Cada equipo debe tener un único lugar donde buscar todas las incidencias.

El segundo requisito importante para nosotros era la capacidad de acción y la trazabilidad. En términos sencillos, no queríamos que las incidencias fueran meras entradas en una plataforma de registro, notificaciones de Slack o correos electrónicos, porque no hay garantías de que alguien las mire o actúe sobre ellas. No puedes informar fácilmente sobre su recuento, tiempo de resolución u otros factores, si algunos de ellos están sin resolver más tiempo del debido, etc.

Ser jefe técnico de un equipo es uno de los roles más difíciles, por lo que queríamos que el flujo de trabajo de incidencias fuera muy fácil de usar para ellos. Al final, los jefes técnicos son responsables de la resolución de incidencias dentro de sus equipos. Y como nuestros equipos son multifuncionales, no queríamos que los responsables técnicos tuvieran que recurrir a un montón de herramientas distintas para hacerse una idea general de lo que ocurre en sus equipos.

Almacenamiento

Para garantizar la capacidad de acción y la trazabilidad, decidimos desde el principio que todas las incidencias debían enviarse y almacenarse en nuestro sistema de seguimiento de incidencias, YouTrack. La mayoría de las incidencias son problemas que aún no han sido informados por un usuario final, por lo que no tiene sentido mantenerlos separados de los errores informados. Además, tenemos flujos de trabajo, alertas e informes bastante potentes creados a partir de YouTrack, así que queríamos reutilizarlos. Llevando un registro de los incidentes allí, obtenemos datos más precisos sobre a qué dedican tiempo los equipos. Además, nada se pierde en el spam ni se pasa por alto en Slack, y los desarrolladores tienen un único lugar donde buscar sus artículos de trabajo. Enviar todas tus incidencias a un software de seguimiento de incidencias puede asustar al principio, sobre todo si tienes muchas, así que recomendamos una implantación suave, dando a los equipos algo de tiempo para prepararse para la afluencia.

Sin embargo, enviar todas las incidencias directamente al software de seguimiento de incidencias no sería inteligente, ya que, por ejemplo, no hay límites de tarifa. Por eso empleamos Sentry como "sumidero" de todas las incidencias , que se sitúa frente a YouTrack y lo protege de las inundaciones. Principalmente aprovechamos sus reglas de deduplicación, limitación de tarifa y alerta. No tiene sentido informar de cada vez que se produce el mismo error, como tampoco tiene sentido informar de la primera vez que se produce una advertencia. Esto lo controlamos mediante reglas de alerta basadas en el tipo de incidencia (error, advertencia, fatal), el entorno (producción, puesta en escena, desarrollo), el número de eventos y otros criterios.

Almacenamiento de incidencias en Sentry y distribución al gestor de incidencias.

Para cada combinación de equipo, función y, opcionalmente, producto, hay un proyecto Sentry. Puedes elegir fácilmente los proyectos que te interesan, lo que permite dividirlos por esas dimensiones y crear "vistas" para el jefe de equipo (seleccionando todos los proyectos en los que participa el equipo) o el jefe de función (seleccionando todos los proyectos que incluyen, por ejemplo, el frontend). La razón de tal granularidad es que allí también hacemos un seguimiento de las implementaciones y las versiones del producto para detectar cuándo una implementación provoca una oleada de errores. Sentry lo permite por proyecto, lo que nos obliga a segregarlo, aunque esto introduzca cierta sobrecarga operativa.

Colección

Hay dos fuentes principales de incidencias: nuestras aplicaciones y nuestras otras herramientas y sistemas. Recoger las incidencias de nuestras aplicaciones es bastante sencillo. Sentry proporciona SDK para la mayoría de las plataformas. Nuestro trabajo consiste en determinar el equipo, la función y el producto de un incidente. La función y el producto son sencillos, ya que está claro en qué aplicación se originó la incidencia y qué función es responsable de ella.

Recopilación de incidentes de diversas fuentes.

El equipo es más complicado, sobre todo cuando varios equipos mantienen una misma aplicación. Tenemos una aplicación backend monolítica en la que contribuyen la mayoría de los equipos, así que esto es algo que sin duda teníamos que abordar :) Nuestra solución fue anotar todas las transacciones del sistema con el equipo propietario a nivel de código. Así, siempre que se ejecute código, estará claro cuál es el equipo propietario. El equipo propietario puede definirse en ámbitos más amplios, por ejemplo, módulos o API enteras, lo que ayuda al desplegar la distribución inicial de propietarios. Después, los equipos juegan continuamente con las asignaciones a lo largo del tiempo, para que la propiedad converja a un estado estable. Hasta que un equipo vuelva a dividirse, por supuesto.

Desvío 1: nuestras aplicaciones monolíticas son en realidad bastante modulares, con una propiedad clara de cada línea de código ejecutable. Intentamos adoptar los mejores aspectos de ambos enfoques: la simplicidad y el rendimiento de los monolitos con la propiedad y el aislamiento claros de los microservicios. La propiedad transaccional se utiliza no sólo para las incidencias, sino también para la propiedad del rendimiento o para iniciativas de refactorización de mayor envergadura, cuando nos preguntamos: "¿Quién debe refactorizar este endpoint?".

La segunda categoría de productores de incidentes son otras herramientas y sistemas como New Relic, Azure Monitor, Azure DevOps, Rapid7 InsightOps, etc. Estas herramientas no suelen admitir la anotación de las alertas con metadatos personalizados, por lo que utilizamos convenciones de nomenclatura para distinguir el equipo y otros atributos. Y como estas herramientas no suelen integrarse directamente con Sentry, enviamos los webhooks a través de un "middleware" de recogida unificada integrado en Zapier que utilizamos como un simple FaaS. Allí transformamos todos los formatos de webhook propietarios en uno unificado, extraemos el equipo, la función y el producto del nombre de la alerta, y enviamos la incidencia a Sentry.

Notificaciones

La última parte, la más fácil, la más visible (y para algunas personas la más molesta) es el sistema de notificaciones. Cuando se plantea o se eleva una incidencia en nuestro software de seguimiento de incidencias, un flujo de trabajo la selecciona y envía un webhook a Zapier. Allí, basándonos en varios criterios, distribuimos las notificaciones a diferentes canales. Siempre a un canal de incidencias de Slack del equipo propietario, a veces a un canal más general y, para los incidentes más graves, a PagerDuty.

Parte de notificación del flujo de trabajo.

Desvío 2: Te habrás dado cuenta de que utilizamos Zapier en gran medida. No es una coincidencia y, aunque dos de nuestras herramientas tengan integración directa, enviamos la comunicación a través de Zapier. Eso nos permite tener un único lugar donde investigar la comunicación entre todos nuestros sistemas, lo que ayuda enormemente a la posible depuración de flujos de trabajo más avanzados. No todas las herramientas tienen una gran visibilidad de los webhooks salientes, su historial o por qué fallaron algunos. Zapier lo tiene. Puedes inspeccionar las cargas útiles, las transformaciones, las respuestas de los destinatarios, etc. Escribir una sencilla función JavaScript que se active mediante un webhook y realice alguna acción basada en los datos entrantes es pan comido. Zapier puede entenderse como host, IDE y depurador de dichas funciones. No estoy seguro de que ésta fuera la intención original de sus autores, pero este caso práctico nos funciona muy bien.

Resultados

Ya tenemos muchas ideas sobre lo que podemos mejorar en cada paso del flujo de trabajo. Desde descripciones más bonitas de los problemas y reglas de alerta más inteligentes y granulares, hasta mejores notificaciones con destinatarios aún más delimitados, con reglas de distribución y plazos de resolución SLO. Sin embargo, incluso sin esas ventajas, el flujo de trabajo de incidencias "básico" aportó varias ventajas a nuestra organización:

• Ahora disponemos de datos claros, consolidados y completos sobre nuestros incidentes, lo que nos permite tomar decisiones basadas en datos.
• La forma de informar sobre errores o excepciones no gestionadas sigue mejorando, los equipos están deduplicando incidentes, silenciando falsos positivos e introduciendo nuevos incidentes que antes se ignoraban.
• Gracias a una única fuente de verdad, podemos detectar rápidamente si un equipo tiene problemas con un exceso de incidencias y pedir ayuda.
• Tenemos una visión mucho mejor de la calidad de nuestras implementaciones al correlacionar los incidentes con ellas.
• El flujo de trabajo está preconfigurado para todos los equipos y funciones y se proporciona como un servicio de la plataforma. Requiere unos 5 minutos cuando se introduce un nuevo equipo o se le cambia el nombre.
• Es fácilmente extensible mediante la implementación de nuevos recolectores de incidencias para nuevas herramientas en Zapier.
• Ningún incidente se "pierde en la traducción", lo que se traduce en un producto de mejor calidad y tiempos de resolución más rápidos, apoyando nuestra visión de alcanzar la excelencia técnica.

Una vista en helicóptero de todo el flujo de trabajo.

Esperamos que este resumen te sirva de inspiración para mejorar tu proceso de gestión de incidencias. Y, viceversa, nos gustaría saber qué haces mejor o qué podríamos mejorar. O, si quieres que profundice más en alguna parte del artículo, ¡házmelo saber también!