Informar de un hallazgo de rendimiento sin exagerar: línea base, ventana del incidente, herramienta e intervalo

Objetivo

Redactar una observación de rendimiento de modo que otro agente u operador pueda juzgar cuánta confianza merece y reproducir la medición, sin dar a entender que se realizó un experimento controlado que en realidad no se hizo.

Requisitos previos

La salida en bruto, y no solo un resumen, de las herramientas utilizadas tanto en el periodo normal como durante el incidente.

Pasos

1. Indicar primero la línea base: las cifras de un periodo en el que se consideraba que el sistema estaba sano, con la herramienta, su invocación exacta (opciones e intervalo) y la ventana de tiempo real (hora de reloj) muestreada.
2. Indicar las cifras del incidente de la misma manera, con la misma herramienta y el mismo intervalo siempre que sea posible. Una línea base tomada con vmstat 1 5 y una lectura del incidente obtenida de un intervalo de 10 minutos de sar no son directamente comparables, y el informe debe decirlo en lugar de insinuar lo contrario.
3. Nombrar la ventana de tiempo con precisión, incluyendo la zona horaria o UTC explícito, para que un lector pueda obtener por su cuenta esa misma ventana de cualquier otra fuente (logs, alertas, historial de despliegues) que cubra el mismo periodo.
4. Enumerar qué se descartó y cómo: «la CPU no estaba saturada (las muestras de mpstat de 1 segundo se mantuvieron por debajo del 40 % en todos los núcleos durante la ventana)» es un hecho comprobado con esa resolución; «probablemente no es la CPU» es una conjetura y debe etiquetarse como tal. Un promedio solo descarta lo que habría podido detectar: un intervalo de sar de 10 minutos no puede excluir una saturación que dure unos pocos segundos, y una CPU baja en un invitado no dice nada sobre el steal a menos que también se haya leído %steal.
5. Mantener visiblemente separados los dos tipos de afirmación: las cifras leídas directamente de la salida de una herramienta y la interpretación construida sobre ellas. «iowait estaba elevado» es una lectura; «esto lo causa el trabajo de copia de seguridad» es una hipótesis, salvo que el log de la propia copia confirme la coincidencia temporal, e incluso entonces una coincidencia temporal solo muestra coincidencia, no causa, hasta que modificar al sospechoso modifique la medición.
6. Adjuntar o enlazar las capturas en bruto (un .blg, un archivo perf.data, un archivo binario guardado de sar, una transcripción del terminal) y no solo las cifras extraídas, de modo que la lectura pueda verificarse de nuevo más adelante.
7. Anotar lo que no se midió y aun así podría explicar el hallazgo, en lugar de dar a entender que la investigación fue exhaustiva, y mencionar cualquier herramienta cuya propia sobrecarga (strace, un perf record con frecuencia alta) pueda haber alterado las cifras.
8. Si se afirma que se ha corregido el problema, mostrar la misma medición antes y después con una carga comparable: una única ejecución mejor tras un cambio es una observación, no una prueba.

Resultado esperado

Un informe que un segundo lector puede evaluar por sí mismo (misma herramienta, mismo intervalo, misma ventana y una lista explícita de lo descartado) sin tener que fiarse de las decisiones de criterio del primer investigador.

Límites y base de verificación

Esta es una disciplina de redacción propuesta, no un estándar; no existe un formato único utilizado de forma universal entre herramientas y equipos. Por sí sola no valida que las mediciones de base fueran correctas, solo que lo que se midió y lo que se infirió siguen siendo distinguibles para el lector.