DE{CODE}: Monitoramento de sites: a interseção de produto, design e pesquisa de experiência do usuário

Você não odeia quando descobre que seu site ou o site de seu cliente está fora do ar... de seu cliente? Não fique cego nunca mais! Junte-se ao gerente de produto sênior do WP Engine, Bryan Smith, à pesquisadora associada de UX, Kate Meyer, e ao designer de produto sênior, Kameron Fehrmann, enquanto eles percorrem a solução de monitoramento de sites do WP Engine, que torna esse problema uma relíquia do passado. Nesta sessão, você terá uma visão detalhada de como o monitoramento do site funciona e como a interseção de UX Design, UX Research e Development se uniu para garantir o ajuste do produto ao mercado.

Slides da Sessão

Transcrição de texto completo

BRYAN SMITH : Olá a todos. Meu nome é Bryan Smith. Sou gerente de produto aqui na WP Engine. Muito obrigado por se juntar a nós hoje. Estamos aqui para conversar com você sobre monitoramento de sites, interseção de produto, design UX e pesquisa. Juntando-se a mim hoje estão Kate Meyer, uma de nossas pesquisadoras de UX, e Kameron Fehrmann, um de nossos designers de produto. No próximo slide, falarei sobre o que é o monitoramento de sites. Então, acabamos de lançar este novo produto. É chamado de “monitoramento do local”. Está disponível como um complemento para clientes do WP Engine. E com ele, você poderá monitorar qualquer ambiente do seu site que esteja associado à sua conta. E informaremos se houver algum tipo de interrupção que observarmos no site ou em nossa plataforma.

E a seguir, vou passar por nossa agenda bem rápido. Portanto, examinarei o produto e darei a você uma visão geral, bem como um mergulho técnico profundo. Mas antes de fazer isso, vou passar para Kate Meyer para nos contar um pouco sobre como chegamos a este produto. Ela passará por algumas técnicas de pesquisa de usuários que usamos. Em seguida, ela o entregará a Kameron, que passará pelo design e iteração de nosso produto. E então terminarei com a visão geral do produto e um mergulho técnico profundo. Para você, Kate.

KATE MEYER : Tudo bem. Obrigado, Bryan, sou Kate. Sou um pesquisador de UX aqui na WP Engine, atualmente focado em melhorar nossas ofertas de criação de sites. Então Bryan nos mostrou este ótimo novo produto que temos agora. Mas como viemos parar aqui? Quero voltar ao início de nossa linha do tempo e demonstrar como usamos o pensamento de design para nos levar do conhecimento de informações básicas sobre nossos usuários ao lançamento do produto em apenas alguns meses. Vou me concentrar no aspecto de pesquisa do nosso processo e compartilhar com você como você pode implementar essas práticas, independentemente da sua função, mesmo que não tenha um pesquisador de UX em sua equipe.

Como mencionei, usamos essas três fases do design thinking para este projeto. O design thinking é uma estrutura padrão da indústria. Essa é essencialmente uma abordagem centrada no usuário para resolver um problema. Vou dividir nosso trabalho nessas três fases aqui. No verão passado, queríamos aprender não apenas como consertar o que havia de errado com o portal do usuário do WP Engine, mas também como poderíamos levá-lo para o próximo nível.

Então, para resolver isso, usamos a pesquisa generativa. Isso foi na forma de entrevistas com uma variedade de nossos usuários. Fizemos a todos um conjunto de perguntas pré-escritas, todas as mesmas perguntas para todos os usuários, apenas para gerar uma compreensão de coisas como seus trabalhos, metas, desafios, etc. Se um processo de entrevista parecer complicado para você, você também pode utilizar uma ferramenta de pesquisa para o mesmo propósito. Na verdade, usamos o SurveyMonkey junto com as entrevistas apenas como outra forma de obter feedback.

