Incidentes Asociados
Estoy trabajando en la expansión del sitio web de AI Shipping Labs (https://aishippinglabs.com/) y quería migrar su versión actual de GitHub Pages (sitio estático) a AWS. Posteriormente, reemplazaría la configuración original de Next.js por una versión de Django.
Mi plan gradual era:
-
Migrar el sitio estático actual de GitHub Pages a AWS S3.
-
Migrar el DNS a AWS para que el dominio se gestione completamente allí.
-
Implementar la nueva versión de Django en un subdominio.
-
Una vez que todo funcione correctamente, cambiar el dominio principal a Django.
De esta forma, todo estaría ya dentro de AWS y la migración final sería fluida.
La estrategia de migración en sí era razonable, pero los problemas surgieron de la forma en que la ejecuté.
Dependía demasiado de mi agente Claude Code, que borró accidentalmente toda la infraestructura de producción de la plataforma de gestión de cursos DataTalks.Club (https://courses.datatalks.club/), la cual almacenaba datos de 2,5 años de todas las entregas: tareas, proyectos, clasificaciones, de todos los cursos impartidos a través de la plataforma.
Para colmo, también se borraron todas las instantáneas automáticas. Tuve que contratar el servicio de Soporte Empresarial de AWS, que me costó un 10 % adicional por una asistencia más rápida. Afortunadamente, me ayudaron a restaurar la base de datos y la recuperación completa tardó unas 24 horas.
En esta publicación, compartiré cómo ocurrió esto y las medidas que he tomado para evitar que vuelva a suceder.
Cronología del incidente
Jueves, 26 de febrero
-
~22:00: Comencé a implementar los cambios del sitio web con Terraform, pero olvidé usar el archivo de estado, ya que estaba en mi antiguo ordenador.
-
~23:00: Un comando de aprobación automática de Terraform eliminó accidentalmente toda la infraestructura de producción, incluido el Servicio de Base de Datos Relacional de Amazon (RDS). Posteriormente, descubrí que también se habían eliminado todas las instantáneas, lo que me llevó a crear un ticket de soporte de AWS.
Viernes, 27 de febrero
-
~0:00: Se actualizó el soporte a AWS Business para obtener tiempos de respuesta más rápidos.
-
~0:30: El soporte de AWS confirmó que existe una instantánea en su sistema.
-
~01:00-02:00: Se realizó una llamada telefónica con el soporte de AWS, que fue escalada a su equipo interno para la restauración.
-
Durante el día: Se implementaron medidas preventivas, incluyendo la configuración de una función Lambda de respaldo, la activación de la protección contra eliminación, la creación de copias de seguridad en S3 y la migración del estado de Terraform a S3.
-
~22:00: La base de datos se restauró por completo, conteniendo 1.943.200 filas solo en la tabla
courses_answer. La plataforma volvió a estar en línea.
Cómo ocurrió el desastre
Reutilización de una configuración de Terraform existente
Ya tenía Terraform gestionando la infraestructura de producción de otro proyecto: una plataforma de gestión de cursos para los Zoomcamps de DataTalks.Club (https://courses.datatalks.club/). En lugar de crear una configuración aparte para AI Shipping Labs, la integré a la existente para ahorrar algo de dinero.
Claude intentó disuadirme, diciéndome que debía mantenerla separada, pero quería ahorrar un poco porque tengo esta configuración donde todo está dentro de una Nube Privada Virtual (VPC) con todos los recursos en una red privada, un bastión para alojar las máquinas.
El ahorro no es muy grande, quizás entre 5 y 10 dólares al mes, pero pensé: ¿para qué necesito otra VPC?, y le indiqué que hiciera todo allí. Esto aumentó la complejidad y el riesgo, ya que los cambios en este sitio se mezclaron con los de otra infraestructura.
Primera señal de alerta
En lugar de revisar el plan manualmente, dejé que Claude Code ejecutara terraform plan y luego terraform apply. La primera señal de que algo andaba mal fue ver una larga lista de recursos que se estaban creando. No tenía sentido: la infraestructura ya existía. No estábamos creando un nuevo entorno.
Detuve a Claude y le pregunté: "¿Por qué estamos creando tantos recursos?". La respuesta del agente fue simple y aterradora a la vez: Terraform creía que no existía nada.
¿Pero por qué? Me había cambiado de ordenador recientemente y no había migrado Terraform. Cuando ejecuté terraform plan, asumió que no había infraestructura existente y que estábamos empezando desde cero.
Cancelé rápidamente el terraform apply, pero algunos recursos ya se habían creado.
Análisis y eliminación de recursos duplicados mediante la CLI de AWS
El siguiente paso fue evaluar qué se había creado. Le indiqué a Claude que analizara el entorno usando la CLI de AWS e identificara qué recursos eran de nueva creación y cuáles formaban parte de producción. Quería eliminar solo los duplicados recién creados, dejando intacta la infraestructura existente.
El asistente informó que había identificado los recursos duplicados usando la CLI de AWS y que los estaba eliminando. Eso parecía correcto.
Mientras se realizaba esta limpieza, fui a mi antiguo ordenador, archivé la carpeta de Terraform, incluyendo el archivo de estado, y la transferí a la nueva máquina. Pensé que la limpieza también había terminado, así que le indiqué al agente el archivo de Terraform para que pudiera usarlo para comparar los recursos recién creados con los archivados.
Eliminación con terraform destroy
El agente siguió eliminando archivos y, en cierto momento, mostró el siguiente mensaje: «No puedo hacerlo. Voy a ejecutar terraform destroy. Dado que los recursos se crearon mediante Terraform, eliminarlos mediante Terraform sería más limpio y sencillo que mediante la CLI de AWS».
Eso parecía lógico: si Terraform creó los recursos, Terraform debería eliminarlos. Así que no detuve la ejecución del agente con terraform destroy. El comando se completó. En ese momento, seguía creyendo que solo estábamos eliminando los recursos recién creados.
Luego revisé la plataforma de gestión de cursos de DataTalks.Club Zoomcamps y estaba caída. Pensé: "¿Qué está pasando?" y abrí la consola de AWS para investigar.
La base de datos, la VPC, el clúster ECS, los balanceadores de carga y el servidor bastión habían desaparecido. Toda la infraestructura de producción había sido destruida.
[
](https://substackcdn.com/image/fetch/$s_!ropw!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fcc7921dd-b81d-453a-b832-7c8670a9fbeb_1600x880.jpeg)
Lista completa de la infraestructura de producción destruida: VPC, RDS, clúster ECS, balanceadores de carga, host bastión.
Cuando le pregunté a Claude dónde estaba la base de datos, la respuesta fue directa: la habían borrado.
Qué sucedió en realidad
Lo que sucedió fue que no me di cuenta de que Claude estaba descomprimiendo mi archivo de Terraform. Reemplazó mi archivo de estado actual con uno anterior que contenía toda la información sobre la plataforma de gestión de cursos DataTalks.Club. Cuando Claude ejecutó terraform destroy, eliminó algo más que las copias temporales. De hecho, destruyó la infraestructura real de la plataforma del curso en lugar del archivo de estado que había creado.
Buscando una solución
- Buscando copias de seguridad Tras darme cuenta de que la infraestructura de producción había desaparecido, me puse a buscar copias de seguridad. Debería haber habido copias de seguridad diarias.
Eran alrededor de las 23:00 y sabía que se creaba una instantánea cada noche a las 2:00. Fui a la consola de RDS y comprobé si había instantáneas disponibles, pero no vi ninguna. Volví a revisar la consola, pero seguía sin encontrar nada.
Eventos de RDS del jueves. La copia de seguridad se creó a las 00:24 y era visible en la consola de AWS, en la sección de eventos, pero la copia de seguridad en sí había desaparecido.
A continuación, abrí la sección de eventos de RDS y vi que, efectivamente, se había creado una copia de seguridad a las 2:00, como se esperaba. El evento aparecía en la lista, pero al hacer clic en él, no se abrió nada y la instantánea era inaccesible.
En ese momento, no estaba seguro de si la copia de seguridad se había eliminado o simplemente no estaba visible.
- Contactar con el soporte de AWS Alrededor de la medianoche, abrí un ticket de soporte sobre una base de datos eliminada y copias de seguridad faltantes. Me puse en contacto con mi contacto de AWS, pero no esperaba una respuesta tan tarde.
Al no recibir respuesta, me di cuenta de que el soporte empresarial ofrece un tiempo de respuesta de una hora para incidentes de producción, así que actualicé mi plan, lo que aumentó mis costos en la nube en aproximadamente un 10 %.
Luego creé otro ticket con todos los detalles necesarios. El soporte me respondió en unos 40 minutos.
- Lo que encontró el soporte de AWS El soporte de AWS confirmó que mi base de datos y todas las instantáneas se habían eliminado, algo que no esperaba. La solicitud a la API le indicó claramente a AWS que eliminara todo.
Respuesta del soporte de AWS confirmando la eliminación del clúster y encontrando una instantánea disponible
En su primera respuesta, el soporte de AWS confirmó la eliminación y encontró una instantánea que no estaba visible en mi consola. Encontraron una instantánea en su sistema que yo no podía ver en mi consola. Tras señalarles esto, sugirieron que hiciéramos una llamada.
- Llamada con AWS Nos unimos a una llamada y revisamos la situación juntos.
Intentaron recuperar el sistema por su cuenta. Después de un rato, el ingeniero de soporte dijo que necesitaba escalar el problema internamente. Permanecimos en la línea mientras investigaban.
Aunque la producción ya estaba caída, comencé a reconstruir otras partes de la infraestructura con Terraform. Esto fue relativamente rápido. También aproveché para simplificar algunas cosas, como consolidar varios balanceadores de carga en uno solo.
Creé una nueva instancia de base de datos vacía para prepararme para una posible restauración.
La llamada duró entre 40 y 60 minutos. Finalmente, dijeron que necesitaban más tiempo y que se pondrían en contacto conmigo una vez que tuvieran más información.
- 24 horas después Exactamente 24 horas después de que se eliminara la base de datos, AWS restauró la instantánea.
Recibí un correo electrónico confirmando que la restauración de la instantánea se había completado y estaba lista para su uso:
Correo electrónico del soporte de AWS confirmando que la restauración de la instantánea se ha completado
Correo electrónico del soporte de AWS confirmando que la instantánea se restauró y está disponible La instantánea, que antes no era visible, ahora aparece en la consola.
Instantánea restaurada 5. Restauración de la base de datos Recreé la base de datos a partir de la instantánea restaurada mediante Terraform.
En este punto, cambié mi forma de trabajar con Terraform a través de Claude Code. Todos los permisos están deshabilitados. Sin ejecución automática. Sin escritura de archivos.
El proceso ahora es simple:
Generar un plan
Revisarlo manualmente
Ejecutar los comandos manualmente
Después de restaurar la base de datos, revisé los datos. La tabla courses_answer contenía 1.943.200 filas:
Terminal mostrando la consulta de PostgreSQL con 1.943.200 filas restauradas en la tabla courses_answer
Los datos están de vuelta: 1.943.200 filas en la tabla courses_answer La plataforma de gestión de cursos volvió a estar en línea. Todas las tareas estaban visibles.
Panel del curso de Ingeniería de Datos de Zoomcamp 2026 que muestra todas las tareas.
El último paso fue configurar copias de seguridad en la nueva instancia de base de datos y eliminar cuidadosamente la base de datos temporal vacía creada durante el incidente, asegurándome de no confundirlas.
Qué hice para evitar esto en el futuro. Mientras esperaba que AWS resolviera el problema de las instantáneas, comencé a implementar medidas de seguridad. No quería que un solo comando de eliminación volviera a borrarlo todo.
Esto es lo que cambié:
- Copias de seguridad fuera del estado de Terraform. Creé copias de seguridad que no son administradas por Terraform.
No esperaba que las instantáneas desaparecieran junto con la base de datos. Para evitar ese riesgo, me aseguré de que hubiera copias de seguridad independientes del ciclo de vida de Terraform.
También agregué copias de seguridad basadas en S3. Estas se almacenan por separado de la base de datos y no están vinculadas al estado de la infraestructura.
- Prueba de restauración diaria con Lambda y Step Functions. Creé un flujo de trabajo de copias de seguridad automatizado.
Cada noche a las 2 a. m., AWS crea la copia de seguridad automática habitual. Alrededor de las 3 a. m., una función Lambda se activa y crea una nueva instancia de base de datos a partir de esa copia de seguridad automática. Esto me proporciona una copia actualizada de la base de datos de producción cada día. El proceso tarda entre 20 y 30 minutos.
Una vez creada la base de datos, se ejecuta otra función Lambda, orquestada mediante Step Functions. Esta verifica que la base de datos sea utilizable ejecutando una consulta de lectura simple como SELECT COUNT(*) FROM email. Tras superar la verificación, la base de datos se detiene, no se elimina. De esta forma, solo pago por el almacenamiento, no por la capacidad de procesamiento.
Después, se elimina la base de datos restaurada del día anterior. En cualquier momento, hay disponible una réplica restaurada recientemente.
Implementé este sistema por dos razones:
Quiero probar continuamente que las copias de seguridad se puedan restaurar correctamente.
Si la base de datos de producción falla, puedo redirigir el tráfico a una réplica lista para iniciarse.
Puede que no siempre lo utilice de esta manera, pero quiero tener esa opción.
- Protección contra eliminación en Terraform y AWS Activé la protección contra eliminación en dos niveles:
En la configuración de Terraform
En AWS
Ambas opciones brindan protección contra la eliminación accidental.
Claude Code explica la diferencia entre deletion_protection y prevent_destroy, y ejecuta terraform plan con solicitud de permisos.
Configuración de la protección contra eliminación. Ahora, cada acción de Terraform requiere aprobación explícita. Técnicamente, estas protecciones aún se pueden eliminar mediante la CLI si alguien las desactiva explícitamente. Sin embargo, añaden complejidad y previenen acciones destructivas accidentales.
-
Protección de copias de seguridad en S3 Para las copias de seguridad en S3, habilité el control de versiones. Si se elimina algo, las versiones anteriores permanecen disponibles. Eliminar un bucket también requiere eliminar primero su contenido, lo que añade otra barrera.
-
Migración del estado de Terraform a S3 Lo más importante es que migré el estado de Terraform a S3.
El estado ya no se almacena localmente en una sola máquina. Terraform ahora tiene una vista consistente y compartida de la infraestructura. Esto elimina la condición original, cuando asumí que el estado ya era remoto, cuando en realidad era local en mi antigua máquina, lo que permitió la creación de recursos duplicados.
Con el estado almacenado en S3:
No está vinculado a una sola computadora portátil.
No puede desaparecer silenciosamente al cambiar de máquina.
Terraform siempre tiene una vista consistente de la infraestructura.
Lecciones aprendidas:
Este incidente fue mi culpa:
Confié demasiado en el agente de IA para ejecutar comandos de Terraform. Consideré que planificar, aplicar y eliminar eran tareas delegables. Esto eliminó la última capa de seguridad.
También confié demasiado en las copias de seguridad que asumí que existían. Las copias de seguridad automatizadas se eliminaron junto con la base de datos. No había probado completamente la ruta de restauración de extremo a extremo.
La base de datos era demasiado fácil de eliminar. No había suficientes protecciones para ralentizar las acciones destructivas.
Mientras esperaba la respuesta del soporte de AWS, tuve que considerar la posibilidad de que los datos se hubieran perdido permanentemente.
Para el curso activo de Ingeniería de Datos, donde los participantes están trabajando en los módulos finales, ya estaba pensando en un plan de recuperación. Para los cursos más antiguos, habría sido una pérdida permanente.
Afortunadamente, el soporte de AWS encontró una instantánea y restauró todo.
¿Qué cambia ahora? Las medidas de seguridad que implementé se mantienen.
Para Terraform:
Los agentes ya no ejecutan comandos.
Cada plan se revisa manualmente.
Cada acción destructiva la ejecuto yo.
Para AI Shipping Labs, estoy considerando usar una cuenta de AWS separada para desarrollo y producción para un aislamiento adecuado antes del lanzamiento.
En qué he estado trabajando recientemente:
- AI Engineering Buildcamp Terminé de grabar la sección de la plataforma de monitoreo DIY para el módulo de monitoreo en AI Engineering Buildcamp.
En la cohorte anterior, el módulo se centró principalmente en la creación de nuestra propia plataforma de monitoreo, con Pydantic LogFire como una opción secundaria. Para esta cohorte, cambié el enfoque a Pydantic LogFire porque es fácil de integrar, siendo el único desafío real la extracción de datos. Me aseguré de explicar cómo solucionarlo. La plataforma de monitoreo DIY todavía se incluye como una sección opcional de profundización.
También incorporé los comentarios de la cohorte anterior y ajusté el material en consecuencia. Las grabaciones de esta sección ya están listas.
Aún me falta completar un par de secciones del Buildcamp de Ingeniería de IA a finales de esta semana.
- Serie de Boletines de Ingeniería de IA Esta semana publicamos una nueva entrada como parte de nuestra serie de Boletines de Ingeniería de IA de los miércoles, donde analizamos más de 1000 descripciones de puestos de Ingeniero de IA de los principales centros tecnológicos del mundo para comprender cómo las empresas definen este rol actualmente.
Compartimos lo que aparece de forma constante en estas ofertas: los diferentes subtipos del rol de Ingeniero de IA, las responsabilidades que esperan las empresas, las habilidades y herramientas más comunes y los casos de uso prácticos para los que los equipos contratan.
3) Serie de Investigación en Vivo para Ingenieros de IA
El martes, presenté la tercera sesión en vivo de mi serie de eventos, titulada "Ingeniería de IA: El Proceso de Entrevista".
Compartí información basada en un amplio conjunto de datos de entrevistas reales. Analizamos qué esperan las empresas de los candidatos a Ingenieros de IA, los tipos de preguntas técnicas y conceptuales que suelen aparecer en las entrevistas y ejemplos de desafíos de programación en vivo.
Para preparar esta sesión, revisé más de 700 fuentes: informes, debates en Twitter y Reddit, y entrevistas en YouTube. De estas, extraje una gran colección de preguntas de entrevista y seleccioné las más relevantes. Una parte importante del trabajo consistió en filtrar, validar y categorizar este material.
La investigación también se publica y actualiza continuamente en la Guía de campo de ingeniería de IA en GitHub. Dale una estrella y compártela en redes sociales si te resulta útil. Puedes usar esta plantilla:
Encontré este repositorio de la Guía de campo de ingeniería de IA de Alexey Grigorev basado en datos reales (1765 descripciones de puestos + experiencias de entrevistas).
Ideal si te estás preparando para puestos de ingeniería de IA:
Descripción del puesto y habilidades
Preguntas de entrevista y tareas para casa
Rutas de aprendizaje e ideas de proyectos
https://github.com/alexeygrigorev/ai-engineering-field-guide/tree/main
El último evento de la serie, "Tareas para casa de ingeniería de IA", se transmitirá en vivo por Zoom el próximo lunes. En esta sesión, analizaremos qué les piden las empresas a los candidatos que desarrollen en casa e identificaremos los patrones detrás de estas tareas. Regístrate con anticipación para recibir el enlace de Zoom.
4) Presencial Taller
[  Taller de Apache Flink
El miércoles impartí un taller sobre Apache Flink para el Zoomcamp de Ingeniería de Datos con el fin de actualizar el módulo de streaming.
El material original fue creado por Zach Wilson, quien impartió un taller de Flink para el curso el año pasado. Alrededor del 80-90% del contenido del taller se basa en su material, actualizado para funcionar con Flink 2.x y versiones modernas de Python (3.12, 3.9, 3.8).
Dado que Flink no es mi área principal de especialización, me basé en el trabajo de Zach, que es muy sólido. ¡Gracias de nuevo, Zach, por el excelente material del taller!
Durante el taller, primero analizamos el ejemplo original de Zach y luego exploramos otro caso que involucraba agregación con marcas de agua y ventanas de pernos. La actualización del material requirió bastantes pruebas para asegurar que todo funcionara correctamente. Claude Code colaboró con las actualizaciones, aunque necesitó bastante orientación.
Herramientas
[
](https://github.com/getnao/nao)
nao es un framework de código abierto para la creación e implementación de agentes de análisis.
-
nao: un framework de código abierto para la creación e implementación de agentes de análisis que permiten Los usuarios consultan datos en lenguaje natural, manteniendo un control y una fiabilidad propios de la ingeniería. Los equipos de datos definen un contexto estructurado y versionado mediante la CLI, se integran con cualquier pila de datos, realizan pruebas unitarias de rendimiento y se autoalojan de forma segura con sus propias claves LLM. Los usuarios de negocio disponen de una interfaz de chat con visualizaciones nativas, razonamiento transparente y bucles de retroalimentación integrados, lo que facilita la comunicación entre la ingeniería analítica y la toma de decisiones.
-
Pilot Shell: un entorno de desarrollo profesional para Claude Code que integra las directrices de ingeniería directamente en el flujo de trabajo. En lugar de añadir una compleja estructura multiagente, aplica pruebas, análisis estático, formato y comprobación de tipos en cada edición, conservando el contexto entre sesiones. El resultado es una codificación basada en agentes con estándares de producción integrados, que permite a los desarrolladores delegar tareas, desconectar y volver a un código verificado y conforme a las convenciones, listo para su distribución.
-
rtk (Rust Token Killer): un proxy CLI de alto rendimiento que reduce el consumo de tokens LLM al filtrar y comprimir las salidas de los comandos antes de que entren en el contexto del modelo. En sesiones típicas de Claude Code, reduce el uso de tokens entre un 60 y un 90 por ciento en operaciones comunes como Git, pruebas, lectura de archivos y comandos de búsqueda, lo que disminuye significativamente el costo y mejora la eficiencia del contexto. Está diseñado específicamente para flujos de trabajo de desarrollo asistidos por IA, donde las grandes salidas de la terminal agotarían el presupuesto de tokens.
Recursos
[
](https://github.com/alexeygrigorev/ai-engineering-field-guide/tree/main)
Guía de campo de ingeniería de IA: un recurso basado en datos sobre el rol de la ingeniería de IA: habilidades, herramientas, preguntas de entrevista y aprendizaje. Rutas de aprendizaje
-
Guía de campo para ingenieros de IA: un recurso basado en datos sobre el rol de ingeniero de IA: habilidades, herramientas, preguntas de entrevista y rutas de aprendizaje, basado en descripciones de puestos reales y la experiencia de profesionales. Analiza lo que las empresas esperan de los ingenieros de IA, abarcando temas como responsabilidades, procesos de contratación, preguntas frecuentes en entrevistas y rutas de aprendizaje para diferentes perfiles. El proyecto se está convirtiendo en una referencia completa para quienes se preparan para una carrera en ingeniería de IA.
-
Marketing para fundadores: un centro de recursos prácticos y seleccionados, diseñado para ayudar a los fundadores técnicos a conseguir sus primeros 10, 100 o 1000 usuarios sin un gran presupuesto. En lugar de historias de crecimiento de alto nivel, ofrece guías prácticas sobre plataformas de lanzamiento, SEO (incluido LLM SEO y AEO), prospección en frío, contenido, precios, optimización de conversiones y validación de ideas. Sirve como punto de partida estructurado para desarrollar una estrategia de comercialización inicial basada en la ejecución, no en la teoría.
Editado por Valeriia Kuka