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?
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:
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.