"Et si vous ne tirez pas, je serai gâté"
Jusqu'à récemment, on pensait que le service devrait simplement fonctionner. Ils ont dessiné, inventé, écrit des scripts - tout semble aller bien, vous pouvez le faire rouler jusqu'au prod.
Mais les concurrents ne dorment pas, la course commence donc non seulement pour de nouvelles fonctionnalités, mais aussi pour la vitesse. Tout gel de l'application ou une longue réponse du serveur (sans oublier les erreurs de pop-up du 500e) gâchent l'impression du service et obligent l'utilisateur à partir ailleurs. Assurément, tout le monde a été confronté à des situations où, au lieu d'acheter un billet d'avion, de train ou de concert, "Erreur de serveur interne" était affiché à l'écran, et vous étiez furieux de casser le moniteur.
Je suis Victor Bodrov, je travaille chez Yandex.Money dans l'équipe de recherche sur la productivité et je veux parler de l'utilité d'étudier la productivité directement sur la production.
Chaque minute d'arrêt est désastreuse pour les entreprises, en particulier pour celles qui sont impliquées dans des transactions financières, telles que les transferts et les paiements, le paiement des marchandises en magasin. Chaque paiement suspendu n'est pas seulement une perte monétaire, mais aussi une perte de réputation. Dans de telles conditions, un temps de disponibilité élevé est nécessaire, pour lequel il est nécessaire de garder un œil sur le pouls du système de paiement et de surveiller en permanence tous ses indicateurs, en accordant une attention particulière aux performances.
Pourquoi le rechercher?
Tout d'abord, connaître les performances de votre propre service vous aide à préparer le lancement de nouvelles fonctionnalités, diverses promotions et ventes. La connaissance d'indicateurs fiables aidera au bon moment à répondre à l'afflux de nouveaux utilisateurs non pas avec une petite porte avec un tourniquet, mais avec de grandes portes avant et des bras ouverts.
Deuxièmement, un bon service doit connaître la limite de ses performances à tout moment, les mesures doivent donc être régulières. Si vous le faites assez souvent, en conservant la pertinence des données, alors ne manquez pas la dégradation de votre service et vous pouvez rapidement restaurer les indicateurs requis.
Troisièmement, en s'appuyant sur des données de performance actualisées, il est plus facile pour une entreprise de planifier le développement d'un service et de choisir des directions de croissance.
Pour ceux qui sont perplexes devant un tel problème pour la première fois, la question se pose: où et comment mesurer la productivité? Souvent, un banc est utilisé pour de telles expériences. Dans les entreprises individuelles, il existe un stand spécial pour la recherche de performance. Si vous l'avez - super! Si c'est 1 en 1 correspond au produit, alors tout va bien pour vous. Mais le plus souvent, il est très coûteux de maintenir un support parfaitement adapté au produit. Comment être? Il s'avère que le seul endroit qui correspond pleinement au produit est le produit lui-même?
Pour beaucoup, la proposition de mesurer et de vérifier quelque chose directement sur la prod semble hérétique. Ne vous inquiétez pas si tout est fait avec soin, il ne se passera rien de mal. Par exemple, nous pré-calculons les risques possibles et déterminons ce qui dans notre système peut souffrir de l'expérience. Parallèlement à cela, nous prévoyons comment réduire le danger et surveiller en permanence l'état du système.
La recherche sur prod n'annule pas l'utilisation du stand. Il peut effectuer des vérifications de version et des expériences spéciales pour étudier les performances des microservices, y compris individuellement ou dans diverses combinaisons.
L'avantage principal et indéniable des résultats obtenus au niveau du prod - ils sont les plus honnêtes de toutes les options et aussi proches que possible du traitement réel du trafic des utilisateurs. Peu importe à quel point le support est proche du produit en termes de caractéristiques - il ne pourra pas l'attraper, comme la tortue d'Achille. Lorsque vous effectuez des recherches sur le produit, vous utiliserez les mêmes bases de données que les utilisateurs réels, le même réseau, le même environnement. Il n'est pas nécessaire de construire quoi que ce soit, tout a déjà été construit avant vous et fonctionne correctement.
Les données de ces expériences intéresseront tous les ingénieurs, quel que soit le rôle qui leur est assigné: développeurs, testeurs, administrateurs. Les indicateurs de performance garantis intéresseront également l'entreprise - pour les clients potentiels, ils constitueront une publicité convaincante du service.
Sélection de scénarios et modèles de flux de charge
Pour l'organisation sûre et appropriée de telles expériences, plusieurs étapes obligatoires doivent être accomplies.
Sélection de scénario
La première étape, la plus importante, consiste à sélectionner les scénarios à l'étude. Cela peut être soit des demandes uniques (par exemple, vérifier le solde), soit des scénarios avec une logique complexe, où chaque demande suivante dépend des résultats de la précédente (paiement des marchandises dans le magasin, transfert d'un portefeuille à l'autre). Nous prenons régulièrement une liste de tous les processus métier qui existent dans le système. Nous avons plus de 400 processus de ce type, en fonction des objectifs de l'entreprise, nous coordonnerons les priorités des scénarios.
Quels scénarios devraient être inclus dans le groupe prioritaire?
- Ceux pour lesquels une forte augmentation de l'activité des utilisateurs est attendue dans un proche avenir.
- Celles pour lesquelles il existe des restrictions strictes constantes (pour diverses raisons) qui ne vous permettent pas de tomber en dessous du SLA.
Ainsi, il est possible de constituer un pool de scénarios prioritaires pour des contrôles réguliers sur le prod. Dans notre entreprise, nous tirons sur eux au moins une fois par trimestre.
Un ensemble de techniques et d'outils est sélectionné en fonction de la logique du script. Dans notre cas, les scénarios prioritaires ont une logique ramifiée. Par exemple, lorsque vous effectuez des paiements par carte, divers contrôles sont effectués, selon le script qui va sur sa propre branche, nous utilisons donc JMeter pour les implémenter. Il est pratique uniquement pour de tels scénarios complexes, où chaque demande ultérieure dépend du résultat de la précédente. Si vous avez besoin de filmer des requêtes individuelles, je vous recommande d'utiliser le Phantom hautes performances.
Pour rechercher des scénarios utilisateur, des utilisateurs spéciaux peuvent être nécessaires, au nom desquels des demandes seront faites. Si vous utilisez un utilisateur ou un petit nombre d'entre eux, vous pouvez rencontrer la mise en cache des données, ce qui faussera les résultats. Plus les utilisateurs sont différents, plus les données de recherche sont précises.
Circuit de charge
Dans la deuxième étape, nous sélectionnons le circuit d'alimentation d'intensité d'entrée.
Par exemple, avant une vente, nous déterminons quels sont les principaux moyens de paiement des utilisateurs. Pour le réglage et le suivi des goulots d'étranglement, nous effectuons le tir sur certains types de paiements. En règle générale, l'activité des utilisateurs lors de diverses promotions a tendance à favoriser l'un ou l'autre scénario. En le vérifiant, vous obtenez une image claire de son comportement sous charge.
Mais les entreprises peuvent également être intéressées par la performance globale. Dans ce cas, vous pouvez combiner les scénarios d'entreprise les plus populaires proportionnellement à leur utilisation par de vrais utilisateurs et activer la charge cumulée. Il convient de noter que, dans ce cas, des difficultés peuvent survenir avec l'évaluation quantitative. Au lieu d'un numéro de performance spécifique, vous obtiendrez une série de chiffres qui, à son tour, peut varier en fonction des proportions d'un scénario particulier dans le flux général.
L'apport d'intensité peut également être différent. Je vais me concentrer sur les deux profils les plus courants. Il s'agit d'un test avec un flux d'intensité et de stabilité fourni croissant (par étapes), dans lequel le fonctionnement à long terme du service est vérifié sous un flux d'intensité stable. La deuxième option nécessite un temps de recherche long, ce qui n'est pas toujours possible sur un environnement de combat, en plus, le niveau d'intensité fournie doit déjà être connu pour cela.
Axe X - temps, axe Y - intensité de la charge (demandes par seconde)
C'est bien quand il existe un SLA spécifique sur la base duquel vous pouvez effectuer des vérifications en surveillant les performances, le temps de réponse et en surveillant le comportement des composants. Une situation plus courante est lorsque le niveau de performance est inconnu et que vous devez le déterminer. Pour ce faire, nous utilisons la première option - la mesure avec une intensité fournie croissante. Nous activons le flux d'entrée, l'augmentons linéairement ou pas à pas, nous examinons le comportement du service. Une charge appliquée linéairement peut suivre plus précisément le point de saturation et le point de rupture. Cela a été décrit plus en détail dans notre article . Mais l'intensité fournie pas à pas combine même de petits tests de stabilité, surtout si les étapes sont longues. Il n'est pas recommandé d'appliquer immédiatement un flux de charge important à l'entrée, il est préférable de «réchauffer» le service, en augmentant progressivement le flux d'entrée.
Vous pouvez également effectuer une série de deux expériences. Mesurez d'abord le point de saturation avec une charge et un arrêt appliqués linéairement. Vous ne devriez pas continuer à alimenter le flux à la suite de la panne, c'est toujours une prod, pas un stand. La deuxième expérience consiste à regarder le comportement du service sous une charge de pas en sélectionnant plusieurs pas près du point de saturation. Ensuite, effectuez un test de stabilité dans la mesure du temps, en choisissant une charge pour elle de 15 à 20% en dessous du point de saturation (ou une panne si vous l'aviez subitement avant la saturation). Grimper plus haut est dangereux.
Timing
Ensuite, vous devez déterminer la durée de l'expérience. L'une des conditions les plus importantes pour effectuer des mesures de performances sur le prod est la sécurité de tous les utilisateurs réels. Il est extrêmement rare qu'il soit possible d'interrompre le service pendant un certain temps à des fins de prévention et de le bombarder calmement. En règle générale, les services en ligne sont réglés pour fonctionner 24h / 24 et 7j / 7, vous devez donc vous adapter au mode d'utilisation du service.
Il est logique que plus l'activité réelle de l'utilisateur est élevée, plus le tournage peut entraîner des temps d'arrêt et des pertes financières. En revanche, moins il y a de trafic utilisateur, moins il y a d'erreur de mesure. Par conséquent, pour minimiser l'impact des expériences, il est recommandé de les réaliser dans des périodes d'activité réduite de l'utilisateur.
Comme le montre la pratique, l'activité minimale de nos utilisateurs tombe sur la période de deux à sept heures du matin. Bien sûr, chaque service a ses propres caractéristiques et son propre public, nous déterminons donc l'heure de tournage en surveillant le comportement des utilisateurs. Il n'est pas toujours possible d'organiser des expériences dans la période optimale sélectionnée. Pour tirer sur l'engin, en particulier dans la phase initiale de leur connexion, un contrôle accru est nécessaire. Cela causera des difficultés, car vos collègues sont aussi des gens et ne vont pas toujours travailler la nuit. Cette situation nécessitera un compromis. Vous devez choisir une heure qui conviendrait à tout le monde tout en satisfaisant à la condition de faible activité des utilisateurs.
Difficultés à travailler avec des contreparties
Si le service est lié non seulement à des calculs internes, mais également à l'interaction avec des services tiers (contreparties), vous devez choisir la façon dont vous effectuerez votre licenciement: avec la contrepartie ou en utilisant le talon de service à la place. Naturellement, si vous prévoyez de tirer sur les serveurs de la contrepartie, vous devez d'abord vous mettre d'accord sur tout. Cela compliquera considérablement la préparation au tir, mais ajoutera des avantages à la véracité des résultats obtenus.
Et vice versa: si vous remplacez le service de la contrepartie par une prise, la préparation au tournage sera grandement simplifiée, mais l'honnêteté des résultats diminuera. Il convient de garder à l'esprit que le talon doit imiter le comportement de la contrepartie autant que possible, et pas seulement donner 200 OK.
Les contreparties elles-mêmes sont différentes. Certains passent facilement à des vérifications conjointes, tandis que d'autres exécutent chaque étape de nombreuses instances. La détermination du calendrier des expériences peut également être source de controverse. Par exemple, certains bureaux d'État acceptent de ne travailler que de 9 à 18 heures.
Vérification de l'accès et de la coordination avec le Conseil de sécurité, les services financiers, les administrateurs
Dans cette partie, nous nous concentrerons sur les accès et les approbations avec toutes les personnes responsables - le service de sécurité, les services financiers et les administrateurs système.
Vous devez vérifier les accès nécessaires . Assurez-vous que rien n'interfère avec la recherche et, si nécessaire, commandez les accès aux administrateurs réseau, à la fois de votre propre chef et de vos contreparties, si vous travaillez avec eux. Les administrateurs réseau vous aideront à équilibrer les paramètres. Nous avons déjà eu un commutateur d'équilibrage de round-robin à ip-hash. En conséquence, toutes nos requêtes sont tombées sur le même front, sélectionnées par le nouvel algorithme d'équilibrage.
Après avoir obtenu l'accès, vous devez déboguer et vérifier le script sur le plus petit flux d'unité.
Les prochaines étapes sont les approbations . Tout d'abord, contactez le service de sécurité afin que votre expérience ne soit pas interrompue au décollage en raison d'une «activité suspecte». Pour évaluer tous les risques possibles du Conseil de sécurité, un plan de tir détaillé est nécessaire - qui, quoi et en quelles quantités il est impliqué.
Ensuite, vous devez coordonner le plan de tir avec les services financiers et commerciaux. Si le service est associé à des activités financières, une coordination avec le service financier et la comptabilité sera nécessaire. Toute activité financière supplémentaire peut affecter les états financiers ou même provoquer des dysfonctionnements dans la formation de divers résumés de publication. Cela doit être évité, il vaut donc la peine d'avertir ses collègues, après avoir déterminé la configuration optimale des expériences.
Si vous avez un service de statistiques qui accumule des informations sur le fonctionnement du service, vous devez coordonner la prise de vue avec eux. Le fait est que le flux de charge provoquera une vague supplémentaire de statistiques. Décidez s'ils prendront en compte ou non les tests dans leurs rapports. Sinon, décidez comment les données des utilisateurs réels seront séparées des données de test.
Lors de la planification, vous devez également coordonner la date et l'heure des tests avec le service commercial, qu'ils aient des publicités ou des promotions prévues pour cette heure ou autour. N'oubliez pas d'informer les chefs d'équipe de toutes les activités planifiées et non planifiées sur le prod. Naturellement, vous devez avertir et être d'accord avec les administrateurs, car pendant le tournage, leur participation peut être requise. De plus, ce sont les administrateurs du cours sur toutes les actions sur le prod. Peut-être juste au moment que vous choisissez, un changement de centre de données, un remplacement de serveur ou d'autres travaux sont prévus.
Tir et analyse des résultats
Enfin, nous discutons de la conduite du tir avec surveillance. Nous déterminons où regarder pendant les expériences, dans quelles conditions s'arrêter, à quels capteurs répondre? Cela doit être fait "à terre", avant le début du tournage.
Il y a plusieurs raisons d'arrêter.
1) Sur un signal de surveillance. Dans ce cas, peu importe que la fonctionnalité impliquée dans l'expérience soit interrompue ou qu'une urgence se produise à l'autre extrémité du service. Vous devez arrêter les tests et comprendre les raisons, car le bon fonctionnement du service est l'une des principales priorités.
2) Avec la croissance des erreurs réseau ou HTTP. Il s'agit d'une situation d'urgence nécessitant une intervention.
3) Si la saturation est atteinte, les performances n'augmentent plus, mais le temps de réponse augmente. Pas besoin d'attendre la panne et de mettre la prod. Le résultat de l'analyse est déjà là, vous pouvez arrêter l'expérience en toute sécurité.
Après l'expérience, vous pouvez comprendre qu'il n'y a pas suffisamment de journaux et de résultats et vous devez répéter l'expérience avec la journalisation du débogage activée. Cela rendra le journal et l'écriture sur le disque plus lourds, mais maintenant vous connaissez le niveau de la charge requise, ce qui signifie qu'au lieu d'un long test, vous pouvez le faire raccourci.
Analyse des résultats
Au final, il reste à analyser les résultats et à fournir les données obtenues aux parties intéressées. Vous pouvez commencer à le faire déjà pendant les expériences. Nous utilisons les bundles Zabbix et Elastic avec Grafana et Kibana pour l'analyse. Nous surveillons les caractéristiques temporelles de tous les appels externes et internes impliqués dans notre expérience, nous surveillons les pools de connecteurs, les files d'attente et le moniteur de base de données. Pour le suivi en ligne des métriques du côté du générateur de trafic - Service Yandex Lunapark (il existe un analogue ouvert - overload.yandex.net).
La présentation des résultats variera en fonction de qui en a besoin. Pour le développement, les administrateurs et les testeurs ont besoin d'un rapport détaillé avec des métriques, des graphiques, des journaux et des traces de pile précis. Pour les entreprises, le résultat et les prévisions de développement sont importants. Dans ce cas, le caractère concret et l'accent mis sur les nombres sont meilleurs et plus visuels. Pour ce faire, vous pouvez utiliser le principe des feux tricolores. La zone rouge est mauvaise, il est urgent de l'optimiser. Jaune - nous avons remarqué une dégradation des indicateurs, vous devez faire attention à cela. Vert - tout va bien, continuez. Une vue claire et accessible des résultats de la recherche aidera à éliminer les questions sur l'importance et l'utilité de mesurer le rendement.
, !