Durante esta fase da pesquisa, achamos muito interessante que, apesar das diferenças nas funções dos usuários, eles realmente compartilhavam muitos objetivos comuns e pontos problemáticos. E este é realmente um ótimo padrão de se ver. Na verdade, queremos ver essas semelhanças entre diferentes tipos de usuários, porque isso nos ajuda a definir o escopo do nosso trabalho. E enquanto conduzíamos essas entrevistas e pesquisas, começamos a perceber alguns temas comuns no contexto de hospedagem de sites.

Dois dos objetivos sobre os quais sempre ouvíamos era querer apenas uma única ferramenta para monitorar e manter sites e também detectar problemas antes que os clientes e visitantes do site percebessem que algo estava errado. No entanto, um ponto problemático comum era que nosso portal do usuário não permitia que os usuários atingissem essas metas. E, na verdade, o dono da agência resumiu muito bem, dizendo: “Se eu puder resolver um problema antes que o cliente o veja, isso é fantástico. Não quero receber ligações de clientes do tipo 'Ah, ei, adivinhem? Eu fui ao meu site. Não está lá. O que você está fazendo hoje?'"

Depois de ver esses temas comuns surgindo repetidamente ao ouvir os usuários, você sabe que é a hora de idealizar. Sabíamos que precisávamos melhorar o portal do usuário para ajudar os usuários a cuidar de seus sites de forma proativa. E também sabíamos que nossa equipe de engenharia poderia aproveitar a tecnologia de parceiros para abordar um aspecto do ponto problemático dos usuários, que era por meio do monitoramento do tempo de atividade.

Então, neste ponto, teria sido muito fácil para nós simplesmente mergulhar de cabeça e começar a construir algo imediatamente. Mas se você quiser construir a coisa certa da primeira vez, é importante ainda obter feedback e entrada do usuário durante esta fase. Também é muito importante nesta fase ter toda a equipe envolvida.

Você quer ter ótimas ideias, mas também precisa garantir que suas ideias sejam viáveis ​​e que ainda estejam alinhadas com o que seus usuários realmente precisam. Então, durante essa fase, nosso projetista trabalhou com a equipe de engenharia para ter uma ideia e garantir a viabilidade dela para o monitoramento do local. E então, com o gerente de produto e o designer, planejo alguns testes de conceito para que possamos colocar nossa ideia na frente dos usuários.

O teste de conceito é um tipo de pesquisa que ajuda você a saber se a ideia que você tem corresponde às expectativas e necessidades de seus usuários. Então, mostramos a eles nossa ideia e fazemos perguntas sobre ela. Neste caso específico, usamos maquetes LE de preenchimento médio como você vê à esquerda aqui que o designer criou com a ajuda da equipe de engenharia. Mas o bom desse tipo de pesquisa é que você pode mostrar algo tão simples quanto uma caneta no papel. Não precisa nem ter uma boa aparência.

Essa técnica é realmente ótima, porque permite que seus usuários se concentrem nas ideias em vez da apresentação visual. E, novamente, nesta fase, realmente queremos saber se sua ideia está indo na direção certa. E outro aspecto disso é que você não precisa mostrá-lo para dezenas ou centenas de pessoas. Você pode usar apenas cinco participantes para esse tipo de pesquisa porque, nesse ponto, você deve começar a ver alguns temas comuns em suas reações à sua ideia.

Assim, durante nosso teste de conceito, descobrimos que as expectativas de nossos usuários estavam alinhadas com nossos planos para este produto. Isso nos colocou em uma boa posição para começar a construí-lo. Ainda queríamos obter feedback, então decidimos fazer um beta fechado. E o que parece é que alguns usuários aceitam, adicionam o recurso à conta e pedem feedback durante o processo de uso do novo recurso. E ter esse pequeno grupo de usuários com acesso ao produto é uma ótima maneira de testar a usabilidade dele, resolver bugs e apenas entender como você pode atender melhor às expectativas deles antes que o produto seja lançado para todos. dos usuários.

