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

Rate this content
Bookmark

La gestión de incidentes puede ser desafiante y lanzarte bolas curvas con problemas inesperados, lo que resulta en pérdida de datos, tiempos de inactividad y en general, pérdida de dinero y horas de sueño, ¡PERO! Hay cosas prácticas que podrías hacer para que sea un proceso más fluido y manejarlo mejor.
¿Recuerdas cuando estábamos en la escuela y la gente decía: "Escuchar activamente en clase garantiza el 50% de preparación para el próximo examen"?
Lo mismo ocurre con ser proactivo en el trabajo de maneras que te prepararán instantáneamente para gestionar incidentes mejor (por la noche o en general).
En esta charla, cubriré las formas proactivas que podrías tomar e incorporar en tu rutina diaria, para prepararte para un proceso de gestión de incidentes más fluido y eficiente.
También mostraré las mejores prácticas que he finalizado a lo largo de los años y que me han ayudado a tener una visión clara de cómo gestionar incidentes de producción de la manera más rápida y eficiente posible.
Abrazar los consejos que te daré te garantizará que no solo hables, sino que también actúes cuando se trata de la gestión de incidentes.

26 min
15 Feb, 2024

Video Summary and Transcription

Esta charla aborda la importancia de un proceso estructurado para la gestión de incidentes y la necesidad de una mentalidad empresarial. Describe un proceso estructurado de cinco pilares y enfatiza la importancia de mantener la calma y hacer las preguntas correctas durante los incidentes. La charla también destaca la importancia de identificar, categorizar e investigar incidentes de manera efectiva, así como priorizar las causas raíz y comunicar las resoluciones de los incidentes. Además, se discute el papel de los gestores de incidentes, las medidas proactivas para la mejora continua y la importancia de la preparación y una mentalidad proactiva.

Available in English

1. Introducción a la Gestión de Incidentes

Short description:

En esta parte de la charla, cubriré la importancia de un proceso estructurado para la gestión de incidentes y la necesidad de una mentalidad empresarial. También enfatizaré la regla de saber que todo falla todo el tiempo.

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?

2. Proceso Estructurado y Tipos de Personas

Short description:

Los incidentes son caóticos por naturaleza. Tener un proceso estructurado ayudará a prevenir incidentes, mejorar el tiempo medio de resolución, reducir costos y preservar el negocio y la reputación. Seguiremos un proceso estructurado con cinco pilares. Compartiré preguntas para hacer y responder en cada pilar para avanzar hacia la resolución del incidente. Hay dos tipos de personas en la gestión de incidentes: los que se mantienen tranquilos y los que no. Hacer las preguntas correctas te ayudará a mantener la calma y avanzar en cada fase.

por cierto? Preguntarías. En primer lugar, yo. Dije eso muchas veces a lo largo de mi career. Pero en primer lugar, creo que es muy extraño citarme a mí misma. Y en segundo lugar, encontré a alguien con un poco más de crédito en la industria que yo. El CTO de AWS, Werner Vogels. Así que toma su palabra. Todo falla todo el tiempo. Los sistemas de producción, los entornos de desarrollo, los pipelines, las cosas que construimos, las cosas que compramos, los sistemas en los que confiamos para saber que la producción está caída, también conocidos como nuestros sistemas de monitoreo. Incluso nosotros como seres humanos, nos estrellamos y necesitamos dormir y luego reiniciarnos. Todo falla todo el tiempo. Y eso es exactamente. Los incidentes son caóticos por naturaleza. Pero si tenemos este hecho, si sabemos que las fallas son inevitables porque todo falla todo el tiempo, entonces no podemos actuar de manera ad hoc poniendo archivos. Podemos decir, OK, esto sucedió, pero estoy preparado para lidiar con ello. Así que esta es toda la idea de tener un proceso estructurado y un proceso estructurado ayudará a prevenir incidentes, mejorar el tiempo medio de resolución, reducir costos porque se redujo o eliminó por completo el tiempo de inactividad, y preservar nuestro negocio, clientes y reputación. ¿Y cómo lo hacemos? Tenemos un proceso estructurado que podemos seguir aquí, cinco pilares, y repasaremos cada pilar y te mostraré preguntas que puedes hacer y responder en cada pilar para avanzar al siguiente. Pero antes, quiero mostrarte dos tipos de personas que conocí en todo mi recorrido en producción, gestionando incidentes de producción. Conocí a este tipo. En primer lugar, aquel que dice mantén la calma, soy un ingeniero. Y el otro tipo que dice no puedo mantener la calma. Soy un ingeniero. Estos son los dos tipos que conocí. Y digo que puedes mantener la calma si te haces las preguntas que voy a compartir contigo en cada pilar y luego te ayudará a avanzar hacia la siguiente fase y hasta la resolución del incidente.

