Portada! Las nubes también caen - no olvides tener un sitio de contingencia

nube_voladora.png



Antes de partir la historia debo mencionar que Alibaba, el gigante asiático del comercio b2b, también tiene su plataforma de servicios cloud, su "nube" y es uno de los mayores proveedores de servicios cloud del mundo.

La historia cuenta que en diciembre de 2022, hace apenas un mes, la plataforma Cloud de Alibaba tuvo una falla en el sistema de refrigeración en su datacenter de Hong Kong (el nodo o región de una nube) que provocó el cese de servicios de muchos negocios ahí alojados. Entre esos servicios caídos estaba una casa de intercambio de criptomonedas como para que se vayan haciendo una idea del impacto que tuvo este evento.


Hacer las cuentas: ¿cuánto pierde tu negocio por cada día u hora si es que no tienes los sistemas arriba?

Ante una caída de servicios contratados se estila que el proveedor te compense no cobrándote por el lapso de tiempo en que no te brindó el servicio (como tanta generosidad, Dios mío). En este caso Alibaba corrió con plata para compensaciones, pero ese dinero retribuido es ínfimo en comparación a la pérdida por tener el negocio detenido.

No es raro que las empresas no consideren planes de contingencia porque "son caros y no se justifican, si al final las nubes casi nunca fallan". ¿Se imaginan un fallo de un datacenter de un servicio de ventas durante la semana previa a la navidad? Bueno, cuando finalmente fallan es cuando finalmente comienzan a hacer cuentas de cuánto dinero se pierde por estar sin servicio y que a lo mejor tener un sistema de contingencia no era tan mala idea.


Según estudios realizados, para el 60% de las compañías la pérdida económica de caídas de servicio tienen un costo de más de US$100.000 y existe un 15% de compañías cuya pérdida por caída de servicio es de más de 1 millón de dólares (en ese 15% se encuentra capa9) así que como ven, a la larga lo barato termina siendo caro.



Haciendo una analogía más mundana, imagínense que tengo un twingo y un ferrari (una taza vuela y me golpea en la cabeza)... nah. Imagínense que ustedes tienen un local de comida cuyo gancho es tener pantallas para proyectar partidos de fútbol los fines de semana con canal premium de futbol que llega por internet, y tu proveedor de internet te cobra 24 mil pesos mensuales lo que te da un costo de $800 por día y $33 la hora. Ahora ponle que tienes publicidad de "vea el superclásico acá" pero UNA HORA ANTES del partido se cae el servicio de futbol durante 3 horas, lo que significa que no pudiste transmitir el partido de fútbol.

La devolución de tu proveedor de internet por no haber podido entregarte el servicio durante 3 horas es de $100 pesos (una indigna moneda de gamba) pero evidentemente tu pérdida económica es mucho más. ¿Se hubiera justificado haber tenido contratado un segundo enlace de internet en caso de emergencia?


Probablemente ustedes ya lo han hecho pero igual es un buen ejercicio: hagan el cálculo de cuánto pierde su empresa, su institución, si es que sus sistemas están abajo durante un día.



Los ángeles caen, las nubes se caen

Shit happens. Hace un tiempo se apagó un datacenter de la nube de google por altas temperaturas en la ciudad (aguante el calentamiento global) y muchos servicios cayeron. También me acuerdo de que hace unos años un datacenter en el sector norte de Santiago sufrió corte parcial porque un vehículo chocó con un poste eléctrico colindante (tercer mundo, no trates de entenderlo). Así que como ven la probabilidad es muy baja pero real.

Los servicios de nube más importantes ofrecen métodos de contingencia que apuntan a otras regiones, de tal manera que si el datacenter del proveedor ubicado en Santiago que es donde corren tus sistemas falla, puedes inmediatamente activar tus servicios en un nodo de contingencia ubicado en Brasilia o en Kiev (una ciudad tranquila).


