Gestión de cambios: aprobar según el nivel de riesgo
Operaciones de TI · 4 min
Artículos de Luís Carvalho
Tratar todos los cambios de la misma forma genera colas y lotes mayores. Descubra cómo clasificar los cambios por riesgo, preautorizar los repetitivos y generar evidencia sin depender de una reunión semanal.

TL;DR
- Un circuito único de aprobación puede crear retrasos innecesarios al tratar de la misma forma cambios con riesgos diferentes.
- La investigación DORA sobre DevOps asocia procesos de aprobación más ligeros, revisión por pares y automatización con mejores resultados en la entrega de software.
- Distinguir entre cambios estándar, normales y de emergencia permite concentrar el análisis humano donde el riesgo es mayor.
- Los registros de aprobación, pruebas e implementación pueden ser generados por el propio flujo de trabajo, respetando los requisitos de control y segregación de funciones.
- La transición exige un inventario fiable, pruebas, mecanismos de reversión y revisión continua de los resultados.
El comité de cambios se ha convertido en un punto de espera
En muchas organizaciones, cualquier cambio en la infraestructura o en las aplicaciones recorre el mismo circuito: solicitud formal, reunión semanal de un comité de aprobación (CAB, Change Advisory Board) y ventana de implementación definida. El modelo busca proteger los sistemas en producción, pero no todos los cambios presentan el mismo nivel de riesgo. La renovación de un certificado, un cambio de configuración previamente probado y la migración de una base de datos crítica pueden requerir procedimientos de evaluación y aprobación diferentes. Cuando todos siguen el mismo circuito, se acumulan solicitudes, aumenta el tiempo de espera y pueden aparecer implementaciones agrupadas en lotes mayores. Para quien gestiona operaciones de TI, el reto es adecuar los controles a la criticidad y al impacto de cada cambio, sin comprometer la trazabilidad.
Más aprobación formal no significa menos fallos
El programa de investigación DORA (DevOps Research and Assessment), que no debe confundirse con el reglamento europeo de resiliencia operativa digital, analizó esta relación en el informe State of DevOps de 2019. La investigación identificó efectos negativos de los procesos pesados de aprobación externa en el rendimiento de la entrega de software, sin demostrar que estos se tradujeran en una menor tasa de fallos de los cambios. Como alternativa, recomienda acercar la revisión a los equipos que ejecutan el trabajo, recurriendo a la revisión por pares y a la automatización de pruebas, verificaciones y monitorización. Estas conclusiones no significan que los comités de cambios sean prescindibles: siguen siendo útiles para la coordinación entre equipos, la comunicación y las decisiones que exigen una evaluación del impacto en el negocio. La aplicación de estas prácticas a los cambios de infraestructura debe tener en cuenta el riesgo y los requisitos de control de cada organización.
Clasificar los cambios por riesgo antes de aprobarlos
Un enfoque habitual consiste en distinguir tres tipos de cambio. Los cambios estándar son repetitivos, de bajo riesgo y están bien documentados, como determinadas configuraciones previamente probadas, y pueden ser preautorizados siempre que sigan un procedimiento aprobado y queden registrados. Los cambios normales requieren una evaluación y una autorización proporcionales al riesgo, idealmente por parte de quien conoce los sistemas y sus dependencias. Los cambios de emergencia siguen un circuito acelerado, con las autorizaciones y la revisión posterior previstas en el procedimiento aplicable. Los criterios de clasificación deben ser explícitos y tener en cuenta los servicios afectados, la facilidad de reversión, la exposición de datos sensibles y el historial de fallos. Una CMDB actualizada ayuda a identificar otros sistemas que pueden verse afectados por un cambio aparentemente aislado.
La evidencia puede ser generada por el propio proceso
Una de las razones para mantener procesos formales de aprobación es la necesidad de demostrar control ante auditores, clientes o entidades reguladoras. La investigación DORA indica que la revisión por pares, apoyada en la automatización, puede contribuir a un proceso de entrega fiable, sin depender exclusivamente de aprobaciones externas. En la práctica, cada cambio debe quedar asociado a una solicitud, a la identificación del responsable, a las autorizaciones aplicables, a los resultados de las pruebas y al registro de la implementación. Las plataformas de gestión de servicios, las herramientas de automatización y los mecanismos de infraestructura como código pueden producir parte de esta evidencia de forma automática, siempre que los registros sean fiables y los accesos estén debidamente controlados. Cuando parte de la operación está en manos de terceros, por ejemplo en un contrato de gestión de infraestructura, los cambios ejecutados por el proveedor deben integrarse en el proceso de gestión de cambios acordado con el cliente. Los requisitos concretos de evidencia y segregación de funciones deben validarse de acuerdo con las obligaciones aplicables.
Medir la espera y el resultado de cada cambio
La investigación DORA recomienda analizar la proporción de cambios que requieren aprobación manual antes de su entrada en producción, distinguiéndolos por perfil de riesgo, así como el tiempo de espera asociado a las aprobaciones externas. Estos indicadores deben analizarse junto con la frecuencia de cambios que originan incidentes, la necesidad de reversiones y el tiempo de recuperación. Si los cambios de bajo riesgo esperan varios días por una aprobación, sin que el proceso aporte un valor proporcional, puede haber margen para simplificar. Por otro lado, si una categoría presenta fallos frecuentes, la respuesta puede pasar por reforzar las pruebas, mejorar los procedimientos de implementación o revisar los mecanismos de reversión, en lugar de añadir automáticamente un nivel más de aprobación. Una buena observabilidad de los servicios permite detectar rápidamente degradaciones tras un cambio y respaldar decisiones de reversión basadas en datos.
Un proceso proporcional exige disciplina y revisión continua
Aprobar los cambios de acuerdo con el nivel de riesgo puede ayudar a reducir los tiempos de espera, evitar implementaciones agrupadas en lotes mayores y concentrar la atención humana en las decisiones de mayor impacto. Sin embargo, la transición depende de condiciones que no todas las organizaciones reúnen de partida: inventario fiable, procedimientos documentados, pruebas adecuadas, mecanismos de reversión y registros consistentes. Sin estas bases, la preautorización de cambios puede limitarse a trasladar el riesgo a la operación. Una evolución gradual, comenzando por los cambios más repetitivos y revisando periódicamente su clasificación en función de los resultados, tiende a ser más prudente que reformular todo el proceso de una sola vez. El equilibrio entre agilidad, seguridad y control debe evaluarse caso por caso, en función de la criticidad de los servicios, de las responsabilidades contractuales y de las obligaciones aplicables.
Relacionado
- Cómo Observability y AIOps ayudan a acelerar la respuesta a incidentes
- SOC/NOC gestionado para PYMES: una alternativa a la operación interna 24/7
- Hostelería y restauración: gestionar accesos de TI del personal de temporada
- CMDB: gestionar dependencias antes del incidente