Get best of the week

Exploitation d'un grand système distribué: ce que j'ai appris



En lisant divers canaux et newsletters, je tombe souvent sur des articles sur des «douleurs» spécifiques et des problèmes qui surviennent lorsqu'une entreprise se développe, lorsque la fiabilité et l'évolutivité viennent au premier plan. Cet article est différent. Il n'y a pas d'analyse détaillée de solutions architecturales spécifiques ni de guide étape par étape pour changer la culture d'ingénierie. Il s'agit plutôt d'une vue de dessus des défis qui se posent lors de l'exploitation de systèmes distribués et d'un point de départ qui vous aidera à naviguer dans le flux de termes, d'abréviations et de technologies.

J'attire votre attention sur la traduction d'un article rédigé par un ingénieur d'Uber.

* * *

Au cours des dernières années, j'ai créé et maintenu un grand système de paiement distribué dans Uber . Pendant ce temps, j'ai beaucoup appris sur les concepts d'architectures distribuées.et de ma propre expérience, j'ai découvert à quel point il est difficile de créer et de maintenir des systèmes très chargés avec une haute disponibilité. Construire un tel système est un travail intéressant. J'aime planifier la façon dont le système gérera la croissance du trafic de 10 à 100 fois, afin d'assurer la fiabilité des données indépendamment des pannes matérielles. Cependant, l' exploitation d'un grand système distribué m'a donné une expérience inattendue .

Plus le système est grand, plus il est probable que vous rencontrerez une manifestation de la loi de Murphy: " Tout ce qui peut mal tourner va mal ." La probabilité est particulièrement élevée avec des versions fréquentes, lorsque de nombreux développeurs déploient du code, lorsqu'ils utilisent plusieurs centres de données et avec un large public d'utilisateurs à travers le monde. Au cours des dernières années, j'ai rencontré plusieurs pannes de système, dont beaucoup m'ont surpris: des problèmes prévisibles, tels que des pannes matérielles ou des bugs innocents, aux ruptures de câbles qui connectent les centres de données à de nombreux plantages en cascade qui se produisent simultanément. J'ai connu des dizaines d'échecs dans lesquels certaines parties du système ne fonctionnaient pas correctement, ce qui a grandement affecté l'entreprise.

Cet article résume les techniques qui ont bénéficié de l'exploitation d'un grand système dans Uber. Mon expérience n'est pas unique: d'autres travaillent avec des systèmes de même taille et vivent les mêmes aventures. J'ai parlé avec des ingénieurs de Google, Facebook et Netflix, qui ont fait face à des situations similaires et ont trouvé des solutions similaires. De nombreuses idées et processus décrits ici peuvent être appliqués à des systèmes de la même échelle, qu'ils fonctionnent dans des centres de données appartenant à l'entreprise (comme c'est le plus souvent le cas avec Uber) ou dans le cloud (où Uber évolue parfois ). Cependant, ces conseils peuvent être redondants pour des systèmes pas si importants ou importants pour l'entreprise.

Nous parlerons de ces sujets:

  • surveillance
  • Service (sur appel), détection et notification d'anomalies.
  • Gestion des pannes et des incidents.
  • Post mortem, analyse d'incidents et culture d'amélioration continue.
  • Basculement, planification des ressources et test de la boîte noire.
  • SLO, SLA et rapports sur eux.
  • SRE en équipe indépendante.
  • La fiabilité comme investissement permanent.
  • Matériaux utiles.

surveillance


Pour comprendre si le système est sain, nous devons répondre à la question: «Fonctionne-t- il correctement? ". Pour cela, il est essentiel de collecter des informations sur les parties critiques du système. Et lorsque vous avez des systèmes distribués comprenant divers services sur de nombreux serveurs et dans différents centres de données, il peut être difficile de décider quels points clés vous devez vraiment suivre.

