Objeto
Cuentas, ambientes, componentes y horarios incluidos, con un inventario que pueda mantenerse.
Artículo · Operación cloud
Cómo delimitar un servicio gestionado cloud
Un método para acordar responsabilidades, cobertura, alertas, cambios y escalamiento antes de iniciar la operación.
- Publicado
- Revisión técnica
- Revisor técnico
- Wilfredo Rodriguez · Principal Architect
- Estado
- Pieza técnica propia
Alcance operativo
Gestionar no significa asumirlo todo
Un servicio gestionado funciona cuando cada actividad tiene un alcance, un responsable, una evidencia y una ruta de escalamiento. La nube no elimina la responsabilidad del cliente sobre el negocio, la aplicación, los datos o las decisiones que conserva.
La definición debe separar operación recurrente, atención de eventos, cambios autorizados y mejora continua. También debe declarar exclusiones: una alerta observada no equivale automáticamente a corregir código, aprobar gasto o decidir por el propietario de la carga.
Supuestos de la guía
Qué debe conocerse antes de acordar cobertura
- 01Existe un inventario acordado de cuentas, cargas y ambientes
- 02El cliente conserva responsables de negocio, aplicación y seguridad
- 03Cobertura, canales y prioridades se pactan antes de iniciar la operación
Contrato operativo
Cinco capas que evitan zonas grises
Actividad
Qué se observa, ejecuta, aprueba o comunica en monitoreo, incidentes, solicitudes y cambios.
Responsabilidad
Quién participa, quién ejecuta, quién aprueba y quién debe mantenerse informado.
Evidencia
Ticket, registro, alerta, runbook o reporte que permite saber qué ocurrió y qué queda pendiente.
Escalamiento
Condiciones, canal y responsable para involucrar a aplicación, seguridad, proveedor o negocio.
Ejemplo sintético · Sin datos de clientes
Una matriz que convierte una alerta en una respuesta
Imaginemos una carga ficticia con monitoreo fuera del horario laboral. La matriz no promete resolver cualquier causa: define quién recibe la alerta, quién investiga, qué acciones preautorizadas puede ejecutar y cuándo necesita aprobación del cliente.
Si una alarma se activa, el equipo sigue el playbook, registra la evidencia y escala cuando la acción supera el límite acordado. El cierre exige comunicar el resultado y, si corresponde, proponer una mejora separada del incidente.
Equipo gestionado
Recibe la alerta, aplica el playbook, conserva evidencia y comunica el estado por el canal acordado.
Responsable del cliente
Confirma impacto, aporta contexto de aplicación y autoriza decisiones que no fueron preaprobadas.
Especialista o proveedor
Se incorpora cuando la causa o acción requiere una capacidad fuera del alcance operativo pactado.
Preguntas de cierre
Qué confirmar antes de comenzar
- 01Qué recursos, ambientes, horarios y canales están incluidos
- 02Qué alertas requieren una respuesta y qué evidencia debe producirse
- 03Qué acciones están preautorizadas y cuáles necesitan aprobación
- 04Qué prioridades, tiempos objetivos y escalamiento se acordaron
- 05Cómo se revisarán cambios, problemas recurrentes y oportunidades de mejora
Fuentes primarias
Documentación utilizada
Relationships and ownership
AWS Well-Architected sobre responsabilidades y propiedad dentro del modelo operativo.
Conocer más ↗Have a process per alert
AWS Well-Architected sobre respuestas accionables, propiedad y escalamiento para alertas.
Conocer más ↗Use playbooks to investigate issues
AWS Well-Architected sobre investigación consistente, permisos, comunicación y escalamiento.
Conocer más ↗Tu próximo paso
Delimitar mi operación ↗