Então Kameron vai continuar a história daqui. Mas antes de deixarmos a pesquisa para trás, quero encerrar o que espero que você tire da minha história. Então, novamente, essa estrutura pode ajudá-lo a compreender as necessidades do usuário para criar um novo produto. E qualquer pessoa em sua equipe pode aprender com seus usuários por meio de vários métodos e em todas as fases de um projeto. Quando você mantém seus usuários no centro da construção, é assim que você vai garantir que seu produto seja o mais fácil possível para seus usuários e se dê uma vantagem competitiva. Obrigado. Camarão.

KAMERON FEHRMANN : Muito obrigado, Kate. Olá a todos. Eu sou Kameron. Sou designer de produto sênior aqui na WP Engine. Também trabalho com ferramentas de construção e nossos produtos de comércio eletrônico e estou muito animado para falar com vocês sobre monitoramento de sites hoje. Então aqui é onde estamos em nossa linha do tempo. Passamos por isso, fizemos nossa pesquisa generativa, fizemos alguns testes de conceito e agora lançamos para beta. Temos uma pesquisa de que estamos ouvindo as pessoas, e esse foi realmente o ponto em que entrei no projeto.

Eu meio que rapidamente fui pego na pesquisa anterior. Kate e Bryan foram super instrumentais nisso. Honestamente, se já não tivéssemos algumas das cadências de colaboração estabelecidas entre design e pesquisa, produto e engenharia, as coisas não teriam corrido tão bem. Portanto, eles foram ótimos parceiros para me atualizar no meio. Sei que alguns de vocês provavelmente entendem como é trabalhar na vida de uma agência. Sabíamos que essa base era ótima para nosso beta, mas queríamos fazer mais com ela.

Então, nós meio que fizemos um acompanhamento rápido depois que lançamos a versão beta para melhorar um pouco mais o design. Em primeiro lugar, começamos com nosso status WP Engine. Ouvimos dos usuários que eles não tinham certeza se as interrupções que estavam enfrentando eram resultado de algo que haviam feito internamente ou se era um problema do WP Engine que estava, francamente, fora de seu controle. Então, adicionamos esse status para as pessoas, para que pudessem ver, ei, algo está acontecendo com o WP Engine. Somos nós, não você ou vice-versa.

Também adicionamos o recurso Adicionar, Remover ou Pausar para monitoramento. Essa era basicamente uma maneira de as pessoas adicionarem ou removerem monitores e também pausarem o monitoramento quando necessário, e era apenas uma maneira de as pessoas personalizarem um pouco mais sua experiência. E, por último, como você pode ver aqui, identificamos interrupções bastante pesadas. Queríamos garantir que as pessoas pudessem ver claramente o que estava acontecendo com seus sites e se comunicar definitivamente com as pessoas. E isso é algo que ouvimos também, que eles queriam poder ver suas interrupções e resolver os problemas o mais rápido possível.

E aqui está uma espécie de antes e depois de onde começamos com o beta e onde terminamos antes do lançamento. Como você pode ver, algumas diferenças bem grandes. Focamos especificamente nas colunas. Ouvimos de pessoas que elas não estavam entendendo bem o que eram as colunas ou para que serviam ou o que qualquer uma das coisas dentro delas significava.

Portanto, deixamos o status de interrupção muito mais claro sobre se algo estava ou não em interrupção e o que isso significava. E também adicionamos alguns links mais acionáveis. Adicionamos a definição do que é uma interrupção e, em seguida, um link para um artigo de suporte sobre monitoramento de sites para que as pessoas possam encontrar mais informações, se quiserem.

A outra coisa que fizemos foi vincular isso mais de perto ao nosso sistema de design interno. Foi tão bom poder extrair de uma espécie de biblioteca de componentes para mim como designer e desenvolvedores, para que pudéssemos fazer nossos fluxos de trabalho mais rápidos. Se você ainda não tem um sistema de design com o qual está trabalhando, eu recomendo um. Eles apenas tornam seus fluxos de trabalho muito mais fáceis e tornam tudo muito mais rápido. Portanto, conseguimos ir do que você vê à esquerda para a direita rapidamente por causa desse sistema de design.