Suivi de l'état des infrastructures.Si une ou plusieurs machines / machines virtuelles sont surchargées, certaines parties du système distribué peuvent dégrader les performances. Les métriques d'état des machines sur lesquelles le service s'exécute - la consommation de ressources processeur et de mémoire - ce sont les paramètres de base qui doivent être surveillés. Il existe des plates-formes qui suivent initialement ces mesures et mettent automatiquement à l'échelle les instances. Uber dispose d'une excellente équipe d'infrastructure de base qui, par défaut, assure la surveillance et les alertes. Quelle que soit la méthode d'implémentation, vous devez disposer d'informations indiquant que les instances, l'infrastructure ou les services individuels ont des problèmes.

Surveillance de l'état du service: trafic, erreurs, retard . Souvent, vous devez avoir la réponse à la question "Le backend fonctionne-t-il bien? ". La surveillance de métriques telles que la quantité de trafic entrant, la proportion d'erreurs et le retard de réponse fournit des informations précieuses sur l'état du service. Je préfère créer des tableaux de bord pour toutes ces mesures. Lorsque vous créez un nouveau service, l'utilisation des réponses HTTP correctes et la surveillance des codes correspondants peuvent en dire beaucoup sur l'état du système. Si vous êtes sûr que les codes 4xx sont retournés pour les erreurs du client et que les codes 5xx sont retournés pour les erreurs du serveur, il vous sera facile de créer et d'interpréter une telle surveillance.

Il y a autre chose à dire sur la surveillance des délais de réponse. L'objectif des services de production est que la plupart des utilisateurs finaux apprécient de les utiliser. Et mesurer le retard moyen n'est pas la meilleure solution, car la valeur moyenne peut masquer un petit nombre de demandes avec un retard important. Il est préférable de mesurer p95, p99 ou p999 - le délai pour le 95e, 99e ou 99,9e centile des demandes. Ces chiffres aident à répondre à des questions comme: «À quelle vitesse la demande sera-t-elle adressée à 99% des visiteurs?» "(P99) ou" Quelle sera la lenteur de la demande pour un visiteur sur 1000? "(P999). Si vous êtes intéressé par les détails, vous pouvez lire cet article .


Graphique pour p95 et p99. Notez que le délai moyen pour ce point de terminaison est inférieur à 1 seconde et 1% des demandes prend 2 secondes. et plus - cela ne se voit pas lors de la mesure de la valeur moyenne.

Le sujet de la surveillance et de l'observabilité est beaucoup plus profond. Je recommande de lire le livre Google SRE et la section Quatre signaux d'or sur la surveillance des systèmes distribués. Si pour un système avec lequel les utilisateurs interagissent, vous ne pouvez obtenir que quatre mesures, puis concentrez-vous sur le trafic, les erreurs, le retard et la saturation. Il y a moins de matériel - le livre électronique sur l' observabilité des systèmes distribués , qui décrit des outils utiles tels que les journaux, ainsi que les meilleures pratiques d'utilisation des métriques et du traçage.

Surveillance des mesures commerciales. Les services de surveillance nous renseignent sur leur état général. Mais d'après les seules données de surveillance, nous ne pouvons pas dire si les services fonctionnent correctement, si tout est correctement traité d'un point de vue commercial. Dans le cas du système de paiement, la question principale est: «Les gens peuvent-ils faire des voyages en utilisant un mode de paiement spécifique? ". L'une des étapes les plus importantes de la surveillance consiste à identifier et à suivre les événements commerciaux créés et traités par ce service.

Mon équipe a créé un suivi des métriques métier après une panne que nous n'avons pas pu détecter autrement. Tout semblait comme si les services fonctionnaient normalement, mais en fait la fonctionnalité clé ne fonctionnait pas. Ce type de suivi était très inhabituel pour notre entreprise et notre domaine d'activité. Par conséquent, nous avons dû faire beaucoup d'efforts pour configurer cette surveillance pour nous-mêmes, créant notre propre système .

Service, détection d'anomalies et alerte


La surveillance est un excellent outil pour vérifier l'état actuel du système. Mais ce n'est qu'une étape sur la route pour détecter automatiquement les défaillances et alerter ceux qui devraient faire quelque chose dans ce cas.

