Una organización puede enseñar a desplegar aplicaciones en la nube y, aun así, dejar fuera las decisiones que determinan si ese despliegue será repetible, observable y recuperable. El problema aparece cuando Cloud, DevOps, AIOps y Platform Engineering se presentan como herramientas separadas, en lugar de estudiarse como partes de un mismo flujo operativo.
Para empresas de capacitación, consultoras e instructores, la oportunidad consiste en convertir ese flujo en competencias enseñables y evaluables: aprovisionar recursos, automatizar cambios, interpretar telemetría, responder a incidentes y diseñar servicios internos de autoservicio. El análisis siguiente conecta los conceptos técnicos con situaciones que pueden incorporarse a cursos, laboratorios y evaluaciones prácticas.
Prueba la emisión durante 3 meses
Con el plan Free del Instituto Internacional de Ingeniería (3i), una organización puede probar durante 3 meses la emisión de hasta 5 certificados y 5 insignias verificables, y revisar si la plataforma se adapta a su proceso de formación.
Qué aporta cada disciplina
Cloud ofrece acceso bajo demanda a recursos configurables que pueden aprovisionarse y liberarse con poca intervención del proveedor. La definición de computación en la nube de NIST SP 800-145 establece cinco características esenciales, además de modelos de servicio y despliegue. Para una organización formadora, esto permite evaluar si el participante distingue elasticidad, autoservicio y servicio medido de una simple infraestructura alojada fuera de las instalaciones.
DevOps abarca procesos para definir, controlar y mejorar el ciclo de vida del software mediante colaboración entre desarrollo, operaciones y otras partes interesadas. La norma ISO/IEC/IEEE 32675:2022 sobre DevOps sitúa esa colaboración dentro de la construcción, el empaquetado y el despliegue seguro y confiable. Por eso, una evaluación debería revisar prácticas y decisiones, no únicamente el uso de una herramienta de integración continua.
AIOps reúne técnicas de inteligencia artificial y análisis de datos aplicadas a problemas de operación de TI. El estudio revisado por pares A Systematic Mapping Study in AIOps organiza contribuciones según algoritmos, fuentes de datos y componentes objetivo, e identifica tareas relacionadas con fallas, como detección de anomalías y análisis de causa raíz. No presenta una definición normativa única, pero sí un marco útil para delimitar el campo.
Platform Engineering planifica y proporciona plataformas internas que reúnen capacidades, políticas, procesos y experiencias para usuarios como equipos de producto y aplicaciones. El CNCF Platforms White Paper describe plataformas integradas que ofrecen portales, plantillas o API de autoservicio según las necesidades de sus usuarios. La competencia formativa consiste en diseñar una experiencia coherente, no en memorizar un catálogo de herramientas.
Cómo se conectan en el ciclo
La relación se entiende mejor mediante una secuencia. Un participante solicita un entorno desde un portal interno; la plataforma aplica una plantilla aprobada, crea recursos en la nube y configura controles básicos. Luego, un pipeline compila, prueba y despliega el cambio. La aplicación genera telemetría y, cuando aparecen señales anómalas, un proceso de AIOps puede agrupar eventos relacionados para orientar la investigación del incidente.
Este escenario permite evaluar más que la ejecución técnica. El alumno puede justificar qué datos necesita cada etapa, identificar quién aprueba una excepción, explicar cuándo debe detenerse una automatización y proponer evidencias para comprobar el resultado. El instructor observa así si la persona comprende el flujo completo y sus dependencias.
Las métricas de desempeño de entrega de software de DORA consideran cinco medidas: tiempo de entrega del cambio, frecuencia de despliegue, tiempo de recuperación de un despliegue fallido, tasa de fallos de cambios y tasa de retrabajo de despliegues. DORA las organiza en dos grupos conceptuales: flujo de entrega o throughput, e inestabilidad. Para interpretarlas con sentido, deben aplicarse a una aplicación o servicio concreto, observarse durante un periodo y no utilizarse para clasificar personas o equipos de manera aislada.
De telemetría a AIOps
AIOps depende de telemetría consistente. La versión vigente en inglés de la documentación Signals de OpenTelemetry explica que el proyecto recopila, procesa y exporta señales que describen la actividad de sistemas operativos y aplicaciones. Entre las señales admitidas se encuentran trazas, métricas, logs y baggage, que aporta información contextual transmitida entre señales.
En un laboratorio, una métrica puede mostrar un aumento de latencia, una traza localizar el servicio donde se acumula la espera y un log registrar el error asociado. El ejercicio gana profundidad cuando el alumno debe correlacionar esas evidencias mediante identificadores, marcas de tiempo y contexto, en vez de limitarse a abrir un panel.
También conviene separar detección, diagnóstico y remediación. Agrupar alertas duplicadas exige un nivel de control distinto al de reiniciar un servicio o revertir una versión. Una evaluación puede pedir que se definan permisos, condiciones de ejecución, registro de acciones y un mecanismo para detener la automatización cuando la evidencia sea insuficiente.
La plataforma como producto interno
Una plataforma interna puede ofrecer una ruta para publicar una API que incluya repositorio, pipeline, análisis de seguridad, infraestructura, observabilidad y documentación. El equipo de producto conserva las decisiones sobre la lógica de su servicio, mientras la plataforma estandariza actividades repetidas y presenta opciones mediante interfaces consistentes.
Para enseñarla como producto, el curso debe partir de usuarios y necesidades. Los participantes pueden entrevistar a un equipo ficticio, identificar solicitudes frecuentes, diseñar una plantilla y definir qué excepciones permanecerán fuera de la ruta recomendada. Si cada solicitud termina en un ticket manual, el autoservicio es incompleto; si toda excepción está prohibida, la plataforma puede bloquear requisitos legítimos.
Competencias para una adopción real
Un programa formativo sólido combina conocimientos técnicos con criterios operativos. Las organizaciones e instructores pueden estructurar sus evaluaciones alrededor de cuatro capacidades observables:
Una rúbrica puede valorar la evidencia utilizada, la coherencia de la secuencia, el tratamiento de riesgos y la explicación del resultado. Así, la credencial documenta una capacidad aplicada a un escenario y no solo la asistencia a una clase o la repetición de definiciones.
Conclusión
La pregunta central no es qué tecnología debe enseñarse primero, sino si el programa permite comprender y demostrar un flujo operativo completo. La implicación práctica para una organización formadora es diseñar evaluaciones donde cada participante produzca evidencias verificables de sus decisiones, automatizaciones y respuestas ante un escenario definido.
Convierte competencias en credenciales verificables
Mantén tus cursos y la relación con tus alumnos mientras incorporas certificados con QR, enlace o código de validación para documentar competencias evaluadas en operaciones y plataformas digitales.
Fuentes consultadas
Peter Mell y Timothy Grance. The NIST Definition of Cloud Computing. 2011.
ISO, IEC e IEEE. ISO/IEC/IEEE 32675:2022 — Information technology — DevOps — Building reliable and secure systems including application build, package and deployment. 2022.
Paolo Notaro, Jorge Cardoso y Michael Gerndt. A Systematic Mapping Study in AIOps. 2021.
OpenTelemetry Authors. Signals. 2026.
CNCF Platforms Working Group. CNCF Platforms White Paper. 2023.
Nathen Harvey, DORA. DORA’s software delivery performance metrics. 2026.