E aqui está como era esse fluxo de trabalho, essa iteração enquanto trabalhávamos na versão beta. Então começamos. Nós liberamos. Eu estava recebendo feedback de nossos usuários com nossa pesquisa e também dos desenvolvedores que trabalham no produto. Fiz algumas alterações de design. Eu falaria com a tríade. Poderíamos ter algum feedback apenas entre nós, e então eu o passaria para os desenvolvedores. Eles podem ter algum feedback. Poderíamos ter alguma discussão e então lançaríamos para beta e o ciclo recomeçaria.

Então, apenas para verificar aqui, nós passamos, lançamos para beta. Ouvimos as pessoas em nossa pesquisa beta. E agora, estamos prontos para iniciar os alertas e obter essa experiência. Portanto, alertas, sabíamos que as pessoas queriam alertas, precisavam de alertas. Isso foi algo que ouvimos dos usuários, era super importante e tornaria o monitoramento ainda mais valioso para eles.

Também sabíamos que os usuários queriam ser notificados sobre um problema antes que se tornasse um problema para seus clientes, como você ouviu em nossa citação. Eles não querem receber uma ligação de um cliente informando que há um problema ou uma interrupção em seu site e eles próprios não sabiam disso. Isso não é bom.

A outra coisa sobre isso é que incluímos mais duas equipes de desenvolvimento neste trabalho, porque queríamos cumprir nosso cronograma de lançamento. Aquele ciclo que você meio que viu ficou superimportante porque tinha mais times. Mais mãos tornam o trabalho mais leve, mas também podem tornar as coisas mais complicadas. Mas, felizmente, conseguimos cuidar disso para suas cadências. O que meio que tivemos que descobrir com os alertas foram os canais que queríamos usar.

O que ouvimos principalmente dos usuários foi que o e-mail era o canal preferido deles em relação ao Slack ou SMS, então decidimos ficar com os e-mails primeiro. E então tivemos que partir daí e pensar em todos os diferentes cenários de e-mail. Queríamos ter certeza de que nossa mensagem fosse super clara e acionável para as pessoas, para que pudessem entender e agir o mais rápido possível quando recebessem um alerta.

A outra coisa em que tínhamos que pensar era que, quando alguém se inscreve para receber um alerta, queremos ter certeza de que estamos confirmando a inscrição. Isso é apenas uma prática recomendada com a experiência do usuário. E então, no extremo oposto, certificando-se de que a função de cancelamento de assinatura seja realmente perfeita para as pessoas e seja uma experiência muito fácil e boa, considerando todas as coisas. Então, sim, passamos e fizemos mais alguns testes com usuários e mais algumas pesquisas para isso. E realmente queríamos garantir, como eu disse, que a mensagem fosse compreensível e acionável.

Então, aqui está, novamente, apenas um lado a lado do teste antes e depois. Não há muitas diferenças malucas aqui. Principalmente, ouvimos dos usuários que eles queriam saber quais eram os erros específicos e queriam mais informações, então foi isso que tentamos dar a eles. Tentamos fornecer a eles os códigos de erro e qualquer outra informação que pudéssemos e apenas esclarecer um pouco esse conteúdo. E depois disso, honestamente, foi só uma questão de trabalhar para o lançamento. Sinceramente, só quero destacar algumas das principais conclusões sobre as quais falei e os principais pontos de colaboração que temos ao longo deste projeto.

Em primeiro lugar, o modelo operacional da tríade foi super importante para nós. Mais uma vez, isso foi design e pesquisa, produto e engenharia, todos trabalhando juntos como uma equipe para lançar este produto. Freqüentemente, tínhamos sincronizações e bases de toque em design, pesquisa, engenharia. E nós faríamos perguntas, colaboraríamos.

