WAF<\/a> con inspecci\u00f3n profunda, lo sufriste m\u00e1s: el camino hacia tu contenido era m\u00e1s largo y cada paso extra era un punto de quiebre.<\/p>\n\n\n\n\u00bfPor qu\u00e9 esto importa? Porque una ca\u00edda as\u00ed no es \u201cun rayo en cielo despejado\u201d; es un recordatorio pr\u00e1ctico de que la fiabilidad<\/strong> es una funci\u00f3n de dise\u00f1o, no un deseo. La diferencia entre drama y an\u00e9cdota no est\u00e1 en el incidente, sino en cu\u00e1nto tardas en mostrar algo \u00fatil, cobrar y explicar con calma qu\u00e9 pasa. Ah\u00ed se mide la madurez de un stack\u2026 y de un equipo.<\/p>\n\n\n\n
\n\n\n\nCausa t\u00e9cnica sin rodeos: del \u201cfeature file\u201d a los 5xx (explicado f\u00e1cil)<\/h2>\n\n\n\n
La explicaci\u00f3n corta: un cambio aparentemente menor en c\u00f3mo se alimentaba de se\u00f1ales la capa de Bot Management<\/strong> desencaden\u00f3 un crecimiento inesperado de un archivo\/estructura (\u201cfeature file\u201d) que el sistema usa para decidir si alguien es bot o humano. Ese crecimiento empuj\u00f3 l\u00edmites de memoria y degrad\u00f3 componentes que, a su vez, alimentan otras piezas de la red. Resultado: efecto domin\u00f3. La IA que protege, si no est\u00e1 bien acotada, tambi\u00e9n puede tirar del hilo equivocado y deshacer el jersey.<\/p>\n\n\n\nDesgran\u00e1ndolo sin jerga innecesaria: los sistemas anti-bots combinan heur\u00edsticas, modelos y pipelines que procesan huellas del navegador, patrones de tr\u00e1fico, retos de JavaScript y scores de reputaci\u00f3n. Todo eso se resume en \u201cfeatures\u201d que se consultan al vuelo. Si un despliegue cambia la cardinalidad o el volumen de esas features (por ejemplo, a\u00f1adiendo campos, elevando granularidad o perdiendo limpieza de entradas), el archivo de referencia puede crecer m\u00e1s de la cuenta, invalidar cach\u00e9s, forzar rehidrataciones y abrir una cascada de lecturas\/escrituras. \u00bfTe suena a teor\u00eda? Ayer dej\u00f3 de serlo.<\/p>\n\n\n\n
En entornos distribuidos, los problemas raras veces se quedan en un solo sitio. Un microservicio que va al 100% de CPU empuja la cola, la cola obliga a reintentos, los reintentos multiplican las peticiones, las peticiones presionan al balanceador, el balanceador recalienta el edge\u2026 y as\u00ed. La soluci\u00f3n no es \u201cquitar la IA\u201d (ser\u00eda ingenuo): es poner guardarra\u00edles<\/strong>. L\u00edmites duros, cuotas por tenant, watchdogs que maten funciones cuando el ratio de errores excede umbrales, y circuit breakers<\/strong> que abran cuando determinada dependencia provoca m\u00e1s da\u00f1o que beneficio.<\/p>\n\n\n\nMoraleja: si una caracter\u00edstica \u201cde seguridad\u201d puede, en el peor caso, impedir servir contenido leg\u00edtimo, entonces necesitas un modo degradado seguro<\/strong> (hablo de esto m\u00e1s abajo) que mantenga el sitio respirando aunque con menos defensas, antes que un apag\u00f3n total.<\/p>\n\n\n\n
\n\n\n\nServicios afectados y cronolog\u00eda (horas clave y s\u00edntomas t\u00edpicos)<\/h2>\n\n\n\n
La jornada dej\u00f3 un patr\u00f3n com\u00fan en muchas plataformas:<\/p>\n\n\n\n
\n- Inicio del incidente:<\/strong> subida de latencias y picos de 4xx\/5xx intermitentes. Usuarios experimentando bucles de verificaci\u00f3n humana, timeouts en logins y APIs que no respond\u00edan.<\/li>\n\n\n\n
- Fase de impacto amplio:<\/strong> degradaci\u00f3n visible en webs de alto tr\u00e1fico, apps sociales, servicios de IA y juegos online. El s\u00edntoma m\u00e1s frecuente: p\u00e1ginas que \u201cparecen vivas\u201d pero no completan acciones cr\u00edticas (checkout, login, pagos).<\/li>\n\n\n\n
- Comunicaciones y mitigaci\u00f3n:<\/strong> anuncios de incidencia, actualizaciones parciales, y\u2014curiosamente\u2014status pages de algunos servicios tambi\u00e9n con problemas, se\u00f1al de que estaban dentro del mismo per\u00edmetro afectado.<\/li>\n\n\n\n
- Recuperaci\u00f3n progresiva:<\/strong> primero restablecimiento del tr\u00e1fico en regiones, luego normalizaci\u00f3n del challenge\/scoreo, despu\u00e9s descenso de errores 5xx. Finalmente, nota de \u201cmonitoring\u201d mientras se estabilizaban colas y repoblaciones de cach\u00e9.<\/li>\n<\/ul>\n\n\n\n
Si operabas un eCommerce, el golpe t\u00edpicamente se tradujo en carritos que no avanzaban y callbacks de pago fallidos. En SaaS, soporte saturado y clientes preguntando si \u201cles hab\u00edan hackeado\u201d. En medios, peaks de visitas a p\u00e1ginas est\u00e1ticas que s\u00ed cargaban (home cacheada) y ca\u00edda de rutas m\u00e1s din\u00e1micas. En todos los casos, qued\u00f3 claro que seguimos construyendo ciudades enteras sobre dos o tres autopistas: cuando una se corta, no basta con pitar; hay que tener desv\u00edos se\u00f1alizados.<\/p>\n\n\n\n
Mi consejo para la pr\u00f3xima: documenta tu propia cronolog\u00eda interna<\/strong>. Hora exacta del primer s\u00edntoma, primeras m\u00e9tricas afectadas, hip\u00f3tesis inicial, decisi\u00f3n de activar degradaci\u00f3n, mensajes enviados y tiempos de recuperaci\u00f3n. Ese \u201cpostmortem de bolsillo\u201d vale oro para ajustar alertas y respuestas.<\/p>\n\n\n\n
\n\n\n\nLo que nos ense\u00f1\u00f3 el incidente: dependencias invisibles y blast radius<\/h2>\n\n\n\n
Primera lecci\u00f3n: dependencias invisibles<\/strong>. Muchos descubrieron que todo pasaba por el mismo t\u00fanel: CDN, WAF, DNS, Bot Management\u2026 Comod\u00edsimo hasta que no. No se trata de \u201chuir\u201d del proveedor, sino de dise\u00f1ar pensando en fallos parciales<\/strong>. \u00bfTienes rutas de escape? \u00bfPuedes degradar funciones sin apagar el sitio entero? \u00bfTu DNS y tu status page viven fuera de la misma jaula?<\/p>\n\n\n\nSegunda: el blast radius<\/strong>. Si un ajuste en se\u00f1ales para un modelo puede desbordar memoria, necesitas feature flags<\/strong> de verdad, no solo booleanos simp\u00e1ticos en un panel. Meter una funci\u00f3n detr\u00e1s de un flag sin l\u00edmites es como poner una puerta giratoria en una autopista: si se atasca, te llevas por delante todo el tr\u00e1fico. Los guardarra\u00edles que s\u00ed funcionan: l\u00edmites de QPS por servicio, colas con tama\u00f1os m\u00e1ximos y rechazo elegante, tasas de retry con backoff exponencial y jitter, y breakers que abran circuitos antes de colapsar.<\/p>\n\n\n\nTercera: el dilema de la seguridad que cae<\/strong>. Parad\u00f3jico pero real: el m\u00f3dulo hecho para proteger contra scraping y automatizaci\u00f3n termina empujando a los buenos al abismo. La soluci\u00f3n no es \u201capagamos seguridad y a correr\u201d, sino un modo \u00e1mbar<\/strong>: reglas m\u00ednimas de defensa (listas de bloqueo conocidas, rate limits conservadores, validaciones b\u00e1sicas) que permitan servir contenido durante la tormenta. Prefiero un sitio parcialmente expuesto durante minutos con l\u00edmites estrictos, a un ecommerce muerto una hora en pleno pico.<\/p>\n\n\n\nY cuarta: comunicaci\u00f3n<\/strong>. Si tu status page cae con el proveedor, no tienes status page. Necesitas redundancia fuera del mismo per\u00edmetro y un canal sincronizado (newsletter, X, LinkedIn, email a clientes enterprise). Decir la verdad, pronto y con precisi\u00f3n, reduce tickets y salva reputaci\u00f3n.<\/p>\n\n\n\n
\n\n\n\nDe la teor\u00eda a la pr\u00e1ctica: tu plan de degradaci\u00f3n en 7 pasos<\/h2>\n\n\n\n\n- P\u00e1gina est\u00e1tica fuera de banda.<\/strong> Mant\u00e9n una landing est\u00e1tica cacheada en un origen alternativo (otro proveedor o un bucket p\u00fablico con CDN distinto). Debe explicar que hay incidencia, incluir el m\u00ednimo de SEO y ofrecer acciones \u00fatiles (contacto, estado, acceso a documentaci\u00f3n offline).<\/li>\n\n\n\n
- Rutas cr\u00edticas sin JS pesado.<\/strong> Ten versiones \u201cligeras\u201d de \/login, \/checkout y \/status que no dependan de recursos de terceros. HTML+CSS+un poco de JS vanilla es suficiente para sobrevivir.<\/li>\n\n\n\n
- Banner y UX de contingencia.<\/strong> No ocultes el problema: un banner claro reduce rebotes y evita que usuarios repitan acciones que van a fallar.<\/li>\n\n\n\n
- Toggle de features non-core.<\/strong> Conmutadores para apagar recomendaciones, personalizaci\u00f3n agresiva o terceros que no sean esenciales para cobrar o servir contenido.<\/li>\n\n\n\n
- Controles de cach\u00e9 y TTL sensatos.<\/strong> TTL m\u00e1s largos para assets inmutables; \u201cstale-while-revalidate\u201d para contenido semiest\u00e1tico; y bypass controlado para rutas din\u00e1micas cr\u00edticas.<\/li>\n\n\n\n
- Kill-switch independientes.<\/strong> Deben funcionar incluso si el panel principal est\u00e1 ca\u00eddo. Scripts o endpoints internos que fuerzan reglas m\u00ednimas o apagan m\u00f3dulos problem\u00e1ticos.<\/li>\n\n\n\n
- Runbook de comunicaci\u00f3n.<\/strong> Plantillas de mensajes para clientes, status y redes, con m\u00e9tricas concretas (qu\u00e9 afecta, qu\u00e9 no, ETA de la pr\u00f3xima actualizaci\u00f3n, v\u00edas alternativas).<\/li>\n<\/ol>\n\n\n\n
Durante la incidencia, yo priorizo: mantener una cara p\u00fablica \u00fatil (aunque sea b\u00e1sica), cobrar si es posible y capturar datos de contacto para retomar pedidos. Despu\u00e9s, postmortem con foco en decisiones: \u00bfqu\u00e9 apagaste? \u00bfqu\u00e9 qued\u00f3 activo? \u00bfqu\u00e9 m\u00e9tricas te hicieron actuar? Itera el runbook: el que no se prueba, no existe.<\/p>\n\n\n\n
\n\n\n\nDNS, cach\u00e9 y \u201cmodo \u00e1mbar\u201d de seguridad: servir algo antes que caer del todo<\/h2>\n\n\n\n
DNS.<\/strong> Si tu DNS est\u00e1 en el mismo proveedor que todo lo dem\u00e1s, ya sabes el riesgo. Configura al menos un plan de failover<\/strong>: zona replicada en un segundo proveedor (aunque sea activaci\u00f3n manual), registros cr\u00edticos listos para apuntar a un origen alternativo y TTL que te den margen (ni 5 segundos ni 1 d\u00eda; piensa en minutos bien elegidos seg\u00fan tu tr\u00e1fico). Automatiza lo que puedas, pero acepta que el \u201cmodo manual\u201d es a veces el plan B m\u00e1s robusto.<\/p>\n\n\n\nCach\u00e9.<\/strong> La cach\u00e9 no es una capa m\u00e1gica; es una decisi\u00f3n de producto. Identifica qu\u00e9 puedes servir en stale<\/strong> con seguridad: posts, fichas informativas, documentaci\u00f3n, landing de precios. Define pol\u00edticas \u201cstale-if-error\u201d y \u201cstale-while-revalidate\u201d. En un evento as\u00ed, un 70% de tu tr\u00e1fico puede quedar satisfecho con contenido viejo 5\u201330 minutos si se lo explicas bien al usuario.<\/p>\n\n\n\nModo \u00e1mbar de seguridad.<\/strong> Establece por adelantado un set m\u00ednimo de reglas cuando la seguridad \u201cinteligente\u201d se vuelve un cuello de botella. Piensa en:<\/p>\n\n\n\n\n- Rate limits<\/strong> conservadores por IP\/ASN para zonas cr\u00edticas.<\/li>\n\n\n\n
- Bloqueos de firmas conocidas<\/strong> (listas de reputaci\u00f3n est\u00e1ticas) que no dependan de modelos din\u00e1micos.<\/li>\n\n\n\n
- Desaf\u00edos livianos<\/strong> solo en endpoints sensibles, no en todo el sitio.<\/li>\n\n\n\n
- Observabilidad reducida<\/strong>: si tus pipelines de logging\/ML se ahogan, baja cardinalidad y conserva lo esencial.<\/li>\n<\/ul>\n\n\n\n
Este modo debe activarse con un switch simple<\/strong> y revertirse igual de f\u00e1cil. Documenta las condiciones de entrada\/salida (por ejemplo: si error budget de la capa de seguridad se consume >X% en Y minutos, activa \u00e1mbar; cuando el p95 de latencia y la tasa de \u00e9xito vuelvan a l\u00edmites, regresa a verde).<\/p>\n\n\n\n
\n\n\n\nObservabilidad que salva: SLOs por presupuesto de errores y kill-switch reales<\/h2>\n\n\n\n
La observabilidad no es el mural bonito de la oficina, es tu sistema nervioso<\/strong>. Define SLOs<\/strong> (objetivos de nivel de servicio) basados en experiencia de usuario: tasa de \u00e9xito por ruta, latencia p95\/p99, porcentaje de pedidos completados. A partir de ah\u00ed, calcula error budgets<\/strong>. Cuando un proveedor externo empieza a gastar ese presupuesto, la plataforma debe tomar decisiones autom\u00e1ticas: bajar un nivel de seguridad, reducir features, recortar tr\u00e1fico no esencial.<\/p>\n\n\n\nTres piezas pr\u00e1cticas:<\/p>\n\n\n\n
\n- Alertas por s\u00edntoma, no por CPU.<\/strong> Menos spam de m\u00e9tricas internas; m\u00e1s se\u00f1ales de usuario (c\u00f3digos de respuesta, latencias en el edge, conversiones).<\/li>\n\n\n\n
- Circuit breakers.<\/strong> Si una dependencia dispara errores sostenidos, el breaker abre y devuelve respuestas degradadas o cacheadas sin seguir golpeando la dependencia.<\/li>\n\n\n\n
- Rollbacks en fr\u00edo.<\/strong> Versiones estables listas para entrar sin rebuilds. No conf\u00edes en que \u201cya compila r\u00e1pido\u201d. En crisis, lo r\u00e1pido es lo que ya est\u00e1.<\/li>\n<\/ul>\n\n\n\n
Y, por favor, kill-switch reales<\/strong>. He visto demasiados toggles que dependen del mismo panel afectado. Necesitas un plan B: scripts firmados, CLI interna o un panel minimalista servido desde otra regi\u00f3n\/proveedor que permita apagar m\u00f3dulos peligrosos (por ejemplo, inspecci\u00f3n avanzada de bots) sin contactar a medio mundo.<\/p>\n\n\n\n
\n\n\n\nChecklist para simulacros y pruebas de caos (con m\u00e9tricas de salida)<\/h2>\n\n\n\n\n- Ejercicio trimestral de degradaci\u00f3n.<\/strong> Objetivo: en 10 minutos, levantar landing est\u00e1tica fuera de banda y banner global. M\u00e9trica de salida: tiempo hasta \u201calgo \u00fatil\u201d visible.<\/li>\n\n\n\n
- Failover DNS manual.<\/strong> Cambiar registros cr\u00edticos a un origen alterno. M\u00e9trica: TTL efectivo + tiempo humano < X minutos.<\/li>\n\n\n\n
- Apagado controlado del WAF avanzado.<\/strong> Activar modo \u00e1mbar con reglas m\u00ednimas. M\u00e9trica: reducci\u00f3n de 5xx > Y% sin disparar abusos medibles.<\/li>\n\n\n\n
- Chaos en horas valle.<\/strong> Cortar una dependencia (por ejemplo, motor de recomendaciones) y medir impacto real en conversi\u00f3n.<\/li>\n\n\n\n
- Status fuera del per\u00edmetro.<\/strong> Verificar que la p\u00e1gina de estado y el canal de comunicaci\u00f3n externo siguen vivos cuando el principal no lo est\u00e1.<\/li>\n\n\n\n
- Postmortem corto.<\/strong> 1 p\u00e1gina: qu\u00e9 pas\u00f3, qu\u00e9 hicimos, qu\u00e9 cambiaremos. Accionable, sin poes\u00eda.<\/li>\n\n\n\n
- Formaci\u00f3n cruzada.<\/strong> Que al menos dos personas por turno sepan ejecutar el runbook sin pedir permisos especiales.<\/li>\n<\/ul>\n\n\n\n
Si te suena mucho trabajo, piensa en el costo de una hora de ca\u00edda en pico. No se trata de paranoia: se trata de aceptar que la pr\u00f3xima ca\u00edda llegar\u00e1\u2014de \u00e9ste u otro proveedor\u2014y decidir si te pilla con el plan impreso o con el meme del \u201cintern\u00e9\u00e9\u00e9\u2026\u201d en bucle.<\/p>\n\n\n\n
\n\n\n\nPreguntas frecuentes: errores \u201cchallenges\u201d, 5xx y m\u00e1s<\/h2>\n\n\n\n
\u00bfPor qu\u00e9 veo retos infinitos de verificaci\u00f3n humana?<\/strong>
Porque la capa que decide si eres humano o bot est\u00e1 estresada o inconsistentes sus se\u00f1ales. Si el score no llega o llega tarde, te deja en un limbo. En modo \u00e1mbar, limita esos retos a endpoints sensibles y sirve el resto con reglas m\u00ednimas.<\/p>\n\n\n\n\u00bfC\u00f3mo reduzco el impacto si dependo de un \u00fanico proveedor?<\/strong>
Con duplicaci\u00f3n inteligente: DNS alterno (aunque sea manual), origen de emergencia, landing est\u00e1tica fuera de banda, TTL razonables, cach\u00e9 \u201cstale-if-error\u201d, y un runbook claro para apagar funciones no esenciales.<\/p>\n\n\n\n\u00bfQu\u00e9 hago si mi status page tambi\u00e9n cae?<\/strong>
Tener una segunda, fuera del mismo proveedor, con actualizaciones r\u00e1pidas. A\u00f1ade un listado de lo que funciona y lo que no, y un feed que puedas actualizar con baja fricci\u00f3n.<\/p>\n\n\n\n\u00bfSe debe apagar la seguridad cuando hay incidencia?<\/strong>
No. Se debe degradar inteligentemente<\/strong>: listas est\u00e1ticas, rate limits, menos inspecci\u00f3n avanzada. Sirve contenido y vigila m\u00e9tricas de abuso. Cuando el tr\u00e1fico y los errores se normalicen, vuelves a verde.<\/p>\n\n\n\n\u00bfC\u00f3mo explico esto a negocio sin tecnicismos?<\/strong>
Con tres datos: tiempo hasta mostrar algo \u00fatil, porcentaje de transacciones completadas durante la incidencia y tiempo total hasta recuperar la normalidad. Son m\u00e9tricas que entienden y que gu\u00edan inversi\u00f3n en resiliencia.<\/p>\n\n\n\n
\n\n\n\nSobre la ca\u00edda de cloudflare<\/h2>\n\n\n\n
Ayer fue un recordatorio brutal de que la resiliencia no es un bot\u00f3n, es una arquitectura con criterio. Mi lectura pr\u00e1ctica: dise\u00f1a para fallos parciales, limita tu blast radius, y prepara un modo \u00e1mbar que te permita seguir vendiendo y comunicando<\/strong> mientras arreglas lo roto. Porque s\u00ed, seguimos construyendo ciudades enteras sobre pocas autopistas; pero los desv\u00edos bien se\u00f1alizados hacen que un martes negro se quede en an\u00e9cdota y no en titular.<\/p>\n\n\n\nOpini\u00f3n Personal<\/strong><\/p>\n\n\n\nAyer muchos sentimos que Internet se qued\u00f3 sin pulso. No fue \u201cla red\u201d entera: fue una pieza cr\u00edtica de infraestructura que, al fallar, nos record\u00f3 lo fr\u00e1giles que somos cuando apostamos todo a un solo proveedor. Y aqu\u00ed va mi opini\u00f3n: la resiliencia no se delega<\/strong>. Ni en Cloudflare, ni en ning\u00fan otro. Se dise\u00f1a.<\/p>\n\n\n\nCelebro que existan plataformas que nos permiten ir m\u00e1s r\u00e1pido, m\u00e1s seguros, m\u00e1s baratos. Pero confundir comodidad con estrategia<\/strong> es un error caro. Si un ajuste en un m\u00f3dulo de bots puede dejar en jaque a medio ecosistema, la lecci\u00f3n es simple: diversifica, degrada, comunica<\/strong>. Diversifica proveedores y rutas de salida. Dise\u00f1a degradaci\u00f3n para servir \u201calgo\u201d \u00fatil cuando la capa inteligente se atora. Comunica con transparencia, y hazlo desde un canal que no dependa de la misma jaula.<\/p>\n\n\n\nLo m\u00e1s inc\u00f3modo de aceptar es que la seguridad tambi\u00e9n puede caerse. Por eso defiendo el modo \u00e1mbar<\/strong>: reglas m\u00ednimas, l\u00edmite estricto y continuidad del servicio. Es mejor vender menos por 20 minutos que no vender nada durante una hora. \u00bfRiesgos? S\u00ed. \u00bfControlables? Tambi\u00e9n. Lo contrario es tener una web \u201cperfecta\u201d que no carga.<\/p>\n\n\n\nOtro punto: la observabilidad<\/strong>. Si tus alertas hablan de CPU, vas tarde. Las alertas deben hablar de personas: tasa de \u00e9xito, latencia percibida, transacciones completadas. Cuando el presupuesto de error se consume, la plataforma debe decidir por s\u00ed sola: apagar funciones no esenciales, recortar complejidad, activar landing est\u00e1tica. Sin reuniones. Sin h\u00e9roes. Con protocolos.<\/p>\n\n\n\nY ya que hablamos de h\u00e9roes: el mejor \u201cincidente\u201d es el que ensayaste. Prueba tu plan de caos en horas valle. Cambia DNS a mano. Mide tiempo hasta mostrar algo \u00fatil. Documenta. Repite. La pr\u00f3xima ca\u00edda no es una posibilidad remota: es estad\u00edstica. La diferencia entre titular y an\u00e9cdota estar\u00e1 en qu\u00e9 tan r\u00e1pido tu equipo puede seguir cobrando y explicando<\/strong> mientras arregla lo roto.<\/p>\n\n\n\nEn resumen: admiro la innovaci\u00f3n, pero mi lealtad est\u00e1 con la continuidad. Menos magia opaca, m\u00e1s arquitectura con criterio. Menos \u201ctodo en uno\u201d, m\u00e1s opciones reales<\/strong>. Hoy no se trata de culpar; se trata de madurar.<\/p>\n\n\n\nAhora quiero leerte a ti: \u00bfc\u00f3mo viviste la ca\u00edda?, \u00bfqu\u00e9 te funcion\u00f3 y qu\u00e9 vas a cambiar<\/strong> en tu stack a partir de ahora? D\u00e9jame tus comentarios abajo y abramos el debate.<\/p>\n\n\n\n<\/p>\n","protected":false},"excerpt":{"rendered":"
Ayer internet son\u00f3 a cortocircuito. Esa fue exactamente la sensaci\u00f3n: pesta\u00f1as recargando sin fin, aplicaciones que no iniciaban sesi\u00f3n y un desfile de 5xx record\u00e1ndonos lo fr\u00e1gil que es todo cuando un proveedor clave tose. No fue \u201cla web\u201d entera; fue una pieza de infraestructura que muchos damos por descontada hasta que deja de estar\u2014y […]<\/p>\n","protected":false},"author":1,"featured_media":7315,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"set","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[1],"tags":[],"class_list":["post-7314","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-noticias"],"_links":{"self":[{"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/posts\/7314","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/comments?post=7314"}],"version-history":[{"count":3,"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/posts\/7314\/revisions"}],"predecessor-version":[{"id":7318,"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/posts\/7314\/revisions\/7318"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/media\/7315"}],"wp:attachment":[{"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/media?parent=7314"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/categories?post=7314"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/tags?post=7314"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}