Central Dashboard Control

1) Nombramiento y principios

El dashboard central de control (en adelante, DDU) es una ventanilla única para la toma de decisiones en las operaciones. Agrega señales de telemetría, ITSM, CI/CD, catálogo de servicios, calendario de trabajo y proveedores, convirtiéndolas en widgets válidos (actionables).

• SLO-first: arriba - SLO objetivo y burn-rate por Tier-0/1.
• One-click to action: desde el widget - hasta el playbook/runbook o el ticket.
• Diccionario único: los mismos SEV, estados, colores y umbrales.
• Anotaciones de eventos: lanzamientos/confecciones/ventanas en todos los gráficos.
• Funciones y permisos: presentaciones personales (on-call, IC, management).
• Ruido bajo: quórum de fuentes, deduplicación y supresión por ventanas.

2) Roles y escenarios clave

On-call (P1/P2): entender rápidamente «lo que está ardiendo» y abrir el playbook (≤1 clic).
IC: declarar SEV, ejecutar el modo war-room, controlar cadence comm updates.
Release Manager: ver las gaitas, el progreso de los canarios, la disposición a retroceder.
Service Owner/Product: SLI empresarial (éxito de pagos/registros), impacto de fich.
SRE/Plataforma: Capacidad, Auto Scale, Anomalías, Preparación DR.
FinOps: $/unidad, sobrecostos, alertas presupuestarias.
Seguridad/Legal: posture, certificados clave, ventanas rotativas, auditoría WORM por enlaces.

3) Arquitectura de la información de los centros de datos

• SLO по Tier-0/1 (availability/latency/success) с burn-rate 2-окна.
• Estado SEV: incidentes activos y su línea de tiempo.
• Estado de los lanzamientos: canario/azul-verde, gaitas activas.
• «Traffic lights» de los proveedores (PSP/KYC/CDN).

• Ventanas de servicio (ahora/24h), tarjeta de suppression.
• Capacidad: CPU/RAM/IO/queue-depth/p95 latencia con pronóstico.
• FinOps: $/1k txn, dia spend vs presupuesto, anomalías de volumen de registro.
• DataOps: escaparates frescos, pipelines SLA, errores DQ.
• Seguridad: vencimiento de certificados, rotación de secretos, vulnerabilidades críticas (age/SLA).

• Correlaciones «lanzamiento ↔ SLO», «proveedor ↔ fallo/latencia».
• Enlaces rápidos: logs, tracks, tickets, playbooks, SOP, matriz de escaladas.

4) Widgets (conjunto de referencia)

1. SLO & Burn-rate

Muestra los SLI actuales, el objetivo y el gasto del presupuesto de error (1h/6h).
Acción: abrir el playbook de degradación del servicio.

2. Incidentes (panel SEV)

Activos/últimos, temporizadores Declare/Comms, roles IC/Comms.
Acción: abrir war-room, plantilla de apdate, lista de comprobación de IC.

3. Versiones/Configuraciones

Canario 1→5→25%, banderas, retroceso (botón/referencia SOP).
Anotaciones: versión, commits, autor.

4. Ventanas de servicio

Servicios/regiones actuales/próximos, impactados; máscara de suppression.
Acción: acordar notificaciones, habilitar los guardianes de SLO.

5. Capacidad/Auto Scale

Pronóstico de consumo (Naive/AR), mapa de hotspot, warm-pool.
Acción: solicitud de cuotas/reglas de habilitación (PR en repo-políticas).

6. FinOps

$/unit, top de consultas/registros «caros», daily burn vs budget.
Acción: abrir un informe y una recomendación (muestreo de registros, archivos).

7. Proveedores

SLA/estado PSP/KYC/CDN, peso de las rutas, preparación folback.
Acción: cambiar de peso, patrón de comunicación a los socios.

8. Security

Certificados (≤30d), rotaciones atrasadas, vulnerabilidades (age), eventos sospechosos.
Acción: abrir el reproductor/ticket de IR.

9. DataOps

Frescura del escaparate, porcentaje de pase, falla de paipline, DLQ.
Acción: backfill/cuarentena/transformación rollback.

5) Estados/colores/umbrales (referencia)

Verde: SLI dentro del objetivo, burn-rate <1 ×.
Amber: SLI se degrada, burn-rate 1-2 ×, p95 de crecimiento, pero el trabajo está ahí.
Red: breach o pronóstico burn-out <1h; abrir SEV-1/0.
Grey: suppression (ventana), sin telemetría (error de origen).

6) Anotaciones y correlaciones

Los estatus reliz/konfig/okno/provayderskie son representados sobre las SLO-columnas.
Haga clic en el marcador → diff, autor, gates, botón «Volver/Folback/SOP».
En un incidente, la línea de tiempo se construye a partir de anotaciones y acciones de ChatOps.

7) Fuentes de datos y verificación

Telemetría: métricas/trayectos/registros con trace_id.
ITSM: incidentes/problemas/cambios (estados/SLA).
CI/CD: lanzamientos, firmas, artefactos, pruebas.
Directorio de servicios/CMDB: propietarios, SLO, dependencias.
Calendario: ventanas de servicio.
Proveedores: status-API + confirmaciones manuales (aterrizar en un escaparate separado).
FinOps: facturación/etiquetas de recursos, volúmenes de registro, egresos.

Control de calidad: quórum, sondas duplicadas, frescura SLA, alertas a fuentes «mudas».

8) Modos de visualización

