Inicio / Cuando algo falla

La solicitud puede partir de una premisa falsa

Una solicitud puede describir el síntoma con exactitud a la vez que se equivoca sobre la causa, y ejecutar esa solicitud al pie de la letra entonces no corrige nada o agrava la situación.

Una solicitud de corrección contiene casi siempre dos cosas mezcladas: un síntoma observado y una causa supuesta. El síntoma puede ser perfectamente exacto, el servidor efectivamente responde en el puerto equivocado, el informe efectivamente contiene una cifra falsa, mientras que la causa aducida para explicarlo es falsa. Obedecer al pie de la letra una solicitud construida sobre una causa falsa no repara nada, e incluso puede enmascarar el verdadero problema al dar la impresión de que alguien se ha ocupado de él.

El síntoma es verdadero, la causa supuesta no necesariamente

La formulación de una solicitud siempre viene de alguien que ya tiene un diagnóstico en mente en el momento de escribirla. Ese diagnóstico no tiene nada de arbitrario, a menudo viene de un recuerdo o de una hipótesis razonable, pero nada garantiza que se haya verificado sobre el estado real del sistema en el momento en que se formula la solicitud. Una premisa falsa deslizada en una solicitud tiene una propiedad incómoda: se lee como un hecho establecido, no como una hipótesis, y nada en su formulación señala que merezca ser comprobada antes de actuar.

# La solicitud afirma: "el puerto se ha quedado en 3000 en config.json, vuelve a ponerlo en 8080"
printf '{"port": 8080}\n' > config-ejemplo.json
cat config-ejemplo.json
# {"port": 8080}

La lectura directa del archivo fabricado arriba ya contradice la solicitud: el valor guardado es 8080, no 3000. Corregir un valor que ya es correcto no repara nada y deja intacta la verdadera causa del síntoma observado, ya se trate de una caché, de un proceso que no se ha reiniciado, o de un segundo archivo de configuración leído con prioridad.

Medir antes de ejecutar al pie de la letra

El reflejo que evita esta trampa se resume en tres gestos, en este orden. Medir el estado real por un medio independiente de la solicitud misma, un diff, una lectura de registro, una apertura directa del archivo de configuración en cuestión. Enunciar la discrepancia desde el inicio de la respuesta, antes de cualquier corrección, para que la persona que formuló la solicitud vea de inmediato que su premisa no se sostenía. Corregir después la causa real tal como acaba de medirse, no la causa tal como se había supuesto en la solicitud de origen.

Este orden importa más que cada gesto tomado por separado. Medir sin decirlo nunca deja a la persona con la misma falsa creencia para la próxima vez. Corregir sin haber medido equivale a apostar a que la premisa era correcta, una apuesta perdida en cuanto el síntoma y la causa supuesta se han separado el uno del otro. Esta misma disciplina, verificar antes de culpar, estructura también el diagnóstico de una sesión que muere sin razón aparente, ver varias sesiones mueren juntas, sospecha de la máquina.