Cómo crear infraestructura de autoservicio con gobernanza y aprobaciones

Las organizaciones pueden crear infraestructura de autoservicio permitiendo que los usuarios soliciten tipos de recursos y parámetros de servicio aprobados, mientras la plataforma aplica cuotas, permisos, reglas de aprobación, políticas de ejecución y auditoría. La fuente no define un producto formal llamado portal de autoservicio, pero sí ofrece los componentes operativos que este modelo necesita.

El autoservicio debe simplificar la solicitud manteniendo la gobernanza intacta. Los usuarios no necesitan conocer la tarjeta GPU física, el puerto del switch o el comando del servidor. Deben elegir un servicio o una especificación de recursos aprobada, y la plataforma decide si la solicitud está permitida y de qué forma se entrega.

¿Qué significa el autoservicio en las operaciones de infraestructura?

El autoservicio implica que un usuario puede solicitar o gestionar un servicio de infraestructura aprobado sin tener que esperar a que un operador ejecute cada paso rutinario a mano.

El modelo de programación de la fuente ya avanza en esta dirección. Los usuarios trabajan con especificaciones de recursos estándar mientras el planificador gestiona recursos físicos heterogéneos por debajo. El motor de flujos de trabajo admite aprobaciones dinámicas, las órdenes de trabajo aprobadas pueden activar la asignación de recursos o la automatización, y la capa de gobernanza controla roles, tenants, proyectos y permisos.

En conjunto, estas capacidades forman un patrón operativo de autoservicio: el usuario interactúa con la definición del servicio y la plataforma aplica las reglas de infraestructura.

¿Por qué los usuarios deben solicitar un servicio y no un dispositivo físico?

El usuario suele necesitar un resultado concreto, y el número de serie de un equipo carece de relevancia para él. Un desarrollador puede requerir ocho aceleradores compatibles, un perfil definido de CPU y memoria, capacidad de almacenamiento, una cuota de proyecto o un servicio de inferencia. No necesita saber qué servidor físico o tarjeta GPU cumplirá con esa solicitud.

La capa de programación de la fuente convierte recursos heterogéneos de GPU y NPU en especificaciones estándar, y esa abstracción es justo lo que da valor al autoservicio. El equipo de infraestructura retiene el control del grupo físico de recursos, y el usuario recibe un servicio de recursos listo para usar.

¿Qué debe permanecer oculto para el usuario del autoservicio?

Conviene ocultar cualquier detalle que el usuario no necesite para decidir o que introduzca riesgos operativos. Entre los ejemplos figuran credenciales de BMC, configuraciones en bruto de switches, comandos de firmware, redes de gestión sensibles, controles de encendido físico, administración global de tenants y scripts de automatización de alto riesgo.

El modelo de gobernanza de la fuente aplica el principio de privilegios mínimos y autorizaciones independientes para operaciones delicadas, y el autoservicio debe heredar ese límite. El usuario puede solicitar capacidad sin recibir automáticamente permisos para modificar la infraestructura que la suministra.

¿Qué debe contener el formulario de autoservicio?

El motor de flujos de trabajo de la fuente admite formularios configurables y aprobadores dinámicos, lo que permite que una solicitud de recursos recopile los parámetros necesarios para la asignación y la rendición de cuentas.

Entre los campos útiles se encuentran:

• Proyecto
• Tenant
• Especificación del recurso
• Cantidad
• Duración solicitada
• Prioridad
• Política apropiable o no apropiable
• Justificación empresarial
• Hora de inicio
• Hora de finalización
• Centro de costos donde se utiliza

Los campos exactos dependen del servicio, y la fuente no impone un formulario de solicitud universal. Lo importante es que la petición capture la información suficiente para cuotas, aprobaciones, asignación y auditoría.

¿Cómo deben proteger las cuotas a la plataforma?

La cuota debe comprobarse antes de aceptar la solicitud para su programación habitual. El diseño de programación de la fuente utiliza la cuota del tenant como una restricción estricta, lo que permite a la organización ofrecer autoservicio sin abrir la puerta a un consumo ilimitado.

