Contacto, Soporte y Canales de Comunicación

El equipo de HERA existe para que los equipos de desarrollo sean autónomos, rápidos y seguros. Para lograrlo, la comunicación debe ser precisa, eficiente y con fundamento — no un canal de soporte infinito.

Principio rector

“La documentación responde, el chat aclara, BMC ejecuta.” Antes de contactar al equipo, busca en este portal. Si necesitas aclarar algo, usa el chat. Si necesitas una acción, levanta un ticket.

---

Modelo de Comunicación por Niveles

Nivel 0 — Self-Service: Portal HERA (80% de las dudas)

Este portal es la primera línea de respuesta. Aquí están documentados los estándares, guías, pipelines, arquitectura, seguridad y operaciones de toda la plataforma.

Necesidad	Dónde encontrarlo
Configurar mi ambiente de desarrollo	Desarrollo Local
Entender el flujo CI/CD de mi proyecto	GitLab Workflow
Interpretar un fallo de SonarQube	SAST con SonarQube
Saber qué imagen base usar	Golden Images
Entender el flujo de Git	GitLab Workflow
Saber cómo se despliega mi servicio	GitLab Workflow
Entender la arquitectura GCP	Infraestructura

Si no encuentras la respuesta, pasa al Nivel 1.

---

Nivel 1 — Colaboración Rápida: Google Chat (15% de las dudas)

Para dudas que no están en la documentación o que necesitan una aclaración rápida. No es un canal de soporte — es un espacio de colaboración entre profesionales.

Espacio	Propósito	Participantes
HERA - Soporte General	Preguntas sobre la plataforma, pipelines, documentación	Todos los equipos + equipo HERA
HERA - DevSecOps	Dudas sobre SAST, SCA, vulnerabilidades, Golden Images	Desarrolladores + Security Engineers
HERA - Infraestructura	Consultas sobre GKE, Cloud SQL, networking, Terraform	Arquitectos + Platform + SRE
HERA - Releases & Deploys	Coordinación de releases, problemas de deploy, rollbacks	Tech Leads + DevOps + SRE
HERA - Anuncios	Cambios en la plataforma, mantenimientos, nuevas features	Equipo HERA → Todos (solo lectura)

Reglas de uso

1. Busca primero en el portal — Si la respuesta está documentada, no la preguntes en el chat
2. Solo spaces públicos, nunca DMs — Los mensajes directos (DMs) están prohibidos para temas técnicos. Todo va en el space correspondiente para que los líderes tengan visibilidad y el contexto se preserve ante rotación de personal
3. Incluye contexto — “No me funciona el pipeline” no es una pregunta útil. Incluye: qué haces, qué error ves, qué ya intentaste, enlace al pipeline fallido
4. Usa la estructura de mensaje — Ver la sección Estructura obligatoria de mensajes más abajo
5. Respuesta con enlace — Si un miembro del equipo HERA responde con un link a la documentación, esa es la respuesta. Léela antes de preguntar más
6. El chat no ejecuta — Si necesitas un acceso, un recurso, un cambio de infraestructura o reportar un incidente, eso va en BMC (Nivel 2)
7. Acuerdo en chat = ticket en 4 horas — Si se toma una decisión o se acuerda una acción en el chat, el solicitante es responsable de registrarla como ticket en BMC dentro de las siguientes 4 horas. Sin ticket = no se acordó nada
8. Horario de atención — El equipo HERA responde en el chat de lunes a viernes, 9:00 a 18:00 CST. Fuera de ese horario, los mensajes se atienden el siguiente día hábil

Prohibidos los mensajes directos (DMs) para temas técnicos

Los DMs crean silos de información que se pierden con la rotación de personal. Si un ingeniero resuelve una duda por DM, solo él y el solicitante saben la respuesta. Cuando uno de los dos se va, el conocimiento desaparece. Todo en spaces públicos — así los líderes tienen visibilidad, el equipo aprende por osmosis y la información sobrevive a las personas.

¿Se repite una pregunta?

Si una pregunta aparece más de 3 veces en el chat, el equipo HERA la documentará en este portal. Así el conocimiento crece y el chat se mantiene limpio.

Estructura obligatoria de mensajes en chat

Para evitar mensajes vagos como “oye, necesito algo” o “esto no funciona”, todo mensaje en los spaces de HERA debe seguir esta estructura:

Para dudas técnicas:

🔍 [DUDA] Título corto de la pregunta

Contexto: Qué estoy haciendo y en qué servicio/proyecto
Problema: Qué esperaba vs qué está pasando
Ya intenté: Qué ya revisé/probé (incluir links a docs consultadas)
Link: URL al pipeline/MR/error específico

Para solicitudes que podrían derivar en ticket:

📋 [SOLICITUD] Título corto

Necesito: Descripción concisa de lo que se requiere
Para: Nombre del producto/servicio afectado
Urgencia: Alta / Media / Baja
Contexto: Por qué se necesita

Para reportar un problema:

⚠️ [PROBLEMA] Título corto

Servicio: Nombre del servicio afectado
Ambiente: DEV / QA / PRD
Impacto: Qué funcionalidad está afectada
Desde cuándo: Hora aproximada
Link: URL al dashboard/logs/pipeline

