Comment le commerce électronique survit aux promotions à grande échelle. Se préparer aux pics de charge sur le Web [Partie 2]

Bonjour, Habr!
Il y a une semaine, il y avait un article dans lequel j'ai commencé une conversation sur la façon de préparer un projet de commerce électronique pour une croissance explosive du trafic et d'autres délices des promotions à grande échelle.
Nous avons compris les détails techniques clés, nous allons maintenant prêter attention aux problèmes administratifs et optimiser les processus de support lors des pics de charge:

• ce qui rend le site instable et pourquoi le cloud n'est pas une panacée;
  
• quels paramètres commerciaux doivent être surveillés afin de détecter un problème avant qu'il n'entraîne des pertes importantes;
  
• comment acheminer l'incident de l'événement à la solution sans chaos et localiser l'échec.
  

Et bien plus encore - je demande à tout le monde de couper!

D'après mon expérience, le plus gros casse-tête dans la préparation d'actions à grande échelle est une forte pression administrative. L'entreprise, qui était jusque-là très calme, souhaite soudain que tout le monde soit sur le ruisseau, dépoussière le site, etc. «Dieu ne plaise à ce qui se passe, nous serons condamnés à une amende. Essayons de satisfaire ce désir généralement sain. Nous en parlerons sur l'exemple du Black Friday, car c'est l'exemple le plus frappant d'une forte augmentation de la charge sur le site.
Et nous commencerons par la question fondamentale: quelle est exactement la cause du fonctionnement instable de notre site?

Ce qui rend un site instable

Le moment est venu de faire ce que vous retardez depuis longtemps. Pour comprendre quels facteurs rendent un site moins stable, élevez et analysez l'historique des problèmes. Ne dites simplement pas que vous ne l’avez pas.

Votre top aura plus ou moins les raisons suivantes:

1. Relâchez les plantages liés.
   
2. Les administrateurs ont foiré - réparé un, mais un autre s'est cassé. Malheureusement, ces superpositions sont souvent cachées et ne font pas partie de l'histoire.
   
3. A gâché l'entreprise - a lancé l'action de manière tordue, supprimé quelque chose, etc.
   
4. Services d'affiliation cassés.
   
5. Logiciel "triste". Le plus souvent, cela se produit en raison de paragraphes. 1 et 2.
   
6. Dommages physiques.
   
7. D'autres problèmes.
   

Bien sûr, toutes les situations sont différentes et votre «note» peut s'avérer légèrement différente. Mais les problèmes liés aux changements sur le site et au facteur humain, ainsi que les fruits de leur amour commun - libérations ou tentatives d'optimisation de quelque chose - continueront de mener.

Éradiquer ces problèmes afin qu'à la première tentative d'apporter les modifications nécessaires et de ne pas casser ce qui fonctionne bien, c'est une tâche dont de nombreuses copies ont été cassées. Et nous avons très peu de temps, seulement environ quatre mois. Heureusement, cela peut être géré localement. Pour ce faire, suivez quelques règles simples:

1. Fonctionne - ne touchez pas.

Terminez tous les travaux prévus le plus tôt possible - en quelques semaines, en un mois. L'heure à laquelle les améliorations seront apportées révélera l'historique de vos incidents. Il montre combien de temps dure la queue principale des problèmes. Après cela, ne touchez pas le site et l'infrastructure du produit tant que la charge n'est pas passée.

2. Si vous deviez quand même vous lancer dans la production pour des réparations urgentes - testez.

Régulièrement, sans relâche, même les plus petits et les petits changements. Tout d'abord, dans un environnement de test, y compris sous charge, puis seulement transférez-le au prod. Et encore une fois, testez et revérifiez les paramètres clés du site. Il est préférable de travailler la nuit, lorsque la charge est minimale, car vous devriez avoir le temps de sauver la situation en cas de problème. Un bon test est une science, mais même un test intelligent est mieux que de ne pas l'avoir. L'essentiel est de ne pas compter sur "peut-être".

Le gel des changements pendant une charge élevée est le seul outil fiable.

Que faire des services d'affiliation, nous en avons déjà discuté dans un article précédent. En bref - déconnectez sans pitié pour tout problème. Le plus souvent, de nombreux utilisateurs du service ont immédiatement des problèmes et contacter le support technique est une mesure peu efficace. Vos lettres ne les aideront pas à réparer plus rapidement, dans de telles heures, le service informatique du service est chaud sans eux.

