Revisado · Recursos de Hosmio
Antes de empezar
Reúna el inventario de aplicaciones, el contacto del cliente, el operador actual y un posible reemplazo. Disponga de un lugar para almacenar el informe que siga siendo accesible si el VPS no está disponible. Haga referencia al almacenamiento protegido de secretos; no pegue credenciales en el documento.
01
Defina primero el límite del servicio.
Enumere el trabajo necesario para mantener la aplicación útil: revisiones de acceso, actualizaciones del sistema operativo, cambios de entorno de ejecución, mantenimiento de la base de datos, copias de seguridad, monitorización y renovación de dominios. Separe esto del trabajo que el proveedor de infraestructura ha acordado realmente realizar. Un botón de reinicio, una selección opcional de copia de seguridad o un contacto de soporte no establecen por sí mismos un contrato de servicio gestionado.
Anote cualquier cosa cuyo responsable aún se desconozca. Para Hosmio, las intervenciones finales del proveedor y el alcance del soporte requieren confirmación. Planificar ahora sus propias responsabilidades evita asumir que un incidente de la aplicación será diagnosticado automáticamente por el proveedor de alojamiento.
02
Asigne acciones y autoridad de decisión.
| Actividad | Rol responsable | Disparador y verificación |
|---|---|---|
| Publicación de la aplicación | Operador de la aplicación; suplente designado | Cambio aprobado; probar el inicio de sesión y una tarea representativa |
| Mantenimiento disruptivo | Aprobador de cambios del cliente | Ventana de impacto conocida; decisión explícita de continuar o detener |
| Ejercicio de recuperación | Operador de recuperación | Ensayo programado; registros y adjuntos restaurados verificados |
| Comunicación de incidentes | Responsable actual del incidente | Cambio con impacto material; traspaso con marca de tiempo |
| Excepción de pago | Contacto de compras | Discrepancia o resultado incierto; conservar los datos fácticos del pago |
Un rol solo es útil cuando el equipo ha asignado a una persona localizable. Registre la asignación actual en sus notas operativas privadas. Una persona puede desempeñar varios roles, pero la distinción evita que un técnico apruebe accidentalmente un riesgo empresarial en nombre del cliente.
03
Acuerde el cambio y su punto de parada.
Para una actualización planificada, registre por qué es necesaria, qué cambia, los servicios afectados y cómo volver a un estado conocido. Especifique quién puede aprobar la interrupción y quién puede detener el trabajo si fallan las verificaciones. Utilice una ventana acordada con una zona horaria explícita; "fuera de horario" es ambiguo para un equipo internacional.
Antes de comenzar el trabajo, verifique el acceso, la copia de recuperación y la versión o configuración exacta que se va a cambiar. Establezca un plazo para que el equipo apruebe las verificaciones de aceptación o active su plan de recuperación. No describa la reversión como instantánea a menos que un ensayo real respalde esa expectativa.
04
Elija señales que conduzcan a una acción.
Comience con la tarea del usuario: ¿puede una cuenta representativa iniciar sesión, leer el registro esperado y completar una operación segura? Agregue verificaciones de recursos y dependencias que ayuden a explicar los fallos. Una aplicación puede responder a una solicitud básica de estado mientras una cola en segundo plano ya no avanza.
Elija los umbrales de escalado según las necesidades y observaciones del proyecto. Un portal ilustrativo podría tratar dos verificaciones fallidas de tareas programadas como un aviso para investigar, en lugar de una definición universal de interrupción. Registre cómo se ejecuta la verificación y qué debe inspeccionar el operador a continuación. Las alertas sin un destinatario responsable no crean cobertura.
05
Prepare el reemplazo antes de un incidente.
Haga que el operador de reemplazo encuentre el inventario, el procedimiento de acceso protegido, el último registro de cambios y las notas de recuperación sin orientación. Debería poder distinguir un hecho conocido de una hipótesis no probada. Otórgueles la autoridad adecuada para el rol, en lugar de compartir una cuenta personal simplemente para facilitar el acceso.
Mantenga las marcas de tiempo de los incidentes sin ambigüedad. El RFC 3339 define representaciones de marcas de tiempo con UTC o un desplazamiento explícito; un registro como 2026-09-12T14:00:00Z evita un valor de reloj local inexplicable. RFC 3339: marcas de tiempo de Internet ↗ Siga la guía de traspaso de zona horaria para una transferencia más completa de la responsabilidad actual.
06
Ensayе el informe y registre las lagunas.
Realice un ejercicio de simulación antes de confiar en el documento. Presente un trabajo en segundo plano fallido hipotético mientras el operador principal no está disponible. Pida al reemplazo que identifique el impacto, las acciones permitidas, la ruta de aprobación y la próxima actualización. No realice cambios reales en el servicio solo para demostrar que el breve existe.
Registre los permisos faltantes, la titularidad poco clara y los documentos inaccesibles como acciones con responsables. Revise el breve cuando cambien el personal, las integraciones, los objetivos de recuperación o los proveedores. Completado significa que otra persona autorizada puede seguir el proceso y explicar sus límites; no significa que se haya establecido un equipo de soporte continuo.
Continúe con un ensayo de salida del proveedor y los plantilla de informe de incidentes. Mantenga el breve operativo lo suficientemente conciso para usarlo durante un problema y enlace a procedimientos más detallados cuando sea necesario.