Como propietario de Simple Analytics, creo que es muy importante generar confianza en el usuario. Es casi imposible no cometer errores, así que si una empresa nunca comparte sus errores, probablemente no te esté diciendo la verdad. Por lo tanto, aquí están los míos.
Cuando estás creando una nueva funcionalidad, probablemente quieres desplegarla lo más rápido posible porque estás demasiado emocionado por enseñársela a tus clientes. O a veces estás añadiendo un nuevo servicio a tu servidor y no sabías qué tipo de implicación podría tener. Esto último me ha pasado a mí.
En el último par de semanas desplegué una nueva característica llamada Dominio personalizado. Esta función permitía a los usuarios de Simple Analytics eludir los bloqueadores de publicidad y de seguimiento. Creo que la gente debería poder bloquear el seguimiento, por lo que Simple Analytics respeta la configuración "Do Not Track" del navegador. Lamentablemente, Simple Analytics ha sido incluido en algunas listas de bloqueadores de privacidad, lo que no me parece justo, ya que nos tomamos la privacidad muy en serio (trasladamos los servidores a un país muy respetuoso con la privacidad: Islandia; encriptado nuestro servidor de base de datos; Elimina los datos de la base de datos cuando un usuario borra algo; permitiendo a la gente a descargar sus datos). Así que la nueva función fue muy bien recibida. Una vez desplegada, algunos usuarios empezaron a utilizarla.
Hoy he encontrado un error (afortunadamente por mí mismo) al utilizar la función de dominio personalizado en el que el JavaScript se cargaba, pero la llamada a la API pedía una contraseña. Busqué uno de los sitios web de mis clientes ([excuseme.wtf](https://excuseme.wtf/?ref={{ site.hostname }})) que sé que estaba utilizando la función de dominio personalizado. Comprobé sus estadísticas y me horroricé al ver que no había ninguna visita en la última semana. Inmediatamente empecé a indagar en mis servidores, en busca de pistas.
Configuración actual
Simple Analytics utiliza 4 servidores para que todo funcione lo mejor posible. Tenemos el Queue-server, que es el servidor para recoger las visitas de nuestros JavaScripts. Este es un servidor diferente del servidor principal porque el servidor principal está encriptado. Si un servidor está encriptado sólo debería arrancar después de introducir una contraseña (de lo contrario la encriptación es inútil). En el improbable caso de que sea necesario un reinicio, quiero garantizar cero pérdidas de datos. Todos los datos serán enviados al servidor de cola que los enviará al servidor principal. Si el servidor principal no acepta la solicitud, el servidor de cola "pondrá en cola" (guardará) la solicitud cuando el servidor principal esté realizando una copia de seguridad.
Además de estos servidores, tengo un servidor de pruebas y un servidor externo. El servidor de pruebas ejecuta pruebas de aceptación para supervisar flujos y puntos finales importantes. El servidor externo es necesario para la función de dominio personalizado. Debido a la separación de preocupaciones, no quiero tener certificados SSL de clientes en el mismo servidor que el servidor principal por razones de seguridad.
¿Qué fue mal?
Decidí instalar una nueva aplicación de monitorización en el servidor de colas, de esta forma podía comprobar remotamente si había algún problema en el servidor. También me daba información sobre el uso de CPU y memoria. Añadí un archivo de configuración NGINX para esta aplicación para poder acceder a ella desde el exterior. Cuando añado una nueva aplicación siempre pruebo la configuración de NGINX y la recargo cuando tiene éxito sudo nginx -t && sudo nginx -s reload. NGINX no dio ningún error por lo tanto, pude acceder a mi recién instalada app de monitorización; estoy contento.
Por suerte, tengo un directorio/registros de logs de NGINX, desde donde puedo recuperar la mayoría de las peticiones perdidas. Estos registros contenían menos información en ese momento y sólo registraban la hora, la URL y el agente de usuario.
¿Qué he hecho para evitar que esto vuelva a ocurrir?
Aunque este fallo no afectó a muchos clientes y no hubo una pérdida de datos significativa, quiero hacer todo lo posible para evitar que vuelva a ocurrir en el futuro. El error se creó al añadir otra aplicación al mismo servidor que no tenía ninguna directiva de servidor definida como servidor predeterminado. NGINX entonces hace lo posible por seleccionar un servidor como servidor por defecto y envía las peticiones a la app definida en ese servidor.
En primer lugar, he añadido el servidor por defecto a la directiva listen para los puertos 80 y 443 en la aplicación principal(nginx docs). La app principal en ese servidor era la app externa que gestiona los certificados para el Custom domain-feature y responde con un script y el API endpoint no usa URLs de Simple Analytics lo que lo hace difícil de bloquear.
En segundo lugar, aumenté el historial de registro a 90 días para poder recuperar las visitas para futuros problemas. El Queue-server y el Main-server ahora registran cada petición fallida por cualquiera. Esto significa que cada petición que devuelva un código HTTP 5xx o 4xx se guardará en los registros y se podrá recuperar a partir de ella. Requerirá bastante trabajo hacerlo si es necesario, pero significa que no hay pérdida de datos.
He añadido pruebas de aceptación para la característica de dominio personalizado que comprueba si ambos puntos finales siguen funcionando como se esperaba. Si no cumplen, recibiría una llamada telefónica y un mensaje de Telegram.
Por último, voy a etiquetar las nuevas funciones como "versión beta", para que los clientes sean conscientes de que pueden tener errores, ya que no se han completado para la versión final. Por lo tanto, depende de los clientes arriesgarse y utilizar la función bajo su propia responsabilidad.
Me he puesto en contacto con los clientes afectados por este error y les he ofrecido devolverles el dinero del mes. No lo consideraron necesario y me dijeron que no me preocupara. Hice todo lo que pude para recuperar la mayoría de sus datos y, con todas las medidas anteriores, estoy bastante seguro de que esto no volverá a ocurrir.
Cambiemos la transparencia en torno a los errores y creo que la gente se tomará tu negocio más en serio. Demuestras lo que hiciste al respecto y lo capaz que eres. Algunas personas discutirían si es inteligente, pero yo lo veo como una oportunidad para mostrar transparencia.