PD: tengo una anécdota sabrosa de una caída grandota que le ocurrió a la plataforma del transantiago que mostró que el ahorrarse un sistema de monitoreo provocó al final pérdidas cuantiosas.





Estudios del impacto de caídas de servicios

 
Última modificación:

senbe

Anciano
Miembro del Equipo
MOD
Se incorporó
25 Julio 2006
Mensajes
11.746
Puta, es parecido con lo que sucede con la luz en el campo. Te quedas sin luz y no es tan terrible estar sin la tele, la radio, el refri...pero si sacas agua de un pozo con una bomba eléctrica te fuiste a la chucha.
 

duendenegro25

Miembro Regular
Se incorporó
13 Abril 2021
Mensajes
44
Por mi parte en mi anterior trabajo tenia desplegada la carga de trabajo en Sao Paulo (AWS) y la w** tuve N caidas en las zonas donde tenia mis instancias, y por lo menos apuntando a otras regiones se mitiga el problema, creo que a todos les pasa (aws, azure, gcp)
 

nibal2

pajarón nuevo
MOD
Se incorporó
15 Junio 2007
Mensajes
2.889
Hola, quedo a la espera de esa anécdota sabrosa
 

Soujiro

Fanático
Se incorporó
14 Enero 2008
Mensajes
1.307
Por mi parte en mi anterior trabajo tenia desplegada la carga de trabajo en Sao Paulo (AWS) y la w** tuve N caidas en las zonas donde tenia mis instancias, y por lo menos apuntando a otras regiones se mitiga el problema, creo que a todos les pasa (aws, azure, gcp)
Yo tengo la carga en 2 zonas gcp completamente diferentes, sao paulo y virgina en usa y aun asi nos quedo una conga mas o menos con un cliente que tenia los dns mal configurados, cuando se cambio de zona por asdf el cliente "seguia" apuntando a la zona antigua... A veces uno hace su mejor esfuerzo pero no hay caso.
 

Miguelwill

Merc Netrunner
Miembro del Equipo
MOD
Se incorporó
23 Febrero 2004
Mensajes
11.999
Yo tengo la carga en 2 zonas gcp completamente diferentes, sao paulo y virgina en usa y aun asi nos quedo una conga mas o menos con un cliente que tenia los dns mal configurados, cuando se cambio de zona por asdf el cliente "seguia" apuntando a la zona antigua... A veces uno hace su mejor esfuerzo pero no hay caso.
oh cierto, es un cacho cuando aunque el nombre dns se supone que apunta a las ip de ambas zonas, en la zona raiz (nic) no la tiene apuntando y la mier** queda solo usando las otras
 

Zuljin

Fundador
Miembro del Equipo
Fundador
ADMIN
Se incorporó
15 Enero 2004
Mensajes
11.464
El tema del Transantiago no es tanto por no tener un sitio de contingencia (que si lo tenía y estoy casi seguro de que todavía lo tiene) sino que uno de sus sistemas de monitoreo de las platas no tenía monitoreo de visibilidad (no se si lo habrán creado pero me juego las millas latanpass que no).
Esto es con información de hace 10 años, probablemente haya cambiado.


La cosa es que los puntos de carga de tarjetas (no los torniquetes, ojo ahí) están conectados a un sistema central que maneja toda la plata y las operaciones. Obviamente esa conexión es por red tcp a un datacenter de Sonda.

Ley de la vida y ley de sistemas: shit happens. Hubo un problema de telecomunicaciones brígido (algo relacionado con el firmware de un switch core, no lo sé bien) y los puntos de carga quedaron aislados del sistema central.

Menos mal que no era un sistema manejado por nosotros y tampoco la infra era manejada por nosotros, porque el cagazo fue grande y los gerentes andaban vueltos locos pidiendo explicaciones. Los puntos de carga tienen la capacidad de trabajar offline, es decir, podías cargar tu tarjeta bip igual así que el usuario no se veía afectado, pero el punto de venta no podía actualizarle la información al sistema central y si al punto de venta se le acababa la plata asignada pues quedaba inutilizado.