War-room: distribución fija del temporizador SLO/Incidents/Releases/Comms.
Executive (28 días): tendencias MTTR/MTTD/SEV mix, $/ed., SLO-adgerens.
On-call: compacto panel «nocturno» (modo oscuro, números grandes).
Multi-tenant/región: filtros service/region/tenant; presets.

9) Navegación y acciones (one-click)

Botones: '/declare sev1 ', '/freeze', '/rollback ', '/status update', «abrir playbook».
Drill- ดาวn: SLO → gráficos → registros/tracks con filtros prellenados (trace_id, release_id).
Sharing: snapshot de paneles en una página de ticket/status.

10) Seguridad, accesos, auditoría

SSO/OIDC + RBAC/ABAC: roles y scoops (view/action).
JIT/JEA: la acción «peligrosa» sólo está disponible con un aumento temporal.
Auditoría sin cambios: quién hizo clic en qué solicitudes/comandos se fueron.
Secretos: no se muestran, sólo enlaces al gestor de secretos.

11) Métricas de madurez DDC

Actionability ≥ 90%: los clics conducen a la acción, no sólo a los horarios.
Time-to-First-Action ≤ 2 min de DDU al SEV-1/0.
La proporción de incidentes en los que la DDC fue la «fuente de la verdad» ≥ el 95%.
Freshness widgets:% con datos «frescos 5 min».
Cobertura:% de los servicios críticos que tienen tarjetas SLO y anotaciones de lanzamiento.
Zero-blind-spots: fuentes «mudas» en una semana = 0.

12) Hojas de cheques

Diseño

• Funciones y escenarios descritos (P1/P2/IC/Exec/FinOps/Security/DataOps).
• El diccionario de colores/SEV/umbrales está acordado.
• Fuentes de datos con quórum y frescura SLA.
• Diseños de War-room/On-call/Executive.
• Plan de integración de ChatOps/ITSM/CI/CD/CMDB.

• Los widgets pasan el linter (campos obligatorios, owner, umbrales).
• Una vez a la semana - Escalation/Alert Review con mejoras en los CDU.
• Los snapshots de incidentes se aplican en AAR/RCA.
• Modo oscuro/preset móvil para los servicios.
• Pruebas de «mudo» de las fuentes y corrección de las anotaciones.

13) Plantillas (ideas)

13. 1 Definición de widget (YAML)

yaml id: slo-payments title: "SLO: Success of payments (EU)"
owner: team-payments type: slo_burnrate sli:
metric: "biz. payment_success_ratio"
target_pct: 99. 5 burn_rate:
short_window: "1h"
long_window: "6h"
thresholds:
amber: { burn_rate: 1. 2 }
red:  { burn_rate: 2. 0 }
actions:
- label: "Open playbook"
link: "rb://payments/slo-degrade"
- label: "Release rollback"
link: "sop://REL-ROLLBACK-01"
annotations:
release: true change: true filters:
region: "eu"
tier: "0"

13. 2 Tarjeta de incidentes (JSON)

json
{
"id": "incidents-active",
"type": "incident_board",
"sev": ["SEV-0", "SEV-1", "SEV-2"],
"fields": ["id","sev","service","since","ic","next_comms_at"],
"actions": [{"label":"War-room","cmd":"/declare sev1"}]
}

13. 3 Relación con la versión

yaml id: release-canary type: release_progress source: cicd://checkout gates: ["tests","signatures","slo_guardrails"]
canary_steps: [1,5,25]
rollback: "sop://REL-ROLLBACK-01"
annotations: { on_charts: ["slo-latency","slo-success"] }

13. 4 Widget FinOps

yaml id: finops-burn type: cost_unit metrics:
- id: "cost_per_1k_txn"
- id: "logs_daily_gib"
alerts:
- when: "cost_per_1k_txn > target1. 2"
action: "open://finops/reco-logs-sampling"

14) Anti-patrones

«Pared de gráficos» sin acciones y playbucks.
Diferentes colores/umbrales por equipos → confusión en el SEV.
No hay anotaciones de lanzamientos/ventanas - una compleja correlación de causas.
Fuentes duplicadas sin quórum - falsa página/ruido.
Secretos/claves en el panel - riesgo de fuga.
Renderizado lento (no se cachean solicitudes/agregaciones): los paneles no se abren en combate.

15) Hoja de ruta para la implementación (4-8 semanas)

1. Ned. 1: recopilación de requisitos por roles, diccionario de estados/colores, maquetas de tres modos.
2. Ned. 2: conexión SLO/Incidents/Releases/Windows, anotaciones, acciones de ChatOps.
3. Ned. 3: añadir FinOps/Capacity/Providers/DataOps/Security, quórum de fuentes.
4. Ned. 4: War-room modo, snapshots en ITSM, piloto en Tier-0.
5. Ned. 5-6: optimización de rendimiento, preset móvil/on-call, widgets linter.
6. Ned. 7-8: métricas de madurez, revisión semanal, recomendaciones automáticas (muestreo de registros, cuotas, folback).

16) Resultado

Los CDU no son «gráficos hermosos», sino un panel de soluciones: SLO y burn-rate en la parte superior, incidentes/lanzamientos/ventanas en el mismo contexto, acciones instantáneas a través de ChatOps y SOP, fuentes confirmadas y anotaciones. Este dashboard reduce el MTTA/MTTR, simplifica las comunicaciones, soporta FinOps y hace que la operación sea transparente y predecible.