Muy pocos de nosotros en la industria del alojamiento web tendremos la necesidad de escalar al nivel que hacen servicios como Dropbox. Dicho esto, cuando un servicio del tamaño de Dropbox da un paso en falso que conduce a una interrupción, vale la pena prestar atención a las causas y al impacto para ver si hay posibles lecciones que aprender.
El 10 de enero, Dropbox se desconectó. Los usuarios no podían sincronizar sus carpetas y, por lo tanto, no podían acceder a sus archivos en muchos dispositivos. El servicio estuvo inactivo durante gran parte del viernes por la noche, y los usuarios tuvieron problemas para acceder a sus archivos durante todo el fin de semana.
Por supuesto, los medios de comunicación estaban llenos de especulaciones sobre las posibles causas de la interrupción, y muchos se centraron en un posible ataque DDoS. El lunes siguiente, Dropbox lanzó una declaración que entró en detalles sobre las causas de la interrupción, que rechazó la idea de un ataque de hackers y en su lugar culpó a un proceso de actualización defectuoso.
El día de la interrupción, Dropbox estaba ejecutando una copia de seguridad programada del sistema operativo. Como puede imaginar, actualizar los miles de servidores que utiliza Dropbox no es una tarea fácil. Gran parte del proceso está automatizado con scripts, que pueden haber sido la causa del tiempo de inactividad.
La lección clave aquí, como detalla el Jefe de Infraestructura en Dropbox, Akhil Gupta, es que si va a realizar una actualización, debe estar absolutamente seguro de en qué estado se encuentra el servidor. Para evitar que vuelva a ocurrir el mismo error, Dropbox implementó un nivel adicional de comprobaciones, para que el servidor verifique su propio estado antes de ejecutar comandos, en lugar de ejecutar ciegamente las instrucciones entrantes, independientemente de lo que esté haciendo cuando las reciba.
No se menciona en la autopsia del incidente, pero la interrupción probablemente podría haberse evitado con pruebas más rigurosas. La interrupción de Dropbox es un recordatorio de lo que puede suceder cuando una empresa está escalando rápidamente su infraestructura. La escala se convierte en el objetivo principal, y las pruebas quedan en el camino hasta cierto punto.
Un enfoque más riguroso para probar y verificar los scripts de automatización puede haber detectado el "error sutil" antes de que causara estragos.
Acerca de Graeme Caldwell: Graeme trabaja como vendedor entrante para InterWorx, un panel de control de alojamiento web revolucionario para hosts que necesitan escalabilidad y confiabilidad. Siga a InterWorx en Twitter en @interworx, Como ellos en Facebook y mira su blog, http://www.interworx.com/community.
