El desarrollador que borró producción en su primer día

En tu primer día de trabajo como desarrollador pueden pasar muchas cosas, pero unas de las peores es que borres toda la base de datos.

Leí hace unos días la historia de un desarrollador que entró a trabajar en una empresa como Junior Software Developer. En su primer día en la empresa tuvo que configurar el entorno de desarrollo, así que sus superiores le mandaron un documento donde le detallaban cómo debía crearlo. El proceso era bastante simple: ejecutar un script que, entre otras cosas, crearía una copia de la base de datos con datos de prueba. Tras crear esta base de datos, era necesario ejecutar los tests para comprobar que todo estuviera configurado correctamente.

El problema llegó cuando este desarrollador utilizó las credenciales de la base de datos de producción en lugar de las de su copia local. Al ejecutar los tests, llenó la base de datos con datos de prueba y borró los que habían. Conclusión: todos los datos de producción fueron borrados y el desarrollador fue despedido.

La respuesta por parte de la empresa y de su CTO fue fulminante. El trabajador fue despedido casi al instante, pese a que se ofreció ayuda. Incluso le amenazaron con emprender acciones legales contra él debido a la severidad del problema. Pero, ¿está justificado este comportamiento por parte de la empresa?

La comunidad habla: Gitlab y Amazon

No es la primera vez que una empresa pierde sus datos debido a un error humano. Y tampoco es algo ajeno a grandes compañías. A Gitlab le ocurrió algo parecido en Febrero de este año cuando alguien borró accidentalmente unas 6 horas de datos de sus bases de datos. La estimación que dio Gitlab fue que perdieron información de unos 5.000 proyectos, 5.000 comentarios y 700 nuevas cuentas.

Amazon también ha sido una de las empresas que ha sufrido este problema. En Diciembre de 2012, un desarrollador que tenía acceso al entorno de producción borró datos del estado del servicio de balanceador de carga ELB (Amazon Elastic Load Balancer) mientras realizaba tareas de mantenimiento.

El ingeniero de Gitlab que borró estos datos (yorickpeterse en Reddit) ha hecho un excelente comentario en el post de Reddit justificando que en realidad la culpa no ha sido del desarrollador, o al menos no del todo.

Si bien es cierto que el que borró los datos fue él, también hay que destacar que la empresa parecía no tener claros ciertos protocolos y aspectos de su base de datos:

  1. La empresa envió un documento con las credenciales de producción a una persona que está en su primer día.
  2. La empresa no creó un usuario de sólo lectura para este recién llegado; en su lugar le proporcionó acceso de administrador a toda la base de datos, cosa ilógica por otra parte ya que este solamente necesitaba leer la base de datos, no escribir en ella.
  3. La empresa crea entornos de desarrollo basados en la base de datos de producción, en lugar de tener un clon de la base de datos de producción lista para desarrollo.
  4. El CTO de la empresa culpa al nuevo desarrollador, en lugar de preocuparse porque esto no vuelva a ocurrir. De hecho, podría ocurrir de nuevo con un desarrollador que ya estuviera en plantilla simplemente porque “somos humanos”.
  5. Las herramientas utilizadas en el proceso de copia no comprobaron que la base de datos contra la que atacaba era la correcta.
  6. La empresa no asignó a nadie para guiar a esa persona en su primer día: simplemente un documento con datos de producción y a buscarse la vida.
  7. La empresa no tenía backups; de tenerlos hubiera sido tan fácil como restaurar todo tras el incidente.

Si un becario puede romper producción en su primer día, tu negocio está jodido

Si una persona entra a trabajar y en su primer día puede borrar toda una base de datos por accidente, esto quiere decir que tu proceso de desarrollo no está bien pensado. No parece lógico dar acceso completo para escribir, o permitir hacer despliegues de nuevas versiones de la aplicación a una persona que lleva 1 mes en la empresa. Al no conocer los procesos le va a ser muy fácil equivocarse. Y esto es algo para lo que una empresa que basa su negocio en el software debe estar preparado.

Algo tan simple como restringir qué puede hacer cada uno con los entornos, los datos y el código puede ahorrar muchos problemas. Y en caso de ocurrir, también debería existir un plan B para no entrar en pánico.

No hay una regla de oro para evitar que estos problemas ocurran. A todos nos ha pasado alguna vez que nos equivocamos y borramos la carpeta que no es, o sobreescribimos datos en la base de datos porque nos faltó poner una condición en la consulta.

¿Es un problema? Sí. ¿Es el fin del mundo? Para nada. Lo que hay que hacer para evitar esto es mantener copias de seguridad de todo lo que sea crítico para el negocio (código y datos, por ejemplo). También es importante establecer un protocolo en caso de tener que crear un nuevo entorno de desarrollo, ya sea para una nueva incorporación al equipo o simplemente porque hemos formateado y necesitamos instalar todo. Y más importante aún: hay que tener un plan por si algo pasa. Que en este mundillo del desarrollo software, ya se sabe: shit happens.

Enlaces relacionados

test