3. Identificar y Categorizar

Short description:

Para manejar eficazmente los incidentes, es necesario comprender la magnitud del problema y su impacto en el negocio. Determinar si el problema puede esperar o necesita atención inmediata. Asegurarse de recibir alertas de los canales adecuados. Escalar si es necesario.

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.

4. Notify, Escalate, Investigate

Short description:

Durante un incidente, notificar a los equipos y partes interesadas relevantes. Determinar si es necesario escalar para una resolución oportuna. Investigar y diagnosticar el incidente, centrándose en la información relevante. Escalar si es necesario para evitar incumplir los SLA.

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.

5. Root Causes, Remediation, Closure

Short description:

Priorizar las causas raíz sobre los síntomas superficiales. Elegir la solución más rápida para eliminar el tiempo de inactividad sin comprometer la salud y estabilidad del sistema. Verificar las tareas pendientes después de resolver el problema. Notificar a las partes relevantes al cerrar el incidente.

Queremos evitar incumplir los SLA. Esa es la razón por la que lo hacemos. También debemos priorizar las causas raíz sobre los síntomas superficiales. Si recibes una alerta de que un servicio en un servidor se detuvo, y, bueno, puedes ir y reiniciar el servicio, o puedes entender e investigar por qué se detuvo el servicio en primer lugar, porque de esa manera podrías exponer un problema subyacente y todos queremos tener un sistema estable. Simplemente reiniciar el servicio no sería suficiente. Debes asegurarte de saber por qué se detuvo en primer lugar. Eso es todo al respecto. Y recuerda que si encontramos la causa raíz, se pueden determinar posibles pasos de remedio, lo que me lleva a la siguiente fase en un segundo. Encontramos la causa raíz. Ahora tenemos posibles pasos de remedio que podemos tomar. ¿Cuál es el mejor paso de remedio que podemos tomar? Debemos elegir la solución más rápida para eliminar el tiempo de inactividad sin comprometer la salud y estabilidad del sistema. ¿Por qué? ¿Y por qué debe ser rápido? En primer lugar, porque si es en medio de la noche, queremos volver a dormir. Pero también, por supuesto, por el bien del negocio, queremos que el servicio esté en funcionamiento lo antes posible. Eso es todo al respecto. Una vez que decidimos sobre el paso de remedio que debemos tomar, verificamos si hay tareas pendientes que deben hacerse después de resolver el problema. Por ejemplo, si fue en medio de la noche y el paso de remedio que se tomó es hacer un parche, porque es en medio de la noche, no vas a hacer una solución completa en medio de la noche. Y todos son conscientes de eso, y eso es bueno. Pero si hiciste un parche, soluciónalo permanentemente y asegúrate de que esté solucionado permanentemente durante el horario comercial. ¿Y por qué? Porque queremos evitar que los problemas recurrentes ocurran una y otra vez. No solo para que no te despiertes, por supuesto, sino también, nuevamente, para que el sistema sea estable. Nos importa el sistema. Queremos que el sistema sea estable y saludable. Así que queremos evitar cualquier problema recurrente. Entonces, si hicimos un parche, solucionemos permanentemente los problemas. Pero este es solo un ejemplo. Si hay tareas pendientes después de resolver el problema, este es el momento de hacerlo. Y al cerrar el incidente, ¿qué se debe hacer? ¿Necesito notificar a alguien sobre la resolución del incidente? Debemos ser comunicadores de extremo a extremo. Entonces, si notificamos y escalamos en un pilar, notificamos a algunas personas. Debemos notificar a las mismas personas y decirles: `OK, creo que el problema ahora debería estar resuelto. Por favor, verifica desde tu lado que todo se vea bien. Además, si el incidente fue crítico, notificar a los clientes.

6. Communication, Alerts, Incident Run Book

Short description:

Asegurarse de que la resolución del incidente se comunique y verificar si está completamente resuelto. Verificar y ajustar las alertas según sea necesario. Tener un manual de ejecución de incidentes actualizado para los sistemas gestionados por otros.

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.

7. Incident Management Best Practices

Short description:

Evitar despertar a las personas innecesariamente, resolver los incidentes rápidamente y prevenir futuros incidentes. Verificar y actualizar los manuales de ejecución de incidentes. Manejar problemas evitables durante el horario comercial. Considerar un informe posterior para el aprendizaje y la mejora.

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.

8. Postmortems and War Room Conduct

Short description:

Considerar la realización de una autopsia o compartir conocimientos para los incidentes. La conducta en la sala de guerra es importante para los incidentes críticos que involucran a múltiples equipos. Evitar perder tiempo y enfocarse en la información relevante para la resolución.

¿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.

9. War Room Conduct and Incident Management

Short description:

Me uní a la sala de guerra, observé a las personas compartir información no relevante, asumí el rol de gerente de incidentes. Identifiqué la necesidad de un manual de ejecución para iniciar la aplicación correctamente.

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.

10. Roles and Responsibilities of Incident Managers

Short description:

Dividí el trabajo, le dije a la gente qué hacer, reduje la participación si no sirve al propósito. Los gerentes de incidentes deben estar tranquilos y serenos.

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.

11. Proactive Measures and Continuous Improvement

Short description:

Crear turnos de guardia, hacer un análisis post mortem y retrospectivo, crear nuevas tareas, modificar alertas, actualizar manuales de incidentes, verificar candidatos para la auto-remediación.

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.

12. Preparation and Proactive Mindset

Short description:

Compartir conocimientos, leer traspasos de guardia, estar preparado, conocer los puntos de escalada, comprender la arquitectura del sistema, aprender los flujos de la aplicación, estar familiarizado con las estadísticas de los miembros del equipo, ser una persona de referencia.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2021React Advanced Conference 2021
39 min
Don't Solve Problems, Eliminate Them
Top Content
Humans are natural problem solvers and we're good enough at it that we've survived over the centuries and become the dominant species of the planet. Because we're so good at it, we sometimes become problem seekers too–looking for problems we can solve. Those who most successfully accomplish their goals are the problem eliminators. Let's talk about the distinction between solving and eliminating problems with examples from inside and outside the coding world.
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Top Content
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
React Advanced Conference 2021React Advanced Conference 2021
47 min
Design Systems: Walking the Line Between Flexibility and Consistency
Top Content
Design systems aim to bring consistency to a brand's design and make the UI development productive. Component libraries with well-thought API can make this a breeze. But, sometimes an API choice can accidentally overstep and slow the team down! There's a balance there... somewhere. Let's explore some of the problems and possible creative solutions.
TestJS Summit 2021TestJS Summit 2021
33 min
Network Requests with Cypress
Top Content
Whether you're testing your UI or API, Cypress gives you all the tools needed to work with and manage network requests. This intermediate-level task demonstrates how to use the cy.request and cy.intercept commands to execute, spy on, and stub network requests while testing your application in the browser. Learn how the commands work as well as use cases for each, including best practices for testing and mocking your network requests.
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
React 18! Concurrent features! You might’ve already tried the new APIs like useTransition, or you might’ve just heard of them. But do you know how React 18 achieves the performance wins it brings with itself? In this talk, let’s peek under the hood of React 18’s performance features: - How React 18 lowers the time your page stays frozen (aka TBT) - What exactly happens in the main thread when you run useTransition() - What’s the catch with the improvements (there’s no free cake!), and why Vue.js and Preact straight refused to ship anything similar
TestJS Summit 2021TestJS Summit 2021
38 min
Testing Pyramid Makes Little Sense, What We Can Use Instead
Top Content
Featured Video
The testing pyramid - the canonical shape of tests that defined what types of tests we need to write to make sure the app works - is ... obsolete. In this presentation, Roman Sandler and Gleb Bahmutov argue what the testing shape works better for today's web applications.

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
TestJS Summit 2022TestJS Summit 2022
146 min
How to Start With Cypress
Featured WorkshopFree
The web has evolved. Finally, testing has also. Cypress is a modern testing tool that answers the testing needs of modern web applications. It has been gaining a lot of traction in the last couple of years, gaining worldwide popularity. If you have been waiting to learn Cypress, wait no more! Filip Hric will guide you through the first steps on how to start using Cypress and set up a project on your own. The good news is, learning Cypress is incredibly easy. You'll write your first test in no time, and then you'll discover how to write a full end-to-end test for a modern web application. You'll learn the core concepts like retry-ability. Discover how to work and interact with your application and learn how to combine API and UI tests. Throughout this whole workshop, we will write code and do practical exercises. You will leave with a hands-on experience that you can translate to your own project.
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
Top Content
WorkshopFree
- Introduction- Prerequisites for the workshop- Fetching strategies: fundamentals- Fetching strategies – hands-on: fetch API, cache (static VS dynamic), revalidate, suspense (parallel data fetching)- Test your build and serve it on Vercel- Future: Server components VS Client components- Workshop easter egg (unrelated to the topic, calling out accessibility)- Wrapping up