En été, à la fois l'activité d'achat et l'intensité des changements dans l'infrastructure des projets Web diminuent traditionnellement, nous dit Captain Evidence. Tout simplement parce que même les informaticiens se rendent en vacances. Et CTO aussi. C'est d'autant plus difficile pour ceux qui restent en fonction, mais pas à ce sujet maintenant: c'est peut-être pourquoi l'été est le meilleur moment pour se précipiter à travers le système de réservation existant et faire un plan pour son amélioration. Et en cela, vous bénéficierez de l'expérience de Yegor Andreev d' AdminDivision , dont il a parlé lors de la conférence Uptime Day .Lors de la construction des sites de réserve, lors de la réservation il y a plusieurs pièges dans lesquels vous pouvez tomber. Et y tomber est absolument impossible. Et nous ruiner dans tout cela, ainsi que dans bien d'autres choses, le perfectionnisme et ... la paresse. Nous essayons de tout faire, tout, tout est parfait, mais vous n’avez pas à le faire parfaitement! Il suffit de faire certaines choses, mais de les faire correctement, de les mener à terme, pour qu'elles fonctionnent normalement.
Le basculement n'est pas une sorte d'amusement «amusant à avoir»; c'est une chose qui devrait faire exactement une chose - réduire les temps d'arrêt afin que le service, l'entreprise, perde moins d'argent. Et dans toutes les méthodes de réservation, je suggère de penser dans le contexte suivant: où est l'argent?
Premier piège : lorsque nous construisons de grands systèmes fiables et effectuons des sauvegardes, nous réduisons le nombre d'accidents. C'est une erreur fallacieuse. Lorsque nous effectuons des sauvegardes, nous augmentons très probablement le nombre d'accidents. Et si nous faisons tout correctement, alors ensemble, nous réduirons les temps d'arrêt. Il y aura plus d'accidents, mais ils se produiront à moindre coût. Après tout, qu'est-ce que la redondance? Est une complication du système. Toute complication est mauvaise: nous obtenons plus de rouages, plus de vitesses, en un mot, plus d'éléments - et, par conséquent, un risque de panne plus élevé. Et ils se cassent vraiment. Et ils se briseront plus souvent. Un exemple simple: disons que nous avons un site Web avec PHP, MySQL. Et il a un besoin urgent d'être réservé.
Shtosh (c) Nous prenons le deuxième site, nous construisons un système identique ... La complexité devient deux fois plus grande - nous avons deux entités. Et nous roulons également une certaine logique de transfert de données d'une plate-forme à une autre par le haut - c'est-à-dire la réplication de données, la copie de statiques, etc. Ainsi, la logique de réplication est généralement très complexe, et par conséquent, la complexité totale du système peut ne pas être 2, mais 3, 5, 10 fois plus.
Le deuxième piège : lorsque nous construisons de véritables systèmes complexes, nous fantasmons sur ce que nous voulons obtenir au final. Voila: nous voulons obtenir un système super fiable qui fonctionne sans temps d'arrêt, passe en une demi-seconde (ou mieux en général instantanément), et commence à réaliser les rêves. Mais il y a aussi une nuance: plus le temps de commutation souhaité est court, plus la logique du système est complexe. Plus il nous sera difficile de faire cette logique, plus souvent le système se brisera. Et vous pouvez vous retrouver dans une situation très désagréable: nous faisons de notre mieux pour réduire les temps d'arrêt, mais en fait nous compliquons les choses, et en cas de problème, le temps d'arrêt sera plus long. Ici, vous vous surprenez souvent à penser: ici ... ce serait mieux s'ils n'avaient pas été réservés. Il serait préférable que cela fonctionne seul avec un temps d'arrêt compréhensible.
Comment y faire face? Nous devons cesser de nous mentir, cesser de nous flatter que nous allons construire un vaisseau spatial ici, mais pour bien comprendre à quel point le projet peut se coucher. Et pour ce temps maximum, nous choisirons avec quelles méthodes, en fait, nous augmenterons la fiabilité de notre système.
Il est temps pour les "histoires de w" ... de la vie, bien sûr.
Exemple numéro un
Imaginez la carte de site de l'usine de laminage de tuyaux n ° 1 de la ville N. Elle est écrite en grosses lettres dessus - USINE DE PIPELINE N ° 1. Un peu plus bas - le slogan: "Nos pipes sont les pipes les plus rondes en N". Et sous le numéro de téléphone du PDG et son nom. Nous comprenons que vous devez réserver - c'est une chose très importante! Nous commençons à comprendre de quoi il s'agit. Html-statics - c'est-à-dire quelques photos où le général, en fait, à la table du bain avec son partenaire discute d'un prochain accord. Nous commençons à penser aux temps d'arrêt. Cela me vient à l'esprit: vous devez rester allongé pendant cinq minutes, pas plus. Et puis la question est: combien de ventes de ce site étaient en général? Combien combien? Que signifie zéro? Et cela signifie: parce que le général a effectué les quatre transactions au cours de l'année écoulée à la même table, avec les mêmes personnes avec lesquelles ils vont aux bains assis à la table. Et nous comprenons que même si le site se couche pendant une journée, il n'y aura rien de terrible.
Sur la base de l'introduction, il y a un jour pour soulever cette histoire. Nous commençons à penser au schéma de sauvegarde. Et nous sélectionnons le schéma de sauvegarde le plus idéal pour cet exemple: nous n'utilisons pas de redondance. Tout cela monte par n'importe quel administrateur pendant une demi-heure avec des pauses de fumée. Mettre un serveur web, mettre des fichiers, c'est tout. Ça va marcher. Vous n'avez rien à suivre, vous n'avez pas besoin d'accorder une attention particulière à quoi que ce soit. Autrement dit, la conclusion de l'exemple numéro un est assez évidente: les services que vous n'avez pas besoin de réserver ne sont pas nécessaires.
Exemple numéro deux
Blog de l'entreprise: des personnes spécialement formées y écrivent des nouvelles, nous avons donc participé à telle ou telle exposition, mais ici nous avons sorti un autre nouveau produit et ainsi de suite. Disons que c'est PHP standard avec WordPress, une petite base de données et un peu de statique. Bien sûr, je me rappelle encore une fois que vous ne devez jamais mentir - "pas plus de cinq minutes!", C'est tout. Mais réfléchissons plus loin. Que fait ce blog? Ils viennent de Yandex, de Google sur certaines demandes, de produits biologiques. Ouah. Et les ventes sont-elles liées à lui? Perspicacité: pas vraiment. Le trafic publicitaire est dirigé vers le site principal, qui se trouve sur une autre machine. Nous commençons à penser au schéma de réservation des livrets. Dans le bon sens, il doit être levé en quelques heures, et ce serait bien de s'y préparer. Il serait raisonnable de prendre une machine dans un autre centre de données, d'y conduire l'environnement, c'est-à-dire un serveur Web, PHP, WordPress, MySQL et de le laisser couché. Au moment où nous comprenons que tout est cassé, deux choses doivent être faites - rouler le dump mysql à 50 mètres, il y volera dans une minute, et roulera un certain nombre d'images de la sauvegarde là-bas. Ce n'est pas là non plus une bonne nouvelle. Ainsi, en une demi-heure, tout cela monte. Aucune réplication, ou Dieu me pardonne, basculement automatique. Conclusion: ce que nous pouvons rapidement déployer de la sauvegarde n'est pas nécessaire de réserver.
Exemple numéro trois, plus compliqué
Boutique en ligne. PhP à cœur ouvert est un peu déposé, mysql avec une base solide. Beaucoup de statique (après tout, la boutique en ligne a de belles images HD et tout ce jazz), Redis pour la session et Elasticsearch pour la recherche. Nous commençons à penser aux temps d'arrêt. Et ici, bien sûr, il est évident qu'une boutique en ligne ne peut pas se vautrer sans douleur. Après tout, plus il s'allonge, plus nous perdons d'argent. Cela vaut la peine d’accélérer. Combien? Je crois que si on se couche pendant une heure, personne ne deviendra fou. Oui, nous allons perdre quelque chose, mais si nous commençons à zeler, cela ne fera qu'empirer. Nous déterminons le temps d'inactivité autorisé par heure.
Comment réserver tout cela? Une machine est nécessaire dans tous les cas: une heure de temps, c'est beaucoup. Mysql: réplication, la réplication en direct est déjà nécessaire ici, car dans une heure, 100 Go dans un vidage, très probablement, ne seront pas versés. Statique, images: encore une fois, dans une heure, 500 Go peuvent ne pas avoir le temps de fusionner. Par conséquent, il est préférable de copier immédiatement les photos. Redis: plus intéressant ici. Les sessions sont à Redis - nous ne pouvons tout simplement pas le prendre et l'enterrer. Parce que ce ne sera pas très bien: tous les utilisateurs seront déconnectés, les paniers vidés et ainsi de suite. Les gens seront obligés de ressaisir leur nom d'utilisateur et leur mot de passe, et de nombreuses personnes pourraient se séparer et ne pas terminer l'achat. Encore une fois, la conversion va tomber. D'autre part, Redis est directement un à un pertinent, avec les derniers utilisateurs connectés, probablement, n'est également pas nécessaire. Et un bon compromis est de prendre Redis et de le restaurer à partir d'une sauvegarde hier, ou, si vous le faites toutes les heures, - il y a une heure. L'avantage de le restaurer à partir de la sauvegarde est de copier un fichier. Et l'histoire la plus intéressante est Elasticsearch. Qui a déjà lancé la réplication MySQL? Qui a déjà lancé la réplication Elasticsearch? Et avec qui travaillait-elle normalement? Qu'est-ce que je fais: nous voyons une certaine entité dans notre système. Cela semble utile - mais c'est compliqué.
Complexe dans le sens où nos collègues ingénieurs n'ont aucune expérience de travail avec. Ou il y a une expérience négative. Ou nous comprenons que jusqu'à présent, il s'agit d'une technologie assez nouvelle avec des nuances ou de l'humidité. Nous pensons ... Merde, l'élastique est également sain, il faut aussi beaucoup de temps pour le restaurer à partir d'une sauvegarde, que dois-je faire? Nous comprenons que l'élastique dans notre cas est utilisé pour la recherche. Et comment se vend notre boutique en ligne? Nous allons chez les commerçants, demandons d'où viennent les gens. Ils répondent: "90% du marché Yandex vient directement de la fiche produit." Et acheter ou non. Par conséquent, 10% des utilisateurs ont besoin d'une recherche. Et pour conserver une réplication élastique, en particulier entre différents centres de données dans différentes zones, il y a vraiment beaucoup de nuances. Quelle est la sortie? Nous prenons l'élastique sur un site réservé et n'en faisons rien. Si l'affaire traîne en longueur, un jour nous la relèverons probablement, mais ce n'est pas certain. En fait, la conclusion plus ou moins est la même: nous, encore une fois, nous ne réservons pas des services qui n'affectent pas l'argent. Pour garder le circuit plus simple.
Exemple numéro quatre, encore plus difficile
Intégrateur: vendre des fleurs, appeler un taxi, vendre des marchandises, en général, n'importe quoi. Une chose sérieuse qui fonctionne 24/7 pour un grand nombre d'utilisateurs. Avec une pile intéressante à part entière, où il y a des bases intéressantes, des solutions, une charge élevée, et surtout, cela lui fait mal de mentir plus de 5 minutes. Non seulement et pas tant parce que les gens n'achèteront pas, mais parce que les gens verront que cette chose ne fonctionne pas, ils seront bouleversés et ne reviendront peut-être pas pour la deuxième fois.
Ok Cinq minutes. Qu'allons-nous en faire? Dans ce cas, nous sommes de manière adulte, avec tout l'argent, nous construisons un vrai site de sauvegarde, avec la réplication de tout et de tout, et peut-être même d'automatiser le passage maximum à ce site. Et en plus de cela, il ne faut pas oublier de faire une chose importante: en fait, écrire le calendrier de commutation. Les réglementations, même si vous avez tout automatisé, peuvent être très simples. De la série «exécuter tel ou tel script ansible», «cliquer tel ou tel daw sur la route 53» et ainsi de suite - mais cela devrait être une liste exacte d'actions.
Et tout semble clair. La commutation de la réplication est une tâche triviale, ou elle se changera d'elle-même. Réécrivez un nom de domaine en DNS - de la même série. Le problème est que lorsqu'un projet similaire se bloque, la panique commence et même les administrateurs barbus les plus puissants peuvent y être sujets. Sans instruction claire «ouvrez un terminal, allez ici, l'adresse sur notre serveur est toujours comme ça», le terme de 5 minutes allouées à la réanimation est difficile à maintenir. De plus, lorsque nous utilisons ces réglementations, il est facile de corriger certains changements dans l'infrastructure, par exemple, et de modifier les réglementations en conséquence.
Eh bien, si le système de sauvegarde est très complexe et à un moment donné, nous avons fait une erreur, nous pouvons également mettre notre site de réserve et, en plus, transformer les données en citrouille sur les deux sites - ce sera vraiment triste.
Exemple numéro cinq, hardcore complet
Un service international avec des centaines de millions d'utilisateurs dans le monde. Tous les fuseaux horaires, qui n'existent que, à pleine charge à vitesse maximale, vous ne devriez pas mentir du tout. Une minute - et ce sera triste. Que faire Réserve, encore une fois, dans son intégralité. Ils ont fait tout ce qui était mentionné dans l'exemple précédent, et un peu plus. Un monde idéal, et notre infrastructure - c'est par tous les concepts de la devopa IaaC. Autrement dit, tout en général dans git, et cliquez simplement sur le bouton.
Qu'est-ce qui manque? L'un est les enseignements. Vous ne pouvez pas vous en passer. Il semble que tout soit parfait chez nous, tout est sous contrôle en général. On appuie sur le bouton, tout se passe. Même s'il en est ainsi - et nous comprenons que cela ne se produit pas - notre système interagit avec certains autres systèmes. Par exemple, ce sont les DNS de la route 53, le stockage s3, l'intégration avec certaines API. Nous ne pourrons pas tout prévoir dans cette expérience spéculative. Et tant que nous n'appuierons pas vraiment sur l'interrupteur, nous ne saurons pas si cela fonctionnera ou non.
C'est probablement tout. Ne soyez pas paresseux et n'en faites pas trop. Et que la disponibilité soit avec vous!