Responsabilidad Compartida
En HERA, la operación exitosa de un producto digital se basa en un Modelo de Responsabilidad Compartida. Esta división clara de tareas asegura que los equipos de Producto tengan la autonomía necesaria para innovar, que el equipo de Plataforma garantice cimientos sólidos y escalables, y que los roles de Gobierno Transversal impongan los guardrails de seguridad, arquitectura y datos que protegen al ecosistema completo.
El Modelo Visual
Sección titulada «El Modelo Visual»El siguiente diagrama muestra cómo se dividen las responsabilidades a través de las capas de la plataforma.
Modelo de Responsabilidad Compartida — Contenedores en HERA
Equipo DevOps / Plataforma
Infraestructura y herramientas
- Seguridad del clúster GKE (nodos, red, almacenamiento)
- Configuración de la red VPC y Cloud Armor
- Pipelines CI/CD (templates y runners)
- Herramientas de escaneo (SonarQube, Docker Scout, TruffleHog)
- Artifact Registry y políticas de retención
- Gestión de secretos a nivel de infraestructura
- Monitoreo de infraestructura y alertas
- Soporte técnico y acompañamiento a equipos
Límite de
responsabilidad
responsabilidad
Equipo de Desarrollo
Código y artefactos de aplicación
- Dockerfile y selección de imagen base del SO
- Librerías del SO dentro del contenedor (libssl, curl, etc.)
- Dependencias de aplicación (npm, pip, maven, etc.)
- Código fuente y lógica de negocio
- Remediación de vulnerabilidades detectadas por el pipeline
- Escaneo local con Docker Scout antes de push
- Actualización periódica de imágenes base y dependencias
- Pruebas unitarias, integración y cobertura de código
Mensaje clave El contenedor es un artefacto de desarrollo. Las vulnerabilidades dentro del contenedor son responsabilidad del equipo que lo construye.
Detalle de Responsabilidades
Sección titulada «Detalle de Responsabilidades»1. Equipos de Producto / Negocio
Sección titulada «1. Equipos de Producto / Negocio»Dueños del valor de negocio. Escriben la aplicación, definen su arquitectura interna, ejecutan los despliegues a través del Golden Pipeline y son quienes aprueban su ida a producción.
Roles que componen este bloque: Developer (DEV), Tech Lead (TL), QA Engineer (QA), Product Owner (PO). Los Partners de Desarrollo externos asumen responsabilidades equivalentes a DEV + TL.
| Área | Responsable principal | Detalle |
|---|---|---|
| Código de aplicación | Developer | Escribir código siguiendo los estándares HERA, Conventional Commits y code review en cada MR. |
| Pruebas unitarias e integración | Developer | Implementar y mantener los tests que corren en el pipeline antes de mergear. |
| Pruebas funcionales (QA) | QA Engineer | Validar features en el ambiente de QA desplegado automáticamente por HERA. |
| Arquitectura del servicio | Tech Lead | Definir diseño interno, patrones aplicables y ADRs. Decisiones de alto impacto escalan al Arquitecto. |
Merge a develop / main | Tech Lead | Aprobador principal de MRs; valida Quality Gates y promociones entre ambientes. |
| Manifiestos del producto/servicio | Developer + Tech Lead | Declarar product-manifest.yml y service-manifest.yml — el Golden Pipeline los consume y genera automáticamente los YAMLs de Kubernetes. |
| Remediación de vulnerabilidades | Developer | Actualizar dependencias y fixear findings SAST/SCA detectados en el pipeline (Tech Lead consulta). |
| Declaración de secretos y variables | Developer | Declarar ExternalSecret y variables de entorno consumidos por la aplicación. El secreto físico vive en GCP Secret Manager y es provisionado por Security. |
| Dashboards de negocio y alertas de aplicación | Developer + Tech Lead | Definir métricas de dominio y alertas específicas del producto. Los SLOs formales se definen junto al SRE. |
| Optimización de costos del servicio | Developer | Ajustar resources, réplicas y patrones de uso. La visibilidad la provee Plataforma. |
| Deploy a DEV y ejecución del deploy a PRD | Developer | El pipeline despliega automáticamente a DEV; el deploy a PRD se ejecuta cuando el PO aprueba. |
| Aprobación final de release a PRD | Product Owner | Valida funcionalidad y da el go/no-go para liberar a producción. |
| Documentación del servicio | Tech Lead + Developer | README, diagramas de secuencia, ADRs y runbooks del producto. |
2. Equipo de Plataforma HERA
Sección titulada «2. Equipo de Plataforma HERA»Dueños de la autopista pavimentada. Proveen las capacidades compartidas (infraestructura, pipelines, imágenes base, monitoreo) para que los equipos de Producto sean autónomos. No construyen el producto — habilitan su construcción.
Roles que componen este bloque: Platform Engineer (PE), SRE.
| Área | Responsable principal | Detalle |
|---|---|---|
| Clusters GKE y redes (VPC) | Platform Engineer | Mantiene y escala los clusters, VPC, servicios compartidos (Pub/Sub, Memorystore). |
| Módulos Terraform reutilizables | Platform Engineer | Construye y versiona los módulos IaC que los productos consumen. |
| Golden Pipeline (templates CI/CD) | Platform Engineer | Provee, versiona (SemVer) y evoluciona el template centralizado. Los productos lo heredan. |
| Runners corporativos | Platform Engineer | Mantiene, escala y actualiza los runners que ejecutan los pipelines. |
| Golden Images | Platform Engineer | Construye, certifica y publica hera/*-golden en el Artifact Registry. |
| Workload Identity y GSAs | Platform Engineer | Provisiona Google Service Accounts y bindings KSA↔GSA declarados por el producto. |
| Cloud SQL (operación) | Platform Engineer | Opera las instancias provisionadas por el DBA a través de Terraform. |
| SLOs y observabilidad de producción | SRE | Define el framework de SLOs. Para cada servicio, el Tech Lead define umbrales específicos (SRE como R, TL como A). |
| Oncall L2, post-mortems y runbooks operativos | SRE | Lidera la respuesta técnica durante incidentes y mantiene los runbooks de plataforma. |
| Estrategia de deploy y ventanas a PRD | SRE | Aprueba la estrategia (canary, blue/green) y ventanas de despliegue. |
| FinOps (visibilidad y reportes) | Platform Engineer | Dashboards de costos y reportes de tendencia a liderazgo. Las decisiones de presupuesto las toma el PO. |
| Soporte L1/L2 | Platform Engineer | Atiende #hera-soporte (L1) y tickets BMC (L2). |
| Soporte L3 y evolución del ecosistema | Platform Engineer | Resuelve problemas profundos de plataforma y mantiene herramientas (SonarQube, GitLab Runner, Artifact Registry). |
3. Roles de Gobierno Transversal
Sección titulada «3. Roles de Gobierno Transversal»Imponen los guardrails transversales que protegen al ecosistema completo. No pertenecen ni a Producto ni a Plataforma: son una tercera fuerza que define, audita y autoriza.
Roles que componen este bloque: Security Engineer (SEC), Arquitecto de Soluciones (ARQ), DBA / Data Engineer. El Comité de Arquitectura (COMA) es la mesa de gobierno donde ARQ, PE, SEC y líderes técnicos deciden cambios de alto impacto.
| Área | Responsable principal | Detalle |
|---|---|---|
| Políticas de seguridad (IAM, Zero Trust, WAF, mTLS) | Security Engineer | Define las políticas que Plataforma implementa técnicamente. |
| Quality Gates de seguridad | Security Engineer | Configura umbrales de SonarQube, reglas de Docker Scout, policies de Kyverno. Platform Engineer opera la herramienta. |
| GCP Secret Manager (gestión, rotación, accesos) | Security Engineer | Crea, rota y controla accesos a los secretos que los productos referencian vía ExternalSecret. |
| Triaje y excepciones de vulnerabilidades | Security Engineer | Clasifica severidad, revisa y autoriza excepciones documentadas; tiene veto. |
| Investigación de incidentes de seguridad | Security Engineer | Lidera la investigación; SRE lidera la contención técnica en paralelo. |
| Compliance y auditoría (ISO 27001, SOC 2, PCI-DSS) | Security Engineer | Mantiene certificaciones, atiende auditores externos, genera reportes. |
| Revisiones de acceso periódicas | Security Engineer | Coordina la revisión cuatrimestral de accesos con los Tech Leads. |
| Estándares arquitectónicos (13 categorías, patrones, principios) | Arquitecto | Define y evoluciona los estándares que todos los productos siguen. |
| Aprobación de cambios arquitectónicos mayores | Arquitecto + COMA | ARQ consulta; COMA es quien aprueba formalmente. |
| Validación de diseño contra principios HERA | Arquitecto | Revisa propuestas de arquitectura nuevas antes de su implementación. |
| Revisión de ADRs de alto impacto | Arquitecto | Firma los ADRs que cruzan boundaries de producto o afectan la plataforma. |
| Provisión y diseño de bases de datos (Cloud SQL) | DBA | Aprueba el schema, índices, estrategia de migración. Platform Engineer ejecuta el aprovisionamiento vía Terraform. |
| Tuning de rendimiento de BD | DBA | Analiza queries lentas, propone índices, configura parámetros de Cloud SQL. |
| Respaldo, retención y recuperación de BD | DBA + SRE | DBA define políticas; SRE las opera y valida DR testing. |
| Schema migrations (Database as Code) | DBA | Aprueba migraciones con breaking changes (DROP, RENAME, cambios de tipo) y las que puedan tomar locks largos en PRD. Developer redacta el archivo de migración; el pipeline aplica migrate up en el stage pre-deploy. Ver Cloud SQL — Database as Code. |
| Inventario instancia → DB → servicio | DBA | Mantiene y audita el mapeo entre instancias Cloud SQL compartidas, sus bases lógicas y los servicios propietarios. Platform Engineer aplica los cambios vía IaC (cloudsql-instance); Tech Lead declara en el service-manifest.yml a qué instancia y DB se conecta el servicio. Ver Modelo de instancia compartida. |
| Auditoría cuatrimestral de migrations y accesos a BD | DBA | Revisa el historial de migrations aplicadas, el inventario de GRANTs y el mapeo instancia→DB; coordina con Security Engineer para compliance. |
Seguridad: Una Responsabilidad Triangular
Sección titulada «Seguridad: Una Responsabilidad Triangular»La seguridad en HERA sigue el modelo “Shift-Left”, pero requiere acción coordinada de tres partes, no dos:
- Security Engineer define los guardrails. Escribe las políticas (IAM, Network Policies, Zero Trust, Kyverno), configura los Quality Gates de SonarQube y Docker Scout, y tiene veto sobre excepciones. Es quien gestiona GCP Secret Manager.
- Platform Engineer implementa y opera los guardrails. Traduce las políticas en código e infraestructura: Admission Controllers, Network Policies en los clusters, herramientas de escaneo en el pipeline, Workload Identity provisionado por Terraform.
- Equipo de Producto remedia los findings. Cuando el pipeline detecta una vulnerabilidad Crítica en una dependencia, el Developer actualiza la librería y el Tech Lead valida que el Quality Gate vuelva a pasar antes del merge.
Matriz de Decisión Operativa
Sección titulada «Matriz de Decisión Operativa»¿Quién es responsable de resolver un problema? La columna “Responsable inicial” indica quién investiga primero; la columna “Posible escalación” señala a quién recurrir si la causa raíz cae fuera de su scope.
| Si el error es… | Responsable inicial | Posible escalación |
|---|---|---|
| Falla en lógica de negocio (500 Internal Error) | Developer + Tech Lead | — |
| Vulnerabilidad SAST en código fuente | Developer (remedia) + Tech Lead (aprueba) | Security Engineer (si hay duda de severidad o se pide excepción) |
| Vulnerabilidad SCA en dependencia | Developer (actualiza dependencia) | Security Engineer (triaje, excepción) |
| Pipeline falla por Quality Gate de seguridad | Developer (remedia el finding) | Security Engineer (si el gate está mal configurado) |
| Pipeline no inicia (Runner error) | Platform Engineer | — |
| Falla en el cluster GKE (Node Pressure, OOM en nodo) | SRE (on-call L2) | Platform Engineer (si requiere cambio de infra) |
| Incidente de seguridad (filtración, bypass, abuso) | Security Engineer (investiga) + SRE (contiene) | COMA (si implica cambio de política) |
Error de Access Denied al consumir un secreto | Developer (verifica que el ExternalSecret esté bien declarado) | Security Engineer (si el secreto en GCP Secret Manager está mal provisionado o el binding falta) |
Error de Access Denied en Workload Identity (GSA) | Developer (valida manifiesto del servicio) | Platform Engineer (si el GSA o el binding KSA↔GSA no está provisionado) |
| Lentitud en queries de BD | DBA (tuning, índices) | Tech Lead (si el problema está en el patrón de acceso desde el código) |
| Cloud SQL inaccesible / fuera de servicio | SRE + DBA | Platform Engineer (si es infra de red/VPC) |
| Disputa sobre patrón arquitectónico aplicable | Tech Lead propone | Arquitecto decide → COMA si el impacto es transversal |
| Costos disparados en un producto | Developer (optimización) + Tech Lead (revisión) | PO (aprobar excepción de presupuesto) |
| Lentitud general de red en GCP | SRE + Platform Engineer | — |
| Excepción solicitada sobre un Quality Gate o política | Security Engineer (si es seguridad) / Arquitecto (si es arquitectura) | COMA (si el alcance es transversal a varios productos) |
¿Dudas sobre tu responsabilidad?
Sección titulada «¿Dudas sobre tu responsabilidad?»Si una tarea no está claramente definida en esta página, usa este orden:
- Consulta el Modelo RACI formal (secciones 5.1–5.10). Es la fuente de verdad cuando hay ambigüedad.
- Si tu tarea no está en el RACI, aplica el principio general: “Tú lo construyes, tú lo corres” (You build it, you run it) dentro de los guardrails definidos por Security, Arquitectura y Datos.
- Para casos grises o escalaciones, abre el canal
#hera-soporteen Google Chat.