Cuando tu proveedor se cae
Última actualización:
Una página de estado de un proveedor es el panel público que un proveedor de nube, alojamiento, código o pagos mantiene para declarar su propia salud: un indicador general, una lista de componentes y una cronología de incidentes escrita por el propio proveedor mientras esos incidentes aún están en curso. Leerla bien es una habilidad de operador, porque el titular es un resumen y la verdad vive debajo de él: en qué componente está afectado, en qué región, con qué impacto declarado y hasta dónde ha avanzado el incidente en el propio flujo del proveedor. Este artículo enseña esa lectura y termina con lo que hay que hacer en los primeros diez minutos cuando el proveedor en cuestión es uno del que dependes. Empieza en el panel de estado de proveedores, que reúne las páginas de los principales proveedores en una instantánea, y ten presente durante todo el texto la pregunta de ¿está caído o eres solo tú?: las dos herramientas responden a las mitades opuestas de la misma duda.
Dos cosas distintas: el indicador y el estado del incidente
Toda página de estado madura lleva dos señales separadas que los lectores confunden constantemente. La primera es el indicador general: un único estado resumido para todo el servicio, normalmente uno de none, minor, major, critical o maintenance en el feed legible por máquinas que hay tras la página —el modelo documentado en la documentación para desarrolladores de Statuspage, que la mayoría de los grandes proveedores usa directamente o imita de cerca—. El indicador es deliberadamente tosco. Existe para que un lector ocupado —o una máquina, como nuestro panel de estado— pueda responder a «¿pasa algo allí?» en un segundo, y se calcula a partir del componente más afectado, del propio juicio del proveedor, o de ambos.
La segunda señal es el incidente en sí, y tiene su propio ciclo de vida que el indicador aplana. Un incidente se abre con un nombre, un impacto declarado y un estado tomado de un flujo: investigando (vemos síntomas y aún no sabemos la causa), identificado (sabemos la causa y estamos en ello), monitorizando (una corrección está fuera y observamos si aguanta) y resuelto (creemos que ha terminado, a la espera del postmortem). Esos estados llevan información que el indicador no puede llevar. Un incidente crítico que lleva dos horas en monitorización probablemente está terminando; un incidente minor que entró en investigación hace cuatro minutos puede convertirse todavía en cualquier cosa.
Lee ambas, en ese orden, y lee las actualizaciones entre ellas. La cronología de actualizaciones cortas bajo un incidente es donde el proveedor te dice lo que el titular nunca dirá: qué subsistema falló, qué solución alternativa existe, si lo afectado son los datos o solo la disponibilidad, y si la próxima actualización se promete en veinte minutos o en dos horas. Un incidente cuyas actualizaciones dejan de llegar es en sí mismo una señal: o el equipo está desbordado, lo que se correlaciona con una caída más larga, o el incidente se ha plegado en silencio dentro de uno mayor. Los operadores que hacen una captura del titular y dejan de leer actúan de forma rutinaria sobre la frase menos informativa de la página.
Por qué «todos los sistemas operativos» puede significar que tú estás caído
El indicador resume el servicio entero, y los servicios modernos no son una sola cosa. Un proveedor puede estar honestamente en verde a nivel global mientras la región en la que despliegas, la única superficie de producto a la que llamas, la versión heredada de la API a la que estás anclado o el plano de control que necesitas para un despliegue están fallando para cada cliente que los toca. Las listas de componentes existen precisamente por esto: una página como la página de estado de GitHub descompone el servicio en operaciones Git, peticiones de API, Actions, Pages y más, y cualquiera de ellos puede estar degradado mientras el cartel general sigue siendo tranquilizador —o al revés, con el cartel en rojo por un componente que nunca has usado—.
Hay también tres brechas más silenciosas. Primera, el retraso de declaración: un proveedor declara un incidente cuando lo ha confirmado, no cuando ocurrió el primer error, así que los primeros minutos de muchas caídas muestran una página verde y un feed social ardiendo; la página no miente, simplemente va por detrás. Segunda, los umbrales: un proveedor puede tratar una tasa de error del dos por ciento en un nivel como ruido normal y no declarar nunca nada, mientras ese dos por ciento se concentra exactamente en tu patrón de tráfico. Tercera, el alcance: las páginas de estado describen el lado del cable del proveedor. Un fallo de DNS, un problema de enrutamiento o un camino bloqueado entre tus usuarios y un proveedor sano produce una caída total para ti bajo un indicador verde —y por eso la pregunta compañera, está caído o eres solo tú, tiene que responderse desde puntos de vista independientes, no desde la propia página del proveedor—.
La regla de trabajo es tratar el verde como «ningún incidente declarado», nunca como «saludable probado». Cuando tu propia monitorización dice que los usuarios están fallando y el proveedor dice operativo, cree a tu monitorización en lo que respecta a tus usuarios y usa la página de estado para otro trabajo: comprobar si más tarde aparece una declaración, que confirma retrospectivamente la causa, y si el componente del que dependes tiene un historial de incidentes con la misma forma que el que estás viviendo.
Suscríbete a componentes, no a páginas
La mayoría de los operadores se suscribe a una página de estado como se suscribe a un boletín: una suscripción, cada incidente, para siempre —y luego, previsiblemente, empieza a ignorar el correo, porque un feed global de un proveedor grande produce un goteo constante de incidentes de componentes que no usa, en regiones a las que no sirve—. La fatiga de alertas no es un defecto de carácter; es la respuesta correcta a una señal mal delimitada. La corrección es mecánica y está disponible en casi todas las páginas de estado maduras: suscríbete a nivel de componente. El mismo modelo de Statuspage que define los indicadores permite también a los suscriptores filtrar por componente, y los proveedores que ejecutan sus propios sistemas, como la página de estado de Cloudflare, ofrecen la misma elección a través de sus propios flujos de suscripción.
Delimita cada suscripción a lo que realmente cambiaría tu conducta a las 3 de la mañana. Los componentes a los que llama tu tráfico de producción pertenecen al canal ruidoso —el que avisa, manda mensajes o al menos marca algo que verás en minutos—. Los componentes que usas solo para construcciones, analítica o herramientas internas pertenecen a un canal silencioso que revisas en horas de trabajo. Los componentes que no usas no pertenecen a ninguna parte: cada notificación que ignoras correctamente hace que la siguiente sea más fácil de ignorar, incluida la que importa. Revisa la lista cada vez que cambie la pila, porque las suscripciones se pudren en ambas direcciones: dependencias nuevas a las que nadie se suscribió y muertas que siguen avisando a un canal que nadie mira.
Prefiere los feeds legibles por máquinas cuando puedas. El correo es el canal más lento y más ignorable que ofrece una página de estado; los webhooks y los feeds pueden alimentar tu propio panel, abrir un ticket interno o voltear la página de espera preparada de tu equipo de soporte antes de que llegue la primera queja de un usuario. Incluso una versión ligera compensa: la instantánea de nuestro panel de estado de proveedores se construye exactamente desde estos feeds públicos, lo que prueba que los datos están ahí para ser consumidos programáticamente en lugar de admirados en una pestaña del navegador que tienes que acordarte de abrir.
Construye tu propio inventario de dependencias
Nada de los consejos anteriores funciona sin una lista, y la mayoría de los equipos descubre durante una caída que no tiene una. Un inventario de dependencias es simplemente la respuesta escrita a una pregunta que suena trivial y no lo es: qué servicios externos, si se detuvieran esta noche, nos detendrían a nosotros —y cuáles solo nos avergonzarían—. Constrúyelo con buen tiempo. Recorre tu arquitectura superficie por superficie —alojamiento, DNS, alojamiento de código y CI, los proveedores de base de datos y almacenamiento, el procesador de pagos, los remitentes de correo y SMS, el proveedor de identidad, el rastreador de errores, la etiqueta de analítica, las fuentes y scripts que tus páginas cargan desde el CDN de otro— y escribe, para cada uno, el proveedor, el componente que realmente consumes, dónde vive su página de estado y qué experimentan tus usuarios cuando falla.
Clasifica cada entrada por la forma de su fallo, no por lo mucho que te guste el vendedor. Algunas dependencias son duras: si se detienen, tú te detienes, y el único trabajo disponible es comunicar y esperar. Algunas son blandas: el sitio funciona sin ellas, degradado —sin analítica, sin widget de chat, sin personalización— y para esas, el inventario debe decir quién puede apagarlas y cómo. Y algunas están ocultas: las dependencias transitivas que no elegiste, como el estado de la región de nube en la que corre tu propia base de datos SaaS, o la infraestructura de certificados y DNS debajo de todo. Las dependencias ocultas son las que producen la caída de «todo está caído y nada de lo que pagamos está en la lista», y las encuentras preguntando a cada vendedor, una vez, de qué depende él.
Guarda el inventario donde un incidente pueda alcanzarlo: en el runbook, junto a la lista de escalación, no en una página wiki que nadie puede abrir cuando el proveedor de identidad es precisamente lo que está caído. Una página basta. Su trabajo durante una caída es convertir «algo va mal» en una lista de verificación —por cada dependencia dura, arriba o abajo, en treinta segundos— y su trabajo después es ser corregido, porque cada incidente real te enseña algo sobre una dependencia que habías clasificado mal. Un inventario que nunca se corrige es un documento histórico, no operativo.
Los primeros diez minutos de una caída de proveedor
Del minuto cero al dos: confirma y localiza. Revisa tu propia monitorización para asegurarte de que el fallo es real y tuyo para anunciarlo, y después abre el panel de estado y la página del proveedor sospechoso. Estás respondiendo a una pregunta: ¿hay un incidente declarado que se cruce con lo que usas —componente, región, producto—? Si lo hay, tienes tu causa y tu primer mensaje. Si no lo hay, amplía la comprobación: otro proveedor de tu inventario, tu último despliegue, tu DNS. La mayoría de los dramas falsos mueren en estos dos minutos, y la mayoría de los reales cobran aquí su forma.
Del minuto dos al cinco: comunica, con claridad y pronto. Cuenta a tus usuarios, en los canales que realmente leen, que un proveedor externo con nombre está teniendo un incidente, qué significa para ellos en términos prácticos —qué no funciona, qué sigue funcionando, si sus datos están a salvo— y cuándo volverás a actualizar. Un mensaje de espera honesto enviado en el minuto cuatro vence a una explicación precisa enviada en el minuto cuarenta, porque el silencio es lo que los usuarios rellenan con sus peores suposiciones y los nombres de tus competidores. Internamente, abre un único hilo de incidente, nombra a una sola persona para hablar y pon marca de tiempo a todo; te lo agradecerás en el postmortem, y el equipo de soporte del proveedor también si los necesitas.
Del minuto cinco al diez: deja de empeorarlo y prepara los aterrizajes suaves. Congela los despliegues: un cambio hecho dentro de un incidente activo de un proveedor externo no puede evaluarse y puede que ni siquiera pueda revertirse. Apaga los reintentos agresivos y los trabajos no esenciales que machacan al proveedor que falla; la recuperación es mediblemente más lenta cuando diez mil clientes reintentan al unísono, y algunos proveedores te limitarán hasta una segunda caída, esta vez autoinfligida. Apaga o degrada las dependencias blandas que tu inventario marcó como prescindibles, publica la página de espera si tienes una, y luego entra en el ritmo que dicte el incidente: monitoriza las actualizaciones del proveedor, actualiza a tus usuarios a las horas prometidas haya o no noticias, y no cambies nada más a menos que cambien los hechos. La caída terminará en el horario del proveedor, no en el tuyo; tus diez minutos deciden si tus usuarios la recuerdan como el mal día de su proveedor o como el tuyo.