Até criamos nosso próprio canal no Slack. Eu reconheço que nem todo mundo pode ou é capaz de fazer isso, mas criar essas relações colaborativas entre design e produto é realmente importante. E eles são realmente essenciais para garantir que você tenha esse alinhamento e responsabilidade no nível da empresa ou agência ao criar produtos.

A outra coisa que mencionarei é design e pesquisa tendo uma parceria tão próxima. Reconheço que nem todo mundo trabalha com um designer ou pesquisador, mas você ainda pode ser um defensor da experiência do usuário, se quiser. Existem muitos grupos de UX por aí que fornecem ótimos recursos e práticas recomendadas, para que você ainda possa ser um defensor da usabilidade, mesmo que isso não seja sua função principal ou não seja algo que você faça com frequência.

A outra coisa que vou mencionar é na verdade a parceria com o desenvolvimento. Trabalhei de perto com todas as equipes de desenvolvimento neste projeto. Muitas vezes me peguei indo até eles, perguntando se eu era louco por criar um design ou algo assim, e eles sempre estavam tão abertos para trabalhar comigo e meio que fornecer todos os tipos de insights, fazer perguntas.

Foi ótimo. Tínhamos um ótimo tipo de relacionamento colaborativo. Portanto, direi, se você estiver trabalhando com um designer, não hesite em colocar a mão na massa e colaborar com eles. Adoramos trabalhar com desenvolvedores que estão dispostos a sentar e entender os problemas que estamos tentando resolver e meio que trabalhar juntos para atingir esse objetivo comum.

Outra coisa sobre isso, eu realmente me envolvi em muitas das cerimônias e cadências ágeis que essas equipes têm. Portanto, poder sentar, refinamentos de backlog ou planejamento de sprint e fazer perguntas, fazer com que eles me façam perguntas no contexto do trabalho de desenvolvimento foi super valioso. E por último, mas não menos importante, colaboração assíncrona. Isso foi realmente fundamental. Somos uma empresa global. Temos equipes em todo o mundo e estamos todos muito ocupados.

Portanto, poder criar canais específicos do Slack entre as equipes para que todos nós colaborássemos foi realmente fundamental. Kate e eu poderíamos postar sobre pesquisa e design. Poderíamos obter feedback, fazer perguntas sem ter que esperar por uma revisão ou uma reunião. E acho que só quero ressaltar isso, que a situação não precisa ser perfeita – perfeita, desculpe-me, para que possamos colaborar. Você pode fazer isso de forma assíncrona. Você não precisa esperar por uma reunião. Nem tudo precisa estar exatamente certo para que as coisas sejam feitas. Então é a minha vez. Obrigado a todos vocês. Bryan, vou deixar você falar sobre nossa visão geral do produto.

BRYAN SMITH: Muito obrigado, Kameron. Tudo bem. Como prometido, vou pular para uma visão geral do produto e, em seguida, faremos um mergulho técnico profundo antes de fecharmos. Portanto, monitoramento de sites e portal. Para aqueles que adicionam o complemento, eles terão acesso a uma nova página do portal. É chamado de “monitoramento do local”. E nesta página, você pode adicionar monitores, pausar e excluir. Kameron aludiu um pouco a isso, mas esta é a página a partir da qual você faz isso.

Além disso, nessa página, você poderá visualizar interrupções, tempo de atividade e tempo médio de resposta para um intervalo de datas selecionado. Você também poderá vincular a logs de erros específicos do site quando detectarmos interrupções, portanto, tudo isso é possível nesta página. Também haverá links para a página Preferências de alerta, que abordaremos aqui em apenas um segundo.

OK. Então, eu quero pular para um vídeo bem rápido e, em seguida, vamos pular de volta para os slides, mas esta será uma demonstração real de como essa página se parece no portal. Apenas uma coisa para chamar, foi gravado antes de algumas dessas imagens que você viu de Kameron. Então, estamos atualizando isso. Não tome isso exatamente como parece, mas é uma boa aproximação do que você verá no portal.