Un buen mensaje se responde en 1 interacción

Si tu mensaje requiere 3 rondas de “¿en qué ambiente?”, “¿qué servicio?”, “¿qué error ves?” — el mensaje original fue incompleto. Invierte 2 minutos extra en el mensaje y ahorra 20 minutos de ida y vuelta.

Lo que NO va en Google Chat

Situación	Canal correcto
”Necesito acceso al proyecto X en GCP”	BMC → Petición de acceso
”Se cayó el servicio en producción”	BMC → Incidente (prioridad alta)
“Necesito un nuevo namespace en GKE”	BMC → Petición de infraestructura
”Quiero una excepción de seguridad”	BMC → Excepción de seguridad
”¿Cómo configuro ESLint?”	Portal HERA → Desarrollo Local

---

Nivel 2 — Acción Formal: BMC (5% de las dudas)

BMC es la herramienta para peticiones que requieren acción, tracking y auditoría. Úsala cuando necesitas que alguien haga algo, no cuando necesitas que alguien te explique algo.

Categoría BMC	Ejemplos	SLA esperado
Acceso y permisos	Nuevo usuario en HERA, cambio de rol, acceso a proyecto GCP	24 horas
Infraestructura	Nuevo namespace, Cloud SQL instance, storage bucket, Pub/Sub topic	48 horas
Onboarding de proyecto	Alta de nuevo producto en HERA, creación de subgrupo y repos en GitLab	48 horas
Incidentes de plataforma	Pipeline template roto, cluster degradado, secreto expuesto	Según severidad
Cambios de plataforma	Nueva herramienta, cambio de política, actualización de template	Según impacto
Excepciones	Excepción de Security Quality Gate, recurso fuera de estándar	72 horas

BMC no es para preguntas

Si tu ticket de BMC empieza con “¿Cómo…?” o “¿Por qué…?”, probablemente no necesitas un ticket. Busca en el portal o pregunta en Google Chat primero. BMC es para acciones, no para información.

Acuerdo en chat sin ticket = no existió

Si se tomó una decisión, se aprobó una excepción o se acordó una acción en Google Chat, el solicitante tiene 4 horas para registrarla como ticket en BMC. Si no hay ticket: no hay acuerdo, no hay compromiso, no hay SLA. Los acuerdos informales no sobreviven a la rotación de personal ni son auditables.

---

Equipo HERA — Responsables por Pilar

Equipo de Plataforma (DevOps / SRE)

Construye, mantiene y evoluciona la plataforma HERA: pipelines, infraestructura GKE, herramientas del ecosistema.

• Líder de Equipo: [Nombre del Líder de Plataforma]
• Contacto: [Email o alias del equipo]
• Espacios de Chat: HERA - Soporte General, HERA - Infraestructura, HERA - Releases & Deploys
• Responsabilidades:
  • Onboarding de nuevos proyectos a HERA
  • Mantenimiento de runners de GitLab y clusters de GKE
  • Plantillas de pipeline (templates)
  • Evolución de la arquitectura de la plataforma

Equipo de Seguridad (DevSecOps)

Define políticas de seguridad, gestiona herramientas de escaneo y lidera la gestión de vulnerabilidades.

• Líder de Equipo: [Nombre del Líder de Seguridad]
• Contacto: [Email o alias del equipo]
• Espacio de Chat: HERA - DevSecOps
• Responsabilidades:
  • Configuración de Quality Gates en SonarQube y Docker Scout
  • Triaje de vulnerabilidades Críticas y Altas
  • Gestión de acceso a GCP Secret Manager
  • Aprobación de excepciones de seguridad

Arquitectura

Define los estándares, patrones y decisiones de arquitectura que rigen el desarrollo en HERA.

• Líder de Equipo: [Nombre del Arquitecto Principal]
• Contacto: [Email o alias del equipo]
• Espacio de Chat: HERA - Infraestructura
• Responsabilidades:
  • Revisión de arquitectura de nuevos proyectos
  • Estándares técnicos transversales
  • Decisiones de infraestructura transversales
  • Gobernanza cloud y FinOps

---

Sesiones Técnicas Remotas

Para temas complejos que no se resuelven por chat ni por ticket, el equipo HERA ofrece videollamadas agendadas con objetivos claros. Toda sesión es via Google Meet con agenda publicada previamente.

Tipos de sesiones

Sesión	Frecuencia	Duración	Propósito
Sesión de soporte	Quincenal	60 min	Q&A abierto + demos de capacidades nuevas
Sesión estratégica	Bajo demanda	60 min	Decisiones de arquitectura, excepciones, trade-offs
Sesión de onboarding	Al incorporar partner/equipo	90 min	Walkthrough del ecosistema HERA para equipos nuevos

Regla fundamental

Toda sesión requiere agenda publicada con anticipación. Sin agenda = sin reunión. Esto aplica para cualquier videollamada del equipo HERA, no solo las sesiones programadas.

Plantilla de agenda para sesiones

Toda convocatoria de reunión debe incluir esta estructura en la descripción del evento de Google Calendar:

