DE{CODE} : Surveillance de site : l'intersection du produit, de la conception UX et de la recherche

Ne le détestez-vous pas lorsque vous découvrez que votre site ou le site de votre client est en panne… de votre client ? Ne soyez plus jamais pris au dépourvu ! Rejoignez le chef de produit senior de WP Engine Bryan Smith, la chercheuse associée UX Kate Meyer et le concepteur de produit senior Kameron Fehrmann alors qu'ils parcourent la solution de surveillance de site de WP Engine, qui fait de ce problème une relique du passé. Au cours de cette session, vous obtiendrez un aperçu détaillé du fonctionnement de la surveillance du site et de la manière dont l'intersection de la conception UX, de la recherche et du développement UX s'est réunie pour assurer l'adéquation produit-marché.

Diapositives de la session

Transcription du texte intégral

BRYAN SMITH : Bonjour, tout le monde. Je m'appelle Bryan Smith. Je suis chef de produit ici chez WP Engine. Merci beaucoup de vous joindre à nous aujourd'hui. Nous sommes ici pour vous parler de la surveillance de site, de l'intersection du produit, de la conception UX et de la recherche. Je suis accompagné aujourd'hui de Kate Meyer, l'une de nos chercheuses UX, et de Kameron Fehrmann, l'un de nos concepteurs de produits. Sur la diapositive suivante, je vais vous parler de ce qu'est la surveillance de site. Nous venons donc de sortir ce nouveau produit. C'est ce qu'on appelle la « surveillance du site ». Il est disponible en tant que module complémentaire pour les clients WP Engine. Et avec lui, vous pourrez surveiller tous les environnements de votre site associés à votre compte. Et nous vous dirons s'il y a des pannes que nous voyons sur le site ou sur notre plateforme.

Et ensuite, je vais parcourir notre ordre du jour très rapidement. Je vais donc passer en revue le produit et vous donner un aperçu ainsi qu'une plongée technique approfondie. Mais avant de faire cela, je vais laisser la parole à Kate Meyer pour qu'elle nous explique un peu comment nous sommes arrivés à ce produit. Elle passera en revue certaines techniques de recherche d'utilisateurs que nous avons utilisées. Ensuite, elle passera la parole à Kameron, qui passera en revue la conception et l'itération de nos produits. Et puis je terminerai avec la présentation du produit et une plongée technique approfondie. À vous, Kate.

KATE MEYER : D'accord. Merci, Bryan, je suis Kate. Je suis un chercheur UX ici chez WP Engine, actuellement concentré sur l'amélioration de nos offres de construction de sites. Bryan nous a donc montré ce nouveau produit formidable que nous avons maintenant. Mais comment en sommes-nous arrivés là ? Je veux revenir au début de notre chronologie et montrer comment nous utilisons le design thinking pour passer de la connaissance des informations de base sur nos utilisateurs à la sortie du produit en quelques mois seulement. Je vais me concentrer sur l'aspect recherche de notre processus et partager avec vous comment vous pouvez mettre en œuvre ces pratiques, quel que soit votre rôle, même si vous n'avez pas de chercheur UX dans votre équipe.

Comme je l'ai mentionné, nous avons utilisé ces trois phases du design thinking pour ce projet. Le design thinking est un cadre standard de l'industrie. Il s'agit essentiellement d'une approche centrée sur l'utilisateur pour résoudre un problème. Je vais décomposer notre travail en ces trois phases ici. L'été dernier, nous voulions apprendre non seulement à corriger ce qui n'allait pas avec le portail utilisateur de WP Engine, mais aussi comment nous pouvions le faire passer au niveau supérieur.