Un usuario puede estar autorizado para pedir recursos GPU dentro del Proyecto A, y dicho proyecto puede conservar una cuota sobre el recuento de GPU, memoria de aceleradores, tareas simultáneas y horas de tarjeta mensuales, de acuerdo con la política corporativa.

Si la solicitud supera la cuota disponible, la plataforma debe mostrar el motivo con claridad para que el usuario no necesite recurrir a un ingeniero de infraestructura para averiguar qué ocurrió.

¿Cómo deben funcionar los permisos?

Los permisos determinan quién puede solicitar, aprobar, ver u operar cada servicio. La capa de gobernanza de la fuente contempla organización, rol, matriz de permisos, pertenencia a tenants, pertenencia a proyectos y privilegios mínimos.

Eso permite estructurar distintos roles de autoservicio. Un usuario de proyecto puede enviar peticiones, el responsable de un proyecto puede aprobar ciertas solicitudes, un operador de infraestructura gestiona el grupo de recursos y un administrador de la plataforma define las políticas globales. La nomenclatura exacta de los roles depende de cada empresa. El principio operativo radica en que las acciones de autoservicio permanezcan dentro del ámbito autorizado del usuario.

¿Cómo deben diseñarse las aprobaciones?

Conviene recurrir a aprobaciones solo allí donde aporten un control real. El motor de flujos de trabajo de la fuente admite aprobadores dinámicos, aprobaciones multinivel, tiempos límite, escalamiento y ejecución automatizada tras el visto bueno, lo que permite tramitar peticiones con mínima intervención manual sin perder el control.

Por ejemplo, una solicitud pequeña dentro de la cuota puede aprobarse de forma automática por política. Una petición de mayor envergadura puede requerir al responsable del proyecto, un pedido de coste elevado puede exigir un gerente adicional y un cambio en la infraestructura de producción puede necesitar la aprobación independiente del equipo de operaciones.

La fuente no fija estos umbrales específicos. Cada empresa debe hacer coincidir la profundidad de aprobación con el nivel de riesgo y coste.

¿Por qué la aprobación debe activar la ejecución automáticamente?

Volver a introducir a mano una solicitud ya aprobada recrea el trabajo que el autoservicio pretendía eliminar. El modelo de flujo de trabajo de la fuente admite explícitamente nodos de ejecución tras la aprobación, de forma que el formulario aprobado sirve directamente de entrada para la asignación o la automatización.

El usuario solicita la especificación de recurso aprobada, el aprobador revisa la petición exacta, el flujo de trabajo la valida, el planificador asigna el recurso y el resultado se registra en el sistema. Esta cadena de control es mucho más limpia que abrir un ticket, aguardar la aprobación, esperar a un operador y ver cómo ese operador copia los datos en otra consola.

¿Cómo encaja el aprovisionamiento bare metal en el autoservicio?

El modelo de entrega bare metal de la fuente automatiza la instalación del sistema operativo, los controladores, el monitoreo y el registro en el clúster, lo que puede convertirse en uno de los servicios ofrecidos mediante un flujo de solicitudes controlado.

El usuario pide un perfil bare metal aprobado. La plataforma comprueba el servidor físico, el flujo de trabajo aprovisiona la imagen y la pila de software autorizadas, y tanto el inventario como el monitoreo se actualizan de forma automática. Es un claro ejemplo de autoservicio, ya que el usuario recibe un entorno completamente desplegado en lugar de iniciar un proyecto manual de infraestructura.

En cuanto a la cadena de entrega, el artículo sobre cómo funciona el aprovisionamiento bare metal automatizado para servidores físicos, sistemas operativos, controladores GPU y agentes de monitoreo explica los pasos respaldados por la fuente.

¿Cómo encaja la asignación de GPU en el autoservicio?

El catálogo de recursos debe mostrar especificaciones estándar de GPU en lugar de detallar cada dispositivo físico. El planificador de la fuente ya soporta grupos heterogéneos, especificaciones estandarizadas, cuotas, prioridades, apropiación, recursos de tarjeta completa o fraccionada y asignación consciente del estado de salud del hardware.

El usuario escoge la especificación aprobada y la plataforma localiza recursos compatibles y en buen estado. Así, el autoservicio escala sobre hardware mixto sin obligar a los usuarios a conocer las particularidades de cada fabricante de aceleradores.

