{"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\/da\/blog\/administrirovanie\/top-fakapov-czian","title":{"rendered":"Top fejl fra Cian","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Top fejl fra Cian\" src=\"\/wp-content\/uploads\/2020\/05\/61cf8d25f1f3e858a3b9541cb026cf3c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nGoddag alle!\u00a0<\/p>\n<p>Mit navn er Nikita, jeg er teamleder for ingeni\u00f8rteamet hos Cian. En af mine opgaver i virksomheden er at reducere antallet af h\u00e6ndelser relateret til infrastrukturen i produktionen til nul.<br \/>\nDet, vi vil tale om nedenfor, har for\u00e5rsaget os meget smerte, og form\u00e5let med denne artikel er at forhindre andre i at gentage vores fejl eller i hvert fald minimere deres indflydelse.\u00a0<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>Pr\u00e6ambel<\/h3>\n<p>\nFor l\u00e6nge siden, da Cian bestod af monolitter, og der slet ikke var nogen tegn p\u00e5 mikrotjenester, m\u00e5lte vi tilg\u00e6ngeligheden af ressourcen ved at tjekke 3\u20135 sider.\u00a0<\/p>\n<p>Hvis de svarede \u2014 alt var godt, hvis de ikke svarede i lang tid \u2014 alert. Hvor lang tid de skulle v\u00e6re nede for at blive betragtet som en h\u00e6ndelse, blev besluttet af folk p\u00e5 m\u00f8der. Ingeni\u00f8rteamet deltager altid i efterforskningen af h\u00e6ndelsen. N\u00e5r unders\u00f8gelsen er afsluttet, skrives en postmortem \u2014 en slags rapport p\u00e5 e-mail i formatet: hvad der skete, hvor l\u00e6nge det varede, hvad vi gjorde i \u00f8jeblikket, hvad vi vil g\u00f8re i fremtiden.\u00a0<\/p>\n<h3>Hovedsiderne p\u00e5 hjemmesiden eller hvordan vi ved, at vi har ramt bunden<\/h3>\n<p>\u00a0<br \/>\nFor at kunne forst\u00e5 prioriteten af fejlen, har vi fremh\u00e6vet de mest kritiske sider for forretningsfunktionen. Ud fra dem t\u00e6ller vi antallet af succesfulde\/ikke-succesfulde anmodninger og timeouts. P\u00e5 den m\u00e5de m\u00e5ler vi uptime.\u00a0<\/p>\n<p>Lad os sige, at vi har fastsl\u00e5et, at der er en r\u00e6kke supervigtige sektioner af hjemmesiden, der er ansvarlige for den prim\u00e6re service \u2014 s\u00f8gning og indsendelse af annoncer. Hvis antallet af anmodninger, der afsluttes med en fejl, overstiger 1%, er det en kritisk h\u00e6ndelse. Hvis procentdelen af fejl under primetime overstiger 0,1% i l\u00f8bet af 15 minutter, betragtes dette ogs\u00e5 som en kritisk h\u00e6ndelse. Disse kriterier d\u00e6kker st\u00f8rstedelen af h\u00e6ndelserne, \u00f8vrige falder uden for denne artikel.<\/p>\n<p><img decoding=\"async\" alt=\"Top fejl fra Cian\" src=\"\/wp-content\/uploads\/2020\/05\/f5d76b1784c9a52ae1dc4728f1509ccc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Top bedste h\u00e6ndelser fra Cian<\/h3>\n<p>\nS\u00e5 vi har helt sikkert l\u00e6rt at bestemme, hvorn\u00e5r en h\u00e6ndelse er sket.\u00a0<\/p>\n<p>Nu er hver h\u00e6ndelse detaljeret beskrevet og reflekteret i en epik i Jira. For at sige det s\u00e5dan: vi har startet et separat projekt, kaldte det FAIL \u2014 her kan man kun oprette epikker.\u00a0<\/p>\n<p>Hvis vi samler alle fejlene fra de seneste \u00e5r, er de dominerende:\u00a0<\/p>\n<ul>\n<li>h\u00e6ndelser relateret til mssql;<\/li>\n<li>h\u00e6ndelser for\u00e5rsaget af eksterne faktorer;<\/li>\n<li>administratorfejl.<\/li>\n<\/ul>\n<p>\nLad os se n\u00e6rmere p\u00e5 administratorfejl samt nogle andre interessante fiaskoer.<\/p>\n<h4>Femte plads \u2014 \"Vi organiserer DNS\"<\/h4>\n<p>\nDet var en gr\u00e5 tirsdag. Vi besluttede at organisere DNS-klyngen.\u00a0<\/p>\n<p>Vi \u00f8nskede at migrere interne dns-servere fra bind til powerdns, ved at dedikere fuldst\u00e6ndig separate servere, hvor der ikke er andet end dns.\u00a0<\/p>\n<p>Vi placerede en dns-server i hver af vores datacenters lokationer, og nu var tiden kommet til at migrere zoner fra bind til powerdns og skifte infrastrukturen til de nye servere.\u00a0<\/p>\n<p>I den mest hektiske periode af migreringen var der kun \u00e9n tilbage <a class=\"wpil_keyword_link\" href=\"https:\/\/prohoster.info\/da\/server\/\"   title=\"servere\" data-wpil-keyword-link=\"linked\"  data-wpil-monitor-id=\"1484\">servere<\/a>, som var angivet i de lokale cache-bind p\u00e5 alle servere, og den var i datacentret i Sankt Petersborg. Dette datacenter var oprindeligt blevet deklareret som ikke-kritisk for os, men blev pludselig et single point of failure.<br \/>\nLige i denne migrationsperiode gik forbindelsen mellem Moskva og Sankt Petersborg ned. Vi var faktisk uden DNS i fem minutter og kom op igen, da <a class=\"wpil_keyword_link\" href=\"https:\/\/prohoster.info\/da\/\"   title=\"hoster\" data-wpil-keyword-link=\"linked\"  data-wpil-monitor-id=\"1206\">hoster<\/a> fejlen blev rettet.\u00a0<\/p>\n<p><b>Konklusioner: <\/b><\/p>\n<p>Tidligere havde vi overset eksterne faktorer under forberedelserne til arbejdet, men nu medtager vi dem ogs\u00e5 p\u00e5 listen over, hvad vi forbereder os p\u00e5. Og nu str\u00e6ber vi efter, at alle komponenter er reserveret til n-2, og at vi under arbejdet kan s\u00e6nke dette niveau til n-1.<\/p>\n<ul>\n<li>N\u00e5r du laver handlingsplanen, skal du notere punkter, hvor tjenesten kan falde, og t\u00e6nke p\u00e5 scenarier, hvor alt g\u00e5r \"v\u00e6rre end v\u00e6rst\", p\u00e5 forh\u00e5nd.<\/li>\n<li>Fordel interne dns-servere p\u00e5 forskellige geolokationer\/datacentre\/rack\/switches\/indgange.<\/li>\n<li>Installer en lokal cache dns-server p\u00e5 hver server, som omdirigerer foresp\u00f8rgsler til de prim\u00e6re dns-servere, og i tilf\u00e6lde af utilg\u00e6ngelighed vil svare fra cachen.\u00a0<\/li>\n<\/ul>\n<p><\/p>\n<h4>Fjerde plads \u2014 \"Vi organiserer Nginx\"<\/h4>\n<p>\nEn sk\u00f8n dag besluttede vores team, at \"nu er det nok\", og processen med at refaktorere nginx-konfigurationerne blev iv\u00e6rksat. Hovedm\u00e5let er at give konfigurationerne en intuitiv struktur. Tidligere var alt \"historisk opst\u00e5et\" og havde ingen logik i sig. Nu har vi flyttet hver server_name til en tilsvarende fil og kategoriseret alle konfigurationer i mapper. For at sige det mildt \u2014 konfigurationen indeholder 253949 linjer eller 7836520 tegn og fylder n\u00e6sten 7 megabyte. \u00d8verste niveau af strukturen:\u00a0<\/p>\n<p>                        <b class=\"spoiler_title\">Nginx-struktur<\/b><\/p>\n<pre><code class=\"plaintext\">\u251c\u2500\u2500 adgang\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 ..  \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>Det blev markant bedre, men under omd\u00f8bning og fordeling af konfigurationer havde nogle af dem forkerte filendelser og kom ikke ind i direktivet include *.conf. Som f\u00f8lge heraf blev nogle hosts utilg\u00e6ngelige og returnerede 301 til forsiden. Fordi svarkoden ikke var 5xx\/4xx, blev det ikke opdaget med det samme, men f\u00f8rst tidligt om morgenen. Derefter begyndte vi at skrive tests til kontrol af infrastrukturkomponenterne.<\/p>\n<p><b>Konklusioner:<\/b>\u00a0<\/p>\n<ul>\n<li>Strukturer konfigurationerne korrekt (ikke kun nginx) og overvej strukturen tidligt i projektet. Det vil g\u00f8re dem mere forst\u00e5elige for teamet, hvilket i sin tur vil reducere TTM.<\/li>\n<li>Skriv tests for nogle infrastrukturkomponenter. For eksempel: kontrol, at alle n\u00f8gle server_name returnerer den korrekte status, + svarindholdet. Det er tilstr\u00e6kkeligt at have bare et par scripts, der kontrollerer de grundl\u00e6ggende funktioner af komponenten, s\u00e5 man ikke nerv\u00f8st skal huske, hvad man ellers skal tjekke klokken 3 om natten.\u00a0<\/li>\n<\/ul>\n<p><\/p>\n<h4>Tredje plads \u2014 \"Pludselig var der ikke mere plads i Cassandra\"<\/h4>\n<p>\nDataene voksede st\u00f8t, og alt var fint, indtil klustret Cassandra begyndte at fejle ved reparation af store keyspaces, fordi det ikke kunne gennemf\u00f8re compaction.\u00a0<\/p>\n<p>P\u00e5 en dyster dag n\u00e6sten forvandlede klustret sig til et gr\u00e6skar, nemlig:<\/p>\n<ul>\n<li>der var ca. 20% plads tilbage i hele klustret;<\/li>\n<li>det var ikke muligt at tilf\u00f8je noder ordentligt, fordi cleanup ikke kunne gennemf\u00f8res efter tilf\u00f8jelsen af en node p\u00e5 grund af pladsmangel p\u00e5 partitionerne;<\/li>\n<li>ydelsen falder lidt, fordi compaction ikke virker;\u00a0<\/li>\n<li>klustret k\u00f8rer i n\u00f8dtilstand.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"Top fejl fra Cian\" src=\"\/wp-content\/uploads\/2020\/05\/1d036fbc500a49a285fa4b0014e2a70d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUdgangen \u2014 vi har tilf\u00f8jet fem ekstra noder uden cleanup, hvorefter vi begyndte systematisk at fjerne dem fra klyngen og geninds\u00e6tte dem som tomme noder, hvor der ikke var plads tilbage. Tiden brugt hertil har v\u00e6ret betydeligt mere, end vi \u00f8nskede. Der var en risiko for delvis eller total utilg\u00e6ngelighed af klyngen.\u00a0<\/p>\n<p><b>Konklusioner:<\/b><\/p>\n<ul>\n<li>P\u00e5 alle servere m\u00e5 cassandra ikke have mere end 60% af pladsen optaget i hver partition.\u00a0<\/li>\n<li>De m\u00e5 ikke v\u00e6re mere end 50% belastet p\u00e5 CPU.<\/li>\n<li>Man b\u00f8r ikke overse kapacitetsplanl\u00e6gning, og det skal overvejes for hver komponent ud fra dens specifikation.<\/li>\n<li>Jo flere noder i klyngen, desto bedre. Servere med sm\u00e5 datam\u00e6ngder genopretter hurtigere, og en s\u00e5dan klynge er lettere at genoplive.\u00a0<\/li>\n<\/ul>\n<p><\/p>\n<h4>Andet sted \u2014 \u00abData forsvandt fra consul key-value storage\u00bb<\/h4>\n<p>\nTil service discovery bruger vi, ligesom mange, consul. Men vi bruger ogs\u00e5 dens key-value til blue-green deployment af monoliten. Her opbevares oplysninger om aktive og inaktive upstreams, som udskiftes under deployment. Der blev skrevet en deploy-service, som interagerede med KV. P\u00e5 et tidspunkt forsvandt dataene fra KV. Vi genskabte det fra hukommelsen, men med en r\u00e6kke fejl. Som f\u00f8lge heraf blev belastningen p\u00e5 upstreams ikke fordelt j\u00e6vnt under deployment, og vi fik mange 502-fejl p\u00e5 grund af overbelastning af backendene p\u00e5 CPU. I sidste ende flyttede vi fra consul KV til postgres, hvorfra det ikke er s\u00e5 nemt at slette dem.\u00a0\u00a0<\/p>\n<p><b>Konklusioner:<br \/>\n<\/b><\/p>\n<ul>\n<li>Tjenester uden nogen form for autentifikation m\u00e5 ikke indeholde kritiske data, der er n\u00f8dvendige for webstedets funktion. For eksempel, hvis du ikke har autentifikation i ES \u2014 er det bedst at forhindre adgang p\u00e5 netv\u00e6rksniveau fra alle steder, hvor det ikke er n\u00f8dvendigt, kun lade de n\u00f8dvendige v\u00e6re, samt at g\u00f8re action.destructive_requires_name: true.<\/li>\n<li>Arbejd med mekanismen for backup og genopretning p\u00e5 forh\u00e5nd. For eksempel, lav et script (for eksempel p\u00e5 python), der kan b\u00e5de tage backup og genoprette.<\/li>\n<\/ul>\n<p><\/p>\n<h4>F\u00f8rste sted \u2014 \u00abKaptajn \u00e5benbarhed\u00bb\u00a0<\/h4>\n<p>\nP\u00e5 et tidspunkt bem\u00e6rkede vi en uj\u00e6vn fordeling af belastningen p\u00e5 nginx upstreams, n\u00e5r der var 10+ servere i backend. Da round-robin dirigerede anmodninger fra den f\u00f8rste til den sidste upstream i r\u00e6kkef\u00f8lge, og hver genstart af nginx startede forfra, fik de f\u00f8rste upstreams altid flere anmodninger end de andre. Som f\u00f8lge heraf arbejdede de langsommere, hvilket p\u00e5virkede hele hjemmesiden. Dette blev stadig mere tydeligt i takt med, at trafikm\u00e6ngden steg. At opdatere nginx for at inkludere random l\u00f8ste ikke problemet \u2014 vi skulle genarbejde en masse lua-kode, der ikke fungerede p\u00e5 version 1.15 (p\u00e5 det tidspunkt). Vi endte med at patch vores nginx 1.14.2 og indf\u00f8re underst\u00f8ttelse af random. Dette l\u00f8ste problemet. Denne fejl vinder prisen for 'kaptejn uvidenhed'.<\/p>\n<p><b>Konklusioner:<\/b><\/p>\n<p>Det var meget interessant og sp\u00e6ndende at unders\u00f8ge denne fejl).\u00a0<\/p>\n<ul>\n<li>Organiser overv\u00e5gningen, s\u00e5 den hurtigt hj\u00e6lper med at finde s\u00e5danne flingeringer. For eksempel kan man bruge ELK til at overv\u00e5ge rps p\u00e5 hver backend af hver upstream og f\u00f8lge deres svartider set fra nginx. I dette tilf\u00e6lde hjalp det os med at identificere problemet.\u00a0<\/li>\n<\/ul>\n<p>\nDe fleste fejl kunne v\u00e6re undg\u00e5et med en mere omhyggelig tilgang til det, man laver. Man skal altid huske p\u00e5 Murphys lov:\u00a0<i>Anything that can go wrong will go wrong, <\/i>og bygge komponenterne med det i mente.\u00a0<br \/>\n<br \/>Kilde: <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\/da\/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=\"da_DK\" \/>\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\/da\/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 fejl fra CIAN | ProHoster","description":"Goddag! Jeg hedder Nikita, jeg er teamleder for ingeni\u00f8rteamet hos CIAN.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/top-fakapov-czian","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/80031","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=80031"}],"version-history":[{"count":2,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/80031\/revisions"}],"predecessor-version":[{"id":158728,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/80031\/revisions\/158728"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/80032"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=80031"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=80031"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=80031"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}