Donc, pour résoudre ce problème, nous avons utilisé la recherche générative. C'était sous la forme d'entretiens avec une variété de nos utilisateurs. Nous leur avons posé à tous une série de questions pré-écrites, toutes les mêmes questions pour tous les utilisateurs, juste pour générer une compréhension de choses comme leur travail, leurs objectifs, leurs défis, etc. Si un processus d'entretien vous semble accablant, vous pouvez également utiliser un outil d'enquête dans le même but. En fait, nous avons utilisé SurveyMonkey avec des entretiens comme un autre moyen d'obtenir des commentaires.

Au cours de cette phase de la recherche, nous avons trouvé très intéressant que, malgré les différences dans les rôles des utilisateurs, ils partagent en fait de nombreux objectifs et problèmes communs. Et c'est un très bon modèle à voir. En fait, nous voulons voir ces similitudes entre différents types d'utilisateurs, car cela nous aide à définir notre travail. Et pendant que nous menions ces entretiens et les enquêtes, nous avons commencé à remarquer certains thèmes communs dans le contexte de l'hébergement de sites Web.

Deux des objectifs dont nous n'arrêtions pas d'entendre parler étaient de ne vouloir qu'un seul outil pour surveiller et maintenir les sites Web et également détecter les problèmes avant que les clients et les visiteurs du site ne remarquent que quelque chose ne va pas. Cependant, un problème commun était que notre portail utilisateur ne permet pas actuellement aux utilisateurs d'atteindre ces objectifs. Et en fait, ce propriétaire d'agence l'a assez bien résumé en disant : « Si je peux résoudre un problème avant que le client ne le voie, c'est fantastique. Je ne veux pas recevoir ces appels de clients, "Oh, hé, devinez quoi ?" Je suis allé sur mon site Web. Ce n'est pas là. Que fais-tu aujourd'hui?'"

Une fois que vous voyez ces thèmes communs revenir encore et encore lorsque vous entendez des utilisateurs, alors vous savez qu'il est temps d'idéer. Nous savions que nous devions améliorer le portail utilisateur pour aider les utilisateurs à prendre soin de leurs sites de manière proactive. Et nous savions également que notre équipe d'ingénieurs pouvait tirer parti de la technologie de nos partenaires pour résoudre un aspect du problème des utilisateurs, à savoir la surveillance de la disponibilité.

Donc, à ce stade, il aurait été très facile pour nous de plonger directement et de commencer à construire quelque chose immédiatement. Mais si vous voulez créer la bonne chose du premier coup, il est important de toujours obtenir les commentaires et les commentaires des utilisateurs pendant cette phase. Il est également très important à ce stade que toute l'équipe soit impliquée.

Vous voulez proposer de bonnes idées, mais vous devez également vous assurer que vos idées sont réalisables et qu'elles correspondent toujours aux besoins réels de vos utilisateurs. Ainsi, durant cette phase, notre concepteur a travaillé avec l'équipe d'ingénierie pour proposer une idée et s'assurer de sa faisabilité pour le suivi du site. Et ensuite, avec le chef de produit et le designer, je planifie des tests de concept afin que nous puissions présenter notre idée aux utilisateurs.

Le test de concept est un type de recherche qui vous aide à savoir si l'idée que vous avez correspond aux attentes et aux besoins de vos utilisateurs. Nous leur montrons donc notre idée et leur posons des questions à ce sujet. Dans ce cas particulier, nous avons utilisé des maquettes LE midfill comme vous le voyez à gauche ici que le concepteur a créées avec l'aide de l'équipe d'ingénierie. Mais ce qui est formidable avec ce type de recherche, c'est que vous pouvez montrer quelque chose d'aussi simple qu'un simple stylo sur papier. Il n'a même pas besoin d'être beau.

Cette technique est vraiment géniale, car elle permet à vos utilisateurs de se concentrer sur les idées plutôt que sur la présentation visuelle. Et encore une fois, à ce stade, nous voulons vraiment savoir si votre idée va dans la bonne direction. Et un autre aspect de ceci est que vous n'avez pas à le montrer à des dizaines ou des centaines de personnes. Vous pouvez utiliser aussi peu que cinq participants pour ce type de recherche car, à ce stade, vous devriez commencer à voir certains thèmes communs dans leurs réactions à votre idée.

