<\/a><\/noindex>En lan\u00e7ant le service, nous savions que le plus important \u00e9tait d'assurer la tol\u00e9rance aux pannes, la fiabilit\u00e9 et la disponibilit\u00e9 constante du service, car si vous avez un site web ordinaire, un magasin par exemple, qui tombe pendant une heure \u2014 vous \u00eates le seul \u00e0 en souffrir, vous perdez des commandes, vous perdez des clients, mais pour le client lui-m\u00eame \u2014 cela ne lui importe pas beaucoup. Il est bien s\u00fbr d\u00e9\u00e7u, mais il va et ach\u00e8te sur un autre site. En revanche, si c'est une application sur laquelle repose tout le travail de l'entreprise, la communication, les d\u00e9cisions, la chose la plus essentielle est de gagner la confiance des utilisateurs, c'est-\u00e0-dire de ne pas les d\u00e9cevoir et de ne pas tomber. Parce que tout le travail peut \u00eatre paralys\u00e9 si quelque chose \u00e0 l'int\u00e9rieur ne fonctionne pas.<\/p>\n
Bitrix24 en tant que SaaS<\/h4>\n \nNous avons assembl\u00e9 le premier prototype un an avant le lancement public, en 2011. Nous l'avons construit en environ une semaine, l'avons examin\u00e9 et test\u00e9 \u2014 il fonctionnait m\u00eame. Autrement dit, on pouvait acc\u00e9der au formulaire, y entrer le nom du portail, un nouveau portail se d\u00e9ployait, une base d'utilisateurs \u00e9tait cr\u00e9\u00e9e. Nous l'avons examin\u00e9, \u00e9valu\u00e9 le produit dans son ensemble, puis nous avons mis un an \u00e0 le peaufiner. Car nous avions un grand objectif : nous ne voulions pas cr\u00e9er deux bases de code distinctes, nous ne voulions pas maintenir un produit sur site s\u00e9par\u00e9ment des solutions cloud, \u2014 nous voulions faire tout cela dans le cadre d'un seul code. <\/p>\n
Nous avons formul\u00e9 les exigences : il s'agit de la capacit\u00e9 \u00e0 se d\u00e9ployer dans diff\u00e9rents emplacements, \u00e0 prendre en charge la r\u00e9plication, et id\u00e9alement \u00e0 \u00eatre r\u00e9parti dans diff\u00e9rents centres de donn\u00e9es g\u00e9ographiquement dispers\u00e9s. S\u00e9parer la logique du produit et, en propre, le stockage des donn\u00e9es. \u00catre capable de se mettre \u00e0 l'\u00e9chelle dynamiquement selon la charge, et m\u00eame sortir la partie statique. De ces consid\u00e9rations sont n\u00e9es les exigences du produit que nous avons finalement d\u00e9velopp\u00e9 tout au long de l'ann\u00e9e. Au cours de cette p\u00e9riode, dans la plateforme, qui est devenue unique \u2014 pour les solutions sur site, pour notre propre service \u2014 nous avons mis en place le support des \u00e9l\u00e9ments n\u00e9cessaires. Le support de la r\u00e9plication mysql au niveau m\u00eame du produit : c'est-\u00e0-dire que le d\u00e9veloppeur, qui \u00e9crit le code \u2014 ne doit pas se pr\u00e9occuper de la fa\u00e7on dont ses requ\u00eates sont r\u00e9parties, il utilise notre api, et nous savons bien r\u00e9partir les requ\u00eates d'\u00e9criture et de lecture entre les masters et les slaves. <\/p>\n
Nous avons mis en place un support au niveau du produit pour diff\u00e9rents syst\u00e8mes de stockage d'objets cloud : Google Storage, Amazon S3 \u2014 en plus, le support d'OpenStack Swift. Cela a donc \u00e9t\u00e9 pratique tant pour nous en tant que service, que pour les d\u00e9veloppeurs qui travaillent avec la solution sur site : s'ils utilisent simplement notre api pour travailler, ils ne se pr\u00e9occupent pas de l'endroit o\u00f9 le fichier final sera stock\u00e9, que ce soit localement sur le syst\u00e8me de fichiers ou s'il ira dans un stockage d'objets.<\/p>\n
Au final, nous avons imm\u00e9diatement d\u00e9cid\u00e9 de nous r\u00e9server au niveau d'un centre de donn\u00e9es entier. En 2012, nous avons enti\u00e8rement d\u00e9marr\u00e9 sur Amazon AWS, car nous avions d\u00e9j\u00e0 de l'exp\u00e9rience avec cette plateforme - notre propre site y \u00e9tait h\u00e9berg\u00e9. Ce qui nous attirait, c'\u00e9tait que dans chaque r\u00e9gion d'Amazon, il existe plusieurs zones de disponibilit\u00e9 - en gros, (dans leur terminologie) plusieurs centres de donn\u00e9es, qui sont plus ou moins ind\u00e9pendants les uns des autres et nous permettent de nous r\u00e9server au niveau d'un centre de donn\u00e9es entier : si celui-ci venait \u00e0 tomber en panne, les bases sont r\u00e9pliqu\u00e9es en master-master, les serveurs d'applications web sont r\u00e9serv\u00e9s, et la partie statique est stock\u00e9e dans un espace de stockage objet s3. La charge est \u00e9quilibr\u00e9e - \u00e0 l'\u00e9poque, c'\u00e9tait avec l'elb d'Amazon, mais un peu plus tard, nous sommes pass\u00e9s \u00e0 nos propres \u00e9quilibreurs de charge, car nous avions besoin d'une logique plus complexe. <\/p>\n
Ce que nous voulions, nous l'avons eu...<\/h4>\n \nToutes les choses de base que nous voulions assurer - la r\u00e9silience des serveurs eux-m\u00eames, des applications web, des bases de donn\u00e9es - tout fonctionnait bien. Le sc\u00e9nario le plus simple : si l'une de nos applications web tombe en panne, tout est simple - elles sont retir\u00e9es de l'\u00e9quilibrage. <\/p>\n
Nous travaillons partout dans le monde, les pics de charge des clients sont absolument diff\u00e9rents, et, en toute honn\u00eatet\u00e9, nous devons avoir la possibilit\u00e9 d'effectuer des op\u00e9rations de maintenance sur n'importe quel composant de notre syst\u00e8me \u00e0 tout moment - sans que les clients ne s'en aper\u00e7oivent. C'est pourquoi nous avons la possibilit\u00e9 de mettre hors ligne la base de donn\u00e9es, tout en redistribuant la charge sur le deuxi\u00e8me centre de donn\u00e9es. <\/p>\n
Comment tout cela fonctionne-t-il ? \u2014 Nous redirigeons le trafic vers un centre de donn\u00e9es op\u00e9rationnel : si c'est une d\u00e9faillance du centre de donn\u00e9es, cela se fait enti\u00e8rement ; si ce sont nos travaux planifi\u00e9s sur une base particuli\u00e8re, nous redirigeons une partie du trafic de ces clients vers le second centre de donn\u00e9es, tout en suspendant la r\u00e9plication. Si de nouvelles machines sont n\u00e9cessaires pour les applications web en raison de l'augmentation de la charge sur le deuxi\u00e8me centre de donn\u00e9es, elles d\u00e9marrent automatiquement. Les travaux sont termin\u00e9s, la r\u00e9plication est r\u00e9tablie et nous ramenons toute la charge. Si nous devons effectuer des travaux simultan\u00e9s dans le deuxi\u00e8me DC, par exemple, installer des mises \u00e0 jour syst\u00e8me ou modifier les param\u00e8tres dans la deuxi\u00e8me base de donn\u00e9es, nous faisons essentiellement la m\u00eame chose, mais dans l'autre sens. En cas de d\u00e9faillance, nous agissons simplement : dans le syst\u00e8me de surveillance, nous utilisons le m\u00e9canisme des event-handlers. Si plusieurs v\u00e9rifications \u00e9chouent et que le statut passe \u00e0 critique, ce handler s'active, celui qui peut ex\u00e9cuter une logique sp\u00e9cifique. Pour chaque base, nous avons sp\u00e9cifi\u00e9 quel serveur est le failover pour elle, et o\u00f9 rediriger le trafic en cas d'indisponibilit\u00e9. Nous avons, par tradition, utilis\u00e9 Nagios ou ses variantes. En principe, de tels m\u00e9canismes existent dans presque tous les syst\u00e8mes de surveillance ; pour l'instant, nous n'utilisons rien de plus complexe, mais cela pourrait \u00e9voluer un jour. Actuellement, la surveillance se d\u00e9clenche en cas d'indisponibilit\u00e9 et peut rediriger quelque chose.<\/p>\n
Avons-nous tout r\u00e9serv\u00e9 ?<\/h4>\n \nNous avons de nombreux clients aux \u00c9tats-Unis, beaucoup de clients en Europe, et beaucoup de clients plus proches de l'Est \u2014 au Japon, \u00e0 Singapour, etc. Bien s\u00fbr, une grande part des clients se trouve en Russie. Cela signifie que nous travaillons dans plusieurs r\u00e9gions. Les utilisateurs souhaitent une r\u00e9ponse rapide, il y a des exigences en mati\u00e8re de conformit\u00e9 avec diverses lois locales, et dans chaque r\u00e9gion, nous pr\u00e9voyons deux centres de donn\u00e9es, ainsi que d'autres services qui, encore une fois, sont pratiques \u00e0 placer au sein d'une m\u00eame r\u00e9gion \u2014 pour les clients qui exercent leurs activit\u00e9s dans cette r\u00e9gion. Les gestionnaires REST et les serveurs d'autorisation sont moins critiques pour le fonctionnement global du client, il est donc possible de basculer avec un l\u00e9ger d\u00e9lai acceptable. Cependant, nous ne voulons pas r\u00e9inventer la roue concernant leur surveillance et leur gestion. C'est pourquoi nous essayons d'utiliser au maximum les solutions existantes, au lieu de d\u00e9velopper une certaine expertise en produits suppl\u00e9mentaires. Nous utilisons parfois simplement un basculement au niveau DNS, et nous d\u00e9terminons la disponibilit\u00e9 du service avec le m\u00eame DNS. Amazon dispose d'un service appel\u00e9 Route 53, mais ce n'est pas simplement un DNS o\u00f9 l'on peut entrer des enregistrements \u2014 il est beaucoup plus flexible et pratique. Gr\u00e2ce \u00e0 lui, vous pouvez cr\u00e9er des services g\u00e9o-distribu\u00e9s avec g\u00e9olocalisation, o\u00f9 vous d\u00e9finissez d'o\u00f9 provient le client et lui fournissez les enregistrements appropri\u00e9s \u2014 cela permet de construire des architectures de basculement. Les m\u00eames v\u00e9rifications de l'\u00e9tat peuvent \u00eatre configur\u00e9es directement dans Route 53 : vous d\u00e9finissez les points de terminaison \u00e0 surveiller, les m\u00e9triques, et les protocoles \u00e0 utiliser pour d\u00e9terminer la \u00ab disponibilit\u00e9 \u00bb du service \u2014 TCP, HTTP, HTTPS ; vous sp\u00e9cifiez la fr\u00e9quence des v\u00e9rifications qui d\u00e9termineront si le service est en ligne ou non. Et dans le DNS, vous indiquez ce qui sera primaire, ce qui sera secondaire, o\u00f9 basculer en cas de d\u00e9faillance lors des v\u00e9rifications de sant\u00e9 dans Route 53. Tout cela peut \u00eatre fait avec d'autres outils, mais ce qui est pratique, c'est qu'une fois configur\u00e9, vous n'avez plus besoin de vous soucier des v\u00e9rifications ou des basculements : tout fonctionne de mani\u00e8re autonome.<\/p>\n
Le premier \u00ab mais \u00bb<\/b>: comment et avec quoi sauvegarder le route 53 ? Qui sait, si jamais quelque chose lui arrive ? Heureusement, nous n'avons jamais eu ce probl\u00e8me, mais encore une fois, je vais expliquer pourquoi nous avons pens\u00e9 qu'il \u00e9tait n\u00e9cessaire de faire une sauvegarde. Ici, nous pr\u00e9voyons les choses \u00e0 l'avance. Plusieurs fois par jour, nous effectuons une extraction compl\u00e8te de toutes les zones que nous avons dans le route 53. L'API d'Amazon permet de les obtenir facilement en JSON, et nous avons plusieurs serveurs de sauvegarde sur lesquels nous les convertissons et les exportons sous forme de configurations, ce qui nous donne, disons, une configuration de sauvegarde. En cas de besoin, nous pouvons rapidement la d\u00e9ployer manuellement et ne perdons pas les donn\u00e9es de configuration DNS.<\/p>\n
Deuxi\u00e8me \u00ab mais \u00bb<\/b>: qu'est-ce qui n'est pas encore sauvegard\u00e9 dans cette image ? L'\u00e9quilibreur de charge lui-m\u00eame ! La r\u00e9partition des clients par r\u00e9gion est faite de mani\u00e8re tr\u00e8s simple. Nous avons des domaines bitrix24.ru, bitrix24.com, .de \u2014 actuellement, il y en a environ 13 diff\u00e9rents qui fonctionnent dans diverses zones. Nous en sommes arriv\u00e9s \u00e0 la conclusion suivante : dans chaque r\u00e9gion, il y a ses propres \u00e9quilibreurs de charge. C'est plus simple de r\u00e9partir par r\u00e9gion, en fonction de la charge r\u00e9seau maximale. Si une d\u00e9faillance se produit au niveau d'un seul \u00e9quilibreur de charge, il est simplement mis hors service et retir\u00e9 du DNS. En cas de probl\u00e8me avec un groupe d'\u00e9quilibreurs de charge, ils sont sauvegard\u00e9s sur d'autres sites, et la bascule entre eux se fait gr\u00e2ce \u00e0 la m\u00eame route53, car avec un TTL court, le basculement se produit au maximum en 2, 3, 5 minutes. <\/p>\n
Troisi\u00e8me \u00ab mais \u00bb<\/b>: qu'est-ce qui n'est pas encore sauvegard\u00e9 ? S3, c'est vrai. En h\u00e9bergeant les fichiers que nous stockons chez les utilisateurs dans S3, nous croyions sinc\u00e8rement qu'il \u00e9tait infaillible et qu'il n'\u00e9tait pas n\u00e9cessaire de rien sauvegarder l\u00e0-dedans. Mais l'histoire montre que cela se passe diff\u00e9remment. En fait, Amazon d\u00e9crit S3 comme un service fondamental, car Amazon lui-m\u00eame utilise S3 pour stocker des images de machines, des configurations, des AMI, des snapshots\u2026 Et si S3 tombe, comme cela s'est d\u00e9j\u00e0 produit au cours de ces 7 ans o\u00f9 nous exploitons bitrix24, cela entra\u00eene une multitude de probl\u00e8mes \u2014 l'impossibilit\u00e9 de d\u00e9marrer des machines virtuelles, des pannes dans le fonctionnement de l'API, etc. <\/p>\n
Un incident avec S3 peut arriver \u2014 cela s'est d\u00e9j\u00e0 produit. C'est pourquoi nous avons d\u00e9cid\u00e9 de suivre la d\u00e9marche suivante : il y a quelques ann\u00e9es, il n'y avait pas de solutions de stockage objet publiques s\u00e9rieuses en Russie, et nous envisagions de cr\u00e9er quelque chose de notre propre initiative\u2026 Heureusement, nous ne l'avons pas fait, car nous aurions \u00e9t\u00e9 perdus dans une expertise que nous ne ma\u00eetrisons pas, et nous aurions certainement commis des erreurs. Aujourd'hui, des solutions de stockage compatibles avec S3 existent chez Mail.ru, Yandex et d'autres fournisseurs. Nous en sommes venus \u00e0 la conclusion que nous souhaitons avoir, d'une part, une redondance, et d'autre part, la possibilit\u00e9 de travailler avec des copies locales. Pour la r\u00e9gion sp\u00e9cifiquement russe, nous utilisons le service Mail.ru Hotbox, qui est compatible avec S3 via une API. Nous n'avons pas eu besoin d'apporter des modifications majeures au code de l'application, et nous avons mis en place le m\u00e9canisme suivant : S3 dispose de d\u00e9clencheurs qui s'activent lors de la cr\u00e9ation ou de la suppression d'objets, et Amazon propose un service appel\u00e9 Lambda \u2014 cela permet d'ex\u00e9cuter du code en mode serverless, qui s'ex\u00e9cutera lors des d\u00e9clenchements de ces \u00e9v\u00e9nements.<\/p>\n
Au niveau du code, nous d\u00e9finissons pour chaque client les deux stockages : l'un est consid\u00e9r\u00e9 comme principal, l'autre comme de sauvegarde. Si tout fonctionne bien, nous travaillons avec le stockage le plus proche de nous : c'est-\u00e0-dire que nos clients qui sont chez Amazon utilisent S3, tandis que ceux qui op\u00e8rent en Russie utilisent Hotbox. Si un drapeau est activ\u00e9, un failover doit se connecter et nous redirigeons les clients vers un autre stockage. Nous pouvons fixer ce drapeau ind\u00e9pendamment par r\u00e9gions et les basculer. En pratique, nous ne l'avons pas encore utilis\u00e9, mais ce m\u00e9canisme est pr\u00e9vu et nous pensons que lorsque ce besoin de basculement se pr\u00e9sentera, il sera utile. Cela nous est d\u00e9j\u00e0 arriv\u00e9 une fois. <\/p>\n
Oh, Amazon vous a l\u00e2ch\u00e9s...<\/h4>\n \nCe mois d'avril marque l'anniversaire du d\u00e9but des blocages de Telegram en Russie. Le fournisseur le plus touch\u00e9 par cela est Amazon. Malheureusement, ce sont les entreprises russes qui ont le plus souffert, celles qui op\u00e9raient \u00e0 l'\u00e9chelle mondiale. <\/p>\n
Si l'entreprise est mondiale et que la Russie repr\u00e9sente un tr\u00e8s petit segment pour elle, 3-5% - il est possible, d'une mani\u00e8re ou d'une autre, de faire des sacrifices. <\/p>\n
Si c'est une entreprise purement russe, je suis convaincu qu'il faut s'installer localement - c'est juste plus pratique et confortable pour les utilisateurs, le risque sera plus faible. <\/p>\n
Et si c'est une entreprise qui op\u00e8re \u00e0 l'\u00e9chelle mondiale, avec \u00e0 peu pr\u00e8s autant de clients en Russie que dans le reste du monde ? La connectivit\u00e9 des segments est importante, et ils doivent interagir d'une mani\u00e8re ou d'une autre. <\/p>\n
Fin mars 2018, le Roskomnadzor a envoy\u00e9 une lettre aux plus grands op\u00e9rateurs, annon\u00e7ant leur intention de bloquer plusieurs millions d'IP d'Amazon pour bloquer... le messager Zello. Merci \u00e0 ces m\u00eames fournisseurs - ils ont r\u00e9ussi \u00e0 faire fuiter la lettre, et il est devenu clair que la connectivit\u00e9 avec Amazon pourrait s'effondrer. C'\u00e9tait un vendredi, nous avons paniqu\u00e9 et nous sommes dirig\u00e9s vers nos coll\u00e8gues de servers.ru, en leur disant : \u00ab Les amis, nous avons besoin de plusieurs serveurs qui ne seront pas en Russie, ni chez Amazon, mais par exemple, quelque part \u00e0 Amsterdam \u00bb, pour pouvoir mettre en place nos propres serveurs d'une mani\u00e8re ou d'une autre. vpn<\/a> et un proxy pour certains endpoints sur lesquels nous n'avons aucune influence, comme les endpoints de s3 \u2014 il est impossible de tenter de mettre en place un nouveau service et d'obtenir une autre adresse IP, nous devons quand m\u00eame y acc\u00e9der. En quelques jours, nous avons configur\u00e9 ces serveurs, les avons mis en place, et au moment o\u00f9 les blocages ont commenc\u00e9, nous \u00e9tions pr\u00eats. Fait int\u00e9ressant, le Roskomnadzor, apr\u00e8s avoir vu tout le brouhaha et la panique soulev\u00e9e, a d\u00e9clar\u00e9 : \u00ab Non, nous n'allons rien bloquer pour le moment \u00bb. (Mais c'\u00e9tait jusqu'\u00e0 ce qu'ils commencent \u00e0 bloquer Telegram.) En ayant configur\u00e9 les moyens de contournement et en comprenant que le blocage n'avait pas \u00e9t\u00e9 mis en place, nous n'avons cependant pas d\u00e9mont\u00e9 tout cela. Juste au cas o\u00f9. <\/p>\n
Et comment assurer la redondance... d'un fournisseur entier ?<\/h4>\n \nActuellement, nous n'avons pas de sc\u00e9nario en cas de d\u00e9faillance compl\u00e8te d'Amazon. Nous avons un sc\u00e9nario similaire pour la Russie. Nous \u00e9tions h\u00e9berg\u00e9s en Russie par un fournisseur, chez qui nous avions choisi d'avoir plusieurs sites. Il y a un an, nous avons rencontr\u00e9 un probl\u00e8me : m\u00eame si ce sont deux centres de donn\u00e9es, il peut y avoir des probl\u00e8mes au niveau de la configuration r\u00e9seau du fournisseur qui impacteront tout de m\u00eame les deux centres. Nous pouvons avoir des interruptions sur les deux sites. Bien s\u00fbr, cela s'est produit. Nous avons finalement r\u00e9vis\u00e9 notre architecture interne. Elle n'a pas beaucoup chang\u00e9, mais pour la Russie, nous avons maintenant deux sites, qui ne sont pas h\u00e9berg\u00e9s par un seul fournisseur, mais par deux diff\u00e9rents. Si une chose tombe en panne chez l'un, nous pouvons nous rediriger vers l'autre.<\/p>\n
Hypoth\u00e9tiquement, nous envisageons pour Amazon la possibilit\u00e9 de faire de la r\u00e9servation au niveau d'un autre fournisseur ; peut-\u00eatre Google, ou peut-\u00eatre quelqu'un d'autre... Mais jusqu'\u00e0 pr\u00e9sent, nous avons observ\u00e9 dans la pratique que lorsqu'il y a des pannes chez Amazon au niveau d'une zone de disponibilit\u00e9, des pannes touchant tout un r\u00e9gion sont des \u00e9v\u00e9nements assez rares. Par cons\u00e9quent, nous avons une id\u00e9e th\u00e9orique de ce que nous pourrions faire en r\u00e9servant \"Amazon - pas Amazon\", mais pour l'instant, cela n'existe pas en pratique. <\/p>\n
Quelques mots sur l'automatisation<\/h4>\n \nL'automatisation est-elle toujours n\u00e9cessaire ? Il convient de rappeler ici l'effet Dunning-Kruger. Sur l'axe \u00ab x \u00bb, nos connaissances et exp\u00e9riences que nous acqu\u00e9rons, et sur l'axe \u00ab y \u00bb \u2014 notre confiance dans nos actions. Au d\u00e9but, nous ne savons rien et nous ne sommes pas du tout confiants. Ensuite, nous savons un peu et devenons m\u00e9ga-confiants \u2014 c'est ce qu'on appelle le \u00ab pic de la b\u00eatise \u00bb, bien illustr\u00e9 par l'image \u00ab l'ignorance et le courage \u00bb. Ensuite, nous avons un peu appris et sommes pr\u00eats \u00e0 entrer dans la bataille. Puis nous tr\u00e9buchons sur des pi\u00e8ges s\u00e9rieux, nous entrons dans la vall\u00e9e du d\u00e9sespoir, o\u00f9 nous croyons savoir quelque chose, mais en r\u00e9alit\u00e9 nous ignorons beaucoup de choses. Ensuite, au fur et \u00e0 mesure que nous acqu\u00e9rons de l'exp\u00e9rience, nous gagnons en confiance.<\/p>\n
Conclusion<\/h4>\n \nEn 7 ans, nous sommes pass\u00e9s de la panique totale \u00e0 la compr\u00e9hension qu'il n'y a pas de probl\u00e8mes, mais seulement des t\u00e2ches \u00e0 r\u00e9soudre. Lorsque vous construisez un service, regardez-le d'un point de vue global, \u00e9valuez tous les risques qui peuvent survenir. Si vous les voyez tout de suite, anticipez les options de redondance et la possibilit\u00e9 de construire une infrastructure r\u00e9siliente, car tout point pouvant tomber en panne et rendre le service inutilisable le fera n\u00e9cessairement. Et m\u00eame si vous pensez que certains \u00e9l\u00e9ments de l'infrastructure ne tomberont pas en panne \u2014 comme le s3, gardez \u00e0 l'esprit qu'ils pourraient le faire. Ayez au moins une id\u00e9e th\u00e9orique sur ce que vous ferez avec eux si quelque chose se produit. Ayez un plan pour g\u00e9rer les risques. Lorsque vous envisagez de tout faire automatiquement ou manuellement, \u00e9valuez les risques : que se passera-t-il si l'automatisation commence \u00e0 tout basculer \u2014 cela ne conduira-t-il pas \u00e0 une situation encore pire qu'une panne ? Peut-\u00eatre qu'il faut parfois trouver un compromis raisonnable entre l'utilisation de l'automatisation et la r\u00e9action d'un ing\u00e9nieur de garde, qui \u00e9valuera la situation r\u00e9elle et d\u00e9cidera s'il faut basculer quelque chose imm\u00e9diatement ou<\/p>\n
Un compromis raisonnable entre le perfectionnisme et les ressources r\u00e9elles, le temps, l'argent que vous pouvez consacrer au sch\u00e9ma que vous aurez finalement.<\/p>\n
Ce texte est une version augment\u00e9e et \u00e9tendue du rapport d'Alexandre Demidov lors de la conf\u00e9rence. Uptime jour 4<\/a><\/noindex>.<\/i> habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u041d\u0430 \u0441\u0435\u0433\u043e\u0434\u043d\u044f\u0448\u043d\u0438\u0439 \u0434\u0435\u043d\u044c \u0443 \u0441\u0435\u0440\u0432\u0438\u0441\u0430 \u00ab\u0411\u0438\u0442\u0440\u0438\u043a\u044124\u00bb \u043d\u0435\u0442 \u0441\u043e\u0442\u0435\u043d \u0433\u0438\u0433\u0430\u0431\u0438\u0442 \u0442\u0440\u0430\u0444\u0438\u043a\u0430, \u043d\u0435\u0442 \u043e\u0433\u0440\u043e\u043c\u043d\u043e\u0433\u043e \u043f\u0430\u0440\u043a\u0430 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432 (\u0445\u043e\u0442\u044f \u0438 \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u0445, \u043a\u043e\u043d\u0435\u0447\u043d\u043e, \u043d\u0435\u043c\u0430\u043b\u043e). \u041d\u043e \u0434\u043b\u044f \u043c\u043d\u043e\u0433\u0438\u0445 \u043a\u043b\u0438\u0435\u043d\u0442\u043e\u0432 \u043e\u043d \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u043e\u0441\u043d\u043e\u0432\u043d\u044b\u043c \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u043e\u043c \u0440\u0430\u0431\u043e\u0442\u044b \u0432 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438, \u044d\u0442\u043e \u043d\u0430\u0441\u0442\u043e\u044f\u0449\u0435\u0435 business-critical \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435. \u041f\u043e\u044d\u0442\u043e\u043c\u0443 \u043f\u0430\u0434\u0430\u0442\u044c \u2014 \u043d\u0443, \u043d\u0438\u043a\u0430\u043a \u043d\u0435\u043b\u044c\u0437\u044f. \u0410 \u0447\u0442\u043e \u0435\u0441\u043b\u0438 \u043f\u0430\u0434\u0435\u043d\u0438\u0435 \u0432\u0441\u0435-\u0442\u0430\u043a\u0438 \u0441\u043b\u0443\u0447\u0438\u043b\u043e\u0441\u044c, \u043d\u043e \u00ab\u0432\u043e\u0441\u0441\u0442\u0430\u043b\u00bb \u0441\u0435\u0440\u0432\u0438\u0441 \u0442\u0430\u043a \u0431\u044b\u0441\u0442\u0440\u043e, \u0447\u0442\u043e \u043d\u0438\u043a\u0442\u043e \u043d\u0438\u0447\u0435\u0433\u043e \u0438 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":26389,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-35092","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"\u00abBitrix24\u00bb:](\"\/wp-content\/uploads\/2019\/06\/973fa076fc654237aa869d0ecb0dae9a.jpeg\")