Biblioteca / Gobernanza Enterprise
Administracion y Gobernanza de Operaciones Tecnologicas Enterprise
Modelo operativo completo: politicas control de cambios auditoria cloud marcos de cumplimiento y gestion del conocimiento.
Tabla de contenido
Capitulo 1
El modelo operativo tecnologico enterprise
Un modelo operativo tecnologico define como una organizacion gestiona entrega y evoluciona sus capacidades tecnologicas. Sin un modelo explicito las organizaciones operan por inercia.
Las cuatro dimensiones
| Dimension | Que define | Sintomas de fallo | Solucion |
|---|---|---|---|
| Personas | Roles responsabilidades y cultura | Todo depende de una persona clave | RACI claro documentacion cross-training |
| Procesos | Como se toman decisiones y ejecutan cambios | Reuniones sin conclusiones; incidentes sin proceso | Runbooks politicas documentadas y seguidas |
| Tecnologia | Que herramientas se usan y como se integran | Herramientas duplicadas datos en silos | Stack tecnologico definido y estandar |
| Datos | Que metricas se miden y como se usan para decidir | Decisiones por intuicion sin visibilidad de costos | KPIs dashboards cultura data-driven |
Herramienta de diagnostico de madurez
Evalua cada area de 1 (caotico) a 5 (optimizado) y promedia el resultado:
| Area a evaluar | Puntuacion 1-5 |
|---|---|
| Tienes documentado quien decide que en TI? | |
| Existe proceso formal de control de cambios en produccion? | |
| Hay runbooks para los 5 incidentes mas frecuentes? | |
| Se miden y reportan KPIs de TI mensualmente a direccion? | |
| Existe politica de backup verificada con pruebas regulares? | |
| Los nuevos ingresos pueden ser productivos en 48h? | |
| Existe un registro de riesgos tecnologicos actualizado? | |
| Hay proceso documentado de gestion de proveedores? |
1-2: prioridad urgente. 2-3: en proceso continua. 3-4: buen nivel refina. 4-5: excelente comparte tu modelo.
Capitulo 2
Diseno y ciclo de vida de politicas operativas
Las politicas operativas son el contrato interno de la organizacion sobre como se trabaja. Sin ellas cada situacion nueva requiere una decision desde cero.
Anatomia de una politica efectiva
| Componente | Descripcion | Ejemplo |
|---|---|---|
| Identificador | Codigo unico de la politica | POL-OPS-003 |
| Titulo | Nombre descriptivo y claro | Control de Cambios en Produccion |
| Proposito | Por que existe en 2-3 frases | Prevenir interrupciones por cambios no controlados |
| Alcance | A quien y que aplica | Todo el equipo TI sistemas de produccion y staging |
| Declaracion | Las reglas concretas | Todo cambio requiere aprobacion previa del CAB |
| Excepciones | Casos fuera de la norma | P1 puede ejecutar con aprobacion post-hoc del CTO |
| Responsabilidades | Quien hace que | IT Manager aprueba DevOps ejecuta Seguridad revisa |
| Revision | Cuando se revisa y expira | Semestral proxima noviembre 2026 |
Plantilla de politica en Markdown
# POL-OPS-003: Control de Cambios en Produccion Version: 2.1 | Fecha: Mayo 2026 | Estado: Vigente Propietario: IT Manager | Aprobador: CTO ## Proposito Garantizar que todos los cambios en produccion sean planificados, revisados, aprobados y documentados para minimizar interrupciones. ## Alcance Todos los cambios en sistemas de produccion y staging: codigo, infraestructura, configuraciones y bases de datos. ## Tipos de cambio | Tipo | Definicion | Aprobacion | |------------|------------------------------|-----------------| | Estandar | Bajo riesgo conocido | Pre-aprobada | | Normal | Requiere analisis de impacto | CAB semanal | | Emergencia | Respuesta a P1 o P2 activo | CTO post-hoc | ## Proceso normal 1. RFC con 48h de antelacion minima 2. Revision del equipo 3. Aprobacion en CAB semanal 4. Ejecucion en ventana acordada 5. Confirmacion y documentacion del resultado ## Revision Semestral. Proxima: noviembre 2026.
Capitulo 3
Gestion de incidentes y continuidad operativa
La calidad de la respuesta a un incidente determina el impacto final en clientes reputacion y operacion. La preparacion es la unica variable que puedes controlar.
Proceso de gestion de incidentes
| Fase | Actividades | Responsable | Tiempo objetivo |
|---|---|---|---|
| Deteccion | Alerta de monitoreo o reporte de usuario | Sistema automatizado | menor 2 min |
| Registro | Crear ticket con timestamp y sintomas | On-call engineer | menor 5 min |
| Clasificacion | Determinar P1-P4 con arbol de decision | On-call engineer | menor 10 min |
| Escalamiento | Notificar segun clasificacion | On-call engineer | menor 15 min P1 P2 |
| Diagnostico | Identificar causa raiz | Equipo tecnico | Segun complejidad |
| Resolucion | Implementar la correccion | Equipo tecnico | Segun RTO del servicio |
| Comunicacion | Actualizar stakeholders cada 30 min en P1 P2 | IT Manager | Durante el incidente |
| Post-mortem | Analisis de causa raiz y plan de mejora | Todo el equipo | Dentro de 48h |
Plantilla de post-mortem sin culpas
# Post-Mortem: [Titulo del incidente] Fecha: | Duracion: | Severidad: | Autor: ## Resumen ejecutivo (2 parrafos) Que ocurrio, cuando, impacto en usuarios y negocio. ## Cronologia | Timestamp UTC | Evento | |---------------|--------| | 14:03 | Primera alerta de CloudWatch | | 14:07 | On-call confirmo degradacion | | 14:52 | Causa raiz identificada | | 15:31 | Servicio restaurado al 100% | ## Causa raiz Descripcion tecnica precisa de que fallo y por que. ## Impacto Usuarios afectados: X | Duracion: Y min | Costo: $Z ## Plan de accion | Accion | Responsable | Fecha limite | Estado | |--------|-------------|--------------|--------| | Agregar alerta X | DevOps | 2026-06-01 | Pendiente |
Los post-mortems sin culpas son mas efectivos. Un equipo que teme el post-mortem oculta informacion. Un equipo que aprende de el se vuelve mas resiliente con cada incidente.
Capitulo 4
Control de cambios en entornos productivos
El control de cambios protege la estabilidad del servicio sin paralizar al equipo. La clave es hacerlo lo suficientemente liviano para que el equipo lo adopte voluntariamente.
GitOps como mecanismo de control de cambios
| Concepto tradicional | Equivalente GitOps |
|---|---|
| RFC Request for Change | Pull Request con descripcion del cambio |
| Revision del CAB | Code Review en el PR por el equipo |
| Aprobacion del cambio | Merge del PR tras aprobacion de revisores |
| Ejecucion del cambio | Pipeline CI/CD ejecutado automaticamente |
| Registro de cambios | Historial de commits en git |
| Auditoria | git blame y git log con autor y timestamp |
Ventanas de mantenimiento
- Produccion: martes y jueves de 22:00 a 23:30 UTC
- Staging: cualquier dia habil de 14:00 a 17:00 UTC
- Emergencias: cualquier momento con aprobacion de CTO documentada
- Freeze de cambios: 24 diciembre al 2 enero excepto P1 y P2
Notifica los cambios programados con 24h de anticipacion en Slack: que cambia cuando cuanto dura y quien es el punto de contacto. Esto elimina el 80% de la friccion interna.
Capitulo 5
Auditoria digital automatizada en cloud
La auditoria continua reemplaza a la auditoria anual puntual. Con las herramientas correctas conoces el estado de cumplimiento en tiempo real.
Herramientas de auditoria cloud
| Herramienta | Que audita | Salida | Frecuencia |
|---|---|---|---|
| AWS Config | Configuracion de recursos AWS | Dashboard y alertas | Continuo |
| AWS Security Hub | Hallazgos de seguridad consolidados | Dashboard y SIEM | Continuo |
| Prowler | Mas de 500 controles de seguridad AWS | HTML CSV JSON | Semanal |
| CloudTrail + Athena | Historial completo de API calls | SQL queries | Por incidente |
| terraform plan | Drift entre codigo y estado real | CLI output | Antes de cada deploy |
| ScoutSuite | Postura de seguridad multi-cloud | HTML interactivo | Mensual |
Activacion rapida de Security Hub
# Activar Security Hub
aws securityhub enable-security-hub \
--enable-default-standards \
--region us-east-1
# Ver findings criticos activos
aws securityhub get-findings \
--filters '{
"RecordState":[{"Value":"ACTIVE","Comparison":"EQUALS"}],
"SeverityLabel":[{"Value":"CRITICAL","Comparison":"EQUALS"}]
}' \
--query 'Findings[].{Title:Title,Resource:Resources[0].Id}' \
--output table
# Escaneo completo con Prowler
docker run -ti --rm \
-e AWS_ACCESS_KEY_ID -e AWS_SECRET_ACCESS_KEY \
prowler/prowler:latest aws \
--output-formats html,csv \
--output-directory /tmp/prowlerCapitulo 6
Marcos de cumplimiento normativo en cloud
El cumplimiento no es un destino; es un estado continuo que se mantiene con procesos automatizados y revisiones periodicas.
Mapa de controles cruzados
| Control implementado | ISO 27001 | SOC 2 | NIST CSF | ISO 20000 |
|---|---|---|---|---|
| Gestion de accesos IAM con MFA | A.5.17 | CC6.1 | PR.AC-7 | 7.2 |
| Logging centralizado e inmutable | A.8.15 | CC7.2 | DE.AE-3 | 8.2 |
| Control de cambios documentado | A.8.32 | CC8.1 | PR.IP-3 | 9.2 |
| Backup verificado con pruebas | A.8.13 | A1.2 | PR.DS-1 | 10.1 |
| Gestion de vulnerabilidades | A.8.8 | CC7.1 | ID.RA-1 | 8.3 |
| Gestion de proveedores | A.5.19 | CC9.2 | ID.SC-2 | 7.3 |
Hoja de ruta de certificacion ISO 27001 en 12 meses
| Mes | Actividad | Entregable |
|---|---|---|
| 1-2 | Gap analysis estado actual vs requisitos ISO | Informe de brechas priorizado |
| 3-4 | Implementar controles criticos faltantes | Controles documentados y operativos |
| 5-6 | Documentar SGSI alcance politica y SoA | Documentacion del sistema de gestion |
| 7-8 | Auditoria interna simular la certificacion | Informe de auditoria interna |
| 9 | Remediar hallazgos de la auditoria interna | Plan de acciones correctivas cerrado |
| 10-12 | Auditoria de certificacion Stage 1 y 2 | Certificado ISO 27001:2022 |
Una certificacion ISO 27001 para PYME de 10-50 personas cuesta entre 15000 y 40000 USD con consultora. Sin consultora entre 5000 y 15000 USD con documentacion de calidad.
Capitulo 7
Tableros de mando y reporting operativo
El reporting transforma datos tecnicos en decisiones de negocio. Un informe bien estructurado es tan valioso como cualquier otro entregable tecnico.
Los tres niveles de reporting
| Nivel | Audiencia | Frecuencia | Contenido | Lectura |
|---|---|---|---|---|
| Operativo | Equipo tecnico | Diario o semanal | Metricas incidentes activos y deploys | 5 min |
| Tactico | IT Manager y Tech Leads | Semanal o mensual | KPIs por area avance de proyectos y riesgos | 15 min |
| Estrategico | CTO CEO y Direccion | Mensual o trimestral | Estado del negocio tech inversion y roadmap | 30 min |
Plantilla de informe mensual
# Informe Mensual de TI - Mayo 2026 Preparado por: [Nombre] | Fecha: [fecha] ## Estado general VERDE Operaciones: NORMAL | AMARILLO Seguridad: ATENCION ## KPIs del mes | Metrica | Objetivo | Real | vs Anterior | |-------------------|-----------|-------|-------------| | Uptime servicios | >=99.5% | 99.7% | +0.2% | | MTTR incidentes | <=4h | 2.3h | -0.8h | | Frecuencia deploy | >=2/semana| 3.2 | +0.4 | | Cobertura backup | 100% | 100% | sin cambio | ## Top 3 logros 1. Tiempo de deploy reducido de 45 a 12 minutos 2. MFA implementado para todos los usuarios cloud 3. 10 runbooks criticos documentados ## Riesgos activos | ID | Riesgo | Estado | |-----|------------------|-------------| | R02 | IAM sin revision | En progreso | ## Proximo mes 1. Remediar IAM - Kevin - 15 junio 2. Prueba DR trimestral - Equipo Ops - 20 junio
Capitulo 8
Gestion del conocimiento y documentacion tecnica
La documentacion no es un lujo; es infraestructura. Un equipo sin documentacion tiene bus factor de 1.
Tipos de documentacion y su proposito
| Tipo | Pregunta que responde | Cuando actualizar |
|---|---|---|
| Runbook | Como ejecuto esta tarea paso a paso? | Ante cada cambio en el proceso |
| ADR Architecture Decision Record | Por que tomamos esta decision tecnica? | Al tomar cada decision arquitectonica |
| Diagrama de arquitectura | Como estan conectados los sistemas? | Ante cambios de arquitectura |
| Playbook de incidentes | Que hago cuando X falla? | Tras cada post-mortem con gaps |
| Guia de onboarding | Como soy productivo en 48h como nuevo ingreso? | Trimestral |
Architecture Decision Record ADR
# ADR-042: Usar Terraform para infraestructura AWS Estado: Aceptado | Fecha: 2026-03-15 Decisores: CTO, Architect, DevOps Lead ## Contexto Necesitamos gestionar infraestructura cloud de forma reproducible. Actualmente se usa la consola AWS generando inconsistencias entre entornos. ## Decision Adoptaremos Terraform como herramienta de IaC para toda la infraestructura AWS nueva. La infraestructura existente se migrara progresivamente durante Q2 2026. ## Alternativas consideradas - AWS CloudFormation: descartado por sintaxis verbosa y menor flexibilidad. - Pulumi: descartado por menor madurez del ecosistema. ## Consecuencias positivas - Infraestructura reproducible entre todos los entornos - Historial de cambios en git con revision via PR - Tiempo de aprovisionamiento reducido a minutos ## Consecuencias negativas - Curva de aprendizaje inicial de 2-3 semanas por persona
Prueba simple: puede un nuevo ingreso ser productivo en 48h sin preguntar constantemente? Si la respuesta es no la documentacion es insuficiente.
Capitulo 9
Implementacion hoja de ruta y apendices
La implementacion de este framework es un proyecto con fases claras. No intentes implementarlo todo a la vez; el cambio organizacional necesita tiempo.
Plan de 90 dias - quick wins
| Semana | Foco | Entregable concreto |
|---|---|---|
| 1-2 | Diagnostico y priorizacion | Evaluacion de madurez completada; top 5 brechas identificadas |
| 3-4 | RACI y roles | RACI de 20 funciones clave; roles documentados |
| 5-6 | Politicas criticas | 3 politicas redactadas aprobadas y comunicadas |
| 7-8 | Control de cambios | Proceso activo; primeras RFC registradas |
| 9-10 | KPIs y dashboard | Dashboard con 6 KPIs; primer informe mensual |
| 11-12 | Revision y ajuste | Segunda evaluacion de madurez; plan Q2 definido |
Herramientas recomendadas por area
| Area | Herramienta | Alternativa | Costo |
|---|---|---|---|
| Documentacion tecnica | Notion / Confluence | GitHub Wiki | 0-10 USD por usuario |
| Gestion de incidentes | PagerDuty / OpsGenie | Slack mas runbooks | 0-20 USD por usuario |
| Control de cambios | GitHub / GitLab | Jira mas Confluence | 0-15 USD por usuario |
| KPIs y dashboards | Grafana mas CloudWatch | Power BI / Looker | 0-9 USD por usuario |
| Auditoria cloud | Prowler mas Security Hub | CloudSploit | 0-500 USD por mes |
La gobernanza tecnologica no es un proyecto que termina; es una practica que madura. Cada trimestre que implementas consistentemente estos procesos el equipo se vuelve mas eficiente y la organizacion mas preparada para crecer.