Seguridad y operación: ejecutar, recuperar y retirar recursos

Una operación fiable requiere conocer el contexto autorizado, la versión que se ejecuta y el estado real de sus dependencias. Esta guía organiza esas comprobaciones alrededor de tareas habituales: preparar una ejecución, investigar un fallo, mover referencias y retirar un worker. Las acciones administrativas deben realizarse con un rol apropiado y con evidencia suficiente para distinguir una solicitud aceptada de un cambio confirmado.

Identidad, tenant y permisos

Compruebe el tenant y el rol activos antes de editar o ejecutar. Una cuenta con acceso a varios contextos puede ver objetos distintos al cambiar de selección. Mantenga separados el espacio de laboratorio y el operativo, y utilice nombres que permitan reconocer el propósito de cada objeto. Un nombre similar no demuestra que se trate del mismo identificador ni de la misma versión.

En Roles and permissions, otorgue las capacidades necesarias para cada responsabilidad. La lectura de Monitor, la edición de definiciones y la administración de infraestructura son responsabilidades diferentes. Si una opción no aparece, compruebe permisos y contexto antes de asumir que el producto carece de esa función. No intente resolver un rechazo cambiando rutas o invocando directamente un endpoint administrativo.

Las conexiones y API keys deben permanecer en los mecanismos previstos para ellas. Evite colocar credenciales en variables de ejemplo, archivos de muestra, capturas o notas de incidencias. Una clave personal permite identificar una automatización, pero no convierte a su propietario en administrador. Revise su uso y revóquela cuando deje de ser necesaria mediante Developer Tools.

Preparar una ejecución observable

Antes de ejecutar, revise las versiones publicadas de Mapping, Session y Workflow. Confirme bindings, rutas de salida, worker y capacidad. Si una tarea modifica un destino, determine cómo reconocer una ejecución repetida y qué efecto produciría volver a enviar los mismos datos. La idempotencia de una operación de infraestructura no implica que una transformación escribiendo en un sistema externo sea idempotente.

Registre el identificador del intento y consulte Monitor. Distinga cola, actividad y estado terminal. Conserve los overrides empleados y la evidencia relevante sin copiar valores sensibles. Cuando se genere un archivo, valide su contenido con una regla independiente: un estado satisfactorio indica que el proceso terminó según su contrato técnico, pero la comprobación de calidad de datos sigue siendo necesaria.

Diagnosticar antes de recuperar

Ante un fallo, identifique la tarea, su mensaje y el último estado conocido. Clasifique la causa: definición inválida, entrada no accesible, credencial o permiso, capacidad, dependencia o problema del proveedor. Estas categorías requieren respuestas distintas. Repetir la ejecución no corrige una ruta equivocada ni una autorización insuficiente.

Use las acciones de recuperación que la interfaz permita para ese estado. Cancel, Terminate, Rerun y Recover no deben tratarse como sinónimos. Revise el alcance mostrado y el estado del destino antes de repetir una operación que pudo producir efectos parciales. Si el resultado es ambiguo, conserve el identificador de ejecución y confirme el estado de los recursos afectados antes de iniciar otro intento.

Migrar referencias de un worker

En Cloud workers, diferencie la planificación del runtime y el estado de la VM. Drain evita asignaciones nuevas mientras termina el trabajo activo; deshabilitar la planificación no equivale a detener el proveedor. Revise ejecuciones activas y dependencias antes de retirar capacidad.

Use Reassign references para seleccionar origen, destino y referencias, revisar el plan y aplicar una reasignación válida. Los backups de dependencias ayudan a revisar o restaurar referencias conforme a los controles disponibles. Esta operación mueve metadatos de afinidad y dependencias; no copia archivos, discos, bases de datos ni credenciales externas. Valide que el destino pueda acceder a los recursos que necesitan las tareas migradas.

Prepare replacement abre la preparación de un nuevo worker utilizando el flujo existente. El worker anterior permanece hasta que se retire explícitamente. Compruebe compatibilidad, permisos, conectividad y capacidad del reemplazo antes de trasladar trabajo. La creación de infraestructura y la reasignación de referencias son etapas separadas, cada una con su evidencia.

Retirar sin perder el control del recurso

Abra el modal de deprovision y revise recursos cloud, referencias Dova, ejecuciones y bloqueos. Refresh impact obtiene el estado actualizado. Si el proveedor figura como Unavailable, eso no demuestra que la VM haya desaparecido. Restaure el acceso o investigue el fallo; no trate la falta de respuesta como autorización para limpiar un registro.

Cuando esté permitido, Stop and deprovision solicita una confirmación explícita que incluye ambas acciones. El flujo pide la detención, consulta un impacto fresco y sólo solicita eliminación si el servidor la permite. Una respuesta de detención puede indicar que el proveedor todavía está deteniéndose. En ese caso revise de nuevo el impacto más tarde; el flujo no elimina por suposición.

Si el proveedor falla, el registro se conserva para investigación y reintento. Cuando la ausencia de la VM está confirmada, el modal diferencia Clean up Dova record y explica que se limpiará únicamente el registro activo. Revise posteriormente inventario y Audit. Finalice la intervención documentando qué se confirmó, qué permanece pendiente y quién debe resolverlo; no describa una solicitud enviada como una retirada completada.