Cardápio. Você verá um link de monitoramento do site. Abriremos esta página aqui e você verá que tenho uma lista de todos os ambientes de site que estou monitorando. Posso ver esses tempos de resposta e a lista de todos eles que estão sendo monitorados no momento. Cliquei no link de status do WP Engine na parte superior e ele me levou a esta página de status do WP Engine. Kameron também mencionou isso anteriormente, mas está disponível lá.

Quando clico no botão Adicionar monitor, posso fazer isso facilmente com apenas um clique. Eu diria que é uma grande parte deste produto e integração, é apenas a facilidade com que você pode pausar, excluir ou provisionar monitores. Aqui, estou pausando um monitor. Você verá um pequeno botão Continuar aparecer lá. Sim. Se eu clicar em Resume, ele será retomado.

E lembre-se, o que uma pausa realmente faz é apenas impedir que o monitor de ping execute o ping no site. Portanto, sempre que está em pausa, não está realmente enviando esse ping. Aqui, vamos remover um monitor. Você verá uma tela de confirmação. Porque quando você exclui um desses monitores, ele realmente remove todo o histórico de interrupção associado a ele. Então, tenha isso em mente.

E essa é a página no portal. Tudo bem. Vou voltar aos slides agora e falar um pouco sobre o alerta por e-mail, então existem alguns modelos diferentes. Kameron aludiu a isso um pouco antes, mas vou me aprofundar um pouco mais aqui. Assim que você optar por receber alertas por e-mail, receberá um modelo de e-mail semelhante a este, mostrando que agora você se inscreveu para receber alertas de monitoramento de seus sites. Ele fornecerá um link para o nosso artigo do Centro de Suporte, que fornecerá mais informações sobre como este produto funciona. E na parte inferior, há um link para a página de monitoramento do site que acabei de mostrar.

OK. Portanto, quando detectarmos uma interrupção em seu site, você receberá um e-mail parecido com este. Terá o nome do site, quando detectamos a interrupção. Ele também mostrará o status do WP Engine. Agora esse status é importante, porque ele vai te mostrar o status atual da plataforma, da plataforma de hospedagem. Então, se isso parece bom, mas você ainda está recebendo este e-mail, isso indica que há realmente um problema específico do site.

Não é específico da infraestrutura de hospedagem, mas na verdade existe algo no seu site ou no seu domínio. E no conteúdo do e-mail aqui, ele mostrará o código de resposta que estamos vendo. E, na parte inferior, haverá um link para a página de monitoramento do site. Há também um link para os logs de acesso, porque este será o próximo melhor passo para tentar diagnosticar o que está acontecendo e por que você está vendo este e-mail de interrupção.

Tudo bem. E então, quando isso for resolvido, você verá outro e-mail que mostra que seu site está de volta. A interrupção não está mais ocorrendo. Não estamos mais detectando. Isso também informará qual site está de volta. Ele dirá quanto tempo o site ficou fora do ar e, novamente, os links na parte inferior. Mesmos links abaixo na parte inferior.

Mencionei que esta é uma página que você pode acessar na página e no portal de monitoramento do site. É aqui que você realmente configura suas preferências de alerta. A partir daqui, você pode habilitar ou desabilitar os canais de alerta. Você pode inserir contatos de e-mail. Os contatos de e-mail vêm da lista de usuários do seu portal, então você verá isso lá embaixo, à esquerda. É apenas uma caixa de seleção.

Já temos o nome e endereço de e-mail. Você não precisa inserir isso. Novamente, está puxando isso de seus contatos do portal. Mas mencione aqui que esta será uma página na qual você poderá ativar a integração com o Slack. Ainda não temos isso, mas está em nosso roteiro. É algo em que estamos prestes a começar a trabalhar. Atualmente, apenas alertas por e-mail, mas o Slack está no roteiro.