La montre est un vaste sujet. Increment Magazine a fait un excellent travail en soulignant bon nombre des problèmes du numéro sur appel . À mon avis, le devoir est une continuation logique de l'approche «vous avez créé - vous possédez». Les services appartiennent aux équipes qui les ont créés et possèdent également un système d'alerte et de réponse aux incidents. Mon équipe possédait un tel système pour le service de paiement que nous avons créé. Et lorsque l'alerte arrive, l'ingénieur de service doit répondre et savoir ce qui se passe. Mais comment passer de la surveillance aux alertes?

La détermination des anomalies sur la base des données de surveillance est une tâche difficile , et l'apprentissage automatique devrait se manifester pleinement ici. Il existe de nombreux services tiers pour détecter les anomalies. Heureusement pour mon équipe, notre entreprise a son propre groupe d'apprentissage automatique pour résoudre les problèmes auxquels Uber est confronté. L'équipe de New York a écrit un article utile sur le fonctionnement de la détection des anomalies par Uber . Du point de vue de mon équipe, nous ne transmettons que des données de surveillance à ce pipeline et recevons des alertes avec différents degrés de confiance. Et puis nous décidons d'en informer l'ingénieur.

Quand dois-je envoyer une alerte? La question est intéressante. S'il y a trop peu d'alertes, nous pouvons manquer un problème important. Si c'est trop, les gens ne dormiront pas la nuit.Le suivi et la catégorisation des alertes, ainsi que la mesure des rapports signal / bruit, jouent un rôle important dans la mise en place d'un système d'alerte . Une bonne étape vers une rotation régulière des ingénieurs en service consistera à analyser les alertes, à classer les événements comme «nécessitant une action» et «ne nécessitant pas», puis à réduire le nombre d'alertes qui ne nécessitent aucune action.


Un exemple de panneau Call Duty créé par l'équipe Uber Developer Experience à Vilnius.

L'équipe Uber pour la création d'outils de développement à partir de Vilnius a créé un petit outil que nous utilisons pour commenter les alertes et visualiser les changements de service. Notre équipe génère un rapport hebdomadaire sur le travail du dernier quart de travail, analyse les faiblesses et améliore la méthodologie du travail.

Gestion des pannes et des incidents


Imaginez: vous êtes ingénieur de service pendant une semaine. Au milieu de la nuit, vous réveillez un message sur le téléavertisseur. Vous vérifiez si un échec de production s'est produit. Merde, il semble qu'une partie du système s'est écrasée. Maintenant quoi? La surveillance et l'alerte ont bien fonctionné.

Les pannes peuvent ne pas être particulièrement problématiques pour les petits systèmes lorsque l'ingénieur de service peut comprendre ce qui s'est passé et pourquoi. Habituellement, dans de tels systèmes, vous pouvez rapidement identifier les causes et les éliminer. Mais dans le cas de systèmes complexes contenant de nombreux (micro) services, lorsque de nombreux ingénieurs envoient le code en fonctionnement, la raison de l'échec est assez difficile. Et le respect de plusieurs procédures standard peut être très utile.

La première ligne de défense sont les runbooks des procédures de réponse standardqui décrivent des étapes de dépannage simples. Si l'entreprise dispose de telles listes et bénéficie d'un soutien actif, il est peu probable qu'une idée superficielle de l'ingénieur de service sur le système soit un problème. Les listes doivent être tenues à jour, mises à jour et traitées pour trouver de nouvelles façons de résoudre les problèmes.

Informer sur les échecs des autres employésCela devient très important si plusieurs équipes sont impliquées dans le déploiement d'un service. Dans l'environnement dans lequel je travaille, les services, selon les besoins, sont déployés par des milliers d'ingénieurs, avec une fréquence de centaines de versions par heure. Et le déploiement apparemment anodin d'un service peut en affecter un autre. Dans une telle situation, un rôle important est joué par la normalisation des rapports de défaut et des canaux de communication. J'ai eu de nombreux cas où l'alerte ne ressemblait à rien d'autre et j'ai réalisé que pour les autres équipes, cela semblait également étrange. Communiquant dans un chat général sur les pannes, nous identifions le service responsable de la panne et éliminons rapidement les conséquences. Ensemble, nous parvenons à le faire beaucoup plus rapidement que chacun de nous individuellement.

