Navegando el Caos: Un Enfoque Holístico para la Gestión de Incidentes

Hola a todos. Gracias por unirse a mi charla sobre cómo navegar el caos, también conocido como incidentes en producción. Cuando estaba en la escuela secundaria, la creencia común era que si estabas escuchando activamente en clase, ya tenías el 50% de la preparación del examen en tu bolsillo. Quiero mostrarte cómo adopté esta creencia en un enfoque proactivo real que podrías tomar y que te ayudará a gestionar los incidentes de manera más eficiente y estructurada, y eventualmente preservar las horas de sueño tan necesarias. Pero antes que nada, hola, mi nombre es Hila Fish. Soy una ingeniera senior de DevOps. Tengo muchas cosas que decir sobre mí misma, pero básicamente lo más importante que necesitas saber sobre mí en términos de esta presentación es que manejé muchos incidentes de producción cuando estaba de guardia. Cuando no estaba de guardia, grandes corporaciones, startups, he visto muchas cosas. Por eso puedo traer las cosas que aprendí en el camino a esta presentación. Así que cubramos la agenda para hoy. En primer lugar, cubriremos la mentalidad que debes tener para realmente practicar y gestionar los incidentes de manera eficiente. Luego, cubriremos el flujo de incidentes, también conocido como un proceso estructurado que puedes seguir para gestionar los incidentes de manera eficiente y ser proactivo, cosas que puedes hacer en tu día a día y después de que ocurra un incidente que te ayudarán a estar preparado para el próximo incidente que ocurra. Así que primero que nada, establezcamos una base aquí. La gestión de incidentes es un conjunto de procedimientos y acciones que se toman para resolver un incidente crítico. Básicamente, significa que es un proceso de principio a fin que define cómo se detectan y comunican los incidentes, quién es responsable de manejarlos, qué herramientas se utilizan para investigar y responder a ellos, y qué pasos se toman hacia una solución. Y algo en lo que realmente necesitamos pensar cuando nos enfrentamos a incidentes en producción es, en primer lugar, que no todas las páginas que recibes a través de Ops Uni o PagerDuty o cualquier otra herramienta que estés utilizando, se convierten en un incidente. Cuando es un incidente, cuando tienes una pérdida o una posible pérdida de ingresos, clientes, data y reputación. Y si no tenemos un proceso de gestión de incidentes, si simplemente estamos en un enfoque y mentalidad de poner archivos de manera ad hoc, significa que potencialmente perderemos datos valiosos, el tiempo de inactividad podría llevar potencialmente a una reducción de la productividad y los ingresos, y la empresa podría incumplir los acuerdos de nivel de servicio. Cada empresa tiene sus propios SLA y queremos evitar incumplir esos SLA. Por lo tanto, significa que debemos evitar estar de manera ad hoc, diciendo, `ok, algo sucedió, ahora tenemos que solucionar este problema`. Necesitamos tener un proceso estructurado para resolver los incidentes. ¿Y cómo lo hacemos? En primer lugar, cambiando nuestra perspectiva, necesitamos tener una mentalidad empresarial. Esto significa que cada vez que te enfrentes a algo, cada vez que implementes algo en el trabajo, cada vez que hagas algo en el trabajo, debes pensar no solo en los sistemas que estás incorporando e implementando, sino también en comprender el por qué. ¿Por qué hacemos las cosas de cierta manera? ¿Por qué tenemos este sistema? ¿Cómo nos ayuda a hacer las cosas y cómo ayuda al éxito del negocio? Por lo tanto, se necesita una mentalidad empresarial para comprender el impacto general de los incidentes y mitigar los daños en consecuencia. Y es por eso que debe ser un proceso estructurado. Aquí es donde incorporarás la mentalidad empresarial y te asegurarás de que las cosas se manejen lo más rápido posible en beneficio del negocio. Y para realmente, digamos, gestionar los incidentes de manera eficiente, la regla número uno para gestionar los incidentes y ser un mejor ingeniero en general es saber que todo falla todo el tiempo. ¿Quién dijo esto?

