À l'approche des vacances d'hiver, de nombreux commerces de détail se tournent vers l'hypercare alors qu'ils se préparent à acheminer des biens et des services à des niveaux de pointe. Mais qu’est-ce que l’hypercare ? Chez PagerDuty, nous utilisons la définition de travail 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 support, autrement dit, il s'applique aux Black Fridays et aux Cyber Mondays, mais pas aux attaques DDoS. Il est également important de savoir que l'hypercare ne concerne pas uniquement le commerce de détail ; il a un impact n'importe lequel entreprise qui peut traverser une période de soutien élevé, y compris les sorties de produits majeurs, les sorties de jeux, les cycles d'actualités et au-delà. (Pour éviter d'associer trop d'attention au Black Friday, j'utiliserai les termes standard du secteur Go Live Day ou Release Day.)

Avec une portée aussi large, comment les entreprises peuvent-elles soutenir l'hypercare ? C'est simple : pour soutenir l'hypercare, vous devez soutenir les équipes qui fournissent le support technique, et vous pouvez le faire avec des concepts de gestion des incidents, d'observabilité et d'ingénierie du chaos.

Gestion de la réponse aux incidents est probablement ce à quoi la plupart des gens pensent en premier lorsqu’ils commencent à envisager l’hypercare. Après tout, l’hypercare est un soutien élevé et cela implique en partie de répondre 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, décrire ce qui différencie un « incident » qui nécessite un processus de réponse par rapport à tout autre problème dans vos systèmes aidera les intervenants techniques à prioriser les alertes auxquelles répondre, réduisant ainsi le temps de résolution des incidents plus importants. Chez PagerDuty, nous définissons un incident comme « toute interruption ou dégradation imprévue du service qui affecte activement la capacité des clients à utiliser nos produits ou services ».

Les incidents ont des degrés de gravité et des priorités. En termes de réponse humaine, ils nécessitent également que des personnes soient disponibles pour y répondre s'ils surviennent en dehors des heures normales de travail et nécessitent des voies d'escalade définies au cas où ils s'aggraveraient. Tout comme l'incident lui-même, tous ces éléments doivent être définis à l'avance pour garantir que vous ne perdiez pas de temps précieux le jour de la sortie si une situation doit être gérée. Guide de réponse aux incidents peut vous aider à explorer tous ces concepts plus en profondeur, et en plus de cela, je vous recommande de vous entraîner à des incidents simulés avant la mise en service (plus d'informations à ce sujet plus tard). Ceci est particulièrement important si vous apportez des modifications à vos processus ou définitions, afin que les équipes puissent les pratiquer 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 devez disposer d'un système observable. Qu'est-ce que c'est ? « Un système est observable si et seulement si vous pouvez déterminer le comportement du système en fonction 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 . On les appelle les « trois piliers » de l’observabilité : la journalisation, la surveillance/les mesures et le traçage. Disposer de nombreuses données exploitables est essentiel pour soutenir l’hypercare, car c’est ce qui permettra à votre équipe de trier et de résoudre avec succès les problèmes lorsqu’elle reçoit une notification de votre plateforme de gestion des incidents.

Si vous débutez dans un ou plusieurs de ces domaines, ne paniquez pas ! Il existe plusieurs guides de « démarrage » disponibles. Ce qui est le plus important dans les phases de démarrage n'est pas lequel outil, mais quoi données. Plus vous en savez sur vos systèmes, plus vous pouvez adapter les meilleures 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, « 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 de véritables pannes. Cela rejoint ce que j'ai mentionné plus tôt à propos de la pratique des incidents avant le jour de la sortie pour aider votre équipe à se préparer à l'hypercare. Plus ils sont entraînés à gérer les situations qui peuvent survenir et qui surviendront, plus ils sauront gérer les incidents imprévus.

Si vous débutez dans les expériences sur le chaos, effectuez d'abord des expériences hors production. En plus de donner aux humains la possibilité de pratiquer le processus de gestion des incidents, c'est également une excellente occasion de vérifier que vos outils se comportent comme prévu en fournissant les informations correctes et dans le cadre approprié. Pour des conseils supplémentaires, consultez ce post de Gremlin sur la façon de mener votre première expérience de chaos.

Au fur et à mesure que vous maîtriserez mieux les expériences de chaos, vous pourrez déplacer vos expériences de votre environnement de non-production vers l'environnement de production. Lorsque vous aurez fait cela, vous devriez être capable de construire des hypothèses, de les tester et de résoudre les problèmes qui en résultent. Vous devez également choisir des applications et des services assez ou extrêmement critiques, car ce sont ceux que vous devrez comprendre le mieux lors de la mise en service.

De plus, utilisez les communications avec les parties prenantes que vous avez développé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 que quiconque ne panique lorsqu'il voit des alertes en rafale.) Vous devez pas désactivez les alertes car elles font partie du test et vous aideront à voir si elles sont 1) exploitables, 2) routées correctement et 3) contiennent les informations correctes. En cas de doute, consultez l'expérience des autres pour obtenir des conseils. Nous avons une paire de articles de blog détaillant notre échec du vendredi m modèle. Vous pouvez également voir comment New Relic a appliqué ses expériences de chaos à la sécurité, ici .

Tout cela semble probablement beaucoup, et c'est le cas, mais le point 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 qui vise à réduire les surprises et leur impact. Pendant que vous vous préparez pour votre scénario d'hypercare, vous voudrez peut-être garder notre Liste de contrôle de préparation à Hypercare disponible pour vous aider à suivre vos progrès. Si vous avez des questions, n'hésitez pas à nous contacter. Forums communautaires —nous sommes heureux de vous aider !