4 lecciones que aprendimos de nuestra última actualización de infraestructura

Publicado: 2022-05-04

Actualización de infraestructura. Una tarea común, especialmente para una empresa SaaS como la nuestra, ¿no?

Bueno, la última no fue la típica actualización de software, ya que le agregamos un pequeño giro.

El objetivo principal era actualizar nuestro software a la última versión, pero esta vez hemos incluido dos pasos más en el proyecto: reducir la cantidad de IP que nuestros clientes deben incluir en la lista de permitidos y lograr la redundancia de la base de datos.

Y aunque la mayor parte de la actualización se realizó sin problemas, también experimentamos algunas interrupciones del servicio en el camino.

En las siguientes líneas, compartiremos información tras bambalinas sobre por qué realizamos la actualización, cómo fue y cuáles son nuestros principales aprendizajes.

¡Vamos a hacerlo!


Por qué realizamos la actualización en primer lugar y qué incluía

Entendemos la responsabilidad que tenemos y el papel que juega NitroPack en el éxito de los negocios de nuestros clientes. Es por eso que garantizar un rendimiento óptimo, los más altos estándares de seguridad y la estabilidad del servicio las 24 horas del día, los 7 días de la semana, son cruciales.

Actualizar nuestra infraestructura regularmente es una de las muchas maneras de garantizar todo eso. Y como se mencionó anteriormente, había tres partes en esta actualización en particular:


1. Actualice nuestro software a la última versión estable

Como solución basada en la nube, todas las optimizaciones que realiza NitroPack para nuestros más de 100 000 sitios de clientes se realizan en nuestra infraestructura. Actualmente, utilizamos más de 100 servidores para ejecutar el servicio. Con esta actualización, tuvimos que actualizar el software que orquesta nuestra flota de servidores a la última versión estable.


2. Reducir la cantidad de IP que nuestros clientes deben incluir en la lista de permitidos

En pocas palabras, nuestro proceso de inclusión de direcciones IP permitidas no era fácil de usar.

Antes de la actualización, nuestros clientes tenían que incluir en la lista blanca más de 40 direcciones IP que atendían el tráfico saliente (solicitudes) de NitroPack a los sitios de los clientes. Además de eso, estas direcciones IP no se repararon, lo que significa que cuando uno de nuestros servidores se retira, aparece uno nuevo con una dirección IP diferente.

Este proceso de generación de nuevas direcciones IP requería que nuestros clientes incluyeran docenas de nuevas direcciones en la lista blanca para que NitroPack optimizara con éxito sus sitios.

Después de la actualización, nuestros clientes deben incluir en la lista de permitidos solo tres direcciones IP fijas que nunca cambien.


3. Logre la redundancia de la base de datos

Durante mucho tiempo, queríamos lograr la redundancia de la base de datos, ya que mejoraría el rendimiento general del sitio web y el panel de control de NitroPack, y podríamos mejorar la seguridad del servicio. Además, esta actualización nos permitiría realizar futuras actualizaciones de la base de datos sin tiempo de inactividad.

Con estos objetivos en mente, dividimos el proceso en dos pasos, dejándonos un día entre los dos para que tuviéramos un buen respiro:

Paso 1: (4 de noviembre): Reducir el número de IP
Paso 2: (6 de noviembre): redundancia de la base de datos y actualización del software del servidor

Pero no todo salió de acuerdo a nuestras expectativas.


Lo que no salió según lo planeado

A pesar de nuestra minuciosa preparación, enfrentamos algunos problemas inesperados en las tres actualizaciones. Esto es lo que sucedió:

Problema #1: problemas de conectividad durante el proceso de actualización de IP

El 4 de noviembre, teníamos programado realizar una actualización preliminar del servicio, con el objetivo de reducir la cantidad de direcciones IP para el tráfico saliente de NitroPack.

El lanzamiento inicial tenía un error de software interno que no permitía que nuestro servicio creara conexiones salientes en algunos casos. Desafortunadamente, este problema solo apareció cuando nuestra infraestructura experimentó situaciones de tráfico pico. Es por eso que no detectamos el problema en nuestro entorno de prueba durante las pruebas iniciales. El problema de conectividad provocó que NitroPack no realizara las optimizaciones salientes de manera confiable y algunos de nuestros clientes experimentaron inestabilidad en el servicio durante un par de horas.