Veamos. Primer pilar, identificar y categorizar. La primera pregunta es, ¿entiendo la magnitud completa del problema y su impacto en el negocio? Si es así, genial. Vamos a profundizar y pasar a la siguiente fase. Y si no, necesito recopilar más información porque el hecho de que haya una alerta, no significa que deba manejarla con la gravedad que tiene. Tal vez la alerta tenga una gravedad incorrecta. Entonces, si no estás seguro del impacto del incidente o del problema o de la página que recibiste, asegúrate de hacerlo porque así comprenderás el impacto en el negocio de ese problema. Segunda pregunta, ¿este problema, incidente, lo que sea, puede esperar y ser manejado en horario laboral? Si no estás seguro, pregunta. Utiliza la información que tienes y escala si es necesario, que es nuestra siguiente fase. Y verifica cómo te enteraste de este problema. ¿Recibí una notificación sobre este problema de los canales adecuados o esperados, es decir, si lo recibí de una alerta de PagerDuty o OpsGenie, genial. Si lo recibí de una queja de un usuario, esto es malo. Entonces, si lo recibí de los canales adecuados, genial. Si no, haz una nota para ti mismo para solucionarlo, es decir, crea un ticket en Jira para asegurarnos de tener una alerta para eso.

El siguiente pilar es notificar y escalar. ¿Quién debe ser notificado sobre este incidente? Tenemos estos dos caminos aquí, durante el incidente y en general. Durante este incidente, debes decidir en función de la importancia del incidente. Por ejemplo, si necesitamos alertar a los equipos de soporte o éxito del cliente y que necesiten comunicar el problema a los clientes, necesitamos saberlo y actuar en consecuencia. Y en general, tal vez tengamos otros equipos o puntos focales clave que dependan de nuestro sistema. Entonces, tenemos un sistema que se ve comprometido en este incidente y otros equipos, sus flujos no funcionan porque el incidente no funciona. Por lo tanto, ese sistema no funciona. Así que tenemos este flujo que debemos asegurarnos de que funcione. Y si no funciona, debemos alertar a esas personas para decirles que, oye, este sistema no funciona en este momento. Te notificaremos una vez que todo vuelva a la normalidad.

Y la siguiente pregunta es, ¿este incidente necesita escalarse? En primer lugar, para que otros equipos me ayuden a resolver el problema. Y como dije, FYI, equipos de soporte o cara al cliente. Entonces, si el incidente requiere escalarse, este es el momento de hacerlo para no perder más tiempo porque tal vez tengamos tiempo de inactividad actualmente y queremos asegurarnos de que el problema se resuelva lo antes posible.

Tercer pilar, investigar y diagnosticar. ¿Qué información es relevante para la resolución del incidente? Debes centrarte en lo que es importante y relevante en este momento porque enfocarte en lo no relevante te desviará y te hará perder tiempo valioso haciendo depuración. Y también recuerda, el flujo del sistema generalmente consta de muchas partes, piezas móviles, y debes centrarte en la fase relevante para la depuración y escalada. Entonces, si escalas, debes decirles, oye, mi sistema intenta llegar a tu sistema a través del puerto X. No funciona. Ayúdame a solucionarlo y no describas todo el flujo del sistema. A nadie le importa. Solo diles qué no está funcionando actualmente y ayúdalos a enfocarse en lo que necesitan verificar. De acuerdo. Tenía esta información. Solucioné el problema. Genial. Ahora, después de hacer algunas pruebas de depuración, ¿encontré la causa raíz y entiendo la causa raíz? Si es así, genial. Podemos pasar a la siguiente fase. Si no, investiga más y escala si lleva mucho tiempo. ¿Por qué escalar en ese momento? Porque, nuevamente, mentalidad empresarial.

Y sería muy bueno saber que creemos que está resuelto. Pero tal vez solo las personas de Alemania no puedan usar el sistema. Nunca se sabe. Entonces, una vez que notifiques a las personas que, OK, todo debería estar resuelto. Pero avísanos si algo no funciona. Así serás un comunicador de extremo a extremo, no solo cuando las cosas no funcionan, sino también cuando las cosas vuelven a funcionar. Pero también te ayudará a entender si el incidente realmente se resolvió por completo.

Verifica las alertas. ¿Estaban bien las alertas? ¿O necesitan ajustarse, porque tal vez necesites cambiar la gravedad de la alerta o corregir falsos positivos? Ajusta las alertas de la manera que sea necesaria. Consulta el manual de ejecución de incidentes relevante. Solo para tener una referencia aquí. ¿Qué es un manual de ejecución de incidentes? A veces, cuando tienes algunos problemas o procedimientos que necesitas hacer que requieren cierto juicio. Por ejemplo, si ocurre un incidente, reviso los registros, por supuesto. Pero si los registros indican X, entonces hago esto. Pero si indican algo más, tal vez necesite hacer algo diferente. O tal vez necesite consultar con alguien. Entonces, cada vez que tengamos, digamos, algo que requiera juicio. Deberíamos tener un manual de ejecución de incidentes relevante que nos ayude a ejercer este juicio.