Cependant, si vous ne signalez pas le problème et n'obtenez pas le numéro d'incident avec l'heure à laquelle il a commencé, vous ne pourrez probablement pas facturer au service une pénalité pour violation du SLA.

Un peu de fiabilité

Dans le cadre de la préparation, vous devez modifier tous les services matériels et de cluster défaillants. Plus à ce sujet dans l' un de mes articles précédents.

Je voudrais attirer votre attention sur l'idée fausse suivante: il semble à beaucoup que le transfert d'un site de ses serveurs vers le cloud donne immédiatement une fiabilité de +100. Malheureusement, seulement +20.

Pour augmenter la tolérance aux pannes d'un serveur virtuel, le cloud commercial automatise et accélère simplement le "remplacement" du matériel tombé en quelques secondes, soulevant automatiquement la machine virtuelle sur l'un des serveurs en direct. Mots-clés - "accélère" et "fer tombé". La machine virtuelle sera toujours redémarrée. VMware Fault Tolerance et ses analogues qui vous permettent d'échapper à un redémarrage ne sont généralement pas utilisés dans la virtualisation commerciale en raison de la consommation de ressources et des performances réduites des machines virtuelles protégées. D'où la conclusion: un cloud commercial n'est pas une panacée pour la tolérance aux pannes, ses principaux avantages sont la flexibilité et l'évolutivité.

Regardez dans l'historique du nombre de temps d'arrêt que vous avez dû remplacer ou réparer de l'équipement physique. Après avoir déménagé dans le cloud, leur nombre diminuera et - oui, la vie deviendra un peu plus facile pour vous. Vous n'avez pas besoin de courir vers un entrepôt ou un magasin pour un nouveau serveur. Mais maintenant, les blagues sur la virtualisation seront ajoutées aux plantages de fer.

Il peut arriver que la machine soit devenue indisponible, mais l'hôte physique répond toujours. Le cloud ne verra pas ce problème. Ou exactement le contraire: l'hôte ne répond pas, mais tout va bien avec les machines virtuelles. Dans ce cas, la virtualisation les soulèvera ailleurs. Cela prendra un certain temps pour commencer, et encore une fois, vous tomberez au ralenti à l'improviste. Et sous charge, cela peut être fatal. Par conséquent, même dans le cloud, vous devez vous rappeler de la redondance. Soit dit en passant, avertir le fournisseur de virtualisation des machines qui se sauvegardent est une excellente idée. Sinon, il peut arriver que toutes vos voitures se retrouvent sur le même serveur physique et meurent en même temps.

• Lors de l'exécution de tests de charge, il est judicieux de planifier des tests de tolérance aux pannes sous charge.
  

C'est à ce moment-là que, pendant le test de charge, vous déposez le nœud dans le cluster et voyez ce qui se passe. Avec des clusters correctement configurés et des ressources correctement allouées, cela ne devrait pas nuire aux résultats des tests et provoquer un tas d'erreurs.

Il semble que nous ayons fini tous les «tambours» typiques. Avant de poursuivre la lecture, je vous recommande d'actualiser les détails techniques décrits dans l'article précédent . Après tout, si le site est techniquement incapable de résister à la charge, la vitesse de réaction ne vous sauvera pas.

Voyons maintenant comment se préparer à l'insolite ou au soudain. Nous ne pouvons pas les empêcher par définition, il reste donc à retrousser nos manches et à apprendre à les réparer le plus rapidement possible.

Étapes pour résoudre un incident

Considérez ce qui constitue le temps d'éliminer l'accident:

1. Vitesse de détection des pannes - surveillance du retard, réception d'un message de l'utilisateur, etc.
   
2. Temps de réponse à l'incident détecté - quelqu'un devrait remarquer le rapport et le traiter.
   
3. Il était temps de confirmer la présence de l'incident - y avait-il un garçon?
   
4. Il est temps d'analyser l'incident et de trouver des solutions.
   
5. Il est temps de résoudre l'incident et les problèmes. Il n'est pas toujours possible de tout réparer du premier coup, et cette étape peut avoir plusieurs itérations.
   

Habituellement, un service d'assistance est responsable du dépannage. Si l'équipe est grande, chacune de ces étapes peut être effectuée par différentes personnes. Et le temps, comme vous le savez, c'est de l'argent. Dans notre cas, littéralement. Le Black Friday a une durée fixe et les concurrents sont en alerte - les clients peuvent tout dépenser avec eux. En conséquence, il est essentiel que chaque employé connaisse son domaine de responsabilité et que les incidents soient résolus par le convoyeur.