¿Cómo encajan los servicios de modelos en el autoservicio?

La capa MaaS de la fuente utiliza repositorios de modelos, plantillas de despliegue, instancias de inferencia y publicación en API gateway, lo que da lugar a otro patrón de autoservicio. Un usuario autorizado puede seleccionar un modelo aprobado, una plantilla de despliegue autorizada, una especificación de recursos, un proyecto y los parámetros del servicio.

La plataforma puede crear la instancia de inferencia y publicar el servicio bajo los controles habituales de gobernanza, ahorrando al usuario la tarea de construir todo el despliegue a mano.

Para conocer la cadena de servicios de modelos, el artículo sobre qué es MaaS y cómo funcionan juntos los repositorios de modelos, instancias de inferencia, API gateways y medición de tokens explica la conexión entre estos componentes.

¿Cómo afecta la visibilidad de costes al autoservicio?

Los usuarios deben contar con suficiente visibilidad sobre costes o consumo para formular mejores solicitudes. La plataforma de la fuente registra horas de tarjeta, uso de tokens, tasa de inactividad, coste por proyecto y coste por tenant, por lo que el formulario de autoservicio o la vista del proyecto pueden reflejar el impacto de la especificación solicitada.

La fuente no exige una función de estimación de costes al momento de pedir el recurso, pero este mismo modelo de medición puede aportar contexto histórico sobre costes unitarios. El autoservicio no debe ocultar el impacto financiero de una infraestructura costosa.

¿Cómo debe mostrarse el estado de la cola?

Si el recurso solicitado no puede iniciarse de inmediato, el usuario debe saber por qué. El planificador de la fuente hace visibles los motivos de espera en cola, entre los que se incluyen límites de cuota, falta de disponibilidad de la especificación, exclusión por estado de salud, prioridad, topología o fragmentación.

Esto resulta clave en el autoservicio. Sin una explicación clara, los usuarios abren tickets preguntando por qué su solicitud no arranca, mientras que un motivo transparente reduce esa carga operativa.

¿Cómo deben separarse las acciones sensibles?

Solicitar un recurso y modificar la infraestructura exigen niveles de privilegio diferentes. Un usuario puede tener permiso para pedir un recurso sin estar autorizado a actualizar firmware, alterar la configuración de red, cerrar una válvula de refrigeración, cambiar cuotas globales o editar los recursos de otro tenant.

Las capas de gobernanza y automatización de la fuente emplean autorizaciones independientes para operaciones sensibles. Conviene mantener esa separación, de modo que el autoservicio amplíe el acceso a servicios aprobados mientras los privilegios administrativos permanecen estrictamente resguardados.

¿Cómo debe auditarse el proceso?

Toda solicitud de autoservicio debe conservar su trazabilidad. Una cadena de auditoría respaldada por la fuente abarca solicitante, tenant, proyecto, servicio solicitado, parámetros, decisión sobre la cuota, aprobador, identidad de ejecución, recurso asignado, resultado y registro de coste o consumo.

Los registros de operaciones de la fuente también guardan los valores anteriores y posteriores a cada modificación, lo que permite contar con un entorno de autoservicio altamente automatizado y plenamente auditable.

¿Qué deberían implementar primero las empresas?

Conviene empezar con un número reducido de solicitudes repetitivas y de gran volumen. Buenos candidatos respaldados por la fuente incluyen peticiones de recursos GPU, entrega bare metal, ajustes de cuota, despliegue de servicios de inferencia y solicitudes de acceso a proyectos.

Para cada uno de ellos, estandariza los parámetros, define cuotas y aprobaciones, conecta el flujo de trabajo con la ejecución y registra el resultado.

Un ejemplo de plataforma que reúne estas piezas de solicitud, cuotas, flujos de trabajo, programación y gobernanza es Sensaka.

Si tuviera que construir infraestructura de autoservicio, no empezaría entregando más consolas a los usuarios. Convertiría los cinco tickets de infraestructura más frecuentes en solicitudes de servicio aprobadas con parámetros claros, control de cuotas, ejecución automática y auditoría. Eso reduce los tiempos de espera sin debilitar el control.