Estimados clientes de FinanzaPro,
Como Director Ejecutivo de FinanzaPro, quiero expresarles personalmente mis más sinceras disculpas por las interrupciones en el servicio que experimentaron el pasado sábado. Comprendemos completamente la importancia de nuestro software ERP para el funcionamiento fluido de sus operaciones diarias, y sabemos cuán disruptivo puede haber sido este incidente para sus negocios. Valoramos enormemente su confianza en nosotros y estamos comprometidos con la prestación de un servicio de la más alta calidad y confiabilidad. El incidente del sábado no estuvo a la altura de los estándares que nos hemos fijado y los que ustedes merecen. Les aseguro que estamos tomando todas las medidas necesarias para prevenir que un incidente como este se repita en el futuro.
A continuación les brindo detalles de lo sucedido y los cambios que hemos implementado para que no se vuelva a repetir.
Atentamente,
Arturo Monge
Director Ejecutivo de FinanzaPro
El día sábado empezamos a recibir reportes de los usuarios indicando que tenían muchos problemas para imprimir. Al principio, el problema era bastante constante, y luego de varios ajustes por parte de nuestro equipo el problema se convirtió en moderadamente intermitente. Posteriormente, hubo un periodo de 30 minutos en el que no fue posible facturar en absoluto, y al final del día, persistió el problema de impresión de facturas de manera moderadamente intermitente. Esta situación afectó tanto la impresión de facturas desde nuestras aplicaciones, como la generación de facturas y órdenes de pedido en integraciones externas a través de nuestra API.
Normalmente, este problema se habría resuelto muy rápidamente, pero se presentaron dos errores en nuestro proceso habitual de actualización, lo que llevó a un problema mayor, como el experimentado el sábado.
El día viernes, se llevó a cabo una actualización en producción tanto en los servidores de aplicaciones "legacy" como en los servidores de reportes "legacy". Hace más de un año que no tocábamos o actualizábamos los servidores de reportes, pero esta actualización incluía varios cambios en cómo se almacenan las configuraciones de nuestros servidores, ya que necesitábamos incorporar 'secretos' (usuarios y contraseñas a otros servicios internos) dentro de la configuración, lo que nos obligó a actualizar también los servidores de reportes "legacy". Tras realizar las pruebas correspondientes, todo funcionaba normalmente. Como el cambio era de configuración, no sospechamos que se fueran a tener problemas como los experimentados el día sábado.
El sábado, comenzamos a recibir reportes de los usuarios sobre problemas con la impresión de facturas, así que iniciamos el proceso normal de reversión de una actualización problemática. Sin embargo, cuando intentamos revertir los servicios de reportes a la imagen anterior, nos dimos cuenta que una política mal configurada de limpieza de imágenes antiguas había borrado durante la madrugada la imagen anterior y cualquier imagen previa también. A partir de este momento, el problema se incrementó considerablemente porque teníamos un servicio que estaba colapsando con la carga normal de uso de la plataforma, sin poder volver a la imagen anterior. Intentamos varios procesos para recuperar la imagen y evaluamos varias opciones para reconstruir la imagen anterior, pero al ser una imagen antigua, su reconstrucción iba a requerir mucho trabajo que decidimos invertir mejor en averiguar la causa del problema.
Durante estas situaciones, la prioridad número uno de nuestro equipo es estabilizar la plataforma si es posible, y en segundo lugar, encontrar la causa del problema. Sabíamos que había un problema de carga, ya que el servicio de reportes estaba experimentando un uso del 100% de la CPU de los servidores. Por lo tanto, procedimos a agregar más infraestructura al servicio para manejar la carga y reducir el uso de la CPU. No obstante, notamos que esto no resolvía el problema. Sin importar la cantidad de infraestructura que agregáramos, los servicios de reportes seguían utilizando el 100% del CPU de los servidores, provocando cuellos de botella, largos tiempos de espera y fallos en los indicadores de salud de los servidores, lo que causaba que la plataforma estuviera constantemente reemplazándolos, generando un ciclo sin fin. En un momento dado, habíamos agregado 240 nuevos servidores al servicio, pero logrando únicamente una solución parcial.
Al revisar todas las bitácoras, y ya por la noche cuando pudimos hacer pruebas sin la carga masiva que se genera durante un sábado de uso normal de la plataforma, detectamos que por alguna razón, la generación de reportes en la nueva imagen de la actualización estaba requiriendo una cantidad considerablemente mayor de recursos que la imagen anterior. Esto hacía que generar los reportes tomara mucho más tiempo, causando que los servidores no pudieran procesarlos con suficiente velocidad, lo que saturaba las colas de trabajo y disparaba el uso de la CPU de los servidores al 100%, ralentizando todo el proceso. Los servicios estaban experimentando un problema de “thread starvation” o “inanición de hilos”, el cual se define como una situación en programación concurrente donde un hilo (thread) de ejecución no obtiene el tiempo de CPU que necesita para realizar su tarea debido a que otros hilos están consumiendo demasiado tiempo de CPU,
Creemos que el segundo error de nuestra parte que causó el problema es que esa imagen anterior tenía alguna configuración u optimización especial que nunca fue documentada, por lo que el equipo que atendió la emergencia no sabía por qué la imagen actual estaba causando problemas.
Una vez que tuvimos una mayor claridad sobre la causa del problema, hicimos ajustes en la configuración de la infraestructura asignada al servicio de reportes "legacy", de manera que las colas de trabajo de generación de reportes pudieran procesar todas las solicitudes con la velocidad esperada, brindando así un servicio normal en la generación de reportes de facturas.
Además, decidimos crear infraestructura separada para los tres casos de uso que tenemos para la generación de reportes de facturas: para los usuarios que facturan a través de las aplicaciones de FinanzaPro, para los reportes generados por servicios internos y para las integraciones externas a través de las API. De este modo, ahora cada uno de estos casos de uso tiene infraestructura propia y separada, con indicadores de carga y procesos de autoescalamiento separados.
A nivel de las imágenes, corregimos las políticas de limpieza de imágenes. Además, implementamos como proceso que los servicios de reportes legacy se mantengan actualizados al mismo tiempo que actualizamos otros servicios, para evitar tener una imagen muy antigua que no podamos reconstruir de manera rápida y sencilla en caso de que se perdiera por alguna razón.
Con estos cambios (infraestructura, corrección de políticas de limpieza de imágenes, y política de mantener todas las imágenes sin excepción siempre al día) nos aseguramos de que el problema no vuelva a presentarse.
Para concluir, queremos expresar de nuevo nuestras más sinceras disculpas por las interrupciones y los inconvenientes que este incidente pudo haber causado en sus negocios. Entendemos la importancia crucial de nuestro software en sus operaciones diarias y nos tomamos seriamente cualquier perturbación en su funcionalidad. Hemos realizado cambios significativos en nuestra infraestructura y en nuestras políticas para prevenir la recurrencia de este tipo de problemas. Nuestro compromiso con ustedes es firme y reiteramos nuestra dedicación para proporcionar un servicio de calidad y consistente en el que puedan confiar. Agradecemos su paciencia y su lealtad durante este incidente, y continuaremos trabajando incansablemente para fortalecer y mejorar nuestra plataforma para servirles mejor.