
Sesenta contenedores en un servidor
Un servidor bare-metal ejecuta decenas a cientos de contenedores Hoody. KSM y dedup BTRFS hacen que el costo marginal sea casi cero.
PagerDuty te despierta. No te levantes. Abre el marcador para el terminal de producción. PATCH el snapshot de antes del despliegue malo. La producción está de vuelta. Sin bastion, sin VPN, sin portátil.
On-call es un trabajo de triage, no un trabajo de depuración. La URL del terminal te permite entrar. El PATCH de snapshot te saca. La mañana es para el arreglo real.
Llega la alerta. Pantalla del teléfono encendida, luz de la cama apagada.
Abre la URL terminal-1. Tail del registro. Localiza el cambio de variable de entorno del despliegue de las 11pm.
PATCH /containers/[id]/snapshots/pre-deploy-2255. El contenedor se revierte.
La tasa de errores vuelve a la línea base. Actualización de canal enviada. Luces apagadas.
Editar en el teléfono es un infierno, así que el arreglo perezoso es el arreglo correcto. Restaura el contenedor al snapshot que tomaste antes del despliegue malo. El post-mortem de las 11am puede decidir qué cambiar realmente.
La misma ventana, incrustada en tu navegador del teléfono. Línea base, despliegue, pico, restauración, plana. Veintiocho segundos para que vuelva el snapshot.
A las 03:47 no arreglas errores. Arreglas disponibilidad.
La rotación de on-call no es una sesión de depuración. Es una sesión de triage. Los snapshots hacen que el triage sea instantáneo así que la depuración real sucede a las 11am, por humanos que durmieron.
La mayoría de los rituales de on-call son tejido de cicatrices de infraestructura que no era navegable en un teléfono. La URL HTTPS más un PATCH de snapshot reemplazan un montón de ellos.
Abriste una URL en tu teléfono y arreglaste la producción.