{"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\/it\/blog\/administrirovanie\/top-fakapov-czian","title":{"rendered":"Top errori di Cian","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Top errori di Cian\" src=\"\/wp-content\/uploads\/2020\/05\/61cf8d25f1f3e858a3b9541cb026cf3c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nA tutti buona giornata!\u00a0<\/p>\n<p>Mi chiamo Nikita, sono il team leader del gruppo ingegneri di Cian. Una delle mie responsabilit\u00e0 in azienda \u00e8 ridurre il numero di incidenti legati all'infrastruttura in produzione a zero.<br \/>\nQuello di cui parleremo nei prossimi paragrafi ci ha causato molta sofferenza, e l'obiettivo di questo articolo \u00e8 non far ripetere ad altre persone i nostri errori o almeno minimizzare il loro impatto.\u00a0<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>Premessa<\/h3>\n<p>\nMolto tempo fa, quando Cian era composto da monoliti e non c'erano tracce di microservizi, misuravamo la disponibilit\u00e0 del servizio controllando 3-5 pagine.\u00a0<\/p>\n<p>Se le pagine rispondevano, tutto andava bene; se non rispondevano per molto tempo, scattava un alert. Quanto tempo dovevano rimanere inattive per essere considerato un incidente, lo decidevano le persone in riunione. Il team di ingegneri partecipava sempre all'indagine sull'incidente. Quando l'indagine era conclusa, scrivevano un post mortem \u2014 una sorta di rapporto via email nel formato: cosa \u00e8 successo, quanto \u00e8 durato, cosa \u00e8 stato fatto nel momento e cosa faremo in futuro.\u00a0<\/p>\n<h3>Le pagine principali del sito o come comprendiamo di aver toccato il fondo<\/h3>\n<p>\u00a0<br \/>\nPer poter capire in qualche modo la priorit\u00e0 dell'errore, abbiamo identificato le pagine pi\u00f9 critiche per le funzionalit\u00e0 aziendali del sito. Su queste pagine calcoliamo il numero di richieste andate a buon fine\/non andate a buon fine e i timeout. In questo modo misuriamo l'uptime.\u00a0<\/p>\n<p>Supponiamo di aver scoperto che ci sono diverse sezioni super importanti del sito che sono responsabili del servizio principale \u2014 ricerca e invio di annunci. Se il numero di richieste che si sono concluse con un errore supera l'1%, \u00e8 un incidente critico. Se durante 15 minuti nelle ore di punta la percentuale di errori supera lo 0,1%, \u00e8 considerato anch'esso un incidente critico. Questi criteri coprono la maggior parte degli incidenti, gli altri esulano da questo articolo.<\/p>\n<p><img decoding=\"async\" alt=\"Top errori di Cian\" src=\"\/wp-content\/uploads\/2020\/05\/f5d76b1784c9a52ae1dc4728f1509ccc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>I migliori incidenti di Cian<\/h3>\n<p>\nQuindi, abbiamo sicuramente imparato a riconoscere il fatto che si \u00e8 verificato un incidente.\u00a0<\/p>\n<p>Ora ogni incidente \u00e8 descritto in dettaglio e riflesso nell'epica di Jira. A proposito: per questo abbiamo creato un progetto separato, chiamato FAIL \u2014 al suo interno si possono creare solo epiche.\u00a0<\/p>\n<p>Se raccogliamo tutti i fallimenti degli ultimi anni, i pi\u00f9 frequenti sono:\u00a0<\/p>\n<ul>\n<li>incidenti legati a mssql;<\/li>\n<li>incidenti causati da fattori esterni;<\/li>\n<li>errori dell'amministratore.<\/li>\n<\/ul>\n<p>\nFermiamoci a esaminare pi\u00f9 in dettaglio gli errori degli amministratori, cos\u00ec come alcuni altri fallimenti interessanti.<\/p>\n<h4>Quinto posto \u2014 \"Mettiamo in ordine il DNS\"<\/h4>\n<p>\nEra un marted\u00ec tempestoso. Abbiamo deciso di mettere in ordine il cluster DNS.\u00a0<\/p>\n<p>Ci \u00e8 venuta voglia di migrare i server DNS interni da bind a powerdns, dedicando a questo completamente server separati, dove non c'\u00e8 nulla oltre al DNS.\u00a0<\/p>\n<p>Abbiamo posizionato un server DNS in ciascuna delle nostre localit\u00e0 nei DC, e \u00e8 arrivato il momento di migrare le zone da bind a powerdns e di passare l'infrastruttura sui nuovi server.\u00a0<\/p>\n<p>Nel momento pi\u00f9 intenso della migrazione, di tutti <a class=\"wpil_keyword_link\" href=\"https:\/\/prohoster.info\/it\/server\/\"   title=\"server\" data-wpil-keyword-link=\"linked\"  data-wpil-monitor-id=\"1484\">server<\/a>, che erano stati indicati nei bind di caching locali su tutti i server, ne \u00e8 rimasto solo uno, che si trovava nel data center di San Pietroburgo. Questo DC era stato inizialmente dichiarato come non critico per noi, ma \u00e8 diventato improvvisamente un punto unico di guasto.<br \/>\nProprio in quel periodo di migrazione, la connessione tra Mosca e San Pietroburgo \u00e8 caduta. Siamo rimasti effettivamente senza DNS per cinque minuti e ci siamo rialzati quando <a class=\"wpil_keyword_link\" href=\"https:\/\/prohoster.info\/it\/\"   title=\"un hoster\" data-wpil-keyword-link=\"linked\"  data-wpil-monitor-id=\"1206\">un hoster<\/a> ha risolto i problemi.\u00a0<\/p>\n<p><b>Conclusioni: <\/b><\/p>\n<p>Se prima trascuravamo i fattori esterni durante la preparazione ai lavori, ora li abbiamo inclusi nella lista di ci\u00f2 per cui ci prepariamo. Ora ci sforziamo di avere tutti i componenti riservati a n-2, e durante i lavori possiamo abbassare questo livello a n-1.<\/p>\n<ul>\n<li>Durante la stesura del piano d'azione, annota i punti in cui il servizio pu\u00f2 cadere e prevedi uno scenario in cui tutto va \"peggio di cos\u00ec\", in anticipo.<\/li>\n<li>Distribuisci i server DNS interni in diverse geolocalizzazioni\/data center\/rack\/switch\/ingressi.<\/li>\n<li>Su ciascun server, installa un server DNS locale di caching che reindirizza le richieste ai server DNS principali, e nel caso in cui non sia disponibile, risponder\u00e0 dal cache.\u00a0<\/li>\n<\/ul>\n<p><\/p>\n<h4>Quarto punto \u2014 \"Mettiamo in ordine Nginx\"<\/h4>\n<p>\nUn bel giorno, il nostro team ha deciso che \"\u00e8 ora di smettere di tollerarlo\", e \u00e8 iniziato il processo di refactoring delle configurazioni di nginx. L'obiettivo principale \u00e8 rendere le configurazioni pi\u00f9 intuitive. Prima tutto era \"storicamente consolidato\" e non aveva alcuna logica. Ora ogni server_name \u00e8 stato spostato in un file omonimo e tutte le configurazioni sono state distribuite in cartelle. A proposito \u2014 la configurazione contiene 253949 righe o 7836520 caratteri e occupa quasi 7 megabyte. Il livello superiore della struttura:\u00a0<\/p>\n<p>                        <b class=\"spoiler_title\">Struttura Nginx<\/b><\/p>\n<pre><code class=\"plaintext\">\u251c\u2500\u2500 access\n\u2502 \u00a0 \u251c\u2500\u2500 allow.list\n...\n\u2502 \u00a0 \u2514\u2500\u2500 whitelist.conf\n\u251c\u2500\u2500 geobase\n\u2502 \u00a0 \u251c\u2500\u2500 exclude.conf\n...\n\u2502 \u00a0 \u2514\u2500\u2500 geo_ip_to_region_id.conf\n\u251c\u2500\u2500 geodb\n\u2502 \u00a0 \u251c\u2500\u2500 GeoIP.dat\n\u2502 \u00a0 \u251c\u2500\u2500 GeoIP2-Country.mmdb\n\u2502 \u00a0 \u2514\u2500\u2500 GeoLiteCity.dat\n\u251c\u2500\u2500 inc\n\u2502 \u00a0 \u251c\u2500\u2500 error.inc\n...\n\u2502 \u00a0 \u2514\u2500\u2500 proxy.inc\n\u251c\u2500\u2500 lists.d\n\u2502 \u00a0 \u251c\u2500\u2500 bot.conf\n...\n\u2502 \u00a0 \u251c\u2500\u2500 dynamic\n\u2502 \u00a0 \u2514\u2500\u2500 geo.conf\n\u251c\u2500\u2500 lua\n\u2502 \u00a0 \u251c\u2500\u2500 cookie.lua\n\u2502 \u00a0 \u251c\u2500\u2500 log\n\u2502 \u00a0 \u2502 \u00a0 \u2514\u2500\u2500 log.lua\n\u2502 \u00a0 \u251c\u2500\u2500 logics\n\u2502 \u00a0 \u2502 \u00a0 \u251c\u2500\u2500 include.lua\n\u2502 \u00a0 \u2502 \u00a0 \u251c\u2500\u2500 ...\n\u2502 \u00a0 \u2502 \u00a0 \u2514\u2500\u2500 utils.lua\n\u2502 \u00a0 \u2514\u2500\u2500 prom\n\u2502 \u00a0 \u00a0 \u00a0 \u251c\u2500\u2500 stats.lua\n\u2502 \u00a0 \u00a0 \u00a0 \u2514\u2500\u2500 stats_prometheus.lua\n\u251c\u2500\u2500 map.d\n\u2502 \u00a0 \u251c\u2500\u2500 access.conf\n\u2502 \u00a0 \u251c\u2500\u2500 ..\u00a0\n\u2502 \u00a0 \u2514\u2500\u2500 zones.conf\n\u251c\u2500\u2500 nginx.conf\n\u251c\u2500\u2500 robots.txt\n\u251c\u2500\u2500 server.d\n\u2502 \u00a0 \u251c\u2500\u2500 cian.ru\n\u2502 \u00a0 \u2502 \u00a0 \u251c\u2500\u2500 cian.ru.conf\n\u2502 \u00a0 \u2502 \u00a0 \u251c\u2500\u2500 ...\n\u2502 \u00a0 \u2502 \u00a0 \u2514\u2500\u2500 my.cian.ru.conf\n\u251c\u2500\u2500 service.d\n\u2502 \u00a0 \u251c\u2500\u2500 ...\n\u2502 \u00a0 \u2514\u2500\u2500 status.conf\n\u2514\u2500\u2500 upstream.d\n\u00a0\u00a0\u00a0\u00a0\u251c\u2500\u2500 cian-mcs.conf\n\u00a0\u00a0\u00a0\u00a0\u251c\u2500\u2500 ...\n\u00a0\u00a0\u00a0\u00a0\u2514\u2500\u2500 wafserver.conf<\/code><\/pre>\n<p>\u00c8 migliorato significativamente, ma durante il processo di rinominazione e distribuzione delle configurazioni, alcune di esse avevano estensioni errate e non sono state incluse nella direttiva include *.conf. Di conseguenza, alcuni host sono diventati non disponibili e restituivano 301 alla home page. Poich\u00e9 il codice di risposta non era 5xx\/4xx, non ce ne siamo accorti subito, ma solo all'alba. Dopo ci\u00f2, abbiamo iniziato a scrivere test per controllare i componenti infrastrutturali.<\/p>\n<p><b>Conclusioni:<\/b>\u00a0<\/p>\n<ul>\n<li>Struttura correttamente le configurazioni (non solo nginx) e progetta la struttura fin dalle fasi iniziali del progetto. In questo modo, le renderai pi\u00f9 comprensibili per il team, il che a sua volta ridurr\u00e0 il Time To Market.<\/li>\n<li>Per alcuni componenti infrastrutturali scrivi dei test. Ad esempio: verifica che tutti i server_name chiave restituiscano lo stato corretto, insieme al corpo della risposta. \u00c8 sufficiente avere a disposizione alcuni script che controllano le funzioni principali del componente, per non dover ricordare in modo affannoso a tre di notte cosa altro bisogna controllare.\u00a0<\/li>\n<\/ul>\n<p><\/p>\n<h4>Terzo posto \u2013 \"Improvvisamente lo spazio in Cassandra \u00e8 finito\"<\/h4>\n<p>\nI dati sono cresciuti costantemente, e tutto andava bene fino al momento in cui nel cluster Cassandra sono iniziati a fallire i repair dei grandi keyspace, perch\u00e9 non pu\u00f2 eseguire la compaction.\u00a0<\/p>\n<p>Un giorno di maltempo, il cluster \u00e8 quasi diventato una zucca, cio\u00e8:<\/p>\n<ul>\n<li>c'era circa il 20% di spazio residuo complessivamente nel cluster;<\/li>\n<li>non era possibile aggiungere nodi in modo completo, poich\u00e9 non passava il cleanup dopo l'aggiunta del nodo a causa della mancanza di spazio sulle partizioni;<\/li>\n<li>le prestazioni stavano lentamente diminuendo, poich\u00e9 la compaction non funzionava;\u00a0<\/li>\n<li>il cluster funzionava in modalit\u00e0 di emergenza.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"Top errori di Cian\" src=\"\/wp-content\/uploads\/2020\/05\/1d036fbc500a49a285fa4b0014e2a70d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nL'uscita \u2014 abbiamo aggiunto altre 5 nodi senza cleanup, dopo di che abbiamo iniziato a rimuovere progressivamente dal cluster e a reinserire, come nodi vuoti, quelli che non avevano pi\u00f9 spazio. Il tempo impiegato \u00e8 stato molto pi\u00f9 del previsto. C'era il rischio di una parziale o totale indisponibilit\u00e0 del cluster.\u00a0<\/p>\n<p><b>Conclusioni:<\/b><\/p>\n<ul>\n<li>Su tutti i server cassandra non dovrebbe essere occupato pi\u00f9 del 60% dello spazio su ciascuna partizione.\u00a0<\/li>\n<li>Devono essere caricati non pi\u00f9 del 50% della capacit\u00e0 CPU.<\/li>\n<li>Non bisogna trascurare il capacity planning e deve essere elaborato per ogni componente, in base alla sua specificit\u00e0.<\/li>\n<li>Pi\u00f9 nodi ci sono nel cluster \u2014 meglio \u00e8. I server che contengono un piccolo volume di dati si ripristinano pi\u00f9 rapidamente, e un cluster del genere \u00e8 pi\u00f9 facile da ripristinare.\u00a0<\/li>\n<\/ul>\n<p><\/p>\n<h4>Secondo posto \u2014 \u00abDati scomparsi dal consul key-value storage\u00bb<\/h4>\n<p>\nPer la discovery dei servizi utilizziamo, come molti, consul. Ma il nostro key-value viene usato anche per il deployment blue-green del monolite. Qui si trova l'informazione sugli upstream attivi e inattivi, che cambiano posizione durante il deployment. \u00c8 stato scritto un servizio di deployment che interagiva con KV. A un certo punto, i dati da KV sono scomparsi. Li abbiamo ripristinati dalla memoria, ma con alcuni errori. Di conseguenza, durante il deployment, il carico sugli upstream si \u00e8 distribuito in modo irregolare, e abbiamo ricevuto molti errori 502 a causa del sovraccarico dei backend per CPU. Alla fine siamo passati da consul KV a postgres, da dove eliminarli non \u00e8 cos\u00ec semplice.\u00a0\u00a0<\/p>\n<p><b>Conclusioni:<br \/>\n<\/b><\/p>\n<ul>\n<li>I servizi senza alcuna autorizzazione non dovrebbero contenere dati critici per il funzionamento del sito. Ad esempio, se non hai autorizzazione in ES \u2014 sarebbe meglio vietare l'accesso a livello di rete ovunque non sia necessario, mantenere solo quelli necessari e impostare action.destructive_requires_name: true.<\/li>\n<li>Testate prima il meccanismo di backup e ripristino. Ad esempio, preparate in anticipo uno script (ad esempio in python) che possa effettuare sia il backup che il ripristino.<\/li>\n<\/ul>\n<p><\/p>\n<h4>Primo posto \u2014 \u00abCapitano non evidente\u00bb\u00a0<\/h4>\n<p>\nAd un certo punto abbiamo notato una distribuzione irregolare del carico sugli upstream di nginx nei casi in cui c'erano pi\u00f9 di 10 server nel backend. Poich\u00e9 il round-robin inviava le richieste dall'upstream 1 fino all'ultimo in ordine, e ogni ricarica di nginx iniziava da capo, i primi upstream ricevevano sempre pi\u00f9 richieste rispetto agli altri. Di conseguenza, funzionavano pi\u00f9 lentamente e l'intero sito ne risentiva. Questo diventava sempre pi\u00f9 evidente con l'aumentare del traffico. Aggiornare nginx per attivare la modalit\u00e0 casuale non era sufficiente: era necessario riscrivere un sacco di codice lua, che non funzionava con la versione 1.15 (in quel momento). Abbiamo dovuto patchare il nostro nginx 1.14.2, integrando il supporto random. Questo ha risolto il problema. Questo bug vince il premio per il \"capitano dell'ovviet\u00e0\".<\/p>\n<p><b>Conclusioni:<\/b><\/p>\n<p>\u00c8 stato molto interessante e coinvolgente esplorare questo bug).\u00a0<\/p>\n<ul>\n<li>Imposta il monitoraggio in modo da aiutarti a individuare rapidamente tali fluttuazioni. Ad esempio, puoi utilizzare ELK per monitorare l'rps di ogni backend di ciascun upstream, tenendo d'occhio i loro tempi di risposta dal punto di vista di nginx. In questo caso, ci ha aiutato a identificare il problema.\u00a0<\/li>\n<\/ul>\n<p>\nLa maggior parte dei fallimenti sarebbe stata evitabile con un approccio pi\u00f9 scrupoloso a ci\u00f2 che si fa. Bisogna sempre tenere a mente la legge di Murphy:\u00a0<i>Tutto ci\u00f2 che pu\u00f2 andare storto andr\u00e0 storto, <\/i>e costruire i componenti seguendo questo principio.\u00a0<br \/>\n<br \/>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/cian\/blog\/499542\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0412\u0441\u0435\u043c \u0434\u043e\u0431\u0440\u0430!\u00a0 \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u041d\u0438\u043a\u0438\u0442\u0430, \u044f \u0442\u0438\u043c\u043b\u0438\u0434 \u043a\u043e\u043c\u0430\u043d\u0434\u044b \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u043e\u0432 \u0426\u0438\u0430\u043d. \u041e\u0434\u043d\u043e\u0439 \u0438\u0437 \u043c\u043e\u0438\u0445 \u043e\u0431\u044f\u0437\u0430\u043d\u043d\u043e\u0441\u0442\u0435\u0439 \u0432 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0441\u043d\u0438\u0436\u0435\u043d\u0438\u0435 \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u0430 \u0438\u043d\u0446\u0438\u0434\u0435\u043d\u0442\u043e\u0432, \u0441\u0432\u044f\u0437\u0430\u043d\u043d\u044b\u0445 \u0441 \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u043e\u0439 \u043d\u0430 \u043f\u0440\u043e\u0434\u0435, \u0434\u043e \u043d\u0443\u043b\u044f. \u0422\u043e, \u043e \u0447\u0435\u043c \u043f\u043e\u0439\u0434\u0435\u0442 \u0440\u0435\u0447\u044c \u0434\u0430\u043b\u0435\u0435, \u043f\u0440\u0438\u043d\u0435\u0441\u043b\u043e \u043d\u0430\u043c \u043c\u043d\u043e\u0433\u043e \u0431\u043e\u043b\u0438, \u0438 \u0446\u0435\u043b\u044c \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0438 \u2014 \u043d\u0435 \u0434\u0430\u0442\u044c \u0434\u0440\u0443\u0433\u0438\u043c \u043b\u044e\u0434\u044f\u043c \u043f\u043e\u0432\u0442\u043e\u0440\u0438\u0442\u044c \u043d\u0430\u0448\u0438\u0445 \u043e\u0448\u0438\u0431\u043e\u043a \u0438\u043b\u0438 \u0445\u043e\u0442\u044f \u0431\u044b \u043c\u0438\u043d\u0438\u043c\u0438\u0437\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0438\u0445 \u0432\u043b\u0438\u044f\u043d\u0438\u0435.\u00a0 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":80032,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-80031","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2 - 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\/it\/blog\/administrirovanie\/top-fakapov-czian\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"it_IT\" \/>\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\/it\/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 errori di Cian | ProHoster","description":"A tutti un saluto! Mi chiamo Nikita, sono il team leader del gruppo ingegneri di Cian.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/top-fakapov-czian","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","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\/it\/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\/it\/wp-json\/wp\/v2\/posts\/80031","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=80031"}],"version-history":[{"count":2,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/80031\/revisions"}],"predecessor-version":[{"id":158728,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/80031\/revisions\/158728"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/80032"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=80031"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=80031"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=80031"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}