Ainsi, lors de nos tests de concept, nous avons appris que les attentes de nos utilisateurs correspondaient à nos plans pour ce produit. Cela nous a donc mis en bonne position pour commencer à le construire. Cependant, nous voulions toujours recueillir des commentaires, nous avons donc décidé d'opter pour une bêta fermée. Et à quoi cela ressemblait était que certains utilisateurs s'inscrivaient, ajoutaient la fonctionnalité à leur compte, puis leur demandaient des commentaires tout au long de leur processus d'utilisation de la nouvelle fonctionnalité. Et donc avoir ce petit groupe d'utilisateurs ayant accès au produit est un très bon moyen de tester la convivialité de celui-ci, de résoudre les bogues et de comprendre comment vous pourriez mieux répondre à leurs attentes avant que le produit ne soit distribué à tous. des utilisateurs.

Alors Kameron va continuer l'histoire à partir d'ici. Mais avant de laisser la recherche derrière nous, je veux conclure ce que j'espère que vous retiendrez de mon histoire. Encore une fois, ce cadre peut vous aider à passer de la compréhension des besoins des utilisateurs à la création d'un nouveau produit. Et tous les membres de votre équipe peuvent apprendre de vos utilisateurs grâce à diverses méthodes et à toutes les phases d'un projet. Lorsque vous gardez vos utilisateurs au centre de la construction, c'est ainsi que vous vous assurez que votre produit est aussi simple que possible pour vos utilisateurs et que vous vous donnez un avantage concurrentiel. Merci. Kaméron.

KAMERON FEHRMANN : Merci beaucoup, Kate. Hey tout le monde. Je suis Kaméron. Je suis un concepteur de produits senior ici chez WP Engine. Je travaille également avec des outils de construction et nos produits de commerce électronique, et je suis très heureux de vous parler de la surveillance de site aujourd'hui. Donc, voici un peu où nous en sommes dans notre chronologie. Nous avons traversé, fait nos recherches génératives, fait des tests de concept, et maintenant nous sommes sortis en version bêta. Nous avons une enquête sur le fait que nous écoutons les gens, et c'est en fait à ce moment-là que je suis entré dans le projet.

J'ai en quelque sorte rapidement été rattrapé par les recherches précédentes. Kate et Bryan ont été super instrumentaux à cet égard. Honnêtement, si nous n'avions pas déjà mis en place certaines des cadences de collaboration entre la conception et la recherche, le produit et l'ingénierie, les choses ne se seraient pas déroulées aussi facilement. Ils ont donc été d'excellents partenaires pour me faire prendre de la vitesse au milieu. Je sais que certains d'entre vous comprennent probablement comment c'est, travailler dans la vie d'une agence. Nous savions que cette base était plutôt géniale pour notre version bêta, mais que nous voulions en faire plus.

Nous avons donc en quelque sorte fait un suivi rapide après la sortie en version bêta pour améliorer un peu plus la conception. Tout d'abord, nous avons commencé avec notre statut WP Engine. Nous avons entendu des utilisateurs dire qu'ils ne savaient pas vraiment si les pannes qu'ils subissaient étaient le résultat de quelque chose qu'ils avaient fait en interne ou s'il s'agissait d'un problème de WP Engine qui était, franchement, hors de leur contrôle. Nous avons donc ajouté ce statut pour les gens afin qu'ils puissent réellement voir, hé, quelque chose se passe avec WP Engine. C'est nous, pas vous ou vice versa.