Tudo bem. Mencionei que entraríamos em alguns detalhes técnicos aqui para dar a você apenas uma ideia de como tudo isso funciona nos bastidores. Tudo isso é possível por meio do que chamamos de “Agente de monitoramento do site”, e essa é uma camada intermediária entre nosso portal do usuário e o que o usuário está fazendo lá e nosso parceiro New Relic, cujas APIs de monitoramento e alerta estamos consumindo. Portanto, o Site Monitoring Agent basicamente centraliza os recursos da New Relic.

Esta é a camada que cria, atualiza e exclui monitores, bem como alertas. E também é o lugar onde podemos simplesmente reconciliar e identificar qualquer tipo de erro, garantindo que nada seja removido acidentalmente. Essa é a camada intersticial, então vamos falar um pouco sobre algumas das coisas que estão acontecendo em um fluxo de usuário. Então, vamos percorrer um fluxo de usuário típico. Assim, um usuário se inscreverá. O que acontece é que é feita uma checagem de habilitação ao portal para ver se eles têm acesso ao monitoramento do site.

E caso o façam, ele verifica o serviço de autorização do WP Engine para obter esse OK. Depois de passar nessa verificação, o usuário pode criar um monitor a partir da página Monitoramento do site que mostrei anteriormente no portal. Então, eles provisionam manualmente esse monitor clicando no botão Adicionar monitor. E, nos bastidores, está enviando uma solicitação para a API New Relic Synthetics para realmente provisionar esse monitor.

Agora, enquanto você também está na página do portal, pode visualizar os dados. Você pode visualizar dados históricos. Pelo que vimos ao fazer ping no site que você configurou, você também pode ver o tempo médio de resposta, link para logs de acesso. Aqui, um cliente pode visualizar esses dados nessa página. O que está acontecendo nos bastidores é que, na verdade, estamos acessando uma API New Relic diferente. É a API NerdGraph deles. Portanto, o Site Monitoring Agent envia uma solicitação para recuperar esses dados e exibi-los. E tudo isso está acontecendo, novamente, por meio da API NerdGraph por meio da New Relic.

Alguns outros casos de uso que seriam comuns seriam o cenário Edit Monitor. Portanto, isso pode estar pausando um monitor existente e, nesse caso, o agente enviará uma solicitação de patch para a API New Relic Synthetics. Você também pode desprovisionar um monitor. Isso seria excluir um monitor daquela página do portal que mostrei anteriormente. Isso está enviando uma solicitação de exclusão para essa API sintética. Um cliente também pode alterar a configuração. Talvez você queira alterar a URL do domínio para o qual estamos enviando a verificação de ping.

Nesse caso, o agente envia uma solicitação de patch para atualizar esse monitor. Além disso, um usuário pode cancelar o site que possui monitoramento de site. E, nesse caso, o que estaríamos fazendo é apenas enviar uma solicitação de exclusão automaticamente para essa API do Synthetics para desprovisionar esse monitor. Ou, no caso de um cliente cancelar toda a conta que contém vários monitores de sites diferentes, uma solicitação para desprovisionar todos esses monitores é enviada automaticamente quando isso é detectado. Portanto, todas essas coisas são importantes para o fluxo do usuário, e o Site Monitoring Agent é o que torna isso possível.

Tudo bem. Eu mencionei isso antes, mas, olhando para frente, certamente estamos planejando integrar o Slack como um canal de alerta adicional. Também estamos explorando o SMS, portanto, fique atento para mais adições no futuro. Este é o nosso V1. Estamos entusiasmados com isso e muito felizes por poder lançá-lo aqui no DE{CODE}. Mas isso realmente é V1. Temos tantos planos na loja. Estes são apenas alguns deles. Mas também fique atento para mais opções de configuração com o monitoramento, mais melhorias no portal do usuário e continuaremos a seguir o processo iterativo de pesquisa e design que temos feito e que nos levou a este ponto.

Então, graças aos outros apresentadores, Kate e Kameron. E obrigado a todos por se juntarem a nós hoje. Tenha um ótimo dia e verifique o monitoramento do site. Obrigado a todos.