{"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\/nl\/blog\/administrirovanie\/top-fakapov-czian","title":{"rendered":"Top blunders van TSIAN","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Top blunders van TSIAN\" src=\"\/wp-content\/uploads\/2020\/05\/61cf8d25f1f3e858a3b9541cb026cf3c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIedereen een goede dag!\u00a0<\/p>\n<p>Mijn naam is Nikita, ik ben teamleider van het engineeringteam van Cian. Een van mijn verantwoordelijkheden binnen het bedrijf is om het aantal incidenten gerelateerd aan de infrastructuur in productie tot nul te reduceren.<br \/>\nHet onderwerp waar we het hier verder over gaan hebben, heeft ons veel problemen bezorgd, en het doel van dit artikel is om andere mensen te helpen onze fouten niet te herhalen of op zijn minst de impact ervan te minimaliseren.\u00a0<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>Inleiding<\/h3>\n<p>\nLang geleden, toen Cian uit monolithen bestond en er nog geen aanwijzingen voor microservices waren, maten we de beschikbaarheid van de dienst door 3\u20135 pagina's te controleren.\u00a0<\/p>\n<p>Als ze reageerden, was alles goed, als ze lange tijd niet reageerden, was het een alert. Hoeveel tijd ze niet moeten werken om als een incident te worden beschouwd, werd bepaald door mensen in vergaderingen. Het engineeringteam was altijd betrokken bij het onderzoek van het incident. Wanneer het onderzoek was afgerond, werd er een postmortem geschreven - een soort rapport in de vorm van: wat er was gebeurd, hoe lang het had geduurd, wat we op dat moment deden, en wat we in de toekomst gaan doen.\u00a0<\/p>\n<h3>Belangrijke pagina's van de website of hoe we begrijpen dat we de bodem hebben bereikt.<\/h3>\n<p>\u00a0<br \/>\nOm de prioriteit van een fout te begrijpen, hebben we de meest kritische pagina's voor de bedrijfsfunctionaliteit van de website ge\u00efdentificeerd. We tellen het aantal succesvolle\/falende aanvragen en time-outs voor deze pagina's. Op deze manier meten we de uptime.\u00a0<\/p>\n<p>Stel, we hebben ontdekt dat er een aantal superbelangrijke secties van de website zijn die verantwoordelijk zijn voor de hoofddienst - het zoeken en plaatsen van advertenties. Als het aantal aanvragen dat eindigt in een fout meer dan 1% is, dan is dat een kritiek incident. Als in de piekuren het percentage fouten gedurende 15 minuten meer dan 0,1% is, wordt dat ook als een kritiek incident beschouwd. Deze criteria dekken het grootste deel van de incidenten, de rest valt buiten de reikwijdte van dit artikel.<\/p>\n<p><img decoding=\"async\" alt=\"Top blunders van TSIAN\" src=\"\/wp-content\/uploads\/2020\/05\/f5d76b1784c9a52ae1dc4728f1509ccc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Top beste incidenten van Cian<\/h3>\n<p>\nDus we hebben zeker geleerd om vast te stellen dat er een incident heeft plaatsgevonden.\u00a0<\/p>\n<p>Nu is elk incident bij ons gedetailleerd beschreven en vastgelegd in een Jira-epic. Overigens hebben we hiervoor een apart project opgericht en het FAIL genoemd - hierin kunnen alleen epics worden aangemaakt.\u00a0<\/p>\n<p>Als we al de mislukkingen van de afgelopen jaren samenvoegen, zijn de meeste:\u00a0<\/p>\n<ul>\n<li>incidenten gerelateerd aan mssql;<\/li>\n<li>incidenten veroorzaakt door externe factoren;<\/li>\n<li>adminfouten.<\/li>\n<\/ul>\n<p>\nLaten we iets dieper ingaan op de fouten van admins en enkele andere interessante mislukkingen.<\/p>\n<h4>Vijfde plaats - 'Ordenen van DNS'<\/h4>\n<p>\nHet was een sombere dinsdag. We besloten om orde te scheppen in het DNS-cluster.\u00a0<\/p>\n<p>We wilden de interne dns-servers van bind naar powerdns migreren, door daar volledig aparte servers voor in te richten, waar alleen dns draait.\u00a0<\/p>\n<p>We hebben \u00e9\u00e9n dns-server in elke locatie van onze datacenters geplaatst, en het moment van de verhuizing van de zones van bind naar powerdns en het omschakelen van de infrastructuur naar de nieuwe servers brak aan.\u00a0<\/p>\n<p>Tijdens de verhuizing was er \u00e9\u00e9n <a class=\"wpil_keyword_link\" href=\"https:\/\/prohoster.info\/nl\/server\/\"   title=\"servers\" data-wpil-keyword-link=\"linked\"  data-wpil-monitor-id=\"1484\">servers<\/a>, die was opgegeven in de lokale caching bind-servers op alle servers, nog overgebleven, en dat was in het datacenter in Sint-Petersburg. Dit datacenter was oorspronkelijk als niet-kritisch voor ons gedeclareerd, maar werd plotseling een single point of failure.<br \/>\nJuist in deze verhuisperiode viel de verbinding tussen Moskou en Sint-Petersburg uit. We waren feitelijk vijf minuten zonder DNS en kwamen weer online toen <a class=\"wpil_keyword_link\" href=\"https:\/\/prohoster.info\/nl\/\"   title=\"hoster\" data-wpil-keyword-link=\"linked\"  data-wpil-monitor-id=\"1206\">hoster<\/a> de problemen waren opgelost.\u00a0<\/p>\n<p><b>Conclusies: <\/b><\/p>\n<p>Vroeger negeerden we externe factoren tijdens de voorbereidingen voor het werk, maar nu hebben we deze ook op de lijst gezet van waarvan we ons voorbereiden. En we streven er nu naar om alle componenten te reserveren n-2, en tijdens het werk kunnen we dit niveau verlagen tot n-1.<\/p>\n<ul>\n<li>Bij het opstellen van het actieplan markeert u de punten waar de service kan uitvallen en bedenkt u een scenario waarin alles 'slechter kan worden dan dit', van tevoren.<\/li>\n<li>Verdeel interne dns-servers over verschillende geografische locaties\/datacenters\/stacks\/schakelaars\/invoeren.<\/li>\n<li>Installeer op elke server een lokale cache dns-server die verzoeken doorstuurt naar de primaire dns-servers, en in het geval van onbeschikbaarheid vanuit de cache zal antwoorden.\u00a0<\/li>\n<\/ul>\n<p><\/p>\n<h4>De vierde plaats - 'Orde scheppen in Nginx'<\/h4>\n<p>\nOp een mooie dag besloot ons team dat 'het genoeg was geweest', en het proces van refactoren van de nginx-configs begon. Het hoofddoel was om de configs naar een intu\u00eftieve structuur te brengen. Voorheen was alles 'historisch gegroeid' en droeg het geen logica in zich. Nu hebben we elke server_name in een bestand met dezelfde naam geplaatst en alle configs over mappen verdeeld. Ter info: de config bevat 253949 regels of 7836520 tekens en is bijna 7 megabyte groot. De bovenste niveaustructuur:\u00a0<\/p>\n<p>                        <b class=\"spoiler_title\">Nginx-structuur<\/b><\/p>\n<pre><code class=\"plaintext\">\u251c\u2500\u2500 toegang\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 dynamisch\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 logica\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>Het is aanzienlijk verbeterd, maar tijdens het hernoemen en toewijzen van configuraties hadden sommige een verkeerd bestandsextensie en kwamen ze niet in de include-directive *.conf. Als gevolg hiervan werden sommige hosts onbereikbaar en gaven ze een 301-redirect naar de homepage. Omdat de antwoordcode geen 5xx\/4xx was, werd dit niet meteen opgemerkt, maar pas in de vroege ochtend. Daarna zijn we begonnen met het schrijven van tests voor de infrastructuurcomponenten.<\/p>\n<p><b>Conclusies:<\/b>\u00a0<\/p>\n<ul>\n<li>Structureer configuraties goed (niet alleen nginx) en denk na over de structuur in het vroege stadium van het project. Dit maakt ze begrijpelijker voor het team, wat op zijn beurt de Time to Market (TTM) vermindert.<\/li>\n<li>Voor sommige infrastructuurcomponenten schrijf tests. Bijvoorbeeld: controleer dat alle belangrijke server_name de juiste status teruggeven, plus de body van het antwoord. Het is voldoende om gewoon een paar scripts bij de hand te hebben die de belangrijkste functies van de component controleren, zodat je niet in paniek hoeft te denken in het midden van de nacht wat er nog meer moet worden gecontroleerd.\u00a0<\/li>\n<\/ul>\n<p><\/p>\n<h4>Derde plaats \u2014 \u2018Plotseling was er geen ruimte meer in Cassandra\u2019<\/h4>\n<p>\nDe gegevens groeide geleidelijk, en alles was in orde totdat de repair van grote keyspaces in het Cassandra-cluster begon te falen, omdat compaction niet kon worden uitgevoerd.\u00a0<\/p>\n<p>Op een slechte dag veranderde het cluster bijna in een pompoen, en wel:<\/p>\n<ul>\n<li>er was ongeveer 20% ruimte over in het cluster;<\/li>\n<li>je kunt geen nodes volledig toevoegen, omdat cleanup niet kan worden uitgevoerd na het toevoegen van een node door een gebrek aan ruimte op de volumes;<\/li>\n<li>de prestaties dalen geleidelijk, omdat compaction niet werkt;\u00a0<\/li>\n<li>het cluster werkt in een noodmodus.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"Top blunders van TSIAN\" src=\"\/wp-content\/uploads\/2020\/05\/1d036fbc500a49a285fa4b0014e2a70d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDe uitkomst is dat we nog 5 nodes hebben toegevoegd zonder cleanup, waarna we geleidelijk zijn begonnen met het verwijderen uit het cluster en opnieuw introduceren als lege nodes waarvoor geen plaats meer was. De tijd die eraan besteed is, is veel meer dan gewenst. Er was een risico op gedeeltelijke of volledige onbeschikbaarheid van het cluster.\u00a0<\/p>\n<p><b>Conclusies:<\/b><\/p>\n<ul>\n<li>Op alle servers van Cassandra mag niet meer dan 60% van de ruimte op elke partij in gebruik zijn.\u00a0<\/li>\n<li>Ze moeten niet meer dan 50% belast zijn qua CPU.<\/li>\n<li>Negeer capacity planning niet: het moet voor elk component worden overwogen, gebaseerd op zijn specificiteit.<\/li>\n<li>Hoe meer nodes in het cluster, hoe beter. Servers met een kleine hoeveelheid gegevens kunnen sneller opnieuw worden geladen, en zo'n cluster is gemakkelijker te herstellen.\u00a0<\/li>\n<\/ul>\n<p><\/p>\n<h4>Tweede plaats - \"Gegevens verdwenen uit consul key-value storage\"<\/h4>\n<p>\nVoor service discovery gebruiken wij, net als veel anderen, consul. Maar we gebruiken de key-value ook voor blue-green deployment van de monoliet. Daarin wordt informatie opgeslagen over actieve en inactieve upstreams, die van plaats wisselen tijdens de deploy. Hiervoor is een deploymentservice geschreven die met KV werkte. Op een gegeven moment verdwenen de gegevens uit KV. We hebben het uit het hoofd hersteld, maar met verschillende fouten. Als gevolg daarvan werd de belasting op de upstreams ongelijk verdeeld tijdens de uitrol, en kregen we veel 502-fouten door overbelasting van de backend qua CPU. Uiteindelijk zijn we overgestapt van consul KV naar Postgres, van waaruit het al moeilijker is om gegevens te verwijderen.\u00a0\u00a0<\/p>\n<p><b>Conclusies:<br \/>\n<\/b><\/p>\n<ul>\n<li>Diensten zonder enige autorisatie mogen geen kritische gegevens voor de werking van de website bevatten. Als u bijvoorbeeld geen autorisatie in ES heeft, is het beter om de toegang op netwerkniveau te verbieden waar deze niet nodig is, alleen de noodzakelijke toegang te behouden en ook action.destructive_requires_name: true in te stellen.<\/li>\n<li>Werk het mechanisme voor back-ups en herstel van tevoren uit. Maak bijvoorbeeld van tevoren een script (bijvoorbeeld in Python) dat zowel back-ups kan maken als herstellen.<\/li>\n<\/ul>\n<p><\/p>\n<h4>Eerste plaats - \"Kapitein Onopvallendheid\"\u00a0<\/h4>\n<p>\nOp een gegeven moment merkten we een ongelijkmatige belasting op de upstreams van nginx wanneer er meer dan 10 servers in de backend waren. Omdat de round-robin verzoeken volgde van de eerste tot de laatste upstream in volgorde, en elke reload van nginx opnieuw begon, kregen de eerste upstreams altijd meer verzoeken dan de anderen. Als gevolg hiervan werkten ze langzamer en had de hele site eronder te lijden. Dit werd steeds duidelijker naarmate het verkeer toenam. Gewoon nginx bijwerken om random in te schakelen werkte niet \u2014 we moesten een heleboel lua-code opnieuw schrijven, die niet werkte in versie 1.15 (op dat moment). Daarom hebben we onze nginx 1.14.2 gepatcht om ondersteuning voor random toe te voegen. Dit loste het probleem op. Deze bug wint in de nominatie 'kapitein voor de onduidelijkheid'.<\/p>\n<p><b>Conclusies:<\/b><\/p>\n<p>Het was erg interessant en boeiend om deze bug te onderzoeken).\u00a0<\/p>\n<ul>\n<li>Zorg ervoor dat je monitoring zo is ingericht dat het helpt om dergelijke fluctuaties snel te vinden. Je kunt bijvoorbeeld ELK gebruiken om rps voor elke backend van elke upstream te observeren en hun responsetijden vanuit het perspectief van nginx te volgen. Dit hielp ons om het probleem te identificeren.\u00a0<\/li>\n<\/ul>\n<p>\nDoor een zorgvuldiger aanpak van wat je doet, had de meerderheid van de fouten kunnen worden voorkomen. Je moet altijd de wet van Murphy in gedachten houden:\u00a0<i>Alles wat mis kan gaan, zal ook misgaan. <\/i>En bouw componenten met deze gedachten in het achterhoofd.\u00a0<br \/>\n<br \/>Bron: <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\/nl\/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=\"nl_NL\" \/>\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\/nl\/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 blunders van Cian | ProHoster","description":"Iedereen goeds! Mijn naam is Nikita, ik ben teamleider van het ingenieursteam van Cian.","canonical_url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/top-fakapov-czian","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nl_NL","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\/nl\/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\/nl\/wp-json\/wp\/v2\/posts\/80031","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=80031"}],"version-history":[{"count":2,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/80031\/revisions"}],"predecessor-version":[{"id":158728,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/80031\/revisions\/158728"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media\/80032"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=80031"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=80031"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=80031"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}