Se armó una sala de crisis en donde iban los gerentes enojados a pedir explicaciones a todo el mundo y a apurar a los ingenieros de sonda a cargo (porque se sabe que gritarle a un técnico hará que el soporte internacional de cisco te responda más rápido), y de pasada darse cuenta de que NO TENIAN SISTEMA DE MONITOREO OFFLINE DE PLATA DE LOS PUNTOS DE VENTA. Como la huea no falló en 10 años no previeron la importancia de esa área de negocio y no se preocuparon demasiado porque cuando necesitaban saber la cantidad de plata que tenía un punto de venta le tiraban una query a la base de datos del sistema central que le daba la información actualizada (sconf).


Cuando se solucionó el problema de conectividad dieron cuenta de que era importante tener visibilidad online del estado del saldo de plata de los puntos de venta. Yo suponía que después de la desesperación de los grandes gerentes fijo que nos iban a pedir una solución tecnológica para eso y ya estábamos preparando la calculadora para cotizar. Yo me imaginaba hacer un sistema que se alimentara con pantallas con puntos de venta, saldo online, su gráfico loco que se actualice minuto a minuto, onda pinchas un punto de venta y te muestra el saldo, saldo acumulado de la red general, etc.

Cuento corto: por ahorrarse el costo de desarrollar un sistema bueno al final nos pidieron que le mandemos una planilla excel cuatro veces al día con el saldo de los puntos de venta en ese momento. Una consulta sql cronteada en linux que genera un archivo csv que se enviaba por correo a un grupo de personas, con punto de venta, última actualización y saldo de plata.

Hasta que no ocurra otro cagazo igual no se va a saber si esa planilla excel cada seis horas le es suficiente.
 

iRock

Ex reportero de CHW y FayerWayer
Se incorporó
13 Diciembre 2007
Mensajes
1.355
Cuento corto: por ahorrarse el costo de desarrollar un sistema bueno al final nos pidieron que le mandemos una planilla excel cuatro veces al día con el saldo de los puntos de venta en ese momento.
Típica "solución" a la chilena. :facepalm
 

schyzo

Experto (retirado) en comer costillar c/ cubiertos
Miembro del Equipo
MOD
Se incorporó
18 Agosto 2019
Mensajes
438
El tema del Transantiago no es tanto por no tener un sitio de contingencia (que si lo tenía y estoy casi seguro de que todavía lo tiene) sino que uno de sus sistemas de monitoreo de las platas no tenía monitoreo de visibilidad (no se si lo habrán creado pero me juego las millas latanpass que no).
Esto es con información de hace 10 años, probablemente haya cambiado.


La cosa es que los puntos de carga de tarjetas (no los torniquetes, ojo ahí) están conectados a un sistema central que maneja toda la plata y las operaciones. Obviamente esa conexión es por red tcp a un datacenter de Sonda.

Ley de la vida y ley de sistemas: shit happens. Hubo un problema de telecomunicaciones brígido (algo relacionado con el firmware de un switch core, no lo sé bien) y los puntos de carga quedaron aislados del sistema central.

Menos mal que no era un sistema manejado por nosotros y tampoco la infra era manejada por nosotros, porque el cagazo fue grande y los gerentes andaban vueltos locos pidiendo explicaciones. Los puntos de carga tienen la capacidad de trabajar offline, es decir, podías cargar tu tarjeta bip igual así que el usuario no se veía afectado, pero el punto de venta no podía actualizarle la información al sistema central y si al punto de venta se le acababa la plata asignada pues quedaba inutilizado.


