CI/CD: Conservación de Islas / Ciencia de Datos

Blameless Postmortem: Incidente de créditos de Azure

28 Aug 2026 - Memo y Mario

Resumen del incidente

A partir del viernes 14 hasta el jueves 20 de agosto nos quedamos sin servidores de trabajo. Esto sucedió una semana antes de que se acabara el patrocinio porque nos quedamos sin créditos antes. Durante este tiempo no pudimos atender tareas de clase 1 o mayores. Durante 5 días estuvieron desactivados los servicios para verificar los datos de trampeo. Durante 3 días no tuvimos servidor de desarrollo. Nos tomó 3 días de trabajo migrarnos a AWS. Este fue un incidente de alta severidad debido a que interrumpió el trabajo regular por 6 días.

¿Qué nos condujo al evento?

En octubre de 2023 Digital Ocean nos retiró el patrocinio y Azure nos redujo los créditos de $3,500 a $2,000. Es decir, nos quedamos sin diversidad de proveedores de infraestructura como servicio (IaaS). Modificamos el consumo de servicios proporcionados por Azure; activamos una computadora en las oficinas para sustituir las funcionalidades que habíamos perdido. Calculamos que con los créditos disponibles nos sobraba para cubrir el año. En algún momento comenzamos a proveer herramientas para uso de CD y tramperos. Con este cambio, aumentamos la capacidad (el costo) del webserver y ya no calculamos el nuevo coste. Esto provocó que nos quedaramos sin créditos antes de que se terminara el tiempo de la renovación, ~15 días.

Falla

No teníamos créditos en Azure y, por lo tanto, no contábamos con infraestructura como servicio.

Impacto

Del 14 al 19 de agosto nos quedamos sin 3 de las 5 máquinas que usamos en el equipo de CD:

Detección

La primer alerta llegó cuando recibimos una factura el domingo 9 de agosto con saldo en rojo. El director de CD reenvío la factura al equipo y comenzó a gestionar la renovación de la donación de Azure. El 11 de agosto el equipo de CD solicitamos las credenciales de AWS para gestionar la migración de los servidores. Para mejorar el tiempo de detección podríamos revisar de alguna manera periodicamente el saldo de nuestros IaaS. En AWS es posible agregar una alerta automática que nos avise que ya se están acabando los créditos.

Respuesta

El director de CD contactó al soporte de Azure para pedir la renovación del patrocinio. El 11 de agosto aprobaron la renovación del patrocinio. El 14 de agosto nos dimos cuenta que la donación de Azure no se activó inmediatamente debido al saldo vencido. Fue necesario hacer una solicitud explícita para usar los créditos para pagar el saldo vencido. Hasta el 14 de agosto el equipo de CD contó con las credenciales en AWS Console para poder utilizar los créditos del patrocinio. El 17 de agosto comenzamos la migración de los servidores a AWS. Terminamos con la migración del webserver y el devserver el 19 de agosto.

Recuperación

Al darnos cuenta que no teníamos servidor de desarrollo, a pesar de haber renovado el patrocinio, decidimos mover nuestros servidores a AWS.

Reducción del tiempo de recuperación

Si hubiéramos explorado la migración a AWS, una vez que ya nos habían aceptado la donación, hubiera sido menor el tiempo de recuperación. Teníamos una dependencia fuerte con el director de CD como administrador de los recursos de la donación de Azure y AWS. Si podemos hacernos cargo de esta responsabilidad, tal vez la detección y la respuesta hubieran sido un poco más ágiles.

Línea de tiempo

Cinco “¿por qué?”

  1. ¿Por qué nos quedamos sin servidores de trabajo?
    • Se acabaron los créditos de Azure y no teníamos otro proveedor activo de IaaS.
  2. ¿Por qué no teníamos otro proveedor de IaaS?
    • En octubre de 2023 nos quedamos con menos de la mitad de los recursos que teníamos antes. Nos quitaron el patrocinio de DO y nos redujeron la donación de Azure.
    • Comenzamos la gestión de créditos en AWS y la obtuvimos en junio de 2026.
    • No habíamos implementado/probado como usar los recursos de AWS.
  3. ¿Por qué no terminamos con la tarea de usar los créditos de AWS?
    • Falta del conocimiento técnico y no darnos el tiempo para aprenderlo.
    • En la priorización no entró está tarea al Kanban.
    • No estaba a la vista de todos los créditos restantes.
  4. ¿Por qué no tomamos esta tarea?
    • Esta tarea no entraba en el criterio de tarea relacionada con una especie o isla; por lo tanto no llegaba al Kanban.
    • Este criterio no se ha actualizado después del cambio de estructura del equipo de CD donde no hay coordinador.
  5. ¿Por qué no hemos reaccionado al cambio de estructura del equipo de CD sin coordinador?
    • Nada nos había obligado a hacer el cambio de estructura hasta este incidente.
    • Las responsabilidades del coordinador recayeron todas en el director del equipo.
    • Nadie pensó en distribuir las responsabilidades de manera sostenible de acuerdo a la carga de trabajo de todos los miembros del equipo.
    • No era evidente la importancia de esta tarea. Hemos atendido tareas que son más “urgentes”.

Causa raíz

Después del cambio de estructura del equipo de CD sin coordinador, no distribuimos las tareas de este rol en todos los miembros del equipo. Hasta este incidente, no era evidente la importancia de redistribuir las tareas del coordinador.

Lecciones aprendidas y cosas ganadas

Acciones correctivas