{"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\/pt\/blog\/administrirovanie\/top-fakapov-czian","title":{"rendered":"Os principais erros da Cian","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Os principais erros da Cian\" src=\"\/wp-content\/uploads\/2020\/05\/61cf8d25f1f3e858a3b9541cb026cf3c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nOl\u00e1 a todos!\u00a0<\/p>\n<p>Meu nome \u00e9 Nikita, sou o l\u00edder da equipe de engenheiros da Cian. Uma das minhas responsabilidades na empresa \u00e9 reduzir o n\u00famero de incidentes relacionados \u00e0 infraestrutura em produ\u00e7\u00e3o para zero.<br \/>\nO que ser\u00e1 discutido a seguir nos trouxe muita dor, e o objetivo deste artigo \u00e9 evitar que outras pessoas cometam nossos erros ou, pelo menos, minimizar seu impacto.\u00a0<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>Pr\u00e9\u00e2mbulo<\/h3>\n<p>\nH\u00e1 muito tempo, quando a Cian era composta por mon\u00f3litos e ainda n\u00e3o havia ind\u00edcios de microsservi\u00e7os, med\u00edamos a disponibilidade do recurso verificando de 3 a 5 p\u00e1ginas.\u00a0<\/p>\n<p>Quando respondem \u2014 tudo bem, quando n\u00e3o respondem por muito tempo \u2014 alerta. O quanto de tempo elas devem ficar fora do ar para que seja considerado um incidente, era decidido em reuni\u00f5es. A equipe de engenheiros sempre participava da investiga\u00e7\u00e3o do incidente. Quando a investiga\u00e7\u00e3o terminava, escrev\u00edamos um postmortem \u2014 um tipo de relat\u00f3rio enviado por e-mail no formato: o que aconteceu, quanto tempo durou, o que fizemos no momento, o que faremos no futuro.\u00a0<\/p>\n<h3>P\u00e1ginas principais do site ou como sabemos que atingimos o fundo do po\u00e7o<\/h3>\n<p>\u00a0<br \/>\nPara que pud\u00e9ssemos entender de alguma forma a prioridade do erro, destacamos as p\u00e1ginas do site que s\u00e3o mais cr\u00edticas para a funcionalidade do neg\u00f3cio. Para elas, contamos o n\u00famero de requisi\u00e7\u00f5es bem-sucedidas \/ malsucedidas e timeouts. Assim, medimos o uptime.\u00a0<\/p>\n<p>Suponha que descobrimos que h\u00e1 uma s\u00e9rie de se\u00e7\u00f5es super importantes do site, que s\u00e3o respons\u00e1veis pelo principal servi\u00e7o \u2014 busca e envio de an\u00fancios. Se o n\u00famero de requisi\u00e7\u00f5es que resultaram em erro ultrapassa 1%, isso \u00e9 um incidente cr\u00edtico. Se durante 15 minutos em hor\u00e1rio de pico a porcentagem de erros supera 0,1% \u2014 isso tamb\u00e9m \u00e9 considerado um incidente cr\u00edtico. Esses crit\u00e9rios cobrem a maior parte dos incidentes; os demais est\u00e3o fora do escopo deste artigo.<\/p>\n<p><img decoding=\"async\" alt=\"Os principais erros da Cian\" src=\"\/wp-content\/uploads\/2020\/05\/f5d76b1784c9a52ae1dc4728f1509ccc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Top melhores incidentes da Cian<\/h3>\n<p>\nPortanto, aprendemos a identificar claramente quando um incidente ocorre.\u00a0<\/p>\n<p>Agora, cada incidente \u00e9 detalhadamente descrito e refletido na \u00e9pica do Jira. A prop\u00f3sito: para isso criamos um projeto separado, chamamos de FAIL \u2014 nele s\u00f3 \u00e9 poss\u00edvel criar \u00e9picas.\u00a0<\/p>\n<p>Se reunirmos todos os fracassos dos \u00faltimos anos, os principais s\u00e3o:\u00a0<\/p>\n<ul>\n<li>incidentes relacionados ao mssql;<\/li>\n<li>incidentes causados por fatores externos;<\/li>\n<li>erros de administra\u00e7\u00e3o.<\/li>\n<\/ul>\n<p>\nVamos nos aprofundar mais nos erros de administra\u00e7\u00e3o, bem como em alguns outros fracassos interessantes.<\/p>\n<h4>Quinto lugar \u2014 \"Colocando ordem no DNS\"<\/h4>\n<p>\nFoi uma ter\u00e7a-feira chuvosa. Decidimos organizar o cluster DNS.\u00a0<\/p>\n<p>Quisemos migrar os servidores DNS internos de BIND para PowerDNS, dedicando servidores inteiramente para isso, onde n\u00e3o h\u00e1 nada al\u00e9m do DNS.\u00a0<\/p>\n<p>Colocamos um servidor DNS em cada localiza\u00e7\u00e3o dos nossos datacenters, e chegou o momento de migrar as zonas de BIND para PowerDNS e direcionar a infraestrutura para os novos servidores.\u00a0<\/p>\n<p>No auge da migra\u00e7\u00e3o, de todos <a class=\"wpil_keyword_link\" href=\"https:\/\/prohoster.info\/pt\/server\/\"   title=\"servidores\" data-wpil-keyword-link=\"linked\"  data-wpil-monitor-id=\"1484\">servidores<\/a>, que estavam configurados nos caches locais de BIND em todos os servidores, restou apenas um, localizado no datacenter em S\u00e3o Petersburgo. Este datacenter havia sido inicialmente declarado como n\u00e3o cr\u00edtico para n\u00f3s, mas de repente tornou-se um ponto \u00fanico de falha.<br \/>\nExatamente durante esse per\u00edodo de migra\u00e7\u00e3o, a conex\u00e3o entre Moscovo e S\u00e3o Petersburgo caiu. Ficamos efetivamente sem DNS por cinco minutos e recuperamos quando <a class=\"wpil_keyword_link\" href=\"https:\/\/prohoster.info\/pt\/\"   title=\"hospedagem\" data-wpil-keyword-link=\"linked\"  data-wpil-monitor-id=\"1206\">hospedagem<\/a> os problemas foram resolvidos.\u00a0<\/p>\n<p><b>Conclus\u00f5es: <\/b><\/p>\n<p>Anteriormente, descuid\u00e1vamos dos fatores externos ao preparar os trabalhos, mas agora tamb\u00e9m os inclu\u00edmos na lista de coisas para as quais nos preparamos. E agora buscamos que todos os componentes sejam reservados em n-2, enquanto durante os trabalhos podemos reduzir esse n\u00edvel para n-1.<\/p>\n<ul>\n<li>Ao elaborar o plano de a\u00e7\u00e3o, anote os pontos onde o servi\u00e7o pode falhar e pense em um cen\u00e1rio onde tudo foi \"para o pior\", com anteced\u00eancia.<\/li>\n<li>Distribua os servidores DNS internos por diferentes geolocaliza\u00e7\u00f5es\/datacenters\/arm\u00e1rios\/ switches\/entradas.<\/li>\n<li>Em cada servidor, instale um servidor DNS cache local que redirecione as solicita\u00e7\u00f5es para os servidores DNS principais e, em caso de indisponibilidade, responda a partir do cache.\u00a0<\/li>\n<\/ul>\n<p><\/p>\n<h4>O quarto lugar \u2014 \"Organizando o Nginx\"<\/h4>\n<p>\nEm um belo dia, nossa equipe decidiu que \"basta de tolerar isso\", e o processo de refatora\u00e7\u00e3o das configura\u00e7\u00f5es do Nginx se iniciou. O principal objetivo \u00e9 trazer as configura\u00e7\u00f5es para uma estrutura intuitiva. Antes, tudo era \"historicamente composto\" e n\u00e3o tinha l\u00f3gica. Agora, cada server_name foi levado para um arquivo hom\u00f4nimo e todas as configura\u00e7\u00f5es foram distribu\u00eddas por pastas. A prop\u00f3sito \u2014 a configura\u00e7\u00e3o cont\u00e9m 253949 linhas ou 7836520 caracteres e ocupa quase 7 megabytes. O n\u00edvel superior da estrutura:\u00a0<\/p>\n<p>                        <b class=\"spoiler_title\">Estrutura do Nginx<\/b><\/p>\n<pre><code class=\"plaintext\">\u251c\u2500\u2500 acesso\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>Melhorou significativamente, mas durante o processo de renomea\u00e7\u00e3o e redistribui\u00e7\u00e3o das configura\u00e7\u00f5es, algumas delas estavam com a extens\u00e3o errada e n\u00e3o foram inclu\u00eddas na diretiva include *.conf. Como resultado, alguns hosts ficaram indispon\u00edveis e retornavam 301 para a p\u00e1gina principal. Como o c\u00f3digo de resposta n\u00e3o era 5xx\/4xx, isso n\u00e3o foi percebido imediatamente, apenas pela manh\u00e3. Depois disso, come\u00e7amos a escrever testes para verificar os componentes da infraestrutura.<\/p>\n<p><b>Conclus\u00f5es:<\/b>\u00a0<\/p>\n<ul>\n<li>Estruture corretamente as configura\u00e7\u00f5es (n\u00e3o apenas do nginx) e pense na estrutura desde o in\u00edcio do projeto. Assim, voc\u00ea as tornar\u00e1 mais compreens\u00edveis para a equipe, o que, por sua vez, reduzir\u00e1 o TTM.<\/li>\n<li>Para alguns componentes da infraestrutura, escreva testes. Por exemplo: verifique se todos os principais server_name retornam o status correto, al\u00e9m do corpo da resposta. Apenas alguns scripts que verifiquem as fun\u00e7\u00f5es principais do componente ser\u00e3o suficientes, para que voc\u00ea n\u00e3o precise se lembrar freneticamente \u00e0s 3 da manh\u00e3 do que mais precisa ser verificado.\u00a0<\/li>\n<\/ul>\n<p><\/p>\n<h4>Terceiro lugar - \"Espa\u00e7o inesperadamente acabou no Cassandra\"<\/h4>\n<p>\nOs dados cresceram de forma consistente, e tudo estava bem at\u00e9 o momento em que os reparos de grandes keyspaces come\u00e7aram a falhar no cluster Cassandra, pois a compacta\u00e7\u00e3o n\u00e3o p\u00f4de ser processada.\u00a0<\/p>\n<p>Em um dia nublado, o cluster quase virou uma ab\u00f3bora, ou seja:<\/p>\n<ul>\n<li>restavam cerca de 20% de espa\u00e7o total no cluster;<\/li>\n<li>n\u00e3o \u00e9 poss\u00edvel adicionar n\u00f3s plenamente, pois n\u00e3o passa pelo cleanup ap\u00f3s a adi\u00e7\u00e3o de um n\u00f3 devido \u00e0 falta de espa\u00e7o nas parti\u00e7\u00f5es;<\/li>\n<li>a performance cai gradativamente, j\u00e1 que a compacta\u00e7\u00e3o n\u00e3o est\u00e1 funcionando;\u00a0<\/li>\n<li>o cluster opera em modo de emerg\u00eancia.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"Os principais erros da Cian\" src=\"\/wp-content\/uploads\/2020\/05\/1d036fbc500a49a285fa4b0014e2a70d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nA sa\u00edda - adicionamos mais 5 n\u00f3s sem limpeza, ap\u00f3s o que come\u00e7amos a remover sistematicamente do cluster e a reinseri-los, como n\u00f3s vazios, onde o espa\u00e7o acabou. O tempo gasto foi muito maior do que gostar\u00edamos. Havia risco de indisponibilidade parcial ou total do cluster.\u00a0<\/p>\n<p><b>Conclus\u00f5es:<\/b><\/p>\n<ul>\n<li>Em todos os servidores Cassandra, n\u00e3o deve haver mais de 60% de espa\u00e7o ocupado em cada parti\u00e7\u00e3o.\u00a0<\/li>\n<li>Eles devem estar carregados em no m\u00e1ximo 50% de CPU.<\/li>\n<li>N\u00e3o devemos negligenciar o planejamento de capacidade e ele deve ser pensado para cada componente, com base em suas especificidades.<\/li>\n<li>Quanto mais n\u00f3s no cluster, melhor. Servidores com um pequeno volume de dados s\u00e3o mais r\u00e1pidos para reiniciar, e esse tipo de cluster \u00e9 mais f\u00e1cil de reanimar.\u00a0<\/li>\n<\/ul>\n<p><\/p>\n<h4>Segundo lugar - \"Dados sumiram do armazenamento de chave-valor do Consul\"<\/h4>\n<p>\nPara descoberta de servi\u00e7os, n\u00f3s, como muitos, usamos o Consul. Mas o nosso key-value \u00e9 utilizado tamb\u00e9m para a implanta\u00e7\u00e3o blue-green do mon\u00f3lito. Nele est\u00e1 armazenada a informa\u00e7\u00e3o sobre os upstreams ativos e inativos, que mudam de lugar durante o deploy. Para isso, um servi\u00e7o de deploy foi escrito, que interagia com KV. Em algum momento, os dados do KV sumiram. Recuperamos da mem\u00f3ria, mas com alguns erros. Como consequ\u00eancia, durante a implanta\u00e7\u00e3o a carga nos upstreams foi distribu\u00edda de forma desigual, e recebemos muitos erros 502 devido \u00e0 sobrecarga dos backends por CPU. No final, migramos do Consul KV para o Postgres, de onde \u00e9 mais dif\u00edcil remover os dados.\u00a0\u00a0<\/p>\n<p><b>Conclus\u00f5es:<br \/>\n<\/b><\/p>\n<ul>\n<li>Servi\u00e7os sem qualquer autoriza\u00e7\u00e3o n\u00e3o devem conter dados cr\u00edticos para o funcionamento do site. Por exemplo, se voc\u00ea n\u00e3o tem autoriza\u00e7\u00e3o no ES, \u00e9 melhor proibir o acesso a partir da rede em qualquer lugar onde n\u00e3o seja necess\u00e1rio, deixar apenas os acessos essenciais, e tamb\u00e9m definir action.destructive_requires_name: true.<\/li>\n<li>Trabalhe o mecanismo de backup e recupera\u00e7\u00e3o antecipadamente. Por exemplo, crie um script (como em python) que consiga tanto fazer backup quanto restaurar.<\/li>\n<\/ul>\n<p><\/p>\n<h4>Primeiro lugar - \"Capit\u00e3o \u00d3bvio\"\u00a0<\/h4>\n<p>\nEm algum momento, notamos uma distribui\u00e7\u00e3o desigual da carga nos upstreams do nginx quando havia 10 ou mais servidores no backend. Como o round-robin direcionava as solicita\u00e7\u00f5es do primeiro ao \u00faltimo upstream em ordem, e cada recarga do nginx come\u00e7ava do zero, os primeiros upstreams sempre recebiam mais solicita\u00e7\u00f5es do que os demais. Como resultado, eles funcionavam mais devagar, afetando todo o site. Isso se tornava cada vez mais evidente \u00e0 medida que o tr\u00e1fego aumentava. Simplesmente atualizar o nginx para incluir random n\u00e3o resolveu \u2014 era necess\u00e1rio refazer uma s\u00e9rie de c\u00f3digos em lua que n\u00e3o funcionavam na vers\u00e3o 1.15 (naquele momento). Tivemos que patchar nosso nginx 1.14.2, implementando suporte para random. Isso resolveu o problema. Esse bug merece o pr\u00eamio de 'capit\u00e3o da obviedade'.<\/p>\n<p><b>Conclus\u00f5es:<\/b><\/p>\n<p>Foi muito interessante e envolvente investigar esse bug).\u00a0<\/p>\n<ul>\n<li>Configure o monitoramento de forma que ele ajude a identificar rapidamente flutua\u00e7\u00f5es semelhantes. Por exemplo, voc\u00ea pode usar o ELK para observar a rps de cada backend de cada upstream, monitorando seus tempos de resposta do ponto de vista do nginx. Nesse caso, isso nos ajudou a identificar o problema.\u00a0<\/li>\n<\/ul>\n<p>\nA maior parte das falhas poderia ter sido evitada com uma abordagem mais meticulosa em rela\u00e7\u00e3o ao que se est\u00e1 fazendo. Sempre deve-se lembrar da lei de Murphy:\u00a0<i>Anything that can go wrong will go wrong, <\/i>e construir componentes com base nisso.\u00a0<br \/>\n<br \/>Fonte: <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.3 - 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\/pt\/blog\/administrirovanie\/top-fakapov-czian\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"pt_PT\" \/>\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\/pt\/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 falhas da Cian | ProHoster","description":"Ol\u00e1 a todos! Meu nome \u00e9 Nikita, sou l\u00edder da equipe de engenheiros da Cian.","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/top-fakapov-czian","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pt_PT","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\/pt\/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\/pt\/wp-json\/wp\/v2\/posts\/80031","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/comments?post=80031"}],"version-history":[{"count":2,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/80031\/revisions"}],"predecessor-version":[{"id":158728,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/80031\/revisions\/158728"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media\/80032"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=80031"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=80031"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=80031"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}