Nous avons également ajouté la fonctionnalité Ajouter, Supprimer ou Pause pour la surveillance. C'était essentiellement un moyen pour les gens d'ajouter ou de supprimer des moniteurs, puis de suspendre la surveillance en cas de besoin, et c'était juste un moyen pour les gens de personnaliser un peu plus leur expérience. Et enfin, comme vous pouvez le voir ici, nous avons signalé des pannes assez lourdement. Nous voulions nous assurer que les gens pouvaient voir clairement ce qui se passait avec leurs sites et communiquer définitivement avec les gens. Et c'est quelque chose que nous avons également entendu, qu'ils voulaient pouvoir voir leurs pannes et régler les problèmes le plus tôt possible et le plus rapidement possible.

Et voici une sorte d'avant et d'après où nous avons commencé avec la bêta et où nous nous sommes retrouvés avant de sortir. Comme vous pouvez le voir, quelques différences assez importantes. Nous nous sommes spécifiquement concentrés sur les colonnes. Des gens nous ont dit qu'ils ne comprenaient pas tout à fait ce qu'étaient les colonnes, à quoi elles servaient ou ce qu'elles signifiaient.

Nous avons donc rendu le statut de panne beaucoup plus clair pour savoir si quelque chose était en panne ou non et ce que cela signifiait. Et puis nous avons également ajouté des liens plus exploitables. Nous avons ajouté dans la définition de ce qu'est une panne, puis un lien vers un article d'assistance sur la surveillance du site afin que les gens puissent aller chercher plus d'informations s'ils le souhaitent.

L'autre chose que nous avons faite a été de lier cela plus étroitement à notre système de conception interne. C'était tellement génial de pouvoir puiser dans une sorte de bibliothèque de composants pour moi en tant que concepteur et en tant que développeurs, afin que nous puissions tous accélérer nos flux de travail. Si vous ne disposez pas déjà d'un système de conception avec lequel vous travaillez, je vous en recommande fortement un. Ils rendent simplement vos flux de travail tellement plus faciles et ils font que tout aille beaucoup plus vite. Nous avons donc pu passer de ce que vous voyez de gauche à droite assez rapidement grâce à ce système de conception.

Et voici à quoi ressemblait ce flux de travail, cette sorte d'itération pendant que nous travaillions sur la version bêta. Alors nous avons commencé. Nous avons libéré. Je recevais des commentaires de nos utilisateurs avec notre enquête et aussi des développeurs travaillant sur le produit. J'ai fait quelques modifications de conception. Je parlerais avec la triade. Nous pourrions avoir des commentaires entre nous, puis je les transmettrais aux développeurs. Ils pourraient avoir des commentaires. Nous pourrions avoir des discussions, puis nous publierions en version bêta et le cycle recommencerait.

Donc, juste pour vérifier ici, nous avons traversé, publié en version bêta. Nous avons écouté les gens dans notre enquête bêta. Et maintenant, nous sommes prêts à commencer les alertes et à vivre cette expérience. Donc les alertes, nous savions que les gens voulaient des alertes, avaient besoin d'alertes. C'est quelque chose que nous avons entendu des utilisateurs était super important et rendrait la surveillance encore plus précieuse pour eux.

Nous savions également que les utilisateurs souhaitaient être informés d'un problème avant que ce ne soit un problème pour leurs clients, un peu comme vous l'avez entendu dans notre devis. Ils ne veulent pas recevoir d'appel d'un client indiquant qu'il y a un problème ou une panne avec leur site et qu'ils ne le savaient pas eux-mêmes. Ce n'est pas bon.

L'autre chose à ce sujet est que nous avons en fait inclus deux équipes de développement supplémentaires dans ce travail, car nous voulions être en mesure de respecter notre calendrier de publication. Ce cycle que vous avez en quelque sorte vu est devenu super important parce qu'il y avait plus d'équipes. Plus de mains rendent le travail plus léger, mais peuvent aussi rendre les choses plus compliquées. Mais heureusement, nous avons pu nous en occuper pour leurs cadences. La chose que nous devions en quelque sorte déterminer avec les alertes était les canaux que nous voulions utiliser.

