{"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\/de\/blog\/administrirovanie\/top-fakapov-czian","title":{"rendered":"Die gr\u00f6\u00dften Fehler von Cian","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Die gr\u00f6\u00dften Fehler von Cian\" src=\"\/wp-content\/uploads\/2020\/05\/61cf8d25f1f3e858a3b9541cb026cf3c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAllen gute W\u00fcnsche!\u00a0<\/p>\n<p>Mein Name ist Nikita, ich bin Teamleiter der Ingenieurmannschaft von Cian. Eine meiner Aufgaben im Unternehmen ist es, die Anzahl der incidents im Zusammenhang mit der Infrastruktur im Produktionsumfeld auf null zu reduzieren.<br \/>\nWas als N\u00e4chstes zur Sprache kommt, hat uns viel Schmerz bereitet, und das Ziel dieses Artikels ist es, anderen zu helfen, unsere Fehler nicht zu wiederholen oder zumindest ihren Einfluss zu minimieren.\u00a0<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>Pr\u00e4ambel<\/h3>\n<p>\nVor langer Zeit, als Cian aus Monolithen bestand und es noch keine Anzeichen von Mikrodiensten gab, haben wir die Verf\u00fcgbarkeit des Dienstes gemessen, indem wir 3\u20135 Seiten \u00fcberpr\u00fcften.\u00a0<\/p>\n<p>Wenn sie antworteten \u2013 war alles in Ordnung, antworteten sie \u00fcber einen l\u00e4ngeren Zeitraum nicht \u2013 dann gab es einen Alert. Wie lange sie nicht funktionieren mussten, um als Incident betrachtet zu werden, wurde in Meetings entschieden. Das Ingenieurteam war immer an der Untersuchung des Incidents beteiligt. Nach Abschluss der Untersuchung wurde ein Postmortem geschrieben \u2013 eine Art Bericht per E-Mail im Format: was passiert ist, wie lange es gedauert hat, was wir in dem Moment gemacht haben, was wir in Zukunft tun werden.\u00a0<\/p>\n<h3>Die Hauptseiten der Website oder wie wir erkennen, dass wir den Tiefpunkt erreicht haben<\/h3>\n<p>\u00a0<br \/>\nUm die Priorit\u00e4t eines Fehlers zu verstehen, haben wir die kritischsten Seiten der Website f\u00fcr die Gesch\u00e4ftsanforderungen identifiziert. Anhand dieser messen wir die Anzahl der erfolgreichen und nicht erfolgreichen Anfragen sowie Timeouts. So messen wir die Uptime.\u00a0<\/p>\n<p>Angenommen, wir haben festgestellt, dass es eine Reihe von superwichtigen Bereichen der Website gibt, die die Hauptdienste \u2014 die Suche und die Einreichung von Anzeigen \u2014 betreffen. Wenn die Anzahl der Anfragen, die mit einem Fehler enden, \u00fcber 1 % steigt, ist das ein kritischer Incident. Wenn w\u00e4hrend der Hauptzeit in 15 Minuten der Fehleranteil \u00fcber 0,1 % steigt, wird das ebenfalls als kritischer Incident angesehen. Diese Kriterien decken den Gro\u00dfteil der Incidents ab, die \u00fcbrigen fallen au\u00dferhalb dieses Artikels.<\/p>\n<p><img decoding=\"async\" alt=\"Die gr\u00f6\u00dften Fehler von Cian\" src=\"\/wp-content\/uploads\/2020\/05\/f5d76b1784c9a52ae1dc4728f1509ccc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Die Top der besten Incidents von Cian<\/h3>\n<p>\nAlso, wir haben definitiv gelernt zu erkennen, dass ein Incident passiert ist.\u00a0<\/p>\n<p>Jetzt ist jeder Incident bei uns detailliert beschrieben und in einem Epic in Jira festgehalten. \u00dcbrigens: Daf\u00fcr haben wir ein eigenes Projekt eingerichtet, das wir FAIL genannt haben \u2014 in dem k\u00f6nnen nur Epics erstellt werden.\u00a0<\/p>\n<p>Wenn man alle Fehlschl\u00e4ge der letzten Jahre zusammenfasst, f\u00fchren an die Spitze:\u00a0<\/p>\n<ul>\n<li>Incidents, die mit mssql verbunden sind;<\/li>\n<li>Incidents, die durch externe Faktoren verursacht werden;<\/li>\n<li>Fehler des Administrators.<\/li>\n<\/ul>\n<p>\nLassen Sie uns detaillierter auf die Fehler der Administratoren und einige andere interessante Fehlschl\u00e4ge eingehen.<\/p>\n<h4>Platz f\u00fcnf \u2014 \u201eOrdnung im DNS schaffen\u201c<\/h4>\n<p>\nEs war ein ungem\u00fctlicher Dienstag. Wir beschlossen, Ordnung in den DNS-Cluster zu bringen.\u00a0<\/p>\n<p>Wir wollten die internen DNS-Server von BIND auf PowerDNS umstellen, indem wir daf\u00fcr komplett separate Server bereitstellten, auf denen au\u00dfer DNS nichts l\u00e4uft.\u00a0<\/p>\n<p>Wir haben in jedem unserer Rechenzentren einen DNS-Server platziert, und der Moment f\u00fcr den Umzug der Zonen von BIND zu PowerDNS sowie die Umschaltung der Infrastruktur auf die neuen Server kam.\u00a0<\/p>\n<p>Inmitten des Umzugs blieb nur einer der DNS-Server \u00fcbrig, <a class=\"wpil_keyword_link\" href=\"https:\/\/prohoster.info\/de\/server\/\"   title=\"Server\" data-wpil-keyword-link=\"linked\"  data-wpil-monitor-id=\"1484\">Server<\/a>, der in den lokalen zwischengespeicherten BINDs auf allen Servern angegeben war und sich im Rechenzentrum in Sankt Petersburg befand. Dieses Rechenzentrum war urspr\u00fcnglich als nicht kritisch f\u00fcr uns deklariert worden, wurde aber pl\u00f6tzlich zum Single Point of Failure.<br \/>\nGenau in dieser Phase des Umzugs fiel die Verbindung zwischen Moskau und Sankt Petersburg aus. Wir standen faktisch f\u00fcr f\u00fcnf Minuten ohne DNS da und liefen wieder hoch, als <a class=\"wpil_keyword_link\" href=\"https:\/\/prohoster.info\/de\/\"   title=\"Hoster\" data-wpil-keyword-link=\"linked\"  data-wpil-monitor-id=\"1206\">Hoster<\/a> die St\u00f6rungen behoben waren.\u00a0<\/p>\n<p><b>Fazit: <\/b><\/p>\n<p>Fr\u00fcher haben wir externe Faktoren w\u00e4hrend der Vorbereitung auf die Arbeiten vernachl\u00e4ssigt, aber jetzt haben wir sie ebenfalls in die Liste aufgenommen, auf die wir uns vorbereiten. Und jetzt streben wir danach, dass alle Komponenten n-2 reserviert sind, w\u00e4hrend wir in der Arbeitsphase dieses Niveau auf n-1 absenken k\u00f6nnen.<\/p>\n<ul>\n<li>W\u00e4hrend der Erstellung des Aktionsplans sollten Sie Punkte markieren, an denen der Service ausfallen kann, und ein Szenario durchdenken, in dem alles \"schlimmer geht's nicht\".<\/li>\n<li>Verteilen Sie die internen DNS-Server auf verschiedene Geolokationen\/Rechenzentren\/Racks\/Switches\/Eing\u00e4nge.<\/li>\n<li>Installieren Sie auf jedem Server einen lokalen zwischenspeichernden DNS-Server, der Anfragen an die Haupt-DNS-Server weiterleitet und im Falle seiner Nichterreichbarkeit aus dem Cache antwortet.\u00a0<\/li>\n<\/ul>\n<p><\/p>\n<h4>Der vierte Punkt \u2014 \"Ordnung in Nginx schaffen\"<\/h4>\n<p>\nEines sch\u00f6nen Tages beschloss unser Team, dass \"es reicht, das zu ertragen\", und der Prozess der Refaktorisierung der Nginx-Konfigurationen begann. Das Hauptziel war es, die Konfigurationen in eine intuitiv verst\u00e4ndliche Struktur zu bringen. Fr\u00fcher war alles \"historisch gewachsen\" und trug keine Logik in sich. Jetzt haben wir jeden server_name in eine gleichnamige Datei ausgelagert und alle Konfigurationen in Ordner verteilt. \u00dcbrigens \u2014 die Konfiguration enth\u00e4lt 253949 Zeilen oder 7836520 Zeichen und ist fast 7 Megabyte gro\u00df. Die oberste Ebene der Struktur:\u00a0<\/p>\n<p>                        <b class=\"spoiler_title\">Nginx-Struktur<\/b><\/p>\n<pre><code class=\"plaintext\">\u251c\u2500\u2500 Zugriff\n\u2502   \u251c\u2500\u2500 allow.list\n...\n\u2502   \u2514\u2500\u2500 whitelist.conf\n\u251c\u2500\u2500 Geobase\n\u2502   \u251c\u2500\u2500 exclude.conf\n...\n\u2502   \u2514\u2500\u2500 geo_ip_to_region_id.conf\n\u251c\u2500\u2500 Geodb\n\u2502   \u251c\u2500\u2500 GeoIP.dat\n\u2502   \u251c\u2500\u2500 GeoIP2-Country.mmdb\n\u2502   \u2514\u2500\u2500 GeoLiteCity.dat\n\u251c\u2500\u2500 inc\n\u2502   \u251c\u2500\u2500 error.inc\n...\n\u2502   \u2514\u2500\u2500 proxy.inc\n\u251c\u2500\u2500 lists.d\n\u2502   \u251c\u2500\u2500 bot.conf\n...\n\u2502   \u251c\u2500\u2500 dynamisch\n\u2502   \u2514\u2500\u2500 geo.conf\n\u251c\u2500\u2500 lua\n\u2502   \u251c\u2500\u2500 cookie.lua\n\u2502   \u251c\u2500\u2500 log\n\u2502   \u2502   \u2514\u2500\u2500 log.lua\n\u2502   \u251c\u2500\u2500 logics\n\u2502   \u2502   \u251c\u2500\u2500 include.lua\n\u2502   \u2502   \u251c\u2500\u2500 ...\n\u2502   \u2502   \u2514\u2500\u2500 utils.lua\n\u2502   \u2514\u2500\u2500 prom\n\u2502       \u251c\u2500\u2500 stats.lua\n\u2502       \u2514\u2500\u2500 stats_prometheus.lua\n\u251c\u2500\u2500 map.d\n\u2502   \u251c\u2500\u2500 access.conf\n\u2502   \u251c\u2500\u2500 .. \n\u2502   \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   \u251c\u2500\u2500 cian.ru\n\u2502   \u2502   \u251c\u2500\u2500 cian.ru.conf\n\u2502   \u2502   \u251c\u2500\u2500 ...\n\u2502   \u2502   \u2514\u2500\u2500 my.cian.ru.conf\n\u251c\u2500\u2500 service.d\n\u2502   \u251c\u2500\u2500 ...\n\u2502   \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>Es hat sich deutlich verbessert, aber w\u00e4hrend der Umbenennung und Verteilung der Konfigurationen hatten einige davon die falsche Erweiterung und wurden nicht in die Direktive include *.conf aufgenommen. Infolgedessen wurden einige Hosts nicht erreichbar und gaben einen 301-Redirect zur Hauptseite zur\u00fcck. Da der Antwortcode nicht 5xx\/4xx war, fiel dies nicht sofort auf, sondern erst morgens. Danach begannen wir mit dem Schreiben von Tests zur \u00dcberpr\u00fcfung der Infrastrukturkomponenten.<\/p>\n<p><b>Fazit:<\/b>\u00a0<\/p>\n<ul>\n<li>Strukturieren Sie die Konfigurationen (nicht nur nginx) richtig und denken Sie bereits in der fr\u00fchen Projektphase \u00fcber die Struktur nach. So machen Sie sie f\u00fcr das Team verst\u00e4ndlicher, was wiederum die Time-to-Market reduziert.<\/li>\n<li>F\u00fcr einige Infrastrukturkomponenten schreiben Sie Tests. Zum Beispiel: \u00dcberpr\u00fcfen Sie, dass alle wichtigen server_name den richtigen Status zur\u00fcckgeben, + den Antwortk\u00f6rper. Es gen\u00fcgt, einfach einige Skripte bereitzuhalten, die die grundlegenden Funktionen der Komponente \u00fcberpr\u00fcfen, damit Sie nicht um 3 Uhr nachts in Panik versuchen m\u00fcssen, sich zu erinnern, was Sie noch \u00fcberpr\u00fcfen sollten.\u00a0<\/li>\n<\/ul>\n<p><\/p>\n<h4>Dritter Platz \u2014 \"Pl\u00f6tzlich war der Speicher in Cassandra voll\"<\/h4>\n<p>\nDie Daten wuchsen kontinuierlich, und alles war gut, bis im Cassandra-Cluster gro\u00dfe Keyspaces w\u00e4hrend des Repairs ausfielen, weil die Compaction nicht arbeiten konnte.\u00a0<\/p>\n<p>An einem nebligen Tag verwandelte sich der Cluster fast in einen K\u00fcrbis, und zwar:<\/p>\n<ul>\n<li>Es waren nur noch etwa 20 % des Gesamtplatzes im Cluster verf\u00fcgbar;<\/li>\n<li>Knoten k\u00f6nnen nicht hinzugef\u00fcgt werden, da der Cleanup nach der Hinzuf\u00fcgung eines Knotens aufgrund von Platzmangel nicht durchgef\u00fchrt wird;<\/li>\n<li>Die Leistung sinkt allm\u00e4hlich, da die Compaction nicht funktioniert;\u00a0<\/li>\n<li>Der Cluster l\u00e4uft im Notbetrieb.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"Die gr\u00f6\u00dften Fehler von Cian\" src=\"\/wp-content\/uploads\/2020\/05\/1d036fbc500a49a285fa4b0014e2a70d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDer Ausstieg \u2014 wir haben weiteren 5 Knoten ohne Cleanup hinzugef\u00fcgt, danach begannen wir schrittweise, aus dem Cluster auszusteigen und erneut einzuf\u00fchren, als leere Knoten, auf denen kein Platz mehr war. Die aufgebrachte Zeit war viel gr\u00f6\u00dfer als gew\u00fcnscht. Es bestand das Risiko einer partiellen oder vollst\u00e4ndigen Nichterreichbarkeit des Clusters.\u00a0<\/p>\n<p><b>Fazit:<\/b><\/p>\n<ul>\n<li>Auf allen Cassandra-Servern sollte auf jeder Partition nicht mehr als 60 % des Speichers belegt sein.\u00a0<\/li>\n<li>Sie sollten nicht zu mehr als 50 % ausgelastet sein, was die CPU betrifft.<\/li>\n<li>Man sollte das Capacity Planning nicht vernachl\u00e4ssigen, und es sollte f\u00fcr jede Komponente unter Ber\u00fccksichtigung ihrer Besonderheiten durchdacht werden.<\/li>\n<li>Je mehr Knoten im Cluster sind, desto besser. Server mit einem kleinen Datenvolumen k\u00f6nnen schneller neu konfiguriert werden, und ein solcher Cluster ist einfacher wiederherzustellen.\u00a0<\/li>\n<\/ul>\n<p><\/p>\n<h4>Der zweite Punkt \u2014 \u201eDaten aus dem Consul-Key-Value-Speicher sind verschwunden\u201c<\/h4>\n<p>\nF\u00fcr das Service Discovery verwenden wir, wie viele andere, Consul. Aber wir nutzen dessen Key-Value auch f\u00fcr die Blue-Green-Bereitstellung des Monolithen. Dort wird die Information \u00fcber aktive und inaktive Upstream ver\u00e4ndert, w\u00e4hrend des Deployments. Daf\u00fcr wurde ein Bereitstellungsdienst geschrieben, der mit KV interagierte. Irgendwann sind die Daten aus dem KV verschwunden. Wir haben sie aus dem Ged\u00e4chtnis wiederhergestellt, jedoch mit einigen Fehlern. Infolgedessen wurde beim Deployment die Last auf die Upstreams ungleich verteilt, und wir erhielten viele 502-Fehler aufgrund einer \u00dcberlastung der Backends durch die CPU. Letztendlich sind wir von Consul KV auf Postgres umgestiegen, von wo es nicht so einfach ist, sie zu entfernen.\u00a0\u00a0<\/p>\n<p><b>Fazit:<br \/>\n<\/b><\/p>\n<ul>\n<li>Dienste ohne jegliche Authentifizierung sollten keine kritischen Daten f\u00fcr den Betrieb der Website enthalten. Wenn Sie beispielsweise in ES keine Authentifizierung haben, w\u00e4re es besser, den Zugriff auf Netzwerkebene von \u00fcberall dort zu verbieten, wo er nicht ben\u00f6tigt wird, nur die notwendigen zu lassen und action.destructive_requires_name: true zu setzen.<\/li>\n<li>\u00dcben Sie den Mechanismus f\u00fcr Backup und Wiederherstellung im Voraus. Erstellen Sie beispielsweise im Voraus ein Skript (zum Beispiel in Python), das sowohl Backups erstellen als auch wiederherstellen kann.<\/li>\n<\/ul>\n<p><\/p>\n<h4>Der erste Punkt \u2014 \u201eKapitan Offensichtlichkeit\u201c\u00a0<\/h4>\n<p>\nIrgendwann haben wir eine ungleichm\u00e4\u00dfige Lastverteilung auf die Upstreams von Nginx bemerkt, wenn im Backend mehr als 10 Server waren. Da das Round-Robin-Schema die Anfragen der Reihe nach dem ersten bis zum letzten Upstream zuwies und jedes Nginx-Reload wieder von vorne begann, hatten die ersten Upstreams immer mehr Anfragen als die anderen. Dies f\u00fchrte dazu, dass sie langsamer arbeiteten und die gesamte Website litt. Mit steigendem Traffic wurde das immer deutlicher. Ein einfaches Update von Nginx zur Aktivierung von Random-Kumulierung brachte nicht den gew\u00fcnschten Erfolg \u2014 wir mussten eine Menge Lua-Code neu schreiben, der in Version 1.15 nicht funktionierte. Daher mussten wir unser Nginx 1.14.2 patchen und die Unterst\u00fctzung f\u00fcr Random-Kumulierung einbauen. Dadurch wurde das Problem behoben. Dieser Bug gewinnt in der Kategorie \u201eKapitan Offensichtlichkeit\u201c.<\/p>\n<p><b>Fazit:<\/b><\/p>\n<p>Es war sehr interessant und fesselnd, diesen Bug zu untersuchen.\u00a0<\/p>\n<ul>\n<li>Richten Sie das Monitoring so ein, dass es Ihnen hilft, \u00e4hnliche Fluktuationen schnell zu finden. Zum Beispiel k\u00f6nnten Sie ELK verwenden, um die RPS f\u00fcr jedes Backend jedes Upstreams zu \u00fcberwachen und deren Antwortzeiten aus der Sicht von Nginx zu verfolgen. In diesem Fall hat uns das geholfen, das Problem zu identifizieren.\u00a0<\/li>\n<\/ul>\n<p>\nEin Gro\u00dfteil der Fehler h\u00e4tte durch einen sorgf\u00e4ltigeren Ansatz vermieden werden k\u00f6nnen. Man muss immer das Murphy-Gesetz im Hinterkopf behalten:\u00a0<i>Anything that can go wrong will go wrong, <\/i>und Komponenten entsprechend gestalten.\u00a0<br \/>\n<br \/>Quelle: <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.1.1 - 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\/de\/blog\/administrirovanie\/top-fakapov-czian\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"de_DE\" \/>\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\/de\/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\udd47Die gr\u00f6\u00dften Fehler von Cian | ProHoster","description":"Allen alles Gute! Mein Name ist Nikita, ich bin Teamleiter der Ingenieure von Cian.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/top-fakapov-czian","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","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\/de\/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\/de\/wp-json\/wp\/v2\/posts\/80031","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=80031"}],"version-history":[{"count":2,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/80031\/revisions"}],"predecessor-version":[{"id":158728,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/80031\/revisions\/158728"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/80032"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=80031"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=80031"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=80031"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}