intive Argentina Blog

Servicio no disponible hasta nuevo aviso

Enciendo la computadora, inicio el navegador y me dispongo a comprar una entrada para un concierto. Pero entonces la página web tarda más de lo usual en cargar. Lo intento nuevamente con el teléfono y obtengo el mismo resultado. Cansado, abro Twitter o Facebook, busco la web que me ha estado dando batalla, y me solidarizo con los usuarios frustrados, de los cuales yo me siento parte.

Considero que muchos nos hemos enfrentado a la frustración cuando queremos comprar esa entrada a un concierto que hemos estado esperando, o ver el capitulo nuevo de la serie del momento o una transmisión en vivo. Cualquier servicio que nos disponibiliza internet en forma masiva presenta los mismos inconvenientes y, para los usuarios, es sumamente molesto no poder utilizarlo. Desde el punto de vista de una empresa que ofrece servicios estos inconvenientes pueden significar la ruina, una pérdida de confianza grande por parte del público, y una pésima publicidad en los medios.

Para empezar a analizar cuántas aspirinas necesitarán los administradores de sistemas, podemos intentar clasificar nuestro servicio en uno de estos tres grupos:

  • Caso 1: Mis servicios ocasionalmente van a tener un aumento grande de usuarios concurrentes por períodos cortos de tiempo.
  • Caso 2: Mis servicios no toleran fallas, no puedo arriesgarme a que uno o varios de ellos no estén disponibles.
  • Caso 3: Mis servicios no toleran caídas y pueden tener picos ocasionales de usuarios.

Caso 1

Para el primer caso, se considera que no es conveniente tener una gran infraestructura ociosa esperando ser utilizada. Diferentes nubes ofrecen una opción que permite desplegar rápidamente máquinas virtuales o contenedores. En AWS esto se llama “Auto Scaling Groups” para EC2 normales o “Service Auto Scaling” para contenedores. En simples palabras, cuando se cumplen ciertas alertas, la nube automáticamente despliega los contenedores o máquinas virtuales hasta llegar a un límite propuesto por el administrador y se destruye cuando se cumplen otros parámetros. De esta manera rápidamente se incrementa el poder de la infraestructura, no se tiene infraestructura ociosa y se abonan estos nuevos elementos solamente por los cortos periodos de tiempo que se utilicen.

Screen Shot 2017-08-30 at 12.22.45 PM

Caso 2

En el segundo caso, se pueden plantear dos posibles soluciones, a realizar individualmente o en conjunto. Cabe mencionar que requieren una orquestación, planning, pruebas de grandes dimensiones y mediciones más allá de estos puntos concretos. Para ambas soluciones se plantea el uso de múltiples regiones a nivel mundial, lo que brinda la ventaja de tener la infraestructura distribuida y lista en diferentes partes del mundo (algo así como aquel consejo de no tener todos los huevos en la misma canasta).

Solución A)

Se puede plantear un Failover multiregión el cual es explicado en esta presentación.

Understand AWS Cross Region Failover in 10 Easy Steps from devopsjour

 

Solución B)

Se puede optar por una aplicación distribuida en múltiples regiones y, gracias a la magia del DNS, tener improvements dependiendo de la región, lo que nos permite dar énfasis a una región en particular que pueda necesitar mayor atención. En la siguiente presentación se ejemplifica cómo implementarla.

Aws multi-region High Availability from Adam Book

Caso 3

Para este caso, se puede pensar en una arquitectura orientada en un failover multiregión aparte de sistemas de réplica y planes de recuperación. Este caso es sumamente más complejo y no se puede presentar una receta fácil, es preciso realizar una planeación más a medida que contempla las necesidades reales del negocio con el fin de priorizar y optimizar las funcionalidades con mayor valor para el cliente.

Una buena práctica que proponen varias empresas es el uso de CDN (Content Delivery Network) para diferentes tipos de contenido, específicamente para archivos estáticos de video, imágenes, html, css o js. En AWS, junto con S3, se pueden utilizar los Edge Locations mediante CloudFront para poner a disponibilidad los archivos. En este video se explica como funciona. Esto es útil también para mejorar el rendimiento y la disponibilidad de nuestros servicios.

A esa altura muchos se preguntarán: ¿Y si todo esto falla? ¿Y si la demanda es más alta que mi capacidad de pago o mis preparativos? ¿Qué hago? Ante todo, recordemos las enseñanzas del Chapulín Colorado:

Screen Shot 2017-08-30 at 12.23.09 PM

Primeros pasos

Lo más importante es reconocer que los problemas existen. El usuario tiene que ser notificado si se está trabajando para solucionar el problema o si el servicio presenta inestabilidad. No es extraño que los usuarios utilicen las redes sociales para buscar respuestas, por lo que el manejo de las mismas es fundamental en tiempos de crisis. La comunicación debe ser efectiva, e incluso se puede utilizar el recurso del humor para aligerar la tensión con los usuarios, como muchos pudimos observar en la página de error de Youtube, que muestra el mensaje “A team of highly trained monkeys has been dispatched to deal with this situation” (“un equipo de monos altamente entrenados ha sido liberado para lidiar con esta situación”)

Screen Shot 2017-08-30 at 12.23.20 PM

Gitlab es otro ejemplo de empresas que suelen manejar bien la comunicación en momentos de crisis. Mientras su servicio estuvo caído varias horas por un problema técnico, el equipo decidió mostrar al mundo como iban solucionando el incidente. Acá se puede ver el streaming.

Cuando la tormenta pasa

Después de haber solucionado el problema, el siguiente paso es comunicar a los usuarios qué fue lo que sucedió, mostrando así que todo fue controlado y que el servicio busca mejorar e impedir nuevos sucesos críticos. Dos buenos ejemplos son AWS y -nuevamente- Gitlab, con un recuento postmortem del incidente.

Más allá de todo lo antes mencionado, no se olviden que lo más importante es aprender de nuestros errores, mejorar el proceso, ser proactivos para prevenir futuros incidentes y, por supuesto, tener el café para emergencias siempre listo.

Screen Shot 2017-08-30 at 12.23.36 PM

Rodolfo Cordero

Rodolfo Cordero es desarrollador en la compañía desde junio de 2016. Es Licenciado en Desarrollo de Software, graduado de la Universidad Latina de Costa Rica, país del cual es oriundo. Asiduo lector y melómano, hizo cursos de coctelería y barismo, habilidades con las que deleita al staff de intive en los afters organizados por la compañía.

Deja un comentario