Especialmente si no todos conocen todo sobre todos los sistemas. A veces, el sistema fue implementado por un miembro del equipo, por ejemplo. Entonces, para que puedas manejar problemas en ese sistema, porque no podrás lidiar y gestionar el sistema en el día a día como tu compañero de equipo, debes tener un manual de ejecución de incidentes que te ayude a resolver cualquier problema en ese sistema. Asegúrate de que haya un manual de ejecución de incidentes relevante. Y asegúrate de que no esté desactualizado. Quieres asegurarte de que esté actualizado. Porque ha habido momentos en los que seguí un manual de ejecución de incidentes hasta la mitad, algo así. Y luego resultó que no estaba actualizado. Y tuve que ir a preguntar a las personas qué sigue porque no estaba actualizado. Y, por supuesto, lo actualicé después. Pero es en medio de la noche cuando tienes un manual de ejecución de incidentes que no está actualizado.

No es bueno despertar a las personas solo por eso. Además, hace que la resolución del incidente sea más lenta. Y todos queremos una resolución más rápida por el bien del negocio. Así que verifica los manuales de ejecución de incidentes, que tengas manuales de ejecución y que estén actualizados.

Piensa en la posibilidad de prevenir cualquier incidente similar o cualquier incidente que pueda ocurrir. Por ejemplo, durante los incidentes descubrí que no hay una fecha local en el servidor. No es bueno. Necesito hacerlo. Así que crearé un ticket y lo resolveré durante el horario comercial. Este es un ejemplo. Pero cualquier ejemplo que se te ocurra que ayude a prevenir problemas que hayas encontrado durante el manejo de este incidente. Puedes abrir tickets en Jira y manejarlos durante el horario comercial, lo que ayudará a que el sistema sea más estable. ¿Y este incidente requiere un informe posterior? Los informes posteriores son las reuniones que tenemos, generalmente después de incidentes críticos. Básicamente, deberían estar en una cultura de aprendizaje y no de culpa. Y significa que, bueno, tenemos este incidente. ¿Cómo podemos aprender de él? ¿Qué hicimos mal y cómo podemos aprender de ello, mejorar y potencialmente prevenir futuros incidentes similares? O no solo similares. Podemos aprender mucho sobre cómo manejamos las cosas a partir de este proceso. Y podemos implementarlo para cualquier otro incidente que ocurra.

¿Entonces este incidente requiere una autopsia? Si es así, genial. Anota las notas lo antes posible mientras aún está fresco en tu mente. De esa manera tendrás una reunión de autopsia más eficiente. Porque una vez que tengamos todos los detalles, podemos discutirlos más a fondo. E incluso si no tienes que hacer una reunión de autopsia, aún comparte el conocimiento a través de un manual de ejecución o a través de un informe diario. Y estoy seguro de que ayudará a cualquiera a aprender más sobre lo que sucedió y aprender de tu línea de pensamiento. Es una situación en la que todos ganan.

Así que eso fue sobre una estructura de incidente y cómo puedes manejar incidentes, cualquier incidente, si sigues esta estructura. Y quiero cubrir algunos detalles aquí sobre la conducta en la sala de guerra. La sala de guerra es básicamente cuando tienes un incidente crítico que requiere más de, diría yo, cuatro o cinco personas para manejar este incidente. Entonces las personas vienen de otros equipos o equipos multifuncionales. Y esto es lo que llamamos una sala de guerra. Y también debe haber una conducta para eso. Y te contaré una historia. Así que en una de mis compañías anteriores, hubo un incidente muy crítico. Fue durante los tiempos de COVID.

Entonces se creó una sala de guerra a través de Zoom. Y yo era muy nuevo en la compañía, como un mes, algo así. Y me uní a la sala de guerra, la de Zoom. Me silencié, solo quería ser un observador y aprender porque sabía que aprendería de lo que estaba sucediendo allí. Así que me uní.

