#8 – Cómo envié 80.000 emails por error en prod

El peor error que he cometido en mi carrera

Nunca he sido fan de prohibir despliegues los viernes. Y lo sigo pensando, una organización madura debería poder desplegar cuando lo necesite. Pero curiosamente el mayor problema que causé en mi carrera fue en ese dichoso día xD.

Desplegamos una nueva web en el CRM interno en Salesforce, y como todo se veía bien cerré el portátil y me fui a dar un paseo. Al volver, tenía miles de mensajes y correos. Recibía tantos que mi cuenta de Gmail se bloqueó, mi Slack iba a pedales y el sistema de seguridad anti-spam de la empresa se cayó.

No tenía ni idea de la que había liado, y mi equipo ya estaba trabajando en ello para parchear la situación lo antes posible.

---

Esta entrega de Status 418 está patrocinada por @DanielBlancoSWE (yo xD)

Mis cursos de Udemy están al mejor precio disponible! Aprovecha las rebajas para aprender más sobre las bases de la ingeniería de software.

🔹 Arquitectura Software Avanzada: Más Allá de los Patrones

🔹 El Camino a Senior: Claves para el Éxito como Programador

🔹 Diseño de Sistemas a Gran Escala

🔹 Arquitectura Software Moderna: DDD, Eventos, Microservicios

🔹 Principios SOLID y Clean Code. Escribe código de calidad.

🔹 Algoritmos, Estructuras de Datos y Entrevistas Programación

---

El preludio

Estábamos construyendo un buscador interno para todo lo que necesitaban los empleados de Salesforce. Para ello, se integraba con el CRM de la empresa para obtener información de todo tipo.

Para esa web se usaron tecnologías relativamente modernas, casi todo Java y React. Se hacían llamadas a las APIs de la plataforma para obtener la información necesaria. Pero, para ciertas funcionalidades, eso no era suficiente.

Una de esas funcionalidades era el chat de soporte. Si tenías alguna urgencia, como por ejemplo problemas con tu portátil, podías abrir un chat directamente con el servicio técnico. Salesforce proporciona esta funcionalidad de forma nativa en la plataforma, pero no a través de APIs.

Para implementar esta funcionalidad me asignaron a mí. Con cero experiencia como desarrollador de Salesforce a mis espaldas, no fue una tarea sencilla. La solución final fue implementar un Salesforce Site (web nativa de la plataforma) únicamente con el código necesario para que el chat de soporte cargase, y después incrustarlo en nuestra web principal mediante un iframe.

Cuando se completó el trabajo, se desplegó a producción el site nativo antes de lanzar nuestra plataforma.

El día D

Llego del paseo y entro en panic mode. ¿Por qué estaba recibiendo mensajes y correos de miles de empleados sin parar? Me conecto a la llamada con mi equipo y me explican la situación.

Se había enviado un correo a los 80,000 empleados de Salesforce de forma automática al desplegar el site. Resulta que los sites nativos de Salesforce tienen una opción por defecto de enviar un email de bienvenida a los usuarios con acceso (en nuestro caso, toda la empresa). Hasta el CEO, Marc Benioff, recibió mi correo electrónico.

Para empeorar la situación, el nombre de la web era bastante críptico, la plantilla de bienvenida era la predeterminada y los correos salían a mi nombre, pero con un dominio custom, porque había sido yo quien desplegó esa web. Eso hizo que los usuarios reportaran el email y, de tantos reportes y respuestas a mi correo, el sistema de seguridad interno se cayó.

El equipo, lejos de buscar culpables, se puso manos a la obra para solucionar el problema. Mi manager habló con el equipo de seguridad para que descartasen un posible ataque, y contactó con un compañero que tenía acceso a producción en Google Workspace para eliminar el correo de la bandeja de entrada de los empleados y así evitar que el caos siguiera aumentando.

Yo me puse a analizar si podría haber otros casos en los que se enviasen correos electrónicos automáticos desde el site. Por suerte, encontré un par de casos antes de que causaran más problemas. Los desactivamos y desplegamos el parche al momento en producción.

Qué saqué de este incidente

Afortunadamente, el daño causado fue muy pequeño porque los usuarios eran solamente internos de la empresa. Pero, si en lugar de ser un site interno, hubiera sido algo con clientes reales de Salesforce, el daño reputacional podría haber sido mayor.

Es imposible saber lo que no sabes. Al ser nuevo en el desarrollo de Salesforce, era difícil que supiese que existían esos correos automáticos. La mayor lección aprendida fue que toda precaución es poca cuando tratas con algo nuevo. Y más aún, cuando es un despliegue a tal escala.

En lugar de desplegar el site con todos los usuarios asignados, habría sido más inteligente hacer una prueba con nuestro equipo únicamente, y testear todo más a fondo. Nosotros sólo hicimos pruebas en QA, donde esos correos estaban desactivados por defecto.

Otro punto que me llevé de esta experiencia es la importancia de tener un equipo que te apoye. Nunca nadie me echó la culpa. Al contrario, me animaron y me ayudaron desde el primer minuto. Me recordaron también que el desarrollo de software es un trabajo de equipo y, aunque uno pueda provocar directamente un problema, el equipo también es responsable de revisar.

Sigo pensando que no se deberían prohibir despliegues los viernes. Pero a partir de ese momento también sé por qué muchos equipos deciden no hacerlo xD

---

Y recuerda echarle un vistazo a mis cursos para aprender más sobre las bases de la ingeniería de software.

🔹 Arquitectura Software Avanzada: Más Allá de los Patrones

🔹 El Camino a Senior: Claves para el Éxito como Programador

🔹 Diseño de Sistemas a Gran Escala

🔹 Arquitectura Software Moderna: DDD, Eventos, Microservicios

🔹 Principios SOLID y Clean Code. Escribe código de calidad.

🔹 Algoritmos, Estructuras de Datos y Entrevistas Programación