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

rodrigokfw · 18 Enero 2023

buena nota, esperamos la de transantiago =)

iRock · 18 Enero 2023

Zuljin dijo:
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.

Bitch please... pero si el Transantiago en sí es una pérdida cuantiosa. :yao

senbe · 18 Enero 2023

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.

_userdefault · 18 Enero 2023

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 · 19 Enero 2023

Hola, quedo a la espera de esa anécdota sabrosa

Soujiro · 19 Enero 2023

duendenegro25 dijo:
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 · 19 Enero 2023

Soujiro dijo:
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 · 19 Enero 2023

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 · 20 Enero 2023

Zuljin dijo:
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

Skablop · 20 Enero 2023

Muy interesante la nota, se agradece!

schyzo · 20 Enero 2023

Zuljin dijo:
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 :zippyflaite

Imagino que a estas alturas tendrán algo más robusto

unreal4u · 22 Enero 2023

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 · 24 Enero 2023

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 · 25 Enero 2023

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 · 27 Enero 2023

duendenegro25 dijo:
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 · 27 Enero 2023

pab.str dijo:
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 · 27 Enero 2023

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 · 27 Enero 2023

lavtaro dijo:
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.

Harima dijo:
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

_userdefault · 28 Enero 2023

pab.str dijo:
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

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

Gold Member

Ex reportero de CHW y FayerWayer

Asesino de ferrules.

Miembro Regular

pajarón nuevo

Fanático

I am online

Fundador

Ex reportero de CHW y FayerWayer

Miembro Regular

Experto (retirado) en comer costillar c/ cubiertos

I solve problems.

Closcapchon.

Capo

Miembro Activo

Ciclista Jipi

Pegao al tarro

Autoridad Ancestral de Transacciones

Miembro Regular