Ce que nous avons entendu des utilisateurs, c'est principalement que l'e-mail était leur canal de prédilection par rapport à Slack ou aux SMS, nous avons donc décidé de nous en tenir d'abord aux e-mails. Et puis nous avons en quelque sorte dû partir de là et réfléchir à tous les différents scénarios de messagerie. Nous voulions nous assurer que nos messages étaient super clairs et exploitables pour les gens, qu'ils pouvaient comprendre et agir dès que possible lorsqu'ils recevaient une alerte.

L'autre chose à laquelle nous avons dû penser, c'est que lorsque quelqu'un s'inscrit à une alerte, nous voulons nous assurer que nous confirmons qu'il est abonné. C'est juste une sorte de meilleure pratique avec l'expérience utilisateur. Et puis à l'opposé, assurez-vous que la fonction de désabonnement est en fait assez transparente pour les gens et que c'est une expérience assez facile et bonne, tout bien considéré. Donc, oui, nous avons parcouru et fait d'autres tests d'utilisateurs et d'autres recherches à ce sujet. Et nous voulions vraiment nous assurer, comme je l'ai dit, que le message était compréhensible et exploitable.

Voici donc, encore une fois, juste un côte à côte des tests avant et après. Pas beaucoup de différences folles ici. Principalement, nous avons entendu des utilisateurs dire qu'ils voulaient savoir quelles étaient les erreurs spécifiques et qu'ils voulaient plus d'informations, c'est donc ce que nous avons essayé de leur donner. Nous avons essayé de leur donner les codes d'erreur et toute autre information que nous pouvions et de clarifier un peu ce contenu. Et après cela, honnêtement, ce n'était qu'une question de travail pour la sortie. Donc, honnêtement, je veux juste souligner certains de ces points clés dont j'ai parlé et ces points de collaboration clés que nous avons tout au long de ce projet.

D'abord et avant tout, le modèle de fonctionnement de la triade était très important pour nous. Encore une fois, c'était la conception et la recherche, le produit et l'ingénierie qui travaillaient tous ensemble en équipe pour lancer ce produit. Nous avions fréquemment des synchronisations et des bases tactiles sur la conception, la recherche, l'ingénierie. Et nous posions des questions, collaborions.

Nous avons même créé notre propre chaîne Slack. Je reconnais que tout le monde ne peut pas ou n'est pas capable de le faire, mais la création de ces relations de collaboration entre la conception et le produit est vraiment importante. Et ils sont vraiment essentiels pour s'assurer que vous avez cet alignement et cette responsabilité au niveau de cette entreprise ou de cette agence lors de la création de produits.

L'autre chose que je mentionnerai, c'est que la conception et la recherche ont un partenariat aussi étroit. Je reconnais que tout le monde ne travaille pas avec un designer ou un chercheur, mais vous pouvez toujours être un défenseur de l'expérience utilisateur si vous le souhaitez. Il existe de nombreux groupes UX qui fournissent d'excellentes ressources et meilleures pratiques, vous pouvez donc toujours être un défenseur de l'utilisabilité même si ce n'est pas votre rôle principal ou si ce n'est pas quelque chose que vous faites souvent.

L'autre chose que je mentionnerai est en fait le partenariat avec le développement. J'ai travaillé en étroite collaboration avec toutes les équipes de développement sur ce projet. Je me suis souvent retrouvé à venir vers eux, leur demandant si j'étais fou de créer un design ou quelque chose du genre, et ils étaient toujours si ouverts à travailler avec moi et à fournir toutes sortes d'idées, à poser des questions.

C'était super. Nous avions une très bonne relation de collaboration. Je dirai donc que si vous travaillez avec un designer, n'hésitez pas à vous salir les mains et à collaborer avec lui. Nous aimons travailler avec des développeurs qui sont prêts à s'asseoir et à comprendre les problèmes que nous essayons de résoudre et à travailler ensemble vers cet objectif commun.

