{"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\/fr\/blog\/administrirovanie\/top-fakapov-czian","title":{"rendered":"Top des erreurs de Tsiang","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Top des erreurs de Tsiang\" src=\"\/wp-content\/uploads\/2020\/05\/61cf8d25f1f3e858a3b9541cb026cf3c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nBonjour \u00e0 tous !\u00a0<\/p>\n<p>Je m'appelle Nikita, je suis le chef d'\u00e9quipe des ing\u00e9nieurs chez Cian. L'une de mes responsabilit\u00e9s dans l'entreprise est de r\u00e9duire le nombre d'incidents li\u00e9s \u00e0 l'infrastructure en production \u00e0 z\u00e9ro.<br \/>\nCe dont nous allons parler par la suite nous a caus\u00e9 beaucoup de douleurs, et l'objectif de cet article est d'\u00e9viter \u00e0 d'autres de r\u00e9p\u00e9ter nos erreurs ou tout au moins de minimiser leur impact.\u00a0<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>Pr\u00e9ambule<\/h3>\n<p>\nIl \u00e9tait une fois, quand Cian n'\u00e9tait constitu\u00e9 que de monolithes, et qu'il n'y avait aucun indice sur les microservices, nous mesurions la disponibilit\u00e9 des ressources en v\u00e9rifiant 3 \u00e0 5 pages.\u00a0<\/p>\n<p>S'ils r\u00e9pondent \u2014 tout va bien, s'ils ne r\u00e9pondent pas pendant un long moment \u2014 alerte. Combien de temps ils doivent \u00eatre hors service pour que cela soit consid\u00e9r\u00e9 comme un incident, cela \u00e9tait d\u00e9cid\u00e9 par des personnes lors de r\u00e9unions. L'\u00e9quipe d'ing\u00e9nieurs participait toujours \u00e0 l'enqu\u00eate sur l'incident. Lorsque l'enqu\u00eate \u00e9tait termin\u00e9e, un post-mortem \u00e9tait r\u00e9dig\u00e9 \u2014 un rapport adress\u00e9 par email sous la forme : ce qui s'est pass\u00e9, combien de temps cela a dur\u00e9, ce que nous avons fait sur le moment, ce que nous ferons \u00e0 l'avenir.\u00a0<\/p>\n<h3>Les pages principales du site ou comment nous savons que nous avons atteint un point critique<\/h3>\n<p>\u00a0<br \/>\nPour pouvoir comprendre la priorit\u00e9 des erreurs, nous avons identifi\u00e9 les pages du site les plus critiques pour la fonctionnalit\u00e9 commerciale. Nous comptons le nombre de requ\u00eates r\u00e9ussies\/\u00e9chou\u00e9es et de timeouts sur ces pages. Ainsi, nous mesurons le temps de disponibilit\u00e9.\u00a0<\/p>\n<p>Supposons que nous avons d\u00e9termin\u00e9 qu'il y a plusieurs sections super importantes du site qui sont responsables du service principal \u2014 la recherche et la soumission d'annonces. Si le nombre de requ\u00eates qui se terminent par une erreur d\u00e9passe 1 %, c'est un incident critique. Si pendant 15 minutes durant les heures de pointe, le pourcentage d'erreurs d\u00e9passe 0,1 %, cela est \u00e9galement consid\u00e9r\u00e9 comme un incident critique. Ces crit\u00e8res couvrent la plus grande partie des incidents, les autres d\u00e9passent le cadre de cet article.<\/p>\n<p><img decoding=\"async\" alt=\"Top des erreurs de Tsiang\" src=\"\/wp-content\/uploads\/2020\/05\/f5d76b1784c9a52ae1dc4728f1509ccc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Top des incidents les plus marquants de Cian<\/h3>\n<p>\nDonc, nous avons certainement appris \u00e0 d\u00e9finir le fait qu'un incident s'est produit.\u00a0<\/p>\n<p>Maintenant, chaque incident est d\u00e9taill\u00e9 et refl\u00e9t\u00e9 dans une \u00e9pop\u00e9e Jira. \u00c0 propos : pour cela, nous avons cr\u00e9\u00e9 un projet s\u00e9par\u00e9, que nous avons appel\u00e9 FAIL \u2014 o\u00f9 l'on peut uniquement cr\u00e9er des \u00e9pop\u00e9es.\u00a0<\/p>\n<p>Si nous rassemblons tous les \u00e9checs des derni\u00e8res ann\u00e9es, nous constatons que les principaux sont :\u00a0<\/p>\n<ul>\n<li>incidents li\u00e9s \u00e0 mssql ;<\/li>\n<li>incidents caus\u00e9s par des facteurs externes ;<\/li>\n<li>erreurs d'administration.<\/li>\n<\/ul>\n<p>\nConcentrons-nous plus en d\u00e9tail sur les erreurs des administrateurs, ainsi que sur quelques autres \u00e9checs int\u00e9ressants.<\/p>\n<h4>Cinqui\u00e8me place \u2014 \u00ab Mettre de l'ordre dans le DNS \u00bb<\/h4>\n<p>\nC'\u00e9tait un mardi pluvieux. Nous avons d\u00e9cid\u00e9 de faire le m\u00e9nage dans le cluster DNS.\u00a0<\/p>\n<p>Nous avons voulu migrer nos serveurs DNS de BIND vers PowerDNS, en allouant des serveurs enti\u00e8rement d\u00e9di\u00e9s \u00e0 cela, o\u00f9 il n'y a rien d'autre que des DNS.\u00a0<\/p>\n<p>Nous avons install\u00e9 un serveur DNS dans chaque emplacement de nos centres de donn\u00e9es, et le moment est venu de migrer les zones de BIND vers PowerDNS et de passer notre infrastructure vers les nouveaux serveurs.\u00a0<\/p>\n<p>Au beau milieu de la migration, tous <a class=\"wpil_keyword_link\" href=\"https:\/\/prohoster.info\/fr\/server\/\"   title=\"serveurs\" data-wpil-keyword-link=\"linked\"  data-wpil-monitor-id=\"1484\">serveurs<\/a>, qui \u00e9taient indiqu\u00e9s dans les caches locaux de BIND sur tous les serveurs, il ne restait qu'un seul serveur, situ\u00e9 dans le centre de donn\u00e9es de Saint-P\u00e9tersbourg. Ce DC avait initialement \u00e9t\u00e9 d\u00e9clar\u00e9 non critique pour nous, mais il est soudainement devenu un point de d\u00e9faillance unique.<br \/>\nJuste \u00e0 ce moment-l\u00e0, le lien entre Moscou et Saint-P\u00e9tersbourg est tomb\u00e9. Nous avons \u00e9t\u00e9 sans DNS pendant cinq minutes, et nous avons r\u00e9cup\u00e9r\u00e9 quand <a class=\"wpil_keyword_link\" href=\"https:\/\/prohoster.info\/fr\/\"   title=\"l&#039;h\u00e9bergeur\" data-wpil-keyword-link=\"linked\"  data-wpil-monitor-id=\"1206\">l'h\u00e9bergeur<\/a> les probl\u00e8mes ont \u00e9t\u00e9 r\u00e9solus.\u00a0<\/p>\n<p><b>Conclusions : <\/b><\/p>\n<p>Alors qu'auparavant, nous ne tenions pas compte des facteurs externes lors de la pr\u00e9paration des travaux, nous avons d\u00e9sormais inclus ces \u00e9l\u00e9ments dans notre liste de pr\u00e9paration. Nous visons d\u00e9sormais \u00e0 avoir tous les composants redond\u00e9s en n-2, et pendant la dur\u00e9e des travaux, nous pouvons r\u00e9duire ce niveau \u00e0 n-1.<\/p>\n<ul>\n<li>Lors de l'\u00e9laboration du plan d'actions, notez les points o\u00f9 le service pourrait tomber, et planifiez des sc\u00e9narios o\u00f9 tout pourrait aller \"de mal en pis\", \u00e0 l'avance.<\/li>\n<li>R\u00e9partissez les serveurs DNS internes dans diff\u00e9rentes g\u00e9olocalisations \/ centres de donn\u00e9es \/ racks \/ commutateurs \/ entr\u00e9es.<\/li>\n<li>Sur chaque serveur, installez un serveur DNS de cache local qui redirige les requ\u00eates vers les serveurs DNS principaux, et en cas d'indisponibilit\u00e9, r\u00e9pondra \u00e0 partir du cache.\u00a0<\/li>\n<\/ul>\n<p><\/p>\n<h4>Quatri\u00e8me point \u2014 \u00abMise en ordre dans Nginx\u00bb<\/h4>\n<p>\nUn beau jour, notre \u00e9quipe a d\u00e9cid\u00e9 que \"\u00e7a suffit\" et le processus de refactoring des configurations Nginx a commenc\u00e9. L'objectif principal \u00e9tait de rendre les configurations intuitivement compr\u00e9hensibles. Auparavant, tout \u00e9tait \"historique\" et n'avait aucune logique. Maintenant, chaque server_name a \u00e9t\u00e9 d\u00e9plac\u00e9 dans un fichier homonyme et toutes les configurations ont \u00e9t\u00e9 r\u00e9parties dans des dossiers. \u00c0 propos \u2014 la configuration contient 253949 lignes ou 7836520 caract\u00e8res et fait presque 7 m\u00e9gaoctets. Le niveau sup\u00e9rieur de la structure:\u00a0<\/p>\n<p>                        <b class=\"spoiler_title\">Structure Nginx<\/b><\/p>\n<pre><code class=\"plaintext\">\u251c\u2500\u2500 acc\u00e8s\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 dynamique\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>C'est devenu beaucoup mieux, mais au cours du renommage et de la r\u00e9organisation des configurations, certaines d'entre elles avaient une mauvaise extension et n'\u00e9taient pas incluses dans la directive include *.conf. En cons\u00e9quence, certaines h\u00f4tes sont devenus inaccessibles et ont renvoy\u00e9 301 vers l'accueil. Comme le code de r\u00e9ponse n'\u00e9tait pas 5xx\/4xx, cela n'a pas \u00e9t\u00e9 remarqu\u00e9 imm\u00e9diatement, seulement au matin. Apr\u00e8s cela, nous avons commenc\u00e9 \u00e0 \u00e9crire des tests pour v\u00e9rifier les composants d'infrastructure.<\/p>\n<p><b>Conclusions :<\/b>\u00a0<\/p>\n<ul>\n<li>Structurez correctement les configurations (pas seulement nginx) et pensez \u00e0 la structure d\u00e8s le d\u00e9but du projet. Cela les rendra plus compr\u00e9hensibles pour l'\u00e9quipe, ce qui \u00e0 son tour r\u00e9duira le TTM.<\/li>\n<li>Pour certains composants d'infrastructure, \u00e9crivez des tests. Par exemple : v\u00e9rifiez que tous les server_name cl\u00e9s renvoient le bon statut, + le corps de la r\u00e9ponse. Avoir simplement quelques scripts sous la main qui v\u00e9rifient les fonctions principales du composant suffira, afin de ne pas se rappeler fr\u00e9n\u00e9tiquement \u00e0 3 heures du matin ce qu'il faut encore v\u00e9rifier.\u00a0<\/li>\n<\/ul>\n<p><\/p>\n<h4>Troisi\u00e8me place \u2014 \u00abSoudain, plus d'espace dans Cassandra\u00bb<\/h4>\n<p>\nLes donn\u00e9es ont progressivement augment\u00e9, et tout allait bien jusqu'au moment o\u00f9 les r\u00e9parations de grands keyspaces dans le cluster Cassandra ont commenc\u00e9 \u00e0 \u00e9chouer, car la compaction ne pouvait pas \u00eatre effectu\u00e9e.\u00a0<\/p>\n<p>Un jour de temp\u00eate, le cluster s'est presque transform\u00e9 en citrouille, \u00e0 savoir :<\/p>\n<ul>\n<li>il restait environ 20 % en total dans le cluster ;<\/li>\n<li>il n'est pas possible d'ajouter des n\u0153uds pleinement, car le nettoyage ne se passe pas apr\u00e8s l'ajout d'un n\u0153ud en raison du manque d'espace sur les partitions ;<\/li>\n<li>la performance diminue lentement, car la compaction ne fonctionne pas ;\u00a0<\/li>\n<li>le cluster fonctionne en mode d'urgence.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"Top des erreurs de Tsiang\" src=\"\/wp-content\/uploads\/2020\/05\/1d036fbc500a49a285fa4b0014e2a70d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLa sortie \u2014 nous avons ajout\u00e9 cinq n\u0153uds sans nettoyage, puis nous avons commenc\u00e9 \u00e0 les retirer progressivement du cluster et \u00e0 les r\u00e9introduire en tant que n\u0153uds vides, sur lesquels l\u2019espace \u00e9tait \u00e9puis\u00e9. Le temps consacr\u00e9 a \u00e9t\u00e9 beaucoup plus long que pr\u00e9vu. Il y avait un risque d'indisponibilit\u00e9 partielle ou compl\u00e8te du cluster.\u00a0<\/p>\n<p><b>Conclusions :<\/b><\/p>\n<ul>\n<li>Sur tous les serveurs Cassandra, l'espace occup\u00e9 ne doit pas d\u00e9passer 60 % sur chaque partition.\u00a0<\/li>\n<li>Ils ne doivent pas \u00eatre charg\u00e9s \u00e0 plus de 50 % en CPU.<\/li>\n<li>Ne n\u00e9gligez pas la planification de capacit\u00e9 et r\u00e9fl\u00e9chissez-y pour chaque composant, en fonction de ses sp\u00e9cificit\u00e9s.<\/li>\n<li>Plus il y a de n\u0153uds dans le cluster, mieux c'est. Les serveurs contenant un petit volume de donn\u00e9es se red\u00e9marrent plus rapidement, et un tel cluster est plus facile \u00e0 r\u00e9animer.\u00a0<\/li>\n<\/ul>\n<p><\/p>\n<h4>Deuxi\u00e8me place \u2014 \u00abDes donn\u00e9es ont disparu du stockage cl\u00e9-valeur de Consul\u00bb<\/h4>\n<p>\nPour la d\u00e9couverte de services, nous utilisons, comme beaucoup, Consul. Mais notre cl\u00e9-valeur est \u00e9galement utilis\u00e9e pour la mise en production continue de notre monolithe. Elle stocke des informations sur les upstreams actifs et inactifs, qui changent de place lors du d\u00e9ploiement. Un service de d\u00e9ploiement a \u00e9t\u00e9 \u00e9crit pour interagir avec le KV. \u00c0 un moment donn\u00e9, les donn\u00e9es du KV ont disparu. Nous les avons r\u00e9cup\u00e9r\u00e9es de m\u00e9moire, mais avec quelques erreurs. En cons\u00e9quence, lors de la mise en production, la charge sur les upstreams s'est r\u00e9partie de mani\u00e8re in\u00e9gale, et nous avons rencontr\u00e9 de nombreuses erreurs 502 en raison de la surcharge des backends en CPU. Au final, nous avons migr\u00e9 de Consul KV vers Postgres, d'o\u00f9 il n'est pas si facile de les supprimer.\u00a0\u00a0<\/p>\n<p><b>Conclusions :<br \/>\n<\/b><\/p>\n<ul>\n<li>Les services sans aucune autorisation ne doivent pas contenir de donn\u00e9es critiques pour le fonctionnement du site. Par exemple, si vous n'avez pas d'autorisation dans ES, il serait pr\u00e9f\u00e9rable d'interdire l'acc\u00e8s au niveau r\u00e9seau de partout o\u00f9 il n'est pas n\u00e9cessaire, de ne laisser que les acc\u00e8s n\u00e9cessaires, et de rendre action.destructive_requires_name: true.<\/li>\n<li>Testez le m\u00e9canisme de sauvegarde et de restauration \u00e0 l'avance. Par exemple, cr\u00e9ez \u00e0 l'avance un script (par exemple, en Python) qui peut \u00e0 la fois sauvegarder et restaurer.<\/li>\n<\/ul>\n<p><\/p>\n<h4>Premi\u00e8re place \u2014 \u00abCapitaine \u00c9vidence\u00bb\u00a0<\/h4>\n<p>\n\u00c0 un moment donn\u00e9, nous avons remarqu\u00e9 une r\u00e9partition in\u00e9gale de la charge sur les upstreams nginx lorsque le backend comptait plus de 10 serveurs. \u00c9tant donn\u00e9 que le round-robin envoyait les demandes du premier au dernier upstream dans l'ordre, et que chaque rechargement de nginx recommen\u00e7ait, les premiers upstreams recevaient toujours plus de requ\u00eates que les autres. En cons\u00e9quence, ils fonctionnaient plus lentement et l'ensemble du site en souffrait. Cela devenait de plus en plus perceptible \u00e0 mesure que le trafic augmentait. Il n'a pas \u00e9t\u00e9 suffisant de mettre \u00e0 jour nginx pour activer random \u2014 il a fallu r\u00e9\u00e9crire une quantit\u00e9 cons\u00e9quente de code lua, qui ne fonctionnait pas sur la version 1.15 (\u00e0 ce moment-l\u00e0). Nous avons d\u00fb patcher notre nginx 1.14.2 pour y int\u00e9grer le support du random. Cela a r\u00e9solu le probl\u00e8me. Ce bug m\u00e9rite le prix du \u00ab capitaine de l'\u00e9vident \u00bb.<\/p>\n<p><b>Conclusions :<\/b><\/p>\n<p>C'\u00e9tait tr\u00e8s int\u00e9ressant et captivant d'explorer ce bug.)\u00a0<\/p>\n<ul>\n<li>Mettez en place un suivi afin qu'il aide \u00e0 d\u00e9tecter rapidement de telles fluctuations. Par exemple, vous pouvez utiliser ELK pour surveiller le RPS sur chaque backend de chaque upstream et suivre leur temps de r\u00e9ponse du point de vue de nginx. Dans ce cas, cela nous a aid\u00e9s \u00e0 identifier le probl\u00e8me.\u00a0<\/li>\n<\/ul>\n<p>\nUne grande partie des \u00e9checs aurait pu \u00eatre \u00e9vit\u00e9e avec une approche plus scrupuleuse de ce que vous faites. Il faut toujours garder \u00e0 l'esprit la loi de Murphy :\u00a0<i>Tout ce qui peut mal tourner, tournera mal, <\/i>et construire des composants en s'en inspirant.\u00a0<br \/>\n<br \/>Source : <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\/fr\/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=\"fr_FR\" \/>\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\/fr\/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 des faux pas de Cian | ProHoster","description":"Bonjour \u00e0 tous ! Je m'appelle Nikita, je suis le leader de l'\u00e9quipe d'ing\u00e9nieurs de Cian.","canonical_url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/top-fakapov-czian","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"fr_FR","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\/fr\/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\/fr\/wp-json\/wp\/v2\/posts\/80031","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/comments?post=80031"}],"version-history":[{"count":2,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/80031\/revisions"}],"predecessor-version":[{"id":158728,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/80031\/revisions\/158728"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media\/80032"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=80031"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=80031"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=80031"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}