Como ingeniero de software, lidiar con incidentes apesta. ¿Recibir esa llamada de guardia a las 3 am un sábado por la mañana? Puede ser aterrador, chupar el alma y, en conjunto, un episodio aborrecible. Si sucede con frecuencia en su lugar de trabajo, literalmente puede inducir PTSD.
Desafortunadamente, esto es parte integrante del espíritu de la época del software. En todo caso, estos son los fuegos a través de los cuales se forja la verdadera ingeniería. Estos incidentes le enseñan cómo diseñar sistemas reforzados y, en muchos casos, cómo no hacerlo.
Este artículo analiza dos aspectos de cómo abordar los incidentes de software:
Los temas que abordaremos son:
¡Profundicemos para conocer algunos detalles!
Realmente desea minimizar la cantidad de incidentes que aprende, ya sea a través de sus clientes o a través de algunas discrepancias contables graves días o semanas desde que comenzó el incidente. Si bien "automatización" es una palabra que se usa demasiado en ingeniería, esta es una de esas áreas en las que realmente desea encontrar el equilibrio adecuado entre la relación señal-ruido y asegurarse de que usted y su equipo reciban alertas sin necesidad de intervención humana.
Si hay demasiadas cosas para elegir, vaya a un nivel súper alto. ¿Cuál es la métrica de más alto nivel que podría elegir? ¿Si los sistemas que lo componen no funcionan como se esperaba, se desviarán de la norma? Esto podría ser el seguimiento de los ingresos que fluyen a través de la plataforma (para una plataforma de comercio electrónico, financiera o basada en dólares) o la cantidad de usuarios activos actuales (para plataformas de redes sociales).
Si ve que los números disminuyen o caen en una desviación estándar o dos, avise inmediatamente al equipo de desarrollo. Centrar las primeras (o más importantes) alertas en el pulso del negocio o en la experiencia principal del usuario será una excelente métrica a monitorear. A medida que se vuelve más sofisticado y comprende mejor el sistema, puede comenzar a profundizar en la pila desde el punto de vista de la observabilidad.
Los indicadores adelantados son de naturaleza predictiva y es probable que señalen un problema que está a punto de ocurrir, mientras que los indicadores rezagados son post hoc y son representativos de las consecuencias una vez que el problema está en progreso. Si puede aprovechar los indicadores adelantados (como, por ejemplo, "la duración de la sesión" que comienza a disminuir), además de o en lugar de los indicadores rezagados (como, por ejemplo, "el número de pedidos realizados cae en picado"), probablemente pueda evitar algo que es bastante catastrófico.
Sus alertas deben ser evidentes para que quede muy claro qué próximos pasos tomar cuando lo despidan. Ya sea para determinar la gravedad del problema, solucionar el incidente o solucionar el problema, debe haber suficientes detalles asociados con la alerta. Quiere asegurarse de que no se requiera mucha discusión inicial para determinar qué hacer con la alerta.
Puede incluir estos detalles en el contenido de la alerta o, si es bastante detallado, puede vincularlo a uno o varios runbooks que el equipo mantiene para este tipo de problemas.
Tener un esquema claro de lo que sucede cuando se activa una alerta, incluido a quién se dirige en función de aspectos como la propiedad del servicio, el conocimiento de la zona horaria, etc., es fundamental para garantizar una respuesta rápida. Más allá de esa primera línea de defensa inmediata, también es igualmente fundamental garantizar que haya claridad sobre cómo y a quién el personal de respuesta al incidente podría derivar el incidente.
A menudo, si el problema es complejo o tiene un alcance mucho mayor del que una persona puede manejar, puede ser necesario involucrar a personas de mayor rango (o varias personas en el equipo), así como a partes interesadas multifuncionales. Hacer que todo eso sea fácilmente accesible a través de herramientas (como PagerDuty, OpsGenie) o documentación clara (libros de ejecución, páginas wiki, repositorios README), podría ser la diferencia entre un incidente catastrófico o una hamburguesa sin nada.
Si bien necesita rutas de escalada claras, no desea que esa sea la respuesta predeterminada. Debe capacitar a los socorristas para que puedan tomar medidas reales para detener la hemorragia o tomar decisiones inmediatas para remediarlas, sin necesidad de consultar a la alta dirección. Esto es bueno tanto para la empresa en términos de limitar las consecuencias como para los empleados, a quienes se les asigna una gran responsabilidad y se les confía la toma de decisiones importantes. Reducir la burocracia y aumentar la agencia de los individuos.
Junto con elementos como cadenas de llamadas y rutas de escalada, otra garantía importante es la escala de prioridad de incidentes. Esta suele ser una referencia rápida para el socorrista o el comandante del incidente. Les ayuda a identificar rápidamente cuál es la gravedad del incidente y etiquetarlo como tal porque podría justificar diferentes grados de respuestas.
Diferenciar entre incidentes críticos (como interrupciones del sistema o corrupción de datos financieros) y problemas menores (como fallas en la paleta de colores) es esencial para que los socorristas eviten falsas alarmas. También garantiza que la respuesta del equipo siga siendo eficaz y centrada.
Sin duda, una de las cosas más importantes es resolver el incidente lo más rápido posible. No querrás perder tiempo filosofando por qué sucedió algo o cómo podría haberse evitado mientras el incidente está en marcha. Puedes reservarlo para la autopsia. Por el momento, concéntrate sin piedad en resolver el incidente y haz las preguntas difíciles más tarde.
A veces, los incidentes pueden volverse demasiado grandes. Tocan demasiados servicios, abarcan múltiples dominios comerciales o simplemente tienen un gran impacto en términos de ingresos o reputación. Ahí es cuando es absolutamente crucial que haya una persona designada como “policía de tránsito” durante todo el incidente. En Place Exchange, hemos instituido “comandantes de incidentes”, que son un pequeño grupo de personas capacitadas en respuesta a incidentes complejos.
La razón por la que es tan importante tener este tipo de función es porque cuando hay varias partes involucradas, es necesario que alguien dirija el tráfico. A menudo, los ingenieros comenzarán a profundizar en la complejidad del problema o intentarán comprender cómo resolverlo.
El papel del Comandante del Incidente es mantener el enfoque del grupo en la resolución rápida del incidente. Se aseguran de que todos tengan tendencia a actuar y, si bien las investigaciones paralelas pueden ser importantes, garantizar el impulso es aún más importante. También son responsables de garantizar que exista una comunicación clara y constante con las partes interesadas y socios internos y externos.
Los comandantes de incidentes normalmente inician una línea sincrónica de comunicación de voz, como una reunión de Slack o una reunión de Google Meet. Esto garantiza que las personas cruciales para la resolución del incidente estén en contacto constante. Es sorprendente lo efectiva que es esta pequeña cosa en comparación con simplemente permitir que las personas resuelvan cosas de forma asincrónica mediante el chat.
Los comandantes de incidentes también son responsables de garantizar que haya una delegación clara de las tareas que deben realizarse y de asegurarse de que exista responsabilidad para obtener respuestas o resultados para esas tareas.
Como dicen, si le pides a 2 personas que alimenten a un caballo, el caballo muere. Un comandante de incidente evita que esto suceda y, en última instancia, es responsable de la rápida resolución del incidente.
Las personas a menudo perdonarán que su aplicación o software favorito se caiga si se les mantiene informados sobre cómo el equipo está trabajando arduamente para resolver el incidente. Tratar de mantener las cosas ocultas, ya sea porque cree que no tiene un control completo del incidente o porque usted y su equipo se sienten avergonzados por ello, no son razones para detener el flujo de comunicación hacia afuera.
Asegúrese de que la comunicación sea concisa, frecuente y transparente tanto para sus socios internos como externos, ya que eso ayudará a generar buena voluntad.
Las autopsias o retrospectivas posteriores a los incidentes son importantes para construir una cultura de aprendizaje y deben ser absolutamente irreprochables. Sea crítico con el proceso, no con la persona. Nadie es más duro consigo mismo que las personas que podrían haber causado esto, y no se gana nada flagelándolos en público. En todo caso, todas las investigaciones sugieren que en realidad se pierde al hacer esto. La gente de Etsy habla mucho mejor de ello, así que lee https://www.etsy.com/codeascraft/blameless-postmortems si quieres obtener más información.
Si bien realizar autopsias por sí solos es importante para crear conciencia y generar ciclos de retroalimentación para aprender de estos incidentes, los elementos de acción que se discuten para evitar que esto suceda en el futuro son quizás más importantes. Si el grupo ha identificado un conjunto de brechas o vulnerabilidades en el sistema, es muy importante que se preste atención a resolverlas de manera oportuna para evitar que vuelva a ocurrir el mismo problema.
Es difícil evitar que ocurran incidentes y, por lo general, esa es una conversación difícil con su empresa y sus clientes. Pero si el mismo incidente ocurre una y otra vez, eso es mucho más difícil de defender e indica un problema grave en la salud y las habilidades del equipo.
Todo el mundo lo entiende. Incluso los empresarios lo entienden. Crear software es DIFÍCIL, y en un mundo donde todo nuestro software tiene cientos de miles de dependencias, donde las fallas pueden romperse, es imposible de predecir. La mierda golpeará al ventilador y estará bien. No podemos evitar que ocurran incidentes. Sin embargo, lo que realmente ayuda es asegurarse de que el MTTD de sus incidentes sea realmente bajo.
El tiempo medio de detección (MTTD) es un indicador clave de rendimiento (KPI) que mide el tiempo promedio que le toma a una organización identificar un incidente o amenaza de seguridad. Es difícil generalizar, dado el ámbito empresarial, la gravedad del impacto, etc., pero si puede reducir su MTTD a segundos o minutos, probablemente podrá reducir significativamente el impacto de un incidente en lugar de decirlo. fueron de horas a días (y mucho menos semanas o meses, lo que lamentablemente es totalmente posible).
¡Todo esto es tan SERIO! ¡Dinero perdido! ¡Clientes teniendo una experiencia terrible! Sin embargo, en medio de todo esto, he descubierto que es fundamental tener sentido del humor. No debemos olvidar que todos somos seres humanos en este proceso y pasamos por distintos grados de estrés. Inyectar dosis de humor en los momentos apropiados ayuda a aliviar algo de esa presión.
Genera una sensación de camaradería que hace que el equipo se sienta como si estuvieran juntos en esto en lugar de estar en una isla en el infierno.
Eso es un envoltorio. ¡Gracias por leer!
⭐ Si te gusta este tipo de contenido, asegúrate de seguirme o suscribirte a https://a1engineering.substack.com/subscribe . ⭐
Foto destacada de Julien L en Unsplash