Autre chose à ce sujet, je me suis en fait impliqué dans de nombreuses cérémonies et cadences Agile que ces équipes ont. Donc, pouvoir s'asseoir, affiner le backlog ou les planifications de sprint et poser des questions, les faire me poser des questions dans le contexte du travail de développement était super précieux. Et enfin, la collaboration asynchrone. C'était vraiment la clé. Nous sommes une entreprise mondiale. Nous avons des équipes réparties dans le monde entier et nous sommes tous très occupés.

Il était donc essentiel de pouvoir créer des canaux Slack spécifiques entre les équipes pour que nous puissions tous collaborer. Kate et moi pourrions poster sur la recherche et le design. Nous pourrions obtenir des commentaires, poser des questions sans avoir à attendre un examen ou une réunion. Et je pense que je veux juste dire cela, que la situation n'a pas besoin d'être parfaite – parfaite, excusez-moi, pour que nous puissions collaborer. Vous pouvez le faire de manière asynchrone. Vous n'avez pas besoin d'attendre une réunion. Tout n'a pas besoin d'être exactement parfait pour faire avancer les choses. Alors c'est mon temps. Merci beaucoup à vous tous. Bryan, je vais vous laisser emporter et parler de notre aperçu des produits.

BRYAN SMITH : Merci beaucoup, Kameron. D'accord. Comme promis, je vais passer à un aperçu du produit, puis nous ferons une plongée technique approfondie avant de conclure. Donc suivi du site et portail. Pour ceux qui ajoutent le module complémentaire, ils auront accès à une nouvelle page de portail. C'est ce qu'on appelle la « surveillance du site ». Et à partir de cette page, vous pouvez ajouter des moniteurs, mettre en pause et supprimer. Kameron y a un peu fait allusion, mais c'est la page à partir de laquelle vous faites cela.

De plus, à partir de cette page, vous pourrez voir les pannes, le temps de disponibilité, le temps de réponse moyen pour une plage de dates sélectionnée. Vous pourrez également créer un lien vers les journaux d'erreurs spécifiques au site lorsque nous détectons des pannes, donc tout cela est possible à partir de cette page. Il y aura également des liens vers la page des préférences d'alerte, que nous aborderons ici dans une seconde.

D'ACCORD. Je veux donc passer très rapidement à une vidéo, puis nous reviendrons aux diapositives, mais ce sera une véritable démonstration de ce à quoi cette page ressemble dans le portail. Juste une chose à signaler, elle a été enregistrée avant certaines de ces images que vous avez vues de Kameron. Nous mettons donc cela à jour. Ne considérez pas cela comme exactement à quoi il ressemble, mais c'est une bonne approximation de ce que vous verrez dans le portail.

Menu. Vous verrez un lien de surveillance du site. Nous allons afficher cette page ici, et vous verrez que j'ai une liste de tous les environnements de site que je surveille. Je peux voir ces temps de réponse et la liste de tous ceux qui sont actuellement surveillés. J'ai cliqué sur ce lien d'état du moteur WP en haut, et cela m'a amené à cette page d'état du moteur WP. Kameron l'a également mentionné plus tôt, mais c'est disponible là-bas.

Lorsque je clique sur le bouton Ajouter un moniteur, je peux facilement le faire en un seul clic. Je dirais que c'est une partie importante de ce produit et de l'intégration, c'est simplement la facilité avec laquelle vous pouvez mettre en pause, supprimer ou provisionner des moniteurs. Ici, je mets en pause un moniteur. Vous verrez apparaître un petit bouton Reprendre. Ouais. Si je clique sur Reprendre, cela le réactive.

Et gardez à l'esprit que ce qu'une pause fait réellement, c'est qu'elle empêche simplement le moniteur de ping de faire un ping sur le site. Donc, chaque fois que cela est mis en pause, il n'envoie pas réellement ce ping. Ici, nous allons supprimer un moniteur. Vous verrez un écran de confirmation. Parce que lorsque vous supprimez l'un de ces moniteurs, il supprime en fait tout l'historique des pannes associé à celui-ci. Alors gardez cela à l'esprit.

