{"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\/no\/blog\/administrirovanie\/top-fakapov-czian","title":{"rendered":"Top feilene til Cian","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Top feilene til Cian\" src=\"\/wp-content\/uploads\/2020\/05\/61cf8d25f1f3e858a3b9541cb026cf3c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nGod dag alle sammen!\u00a0<\/p>\n<p>Jeg heter Nikita, jeg er teamleder for ingeni\u00f8rteamet i Cian. En av mine oppgaver i selskapet er \u00e5 redusere antall hendelser relatert til infrastrukturen i produksjon til null.<br \/>\nDet som vil bli diskutert videre, har gitt oss mye smerte, og m\u00e5let med denne artikkelen er \u00e5 hindre andre fra \u00e5 gjenta v\u00e5re feil, eller i det minste minimere deres innvirkning.\u00a0<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>Forord<\/h3>\n<p>\nFor lenge siden, n\u00e5r Cian bestod av monolitter, og det ikke var noen tegn p\u00e5 mikrotjenester, m\u00e5lte vi tilgjengeligheten av ressursen ved \u00e5 sjekke 3\u20135 sider.\u00a0<\/p>\n<p>Svarte \u2013 alt er bra, svarer ikke etter lang tid \u2013 alert. Hvor lenge de m\u00e5 v\u00e6re nede for at det skal betraktes som en hendelse, ble avgjort av folk p\u00e5 m\u00f8ter. Ingeni\u00f8rteamet var alltid involvert i etterforskningen av hendelsen. N\u00e5r etterforskningen var fullf\u00f8rt, skrev vi et postmortem \u2013 en slags rapport sendt p\u00e5 e-post i formatet: hva som skjedde, hvor lenge det varte, hva vi gjorde i \u00f8yeblikket, hva vi vil gj\u00f8re i fremtiden.\u00a0<\/p>\n<h3>De viktigste sidene p\u00e5 nettstedet eller hvordan vi forst\u00e5r at vi har truffet bunnen<\/h3>\n<p>\u00a0<br \/>\nFor \u00e5 kunne forst\u00e5 prioriteten til feilen, identifiserte vi de mest kritiske sidene for forretningsfunksjonaliteten p\u00e5 nettstedet. For disse sidene teller vi antall vellykkede\/ mislykkede foresp\u00f8rsel og tidsavbrudd. P\u00e5 denne m\u00e5ten m\u00e5ler vi oppetid.\u00a0<\/p>\n<p>La oss si at vi har funnet ut at det er flere superviktige seksjoner p\u00e5 nettstedet som er ansvarlige for hovedtjenesten \u2013 s\u00f8k og innlevering av annonser. Hvis antall foresp\u00f8rsel som resulterte i feil overskrider 1% \u2013 er det en kritisk hendelse. Hvis prosentandelen av feil overskrider 0,1% i l\u00f8pet av 15 minutter i rushtiden \u2013 betraktes dette ogs\u00e5 som en kritisk hendelse. Disse kriteriene dekker de fleste hendelser, mens andre g\u00e5r utenfor rammen av denne artikkelen.<\/p>\n<p><img decoding=\"async\" alt=\"Top feilene til Cian\" src=\"\/wp-content\/uploads\/2020\/05\/f5d76b1784c9a52ae1dc4728f1509ccc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Top beste hendelsene til Cian<\/h3>\n<p>\nS\u00e5 vi har absolutt l\u00e6rt \u00e5 identifisere at en hendelse har skjedd.\u00a0<\/p>\n<p>N\u00e5 er hver hendelse detaljert beskrevet og reflektert i en episk Jira. For ordens skyld: for dette opprettet vi et eget prosjekt, kalt FAIL \u2013 her kan det kun opprettes episoder.\u00a0<\/p>\n<p>Hvis vi samler alle feilene fra de siste \u00e5rene, er de ledende:\u00a0<\/p>\n<ul>\n<li>hendelser relatert til mssql;<\/li>\n<li>hendelser for\u00e5rsaket av eksterne faktorer;<\/li>\n<li>administrasjonsfeil.<\/li>\n<\/ul>\n<p>\nLa oss g\u00e5 mer detaljert inn p\u00e5 administrasjonsfeilene, samt noen andre interessante feil.<\/p>\n<h4>Femte plassen \u2013 \u00abVi rydder opp i DNS\u00bb<\/h4>\n<p>\nDet var en gr\u00e5 tirsdag. Vi bestemte oss for \u00e5 rydde opp i DNS-klyngen.\u00a0<\/p>\n<p>Vi \u00f8nsket \u00e5 migrere interne DNS-servere fra BIND til PowerDNS, og dedikere helt separate servere til dette, hvor det bare kj\u00f8rer DNS.\u00a0<\/p>\n<p>Vi plasserte \u00e9n DNS-server i hver lokasjon av v\u00e5re datasentre, og tiden for \u00e5 flytte sonene fra BIND til PowerDNS og bytte infrastrukturen til de nye serverne kom.\u00a0<\/p>\n<p>I det mest hektiske \u00f8yeblikket under overf\u00f8ringen av alle <a class=\"wpil_keyword_link\" href=\"https:\/\/prohoster.info\/no\/server\/\"   title=\"servere\" data-wpil-keyword-link=\"linked\"  data-wpil-monitor-id=\"1484\">servere<\/a>, som ble oppgitt i de lokale cacherende BIND-serverne p\u00e5 alle serverne, gjensto bare \u00e9n, som befant seg i datasenteret i St. Petersburg. Dette datasenteret var opprinnelig deklarert som ikke-kritisk for oss, men ble plutselig en single point of failure.<br \/>\nAkkurat i l\u00f8pet av denne overf\u00f8ringsperioden falt kanalen mellom Moskva og St. Petersburg. Vi sto faktisk uten DNS i fem minutter og kom opp igjen da <a class=\"wpil_keyword_link\" href=\"https:\/\/prohoster.info\/no\/\"   title=\"hoster\" data-wpil-keyword-link=\"linked\"  data-wpil-monitor-id=\"1206\">hoster<\/a> feilen var utbedret.\u00a0<\/p>\n<p><b>Konklusjoner: <\/b><\/p>\n<p>Tidligere overs\u00e5 vi eksterne faktorer under forberedelsene til arbeidet, men n\u00e5 inkluderer vi ogs\u00e5 dem i listen over hva vi m\u00e5 forberede oss p\u00e5. N\u00e5 streber vi etter at alle komponenter er reservert i n-2, og i l\u00f8pet av arbeidene kan vi senke dette niv\u00e5et til n-1.<\/p>\n<ul>\n<li>N\u00e5r du lager handlingsplanen, noter punktene hvor tjenesten kan falle, og tenk p\u00e5 scenarier der alt g\u00e5r \u00abs\u00e5 d\u00e5rlig som mulig\u00bb p\u00e5 forh\u00e5nd.<\/li>\n<li>Fordel interne DNS-servere p\u00e5 forskjellige geolokasjoner\/datasentre\/stativer\/brytere\/inntak.<\/li>\n<li>Sett opp en lokal cacherende DNS-server p\u00e5 hver server, som videresender foresp\u00f8rslene til de prim\u00e6re DNS-serverne, og i tilfelle den ikke er tilgjengelig, vil svare fra cachen.\u00a0<\/li>\n<\/ul>\n<p><\/p>\n<h4>Fjerde plassen \u2013 \u00abVi rydder opp i Nginx\u00bb<\/h4>\n<p>\nEn vakker dag bestemte teamet v\u00e5rt at \u00abn\u00e5 er det nok\u00bb, og prosessen med refaktorering av Nginx-konfigurasjonene ble igangsatt. Hovedm\u00e5let var \u00e5 gj\u00f8re konfigurasjonene intuitivt forst\u00e5elige. Tidligere var alt \u00abhistorisk oppbygd\u00bb og inneholdt ikke noe logikk. N\u00e5 har vi flyttet hver server_name til en tilsvarende fil og fordelt alle konfigurasjoner i mapper. For \u00e5 si det slik \u2013 konfigurasjonen inneholder 253949 linjer eller 7836520 tegn og tar nesten 7 megabyte. \u00d8verste niv\u00e5 av strukturen:\u00a0<\/p>\n<p>                        <b class=\"spoiler_title\">Nginx-struktur<\/b><\/p>\n<pre><code class=\"plaintext\">\u251c\u2500\u2500 tilgang\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-Land.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>Det ble betydelig bedre, men i prosessen med \u00e5 omd\u00f8pe og fordele konfigurasjoner hadde noen av dem feil filendelse og havnet ikke i direktivet include *.conf. Som et resultat ble deler av vertene utilgjengelige og ga 301 til hovedsiden. P\u00e5 grunn av at svarkoden ikke var 5xx\/4xx, ble dette ikke lagt merke til med en gang, men f\u00f8rst tidlig om morgenen. Etter dette begynte vi \u00e5 skrive tester for \u00e5 sjekke infrastrukturkomponentene.<\/p>\n<p><b>Konklusjoner:<\/b>\u00a0<\/p>\n<ul>\n<li>Strukturer konfigurasjonene riktig (ikke bare nginx) og tenk gjennom strukturen tidlig i prosjektet. Dette vil gj\u00f8re dem enklere \u00e5 forst\u00e5 for teamet, noe som igjen vil redusere TTM.<\/li>\n<li>Skriv tester for enkelte infrastrukturkomponenter. For eksempel: sjekk at alle n\u00f8kkelservere gir riktig status og kropp av svaret. Det er nok \u00e5 ha noen skript tilgjengelig som tester hovedfunksjonene til komponenten, s\u00e5 du ikke m\u00e5 statte deg selv i panikk klokken tre om natten om hva mer som skal sjekkes.\u00a0<\/li>\n<\/ul>\n<p><\/p>\n<h4>Tredjeplassen - 'Plutselig var det ikke mer plass i Cassandra'<\/h4>\n<p>\nDataene vokste jevnt, og alt var greit inntil det punktet hvor store cassandra-kapsekser begynte \u00e5 feile ved vedlikehold fordi kompaktsjon ikke kan fungere.\u00a0<\/p>\n<p>P\u00e5 en d\u00e5rlig dag ble klusteret nesten til en gresskar, som sagt:<\/p>\n<ul>\n<li>det var omtrent 20% ledig plass totalt i klusteret;<\/li>\n<li>det er ikke mulig \u00e5 legge til noder ordentlig fordi det ikke gjennomf\u00f8res rensing etter \u00e5 ha lagt til en node p\u00e5 grunn av plassmangel p\u00e5 partisjoner;<\/li>\n<li>ytelsen synker litt, siden kompaktsjon ikke fungerer;\u00a0<\/li>\n<li>klusteret fungerer i n\u00f8dmodus.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"Top feilene til Cian\" src=\"\/wp-content\/uploads\/2020\/05\/1d036fbc500a49a285fa4b0014e2a70d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUte \u2014 vi har lagt til fem flere noder uten rensing, hvoretter vi begynte \u00e5 trekke dem systematisk ut av klyngen og deretter legge dem inn igjen som tomme noder som har fylt opp plassen. Tiden brukt har v\u00e6rt betydelig mer enn \u00f8nsket. Det var risiko for delvis eller full utilgjengelighet av klyngen.\u00a0<\/p>\n<p><b>Konklusjoner:<\/b><\/p>\n<ul>\n<li>P\u00e5 alle servere b\u00f8r cassandra ha opptil 60 % av plassen brukt p\u00e5 hver partisjon.\u00a0<\/li>\n<li>De b\u00f8r v\u00e6re lastet opp til maksimalt 50 % av CPU.<\/li>\n<li>Ikke undervurder kapasitetsplanlegging, og det b\u00f8r tenkes p\u00e5 for hver komponent med hensyn til dens spesifikasjoner.<\/li>\n<li>Jo flere noder i klyngen, desto bedre. Servere som inneholder en liten mengde data, blir raskere gjenopprettet, og en slik klynge er lettere \u00e5 reaktivere.\u00a0<\/li>\n<\/ul>\n<p><\/p>\n<h4>Andreplass \u2014 \u00abDataene forsvant fra konsulens key-value-lagring\u00bb<\/h4>\n<p>\nFor tjenestegjenkjenning bruker vi, som mange andre, konsul. Men vi bruker ogs\u00e5 dens key-value for blue-green distribusjon av monolittisk programvare. Der lagres informasjon om aktive og inaktive upstreams, som bytter plass under distribusjonen. For dette ble det skrevet en distribusjonstjeneste som interagerte med KV. P\u00e5 et tidspunkt forsvant dataene fra KV. Vi gjenopprettet dem fra hukommelsen, men med en rekke feil. F\u00f8lgelig ble belastningen p\u00e5 upstreamene fordelt ujevnt under distribusjonen, og vi fikk mange 502-feil p\u00e5 grunn av overbelastning av backendene p\u00e5 CPU. Til slutt flyttet vi fra konsul KV til postgres, hvor det er mye vanskeligere \u00e5 slette dem.\u00a0\u00a0<\/p>\n<p><b>Konklusjoner:<br \/>\n<\/b><\/p>\n<ul>\n<li>Tjenester uten noen form for autorisering b\u00f8r ikke inneholde kritiske data for nettstedets drift. For eksempel, hvis du ikke har autorisasjon i ES \u2014 ville det v\u00e6rt bedre \u00e5 blokkere tilgang p\u00e5 nettverksniv\u00e5 fra alle steder der det ikke er n\u00f8dvendig, og beholde bare de n\u00f8dvendige, samt gj\u00f8re action.destructive_requires_name: true.<\/li>\n<li>\u00d8v p\u00e5 mekanismen for sikkerhetskopiering og gjenoppretting p\u00e5 forh\u00e5nd. For eksempel, lag en skript (for eksempel i python) som kan b\u00e5de sikkerhetskopiere og gjenopprette.<\/li>\n<\/ul>\n<p><\/p>\n<h4>F\u00f8rsteplass \u2014 \u00abKapitano utydelighet\u00bb\u00a0<\/h4>\n<p>\nP\u00e5 et tidspunkt merket vi en ujevn belastning p\u00e5 nginx upstreams n\u00e5r backend hadde 10+ servere. Siden round-robin dirigerte foresp\u00f8rslene fra 1 til siste upstream i rekkef\u00f8lge, og hver reload av nginx startet p\u00e5 nytt, fikk de f\u00f8rste upstreamene alltid flere foresp\u00f8rsel enn de andre. Som et resultat jobbet de tregere, og hele nettsiden led. Dette ble mer og mer merkbart etter hvert som trafikken \u00f8kte. Det var ikke nok \u00e5 bare oppdatere nginx for \u00e5 aktivere random; vi m\u00e5tte omskrive mye lua-kode som ikke fungerte p\u00e5 versjon 1.15 (p\u00e5 den tiden). Vi m\u00e5tte patch nginx 1.14.2 for \u00e5 legge til st\u00f8tte for random. Dette l\u00f8ste problemet. Denne feilen vinner prisen for \u00abkaptein \u00e5penbarhet\u00bb.<\/p>\n<p><b>Konklusjoner:<\/b><\/p>\n<p>Det var veldig interessant og engasjerende \u00e5 unders\u00f8ke denne feilen).\u00a0<\/p>\n<ul>\n<li>Sett opp overv\u00e5kning slik at den kan hjelpe deg med \u00e5 raskt finne slike fluktuasjoner. For eksempel kan man bruke ELK for \u00e5 overv\u00e5ke rps p\u00e5 hver backend av hver upstream, og f\u00f8lge med p\u00e5 svartidene gjennom nginx. I dette tilfellet hjalp det oss \u00e5 avdekke problemet.\u00a0<\/li>\n<\/ul>\n<p>\nMye av feilen kunne v\u00e6rt unng\u00e5tt med en mer grundig tiln\u00e6rming til det man gj\u00f8r. Man m\u00e5 alltid huske p\u00e5 Murphy\u2019s lov:\u00a0<i>Anything that can go wrong will go wrong, <\/i>og bygge komponenter med dette i tankene.\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.5 - 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\/no\/blog\/administrirovanie\/top-fakapov-czian\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.5\" \/>\n\t\t<meta property=\"og:locale\" content=\"nn_NO\" \/>\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\/no\/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 feller fra Cian | ProHoster","description":"God dag alle sammen! Jeg heter Nikita, jeg er teamleder for ingeni\u00f8rteamet til Cian.","canonical_url":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/top-fakapov-czian","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nn_NO","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\/no\/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\/no\/wp-json\/wp\/v2\/posts\/80031","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/comments?post=80031"}],"version-history":[{"count":2,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts\/80031\/revisions"}],"predecessor-version":[{"id":158728,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts\/80031\/revisions\/158728"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/media\/80032"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/media?parent=80031"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/categories?post=80031"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/tags?post=80031"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}