La buena noticia es que nuestro equipo de desarrollo logró mitigar el problema rápidamente al actualizar el software de nuestro cliente HTTP.


Problema nº 2: la copia de seguridad de la base de datos tardó más de lo estimado

Cuando comenzamos a trabajar en la redundancia de la base de datos el 6 de noviembre, rápidamente descubrimos que tomaría mucho más tiempo de lo planeado. Esto nos obligó a impulsar la actualización del software del servidor un día después.

Pero fue con buenas intenciones en mente. En primer lugar, queríamos ser extremadamente cautelosos con la copia de seguridad de la base de datos para poder realizar la redundancia sin ningún problema.


Problema n.º 3: un error del servidor ralentizó el proceso de actualización del software

Cuando comenzamos a implementar la actualización del software del servidor el 7 de noviembre, una pequeña cantidad (menos del 1 %) de los servidores comenzó a generar errores inesperados que finalmente impidieron que se implementara la actualización y ralentizaron todo el proceso. No había forma de solucionar los problemas nosotros mismos y nos vimos obligados a escalarlo a nuestro proveedor de servidores.

Aunque parece un pequeño contratiempo, considerando la magnitud de la tarea, este error inesperado provocó que una pequeña parte (menos del 2 %) de los clientes de NitroPack experimentara un tiempo de inactividad breve e intermitente del servicio.


Problema n.° 4: errores inesperados de CDN 502 causaron inestabilidad en el servicio

Cuando pensamos que habíamos terminado con la actualización, nuestro sistema de monitoreo comenzó a registrar ocurrencias frecuentes de errores de CDN con el código de estado HTTP 502.

Desafortunadamente, el error afectó a todos nuestros clientes y causó inestabilidad en la entrega de recursos de CDN durante un par de días. Después de examinar el problema, emitimos una actualización de software que solucionó la inestabilidad del servicio de forma permanente.

Una vez que todo con NitroPack funcionó correctamente, realizamos una reunión retrospectiva para reflexionar sobre lo que podríamos mejorar en el futuro en función de lo que aprendimos de esta actualización de infraestructura.

Pasos que estamos tomando para garantizar que los mismos problemas no vuelvan a ocurrir en el futuro

En general, estamos orgullosos de cómo fue toda la actualización. Experimentamos inestabilidad ocasional en el servicio, pero fue de manera controlada y evitamos con éxito el tiempo de inactividad de todo el servicio para toda la base de clientes.

Sin embargo, sabemos que darnos palmaditas en la espalda y centrarnos por completo en lo que salió bien no nos hará avanzar como empresa ni como servicio.

Es por eso que queremos comunicar las mejoras que implementaremos para poder realizar futuras actualizaciones de una manera aún más eficiente. Estos son los puntos principales:

Entorno de ensayo apto para pruebas de esfuerzo

Esto nos permitirá detectar errores que solo ocurren en situaciones de gran volumen con decenas de miles de solicitudes. Por ejemplo, eso nos habría ayudado a identificar el cliente HTTP y los problemas de conexiones reutilizables con anticipación, y habríamos podido ejecutar la actualización de IP sin interrupciones.


Mejores sistemas de monitoreo y alerta

Con base en los problemas que ocurrieron durante esta actualización, pudimos identificar áreas en las que carecíamos de monitoreo y alertas. La gran noticia es que ya hemos configurado ambos para estas áreas.


Mejor colaboración entre equipos y más comunicación proactiva con el cliente

Debido a que los diversos equipos involucrados en la actualización no estaban sincronizados de manera ideal entre sí, sentimos que no pudimos comunicar de manera proactiva y oportuna el progreso de la actualización a nuestros clientes existentes. Teníamos nuestra página status.nitropack.io para que todos pudieran seguir lo que estaba sucediendo con la actualización, pero eso no fue suficiente.

La próxima vez, comunicaremos el progreso de la actualización a través de tantos canales como sea posible, incluidas las redes sociales, el correo electrónico, el tablero y el sitio web.


Mejor coordinación con nuestro proveedor de servidores

Para futuras actualizaciones, nos esforzaremos por lograr una mejor coordinación con nuestro proveedor de servicios para garantizar soluciones oportunas a problemas inesperados. Esto nos ayudará a manejar los errores imprevistos del servidor de manera más eficiente.

Finalmente, nos gustaría agradecer a todos nuestros clientes por su paciencia y comprensión. Su confianza es nuestro motor para mejorar constantemente nuestro servicio.