Et c'est la page du portail. D'accord. Je vais maintenant revenir aux diapositives et vous parler un peu de l'alerte par e-mail, il y a donc quelques modèles différents. Kameron y a fait allusion un peu plus tôt, mais je vais approfondir un peu ici. Ainsi, une fois que vous aurez activé les alertes par e-mail, vous recevrez un modèle d'e-mail qui ressemble à ceci, indiquant que vous êtes désormais abonné aux alertes de surveillance de vos sites. Il vous donnera un lien vers notre article du centre de support, qui vous donnera plus d'informations sur le fonctionnement de ce produit. Et en bas, il y a un lien vers la page de surveillance du site que je viens de vous montrer.

D'ACCORD. Ainsi, lorsque nous détectons une panne sur votre site, vous recevez un e-mail qui ressemble à ceci. Il aura le nom du site, lorsque nous aurons détecté la panne. Il montrera également l'état de WP Engine. Maintenant, ce statut est important, car il vous montrera le statut actuel de la plateforme, de la plateforme d'hébergement. Donc, si cela semble bon mais que vous recevez toujours cet e-mail, cela indique qu'il y a en fait un problème spécifique au site.

Ce n'est pas spécifique à l'infrastructure d'hébergement, mais en fait il y a quelque chose sur votre site ou votre domaine. Et dans le contenu de l'e-mail ici, il vous montrera ce code de réponse que nous voyons. Et puis en bas, il y aura un lien vers cette page de surveillance du site. Il existe également un lien vers les journaux d'accès, car ce sera votre prochaine meilleure étape pour essayer de diagnostiquer ce qui se passe et pourquoi vous voyez cet e-mail de panne.

D'accord. Et puis, lorsque cela sera résolu, vous verrez un autre e-mail vous indiquant que votre site est de retour. La panne ne se produit plus. Nous ne le détectons plus. Cela vous indiquera également quel site est sauvegardé. Il vous dira combien de temps ce site était en panne et, encore une fois, des liens en bas. Mêmes liens en bas.

J'ai donc mentionné qu'il s'agit d'une page à laquelle vous pouvez accéder à partir de la page et du portail de surveillance du site. C'est là que vous configurez réellement vos préférences d'alerte. Donc, à partir d'ici, vous pouvez activer ou désactiver les canaux d'alerte. Vous pouvez entrer des contacts e-mail. Les contacts de messagerie proviennent de la liste des utilisateurs de votre portail, vous le verrez donc en bas à gauche. C'est juste une case à cocher.

Nous avons déjà le nom et l'adresse e-mail. Vous n'avez pas à entrer cela. Encore une fois, il extrait cela des contacts de votre portail. Mais mentionnez ici qu'il s'agira d'une page à partir de laquelle vous pourrez activer l'intégration Slack. Nous ne l'avons pas encore, mais c'est sur notre feuille de route. C'est quelque chose sur lequel nous sommes sur le point de commencer à travailler. Donc actuellement, juste des alertes par e-mail, mais Slack est sur la feuille de route.

D'accord. J'ai mentionné que nous allions entrer dans quelques détails techniques ici pour vous donner une idée de la façon dont tout cela fonctionne dans les coulisses. Tout est donc possible grâce à ce que nous appelons notre « agent de surveillance de site », et il s'agit d'une couche intermédiaire entre notre portail utilisateur et ce que l'utilisateur y fait et notre partenaire New Relic, dont nous consommons les API de surveillance et d'alerte. Ainsi, l'agent de surveillance du site centralise essentiellement les ressources de New Relic.