Se armó una sala de crisis en donde iban los gerentes enojados a pedir explicaciones a todo el mundo y a apurar a los ingenieros de sonda a cargo (porque se sabe que gritarle a un técnico hará que el soporte internacional de cisco te responda más rápido), y de pasada darse cuenta de que NO TENIAN SISTEMA DE MONITOREO OFFLINE DE PLATA DE LOS PUNTOS DE VENTA. Como la huea no falló en 10 años no previeron la importancia de esa área de negocio y no se preocuparon demasiado porque cuando necesitaban saber la cantidad de plata que tenía un punto de venta le tiraban una query a la base de datos del sistema central que le daba la información actualizada (sconf).


Cuando se solucionó el problema de conectividad dieron cuenta de que era importante tener visibilidad online del estado del saldo de plata de los puntos de venta. Yo suponía que después de la desesperación de los grandes gerentes fijo que nos iban a pedir una solución tecnológica para eso y ya estábamos preparando la calculadora para cotizar. Yo me imaginaba hacer un sistema que se alimentara con pantallas con puntos de venta, saldo online, su gráfico loco que se actualice minuto a minuto, onda pinchas un punto de venta y te muestra el saldo, saldo acumulado de la red general, etc.

Cuento corto: por ahorrarse el costo de desarrollar un sistema bueno al final nos pidieron que le mandemos una planilla excel cuatro veces al día con el saldo de los puntos de venta en ese momento. Una consulta sql cronteada en linux que genera un archivo csv que se enviaba por correo a un grupo de personas, con punto de venta, última actualización y saldo de plata.

Hasta que no ocurra otro cagazo igual no se va a saber si esa planilla excel cada seis horas le es suficiente.
Sólo puedo decir... la solución pa flaite :zippyflaiteImagino que a estas alturas tendrán algo más robusto
 

unreal4u

I solve problems.
Miembro del Equipo
ADMIN
Se incorporó
2 Octubre 2005
Mensajes
13.026
excelente nota, aunque de todas formas entiendo a los miles y miles de empresas que se arriesgan con sólo una nube: en el caso de la empresa donde trabajo, es una pyme y si bien es cierto quizás podríamos correr con el doble de gastos, no es menos cierto que tb terminaríamos con el doble de cachos y tiempo perdido: si bien es cierto nuestro código está hecho para crecer horizontalmente, cuando ocurra un problema siempre habrá que arreglarlo en 2 partes y nos traería también más problemas que soluciones prácticas: por eso mismo es que no tenemos un SLA con nuestros clientes, y encontramos aceptable para ellos un 99.9% de uptime anual: o sea, cualquiera de nuestros sistemas puede estar abajo por unas 8 horas al año.

El año pasado tuvimos 19 minutos de downtime en la empresa, 15 de los cuales fue por un cagazo con el servidor de imágenes. Si este hubiese estado replicado en otro lado, lo más probable es que me hubiese demorado 25 en arreglarlo.

Eso sí, debo destacar que en este caso es un setup con un riesgo calculado. Sabemos qué pasará si se quema uno de los datacenters y también tenemos como política tener todos los respaldos en al menos 2 proveedores distintos: nuestro correo por ejemplo lo respaldamos primero a GCP y luego a backblaze mientras que todo lo demás es primero GCP y luego Amazon.

De esa forma, si se quema un datacenter de GCP podemos recuperar nuestra infrastructure en otra parte con datos de al menos un par de horas de antigüedad. Es penca que sea así, pero es mejor que nada.

Saludos.
 

Ejecutor_Hanzo

Closcapchon.
Se incorporó
1 Marzo 2006
Mensajes
5.074
Soy parte del 20% que ama los twingos. Siempre encontre muy entretenido su diseño y concepto, y un potencial auto electrificable... si no fuera por piraña que ilegalizo las conversiones a electricos de autos...
 

lavtaro

Capo
Se incorporó
11 Diciembre 2007
Mensajes
200
Hoy en día todos tienen la idea de enviar los servidores en la nube, mi percepción que es mal visto tener servidores en las instalaciones.

