À l'approche des fêtes de fin d'année, de nombreux commerces de détail se tournent vers l'hypercare pour se préparer à une activité de pointe en matière de biens et de services. Mais qu'est-ce que l'hypercare ? Chez PagerDuty, nous utilisons la définition suivante :

L'hypercare est la période pendant laquelle un niveau de support élevé est disponible pour garantir l'adoption ou le fonctionnement transparent d'un système.

Le concept clé ici est que l'hypercare est une période de prévu En d'autres termes, il est valable pour les Black Fridays et les Cyber Mondays, mais pas pour les attaques DDoS. Il est également important de savoir que l'hypercare ne concerne pas uniquement le commerce de détail ; il impacte n'importe lequel Entreprises pouvant bénéficier d'un soutien accru, notamment lors des sorties de produits majeurs, des sorties de jeux, des cycles d'actualités, etc. (Pour éviter d'associer une attention excessive au Black Friday, j'utiliserai les termes habituels du secteur : « Go Live Day » ou « Jour de sortie ».)

Avec une portée aussi vaste, comment les entreprises peuvent-elles soutenir l'hypercare ? C'est simple : pour soutenir l'hypercare, il faut soutenir les équipes qui fournissent le support technique, et cela peut se faire grâce à des concepts de gestion des incidents, d'observabilité et d'ingénierie du chaos.

Gestion de la réponse aux incidents C'est probablement la première chose à laquelle la plupart des gens pensent lorsqu'ils envisagent l'hypercare. Après tout, l'hypercare est un soutien renforcé, qui consiste notamment à réagir rapidement aux situations qui surviennent. Cependant, pour améliorer les MTTA et les MTTR, les organisations doivent définir autant de termes et de processus que possible, le plus tôt possible.

Par exemple, expliquer ce qui distingue un « incident » nécessitant une intervention d'un autre problème dans vos systèmes aidera les intervenants techniques à prioriser les alertes à traiter, réduisant ainsi le délai de résolution des incidents plus importants. Chez PagerDuty, nous définissons un incident comme « toute perturbation ou dégradation imprévue du service affectant activement la capacité des clients à utiliser nos produits ou services ».

Les incidents ont des niveaux de gravité et des priorités. En termes de réponse humaine, ils nécessitent également une disponibilité opérationnelle en cas d'incident en dehors des heures ouvrables normales et des procédures d'escalade définies en cas d'aggravation. Tout comme l'incident lui-même, ces éléments doivent être définis à l'avance afin de ne pas perdre de temps précieux le jour J si une situation nécessite une intervention. Notre guide de réponse aux incidents Cela peut vous aider à explorer tous ces concepts plus en profondeur. De plus, je recommande de vous entraîner à des incidents simulés avant la mise en service (nous y reviendrons plus tard). C'est particulièrement important si vous modifiez vos processus ou vos définitions, afin que les équipes puissent les mettre en pratique et les comprendre à l'avance.

Pour identifier les incidents à gérer, vous devez envoyer des données à vos plateformes de gestion des incidents et d'alerte. Pour ce faire, vous aurez besoin d'un système observable. Qu'est-ce que c'est ? « Un système est observable si, et seulement si, vous pouvez déterminer son comportement à partir de ses sorties. » (Extrait de Conférence de Greg Poirier à Monitorama 2016 .)

Lorsque les gens parlent d’observabilité, ils font généralement référence à la télémétrie Ces trois piliers sont appelés « journalisation », « surveillance/mesures » et « traçage ». Disposer de données exploitables est essentiel pour soutenir l'hypercare, car c'est ce qui permettra à votre équipe de trier et de résoudre efficacement les problèmes lorsqu'elle recevra une notification de votre plateforme de gestion des incidents.

Si vous débutez dans un ou plusieurs de ces domaines, pas de panique ! Plusieurs guides de démarrage sont disponibles. L'essentiel au début n'est pas lequel outil, mais quoi Données. Plus vous en savez sur vos systèmes, plus vous pouvez adapter les bonnes pratiques que vous trouvez pour (par exemple) « surveiller Kubernetes » à vos déploiements spécifiques.

L'un de nos partenaires, Datadog, propose une excellente série en trois parties sur surveillance efficace , et cet article de TechBeacon est riche en ressources, avec des liens vers des articles sur diverses applications et systèmes qui peuvent être surveillés et enregistrés, tels que la journalisation réseau, les différences entre les piliers, comment utiliser OWASP pour la journalisation sécurisée et comment choisir un traceur.

Une fois que vous vous sentez à l'aise avec les éléments essentiels des trois piliers, jetez un œil à l'article de Charity Major, CTO de Honeycomb.io, « Une rétrospective de 3 ans ”, qui met en évidence certaines des lacunes de l’observabilité, ainsi que ce qui peut être fait pour les surmonter.

Et maintenant la dernière pièce : ingénierie du chaos L'ingénierie du chaos consiste à expérimenter en production pour éviter les pannes réelles. Cela rejoint ce que j'ai mentionné précédemment concernant la préparation aux incidents avant le jour de la sortie pour aider votre équipe à se préparer à l'hypercare. Plus votre équipe sera entraînée à gérer les situations qui peuvent survenir, plus elle sera habile à gérer les incidents imprévus.

Si vous débutez avec les expériences chaotiques, commencez par les réaliser hors production. En plus de permettre aux utilisateurs de mettre en pratique le processus de gestion des incidents, c'est aussi une excellente occasion de vérifier que vos outils fonctionnent comme prévu en fournissant les informations correctes et dans le cadre approprié. Pour plus d'informations, consultez ce post Gremlin sur la façon de mener votre première expérience de chaos.

À mesure que vous maîtriserez les expériences chaotiques, vous pourrez les transférer de votre environnement de non-production vers l'environnement de production. Vous serez alors capable d'élaborer des hypothèses, de les tester et de résoudre les problèmes qui en résultent. Choisissez également des applications et des services d'une importance moyenne à élevée, car ce sont eux que vous devrez maîtriser au mieux lors de la mise en production.

De plus, utilisez les communications avec les parties prenantes que vous avez élaborées pour vous assurer que les parties concernées savent que les expériences seront exécutées en production, afin que personne ne soit pris au dépourvu. (Cela permet également d'éviter toute panique face aux alertes.) Vous devriez pas Désactivez les alertes, car elles font partie du test et vous aideront à déterminer si elles sont 1) exploitables, 2) correctement acheminées et 3) contiennent les informations correctes. En cas de doute, consultez l'expérience d'autres utilisateurs. Nous proposons deux solutions. articles de blog détaillant notre échec du vendredi s modèle. Vous pouvez également voir comment New Relic a appliqué ses expériences sur le chaos à la sécurité, ici .

Tout cela peut paraître beaucoup, et c'est le cas, mais l'essentiel à retenir est que l'objectif de l'hypercare est d'éliminer les surprises. Chacun des sujets abordés est une pratique d'ingénierie visant à réduire les surprises et leur impact. En préparant votre scénario d'hypercare, gardez notre guide à portée de main. Liste de contrôle de préparation à Hypercare disponible pour vous aider à suivre vos progrès. Pour toute question, n'hésitez pas à nous contacter. Forums communautaires —nous sommes heureux de vous aider !