Examinons chaque étape séparément, identifions les points problématiques et examinons les moyens de les optimiser rapidement.

Tous les conseils, astuces et recommandations ci-dessous ne sont pas une recette pour une «belle vie», mais des choses spécifiques que vous pourrez mettre en œuvre dans les 3-4 prochains mois jusqu'au Black Friday.

Détecter un accident

Dans le scénario le plus infructueux, le client vous informe des problèmes. Autrement dit, le problème est si grave qu'il a passé son temps à faire rapport . Dans ce cas, seul un client très dédié écrira ou appellera, et un simple utilisateur partira avec un haussement d'épaules.

De plus, le client n'a souvent pas directement accès au service informatique. Par conséquent, il écrit à info@business.ru ou appelle des filles depuis un centre d'appels. Lorsque les informations remontent jusqu'à l'informatique, beaucoup de temps passera.

Supposons que nous ayons beaucoup de clients fidèles, et chacun d'entre eux considère qu'il est de son devoir d'écrire sur les problèmes de TP. Bien que l'incident soit classé comme massif, alors qu'il s'intensifie et se décide, les heures passeront. Dans le même temps, des appels individuels peuvent être perdus et le courrier info@business.ru n'est parfois pas ratissé pendant des semaines.

Par conséquent, il sera très utile de démarrer une surveillance indépendante des principaux paramètres commerciaux. Au moins - le nombre d'utilisateurs sur le site, le nombre d'achats effectués et leur ratio. Ces données vous permettront de réagir rapidement en cas de problème et de réduire considérablement le temps d'identification (et de résolution) d'un problème spécifique sur le site.

Pas d'utilisateurs? Nous devons voir où ils pourraient aller. Il y a des utilisateurs sur le site, mais pas de ventes? C'est un signal du problème, et assez tard. Les tests de scénario automatisés vous aideront à découvrir que quelque chose s'est produit quelque part . En règle générale, les tests automatiques s'exécutent sur des versions ou des versions, mais ils conviennent parfaitement à la surveillance. Avec leur aide, vous pouvez voir la panne ou le ralentissement d'un processus métier important à travers les yeux de l'utilisateur.

Bien sûr, si vous n'avez pas de test de scénario, pour les quelques mois restants jusqu'au Black Friday, vous ne couvrirez pas tous les tests productifs. Oui, et ils peuvent donner une lourde charge. Mais avec les tests d'une dizaine de processus de base, il est tout à fait possible d'être dans le temps.

Il est également très utile de suivre le temps de réponse moyen du serveur. S'il augmente, vous pouvez vous attendre à des problèmes de vente. Ces données devraient être surveillées automatiquement par le système de surveillance.

Comme vous pouvez le voir, avec une surveillance compétente, vous pouvez réduire le temps nécessaire pour détecter un problème de quelques heures et jours à quelques minutes, et parfois voir le problème avant qu'il n'atteigne sa pleine hauteur.

Temps de réponse aux incidents

Nous avons fait un excellent travail et grâce à la surveillance, nous avons instantanément détecté une défaillance. Vous devez maintenant démarrer l'incident, attribuer la priorité, acheminer et affecter la personne responsable du traitement ultérieur.

Deux choses sont importantes ici:

• Recevoir une notification d'un problème dès que possible;
  
• Soyez prêt à traiter la notification rapidement.
  

De nombreux informaticiens ne sont pas habitués à répondre rapidement aux lettres même s'ils ont un client sur leur smartphone. Les notifications importantes ne doivent donc pas être envoyées par e-mail.

Utilisez SMS pour les alertes d'accident. Mieux encore, implémentez un numéroteur bot pour les cas les plus critiques. Personnellement, je n'ai vu aucune implémentation pratique de ces robots, mais si les ressources le permettent, pourquoi pas? En dernier recours, utilisez WhatsApp / Viber / Jabber. Hélas, le télégramme sur le territoire de la Fédération de Russie pour de nombreuses raisons compréhensibles ne peut pas être un canal fiable pour les notifications d'urgence.

Il peut également être utile d'escalader automatiquement un incident en l'absence de confirmation. C'est-à-dire que la surveillance notifiera la ligne suivante si le destinataire principal de la notification ne répond pas. Ce système vous assurera si quelque chose (ou quelqu'un) se passe mal.

