Análisis de la causa raíz: cuatro consejos para solucionar los defectos más rápidamente

Imagínese esto: usted y su equipo trabajan sin descanso para terminar la próxima versión principal de su producto de software. Crean nuevas características a buen ritmo. El equipo corrige los errores tan pronto como los encargados del control de calidad los reporta. Se aprueban todas las pruebas unitarias. Después de que la aplicación recibe el visto bueno de un conjunto de pruebas más completo, es el momento de enviarla. Y entonces… ¡estruendo! En cuanto llega al entorno de producción, la aplicación se cae estrepitosamente. ¿Qué fue lo que falló?

Resulta que los entornos de prueba no eran tan parecidos a la fase de producción como se pensaba. Se realizaron cambios de infraestructura en el entorno sin ningún tipo de registro. El resultado fue que los entornos se desviaron poco a poco.

Como profesionales del sector tecnológico, dedicamos una parte considerable de nuestro tiempo a la resolución de problemas. Y sí, también dedicamos tiempo a solucionarlos, pero no se puede corregir algo cuando no se sabe qué está mal. Como diría cualquier desarrollador de software que haya pasado horas frente a un depurador, la mayoría de las veces lo realmente difícil es encontrar el error. Una vez que se identifica el problema, solucionarlo puede ser incluso trivial.

Por lo tanto, aprender a solucionar problemas más rápidamente es una de las mejores inversiones que se pueden hacer como desarrollador de software o trabajador de TI en general.

Hablemos de cómo podemos detectar los problemas con rapidez y solucionarlos más ágilmente.

Análisis de la causa raíz: ¿en qué consiste y por qué debería importarle?

El análisis de la causa raíz (RCA) es una técnica específica que puede se puede usar para solucionar problemas. Con esta técnica, se analiza el asunto en cuestión mediante una serie de pasos concretos para identificar la causa principal del problema. El análisis de la causa raíz se basa en el principio de que no es útil atender los síntomas de un problema mientras se ignoran sus raíces.

Al emplear el análisis de la causa raíz, podrá entender lo que ha ocurrido. A menudo, no es posible obtener un panorama completo con solo observar los síntomas. Ahora bien, determinar lo que ha sucedido es únicamente el primer paso: hay que ir más allá y revelar la razón por la que ha sucedido. Con estos conocimientos, es el momento de ponerlos en práctica mediante la formulación de un plan o estrategia para reducir la probabilidad de que se repita.

Una vez abordados el “qué” y el “por qué”, he aquí cuatro consejos que ayudarán a utilizar el análisis de causa raíz para tener menos problemas.

Utilice el método del pato de goma
Sí, hablo en serio, el enfoque del pato de goma. No se trata de un invento. También se llama depuración de pato de goma, y probablemente se le llame de otras formas. Consiste en explicar su problema a un pato de goma. ¿No tiene un pato de goma? No se preocupe. Puede utilizar cualquier objeto inanimado que tenga a mano. O incluso puede hablar con una persona.

Entonces, ¿en qué consiste realmente el enfoque del pato de goma? Este enfoque se basa en el efecto observado de que al explicar algo a alguien, uno se obliga a ordenar sus pensamientos. Nuestros procesos de pensamiento con frecuencia son caóticos o desordenados. Cuando nos enfrentamos a la perspectiva de tener que explicárselos a alguien, no tenemos más remedio que ordenarlos de alguna manera. Jeff Atwood, cofundador del conocido sitio de preguntas y respuestas Stack Overflow, comenta que varias veces los desarrolladores de software le ha contado que han averiguado las respuestas por sí mismos al redactar sus nuevas preguntas en el sitio y que, en realidad, ni siquiera enviaron esas preguntas.

¿Es suficiente el enfoque del pato de goma para solucionar cualquier problema? Por supuesto que no. Es posible, pero con frecuencia es solo el primer paso de una estrategia más amplia.

¿Teme que la gente piense que es un poco raro por hablar con objetos inanimados? El hecho es que la idea del pato de goma es una especie de broma. Es una figura simpática y memorable, que no se debe tomar demasiado en serio. Lo importante es que se obligue a expresar los pensamientos en su cabeza de forma ordenada y a explicar el problema en cuestión de la forma más clara posible.

Puede utilizar los siguientes enfoques:
1. Escribe una pregunta de Stack Overflow. O bien puede pretender que escribe una pregunta de Stack Overflow, pero la escribe en un bloc de notas en su lugar.
2. Presente un informe de errores detallado. Probablemente alguien tenga que hacerlo de todos modos, así que ¿por qué no matar dos pájaros de un tiro?
3. Vaya al cubículo/oficina de su compañero de trabajo y hable con él durante unos minutos. Eso sí, siempre que les parezca bien, claro. No moleste a sus compañeros innecesariamente.


