Operacionaliza el Apéndice A del libro de trabajo de Google SRE reinterpretando la carpeta ficticia del “Example Game Service” como checklist ejecutable: redactar el trabajo visible para usuarios; fijar ventanas móviles (ej. cuatro semanas); emparejar subsistemas con SLIs bien definidas (disponibilidad excluyendo 5xx, latencias con cortes ms, freshness de tablas derivadas, corrección vía probes, cobertura de pipelines); exponer texto num/denom; fundamentar redondeos; derivar presupuestos de error objetivo‑a‑objetivo y enlazar la política de presupuesto de errores correlativa.
Casos de uso
- Servicio enfrentado a clientes nuevo y ejecutivos piden contrato antes de GA
- Existen dashboards pero falta vínculo a SLIs firmadas
- API HTTP y pipelines comparten componentes pero necesitan SLO segregados
- Auditorías quieren tamaño cuantificado de errores sintéticos aceptados
- Postmortems muestran SLO vagos impedían freezes consistentes
Funciones principales
- Describir arquitectura y superficies enfrentadas
- Señalar período rodante oficial (cuatro semanas en el ejemplo)
- Definir SLIs con denominadores coherentes LB/prober/pipelines
- Documentar rationale, redondeo y déficit probatorio conocido
- Calcular error budgets separados objetivo‑a‑objetivo
- Referenciar política de uso de budgets y disclaimers LB/prober
Relacionados
Relacionados
3 Entradas indexadas
Error budget policy drafting
Adapta el ejemplo de política de presupuesto de errores del workbook de Google en una guía repetible para ligar el ritmo de releases a la fiabilidad medida: define objetivos (proteger a usuarios de fallos repetidos de SLO preservando incentivos de innovación), detalla qué ocurre cuando la ventana móvil agota el presupuesto (congelar cambios salvo defectos urgentes o trabajo de seguridad), codifica umbrales de investigación por outage y documenta escalamiento cuando hay desacuerdo sobre el cálculo del presupuesto.
Postmortem writing
Captura la línea de tiempo completa del incidente, blast radius, factores contribuyentes y acciones de seguimiento concretas después de incidentes de producción para que los equipos construyan memoria institucional en lugar de repetir las mismas sorpresas. Un postmortem bien escrito separa causa raíz de triggers, evita culpa y produce action items rastreados que previenen recurrencia.
Incident response
Proceso estructurado para manejar incidentes de producción desde detección hasta resolución y post-mortem. Cubre evaluación de severidad usando gradación P0-P3, coordinación de equipo con un incident commander designado, plantillas de comunicación para interesados y usuarios, y requisitos de post-mortem estructurados para impulsar aprendizaje organizacional de cada outage significativo.