Hoy ya hace más de 13 años que inicié mi carrera profesional como desarrollador de software; como podrás calcular, hace 13 años, la información no era tan libre como lo es ahora, era mucho más difícil encontrar información sobre sistemas y programación en general.
Eso sumado al nivel de penetración que tenía el internet y el hecho de que tener una computadora en casa, para la mayoría de familias, era algo realmente difícil. Por sus precios, disponibilidad y, si era como en mi caso, por la zona donde vivías, quizás era más difícil aún.
¿Pero… cómo es que borraste una base de datos completa sin antes hacer backup?
Hace 13 años, cuando se pensaba en desarrollar un sitio web, muy probablemente se pensaba en usar WordPress o Joomla para desarrollarlo; era raro y hasta extraño el sitio web que no operaba con alguno de estos CMS.
Justo para esa época, se popularizó el uso de hosting compartido, que no era más que un servidor que corría un software (cPanel en la mayoría de los casos) que permitía asignar recursos a diferentes usuarios dentro de un mismo servidor.
Tener una cuenta cPanel era como tener un apartamento alquilado en un edificio; una empresa te ofrecía un segmento pequeño dentro de un servidor dedicado o VPS que ellos administraban, y tú compartías recursos con otros usuarios, como la IP, RAM, storage (entre otras cosas) y podías alojar allí tu sitio web con LAMP (Linux, Apache, MySQL y PHP) sin mayor problema.
¿Por qué no hice backup?
Esto tiene muchas posibles respuestas, y los que vivieron esa época lo pueden tener más claro, pero los que no tuvieron la oportunidad, en esa época los backups eran:
Era muy costoso; tener una cuenta con unos pocos megas ya era algo estándar y, cuando se tenía presupuesto, se contrataba más almacenamiento para poder alojar pesados archivos Flash u otros archivos multimedia.
No todos los proveedores lo ofrecían; de hecho, el tener opciones de backup (bien sea manual o automático) no estaba disponible en las primeras versiones de algunos paneles de gestión (como cPanel), por lo que muchos lo que hacían era descargarse un .sql de toda la base de datos y copiaban el código mediante FTP.
El flujo de desarrollo no tenía stages; hoy en día es imposible pensar en algún sistema que no tenga tan siquiera un ambiente adicional al de producción. Pero en esa época, hablando claramente: si no te alcanzaba para un sistema de backup, menos para una cuenta adicional donde tener una réplica para desarrollo.
Falta de interés en presencia web: Aunque puede que hoy sea diferente en muchos sentidos, hace 13 años tener un sitio web era “un lujo” de algunos negocios que podían permitirse tener presencia en internet. Los costos asociados a tener y mantener un sitio web hacían que muchos prefirieran publicitarse en radio, televisión o incluso Páginas Amarillas y Guías Telefónicas.
¿Qué sitio web era… y cómo lo restablecí?
El sitio web era de una estación de radio en la que trabajaba en ese entonces; vale destacar que desde los 8 años hasta los 23 años mi vida estuvo muy ligada a la radio, televisión y medios de comunicación masiva.
Recuerdo que esos eran de los pocos clientes que existían para este tipo de tecnología para ese tiempo, ya que con el auge de los sitios web, los servicios de streaming para estaciones de radio también se popularizaron mucho.
Principalmente, las estaciones de radio miraban de cerca la posibilidad de extender su cobertura y ampliar su masa de oyentes y clientes mediante estos canales digitales, no solo a nivel de streaming, sino también en las noticias que se podían publicar allí.
¿Por qué borré la base de datos?
Recuerdo que fue porque el cliente lo necesitaba; tenía otra página web alojada en su cuenta de cPanel. En ese tiempo, algunas personas hacían este tipo de cosas: un usuario contrataba una cuenta para 2 o 3 sitios web en cPanel y podía desarrollar varias páginas web dentro del mismo alojamiento.
Esto puede sonar contradictorio, pero por eso digo “algunos”, y estas personas tenían muchos motivos para tener cuentas con la posibilidad de tener 2 o 3 sitios web. Recuerdo que en ese entonces, esto lo hacía porque con el proveedor que tenía ofrecía cuentas con streaming incluido para los que pagaran este tipo de cuenta. Y sí, era más valioso que tuvieran un backup y no 6 páginas, pero ¿qué les puedo decir?, así eran esos tiempos.
En este caso puntual, la estación de radio tenía una web principal que yo desarrollé y necesitaban una segunda web para usarla de sitio web exclusivo para móviles (recuerden que eran años previos al 3G, y los famosos dominios m.turadio.com, lo normal de la época).
¿Dónde surgió el problema?
Esta nueva web que yo realicé no necesitaba una web exclusiva para celulares móviles, porque la que yo desarrollé ya tenía soporte para eso; yo analizaba los headers y, según el navegador y OS, entregaba una web u otra desde el mismo WordPress, y eso era muy potente para la época. Ya que no necesitaba subdominios o cosas adicionales, incluso se adaptaba según el navegador o resolución de pantalla.
Recuerden que en ese entonces el rey de los navegadores en móviles era Opera Mini, y los exploradores de los nuevos Android (en ese época nuevos aún) eran muy diferentes a Opera Mini, y eso hacía las diferencias entre las webs; casi que se desarrollaba una web para cada navegador y dispositivo.
El borrado ocurrió justamente porque en las bases de datos en cPanel tenían nombres similares, algo como: turadio_web101radio y la otra base de datos era algo como turadio_w3b101radio. Ya que para ese entonces se usaba una herramienta llamada Softaculous, que aún hoy en día existe y es usada para generar las instancias de WordPress y otras herramientas.
No solo yo la usaba, sino quizás quien hizo esa primera versión de la web, y por eso quizás se generó similar el nombre de las bases de datos. Lo que me confundió y terminé borrando la base de datos equivocada.
¿Fue muy costoso reestablecerlo?
Aquí viene el giro de la historia, porque la verdad no fue tan complejo, y aunque en ese entonces yo acostumbraba a trabajar 100% live, es decir, todos los cambios se realizaban directamente sobre el sitio web en producción, este era un proyecto que tenía relativamente poco funcionando. Cerca de 3 meses para ese momento, si mal no recuerdo bien.
En ese entonces yo usaba un viejo laptop VIT (Venezolana de Industria Tecnológica) para desarrollar, y en ese i3 de 2-3.ª generación con XAMPP correctamente (sí, olvídate de Docker, en ese entonces XAMPP era la forma y el método ideal) ejecutaba el desarrollo base de plantillas y plugins.
A los 17 años, realmente ya tenía como 10 años programando. Recuerdo que mi primer “sistema” estaba escrito en C, y era una calculadora desde terminal que logré copiar de una enciclopedia vieja y desarrollar en una IBM con Windows 2000 que tenía en mi casa. En esa enciclopedia se explicaba algo de sistemas, y en ella estaban capturas de pantalla de cómo hacerla, pero no se confundan, no estaba todo el código, solo capturas de algunos segmentos.
Así que siempre tenía una “base” de los datos a modo de demostración en mi laptop, así que eso sirvió mucho. Pero creo que más que eso, sirvieron muchísimo algunas acciones que tuve, como:
Comunicar correcta y eficientemente lo que pasó: Recuerdo que en ese momento me dije algo como: “No importa lo que pase, los llamo y les digo que borre la base de datos”.
Serenidad y control de daños: No se debe confundir estar sereno con “no importa”; son dos cosas totalmente diferentes. Cuando estás sereno, puedes medir y tomar acciones de forma más correcta; eso facilita el control de daños y poder dar soluciones realmente eficientes.
Compromiso con una solución real: porque justamente no todas las soluciones son las más eficientes o indicadas para una solución real; por eso es importante tener claro lo que se quiere lograr y, según eso, desarrollar una forma de hacerlo funcionar.
Asumir consecuencias: Creo que sin esto no hubiera podido llegar a donde estoy, pero recuerdo que en ese momento lo primero que tenía claro era que iba a tomar las consecuencias de lo que pasó y solucionarlo.
La primera desvelada profesional que tuve
Sí, no les voy a mentir diciendo que mágicamente pude hacer algo que solucionó todo y resolvió el problema; eso no pasó y, por ganar más lectores, no diré lo contrario. Recuerdo que fue la primera vez como programador ya profesionalmente; me quedé toda la noche despierto restableciendo todo.
Y no se confundan, digo que fue la primera vez porque antes lo hice, pero solo por diversión, y en esta ocasión fue porque tenía claro que era un compromiso profesional que cumplir antes con quien me contrató para desarrollar su sitio web.
Terminando de ajustar y reconstruir todo unas 10 horas luego, ya que todos los archivos y scripts quedaron intactos, pero temas relativos a ajustes, configuraciones y personalizaciones se perdieron.
Cosas que cambiaron desde ese día
Muchas, la verdad, no les voy a mentir, creo que, además de anecdótica, esa experiencia fue traumática, y la forma en la que desarrollaba cambió desde ese día.
Fueron varias, pero pueden detallarse en:
Sin documentación, es imposible avanzar: sé que es quizás algo burocrático, pero esto es indispensable en todo proceso. Si quieres que algo salga bien, primero documenta; eso te sirve para aclarar tus ideas y dejar claro cómo van a ser las cosas desde el inicio.
Todo Plan A debe tener un Plan B: no importa el cambio que realices, siempre tienes que tener la noción clara de lo que puede llegar a fallar, y debes tomarte el tiempo de tener un plan de respaldo en caso de que no salga como esperas.
Confía en ti siempre: si te fijas, solo tenía 17 años, y excluirme en eso posiblemente no me hubiera llevado a donde estoy, porque sin compromiso y profesionalismo es imposible que alguien crea en ti. Nadie creerá en ti si tú mismo no lo haces primero, bajo cualquier circunstancia.
Pero eso nada más no es suficiente; recuerda siempre estar en lugares donde puedes cometer errores sin miedo a perder tu empleo solo por eso, y sí, esto tiene asteriscos, no es que todo lo que hagas va a estar mal, pero es importante que siempre comuniques las cosas de forma clara y eficiente.
Si estás comunicando todo oportunamente, y siguiendo todo según la documentación y convenciones, lo esperado es que, si algo llega a fallar, puedas tener la oportunidad de identificar el fallo, documentarlo y adquirir la experiencia suficiente para que este tipo de cosas no pasen nuevamente.