Voyons maintenant comment fournir une réponse rapide aux messages d'échec. Tout d'abord, quelqu'un doit être prêt à être responsable de la gestion des alertes. Les alertes pour toute l'équipe sont utiles, mais uniquement pour tenir les gens à jour.

La responsabilité collective est une chose peu fiable lorsque la vitesse est requise.

Si vous ne définissez pas la montre sur un horaire clair pour la durée de l'action, vous pouvez rencontrer qu'en cas de force majeure, quelqu'un dormira et que quelqu'un n'aura pas accès à la maison. Quelqu'un sera sur la route. Et en fait, il n'y a personne pour s'attaquer au problème dans l'heure qui vient. Bien sûr, vous pouvez mettre un officier de service opérationnel 24 heures sur 24, mais il y a une nuance ici. Vous n'obligerez pas les bons spécialistes à travailler en permanence, ce qui signifie que lorsque vous en avez besoin, vous devez toujours les rechercher et les réveiller. Et ceux qui travaillent encore par roulement, sortent étroitement du contexte général de la vie de l'équipe. Cela a l'effet le plus fatal sur leur efficacité pour les tâches planifiées.

Ce qui nous sauvera, c'est que dans la plupart des projets, nous devons répondre rapidement aux messages, comprendre ce qui s'est passé et doivent être réparés de toute urgence environ 18 heures par jour. En règle générale, de 6 h à 8 h du matin à 1 h à 2 h le lendemain, jusqu'à 90% du trafic et des ventes.

Pour éviter les superpositions, il suffit de déplacer l'horaire de travail des personnes en service vers des formats tels que:

• 6: 00-15: 00 et 17: 00-02: 00 - service "à domicile";
  
• 15: 00-17: 00 - couvrir ceux dans le bureau;
  
• 02: 00-06: 00 - peu de trafic. Cependant, nommez une personne qui ne dort pas très profondément.
  

N'oubliez pas le week-end. Ce problème peut être résolu de la même manière.

Si votre activité quotidienne des utilisateurs est répartie différemment, choisissez un horaire similaire dans lequel le site en prime time ne restera pas sans surveillance.

Être en service signifie être responsable du traitement des événements de surveillance, des appels des lignes précédentes (support client) et de la surveillance du système dans son ensemble. Mais alors que tout est calme, l'officier de permanence est engagé dans son travail principal.

Assurez-vous de commencer le service quelques jours avant le début du chargement. Tout d'abord, cela garantira une fois de plus que tout le monde a tous les accès. Deuxièmement, un changement dans le mode de fonctionnement est stressant, beaucoup devront «s'installer». Et ce serait mieux si la période de dépendance ne coïncide pas avec la chaleur principale.

Super, les alertes arrivent, et c'est à ces personnes qui devraient y répondre. Mais le temps de réponse des personnes en service est fortement influencé par la présence d'alertes inutiles et non traitées, ainsi que de notifications, qui en principe n'impliquent aucune action. Il est très important de ne pas laisser d'alertes non traitées. Si de nombreux événements similaires se produisent régulièrement, recherchez la cause et réparez-le. Il ne doit y avoir aucune alarme active dans le système de surveillance.

Par expérience, si quelque chose ne peut pas être réparé rapidement ou s'il ne nécessite pas de réparation, mais qu'il «clignote», il est préférable de supprimer la notification et de créer une tâche pour le développement. Une alarme clignotant constamment devient tôt ou tard familière et cesse d'attirer l'attention. Le problème est que lorsqu'un problème réel survient, les gens peuvent confondre l'ampoule et ignorer un événement vraiment important.

Une configuration et une hiérarchisation appropriées des événements dans le système de surveillance sont toujours extrêmement importantes. Le système devrait vous informer exactement de ce qui doit être corrigé. A propos de défaillances spécifiques ou du risque de leur survenance. Vous ne réparerez pas 100% d'utilisation du processeur? Vous éliminerez les latences élevées sur le serveur WEB, car l'utilisation du processeur est une information de débogage, pas un problème. Si le Black Friday, le processeur est chargé à 100% à la charge cible, à la vitesse de réponse et en tenant compte des stocks - cela signifie que vous avez tout calculé correctement.

L'utilisation des ressources du système doit être contrôlée, mais il s'agit d'une tâche légèrement différente, qui est importante pour la planification des ressources et l'identification des zones d'impact de l'accident.

