Guías prácticas

Define and monitor website journey reliability

Un sitio web puede devolver HTTP 200 mientras su formulario falla o los pedidos nunca se registran. La confiabilidad debe describir el servicio que los visitantes realmente reciben, utilizando mediciones comprensibles y una respuesta acordada cuando disminuya la calidad.

Ver el método

Diagrama de revisión: estado inicial, elección, verificación y evidencia.
Diagrama de método editorial sin datos de clientes.

Elija el viaje para proteger

Describa la acción esencial, la audiencia y las dependencias que puedan interrumpirla. Un sitio comercial puede necesitar visitantes para leer una oferta y enviar consultas; Una tienda necesita pedidos registrados correctamente. Carga de página separada, finalización de acciones y manejo posterior porque estos pasos pueden fallar de manera diferente.

Los Libro de trabajo de Google SRE Describe los objetivos del servicio basados en indicadores y acuerdos entre las partes interesadas. Adapte el enfoque al tamaño del sitio. Un equipo pequeño puede comenzar con un viaje, un indicador observable y un propietario en lugar de muchos tableros sin tomar decisiones asociadas.

Definir eventos y ventanas de observación

Escriba lo que cuenta como un intento y éxito, dónde se observa y qué exclusiones están justificadas. La entrada deliberadamente inválida difiere de la pérdida de una consulta válida. El monitoreo sintético y el uso real observan diferentes poblaciones; Mantenga sus resultados separados.

Defina la ventana de lectura y la evidencia útil mínima. Los porcentajes son inestables con pocos eventos en un sitio de poco tráfico. Mostrar recuentos de intentos y fallas junto con la tasa e investigar los casos reproducibles. Evite recopilar mensajes innecesarios o información personal para medir un resultado técnico.

Elige un objetivo antes de comprometerte

Un objetivo interno describe un nivel deseado y guía las decisiones. Un compromiso contractual tiene alcance y consecuencias que requieren un acuerdo por separado. Evite adoptar un alto porcentaje simplemente porque suena tranquilizador. Compare las necesidades de los visitantes, las restricciones operativas y los costos de recuperación.

En un cálculo ficticio, 10 fracasos entre 1.000 intentos producen un 99% de éxito. Esto no describe la duración, las personas afectadas o la gravedad: los recuentos idénticos pueden representar inconvenientes menores o órdenes perdidas. La disponibilidad basada en el tiempo requiere una definición diferente; No convierta indicadores sin explicar el método.

Conectar umbrales a acciones

Decida quién investiga las alertas, qué evidencia establece un incidente y cómo se informa a las personas afectadas. Una interrupción confirmada puede requerir una solución o una reversión. Una alerta aislada puede necesitar verificación antes de escalar. Reduzca la incertidumbre y el tiempo de respuesta en lugar de generar mensajes para cada fluctuación.

La calidad del documento disminuye durante los cambios. Los Capítulo de política de presupuesto de error Describe las respuestas acordadas a las brechas de fiabilidad. Un sitio pequeño podría simplemente retrasar un cambio opcional hasta que se resuelva un defecto crítico sin pretender implementar el modelo operativo de un servicio grande.

Verificar observadores y revisar incidentes

El monitoreo de pruebas en sí: ¿distingue la disponibilidad de la página de las acciones completadas? ¿Puede detectar una notificación perdida? ¿Emite una alerta comprensible que recibe una respuesta? Los escenarios disruptivos pertenecen a entornos autorizados. Los controles de producción deben evitar órdenes ficticias y mensajes accidentales.

Después de incidentes, conecte los cronogramas, el impacto, las correcciones y las comprobaciones de regresión. Revise los indicadores si fallas en la detección. Los Guía de respuesta a incidentes y Registro de aceptación ayudar a asignar acciones y retener los hallazgos. Los objetivos útiles evolucionan con los viajes y los riesgos observados.

Contenido actualizado el 2 de octubre de 2026

Matriz de validación funcional para adaptarse al proyecto

Estos controles propuestos utilizan casos ficticios. Decida qué comportamiento se espera con el equipo, anote el resultado y asigne discrepancias no resueltas antes de la publicación.

Casos de prueba, resultados esperados y evidencia útil
CasoResultado esperadoPrueba para mantener
La página devuelve 200 pero no se registra una consulta válida.El monitoreo de viaje detecta la falla de la tarea.Compara intentos, registros y señales de alerta.
Una prueba sintética falla porque su sistema de monitoreo está desconectado.La falla de monitoreo se mantiene distinta de la falla del sitio web.Registre las observaciones y limitaciones disponibles.
Diez fracasos entre mil intentos en un cálculo ficticio.mostrar 99% de éxito con conteos y ventana; No llame a esta disponibilidad basada en el tiempo.Cálculo, definición de evento y período.

Preguntas frecuentes

¿HTTP 200 establece el éxito del sitio web?

Indica una respuesta entregada, no que se registró una consulta o se pueda procesar una orden. Elija un resultado de tarea observable y mantenga el indicador técnico separado.

¿Cómo se deben leer las tarifas con pocas visitas?

Mostrar recuentos, período y exclusiones, luego inspeccionar fallas de concreto. Evite generalizar las fluctuaciones de algunos intentos. Las pruebas sintéticas pueden reproducir defectos sin reemplazar las observaciones de uso.