Yo soy viejo entonces no me asusta, ni me extraña ver un servidor en un "datacenter" en las instalaciones de una empresa (obviamente los respaldos deben estar en la nube), no veo complicado administrar un servidor, si es una empresa que no tiene sucursales con las cuales estar en línea, operar on-premise evita los problemas que se describen en el artículo.

También está el punto de vista de auditores y/o consultores (que dicem "saber todo de todo") que la nube evita el acceso físico a los servidores, pero en su mayoría no tienen en cuenta los casos que se muestran en este artículo.

La replicación de los datos desde el servidor local a una nube también puede ser opción.

Saludos y muchas gracias @Zuljin por la información.
 

pab.str

Miembro Activo
Se incorporó
27 Enero 2023
Mensajes
1
Por mi parte en mi anterior trabajo tenia desplegada la carga de trabajo en Sao Paulo (AWS) y la w** tuve N caidas en las zonas donde tenia mis instancias, y por lo menos apuntando a otras regiones se mitiga el problema, creo que a todos les pasa (aws, azure, gcp)

de Chile me a pasado que eligen Brasil pensando que la latencias es mas baja con aws porque esta mas cerca, pero se da la vuelta larga. los servidores gringos andan mejor.
 

wurrzag

Ciclista Jipi
Se incorporó
30 Mayo 2006
Mensajes
8.533
de Chile me a pasado que eligen Brasil pensando que la latencias es mas baja con aws porque esta mas cerca, pero se da la vuelta larga. los servidores gringos andan mejor.
Algunos ISP efectivamente andan más rápido a Brazil, otros no...

En mis tiempos que jugaba HoTS lamentablemente tenía mejor ping con movistar a Brazil (ostensiblemente mejor que a gringolandía), en el foro de Blizzard estaba lleno de temas de Chilenos reclamando por el ping a BR... eran de VTR, al menos ellos (desconozco otros) se daban una vuelta por miami antes de bajar a BR, mientras que movistar iba directo.
 

Harima

Pegao al tarro
Se incorporó
15 Mayo 2008
Mensajes
3.824
el tema no es tan simple como tener dos "nubes" y la complejidad varia mucho de los sw que se utilicen, recuerdo que en la pega anterior teniamos el sitio A y B en Azure (Tema de zonas) y el C y D en AWS (lo mismo zonas disntintas), pero era un culo de un porte de un buque tener todo sincronizado, y para que decir por ejemplo cuando levantabamos un elasticsearch por ejemplo, si calculaban mal el espacio/rendimiento era un culo estar modificando los cluster y los discos, ahora es mas facil, solo agregas espacios, pero al comienzo tenias que clonar el disco, por eso es mucho mas facil utilizar saas. pero el problema es que los precios se elevan bastante, el modelo se puede simplificar bastante si por ejemplo tienes datacenter con enlace dedicado, creas tus propios tuneles entre datacenter y si modelas bien la red, es transparente, manejas todo como si solo fuera una red, pero ahora que el paradigma cambio y ya no son aplicaciones tan cerradas, con el enfoque de que todo es un servicio, publicas tu puerto de administración/sincronización y todo vuela, da para harto el tema pero principalmente, depende de la arquitectura de tus sistemas, a y obvio no es lo mismo tener software para que tu empresa funcione, que vender servicios en donde tu negocio es el uptime de los servicios

como dato no voy a dar nombres, pero empresas muuuuy grandes en chile con muchos recursos, tienen el doble datacenter, pero como lo tienen por cumplir, al momento de tener que subir el sitio secundario, este simplemente no funciona, o no tienen cosas basicas como la BD replicada (tienen una copia de cuando se levanto el site de meses o años atras), o un maestro secundario en clustrer replicando, o no tienen las configuraciones actualizadas entre servidores, jamas han echo el ejercicio de hacer el switch de datacenter, o lo que es peor es que tienen los DNS solo en el datacenter principal y al caerse, es imposible levantar el datacenter secundario, muchos casos en que da lo mismo si es nube o datacenter, al no tener una buena planificación, igual no va a funcionar
 