Nous avons mis en place les événements, maintenant il est important de prioriser correctement ce que nous allons corriger en premier lieu. Pour ce faire, nous allons déterminer quelles sont les différences entre les niveaux d'alertes critiques et d'avertissement. Permettez-moi de vous donner des exemples exagérés mais compréhensibles.

Critique - c'est quand vous allez chez grand-mère dans le métro, recevez une alerte et allez à la station la plus proche. Vous sortez un ordinateur portable, vous asseyez sur un petit banc et commencez à travailler - il y a eu un arrêt des ventes ou de lourdes pertes sont apparues. Autrement dit, Critical est quelque chose qui a un impact direct, mais significatif sur les utilisateurs.

Avertissement - c'est lorsque vous ne quittez pas le travail jusqu'à ce que vous le répariez. Il n'est pas nécessaire de tout jeter et de courir pour aider aux fins d'avertissement. Vous pouvez terminer / terminer et prendre une décision. Par exemple, il y avait un risque clair de problèmes critiques comme un serveur abandonné d'une paire HA, des erreurs sont tombées dans les journaux et autres. Si vous ne martelez pas et ne réparez pas consciencieusement de tels événements (ainsi que creuser les causes et effectuer des travaux pour les prévenir), il y en aura très peu.

Une autre chose qui est souvent oubliée. Ne jetez pas en service uniquement des administrateurs. Assurez-vous d'attirer les développeurs en formant des paires de travail pour chaque quart de travail. Cela nous sera utile dans les prochaines étapes.

Si le projet est fonctionnellement complexe, il est logique d'envoyer des consultants, des analystes, des testeurs et tous ceux qui peuvent être utiles en service. Assurez leur disponibilité au moins par appel. Le spécialiste devra confirmer le problème (ou vice versa) et aider à la localisation fonctionnelle - lorsque vous devez faire monter une personne pour réparation, cela vous fera gagner du temps. Je vais discuter de cette question plus en détail dans la section suivante.

Et le dernier point important. Chaque officier de permanence doit connaître à fond les contacts et les domaines de responsabilité de tous ses collègues dans les situations d'urgence. S'il ne peut pas résoudre le problème par lui-même et dans une panique commence à chercher des sauveteurs disponibles, le chaos viendra et vous perdrez beaucoup de temps.

Le respect de ces règles simples aidera à éviter les problèmes dus aux notifications manquées et garantira que lorsque l'urgence surviendra (lire à la fois «Black Friday» et «urgence»), les gens pourront résoudre les problèmes rapidement.

Confirmer l'incident

L'étape suivante après avoir reçu une notification est de comprendre ce qui s'est exactement passé et s'il y a un problème de principe: déterminer immédiatement qui a raison, l'utilisateur ou le système, n'est pas toujours facile. Le fait est que la même alerte peut être interprétée différemment selon l'angle de vue.

, , ( ), . , . , . , , «» , .

, . , ! - , «».

- . «» . , , .

— , , . , . , , . — - « », « » « , ».

, , , , «». , , . — , , , . : , , .

, . , . . , , . — , : .

. -, , , – , , , , ( , ) .



. .

. , .

, . , , :

• ;
  
• ;
  
• ;
  
• ;
  
• (, ..).
  

, , , . -. , ELK .

, , .

- , , , .

, — . , , . , . , .

- , . , , , — .

: , , , . , 3 :

1. ;
   
2. ;
   
3. .
   

. ( ). , , -, , - .

. . , , , . , , — .

. , - - , , , - . . . , , , .

, , . , . , , « » .

– SLA. SLA – , , . SLA , . , - . , .

— , . , , . .

Jusqu'à présent, c'est tout ce que je voudrais dire sur ce sujet. Je serai heureux si mes conseils, transférés aux réalités de votre entreprise, me permettent de survivre à la charge élevée calmement et confortablement.

Si vous souhaitez des conseils sur la façon d'agir dans votre situation, je vous invite à mon séminaire Black Friday. Secrets of Survival ». Dans le format de questions et réponses, nous parlerons de la préparation du site pour la croissance du trafic et discuterons des détails techniques et organisationnels de ce processus.

Le séminaire se tiendra le 16 août à Moscou. L'événement se déroulant en chambre (maximum 25 personnes), un rendez-vous est requis. Et j'attends le reste pour discussion dans les commentaires. :)