Y luego escuché a la gente discutir, mucha gente. Alguien va en esta dirección y otro en esta dirección. Y todos están compartiendo información no relevante. Por eso te dije antes, concéntrate en la información relevante, porque lo he visto suceder.

No necesitas que la gente se enfoque en información no relevante y eso desperdicia tiempo. No solo tiempo, sino que también desvía la atención de lo que es importante. Así que mucha gente solo hablaba y hablaba y hablaba y se iba en esta dirección. Y nada avanzaba hacia la resolución. Y miré el reloj y ya habían pasado como 10 o 12 minutos y no estaba pasando nada. Solo la gente hablando y ya está.

Así que me desactivé el silencio. Dije, hola, soy Hilah, para aquellos que no me conocen porque era nuevo en la compañía. Y dije, déjenme intentar poner orden aquí. ¿De acuerdo? Y básicamente asumí el rol de ser un gerente de incidentes. Y una de las cosas que hice fue escuchar a alguien decir que una vez que se resuelva el problema, la aplicación debe iniciarse de cierta manera.

Porque de lo contrario, creará otros problemas con la database y demás. Y luego le pregunté a esta persona, ¿tenemos un manual de ejecución para iniciar la aplicación en ese orden? Y él dijo que no. Y luego le dije, está bien, siéntate y escribe un manual de ejecución. ¿Y por qué? Porque era un incidente crítico. No sabíamos cuándo se resolvería el incidente. Si sería en una hora, dos horas, en medio de la noche. Y si sucede y esta persona no está disponible, necesitamos que alguien más inicie la aplicación correctamente. Y no queremos tener un cuello de botella y un único punto de falla en él. Que él sea el único que sabe cómo iniciar la aplicación correctamente. Así que le dije, crea el manual de ejecución.

Y de esa manera, si no estás disponible, no me importa. Cualquier otra persona puede iniciar la aplicación correctamente cuando se resuelva el incidente. Así que este es un ejemplo de lo que hice. Pero hice otras cosas. Como le dije, tú revisas esto, tú revisas aquello. Y básicamente lo que hice fue dividir el trabajo, decirle a la gente qué hacer. Los gerentes de incidentes deben estar tranquilos y serenos y ver las cosas con claridad. Y lo más importante, no tener miedo de reducir la participación de las personas si no sirve al propósito. Porque si una sala de trabajo tiene demasiada gente, puede volverse muy ruidosa. Y especialmente durante el horario de oficina, cuando te sientas en tu computadora y luego hay personas que simplemente se paran sobre ti. Y como, ¿qué estás haciendo? Y a algunas personas les estresa. Entonces, si no se supone que debes estar allí, diré, ayudas con un ABC. Terminas con eso, está bien, muchas gracias. Te llamaremos si necesitamos algo más. Por ahora, por favor, vete. Eso es todo.

Bien, hemos cubierto la mentalidad, hemos cubierto el flujo de incidentes. Cubramos rápidamente ser proactivos en el día a día y después de que ocurra un incidente. ¿Y por qué necesitamos estar preparados? Porque no importa si estás preparado o no, te encontrarán. Y se les paga tu deber, o cualquier otra aplicación. Entonces, después del hecho, ¿qué puedes hacer? Crear turnos de guardia, Los turnos de guardia son básicamente cuando tienes un turno en el trabajo, escribe un turno de guardia con las cosas que sucedieron. Como suprimí esta alerta falsa positiva. Tuve un problema recurrente. La alerta X está esperando que el desarrollador la revise. Escribe un resumen de tu turno, para que los miembros de tu equipo se beneficien de él durante sus turnos de guardia. Y también para fines de auditoría, porque se guarda en Slack y todo se puede revisar después.

Análisis post mortem, como mencioné antes, incluso si no hay una reunión, haz una revisión mental. Haz una retrospectiva contigo mismo y ve qué podrías haber hecho mejor. Y si tienes un análisis post mortem, anota las notas lo antes posible para una reunión más eficiente. Nuevas tareas. Queremos prevenir que ocurra el próximo incidente y estabilizar el entorno. Entonces, si encuentras algo que pueda ayudar con eso, crea nuevas tareas para eso. Modificar alertas. Arregla cualquier alerta falsa positiva. Por favor, no esperes al próximo turno de guardia para hacerlo, porque ellos esperarán al próximo turno de guardia para hacerlo. Y esperarán, y luego nunca sucederá. Así que por favor, hazlo tú mismo. Manuales de incidentes, como mencioné, escribe manuales si no los tienes en absoluto. Si los tienes, asegúrate de que estén actualizados. Verifica cualquier candidato para la auto-remediación. Tenemos un montón de alertas de espacio en disco. Se llena hasta el 90%. Tal vez podamos hacer cosas automáticamente para limpiar el disco de vez en cuando. Entonces, si descubres algún candidato para la auto-remediación, este es el momento de hacerlo.