📌 Contexto
[Por qué esta sesión es relevante — qué problema resuelve o qué decisión requiere]

🎯 Objetivo de la sesión
[Verbo de acción: Alinear / Validar / Decidir / Autorizar / Explicar ...]

📦 Alcance
Incluye:
- [Tema 1]
- [Tema 2]

No incluye:
- [Tema fuera de scope]

🗓️ Agenda
1. [Tema] (X min)
2. [Tema] (X min)
3. Decisiones y siguientes pasos (X min)

⏰ Duración: [X] minutos

📝 Prerrequisitos
- [Documento o página de HERA que el asistente debe leer antes]

🧾 Decisiones esperadas
- [Qué se necesita decidir o aprobar en esta sesión]

📈 Siguientes pasos
- [Se completa al cierre de la sesión]

Ejemplo: Equipo de desarrollo solicita sesión al equipo de Plataforma/DevOps

Escenario: El equipo de eCommerce (Tienda Herdez) necesita migrar su base de datos de Cloud SQL con HA regional y requiere coordinación con el equipo de plataforma para el provisioning, la estrategia de migración y la configuración de Workload Identity.

📌 Contexto
El equipo de eCommerce (Tienda Herdez) está migrando el servicio
backend-checkout-service de una instancia Cloud SQL zonal a una
instancia regional con HA para cumplir con los SLOs de Tier 1
(99.95% disponibilidad). La migración requiere coordinación con
Plataforma para provisioning de la nueva instancia y configuración
de Cloud SQL + Workload Identity.

🎯 Objetivo de la sesión
Validar la estrategia de migración propuesta por el equipo de
desarrollo y definir el plan de ejecución conjunto con Plataforma.

📦 Alcance
Incluye:
- Revisión del sizing propuesto (n2-standard-4, 100GB SSD)
- Estrategia de migración (PITR vs export/import vs DMS)
- Configuración de Workload Identity para el nuevo SA
- Ventana de mantenimiento y rollback plan

No incluye:
- Cambios en el código de la aplicación (responsabilidad del equipo)
- Migración de otros servicios del producto
- Revisión de costos (eso va por FinOps)

🗓️ Agenda
1. Estado actual y problema (Tech Lead eCommerce) — 10 min
2. Opciones de migración y recomendación (Platform Engineer) — 15 min
3. Configuración de Workload Identity — 10 min
4. Definición de ventana de mantenimiento — 10 min
5. Plan de rollback y criterios de éxito — 10 min
6. Siguientes pasos y owners — 5 min

⏰ Duración: 60 minutos

📝 Prerrequisitos
- Tech Lead: leer Cloud SQL HA en /infraestructura/cloudsql/
- Tech Lead: leer Workload Identity en /infraestructura/gke/
- Platform: revisar el service-manifest.yml del producto

🧾 Decisiones esperadas
- Aprobar estrategia de migración (PITR vs export/import)
- Definir fecha de ventana de mantenimiento
- Asignar Platform Engineer responsable del provisioning

📈 Siguientes pasos
- [Se completa al cierre de la sesión]

Quién convoca: Tech Lead del equipo de desarrollo A quién: Platform Engineer + SRE del equipo de plataforma Canal: Google Calendar con enlace de Google Meet

Buenas prácticas para sesiones

Práctica	Detalle
Agenda publicada 24h antes	Sin agenda = la reunión se cancela
Duración máxima: 60 min	Si necesitas más, divide en 2 sesiones
Un facilitador designado	Controla tiempo, modera preguntas, documenta decisiones
Notas en tiempo real	En el mismo evento de Calendar o en un doc compartido
Decisiones documentadas al cierre	Quién, qué, cuándo — antes de colgar
Grabación opcional	Para quienes no pudieron asistir (no reemplaza las notas)
Sin reuniones los viernes después de 14:00	Alineado con la ventana de deploy de HERA

Las reuniones son costosas

Una reunión de 60 min con 8 personas consume 8 horas-persona de la organización. Antes de agendar, pregúntate: ¿se puede resolver con un mensaje estructurado en el space público de Google Chat? ¿Con un documento compartido? ¿Con un comentario en un Merge Request? ¿Con un ticket en BMC? Si la respuesta es sí, no agendes reunión — usa el canal trazable correspondiente.

---

Resumen: ¿Cuándo usar cada canal?

Necesito…	Canal	Ejemplo
Aprender cómo funciona algo	Portal HERA	”¿Cómo configuro mi pipeline?” → Lee la guía
Aclarar algo que leí en la documentación	Google Chat	”¿El Quality Gate aplica también en ramas feature?”
Coordinar un release o deploy	Google Chat (Releases)	“Vamos a promover v2.1 a PRD mañana”
Reportar un bug de la plataforma	BMC	”El template de pipeline Java falla en el stage de test”
Solicitar un acceso o recurso	BMC	”Necesito un namespace para el proyecto X”
Reportar un incidente de producción	BMC (prioridad alta)	“El cluster de GKE en PRD no responde”
Discutir un tema complejo	Sesión técnica remota	”Quiero evaluar si migrar de monolito a microservicios”