Éliminez les conséquences maintenant et comprenez-le demain. Au milieu d'un accident, j'étais souvent submergé par une vague d'adrénaline à cause d'un désir de corriger les erreurs. Souvent, la cause du problème était le déploiement de mauvais code avec un bogue évident. Auparavant, j'aurais tout quitté et commencé à corriger les erreurs, à envoyer un correctif et à restaurer le code ayant échoué. Mais fixer la cause au milieu d'un accident est une idée terrible . Avec une solution rapide, vous pouvez réaliser peu et perdre beaucoup . Étant donné que la correction doit être effectuée rapidement, elle doit être testée au combat. Et c'est le chemin vers un nouveau bogue - ou un nouvel échec - en plus de celui existant. J'ai vu comment cela a causé un certain nombre d'échecs. Concentrez-vous simplement sur la correction des conséquences, ne soyez pas tenté de corriger le code ou de trouver la cause. L'enquête attendra demain.

Post mortem, analyse d'incidents et culture d'amélioration continue


Un rapport d'incident est une caractéristique importante de la façon dont une équipe gère les conséquences d'une défaillance. La situation inquiète-t-elle les gens? Font-ils un peu de recherche ou consacrent-ils une quantité incroyable d'efforts à l'observation, arrêtent-ils le produit et apportent-ils des corrections?

L'autopsie correctement rédigée est l'un des principaux éléments de la construction de systèmes durables. Il ne condamne personne et ne cherche pas les coupables, il s'agit d'une étude et d'une analyse réfléchies de l'incident. Au fil du temps, nos modèles pour de tels rapports ont évolué, des sections avec des conclusions finales, une évaluation d'impact, une chronologie des événements, une analyse de la raison principale, des leçons apprises et une liste détaillée des éléments pour une observation plus approfondie sont apparues.


J'ai utilisé ce modèle de gestion des erreurs dans Uber.

Dans un bon post-mortem, la cause de l'échec est minutieusement étudiée et des mesures sont proposées pour prévenir, détecter ou éliminer rapidement les conséquences d'échecs similaires. Et quand je dis "profondément", je veux dire que les auteurs ne s'arrêtent pas au fait que la raison en était le roulement de code avec un bug que le relecteur n'a pas remarqué. Les auteurs doivent appliquer la méthodologie Five Why pour arriver à une conclusion plus utile. Par exemple:

  • Pourquoi y a-t-il un problème? -> Le bug a été téléchargé dans le cadre du code.
  • Pourquoi personne n’a-t-il attrapé un bug? -> Celui qui a fait la revue n'a pas remarqué que changer le code pouvait conduire à un tel problème.
  • , ? --> .
  • ? --> .
  • ? --> .
  • : . , .

L'analyse des incidents est un outil complémentaire important pour travailler sur les bogues. Alors que certaines équipes travaillent soigneusement sur les bogues, d'autres peuvent bénéficier de données supplémentaires et apporter des améliorations préventives. Il est également important que les équipes se considèrent responsables et capables d'apporter les améliorations qu'elles proposent au niveau du système.

Dans les organisations soucieuses de fiabilité, les incidents les plus graves sont analysés et éliminés par des ingénieurs expérimentés. Il est également nécessaire de gérer l'ingénierie au niveau de l'entreprise pour s'assurer que les corrections peuvent être apportées - surtout si elles prennent du temps ou interfèrent avec d'autres travaux. Un système fiable ne peut pas être créé en une nuit: des itérations constantes seront nécessaires. Itérations résultant d'une culture d'entreprise d'amélioration continue basée sur les enseignements tirés des incidents.

Basculement, planification des ressources et test de la boîte noire