Recopile muchos datos de registro (y realice búsquedas de forma eficiente)

Si ha logrado explicar el problema de forma obvia pero aún no ha podido encontrar la causa raíz, entonces tiene que ir más allá. Lo que hay que hacer ahora es recopilar datos sobre el problema y extraer información a partir de estos.

El registro y el monitoreo pueden ser útiles en este aspecto: registros de caídas, registros de aplicaciones y servidores, etc. Debe recopilar evidencias de que el problema ocurrió, pero también, si es posible, averiguar durante cuánto tiempo ha ocurrido y con qué frecuencia.

No obstante, esto no es suficiente. Recopilar muchos datos es importante, pero todos esos datos no servirán de mucho si no es posible encontrar los fragmentos específicos que se necesitan con la suficiente rapidez. Estar atrapado en una situación de “aguja en un pajar” no resulta ni divertido ni particularmente productivo.

Por eso es preciso utilizar herramientas que permitan buscar y analizar en tiempo real todos los datos de registro que se han recopilado para convertirlos en información valiosa que permita diagnosticar y resolver los problemas con mayor rapidez.


Emplear la técnica de los cinco porqués
Una vez recopilada la información, es hora de utilizarla mediante la identificación de los factores causales. “Factor causal” en este contexto significa la causa inmediata del problema en cuestión. Lo que no se debe hacer es identificar un factor causal y luego detenerse. Hay que ir más allá. Una de las técnicas más conocidas para ello es la de los cinco porqués.

La técnica consiste en formular la pregunta “¿Por qué?” de forma iterativa hasta llegar a la raíz del problema. Observemos un ejemplo rápido:

Problema: el sitio web muestra el error 500.
1. ¿Por qué? Porque el componente de enrutamiento del marco web funcionó mal.
2. ¿Por qué? Porque requiere otro componente, que a su vez funciona mal.
3. ¿Por qué? Porque este componente del marco web requiere la extensión intl, que no funciona en este momento.
4. ¿Por qué? Porque se desactivó accidentalmente tras la actualización del software del servidor.

Como puede notar, el número cinco es sólo ilustrativo. Es posible llegar a la raíz del problema con menos pasos. O quizá se necesiten más pasos.

La técnica de los cinco porqués está lejos de ser perfecta. Ha sido objeto de muchas críticas y, desde luego, tiene sus limitaciones. Sin embargo, puede ser útil para estimular a los ingenieros a que continúen en la búsqueda de la causa raíz de los problemas en lugar de detenerse ante la primera señal de que se acercan a una solución.


Obtener la ayuda de otra parte para realizar la revisión
Una práctica que he aprendido a apreciar en mi carrera de desarrollador de software es la revisión del código. Es increíble cómo el simple hecho de que otra persona imparcial revise el código puede revelar muchos problemas que antes no se podían detectar. Con el tiempo, la mera expectativa de que otra persona revise el código hace que uno sea más consciente de este. Comienza a dedicar más atención de la que prestaría en otras circunstancias.

Entonces, con este punto, ¿recomiendo las revisiones de código? Es cierto, pero no es la única forma de que un tercero intervenga en la revisión. Sugiero que se empleen procesos similares a la revisión para casi todas las tareas que realiza un ingeniero. O mejor aún, por pares. Realice la programación por pares, la configuración del servidor por pares, la depuración por pares y el soporte al cliente por pares. En resumen: resolver los problemas por pares.

¿Ciencia o arte?

La solución de los problemas se encuentra en una fase en la que todavía es más un arte que una ciencia. Sin embargo, eso no debe impedirle emplear técnicas y herramientas para lograr la eficiencia.

Por lo tanto, utilice esas técnicas para hacer análisis de causa raíz:
1. Utilice el método del pato de goma
2. Recopilar muchos datos de registro y utilizar las herramientas adecuadas para buscarlos y analizarlos
3. Emplear la técnica de los cinco porqués
4. Obtener la ayuda de otra parte para realizar la revisión

Es el momento de agarrar el pato de goma y empezar a analizar la raíz de los problemas.

Más información sobre los precios de Amazon OpenSearch Service

Visite la página de precios
¿Todo listo para crear?
Introducción a Amazon OpenSearch Service
¿Tiene más preguntas?
Contacte con nosotros