Bienvenido, soy Miguel y para hoy les traigo este nuevo tutorial.
🤔 ¿Alguna vez ha intentado investigar un error en el trabajo y ha descubierto que los resultados no son concluyentes? ¿Sintió que lo había intentado todo pero no pudo comunicar claramente los resultados a su equipo o gerente?
Índice
✍️ 1. Enumere sus teorías y suposiciones
Al intentar descubrir la causa raíz de una problema o error en software, es fácil de utilizar sesgo de confirmación. Una forma de aliviar esto es enumerar todas sus teorías en un documento (Google Docs / Confluence / etc.) y escribir notas junto a cada una a medida que las explora, asegurándose de explorar más que solo sus ideas originales. Otra forma de evitar esto es incluir a varias personas en el proceso para reducir el riesgo de que solo pruebe sus ideas amadas; incluya a un miembro del equipo que no esté al otro lado del problema para ayudar a hacer preguntas. Los 5 porqués son útiles aquí para descubrir suposiciones y teorías inexploradas.
✅ 2. Configure sus pruebas correctamente desde el principio
Uno de los mayores desafíos que he encontrado al intentar reproducir un problema en un entorno de no producción (desarrollo) es que existen tantas diferencias entre la producción y el entorno de prueba; el principal es la carga.
«Bien, ¿por qué no simplemente aumentar la carga en el sistema de prueba para reproducir el problema? «
Probablemente hayas tenido este pensamiento. Tengo también. Pero rápidamente se vuelve más difícil que eso. ¿Qué es lo que produce la carga en su sistema? Tráfico HTTP? ¿Trabajos de fondo? Consultas de base de datos? Todas las anteriores? Se vuelve abrumador rápidamente, y en medio de un error de alto impacto, se encuentra trabajando a las 3 a.m. de la mañana siguiente y se da cuenta de que la reproducción de la carga de producción podría llevarle otros 5 días para configurar.
Recientemente investigué un error durante una carga de alta producción que provocó que un punto final HTTP se convirtiera en un cuello de botella y, finalmente, en un tiempo de espera (502).
Supuse que debido a otras tensiones en la base de datos en ese momento (procesamiento de la cola de AWS SQS), el problema fue causado por el agotamiento de la conexión de la base de datos. Intenté reproducir el problema lanzando carga a la cola SQS del entorno de prueba. Esperaba ver un alto consumo de SQS y escrituras de DB a medida que ingeríamos mensajes. En cambio, vi un alto consumo de SQS sin un aumento de escritura en la base de datos.
«¿Qué? ¿Por qué?»
Para los mensajes simulados que estaba enviando a SQS para su ingestión por nuestro servicio, me di cuenta de que estaba enviando la misma ID en cada mensaje. Luego, nuestro servicio ingeriría la ID y, para permanecer idempotente, usaría restricciones de ID únicas en la columna de ID en Postgres. Al mirar los registros de RDS, noté esto:
ERROR: duplicate key violates unique constraint
🤦
Vale la pena dedicar el tiempo por adelantado a asegurarse de que realmente está probando lo que desea probar. Esto lleva tiempo. El DB no estaba haciendo más escrituras porque no tenía nada nuevo que escribir. Arreglé el problema y continué.
¿Qué estaba tratando de probar exactamente? Dediqué tiempo a escribir cada uno de los pasos necesarios para probar una teoría y encontré resultados mucho mejores, con menos tiempo perdido.
En software, siempre es más emocionante lanzarse a la solución, pero vale la pena dedicar tiempo a explorar el problema desde el principio.
👨🏫 3. Comparte tus aprendizajes con tu equipo
Esto puede parecer menos relacionado con el análisis de la causa raíz de un error, pero puedo asegurarle que este paso es lo que paga dividendos en los resultados.
Como programadores, es fácil entusiasmarse resolviendo problemas y adquiriendo comprensión sobre cómo funciona un sistema en un nivel inferior, eso es emocionante por derecho propio. Pero creo que es igualmente emocionante e importante compartir estos aprendizajes con su equipo. Escriba un párrafo, una página o muchas páginas sobre lo que aprendió y comparta estas valiosas lecciones con su equipo. Enumere sus teorías y suposiciones, y el resultado final.
¿Por qué? 🤔
Porque suceden varias cosas cuando comparte lo que ha descubierto:
- Consolida sus aprendizajes: la escritura ayuda a solidificar lo que ya sabe
- El equipo adquiere un entendimiento compartido y puede moverse más rápido juntos cuando ocurre un problema similar
- Sus habilidades de comunicación se perfeccionan y se le considera influyente en este espacio.
¡Gracias!
Si te ha resultado útil, dale un voto positivo. Me encantaría escuchar su experiencia con el análisis de la causa raíz de los errores, así que deje sus comentarios a continuación. 😃
Añadir comentario