Y si el problema fue resuelto, genial. Comparte el conocimiento de manera más profunda que en el traspaso de guardia. Porque de esa manera todos pueden aprender de tu línea de pensamiento.

¿Y qué puedes hacer en tu día a día para estar preparado para un incidente? Los traspasos de guardia que mencioné, léelos de manera continua. ¿Por qué? Porque la producción funciona las 24 horas del día, los 7 días de la semana, no solo cuando estás de guardia. Entonces, si quieres estar al tanto de las cosas y mantenerte actualizado, lee estos traspasos y mantente al tanto de lo que está sucediendo en la producción. Además, tal vez también puedas ayudar a mejorar las cosas al ver otras cosas desde otro punto de vista. Esto ayudará en ciertos escenarios.

Punto de contacto para escalación. Debes conocer la información relevante necesaria para tu infraestructura. Pero también debes conocer otras áreas y tener una visión completa. Digamos que hay un problema con X. Si sabes que John está manejando el servicio desde el otro lado, entonces sabes que puedes escalárselo a él. Identificar los puntos de escalada del servicio de manera continua y no solo de manera ad hoc cuando ocurre un incidente ahorrará tiempo y dinero en la gestión de incidentes y salvará las horas de sueño de otra persona porque tal vez necesite despertar a mi líder de equipo para preguntar quién es responsable del servicio X. Realmente puede ayudar con la depuración y ahorrar horas de sueño a los demás.

Comprender la architecture del sistema. Verifica las áreas débiles y las vulnerabilidades, así como el alcance de la sensibilidad y el radio de acción porque de esa manera sabrás qué es propenso a fallar y tendrás una solución para arreglarlo. Una vez que conozcas la architecture del sistema, te ayudará mucho con la depuración y la resolución de problemas.

Aprender los flujos de la aplicación. Esto se trata de los flujos entre sistemas, a diferencia del punto anterior que se trataba del flujo y la architecture de un sistema para conocer sus detalles. Entonces, aquí, aprende los flujos de la aplicación. Si conoces los flujos de la aplicación, te ayudará con la solución de problemas porque sabrás qué se debe verificar y en qué orden, y contribuirá a la depuración metódica. También te ayudará a incorporar la mentalidad empresarial porque si comprendes que se necesita una escalación, este problema es en realidad un incidente, etc., entonces te ayudará a manejarlo.

Estadísticas de los miembros del equipo. Como mencioné antes, la producción ocurre todo el tiempo y no solo a través de tus tareas. Entonces, familiarízate con lo que están haciendo los demás miembros del equipo y cómo sus cambios afectan la producción, si es que hay alguno, y este punto se refiere a los cambios del 100% en producción. Es posible que otras tareas no afecten la producción, pero los despliegues o los cambios en producción definitivamente sí lo hacen. Entonces, pregunta acerca del cambio y su posible impacto porque, nuevamente, a Ops Unit o PagerDuty no le importa si no hiciste el cambio tú mismo. De todas formas te llamarán si estás de guardia. Asegúrate de saber exactamente de qué se trata el cambio y cómo manejarlo.

Y por último, pero no menos importante, sé una persona de referencia. Si eres una persona de referencia, recibirás notificaciones y disminuirás la necesidad de buscar actualizaciones por tu cuenta porque las personas vendrán a ti para informarte sobre lo que está sucediendo en la producción. Entonces, para poder navegar realmente en el caos y manejar los incidentes de producción de manera más eficiente, incorpora la mentalidad empresarial, conviértelo en un proceso estructurado y sé proactivo. De esa manera estarás preparado para cualquier incidente que se presente y, con suerte, prevenir que ocurra el próximo incidente. Y recuerda, menos incidentes significa menos tiempo de inactividad, lo que se traduce en éxito básico. Y el éxito empresarial es eventualmente tu éxito. Además, podrás conservar esas horas tan necesarias de sueño. Muchas gracias.