Asume la responsabilidad del servicio después del despliegue

Define el servicio del que dependen los usuarios

El despliegue pone el software a disposición de los usuarios. La operación lo mantiene útil mientras cambian usuarios, dependencias, tráfico y requisitos. Un generador de código no elimina este trabajo continuo.

En una exportación ficticia de clientes, los usuarios necesitan más que una página accesible. Necesitan los registros permitidos en el formato requerido y dentro de un tiempo aceptable. También necesitan que el servicio impida acceder a datos de otra organización.

Nombra a la persona responsable antes de publicar. Registra quién responde fuera del horario habitual si forma parte del compromiso del servicio. Un proveedor puede realizar parte del trabajo, pero la organización sigue necesitando una vía clara para decisiones y comunicación.

Elige señales que permitan actuar

Un indicador de nivel de servicio, o SLI, mide una propiedad definida del comportamiento del servicio. Un objetivo de nivel de servicio, o SLO, fija una meta para ese indicador durante un periodo concreto. Elige el objetivo a partir de las necesidades de usuarios y la capacidad operativa.

La guía SRE de Google explica este enfoque y el uso de un presupuesto de error para decisiones de fiabilidad. No copies el objetivo de otro servicio sin comprobar su significado. Guía sobre SLO, ejemplo de política de presupuesto de error.

Para la exportación, define cuándo una solicitud que cumple los requisitos se considera satisfactoria. Separa las denegaciones esperadas de los fallos del sistema. Documenta las exclusiones para que la métrica no pueda mejorar simplemente ocultando solicitudes difíciles.

Evita registrar exportaciones completas para aumentar la visibilidad. Recoge la información mínima necesaria para diagnosticar el problema y protege su acceso.

Prepara la respuesta a incidentes

Decide quién coordina, quién investiga y quién comunica. En un equipo pequeño, estas funciones pueden combinarse, pero las responsabilidades deben seguir claras. Conserva un registro de observaciones y acciones.

La guía de respuesta a incidentes de Google destaca la coordinación y la comunicación junto a la mitigación técnica. Una corrección técnicamente válida puede dejar a los usuarios sin información o permitir que varias personas realicen cambios contradictorios. Respuesta a incidentes.

Un agente puede resumir logs o comparar hipótesis dentro de los límites autorizados de datos. La urgencia del incidente no debe darle permisos ilimitados en producción. Usa una vía de escalado definida para el acceso excepcional.

Practica la recuperación y financia el mantenimiento

Prueba el procedimiento de recuperación con datos ficticios representativos. Identifica lo que una reversión de código no puede deshacer, incluidos registros eliminados o mensajes ya enviados. Registra el tiempo y la información necesarios para restaurar el servicio.

Asigna el trabajo continuo: actualizaciones de dependencias, revisiones de acceso, renovación de certificados cuando corresponda, cambios de capacidad y correcciones de documentación. Un servicio sin capacidad de mantenimiento acumula obligaciones después de agotar su presupuesto de lanzamiento.

Después de un incidente, selecciona mejoras que aborden las causas observadas. Conéctalas con implementación y verificación. Así se cierra el ciclo de vida: las pruebas de operación cambian lo que el equipo especifica y construye a continuación.