«Demain est le 20, ce qui signifie qu'il y aura à nouveau une tempête. Il est impossible de l'arrêter, il suffit de se préparer et d'espérer que cette fois il va exploser, un miracle se produira, et notre ferry sur le lac conquérera l'océan .
» Ces réflexions ont dominé l'équipe impliquée dans le soutien du portail des services municipaux il y a plusieurs années. La façon dont nous nous sommes retrouvés dans cette situation et comment nous en avons trouvé un moyen sera décrite ci-dessous.
Comment tout a commencé
Dans les années 90, le secteur du logement et des services publics a connu un boom du développement, de nouvelles technologies ont été introduites, des systèmes d'information automatisés et de nouveaux équipements ont été achetés. Mais quelque chose est resté longtemps inchangé, à savoir les paiements pour l'appartement. Oui, oui, ces mêmes reçus pour un appartement, transformés en documents de paiement, ayant acquis des codes-barres, un décryptage détaillé, sont restés comme des morceaux de papier. Le plan de travail type du centre d'établissement de l'entreprise de logement et de services communaux ou de l'entreprise fournissant des ressources était le suivant:
Petit à petit, le modem Internet a été remplacé par un accès haut débit, la pensée est née - pourquoi ne pas recevoir les documents de paiement en ligne sous forme électronique? Dans le même temps, le secteur du logement et des services communaux tremblait sous une forme organisationnelle, le logement MPP et les services communaux (entreprise municipale de production de logements et services communaux) ont été remplacés par les entreprises unitaires municipales (entreprises unitaires municipales), les DEZ (directions d'un seul client). À la suite de toutes les transformations, les services informatiques des entreprises de logement et de services communaux ont été aliénés et divers centres de peuplement ont vu le jour sur leur base. L'essence des centres de peuplement était, en fait, le calcul du loyer et le soutien informationnel de la population.
Stade de croissance, 00s
C'est alors que naissent les premiers portails d'information qui fournissent à la population des services électroniques. Le nombre de premiers utilisateurs a été mesuré en dizaines, tout le monde ne faisait pas confiance aux documents de paiement électronique, d'autres n'avaient pas entendu parler des innovations, les applications mobiles dans le domaine des services publics étaient rares. Le travail des portails d'information ne diffère pas beaucoup du travail des systèmes d'information familiers et, bien sûr, n'a jamais été une architecture à forte charge.
Des années ont passé, les portails se sont améliorés, il y avait des possibilités de prendre des relevés de compteurs, de générer des certificats, etc. C'est à cette époque que les premiers «nuages» sont apparus à l'horizon, de plus en plus d'utilisateurs ont commencé à s'inscrire sur des portails et à demander des données. Au loin, la première vague de charges approchantes est apparue.
L'équipe (ci-après dénommée équipe 1) a pris les mesures d'optimisation suivantes:
- Redimensionner un document de paiement au format PDF de 0,5 Mo à 0,2 Mo
- Création d'une file d'attente pour la formation des documents de paiement
- Stockage des documents de paiement générés pour une demande répétée
- Création d'une réplique de la base de données principale, uniquement pour les besoins du portail
Pendant plusieurs années, la situation a semblé stable, le nombre d'utilisateurs de portails individuels a été mesuré par milliers, il n'a pas encore pris d'assaut, mais il a basculé de manière significative, la décentralisation des centres de compensation a joué le jeu des développeurs.
Grande étape de saut
Un nouveau jalon dans l'histoire a été le développement d'un portail des services municipaux au niveau régional. L'inclusion d'un point d'entrée unique pour tout résident de la République était une idée tentante; en outre, cela augmenterait la note du site de l'État au niveau des meilleurs sites commerciaux ou bancaires, où chaque résident de la région recevrait de nombreux types de services différents. L'un des plus populaires pourrait être le paiement du logement et des services communaux et l'inclusion de relevés de compteurs.
Ainsi, l'étape suivante a été la séparation des informations opérationnelles des centres de règlement des informations affichées dans le document de paiement. Pour cela, un format de transfert de données simple et une base de données de stockage des informations ont été développés, et le calcul de l'espace requis pour le stockage pendant 5 ans de fonctionnement a été effectué.
Décisions clés prises à ce stade:
- Département de l'information faisant partie de la base de données opérationnelle;
- Développement d'une base de données pour stocker ce format;
- Combiner les données des centres de peuplement des régions en une seule base de données;
- Intégration avec les processus du portail, développement de services.
À ce stade, la solution est passée d'un système à part entière à un back-end, car le portail offrait aux utilisateurs une interface unique. Le portail avait sa propre équipe, qui l'a développé indépendamment de la solution actuelle des centres de peuplement. Dans notre histoire, la
deuxième équipe apparaît
(ci-après dénommée équipe 2) et un nouveau fournisseur. Comme nous le verrons plus loin, cela a considérablement affecté le développement et la résolution des problèmes. L'essence de la solution de conception était la suivante:
Lors de la conception de la base de données, un simple mappage du format à la base de données a été accepté, PostgreSQL 9.3 a été sélectionné comme SGBD (à l'époque c'était une version très récente). Le format était composé de 9 fichiers plats, chacun étant chargé par la commande COPY (nous lisons - très rapidement) dans les nombreuses tables d'un centre de règlement spécifique (chaque centre de règlement avait son propre numéro d'enregistrement) de la base de données du portail. Dans certains centres d'établissement, le nombre d'enregistrements requis pour la formation des documents de paiement a atteint 1 000 000. En un an, cela s'est élevé à 12 000 000, sur 5 ans - 60 000 000. Le nombre de demandes adressées à cette base de données est passé à la somme de tous les utilisateurs des portails de district et pourrait constituent des dizaines de milliers. Il y avait quelque chose à penser.
N'ayant pas une telle expérience, l'
équipe 1 a pris les mesures suivantes pour réduire la charge potentielle:
- Les tableaux étaient divisés par centres de peuplement et mois de partition;
- Le processus de chargement des données est espacé dans le temps pour différents centres de facturation.
Des défis pour une croissance trop rapide
Le portail a été lancé et les plans préparés étaient confrontés à la réalité:
- Le nombre d'utilisateurs a dépassé très rapidement l'estimation.
- Les requêtes sont allées à la table principale, mais le SGBD a quand même interrogé toutes les tables
- Charge parasite sur le serveur de base de données. Sur ce serveur, il y avait d'autres bases de données incomparablement grandes, dont les informations arrivaient à des moments aléatoires, le chargement prenait toutes les ressources disponibles
- Le service de formation d'un document de paiement a été ralenti en raison d'une mise en œuvre inefficace
- La charge des utilisateurs n'a pas été répartie uniformément sur le mois, mais concentrée sur deux périodes:
Ce moment est décrit au début de l'article. Il était difficile de diagnostiquer le problème, car les problèmes semblaient partout en même temps. L'équipe 1 et l'équipe 2, également aimées par leur leadership, ont pris des mesures pour sortir de la situation, mais il n'y avait pratiquement aucune communication entre elles:
L'équipe 2 , semble-t-il, a pris une mesure logique et utile: la formation d'un document de paiement a commencé à être demandée immédiatement après que l'utilisateur est entré dans le système, dans l'espoir que, alors qu'il atteignait les pages dans les pages, le PA était déjà formé et le document fini pourrait être récupéré rapidement.
À ce moment, l'
équipe 1 a héroïquement résolu un problème par mois chaque mois, convaincant à chaque fois le client que c'était là que se cachait la racine du problème:
- SQL optimisé (a parfois augmenté ses performances);
- Séparer le serveur de base de données du portail du reste des bases de données;
- Nous avons réalisé la formation d'un document de paiement dans une application séparée et l'avons également optimisé;
- Nous avons révisé l'appel à la table principale, changé la version de PostgreSQL;
- Encore une fois, nous avons révisé l'appel (maintenant, seulement une partition particulière a été demandée à la table principale - même une accélération parfois).
Les efforts héroïques des équipes ont conduit à des succès locaux (pendant 2-3 mois, il semblait que le problème était résolu). Mais la réalité a constamment jeté de nouvelles notes d'introduction:
- La base de données contient déjà plusieurs années et a augmenté de plus de 1 To;
- Le nombre d'utilisateurs était déjà de centaines de milliers.
Pendant que la lutte était en cours, l'
équipe 2 a mis en place un test de service automatique, de sorte que tout problème de performance est devenu connu en quelques minutes et le problème a atteint le plus haut niveau de contrôle automatiquement par e-mail.
En ce moment dans l'
équipe 1 :
- Le temps d'archivage de la base de données a commencé à dépasser les limites autorisées (le service est devenu indisponible);
- Un appel au service a immédiatement affecté plusieurs mois, respectivement, a généré de nombreuses demandes;
- Le SGBD a empiré dans l'exécution des requêtes en raison d'une augmentation du nombre de tables (partitions);
- Les utilisateurs qui souhaitaient uniquement effectuer des relevés d'instruments ont tout de même demandé la constitution de documents de paiement (rappel de la décision de l'équipe 2).
Il est devenu clair que d'un point de vue technique, la solution avait atteint ses limites et qu'il était temps de commencer à analyser le comportement des utilisateurs afin d'optimiser les processus ou de changer radicalement les technologies.
À la suite de l'analyse (voici le sujet d'un article séparé), les actions suivantes ont été prises:
- Les données ont été coupées jusqu'aux 3 dernières années, car il n'y a eu aucun appel au cours de la période précédente; depuis lors, l'ancienne période a été annulée chaque année;
- Nous avons refait l'appel à la table maître pour se référer directement à une partition particulière (réduction de la charge sur le SGBD).
Présent
Maintenant, le système est assez stable, respecte le calendrier réglementaire et les exigences pour les caractéristiques non fonctionnelles, mais des nuages sont à nouveau apparus à l'horizon:
- Une nouvelle augmentation du nombre d'utilisateurs;
- Croissance du nombre de ménages desservis;
- Accroître la complexité des services fournis;
- Augmentation de la granularité des données disponibles pour les utilisateurs.
Par conséquent, un plan est élaboré et la mise en œuvre des mesures suivantes est en préparation:
- Analyse du comportement des utilisateurs: combien d'entre eux consultent réellement le document de paiement et combien paient simplement le montant, comme pour un téléphone portable;
- Formation préalable des documents de paiement pour les utilisateurs qui consultent généralement les documents de paiement au moment du moindre chargement;
- Transition vers des technologies alternatives (oui, beaucoup de ceux qui ont atteint ce point ont des solutions beaucoup plus avancées qui ont résolu tous les problèmes au départ, sur les ressources d'un téléphone mobile).
Il semblerait que cela puisse mettre un gros point d'optimisme. Tout est bien fait: ceux qui l'ont fait et ceux qui auraient fait mieux immédiatement. Mais demain, il y aura de nouveaux projets Highload, de nouveaux problèmes inconnus. Comment s'y préparer maintenant, que peut-on envisager quand il n'y a pas encore de données?
Une approche systématique pour résoudre les problèmes
Pouvons-nous transformer l'expérience en une méthodologie pour aborder les problèmes dans les projets Highload? Curieusement, la réponse est OUI, tout a déjà été inventé pour nous et s'inscrit dans le cadre
de la théorie de la contrainte TOC . Seulement 5 étapes simples:
- Trouvez la ou les limitations du système.
- Décidez comment tirer le meilleur parti des limitations du système.
- Subordonnez tout le reste à cette décision.
- Développez les restrictions du système.
- ATTENTION! Si la restriction a été supprimée au cours des 4 étapes précédentes, revenez à l'étape 1, mais ne laissez pas l'inertie provoquer une restriction du système.
La description de cette théorie et l'essence des étapes sont assez bien décrites dans la littérature à la fin de l'article, mais j'écrirai ma vision dans le cadre du processus actuel:
- Restriction: heure de formation du document de paiement.
- Solution: Générez tous les documents de paiement à l'avance, lors du téléchargement des données.
- Subordonné à la décision: Lorsque vous contactez l'utilisateur, émettez un document terminé.
- Prolongez la restriction: optimisez le délai de formation du document de paiement.
- Abandonner le système de pré-formation pour TOUS les ménages, définir une nouvelle restriction.
Une telle approche réduirait le temps de solution de plusieurs années, avec des coûts de main-d'œuvre minimes pour les programmeurs. Le message indique loin de tous les problèmes qui se sont posés et il n'y a pas de détails sur les solutions, car ils ne sont pas si importants dans l'approche proposée.
Que lire sur le sujet:
- «Le but. Processus d'amélioration continue », Eliyahu Goldratt
- «Théorie des contraintes. Approches, outils et solutions de base » , Dmitry Egorov
- «La théorie des contraintes de Goldratt. Une approche systémique de l'amélioration continue », William Detmer