Il s'agit de la couche qui crée, met à jour et supprime les moniteurs ainsi que les alertes. Et c'est aussi l'endroit où nous pouvons simplement concilier et détecter toutes sortes d'erreurs, nous assurer que rien ne soit supprimé accidentellement. Il s'agit donc de cette couche interstitielle, alors parlons un peu de ce qui se passe dans un flux d'utilisateurs. Parcourons donc un flux d'utilisateurs typique. Ainsi, un utilisateur s'inscrira. Ce qui se passe, c'est qu'une vérification des droits est effectuée sur le portail pour voir s'ils ont accès à la surveillance du site.

Et dans le cas où ils le font, il vérifie le service d'autorisation WP Engine pour obtenir ce OK. Une fois qu'il a réussi cette vérification, l'utilisateur peut alors créer un moniteur à partir de cette page de surveillance du site que je vous ai montrée plus tôt dans le portail. Ils provisionnent donc manuellement ce moniteur en cliquant sur le bouton Ajouter un moniteur. Et dans les coulisses, il envoie une demande à l'API New Relic Synthetics pour réellement provisionner ce moniteur.

Maintenant, pendant que vous êtes également sur cette page du portail, vous pouvez afficher les données. Vous pouvez afficher les données historiques. D'après ce que nous avons vu en cinglant le site que vous avez configuré, vous pouvez également voir le temps de réponse moyen, le lien vers les journaux d'accès. Donc ici, un client peut voir ces données sur cette page. Ce qui se passe dans les coulisses, c'est que nous atteignons en fait une API New Relic différente. C'est leur API NerdGraph. Ainsi, l'agent de surveillance du site envoie une demande pour récupérer ces données et les afficher. Et tout cela se passe, encore une fois, via l'API NerdGraph via New Relic.

Deux autres cas d'utilisation qui seraient courants seraient le scénario Edit Monitor. Il peut donc s'agir de la mise en pause d'un moniteur existant, auquel cas l'agent enverra une demande de correctif à l'API New Relic Synthetics. Vous pouvez également déprovisionner un moniteur. Cela supprimerait un moniteur de cette page de portail que je vous ai montrée plus tôt. Cela envoie une demande de suppression à cette API Synthetics. Un client peut également modifier la configuration. Vous souhaitez peut-être modifier l'URL du domaine auquel nous envoyons cette vérification ping.

Dans ce cas, l'agent envoie une demande de correctif pour mettre à jour ce moniteur. En outre, un utilisateur peut annuler le site qui dispose d'une surveillance de site. Et dans ce cas, ce que nous ferions serait simplement d'envoyer automatiquement une demande de suppression à cette API Synthetics pour déprovisionner ce moniteur. Ou dans le cas où un client pourrait annuler l'intégralité du compte qui contient un tas de moniteurs de site différents, une demande de déprovisionnement de tous ces moniteurs est envoyée automatiquement lorsque cela est détecté. Donc, toutes ces choses sont importantes pour le flux d'utilisateurs, et l'agent de surveillance du site est ce qui rend cela possible.

D'accord. Je l'ai donc mentionné plus tôt mais, à l'avenir, nous prévoyons certainement d'intégrer Slack comme canal d'alerte supplémentaire. Nous explorons également les SMS, alors restez à l'écoute pour d'autres ajouts à l'avenir. C'est notre V1. Nous en sommes ravis et nous sommes vraiment heureux de pouvoir le lancer ici à DE{CODE}. Mais c'est vraiment la V1. Nous avons tellement de plans en magasin. Ce ne sont que quelques-uns d'entre eux. Mais restez également à l'écoute pour plus d'options de configuration avec la surveillance, plus d'améliorations du portail utilisateur, et nous continuerons à suivre ce processus itératif de recherche et de conception qui nous a conduits à ce point.

Alors sur ce, merci aux autres présentateurs, Kate et Kameron. Et merci à tous de vous joindre à nous aujourd'hui. Passez une bonne journée et allez voir la surveillance du site Merci à tous.