Lordnet

Autoridad Ancestral de Transacciones
Se incorporó
11 Junio 2004
Mensajes
1.952
Hoy en día todos tienen la idea de enviar los servidores en la nube, mi percepción que es mal visto tener servidores en las instalaciones.

Yo soy viejo entonces no me asusta, ni me extraña ver un servidor en un "datacenter" en las instalaciones de una empresa (obviamente los respaldos deben estar en la nube), no veo complicado administrar un servidor, si es una empresa que no tiene sucursales con las cuales estar en línea, operar on-premise evita los problemas que se describen en el artículo.

También está el punto de vista de auditores y/o consultores (que dicem "saber todo de todo") que la nube evita el acceso físico a los servidores, pero en su mayoría no tienen en cuenta los casos que se muestran en este artículo.

La replicación de los datos desde el servidor local a una nube también puede ser opción.

Saludos y muchas gracias @Zuljin por la información.
En realidad donde trabajo ahora están recién están viendo el caso de negocio de subir parte de la infraestructura a la nube, solo habian hecho pruebas de concepto o servicios de muy baja relevancia.
Personalmente lo viví. Un proyecto que tengo tenia que ir on-premise por la confidencialidad, continuidad y asdf , pero cuando les mostré el costo de licenciamiento mas los costos de puesta en marcha del proveedor TI, lo encontraron muy caro y me dieron el go para nube luego de presentar la evaluación. Capex 0. Opex razonable. Contablemente supongo que tb tenia beneficios enviar el servicio a gasto y no como activo.

como dato no voy a dar nombres, pero empresas muuuuy grandes en chile con muchos recursos, tienen el doble datacenter, pero como lo tienen por cumplir, al momento de tener que subir el sitio secundario, este simplemente no funciona, o no tienen cosas basicas como la BD replicada (tienen una copia de cuando se levanto el site de meses o años atras), o un maestro secundario en clustrer replicando, o no tienen las configuraciones actualizadas entre servidores, jamas han echo el ejercicio de hacer el switch de datacenter, o lo que es peor es que tienen los DNS solo en el datacenter principal y al caerse, es imposible levantar el datacenter secundario, muchos casos en que da lo mismo si es nube o datacenter, al no tener una buena planificación, igual no va a funcionar
por el lado de mi gremio (instituciones financieras) estuvieron limitadas a nivel regulatorio para externalizar los servicios de procesamiento de datos. en su tiempo la SBIF (actual CMF) dio lineamientos para la externalización de servicios e hitos extras si se te ocurría externalizar fuera de CHile (mas encima tenias que tener la aprobación de ellos). Fue tanto el tema que al final en nuestro caso para externalizar un servicio de criticidad alta requiere aprobación del Directorio.

Después la norma CMF se hizo más flexible y en resumen es "externalízalo nomas, yo después reviso si lo hiciste como las pelotas", debido a eso creo que al menos el rubro financiero se ha vuelto a considerar el subir los servicios medianos a críticos a cloud (o en nube híbrida). A eso sumemos los patinazos de los datacenter chilensis, y que vienen los proyectos de Datacenter de las BIG 3 (AWS, google, Azure) puestos directamente en el mejor país del mundo. Pero ahora los incidentes de alibaba y Azure con las olas de calor, creo que hará repensar en qué zona dejas la infraestructura. o Podrían ser nomades. en verano en un site y en invierno en el otro hemisferio :zippy
 

duendenegro25

Miembro Regular
Se incorporó
13 Abril 2021
Mensajes
44
de Chile me a pasado que eligen Brasil pensando que la latencias es mas baja con aws porque esta mas cerca, pero se da la vuelta larga. los servidores gringos andan mejor.
Tal cual, en AWS la carga en North Virginia no he tenido ninguna caída desde que la desplegué ahi en 2021
 
Subir