Il existe plusieurs procédures régulières qui nécessitent des investissements importants, mais qui sont essentielles pour maintenir un grand système distribué. Je suis arrivé à ces idées pour la première fois chez Uber, je n'avais pas besoin de les appliquer à d'autres entreprises en raison de la petite taille et de l'indisponibilité de l'infrastructure. J'ai considéré un

basculement stupide dans le centre de données (basculement) jusqu'à ce que je tombe sur moi-même. Au départ, je pensais que la conception d'un système distribué stable est la stabilité des datacenters à tomber. Pourquoi devrait-il être testé régulièrement si tout devait théoriquement fonctionner? La réponse dépend de la mise à l'échelle et du test de la capacité des services à gérer efficacement l'augmentation inattendue du trafic dans le nouveau centre de données.

Le scénario d'échec le plus courant que j'ai rencontré est que le service ne dispose pas de suffisamment de ressources dans le nouveau centre de données pour gérer le trafic global en cas de basculement. Supposons que le service A fonctionne dans un centre de données et le service B dans un autre. Soit une consommation de ressources de 60% - des dizaines ou des centaines de machines virtuelles tournent dans chaque centre de données et des alertes sont déclenchées lorsqu'un seuil de 70% est atteint. Tout le trafic entre le centre de données A et le centre de données B a échoué. Le deuxième centre de données ne peut pas faire face à une telle augmentation de la charge sans déployer de nouvelles machines. Cependant, cela peut prendre beaucoup de temps, donc les demandes commencent à s'accumuler et à tomber. Le blocage commence à affecter d'autres services, provoquant une défaillance en cascade d'autres systèmes qui ne sont pas liés au basculement principal.


Une situation possible où le basculement entraîne des problèmes.

Un autre scénario de défaillance populaire implique des problèmes au niveau du routage, des problèmes de bande passante réseau ou une contre-pression . Le basculement des centres de données est un développement que tout système distribué fiable doit effectuer sans aucun impact sur les utilisateurs. J'insiste - il le faut , ce développement est l'un des exercices les plus utiles pour vérifier la fiabilité des systèmes Web distribués.

Exercices de temps d'arrêt des services planifiésUn excellent moyen de tester la stabilité d'un système entier. C'est également un excellent outil pour détecter les dépendances cachées ou les utilisations inappropriées / inattendues d'un système particulier. Les exercices de temps d'arrêt planifiés peuvent être relativement faciles à effectuer avec des services avec lesquels les clients interagissent et ont des dépendances peu connues. Cependant, si nous parlons de systèmes critiques pour lesquels un temps d'arrêt très court est autorisé ou dont dépendent de nombreux autres systèmes, il sera difficile de réaliser de tels exercices. Mais que se passe-t-il si un tel système devient indisponible un jour? Il vaut mieux répondre à cette question dans une expérience contrôlée afin que toutes les équipes soient prévenues et prêtes.

Test de Blackbox(méthode de la "boîte noire") est un moyen d'évaluer l'exactitude du système dans une situation aussi proche que possible de la façon dont se déroule l'interaction avec l'utilisateur final. Ceci est similaire aux tests de bout en bout, sauf pour le fait que pour la plupart des produits, les tests de blackbox corrects nécessitent votre propre investissement. Les processus et scénarios utilisateur clés qui impliquent une interaction utilisateur sont de bons candidats pour de tels tests: pour tester le système, assurez-vous qu'ils peuvent être lancés à tout moment.

En utilisant Uber comme exemple, un test évident de la boîte noire vérifie l'interaction conducteur-passager au niveau de la ville: un passager peut-il trouver un conducteur et faire un voyage sur demande spécifique? Après avoir automatisé ce scénario, le test peut être exécuté régulièrement, en émulant différentes villes. Un système de test de boîte noire fiable permet de vérifier facilement le bon fonctionnement du système ou de ses pièces. Cela aide également beaucoup avec les tests de basculement: le moyen le plus rapide d'obtenir des commentaires de commutation est d'exécuter des tests de boîte noire.


