Mixer Mode for SREs — a thought experiment, not advice
Aviso: no soy SRE de carrera. Soy CTO/ingeniero que ha estado en suficientes incidentes a las 2:47 a.m. para reconocer el patrón. Lo que sigue es un experimento pedagógico — Mixer Mode aplicado al dominio del SRE. Sospecho que es el dominio donde el marco aterriza más limpio. Vamos a ver.
Por qué SRE es el caso paradigmático
Un SRE en incidente sostiene latencia, disponibilidad, costo, blast radius y fatiga del equipo al mismo tiempo. Esa lista no es secuencial. Es simultánea, modulada por la fase del incidente. Nadie senior "se enfoca en la causa raíz" y deja los otros canales en cero — porque si los deja en cero, la decisión técnica termina siendo correcta y operativamente desastrosa.
La intuición que tengo: si describís un marco a alguien que ya hace el trabajo, y la persona reconoce su práctica sin haber leído el marco antes, capturaste algo estructural. Cada vez que le mostré Mixer Mode a un SRE senior, la respuesta fue alguna variante de "sí, es eso, no tenía nombre". Esa es la señal que estoy buscando — no novedad, sino vocabulario para algo ya operado.
Dicho de otra forma: el SRE no necesita el marco para hacer su trabajo. Necesita el marco para explicárselo a alguien que no opera así — un product manager pidiendo "foco", un VP pidiendo "prioridad", un nuevo en el equipo aprendiendo a no quedarse en un solo canal.
El disclaimer en serio
Mixer Mode nació mirando software de aplicación, no operaciones. Lo que digo del SRE puede sonar correcto y aún así perderse matices del dominio que solo se ven desde adentro. Cosas como on-call rotation dynamics, error budgets formales como herramienta de negociación con producto, el equilibrio entre toil y proyecto en cuotas trimestrales — yo las conozco de oír, no de vivirlas mes a mes.
Mi propuesta: tomalo como traducción, no como SRE 101. Si soy útil acá, es nombrando el patrón cognitivo, no enseñando la disciplina. La disciplina la sabés vos.
Las dimensiones que veo desde afuera
Mi mejor intento de lista, sujeta a corrección. Latencia: p50, p99, distribución por endpoint, comportamiento bajo carga. Disponibilidad: SLO, error budget consumido, trend de incidentes. Costo: cloud bill, eficiencia de capacity, qué se está pagando por reliability que nadie pidió.
Blast radius: qué pasa si esto falla, quién se entera, cuánto tarda, qué se pierde. Este es el canal que más se subestima en planning fuera del incidente y más importa adentro del incidente. Fatiga del equipo: toil acumulado, on-call sostenibilidad, cuántos PagerDuty nocturnos lleva tu mejor ingeniera este mes.
Deuda operativa: la lista de runbooks que nadie escribió, las alertas que todos saben que son falsas pero nadie deshabilita, los dashboards que dejaron de funcionar hace semanas. Vive como ruido de fondo en el panel — bajito, pero siempre encendido.
El incidente como Mixer Mode forzado
A las 2:47 a.m., con la página activa, todos esos faders están vivos simultáneamente. El SRE senior no "se enfoca en la causa raíz". Modula entre comunicación al canal de incident (mantener al stakeholder informado para que no escalen a tres lugares más), mitigación inmediata (parar el sangrado), preservación de evidencia (no destruyas el estado que vas a necesitar para el postmortem), y evaluación de blast (si esto que voy a hacer falla, ¿empeora?).
El que opera bien no es el que tiene un canal más alto. Es el que mantiene los otros sin colapsar. Eso es exactamente Mixer Mode, y es la diferencia entre un SRE con tres años de oficio y uno con diez. El de diez años no piensa "voy a comunicar, después mitigar, después preservar". Lo hace en paralelo y casi sin atención consciente al hecho de que lo está haciendo en paralelo.
Es el caso límite del marco. Si Mixer Mode no describe lo que pasa en un incidente serio, no describe nada. Y describe — al menos según el feedback que vengo recibiendo.
Cómo se ve fuera del incidente
El truco es que el trabajo no-incidente también es Mixer Mode, pero se disfraza. Standup, planning, postmortems, capacity reviews — todos formatos hat-mode que filtran lo que en realidad estás pensando.
Un standup que pide "qué hiciste ayer" amputa el canal de fatiga (no decís "estoy quemado" en standup). Un capacity planning sin contexto de error budget amputa el canal de disponibilidad. Un postmortem sin contexto de costo amputa la pregunta de si la mitigación es financieramente sostenible. Cada formato hat-mode te obliga a reportar como si hubieras pensado en serie.
Lo que estoy probando como experimento de equipo: standup mixer-mode. En vez de qué hiciste, dos frases sobre qué pasó en los seis canales. "Latencia estable, disponibilidad consumió 8% de error budget esta semana por el incidente del martes, costo bajó 4% por la migración X, blast radius del nuevo deploy es contenido, equipo está cansado por la oncall del fin de semana, deuda operativa subió porque no escribimos el runbook del incidente." Treinta segundos. Y comunica más que "ayer terminé el ticket SRE-1234".
Qué cambia con agentes corriendo runbooks
Las tareas de toil — runbook execution, log triage inicial, alerta deduplication, primera pasada de correlación — se están moviendo a agentes. No mañana. Hoy, en stacks que conozco.
Intuición ingenua: eso libera al SRE. Mi hipótesis: no lo libera, lo libera al panel. Más canales abiertos, menos energía gastada en ejecución mecánica, más capacidad de modular. El SRE post-IA no es "menos SRE". Es más mixer.
Riesgo concreto si esto no se opera explícitamente: el agente toma decisiones que el humano hubiera filtrado por contexto cross-canal. El agente ve la alerta de latencia y restartea el servicio — sin saber que ese servicio acaba de subir un deploy que tarda en estabilizarse, o que el cliente que más sufre el restart está en medio de un demo crítico. Esa decisión cross-canal es Mixer Mode puro. Si nadie la opera, se evapora — y el agente queda actuando con contexto amputado.
Lo que no estoy diciendo
No estoy diciendo cómo correr un postmortem. No estoy proponiendo una nueva métrica de SRE. No estoy diciendo que SLO/SLI esté mal — al contrario, son las herramientas de medición más sólidas que tiene la disciplina. Estoy nombrando lo que vive arriba de ellos en la cabeza del operador. La parte que las métricas no capturan porque no son métricas — son cognición.
Si sos SRE: ¿qué canal me falta? Sospecho que hay al menos uno que solo se ve desde adentro.
#MixerMode #SRE #DevOps #Reliability