OP.PL.4 Dimensionamiento y Gestión de Capacidades
Documentos de referencia
- ISO/IEC 27000
- 27002:2013
- 12.1.3 - Gestión de capacidades
- 27002:2013
- NIST SP 800-53 rev.4
- [SA-2] Allocation of Resources
- [AU-4] Audit Storage Capacity
Definiciones
- EAL. Evaluation Assurance Level. Niveles de confianza en la evaluación.
- TOE. Target of Evaluation. Objetivo de evaluación.
Guía de implantación
-
Conviene destacar que esta medida de seguridad no es meramente técnica, sino que tiene implicaciones presupuestarias y por ello debe gestionarse con tiempo para que las necesidades queden debidamente recogidas en los presupuestos. Si en todas las medidas de seguridad hay que huir de la improvisación, en esta con mayor razón.
-
Nótese que en entornos flexibles como es el empleo de recursos en la nube, el dimensionado efectivo del sistema puede ser dinámico, adecuándose a las necesidades del servicio.
Implementación en Legit Health Plus
Marco de Dimensionamiento y Gestión de Capacidades
Estrategia de Capacity Management
Legit Health Plus implementa un enfoque proactivo de gestión de capacidades que abarca:
- Planificación de capacidad basada en proyecciones de crecimiento
- Monitorización continua de recursos y rendimiento
- Escalado automático en infraestructura cloud
- Optimización de costes mediante rightsizing
- Gestión de picos de demanda estacionales o excepcionales
- Planificación presupuestaria a medio y largo plazo
Modelo de Capacidad Multinivel
La gestión de capacidades se estructura en múltiples niveles:
Jerarquía del Modelo de Capacidad:
Nivel 1: Business Capacity
- Métricas: Usuarios, Transacciones comerciales
- ↓
Nivel 2: Service Capacity
- Métricas: API Calls, Imágenes Procesadas
- ↓
Nivel 3: Application Capacity
- Métricas: Instancias de Aplicación, Modelos ML
- ↓
Nivel 4: Infrastructure Capacity
- Métricas: Compute, Storage, Network
- ↓
Nivel 5: Resource Capacity
- Métricas: CPU, Memory, Disk
Dimensionamiento por Componentes
Infraestructura de Aplicación
Servicios Core - Dimensionamiento Actual:
| Componente | Configuración Actual | Capacidad Máxima | Utilización Target |
|---|---|---|---|
| API Gateway | 4x ECS Tasks (2 vCPU, 4GB) | 1000 req/sec | 70% CPU |
| ML Inference | 2x GPU instances (g4dn.xlarge) | 100 concurrent | 80% GPU |
| Image Processing | Auto-scaling 2-10 tasks | 500 images/min | 75% CPU |
| Auth Service | 2x ECS Tasks (1 vCPU, 2GB) | 200 auth/sec | 60% CPU |
| Background Jobs | 3x ECS Tasks (1 vCPU, 2GB) | 1000 jobs/hour | 70% CPU |
Infraestructura de Datos
Almacenamiento - Capacidad Planificada:
| Sistema | Configuración | Capacidad Actual | Proyección 12M | Crecimiento Anual |
|---|---|---|---|---|
| DocumentDB | 3-node cluster (r6g.large) | 1TB | 5TB | 400% |
| S3 Storage | Standard + IA tiers | 50TB | 200TB | 300% |
| Redis Cache | 2x r6g.large cluster | 32GB | 128GB | 300% |
| CloudWatch Logs | 30-day retention | 500GB/month | 2TB/month | 300% |
| Backup Storage | S3 Glacier Deep Archive | 100TB | 500TB | 400% |
Red y Conectividad
Ancho de Banda Planificado:
Planificación de Capacidad de Red:
| Componente | Capacidad Actual | Capacidad Proyectada | Notas |
|---|---|---|---|
| Internet Gateway | 10 Gbps | 50 Gbps | Bottleneck: Ráfagas de carga de imágenes |
| Tráfico Inter-AZ | 5 Gbps | 20 Gbps | Replicación BD, failover cross-AZ |
| Conexiones VPN | 2x 1 Gbps | 4x 10 Gbps | Integraciones con proveedores sanitarios |
| CDN (CloudFront) | Ilimitado | Ilimitado | Optimización: Estrategia caching regional |
Modelos de Demanda y Proyecciones
Patrones de Uso Identificados
Análisis de Demanda Histórica:
| Métrica | Q1 2024 | Q2 2024 | Q3 2024 | Q4 2024 | Proyección Q1 2025 |
|---|---|---|---|---|---|
| Usuarios Activos | 5,000 | 8,000 | 12,000 | 18,000 | 27,000 |
| Imágenes/Día | 10,000 | 16,000 | 24,000 | 36,000 | 54,000 |
| API Calls/Día | 100K | 160K | 240K | 360K | 540K |
| Storage (TB) | 15 | 25 | 38 | 55 | 85 |
| Concurrent Users | 200 | 320 | 480 | 720 | 1,080 |
Factores de Crecimiento
Drivers de Demanda:
- Expansión geográfica: +200% usuarios por nueva región
- Nuevas especialidades médicas: +50% por especialidad
- Integraciones con HIS/EHR: +300% API calls por integración
- Mejoras en algoritmos: +25% precisión → +40% retención
- Programas de screening: Picos estacionales +500%
Modelado Predictivo
Modelos de Forecasting:
Modelo de Predicción de Capacidad:
Parámetros Base:
- Crecimiento mensual base: 15%
Factores Estacionales:
| Trimestre | Factor | Descripción |
|---|---|---|
| Q1 | 1.2 | Temporada alta screening |
| Q2 | 0.9 | Temporada baja |
| Q3 | 1.0 | Normal |
| Q4 | 1.1 | Temporada conferencias |
Multiplicadores de Expansión:
| Evento | Multiplicador |
|---|---|
| Nueva región | 2.0x |
| Nueva especialidad | 1.5x |
| Cliente enterprise | 3.0x |
Intervalos de Confianza:
| Percentil | Cálculo |
|---|---|
| p50 | Proyección base |
| p80 | Proyección base × 1.4 |
| p95 | Proyección base × 1.8 |
Auto-scaling y Elasticidad
Políticas de Auto-scaling
ECS Auto-scaling Configuration:
Configuración de Auto-scaling para Servicios API:
Target Tracking (Escalado Basado en Objetivos):
- CPU: Mantener 70% utilización
- Memoria: Mantener 75% utilización
Step Scaling (Escalado por Pasos):
Scale Out (Aumentar Capacidad):
| Condición | Acción |
|---|---|
| RequestCount > 500/min | +2 tasks |
| RequestCount > 1000/min | +4 tasks |
Scale In (Reducir Capacidad):
| Condición | Acción |
|---|---|
| RequestCount < 200/min | -1 task (mínimo 2) |
Configuración de Auto-scaling para ML Inference:
Scheduled Scaling (Escalado Programado):
| Horario | Capacidad Mínima | Capacidad Máxima |
|---|---|---|
| Horas laborales | 4 instancias | 20 instancias |
| Fuera de horario | 2 instancias | 10 instancias |
Predictive Scaling (Escalado Predictivo):
- Estado: Activado
- Período de predicción: 7 días
- Buffer de capacidad: 20%
Database Auto-scaling
DocumentDB Scaling Strategy:
| Métrica | Threshold | Acción |
|---|---|---|
| CPU > 80% | 5 min sustained | Add read replica |
| Connections > 90% | 2 min sustained | Scale up instance class |
| Storage > 85% | Alert only | Manual review required |
| Network I/O > 80% | 10 min sustained | Consider sharding |
Storage Tiering Automático
S3 Lifecycle Policies:
Políticas de Lifecycle para S3:
Imágenes Médicas:
| Transición | Tiempo |
|---|---|
| Standard → IA | 30 días |
| IA → Glacier | 90 días |
| Glacier → Deep Archive | 365 días |
| Expiración | Nunca (retención regulatoria) |
Logs de Aplicación:
| Transición | Tiempo |
|---|---|
| Standard → IA | 7 días |
| IA → Glacier | 30 días |
| Expiración | 2555 días (7 años regulatorio) |
Datos de Backup:
| Configuración | Valor |
|---|---|
| Almacenamiento inicial | Glacier Deep Archive (inmediato) |
| Expiración | 2920 días (8 años) |
Monitorización y Alerting
Métricas de Capacidad Críticas
Dashboard Principal - KPIs de Capacidad:
| Métrica | SLA | Warning | Critical | Frecuencia |
|---|---|---|---|---|
| API Response Time | < 500ms p95 | > 400ms | > 800ms | 1 min |
| Image Processing Time | < 30s p95 | > 25s | > 45s | 1 min |
| Database CPU | < 70% avg | > 60% | > 85% | 5 min |
| Storage Usage | < 80% | > 70% | > 90% | 15 min |
| Concurrent Users | N/A | > 80% capacity | > 95% capacity | 1 min |
| Error Rate | < 0.1% | > 0.05% | > 0.2% | 1 min |
Alerting Automático
Alert Routing Matrix:
Matriz de Enrutamiento de Alertas:
Alertas de Capacidad - Nivel Warning:
- Destinatarios: DevOps, SRE Team
- Tiempo de escalado: 30 minutos
- Canales: Slack, Email
Alertas de Capacidad - Nivel Critical:
- Destinatarios: On-call, CTO, DevOps
- Tiempo de escalado: 5 minutos
- Canales: PagerDuty, Teléfono, Slack
- Acciones automáticas: Trigger escalado, Crear incidente
Alertas de Presupuesto:
- Destinatarios: FinOps, CTO
- Umbrales: 50%, 80%, 95%, 100% del presupuesto
- Frecuencia: Diaria
Observabilidad Avanzada
Stack de Monitorización:
| Herramienta | Función | Métricas Clave |
|---|---|---|
| CloudWatch | AWS metrics, logs | Infrastructure, application metrics |
| DataDog | APM, synthetics | End-to-end latency, user experience |
| Grafana | Dashboards | Business metrics, capacity trends |
| Prometheus | Custom metrics | Application-specific KPIs |
| ELK Stack | Log analysis | Error patterns, usage analytics |
Optimización de Costes
FinOps - Gestión Financiera de Cloud
Estructura de Costes Actual (Mensual):
| Categoría | Coste | % Total | Optimización Identificada |
|---|---|---|---|
| Compute (ECS/EC2) | $15,000 | 35% | Reserved Instances: -25% |
| Storage (S3/EBS) | $8,000 | 18% | Lifecycle policies: -30% |
| Database | $12,000 | 28% | Rightsizing: -20% |
| Network/CDN | $5,000 | 12% | Caching optimization: -15% |
| Monitoring/Logs | $3,000 | 7% | Retention policies: -25% |
| Total | $43,000 | 100% | Potential savings: -23% |
Strategies de Optimización
Cost Optimization Roadmap:
Hoja de Ruta de Optimización de Costes:
Q1 2025:
| Iniciativa | Ahorro Mensual |
|---|---|
| Estrategia Reserved Instances | $3,750 |
| Políticas lifecycle S3 | $2,400 |
| Subtotal Q1 | $6,150/mes |
Q2 2025:
| Iniciativa | Ahorro Mensual |
|---|---|
| Rightsizing de bases de datos | $2,400 |
| Optimización retención logs | $750 |
| Subtotal Q2 | $3,150/mes |
Q3 2025:
| Iniciativa | Ahorro Mensual |
|---|---|
| Spot instances para batch jobs | $1,500 |
| Optimización CDN | $750 |
| Subtotal Q3 | $2,250/mes |
Resumen Anual:
- Ahorro anual total: $139,800
- ROI de la optimización: 340%
Capacity Planning - Presupuestos
Proyecciones Presupuestarias
Budget Planning FY2025:
| Trimestre | Usuarios Proyectados | Coste Infraestructura | Crecimiento |
|---|---|---|---|
| Q1 | 30,000 | $52,000/mes | +21% |
| Q2 | 40,000 | $68,000/mes | +31% |
| Q3 | 55,000 | $89,000/mes | +31% |
| Q4 | 75,000 | $118,000/mes | +33% |
| Total FY | - | $1,308,000/año | +180% |
Contingency Planning
Escenarios de Capacidad:
| Escenario | Probabilidad | Impacto Coste | Contingencia |
|---|---|---|---|
| Crecimiento Base | 60% | Budget baseline | Planned scaling |
| Crecimiento Acelerado | 25% | +40% budget | Emergency scaling fund |
| Pandemia/Screening masivo | 10% | +200% capacity | Spot instances + CDN boost |
| Recession/Slow growth | 5% | -30% demand | Scale-down automation |
Gestión de Recursos Especializados
GPU Computing para ML
Configuración GPU Clusters:
Configuración de Clusters GPU para ML:
Cluster de Entrenamiento:
- Instancias: 4x p3.8xlarge (GPU V100)
- Patrón de uso: Trabajos de entrenamiento por lotes (batch)
- Optimización de costes: Spot instances (ahorro 70%)
Cluster de Inferencia:
- Instancias: 6x g4dn.xlarge (GPU T4)
- Patrón de uso: Inferencia en tiempo real
- Escalado: Auto-scale 2-20 instancias
Entorno de Desarrollo:
- Instancias: 2x g4dn.large
- Patrón de uso: Desarrollo de modelos
- Programación: Pool de recursos compartidos
Specialized Storage Requirements
Medical Imaging Storage:
| Tipo | Rendimiento | Capacidad | Coste/TB/mes | Use Case |
|---|---|---|---|---|
| EFS (General) | 100 MB/s | 1TB | $300 | Shared model artifacts |
| S3 Standard | N/A | 50TB | $23 | Active image processing |
| S3 IA | N/A | 150TB | $12.50 | Recent images (30-90 days) |
| S3 Glacier | Minutes | 500TB | $4 | Archive (90+ days) |
| S3 Deep Archive | Hours | 2PB | $1 | Long-term regulatory |
Business Continuity y Disaster Recovery
RTO/RPO Requirements
Recovery Objectives por Servicio:
| Servicio | RTO | RPO | DR Strategy |
|---|---|---|---|
| API Core | 15 min | 1 min | Multi-AZ + auto-failover |
| ML Inference | 30 min | 5 min | Multi-region model deployment |
| Database | 1 hour | 15 min | Cross-region read replica |
| File Storage | 4 hours | 1 hour | Cross-region replication |
| Monitoring | 5 min | Real-time | Multi-region deployment |
Capacity for DR
DR Infrastructure Sizing:
Dimensionamiento de Infraestructura DR:
Configuración de Regiones:
- Región primaria: eu-west-1 (100% capacidad)
- Región DR: eu-central-1 (warm standby)
Asignación de Capacidad DR:
| Componente | Capacidad DR |
|---|---|
| Compute | 50% de primaria (escalado bajo demanda) |
| Storage | 100% (replicación continua) |
| Network | 100% (conexiones redundantes) |
Escenarios de Failover:
| Escenario | RTO |
|---|---|
| Mantenimiento planificado | Zero downtime |
| Fallo de Availability Zone | < 15 minutos |
| Fallo de región | < 4 horas |
Impacto en Costes:
- Incremento de coste de infraestructura: +35%
Compliance y Auditoría
Capacity Management Audit Trail
Auditoría de Decisiones de Capacidad:
Requisitos de Auditoría de Gestión de Capacidad:
Cambios de Capacidad:
- Aprobación requerida: Cambios > 25% de capacidad
- Documentación: Justificación de negocio + evaluación técnica
- Retención: 7 años
Variaciones Presupuestarias:
- Umbral de notificación: ±15% del presupuesto mensual
- Escalado: Notificación a CFO + CTO
- Ciclo de revisión: Mensual
SLAs de Performance:
- Monitorización: Continua
- Reporting: Informes mensuales de SLA
- Cumplimiento: Adhesión a SLA requerida ≥ 99%
Regulatory Compliance para Healthcare
Medical Device Capacity Requirements:
| Regulación | Requirement | Implementation |
|---|---|---|
| FDA QSR | Change control for capacity | Formal approval process |
| EU MDR | Performance monitoring | Continuous metrics collection |
| HIPAA | Availability requirements | 99.9% uptime SLA |
| GDPR | Data processing capacity | Privacy by design scaling |
Automatización y Tooling
Infrastructure as Code
Capacity Automation Stack:
Stack de Automatización de Capacidad:
Herramientas de Infraestructura:
| Herramienta | Función |
|---|---|
| Terraform | Aprovisionamiento infraestructura |
| Ansible | Gestión de configuración |
| Helm | Despliegues Kubernetes |
Herramientas de Monitorización:
| Herramienta | Función |
|---|---|
| Prometheus | Recolección de métricas |
| Grafana | Visualización |
| AlertManager | Enrutamiento de alertas |
Herramientas de Optimización:
| Herramienta | Función |
|---|---|
| AWS Cost Explorer | Análisis de costes |
| AWS Compute Optimizer | Recomendaciones rightsizing |
| Scripts personalizados | Automatización cleanup |
Self-Healing Infrastructure
Automated Remediation:
Procedimiento de Auto-Remediación:
Alerta: CPU Alta
- Verificar: ¿Es posible escalar horizontalmente?
- SÍ → Activar auto-scaling
- NO → Crear incidente "Intervención manual requerida"
Alerta: Almacenamiento Lleno
- Verificar: ¿Es almacenamiento de logs?
- SÍ → Ejecutar limpieza de logs antiguos
- NO → Expandir tier de almacenamiento
Alerta: Presión de Memoria
- Reiniciar servicios intensivos en memoria
- Verificar mejora
- NO mejoró → Escalar tamaño de instancia (scale up)
Métricas y KPIs
Operational Excellence KPIs
| Métrica | Target | Q4 2024 | Trend |
|---|---|---|---|
| Capacity Utilization | 70-80% | 74% | ✅ |
| Cost per Transaction | < $0.02 | $0.018 | ↓ |
| Auto-scaling Events | < 50/day | 32/day | ✅ |
| Capacity Planning Accuracy | ±10% | ±8% | ✅ |
| Time to Scale | < 5 min | 3.2 min | ✅ |
| Budget Variance | ±5% | +3% | ✅ |
Business Impact Metrics
| Business KPI | Target | Current | Impact |
|---|---|---|---|
| Revenue per GB | $0.15 | $0.18 | ↑ 20% |
| User Satisfaction | > 4.5/5 | 4.7/5 | ↑ |
| Time to Market | < 2 weeks | 10 days | ↑ 30% |
| Cost of Downtime | < $1K/hour | $0/hour | ✅ |
Roadmap de Evolución
Capacity Management Maturity
Niveles de Madurez:
- Reactive (Actual): ✅ Monitoring, alerting, manual scaling
- Proactive (Q1 2025): 🔄 Predictive scaling, cost optimization
- Predictive (Q3 2025): 📋 ML-based forecasting, automated optimization
- Autonomous (2026): 📋 Self-managing infrastructure, AI-driven decisions
Technology Evolution
Emerging Technologies:
Hoja de Ruta Tecnológica:
2025:
| Tecnología | Descripción | Beneficio |
|---|---|---|
| Serverless ML | AWS Lambda + SageMaker inference | Escalabilidad elástica |
| Spot Fleet | Batch workloads en spot instances | 80% ahorro costes |
| Graviton Processors | ARM-based AWS Graviton | 20% mejor precio/rendimiento |
2026:
| Tecnología | Descripción | Beneficio |
|---|---|---|
| Kubernetes Adoption | Migración a EKS | Mejor utilización recursos |
| Service Mesh | Istio para gestión tráfico | Observabilidad avanzada |
| Chaos Engineering | Pruebas resilencia automatizadas | Mayor disponibilidad |
2027:
| Tecnología | Descripción | Beneficio |
|---|---|---|
| Quantum-Ready | Criptografía resistente a quántica | Seguridad futura |
| Edge Computing | Despliegue inferencia regional | Baja latencia |
| AI Ops | Operaciones completamente automáticas | Operaciones autónomas |
Anexo A: Capacity Sizing Calculator
Calculadora de Capacidad:
Parámetros de Entrada:
- Tasa de crecimiento (por defecto: 15% mensual)
- Factor estacional (por defecto: 1.0)
Cálculo de Proyección de Capacidad:
Fórmula: capacidad_proyectada = uso_actual × (1 + tasa_crecimiento)^meses × factor_estacional
Ejemplo:
- Uso actual: 100 unidades
- Crecimiento: 15% mensual
- Proyección a 6 meses: 100 × (1.15)⁶ × 1.0 = 231 unidades
Cálculo de Coste:
| Componente | Coste Unitario |
|---|---|
| Compute | $0.05 por CPU-hora |
| Storage | $0.023 por GB |
| Network | $0.09 por GB transferido |
| ML Inference | $0.001 por request |
Coste Total: Suma de todos los componentes
Anexo B: Emergency Scaling Runbook
Procedimiento de Escalado de Emergencia:
- Detección: Alert automática o manual
- Evaluación: Determinar scope y urgencia (< 5 min)
- Autorización: Auto-aprobada si < 200% capacity
- Ejecución: Terraform apply + monitoring
- Validación: Verificar métricas en 15 min
- Comunicación: Stakeholder notification
- Post-mortem: Análisis de causa raíz en 48h
Signature meaning
The signatures for the approval process of this document can be found in the verified commits at the repository for the QMS. As a reference, the team members who are expected to participate in this document and their roles in the approval process, as defined in Annex I Responsibility Matrix of the GP-001, are:
- Author: Team members involved
- Reviewer: JD-003, JD-004
- Approver: JD-001