Un exemple de test de boîte noire pendant le basculement de basculement et la restauration manuelle.

La planification des ressourcesjoue un rôle particulièrement important pour les grands systèmes distribués. En gros, je veux dire ceux dans lesquels le coût de l'informatique et du stockage est calculé en dizaines ou centaines de milliers de dollars par mois. À cette échelle, il peut être moins coûteux d'avoir un nombre fixe de déploiements que d'utiliser des solutions cloud auto-évolutives. Dans les cas extrêmes, les déploiements fixes doivent gérer le trafic caractéristique des «activités normales», avec une mise à l'échelle automatique uniquement aux pics de charge. Mais quel est le nombre minimum d'instances à appliquer le mois prochain? Au cours des trois prochains mois? L'année prochaine?

Il n'est pas difficile de prédire les futurs modèles de trafic pour les systèmes matures avec de grands volumes de statistiques. Ceci est important pour le budget, le choix des fournisseurs ou pour fixer les remises des fournisseurs de cloud. Si votre service génère de grands comptes et que vous n'avez pas pensé à la planification des ressources, il vous manque un moyen simple de réduire les coûts et de les gérer.

SLO, SLA et rapports à leur sujet


SLO signifie Service Level Objective , une mesure de la disponibilité du système. Il est recommandé de définir les SLO au niveau du service pour les performances, le temps de réponse, l'exactitude et la disponibilité. Ces SLO peuvent ensuite être utilisés comme seuils d'alerte. Exemple:

SLO métriqueSous-catégorieValeur du service
PerformanceBande passante minimale500 requêtes par seconde
2 500
50-90
p99500-800
0,5 %
99,9 %

SLO au niveau de l'entreprise . ou SLO fonctionnels, il s'agit d'une abstraction sur les services. Ils couvrent des mesures personnalisées ou commerciales. Par exemple, un SLO au niveau de l'entreprise pourrait être le suivant: 99,99% des reçus devraient être postés dans la minute suivant la fin d'un voyage. Ce SLO peut être comparé au SLO au niveau du service (par exemple, avec le retard du système de paiement ou du système d'envoi des chèques postaux), et peut être mesuré séparément.

SLA - Service Level Agreement . Il s'agit d'un accord plus général entre un fournisseur de services et son consommateur. En règle générale, plusieurs SLO constituent un SLA. Par exemple, la disponibilité d'un système de paiement au niveau de 99,99% peut être SLA, qui est divisée en SLO spécifiques pour chaque système correspondant.

Après avoir déterminé le SLO, vous devez les mesurer et faire un rapport.La surveillance et les rapports automatiques sur les SLA et les SLO sont souvent un projet complexe que ni les ingénieurs ni les entreprises ne souhaitent prioriser. Les ingénieurs ne seront pas intéressés, car ils ont déjà différents niveaux de surveillance pour identifier les pannes en temps réel. Une entreprise préfère prioriser la fourniture de fonctionnalités, plutôt que d'investir dans un projet complexe qui ne donnera pas d'avantages immédiats.

Et cela nous amène à un autre sujet: les organisations qui exploitent de grands systèmes distribués doivent tôt ou tard affecter des personnes pour garantir la fiabilité de ces systèmes. Parlons de l'équipe SRE - Site Reliability Engineering.

SRE en équipe indépendante


Le terme Site Reliability Engineering a été inventé par Google vers 2003, et il existe aujourd'hui plus de 1 500 ingénieurs SRE. Comme le fonctionnement de l'environnement de production devient une tâche de plus en plus complexe nécessitant plus d'automatisation, il deviendra bientôt un travail à part entière. Cela se produit lorsque les entreprises réalisent que les ingénieurs travaillent sur l'automatisation de l'environnement de production presque toute la journée: plus le système est important et plus il y a de pannes, plus tôt le SRE devient un poste séparé.

