{"id":83188,"date":"2020-05-29T07:43:02","date_gmt":"2020-05-29T05:43:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kak-my-perezhili-rezkij-rost-nagruzki-x10-na-udalenke-i-kakie-vyvody-sdelali"},"modified":"2020-05-29T07:43:02","modified_gmt":"2020-05-29T05:43:02","slug":"kak-my-perezhili-rezkij-rost-nagruzki-x10-na-udalenke-i-kakie-vyvody-sdelali","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/kak-my-perezhili-rezkij-rost-nagruzki-x10-na-udalenke-i-kakie-vyvody-sdelali","title":{"rendered":"C\u00f3mo sobrevivimos a un aumento repentino de carga x10 en remoto y qu\u00e9 conclusiones sacamos","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\u00a1Hola, Habr! En los \u00faltimos meses hemos estado en una situaci\u00f3n muy interesante y me gustar\u00eda compartir nuestra historia sobre la escalabilidad de la infraestructura. Durante este tiempo, SberMarket ha crecido cuatro veces en pedidos y ha lanzado su servicio en 17 nuevas ciudades. El explosivo aumento en la demanda de entrega de productos nos ha obligado a escalar la infraestructura. Lee sobre las conclusiones m\u00e1s interesantes y \u00fatiles m\u00e1s abajo.<\/p>\n

\"C\u00f3mo
\n<\/a><\/noindex>
\nMe llamo Dima Bobylev, soy el director t\u00e9cnico de SberMarket. Dado que este es el primer post en nuestro blog, dir\u00e9 algunas palabras sobre m\u00ed y sobre la compa\u00f1\u00eda. El oto\u00f1o pasado particip\u00e9 en el concurso de j\u00f3venes l\u00edderes de Runet. Para el concurso, yo escrib\u00ed una peque\u00f1a historia<\/a><\/noindex> sobre c\u00f3mo vemos en SberMarket la cultura interna y el enfoque hacia el desarrollo del servicio. Y aunque no logr\u00e9 ganar en el concurso, pude formular para m\u00ed los principios fundamentales del desarrollo del ecosistema IT. <\/p>\n

Al gestionar un equipo, es importante entender y encontrar el equilibrio entre lo que necesita el negocio y las necesidades de cada desarrollador en particular. Actualmente, SberMarket est\u00e1 creciendo 13 veces a\u00f1o tras a\u00f1o, y esto afecta al producto, exigiendo un aumento constante en los vol\u00famenes y en la velocidad de desarrollo. A pesar de esto, dedicamos suficiente tiempo a los desarrolladores para el an\u00e1lisis preliminar y la escritura de c\u00f3digo de calidad. El enfoque establecido no solo ayuda en la creaci\u00f3n de un producto funcional, sino tambi\u00e9n en su posterior escalabilidad y desarrollo. Como resultado de este crecimiento, SberMarket se ha convertido en el l\u00edder entre los servicios de entrega de productos: entregamos diariamente alrededor de 18,000 pedidos al d\u00eda, aunque a principios de febrero eran aproximadamente 3,500.<\/p>\n

\"C\u00f3mo
\nUna vez, un cliente pidi\u00f3 al mensajero de SberMarket que le entregara productos sin contacto, directamente en el balc\u00f3n.<\/i><\/p>\n

Pero vayamos a lo concreto. En los \u00faltimos meses, hemos estado trabajando activamente en la escalaci\u00f3n de la infraestructura de nuestra empresa. Esta necesidad se explicaba por factores internos y externos. Al mismo tiempo que nuestra base de clientes se expand\u00eda, el n\u00famero de tiendas conectadas creci\u00f3 de 90 a principios de a\u00f1o a m\u00e1s de 200 a mediados de mayo. Por supuesto, estuvimos preparados, reservamos la infraestructura principal y calculamos la posibilidad de escalar vertical y horizontalmente todas las m\u00e1quinas virtuales alojadas en la nube de Yandex. Sin embargo, la pr\u00e1ctica demostr\u00f3: 'Todo lo que puede salir mal, saldr\u00e1 mal'. Y hoy quiero compartir las situaciones m\u00e1s curiosas que ocurrieron durante estas semanas. Espero que nuestra experiencia sea \u00fatil para usted.<\/p>\n

Slave est\u00e1 en plena capacidad operativa<\/h3>\n

\nIncluso antes del inicio de la pandemia, nos encontramos con un aumento en el n\u00famero de solicitudes a nuestros servidores backend. La tendencia de pedir productos con entrega a domicilio comenz\u00f3 a ganar impulso, y con la implementaci\u00f3n de las primeras medidas de aislamiento en relaci\u00f3n con la COVID-19, la carga aument\u00f3 dr\u00e1sticamente a lo largo del d\u00eda. Surgi\u00f3 la necesidad de descargar r\u00e1pidamente los servidores principales de la base de datos y trasladar parte de las solicitudes de lectura a los servidores r\u00e9plicas (slave).<\/p>\n

Nos preparamos con anticipaci\u00f3n para este paso, y ya se hab\u00edan puesto en marcha 2 servidores slave para tal maniobra. En ellos, principalmente, se ejecutaban tareas por lotes para la generaci\u00f3n de feeds informativos para el intercambio de datos con socios. Estos procesos generaban una carga adicional y, con raz\u00f3n, hab\u00edan sido excluidos 'de la ecuaci\u00f3n' un par de meses antes.\u00a0<\/p>\n

Dado que en Slave se estaba llevando a cabo la replicaci\u00f3n, nos adherimos a la concepci\u00f3n de que las aplicaciones solo pod\u00edan trabajar con ellos en modo de solo lectura. El Plan de Recuperaci\u00f3n ante Desastres supon\u00eda que en caso de una cat\u00e1strofe podr\u00edamos montar simplemente el Slave en lugar del Master y redirigir todas las solicitudes de escritura y lectura al Slave. Sin embargo, tambi\u00e9n dese\u00e1bamos utilizar r\u00e9plicas para las necesidades del departamento de an\u00e1lisis, por lo que los servidores no se trasladaron completamente a un estado de solo lectura, y cada host ten\u00eda su propio conjunto de usuarios, algunos con derechos de escritura para guardar resultados intermedios de c\u00e1lculos.<\/p>\n

Hasta cierto nivel de carga, ten\u00edamos suficiente con el maestro tanto para la escritura como para la lectura al procesar solicitudes http. A mediados de marzo, justo cuando Sbermarket decidi\u00f3 pasar completamente al trabajo remoto, comenzamos a experimentar un crecimiento exponencial en RPS. Cada vez m\u00e1s de nuestros clientes se quedaban en casa o trabajaban desde all\u00ed, lo que se reflej\u00f3 en los indicadores de carga.<\/p>\n

La capacidad del 'maestro' dej\u00f3 de ser suficiente, por lo que comenzamos a mover algunas de las solicitudes de lectura m\u00e1s pesadas a la r\u00e9plica. Para dirigir las solicitudes de escritura al maestro y las de lectura al esclavo de manera transparente, utilizamos la gema ruby \u00abOctopus<\/a><\/noindex>\u00bb. Creamos un usuario especial con el sufijo _readonly sin derechos de escritura. Sin embargo, debido a un error en la configuraci\u00f3n de uno de los hosts, algunas solicitudes de escritura se enviaron al servidor esclavo con el nombre de usuario que ten\u00eda los derechos correspondientes.<\/p>\n

El problema no se manifest\u00f3 de inmediato, ya que la carga aumentada increment\u00f3 el desfase de los esclavos. La inconsistencia de los datos se detect\u00f3 por la ma\u00f1ana, cuando despu\u00e9s de las importaciones nocturnas, los esclavos no hab\u00edan 'alcanzado' al maestro. Atribuimos esto a la alta carga en el propio servicio y las importaciones relacionadas con el lanzamiento de nuevas tiendas. Sin embargo, proporcionar datos con un retraso de varias horas era inaceptable, as\u00ed que cambiamos los procesos al segundo esclavo anal\u00edtico, ya que ten\u00eda m\u00e1s recursos y no estaba cargado con solicitudes de lectura (lo que nos ayud\u00f3 a explicar la ausencia de retraso en la replicaci\u00f3n).mayor audiencia.<\/strong>Cuando entendimos las razones del 'desplazamiento' del esclavo principal, el anal\u00edtico ya hab\u00eda fallado por la misma raz\u00f3n. A pesar de tener dos servidores adicionales, a los que plane\u00e1bamos transferir la carga en caso de que fallara el maestro, result\u00f3 que en un momento cr\u00edtico no hab\u00eda ninguno disponible debido a un desafortunado error.<\/p>\n

Pero dado que no solo realizamos un dump de la base de datos (la restauraci\u00f3n en ese momento tom\u00f3 alrededor de 5 horas), sino tambi\u00e9n un snapshot del servidor maestro, pudimos lanzar la r\u00e9plica en un plazo de 2 horas. Sin embargo, despu\u00e9s de eso, nos esperaba una larga aplicaci\u00f3n del registro de la replicaci\u00f3n (porque el proceso se realiza en modo de un solo hilo, pero esa ya es otra historia).<\/p>\n

Sin embargo, dado que no solo realizamos un volcado de la base de datos (la restauraci\u00f3n en ese momento llevaba alrededor de 5 horas), sino tambi\u00e9n un snapshot del servidor maestro, pudimos iniciar la r\u00e9plica en un plazo de 2 horas. Sin embargo, despu\u00e9s de esto, nos esperaba la aplicaci\u00f3n del registro de replicaci\u00f3n durante un tiempo prolongado (porque el proceso se realiza en modo de un solo hilo, pero esa es una historia completamente diferente).<\/p>\n

Salida:<\/strong> Despu\u00e9s de este incidente, qued\u00f3 claro que deb\u00edamos abandonar la pr\u00e1ctica de restringir el acceso de escritura para los usuarios y declarar todo el servidor como solo lectura. Con este enfoque, podemos estar seguros de que las r\u00e9plicas estar\u00e1n disponibles en momentos cr\u00edticos.<\/p><\/blockquote>\n

<\/p>\n

La optimizaci\u00f3n de incluso una sola consulta pesada puede 'revivir' la base de datos.<\/h3>\n

\nAunque actualizamos constantemente el cat\u00e1logo en el sitio, las consultas que lanz\u00e1bamos a los servidores secundarios mostraban un peque\u00f1o desfase respecto al servidor primario. El tiempo que nos llev\u00f3 detectar y solucionar el problema de los 'esclavos' que 'se sal\u00edan del circuito' super\u00f3 el 'umbral psicol\u00f3gico' (durante ese tiempo podr\u00edan haberse actualizado los precios, y los clientes ver\u00edan datos desactualizados), y nos vimos obligados a redirigir todas las consultas al servidor principal de la base de datos. Como resultado, el sitio funcionaba lentamente\u2026 pero al menos funcionaba. Y mientras el esclavo se recuperaba, no nos qued\u00f3 m\u00e1s remedio que optimizar.\u00a0<\/p>\n

Mientras los servidores secundarios se recuperaban, los minutos se alargaban lentamente, el maestro permanec\u00eda sobrecargado y dedicamos todos nuestros esfuerzos a optimizar las tareas activas seg\u00fan la 'Regla de Pareto': seleccionamos las principales consultas que generaban la mayor parte de la carga y comenzamos a ajustar. Esto se hac\u00eda directamente 'sobre la marcha'.<\/p>\n

Un efecto interesante fue que un MySQL completamente cargado responde incluso a una mejora menor en los procesos. La optimizaci\u00f3n de un par de consultas que solo generaban el 5% de la carga total ya mostr\u00f3 una notable reducci\u00f3n en el uso de CPU. Como resultado, pudimos asegurar un margen aceptable de recursos para que el maestro trabajara con la base de datos y obtener el tiempo necesario para recuperar las r\u00e9plicas.\u00a0<\/p>\n

Salida:<\/strong> Incluso una peque\u00f1a optimizaci\u00f3n permite 'sobrevivir' durante horas de sobrecarga. Justo lo que necesit\u00e1bamos durante el tiempo de recuperaci\u00f3n de los servidores con r\u00e9plicas. Por cierto, discutiremos el aspecto t\u00e9cnico de la optimizaci\u00f3n de consultas en uno de los pr\u00f3ximos art\u00edculos. As\u00ed que suscr\u00edbete a nuestro blog si esto puede resultarte \u00fatil.<\/p><\/blockquote>\n

<\/p>\n

Organiza el monitoreo del estado de los servicios asociados.<\/h3>\n

\nNos encargamos de procesar pedidos de clientes, por lo que nuestros servicios interact\u00faan constantemente con API de terceros: son puertas de enlace para el env\u00edo de SMS, plataformas de pago, sistemas de enrutamiento, geocodificadores, el servicio de la FNS y muchos otros sistemas. Y cuando la carga comenz\u00f3 a crecer r\u00e1pidamente, comenzamos a encontrar limitaciones en los API de nuestros servicios asociados, en las que antes ni siquiera hab\u00edamos pensado.<\/p>\n

Un exceso inesperado de las cuotas de los servicios asociados puede llevar a la inactividad de los suyos. Muchos API bloquean a los clientes que superan los l\u00edmites, y en algunos casos, una sobrecarga de solicitudes puede saturar la producci\u00f3n del socio.\u00a0<\/p>\n

Por ejemplo, en el momento del aumento de entregas, los servicios relacionados no pod\u00edan manejar las tareas de distribuci\u00f3n y definici\u00f3n de rutas. Como resultado, se daban situaciones en las que los pedidos estaban hechos, pero el servicio que generaba la ruta no funcionaba. Debo decir que nuestros logististas hicieron pr\u00e1cticamente lo imposible en estas circunstancias, y la clara interacci\u00f3n del equipo ayud\u00f3 a compensar las ca\u00eddas temporales de los servicios. Pero tal volumen de solicitudes no se puede manejar manualmente de forma constante, y despu\u00e9s de un tiempo habr\u00edamos enfrentado una brecha inaceptable entre los pedidos y su ejecuci\u00f3n.\u00a0<\/p>\n

Se tom\u00f3 una serie de medidas organizativas y el trabajo coordinado del equipo ayud\u00f3 a ganar tiempo mientras negoci\u00e1bamos nuevas condiciones y esper\u00e1bamos la modernizaci\u00f3n de los servicios de algunos socios. Existen otros API que sorprenden por su alta resistencia y tarifas astron\u00f3micas en caso de tr\u00e1fico elevado. Por ejemplo, al principio utiliz\u00e1bamos un conocido API de mapas para determinar la direcci\u00f3n del punto de entrega. Pero al final del mes recibimos una factura de casi 2 millones de rublos. Despu\u00e9s de eso, decidimos reemplazarlo r\u00e1pidamente. No voy a hacer publicidad, pero dir\u00e9 que nuestros gastos se redujeron considerablemente.
\n\"C\u00f3mo<\/p>\n

Salida: <\/strong>Es esencial monitorear las condiciones de trabajo de todos los servicios asociados y tenerlas en cuenta. Incluso si hoy parece que tienen 'un gran margen', no significa que ma\u00f1ana no se conviertan en un obst\u00e1culo para el crecimiento. Y, por supuesto, es mejor acordar las condiciones financieras para las solicitudes aumentadas al servicio con anticipaci\u00f3n.\u00a0<\/p><\/blockquote>\n

<\/p>\n

A veces resulta que \"se necesita m\u00e1s oro<\/a><\/noindex>\" (c) no ayuda<\/h3>\n

\nEstamos acostumbrados a los \u00abcuellos de botella\u00bb en la base de datos principal o en los servidores de aplicaciones, pero al escalar, los problemas pueden aparecer donde menos los esperamos. Para la b\u00fasqueda de texto completo en el sitio, utilizamos el motor Apache Solr. Con el aumento de la carga, notamos una disminuci\u00f3n en el tiempo de respuesta y la carga del CPU del servidor lleg\u00f3 a alcanzar el 100%. \u00bfQu\u00e9 puede ser m\u00e1s simple? Le damos m\u00e1s recursos al contenedor con Solr.<\/p>\n

En lugar del aumento de rendimiento esperado, el servidor simplemente \u00abmuri\u00f3\u00bb. Se sobrecargaba al 100% de inmediato y respond\u00eda a\u00fan m\u00e1s lento. Inicialmente, ten\u00edamos 2 n\u00facleos y 2 GB de RAM. Decidimos hacer lo que normalmente ayuda: le dimos al servidor 8 n\u00facleos y 32 GB. Todo empeor\u00f3 considerablemente (c\u00f3mo y por qu\u00e9 lo explicaremos en una publicaci\u00f3n aparte).\u00a0<\/p>\n

En unos pocos d\u00edas, entendimos las complejidades de este asunto y logramos un rendimiento \u00f3ptimo con 8 n\u00facleos y 32 GB. Esta configuraci\u00f3n permite seguir incrementando la carga, lo cual es muy importante, ya que el crecimiento no solo se da en los clientes, sino tambi\u00e9n en el n\u00famero de tiendas conectadas: en 2 meses su n\u00famero se ha duplicado.\u00a0<\/p>\n

Salida: <\/strong>Los m\u00e9todos est\u00e1ndar como \u00abagregar m\u00e1s hardware\u00bb no siempre funcionan. As\u00ed que, al escalar cualquier servicio, es necesario comprender bien c\u00f3mo utiliza los recursos y probar su desempe\u00f1o en nuevas condiciones por adelantado.\u00a0\n<\/p><\/blockquote>\n

<\/p>\n

Sin estado \u2014 la clave para un f\u00e1cil escalado horizontal.<\/h3>\n

\nEn general, nuestro equipo se adhiere al enfoque conocido: los servicios no deben tener estado interno (stateless) y deben ser independientes del entorno de ejecuci\u00f3n. Esto nos permiti\u00f3 enfrentar el aumento de la carga mediante un simple escalado horizontal. Pero ten\u00edamos un servicio - excepci\u00f3n: un procesador de tareas en segundo plano prolongadas. Se encargaba del env\u00edo de correos electr\u00f3nicos y SMS, el procesamiento de eventos, la generaci\u00f3n de feeds, la importaci\u00f3n de precios e inventarios, y el procesamiento de im\u00e1genes. De alguna manera, depend\u00eda del almacenamiento local de archivos y exist\u00eda en una \u00fanica instancia.\u00a0<\/p>\n

Cuando aument\u00f3 la cantidad de tareas en la cola del procesador (lo cual ocurri\u00f3 naturalmente con el crecimiento de los pedidos), el rendimiento del host en el que se alojaban el procesador y el almacenamiento de archivos se convirti\u00f3 en un factor limitante. Como resultado, se detuvieron las actualizaciones de assortimento y precios, el env\u00edo de notificaciones a los usuarios y muchas otras funciones cr\u00edticas que quedaron atascadas en la cola. El equipo de Ops migr\u00f3 r\u00e1pidamente el almacenamiento de archivos a un sistema de almacenamiento en red similar a S3, lo que nos permiti\u00f3 lanzar varias m\u00e1quinas potentes para escalar el procesador de tareas en segundo plano.<\/p>\n

Salida: <\/strong>La regla Stateless debe seguirse para todos los componentes sin excepci\u00f3n, incluso si parece que \"aqu\u00ed definitivamente no nos quedaremos atascados\". Es mejor dedicar un poco de tiempo a organizar correctamente el trabajo de todos los sistemas que tener que reescribir c\u00f3digo y reparar un servicio que est\u00e1 bajo carga despu\u00e9s de la prisa.<\/p><\/blockquote>\n

<\/p>\n

7 principios para un crecimiento intenso<\/h2>\n

\nA pesar de la disponibilidad de capacidades adicionales, durante el proceso de crecimiento encontramos varios obst\u00e1culos. Durante este tiempo, la cantidad de pedidos aument\u00f3 m\u00e1s de 4 veces. Ahora ya estamos entregando m\u00e1s de 17,000 pedidos al d\u00eda en 62 ciudades y planeamos expandir a\u00fan m\u00e1s nuestra geograf\u00eda: en el primer semestre de 2020 se espera el lanzamiento del servicio en todo Rusia. Para hacer frente a la creciente carga, teniendo en cuenta las lecciones aprendidas, hemos establecido 7 principios fundamentales de funcionamiento bajo condiciones de crecimiento constante:<\/p>\n

    \n
  1. Gesti\u00f3n de incidentes<\/strong>. Creamos un tablero en Jira, donde cada incidente se refleja como un ticket. Esto ayudar\u00e1 a priorizar y ejecutar las tareas relacionadas con el incidente. Despu\u00e9s de todo, en esencia, no es aterrador cometer un error, lo aterrador es cometer el mismo error dos veces. Para aquellos casos en que los incidentes se repiten antes de poder corregir la causa, debe haber una instrucci\u00f3n lista para actuar, porque durante una carga alta es importante reaccionar de inmediato.<\/li>\n
  2. Monitoreo <\/strong>se requiere para todos los elementos de la infraestructura sin excepci\u00f3n. Gracias a \u00e9l, pudimos prever el aumento de la carga y seleccionar correctamente los 'cuellos de botella' para priorizar su eliminaci\u00f3n. Es probable que, bajo alta carga, se rompa o empiece a fallar todo lo que no pensabas. Por eso, es mejor crear nuevas alertas justo despu\u00e9s de que ocurran los primeros incidentes, para monitorearlos y anticiparlos.<\/li>\n
  3. Alertas correctas<\/strong> son absolutamente necesarias ante un aumento brusco de la carga. En primer lugar, deben informar exactamente qu\u00e9 se ha roto. En segundo lugar, no debe haber demasiadas alertas, ya que una abundancia de alertas no cr\u00edticas lleva a ignorar todas las notificaciones en general.<\/li>\n
  4. Las aplicaciones deben ser sin estado. <\/strong>Nos hemos asegurado de que no debe haber excepciones a esta regla. Se necesita una completa independencia del entorno de ejecuci\u00f3n. Para ello, puedes almacenar datos compartidos en una base de datos o, por ejemplo, directamente en S3. Y a\u00fan mejor seguir las normas https:\/\/12factor.net<\/a><\/noindex>. Durante un aumento brusco, no hay tiempo para optimizar el c\u00f3digo, y se tendr\u00e1 que afrontar la carga aumentando directamente los recursos computacionales y utilizando escalado horizontal.<\/li>\n
  5. Cuotas y rendimiento de servicios externos. <\/strong>Durante un crecimiento r\u00e1pido, el problema puede surgir no solo en tu infraestructura, sino tambi\u00e9n en el servicio externo. Lo m\u00e1s frustrante es cuando esto ocurre no por un fallo, sino por alcanzar cuotas o l\u00edmites. As\u00ed que los servicios externos deben escalar tan bien como t\u00fa mismo.\u00a0<\/li>\n
  6. Separa procesos y colas. <\/strong>Esto ayuda mucho cuando hay un bloqueo en uno de los gateways. No habr\u00edamos enfrentado retrasos en la transmisi\u00f3n de datos si las colas llenas para el env\u00edo de SMS no interfirieran con el intercambio de notificaciones entre los sistemas de informaci\u00f3n. Adem\u00e1s, ser\u00eda m\u00e1s f\u00e1cil aumentar el n\u00famero de trabajadores si trabajaran por separado.<\/li>\n
  7. Realidades financieras.<\/strong> Cuando hay un crecimiento explosivo de flujos de datos, no hay tiempo para pensar en tarifas y suscripciones. Pero debes mantenerlos en mente, especialmente si eres una peque\u00f1a empresa. Una gran factura puede ser presentada por el propietario de cualquier API, as\u00ed como por tu proveedor de alojamiento. As\u00ed que debes leer los contratos con atenci\u00f3n.<\/li>\n<\/ol>\n

    <\/p>\n

    Conclusi\u00f3n<\/h2>\n

    \nNo sin p\u00e9rdidas, pero hemos superado esta etapa y hoy nos esforzamos por seguir todos los principios encontrados, y cada m\u00e1quina tiene la posibilidad de aumentar su rendimiento hasta 4 veces para lidiar con imprevistos.\u00a0<\/p>\n

    En las pr\u00f3ximas publicaciones compartiremos nuestra experiencia en la investigaci\u00f3n de la ca\u00edda de rendimiento en Apache Solr, as\u00ed como sobre la optimizaci\u00f3n de consultas y c\u00f3mo la interacci\u00f3n con la FNS ayuda a la empresa a ahorrar dinero. Suscr\u00edbete a nuestro blog para no perderte nada y cu\u00e9ntanos en los comentarios si has tenido problemas similares durante el aumento del tr\u00e1fico.<\/p>\n

    \"C\u00f3mo<\/p>\n

    Solo los usuarios registrados pueden participar en la encuesta. Inicie sesi\u00f3n<\/a><\/noindex>, por favor.<\/p>\n

    \u00bfHas experimentado disminuciones o ca\u00eddas en el servicio debido a un aumento repentino en la carga por:<\/h2>\n