{"id":80031,"date":"2020-05-02T13:42:49","date_gmt":"2020-05-02T11:42:49","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/top-fakapov-czian"},"modified":"2020-05-02T13:42:49","modified_gmt":"2020-05-02T11:42:49","slug":"top-fakapov-czian","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/top-fakapov-czian","title":{"rendered":"Los principales errores de Cian","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Los principales errores de Cian\" src=\"\/wp-content\/uploads\/2020\/05\/61cf8d25f1f3e858a3b9541cb026cf3c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n\u00a1Saludos a todos!\u00a0<\/p>\n<p>Me llamo Nikita, soy el l\u00edder del equipo de ingenieros en Cian. Una de mis responsabilidades en la empresa es reducir a cero la cantidad de incidentes relacionados con la infraestructura en producci\u00f3n.<br \/>\nLo que se abordar\u00e1 a continuaci\u00f3n nos ha causado mucho dolor, y el objetivo de este art\u00edculo es evitar que otras personas cometan nuestros errores o al menos minimizar su impacto.\u00a0<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>Pre\u00e1mbulo<\/h3>\n<p>\nHace mucho tiempo, cuando Cian consist\u00eda en monolitos y no hab\u00eda rastros de microservicios, med\u00edamos la disponibilidad del recurso verificando de 3 a 5 p\u00e1ginas.\u00a0<\/p>\n<p>Responden: todo est\u00e1 bien, no responden por un largo tiempo: alerta. Cu\u00e1nto tiempo deben estar fuera de servicio para que se considere un incidente, lo decid\u00edan las personas en las reuniones. El equipo de ingenieros siempre participaba en la investigaci\u00f3n del incidente. Cuando se conclu\u00eda la investigaci\u00f3n, escrib\u00edan un postmortem, un informe que se enviaba por correo en el formato: qu\u00e9 ocurri\u00f3, cu\u00e1nto dur\u00f3, qu\u00e9 hicimos en el momento, qu\u00e9 haremos en el futuro.\u00a0<\/p>\n<h3>P\u00e1ginas principales del sitio o c\u00f3mo entendemos que hemos tocado fondo<\/h3>\n<p>\u00a0<br \/>\nPara poder entender de alguna manera la prioridad del error, destacamos las p\u00e1ginas del sitio m\u00e1s cr\u00edticas para la funcionalidad del negocio. Sobre ellas, contamos la cantidad de solicitudes exitosas\/no exitosas y los timeouts. De esta manera, medimos el uptime.\u00a0<\/p>\n<p>Supongamos que hemos determinado que hay una serie de secciones super importantes del sitio que son responsables del servicio principal: b\u00fasqueda y presentaci\u00f3n de anuncios. Si el n\u00famero de solicitudes que finalizan con error supera el 1%, se considera un incidente cr\u00edtico. Si durante 15 minutos en la hora pico el porcentaje de errores supera el 0,1%, eso tambi\u00e9n se considera un incidente cr\u00edtico. Estos criterios cubren la mayor parte de los incidentes, los dem\u00e1s quedan fuera del alcance de este art\u00edculo.<\/p>\n<p><img decoding=\"async\" alt=\"Los principales errores de Cian\" src=\"\/wp-content\/uploads\/2020\/05\/f5d76b1784c9a52ae1dc4728f1509ccc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Los mejores incidentes de Cian<\/h3>\n<p>\nAs\u00ed que hemos aprendido a determinar con precisi\u00f3n que un incidente ha ocurrido.\u00a0<\/p>\n<p>Ahora cada incidente est\u00e1 detalladamente descrito y reflejado en un epico de Jira. Por cierto: para esto hemos creado un proyecto separado y lo llamamos FAIL, en el que solo se pueden crear \u00e9picos.\u00a0<\/p>\n<p>Si recopilamos todos los fallos de los \u00faltimos a\u00f1os, los l\u00edderes son:\u00a0<\/p>\n<ul>\n<li>incidentes relacionados con mssql;<\/li>\n<li>incidentes causados por factores externos;<\/li>\n<li>errores de administrador.<\/li>\n<\/ul>\n<p>\nDeteng\u00e1monos a detallar m\u00e1s sobre los errores de los administradores, as\u00ed como sobre otros fallos interesantes.<\/p>\n<h4>Quinto lugar \u2014 'Organizando el DNS'<\/h4>\n<p>\nEra un martes lluvioso. Decidimos ordenar el cl\u00faster DNS.\u00a0<\/p>\n<p>Quisimos migrar los servidores DNS internos de bind a powerdns, dedicando servidores totalmente separados, donde no hubiera nada m\u00e1s que DNS.\u00a0<\/p>\n<p>Colocamos un servidor DNS en cada ubicaci\u00f3n de nuestros centros de datos, y lleg\u00f3 el momento de migrar las zonas de bind a powerdns y cambiar la infraestructura a los nuevos servidores.\u00a0<\/p>\n<p>En medio de la migraci\u00f3n, de todos <a class=\"wpil_keyword_link\" href=\"https:\/\/prohoster.info\/es\/server\/\"   title=\"servidores\" data-wpil-keyword-link=\"linked\"  data-wpil-monitor-id=\"1484\">servidores<\/a>, que estaban indicados en las cach\u00e9s locales de bind en todos los servidores, solo qued\u00f3 uno, que estaba en el centro de datos de San Petersburgo. Este centro de datos hab\u00eda sido declarado inicialmente como no cr\u00edtico para nosotros, pero de repente se convirti\u00f3 en un punto \u00fanico de falla.<br \/>\nJusto en ese per\u00edodo de migraci\u00f3n fall\u00f3 el canal entre Mosc\u00fa y San Petersburgo. Nos quedamos sin DNS durante cinco minutos y volvimos en l\u00ednea cuando <a class=\"wpil_keyword_link\" href=\"https:\/\/prohoster.info\/es\/\"   title=\"ofrezca una gran cantidad de espacio en disco.\" data-wpil-keyword-link=\"linked\"  data-wpil-monitor-id=\"1206\">ofrezca una gran cantidad de espacio en disco.<\/a> se resolvieron los problemas.\u00a0<\/p>\n<p><b>Conclusiones: <\/b><\/p>\n<p>Si antes ignor\u00e1bamos factores externos durante la preparaci\u00f3n para las tareas, ahora tambi\u00e9n los incluimos en la lista de lo que estamos preparando. Y ahora nos esforzamos por que todos los componentes est\u00e9n reservados n-2, y durante el tiempo de trabajo podemos reducir este nivel a n-1.<\/p>\n<ul>\n<li>Al elaborar el plan de acci\u00f3n, marque los puntos donde el servicio puede caer y desarrolle un escenario donde todo salga \"peor que nunca\", por adelantado.<\/li>\n<li>Distribuya los servidores DNS internos en diferentes ubicaciones geogr\u00e1ficas\/data centers\/bater\u00edas\/conmutadores\/entradas.<\/li>\n<li>En cada servidor, instale un servidor DNS local cach\u00e9 que redirija las solicitudes a los servidores DNS principales, y en caso de que no est\u00e9 disponible, responder\u00e1 desde la cach\u00e9.\u00a0<\/li>\n<\/ul>\n<p><\/p>\n<h4>El cuarto lugar - \"Organizando Nginx\"<\/h4>\n<p>\nUn buen d\u00eda, nuestro equipo decidi\u00f3 que \"ya era suficiente\" y se inici\u00f3 el proceso de refactorizaci\u00f3n de las configuraciones de nginx. El objetivo principal es dar a las configuraciones una estructura intuitiva. Antes, todo era \"hist\u00f3ricamente\" y no ten\u00eda ninguna l\u00f3gica. Ahora cada server_name se ha llevado a un archivo del mismo nombre y hemos distribuido todas las configuraciones en carpetas. Por cierto, la configuraci\u00f3n contiene 253949 l\u00edneas o 7836520 caracteres y ocupa casi 7 megabytes. El nivel superior de la estructura:\u00a0<\/p>\n<p>                        <b class=\"spoiler_title\">Estructura de Nginx<\/b><\/p>\n<pre><code class=\"plaintext\">\u251c\u2500\u2500 acceso\n\u2502 \u00a0 \u251c\u2500\u2500 allow.list\n...\n\u2502 \u00a0 \u2514\u2500\u2500 whitelist.conf\n\u251c\u2500\u2500 geobase\n\u2502 \u00a0 \u251c\u2500\u2500 exclude.conf\n...\n\u2502 \u00a0 \u2514\u2500\u2500 geo_ip_to_region_id.conf\n\u251c\u2500\u2500 geodb\n\u2502 \u00a0 \u251c\u2500\u2500 GeoIP.dat\n\u2502 \u00a0 \u251c\u2500\u2500 GeoIP2-Country.mmdb\n\u2502 \u00a0 \u2514\u2500\u2500 GeoLiteCity.dat\n\u251c\u2500\u2500 inc\n\u2502 \u00a0 \u251c\u2500\u2500 error.inc\n...\n\u2502 \u00a0 \u2514\u2500\u2500 proxy.inc\n\u251c\u2500\u2500 lists.d\n\u2502 \u00a0 \u251c\u2500\u2500 bot.conf\n...\n\u2502 \u00a0 \u251c\u2500\u2500 dynamic\n\u2502 \u00a0 \u2514\u2500\u2500 geo.conf\n\u251c\u2500\u2500 lua\n\u2502 \u00a0 \u251c\u2500\u2500 cookie.lua\n\u2502 \u00a0 \u251c\u2500\u2500 log\n\u2502 \u00a0 \u2502 \u00a0 \u2514\u2500\u2500 log.lua\n\u2502 \u00a0 \u251c\u2500\u2500 logics\n\u2502 \u00a0 \u2502 \u00a0 \u251c\u2500\u2500 include.lua\n\u2502 \u00a0 \u2502 \u00a0 \u251c\u2500\u2500 ...\n\u2502 \u00a0 \u2502 \u00a0 \u2514\u2500\u2500 utils.lua\n\u2502 \u00a0 \u2514\u2500\u2500 prom\n\u2502 \u00a0 \u00a0 \u00a0 \u251c\u2500\u2500 stats.lua\n\u2502 \u00a0 \u00a0 \u00a0 \u2514\u2500\u2500 stats_prometheus.lua\n\u251c\u2500\u2500 map.d\n\u2502 \u00a0 \u251c\u2500\u2500 access.conf\n\u2502 \u00a0 \u251c\u2500\u2500 ..\u00a0\n\u2502 \u00a0 \u2514\u2500\u2500 zones.conf\n\u251c\u2500\u2500 nginx.conf\n\u251c\u2500\u2500 robots.txt\n\u251c\u2500\u2500 server.d\n\u2502 \u00a0 \u251c\u2500\u2500 cian.ru\n\u2502 \u00a0 \u2502 \u00a0 \u251c\u2500\u2500 cian.ru.conf\n\u2502 \u00a0 \u2502 \u00a0 \u251c\u2500\u2500 ...\n\u2502 \u00a0 \u2502 \u00a0 \u2514\u2500\u2500 my.cian.ru.conf\n\u251c\u2500\u2500 service.d\n\u2502 \u00a0 \u251c\u2500\u2500 ...\n\u2502 \u00a0 \u2514\u2500\u2500 status.conf\n\u2514\u2500\u2500 upstream.d\n\u00a0\u00a0\u00a0\u00a0\u251c\u2500\u2500 cian-mcs.conf\n\u00a0\u00a0\u00a0\u00a0\u251c\u2500\u2500 ...\n\u00a0\u00a0\u00a0\u00a0\u2514\u2500\u2500 wafserver.conf<\/code><\/pre>\n<p>Ha mejorado significativamente, pero durante el proceso de renombrar y redistribuir las configuraciones, algunas de ellas ten\u00edan una extensi\u00f3n incorrecta y no se incluyeron en la directiva include *.conf. Como consecuencia, algunos hosts se volvieron inaccesibles y devolv\u00edan un 301 a la p\u00e1gina principal. Dado que el c\u00f3digo de respuesta no era 5xx\/4xx, no se not\u00f3 de inmediato, sino m\u00e1s bien por la ma\u00f1ana. Despu\u00e9s de eso, comenzamos a escribir pruebas para verificar los componentes de la infraestructura.<\/p>\n<p><b>Conclusiones:<\/b>\u00a0<\/p>\n<ul>\n<li>Estructura correctamente las configuraciones (no solo nginx) y planifica la estructura en las primeras etapas del proyecto. Esto las har\u00e1 m\u00e1s comprensibles para el equipo, lo que a su vez reducir\u00e1 el TTM.<\/li>\n<li>Para algunos componentes de infraestructura, escribe pruebas. Por ejemplo: verifica que todos los server_name clave devuelvan el estado correcto, m\u00e1s el cuerpo de la respuesta. Solo se necesitar\u00e1 tener a la mano unos pocos scripts que verifiquen las funciones principales del componente, para no recordar fren\u00e9ticamente a las 3 de la ma\u00f1ana que m\u00e1s hay que comprobar.\u00a0<\/li>\n<\/ul>\n<p><\/p>\n<h4>Tercer lugar: 'Repentinamente se acab\u00f3 el espacio en Cassandra'<\/h4>\n<p>\nLos datos crec\u00edan de manera constante y todo iba bien hasta que en el cl\u00faster de Cassandra comenzaron a fallar las reparaciones de grandes keyspaces, porque no pueden ejecutar la compactaci\u00f3n.\u00a0<\/p>\n<p>En un d\u00eda desafortunado, el cl\u00faster casi se convierte en calabaza, a saber:<\/p>\n<ul>\n<li>quedaba alrededor del 20% de espacio total en el cl\u00faster;<\/li>\n<li>no se pueden agregar nodos completamente, porque no pasa la limpieza despu\u00e9s de agregar un nodo debido a la falta de espacio en las particiones;<\/li>\n<li>el rendimiento disminuye poco a poco, ya que no funciona la compactaci\u00f3n;\u00a0<\/li>\n<li>el cl\u00faster opera en modo de emergencia.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"Los principales errores de Cian\" src=\"\/wp-content\/uploads\/2020\/05\/1d036fbc500a49a285fa4b0014e2a70d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLa salida: se a\u00f1adieron 5 nodos m\u00e1s sin limpieza, despu\u00e9s de lo cual comenzamos a retirar progresivamente del cl\u00faster e introducir nuevamente, como nodos vac\u00edos, en los que se hab\u00eda agotado el espacio. Se ha gastado mucho m\u00e1s tiempo del que quisi\u00e9ramos. Hab\u00eda un riesgo de indisponibilidad parcial o total del cl\u00faster.\u00a0<\/p>\n<p><b>Conclusiones:<\/b><\/p>\n<ul>\n<li>En todos los servidores de Cassandra, no debe ocupar m\u00e1s del 60% del espacio en cada partici\u00f3n.\u00a0<\/li>\n<li>Deben estar cargados no m\u00e1s del 50% de uso de CPU.<\/li>\n<li>No se debe descuidar la planificaci\u00f3n de capacidad y debe pensarse para cada componente, dependiendo de sus caracter\u00edsticas.<\/li>\n<li>Cuantos m\u00e1s nodos en el cl\u00faster, mejor. Los servidores que contienen un volumen peque\u00f1o de datos se reconfiguran m\u00e1s r\u00e1pido, y tal cl\u00faster es m\u00e1s f\u00e1cil de reanimar.\u00a0<\/li>\n<\/ul>\n<p><\/p>\n<h4>Segundo lugar: 'Se perdieron datos del almacenamiento key-value de Consul'<\/h4>\n<p>\nPara el descubrimiento de servicios, nosotros, como muchos, usamos Consul. Pero en nuestro caso, su key-value se utiliza tambi\u00e9n para el despliegue blue-green del monolito. All\u00ed se almacena informaci\u00f3n sobre los upstream activos e inactivos, que cambian de lugar durante el despliegue. Para ello, se escribi\u00f3 un servicio de despliegue que interactuaba con KV. En alg\u00fan momento, los datos de KV desaparecieron. Se recuperaron de memoria, pero con varios errores. Como resultado, durante el despliegue, la carga en los upstream se distribuy\u00f3 de manera desigual y obtuvimos muchos errores 502 debido a la sobrecarga de los backend por CPU. Al final, migramos de Consul KV a Postgres, desde donde ya no es tan f\u00e1cil eliminarlos.\u00a0\u00a0<\/p>\n<p><b>Conclusiones:<br \/>\n<\/b><\/p>\n<ul>\n<li>Los servicios sin ning\u00fan tipo de autorizaci\u00f3n no deben contener datos cr\u00edticos para el funcionamiento del sitio. Por ejemplo, si no tiene autorizaci\u00f3n en ES, es mejor prohibir el acceso a nivel de red desde donde no sea necesario, dejando solo los accesos necesarios, as\u00ed como configurar action.destructive_requires_name: true.<\/li>\n<li>Pruebe el mecanismo de copia de seguridad y restauraci\u00f3n con antelaci\u00f3n. Por ejemplo, prepare un script (por ejemplo, en Python) que pueda hacer copias de seguridad y restaurar.<\/li>\n<\/ul>\n<p><\/p>\n<h4>Primer lugar: 'Capit\u00e1n Obviedad'\u00a0<\/h4>\n<p>\nEn alg\u00fan momento, notamos una distribuci\u00f3n desigual de carga en los upstreams de nginx cuando hab\u00eda m\u00e1s de 10 servidores en el backend. Debido a que el round-robin dirig\u00eda las solicitudes desde el primer hasta el \u00faltimo upstream de manera secuencial, y cada recarga de nginx comenzaba de nuevo, los primeros upstreams siempre recib\u00edan m\u00e1s solicitudes que los dem\u00e1s. Como consecuencia, funcionaban m\u00e1s lentamente y todo el sitio sufr\u00eda. Esto se volv\u00eda cada vez m\u00e1s evidente a medida que aumentaba el tr\u00e1fico. Simplemente actualizar nginx para incluir random no funcion\u00f3; hab\u00eda que rehacer un mont\u00f3n de c\u00f3digo Lua que no funcionaba en la versi\u00f3n 1.15 (en ese momento). Tuvimos que parchar nuestro nginx 1.14.2, incorporando soporte para random. Esto resolvi\u00f3 el problema. Este error se lleva el premio a \u00abcapit\u00e1n de la obviedad\u00bb.<\/p>\n<p><b>Conclusiones:<\/b><\/p>\n<p>Fue muy interesante y emocionante investigar este error).\u00a0<\/p>\n<ul>\n<li>Configura el monitoreo de tal manera que ayude a detectar r\u00e1pidamente fluctuaciones similares. Por ejemplo, puedes utilizar ELK para observar el rps de cada backend de cada upstream, y seguir su tiempo de respuesta desde la perspectiva de nginx. En este caso, eso nos ayud\u00f3 a identificar el problema.\u00a0<\/li>\n<\/ul>\n<p>\nEn la mayor\u00eda de los fallos se podr\u00eda haber evitado con un enfoque m\u00e1s meticuloso sobre lo que se est\u00e1 haciendo. Siempre hay que recordar la ley de Murphy:\u00a0<i>Anything that can go wrong will go wrong, <\/i>y construir componentes gui\u00e1ndose por ella.\u00a0<br \/>\n<br \/>Fuente: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/cian\/blog\/499542\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0412\u0441\u0435\u043c \u0434\u043e\u0431\u0440\u0430!\u00a0 \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u041d\u0438\u043a\u0438\u0442\u0430, \u044f \u0442\u0438\u043c\u043b\u0438\u0434 \u043a\u043e\u043c\u0430\u043d\u0434\u044b \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u043e\u0432 \u0426\u0438\u0430\u043d. \u041e\u0434\u043d\u043e\u0439 \u0438\u0437 \u043c\u043e\u0438\u0445 \u043e\u0431\u044f\u0437\u0430\u043d\u043d\u043e\u0441\u0442\u0435\u0439 \u0432 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0441\u043d\u0438\u0436\u0435\u043d\u0438\u0435 \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u0430 \u0438\u043d\u0446\u0438\u0434\u0435\u043d\u0442\u043e\u0432, \u0441\u0432\u044f\u0437\u0430\u043d\u043d\u044b\u0445 \u0441 \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u043e\u0439 \u043d\u0430 \u043f\u0440\u043e\u0434\u0435, \u0434\u043e \u043d\u0443\u043b\u044f. \u0422\u043e, \u043e \u0447\u0435\u043c \u043f\u043e\u0439\u0434\u0435\u0442 \u0440\u0435\u0447\u044c \u0434\u0430\u043b\u0435\u0435, \u043f\u0440\u0438\u043d\u0435\u0441\u043b\u043e \u043d\u0430\u043c \u043c\u043d\u043e\u0433\u043e \u0431\u043e\u043b\u0438, \u0438 \u0446\u0435\u043b\u044c \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0438 \u2014 \u043d\u0435 \u0434\u0430\u0442\u044c \u0434\u0440\u0443\u0433\u0438\u043c \u043b\u044e\u0434\u044f\u043c \u043f\u043e\u0432\u0442\u043e\u0440\u0438\u0442\u044c \u043d\u0430\u0448\u0438\u0445 \u043e\u0448\u0438\u0431\u043e\u043a \u0438\u043b\u0438 \u0445\u043e\u0442\u044f \u0431\u044b \u043c\u0438\u043d\u0438\u043c\u0438\u0437\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0438\u0445 \u0432\u043b\u0438\u044f\u043d\u0438\u0435.\u00a0 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":80032,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-80031","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0412\u0441\u0435\u043c \u0434\u043e\u0431\u0440\u0430! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u041d\u0438\u043a\u0438\u0442\u0430, \u044f \u0442\u0438\u043c\u043b\u0438\u0434 \u043a\u043e\u043c\u0430\u043d\u0434\u044b \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u043e\u0432 \u0426\u0438\u0430\u043d.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/top-fakapov-czian\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"es_ES\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0422\u043e\u043f \u0444\u0430\u043a\u0430\u043f\u043e\u0432 \u0426\u0438\u0430\u043d | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0412\u0441\u0435\u043c \u0434\u043e\u0431\u0440\u0430! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u041d\u0438\u043a\u0438\u0442\u0430, \u044f \u0442\u0438\u043c\u043b\u0438\u0434 \u043a\u043e\u043c\u0430\u043d\u0434\u044b \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u043e\u0432 \u0426\u0438\u0430\u043d.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/top-fakapov-czian\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-05-02T11:42:49+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-05-02T11:42:49+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Top errores de Cian | ProHoster","description":"\u00a1Saludos a todos! Me llamo Nikita, soy el l\u00edder del equipo de ingenieros de Cian.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/top-fakapov-czian","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0422\u043e\u043f \u0444\u0430\u043a\u0430\u043f\u043e\u0432 \u0426\u0438\u0430\u043d | ProHoster","og:description":"\u0412\u0441\u0435\u043c \u0434\u043e\u0431\u0440\u0430! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u041d\u0438\u043a\u0438\u0442\u0430, \u044f \u0442\u0438\u043c\u043b\u0438\u0434 \u043a\u043e\u043c\u0430\u043d\u0434\u044b \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u043e\u0432 \u0426\u0438\u0430\u043d.","og:url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/top-fakapov-czian","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-05-02T11:42:49+00:00","article:modified_time":"2020-05-02T11:42:49+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"80031","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 12:47:44","updated":"2026-02-09 16:50:24","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/80031","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=80031"}],"version-history":[{"count":2,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/80031\/revisions"}],"predecessor-version":[{"id":158728,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/80031\/revisions\/158728"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media\/80032"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=80031"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=80031"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=80031"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}