Les entreprises technologiques à croissance rapide mettent souvent en place très tôt une équipe SRE, qu'elles planifient elles-mêmes. À Uber, une telle équipe a été créée en 2015.Son objectif était de gérer la complexité du système. Dans d'autres sociétés, la répartition des équipes SRE peut être associée à la création d'une équipe infrastructure distincte. Lorsque l'entreprise atteint un tel niveau que la fiabilité du service requiert l'attention d'un nombre important d'ingénieurs, il est temps de créer une équipe distincte.

L'équipe SRE simplifie considérablement la maintenance des grands systèmes distribués pour tous les ingénieurs. L'équipe SRE possède probablement des outils de surveillance et d'alertes standard. Ils achètent ou créent probablement des outils sur appel et sont prêts à partager leur expérience. Ils peuvent faciliter l'analyse des incidents et créer des systèmes qui facilitent la détection des pannes, réduisent leurs conséquences et les préviennent à l'avenir. La commande SRE facilite certainement les opérations de basculement. Il est souvent utilisé pour tester les boîtes noires et planifier les performances. Les ingénieurs SRE gèrent la sélection, la personnalisation ou la création d'outils standard pour déterminer et mesurer les SLO et en rendre compte.

Étant donné que toutes les entreprises ont leurs propres problèmes, pour la solution desquels elles recrutent SRE, ces équipes dans différentes entreprises ont des structures différentes. Même les noms peuvent varier: il peut s'agir d'un service d'exploitation, d'une ingénierie de plateforme ou d'un service d'infrastructure. Google a publié deux livres de lecture obligatoires pour garantir la fiabilité des services . Ils sont disponibles gratuitement et constituent une excellente source d'informations pour une étude plus approfondie du sujet du SRE.

La fiabilité comme investissement permanent


Lors de la création d'un produit, l'assemblage de la première version n'est qu'un début. Après cela, il y aura de nouvelles itérations, avec de nouvelles fonctionnalités. Si le produit est réussi et rentable, le travail se poursuit.

Les systèmes distribués ont le même cycle de vie, sauf qu'ils ont besoin de plus d'investissement non seulement dans de nouvelles fonctionnalités, mais aussi pour suivre l'évolution. Lorsque la charge sur le système augmente, vous devez stocker plus de données, plus d'ingénieurs travaillent sur le système, vous devez constamment prendre soin de son fonctionnement normal. Beaucoup de ceux qui créent des systèmes distribués pour la première fois les considèrent comme quelque chose comme une machine: une fois que vous le faites, il suffit d'effectuer une maintenance tous les quelques mois. Il est difficile de trouver une comparaison plus éloignée de la réalité.

, , . Pour que l'hôpital fonctionne bien, des contrôles constants sont nécessaires (surveillance, alertes, tests en boîte noire). Tout le temps dont vous avez besoin pour embaucher du nouveau personnel et du matériel: pour les hôpitaux, ce sont les infirmières, les médecins et les appareils médicaux, et pour les systèmes distribués, les nouveaux ingénieurs et les services. À mesure que le nombre d'employés et de services augmente, les anciennes méthodes de travail deviennent inefficaces: une petite clinique à la campagne fonctionne différemment d'un grand hôpital dans une métropole. Trouver des modes de fonctionnement plus efficaces se transforme en un travail à part entière, et les mesures et les alertes deviennent de plus en plus importantes. Comme un grand hôpital a besoin de plus de personnel, comme la comptabilité, les ressources humaines et la sécurité,et l'exploitation de grands systèmes distribués repose sur des équipes de service comme l'infrastructure et le SRE.

Pour que l'équipe puisse maintenir un système distribué fiable, l'organisation doit constamment investir dans son fonctionnement, ainsi que dans le travail des plateformes sur lesquelles le système est construit.

Matériaux utiles


Bien que l'article se soit avéré long, il ne présente que les moments les plus superficiels. Pour en savoir plus sur les fonctionnalités d'exploitation des systèmes distribués, je recommande ces sources:

Livres


Des sites


Voir les commentaires sur cet article sur Hacker News .

More articles:


All Articles