DE{CODE}: Мониторинг сайта: пересечение продукта, UX-дизайна и исследований

Разве вы не ненавидите, когда вы узнаете, что ваш сайт или сайт вашего клиента не работает… от вашего клиента? Не ослепляй никогда больше! Присоединяйтесь к старшему менеджеру по продуктам WP Engine Брайану Смиту, младшему исследователю UX Кейт Мейер и старшему дизайнеру продуктов Камерону Ферманну, когда они знакомятся с решением для мониторинга сайта WP Engine, что делает эту проблему пережитком прошлого. На этом занятии вы подробно рассмотрите, как работает мониторинг сайта и как пересечение UX-дизайна, UX-исследований и разработки объединилось для обеспечения соответствия продукта рынку.

Слайды сессии

Полный текст стенограммы

БРАЙАН СМИТ : Всем привет. Меня зовут Брайан Смит. Я менеджер по продукту в WP Engine. Большое спасибо, что присоединились к нам сегодня. Мы здесь, чтобы поговорить с вами о мониторинге сайта, пересечении продукта, дизайна UX и исследований. Сегодня ко мне присоединяются Кейт Мейер, один из наших UX-исследователей, и Камерон Ферманн, один из наших продуктовых дизайнеров. На следующем слайде я расскажу вам, что такое мониторинг сайта. Итак, мы только что выпустили этот новый продукт. Это называется «мониторинг сайта». Он доступен в качестве надстройки для клиентов WP Engine. И с его помощью вы сможете отслеживать любую среду вашего сайта, связанную с вашей учетной записью. И мы сообщим вам, если мы увидим какие-либо сбои на сайте или на нашей платформе.

А затем я быстро пройдусь по нашей повестке дня. Итак, я пройдусь по продукту и дам вам обзор, а также глубокое техническое погружение. Но прежде чем мы это сделаем, я передам это Кейт Мейер, чтобы она немного рассказала нам о том, как мы пришли к этому продукту. Она расскажет о некоторых методах исследования пользователей, которые мы использовали. Затем она передаст его Кэмерон, который займется дизайном и итерацией нашего продукта. И затем я закончу это обзором продукта и глубоким техническим погружением. Тебе слово, Кейт.

КЕЙТ МЕЙЕР : Хорошо. Спасибо, Брайан, я Кейт. Я исследователь UX здесь, в WP Engine, и в настоящее время сосредоточен на улучшении наших предложений по созданию сайтов. Итак, Брайан показал нам этот замечательный новый продукт, который у нас есть сейчас. Но как мы здесь оказались? Я хочу вернуться к началу нашей временной шкалы и продемонстрировать, как мы используем дизайн-мышление, чтобы перейти от знания базовой информации о наших пользователях к выпуску продукта всего за несколько месяцев. Я собираюсь сосредоточиться на исследовательском аспекте нашего процесса и поделиться с вами тем, как вы можете реализовать эти практики, независимо от вашей роли, даже если в вашей команде нет UX-исследователя.

Как я уже упоминал, мы использовали эти три фазы дизайн-мышления для этого проекта. Дизайн-мышление — это отраслевой стандарт. По сути, это ориентированный на пользователя подход к решению проблемы. Я собираюсь разбить нашу работу на эти три этапа. Прошлым летом мы хотели узнать, как не только исправить то, что было не так с пользовательским порталом WP Engine, но и узнать, как мы могли бы вывести его на новый уровень.

Чтобы решить эту проблему, мы использовали генеративное исследование. Это было в форме интервью с различными нашими пользователями. Мы задали им набор заранее написанных вопросов, одни и те же вопросы для всех пользователей, просто чтобы получить представление о таких вещах, как их работа, цели, проблемы и так далее. Если процесс собеседования кажется вам чрезмерным, вы также можете использовать инструмент опроса для той же цели. На самом деле мы использовали SurveyMonkey вместе с интервью как еще один способ получить обратную связь.

На этом этапе исследования нам показалось очень интересным, что, несмотря на различия в ролях пользователей, у них на самом деле было много общих целей и болевых точек. И это действительно отличный образец, чтобы увидеть. На самом деле мы хотим видеть сходство между разными типами пользователей, потому что это помогает нам расширить границы нашей работы. И пока мы проводили эти интервью и опросы, мы начали замечать некоторые общие темы в контексте хостинга веб-сайтов.

Две из целей, о которых мы постоянно слышали, заключались в том, чтобы иметь только один инструмент для мониторинга и обслуживания веб-сайтов, а также для выявления проблем до того, как клиенты и посетители сайта заметят, что что-то не так. Однако общей проблемой было то, что наш пользовательский портал в настоящее время не позволяет пользователям достичь этих целей. И на самом деле, владелец этого агентства очень хорошо подытожил это, сказав: «Если я могу решить проблему до того, как клиент ее увидит, это фантастика. Я не хочу получать эти звонки от клиентов: «О, привет, знаешь что? Я зашел на свой сайт. Это не там. Что ты сегодня делаешь?'"

Как только вы увидите, что эти общие темы возникают снова и снова, когда вы слышите от пользователей, вы понимаете, что пришло время генерировать идеи. Мы знали, что нам нужно улучшить пользовательский портал, чтобы помочь пользователям активно заботиться о своих сайтах. Мы также знали, что наша команда инженеров может использовать партнерские технологии для решения одной из проблем пользователей, а именно путем мониторинга времени безотказной работы.

Так что в этот момент для нас было бы очень легко просто погрузиться и сразу же начать что-то строить. Но если вы хотите создать правильную вещь с первого раза, важно получать обратную связь от пользователей на этом этапе. На этом этапе также очень важно, чтобы вся команда была вовлечена.

Вы действительно хотите придумывать отличные идеи, но вам также необходимо убедиться, что ваши идеи выполнимы и что они по-прежнему соответствуют тому, что действительно нужно вашим пользователям. Поэтому на этом этапе наш дизайнер работал с командой инженеров, чтобы придумать идею и обеспечить ее осуществимость для мониторинга площадки. А затем с менеджером по продукту и дизайнером я планирую тестирование концепции, чтобы мы могли представить нашу идею пользователям.

Тестирование концепции — это тип исследования, которое помогает вам узнать, соответствует ли ваша идея ожиданиям и потребностям ваших пользователей. Поэтому мы показываем им нашу идею и задаем им вопросы о ней. В этом конкретном случае мы использовали макеты среднего заполнения LE, как вы видите здесь слева, которые дизайнер создал с помощью команды инженеров. Но самое замечательное в этом типе исследования то, что вы можете показать что-то такое же простое, как просто ручка на бумаге. Это даже не должно выглядеть хорошо.

Этот метод действительно хорош, потому что он позволяет вашим пользователям сосредоточиться на идеях, а не на визуальном представлении. И опять же, на этом этапе мы действительно хотим узнать, движется ли ваша идея в правильном направлении. И еще один аспект этого заключается в том, что вам не нужно показывать его десяткам или сотням людей. Вы можете использовать всего пять участников для этого типа исследования, потому что к этому моменту вы должны начать видеть некоторые общие темы в их реакции на вашу идею.

Таким образом, во время тестирования концепции мы узнали, что ожидания наших пользователей совпадают с нашими планами относительно этого продукта. Так что это дало нам хорошую возможность начать его строительство. Однако мы все еще хотели получить отзывы, поэтому решили провести закрытое бета-тестирование. И это выглядело так, как если бы некоторые пользователи согласились, добавили функцию в свою учетную запись, а затем попросили их оставить отзыв на протяжении всего процесса использования новой функции. Таким образом, наличие этой небольшой группы пользователей с доступом к продукту — отличный способ проверить удобство его использования, исправить ошибки и просто понять, как вы можете лучше оправдать их ожидания, прежде чем продукт будет выпущен для всех. пользователей.

Итак, Кэмерон собирается продолжить историю отсюда. Но прежде чем мы закончим исследование, я хочу подвести итог тому, что, я надеюсь, вы вынесете из моей истории. Итак, опять же, эта структура может помочь вам перейти от понимания потребностей пользователей к созданию нового продукта. И любой в вашей команде может учиться у ваших пользователей с помощью различных методов и на всех этапах проекта. Когда вы держите своих пользователей в центре разработки, именно так вы сможете убедиться, что ваш продукт максимально прост для ваших пользователей, и дать себе конкурентное преимущество. Спасибо. Камерон.

КАМЕРОН ФЕРМАНН : Большое спасибо, Кейт. Эй, вы все. Я Камерон. Я старший дизайнер продукта в WP Engine. Я также работаю с инструментами для разработки и нашими продуктами для электронной коммерции, и я очень рад сегодня поговорить с вами о мониторинге сайтов. Итак, вот где мы находимся на нашей временной шкале. Мы прошли, провели генеративное исследование, провели некоторое концептуальное тестирование, и теперь мы выпустили бета-версию. У нас есть опрос о том, что мы как бы прислушиваемся к людям, и именно с этого я и пришел в проект.

Я быстро увлекся предыдущим исследованием. Кейт и Брайан сыграли в этом огромную роль. Честно говоря, если бы у нас уже не было налажено несколько каденций сотрудничества между дизайном и исследованиями, продуктом и проектированием, все было бы далеко не так гладко. Так что они были отличными партнерами в том, чтобы догнать меня по середине. Я знаю, что некоторые из вас, вероятно, понимают, каково это — работать в агентстве. Мы знали, что этот фундамент отлично подходит для нашей бета-версии, но мы хотели сделать с ним больше.

Так что после выпуска бета-версии мы как бы быстро следили за тем, чтобы еще немного улучшить дизайн. Прежде всего, мы начали с нашего статуса WP Engine. Мы слышали от пользователей, что они не совсем уверены, были ли сбои, с которыми они столкнулись, результатом чего-то, что они сделали внутри, или это была проблема движка WP, которая, честно говоря, была вне их контроля. Поэтому мы добавили этот статус для людей, чтобы они действительно могли видеть, эй, что-то происходит с WP Engine. Это мы, а не вы или наоборот.

Мы также добавили функцию «Добавить», «Удалить» или «Пауза» для мониторинга. По сути, это был способ для людей добавлять или удалять мониторы, а затем приостанавливать мониторинг, когда это необходимо, и это был просто способ немного больше настроить свой опыт. И, наконец, как вы можете видеть здесь, мы довольно часто обнаруживали перебои в работе. Мы хотели убедиться, что люди могут четко видеть, что происходит с их сайтами, и определенно общаться с людьми. И мы также слышали, что они хотели видеть свои перебои в работе и решать проблемы как можно скорее и как можно быстрее.

И вот своего рода до и после того, где мы начали с бета-версии и где мы закончили перед выпуском. Как видите, некоторые довольно большие различия. Особое внимание мы уделили столбцам. Мы слышали от людей, что они не совсем понимали, что такое колонны, для чего они нужны или что означают какие-то вещи внутри них.

Таким образом, мы сделали статус сбоя намного более ясным, чтобы понять, было ли что-то в сбое и что это означало. А затем мы также добавили еще несколько действенных ссылок. Мы добавили в определение того, что такое сбой, а затем ссылку на статью поддержки о мониторинге сайта, чтобы люди могли найти дополнительную информацию, если захотят.

Еще одна вещь, которую мы сделали, — это более тесно привязали это к нашей внутренней системе дизайна. Было так здорово иметь возможность извлекать из своего рода библиотеки компоненты для себя как дизайнера и как разработчиков, так что мы все могли ускорить наши рабочие процессы. Если у вас еще нет дизайн-системы, с которой вы работаете, я настоятельно рекомендую ее. Они просто упрощают ваши рабочие процессы и делают все намного быстрее. Таким образом, мы смогли довольно быстро перейти от того, что вы видите слева, к правому благодаря этой системе дизайна.

И вот как выглядел этот рабочий процесс, эта итерация, когда мы работали над бета-версией. Итак, мы начали. Мы выпустили. Я получал отзывы от наших пользователей с помощью нашего опроса, а также от разработчиков, работающих над продуктом. Я внес некоторые изменения в дизайн. Я бы поговорил с триадой. У нас может быть некоторая обратная связь только среди нас, и тогда я передам ее разработчикам. У них может быть какая-то обратная связь. У нас может быть какое-то обсуждение, а затем мы выпускаем бета-версию, и цикл начинается сначала.

Итак, просто чтобы зарегистрироваться здесь, мы прошли бета-тестирование. Мы выслушали людей в нашем бета-опросе. И теперь мы готовы приступить к оповещениям и получить этот опыт. Итак, оповещения. Мы знали, что людям нужны оповещения, им нужны оповещения. Мы слышали от пользователей, что это очень важно и сделает мониторинг еще более ценным для них.

Мы также знали, что пользователи хотели быть уведомлены о проблеме до того, как она станет проблемой для их клиентов, как вы слышали в нашей цитате. Они не хотят получать звонки от клиентов о проблемах или сбоях в работе их сайта, о которых они на самом деле не знали сами. Это не хорошо.

Кроме того, мы привлекли к этой работе еще две команды разработчиков, потому что хотели уложиться в сроки выпуска. Тот цикл, который вы видели, стал очень важным, потому что было больше команд. Больше рук облегчают работу, но также могут ее усложнить. Но, к счастью, мы смогли позаботиться об этом для их ритма. Что нам нужно было выяснить с оповещениями, так это каналы, которые мы хотели использовать.

В первую очередь мы слышали от пользователей, что электронная почта была их предпочтительным каналом по сравнению со Slack или SMS, поэтому мы решили сначала придерживаться электронной почты. А затем нам как бы пришлось уйти оттуда и подумать обо всех различных сценариях электронной почты. Мы хотели убедиться, что наши сообщения были очень четкими и действенными для людей, чтобы они могли понять и принять меры как можно скорее, когда получили предупреждение.

Еще одна вещь, о которой мы должны были подумать, заключалась в том, что когда кто-то подписывается на оповещение, мы хотим убедиться, что подтверждаем, что он подписан. Это просто лучшая практика с пользовательским опытом. А затем, с другой стороны, убедитесь, что функция отказа от подписки на самом деле довольно удобна для людей, и это довольно простой и приятный опыт, учитывая все обстоятельства. Итак, да, мы прошли и провели еще несколько пользовательских тестов и еще несколько исследований для этого. И мы действительно хотели убедиться, как я уже сказал, что сообщение было понятным и действенным.

Итак, вот еще раз, просто бок о бок до и после тестирования. Здесь не так много сумасшедших различий. В первую очередь, мы слышали от пользователей, что они хотели знать, в чем заключались конкретные ошибки, и им нужна была дополнительная информация, поэтому мы пытались им это дать. Мы попытались дать им коды ошибок и любую дополнительную информацию, которую мы могли, и просто немного прояснить это содержание. И после этого, честно говоря, это был просто вопрос работы над релизом. Так что, честно говоря, я просто хочу выделить некоторые из этих ключевых выводов, о которых я говорил, и эти ключевые моменты сотрудничества, которые у нас есть на протяжении всего этого проекта.

Прежде всего, для нас была очень важна триадная операционная модель. Опять же, это были дизайн и исследования, продукт и разработка — все они работали вместе как одна команда, чтобы запустить этот продукт. У нас часто были синхронизации и тач-базы по дизайну, исследованиям, инженерии. И мы задавали вопросы, сотрудничали.

Мы даже создали собственный канал в Slack. Я признаю, что не все могут или могут это сделать, но создание этих совместных отношений между дизайном и продуктом действительно важно. И они действительно являются ключевыми для обеспечения согласованности и ответственности на уровне предприятия или агентства при создании продуктов.

Еще одна вещь, о которой я упомяну, это тесное сотрудничество между дизайном и исследованиями. Я понимаю, что не все работают с дизайнером или исследователем, но вы все равно можете быть сторонником пользовательского опыта, если хотите. Существует множество UX-групп, которые предоставляют отличные ресурсы и лучшие практики, поэтому вы все равно можете быть сторонником юзабилити, даже если это не является вашей основной ролью или чем вы редко занимаетесь.

Еще одна вещь, о которой я упомяну, это партнерство с развитием. Я очень тесно сотрудничал со всеми командами разработчиков над этим проектом. Я часто приходил к ним, спрашивая, не сумасшедший ли я для создания дизайна или чего-то еще, и они всегда были так открыты для работы со мной и как бы давали всевозможные идеи, задавали вопросы.

Было здорово. У нас были действительно отличные отношения, основанные на сотрудничестве. Поэтому я скажу, что если вы работаете с дизайнером, не стесняйтесь замарать руки и сотрудничать с ним. Нам нравится работать с разработчиками, которые готовы сесть и понять проблемы, которые мы пытаемся решить, и вместе работать над достижением этой общей цели.

Другое дело, что я действительно участвовал во многих Agile-церемониях и каденциях, которые есть в этих командах. Так что возможность сидеть, уточнять отставание или планировать спринты и задавать вопросы, чтобы они задавали вопросы мне в контексте работы по разработке, была очень ценной. И последнее, но не менее важное: асинхронное сотрудничество. Это было действительно ключевым. Мы глобальная компания. У нас есть команды по всему миру, и мы все очень заняты.

Поэтому возможность создавать специальные каналы Slack для всех команд, чтобы все мы могли сотрудничать, была действительно ключевой. Мы с Кейт могли бы писать об исследованиях и дизайне. Мы могли получать обратную связь, задавать вопросы, не дожидаясь рассмотрения или встречи. И я думаю, я просто хочу подчеркнуть, что ситуация не обязательно должна быть идеальной — идеальной, извините меня, для того, чтобы мы могли сотрудничать. Вы можете сделать это асинхронно. Вам не нужно ждать встречи. Не все должно быть совершенно правильно, чтобы что-то было сделано. Так что это мое время. Большое спасибо всем вам. Брайан, я позволю тебе взять это и рассказать об обзоре нашей продукции.

БРАЙАН СМИТ: Большое спасибо, Камерон. Все в порядке. Как и было обещано, я собираюсь перейти к обзору продукта, а затем мы углубимся в технические детали, прежде чем мы закончим. Итак, мониторинг сайта и портал. Для тех, кто добавит надстройку, будет доступ к новой странице портала. Это называется «мониторинг сайта». И с этой страницы вы можете добавлять мониторы, приостанавливать и удалять. Кэмерон немного намекнул на это, но это страница, с которой вы это делаете.

Кроме того, на этой странице вы сможете просматривать простои, время безотказной работы, среднее время отклика для выбранного диапазона дат. Вы также сможете ссылаться на журналы ошибок для конкретных сайтов, когда мы обнаружим сбои, поэтому все это возможно на этой странице. Там также будут ссылки на страницу настроек предупреждений, на которую мы перейдем через секунду.

ХОРОШО. Итак, я хочу очень быстро перейти к видео, а затем мы вернемся к слайдам, но это будет настоящая демонстрация того, как эта страница выглядит на портале. Единственное, что нужно отметить, это было записано до некоторых из тех образов, которые вы видели у Кэмерона. Поэтому мы обновляем это. Не принимайте это за то, как это выглядит, но это хорошее приближение к тому, что вы увидите в портале.

Меню. Вы увидите ссылку для мониторинга сайта. Мы откроем эту страницу здесь, и вы увидите, что у меня есть список всех сред сайта, которые я отслеживаю. Я вижу эти времена отклика и список всех из них, которые в настоящее время отслеживаются. Я щелкнул ссылку статуса WP Engine вверху, и я попал на эту страницу статуса WP Engine. Кэмерон упоминал об этом и ранее, но это доступно там.

Когда я нажимаю кнопку «Добавить монитор», я могу легко сделать это одним щелчком мыши. Я бы сказал, что это огромная часть этого продукта и интеграции, просто та простота, с которой вы можете приостанавливать, удалять или инициализировать мониторы. Здесь я останавливаю монитор. Там вы увидите маленькую кнопку «Возобновить». Ага. Если я нажму «Возобновить», это остановит его.

И имейте в виду, что на самом деле пауза просто останавливает пинг-монитор от проверки связи с сайтом. Поэтому всякий раз, когда это приостановлено, он на самом деле не отправляет этот пинг. Здесь мы собираемся удалить монитор. Вы увидите экран подтверждения. Потому что, когда вы удаляете один из этих мониторов, он фактически удаляет всю связанную с ним историю отключений. Так что просто имейте это в виду.

И это страница в портале. Все в порядке. Сейчас я вернусь к слайдам и немного расскажу вам об оповещении по электронной почте, так что есть несколько разных шаблонов. Кэмерон упоминал об этом немного раньше, но здесь я остановлюсь немного глубже. Поэтому, как только вы выберете оповещение по электронной почте, вы получите шаблон электронной почты, который выглядит примерно так, показывая, что вы теперь подписаны на мониторинг оповещений для своих сайтов. Это даст вам ссылку на нашу статью Центра поддержки, которая даст вам больше информации о том, как работает этот продукт. А внизу есть ссылка на страницу мониторинга сайта, которую я вам только что показал.

ХОРОШО. Поэтому, когда мы обнаружим сбой на вашем сайте, вы получите электронное письмо, которое выглядит следующим образом. Там будет название сайта, когда мы обнаружили сбой. Он также покажет этот статус WP Engine. Теперь этот статус важен, потому что он покажет вам текущий статус платформы, хостинговой платформы. Так что, если это выглядит хорошо, но вы все еще получаете это электронное письмо, это указывает на то, что на самом деле существует проблема, связанная с конкретным сайтом.

Это не относится к инфраструктуре хостинга, но на самом деле что-то есть на вашем сайте или в вашем домене. И в содержании письма здесь будет показан тот код ответа, который мы видим. А затем внизу будет ссылка на эту страницу мониторинга сайта. Существует также ссылка на журналы доступа, потому что это будет вашим следующим лучшим шагом, чтобы попытаться диагностировать, что происходит и почему вы видите это электронное письмо о сбое.

Все в порядке. И затем, когда это разрешится, вы увидите еще одно электронное письмо, которое показывает, что ваш сайт находится в резервной копии. Отключение больше не происходит. Мы больше не обнаруживаем его. Это также скажет вам, какой сайт находится в резервной копии. Он расскажет вам, как долго этот сайт не работал, и, опять же, ссылки внизу. Те же ссылки внизу.

Итак, я упомянул, что это страница, на которую вы можете попасть со страницы мониторинга сайта и с портала. Здесь вы фактически настраиваете свои настройки предупреждений. Отсюда вы можете включить или отключить каналы оповещения. Вы можете ввести контакты электронной почты. Контакты электронной почты поступают из списка пользователей вашего портала, так что вы увидите это внизу слева. Это просто флажок.

У нас уже есть имя и адрес электронной почты. Вам не нужно вводить это. Опять же, это извлекается из ваших контактов на портале. Но упомяните здесь, что это будет страница, на которой вы можете включить интеграцию со Slack. У нас пока этого нет, но это есть в нашей дорожной карте. Это то, над чем мы как раз собираемся начать работу. Так что в настоящее время только оповещения по электронной почте, но Slack находится на дорожной карте.

Все в порядке. Я упомянул, что мы будем вдаваться в некоторые технические детали, чтобы дать вам представление о том, как все это работает за кулисами. Так что все это возможно с помощью того, что мы называем нашим «Агентом мониторинга сайта», и это промежуточный уровень между нашим пользовательским порталом и тем, что пользователь там делает, и нашим партнером New Relic, чьи API-интерфейсы мониторинга и оповещения мы используем. Таким образом, Site Monitoring Agent по существу централизует ресурсы New Relic.

Это слой, который создает, обновляет и удаляет мониторы, а также предупреждения. И это также место, где мы можем просто согласовать и отловить любые ошибки, убедиться, что ничего не удалено случайно. Итак, это промежуточный слой, так что давайте немного углубимся в некоторые вещи, которые происходят в пользовательском потоке. Итак, давайте пройдемся по типичному пользовательскому потоку. Таким образом, пользователь зарегистрируется. Что происходит, так это проверка прав доступа к порталу, чтобы узнать, есть ли у них доступ к мониторингу сайта.

И в случае, если они это сделают, он проверяет службу прав WP Engine, чтобы получить это ОК. После прохождения этой проверки пользователь может создать монитор на той странице Site Monitoring, которую я показывал вам ранее на портале. Поэтому они вручную подготавливают этот монитор, нажимая кнопку «Добавить монитор». И за кулисами он отправляет запрос в API New Relic Synthetics для фактической подготовки этого монитора.

Теперь, когда вы также находитесь на этой странице портала, вы можете просматривать данные. Вы можете просматривать исторические данные. Из того, что мы видели при проверке связи с настроенным вами сайтом, вы также можете увидеть среднее время ответа, ссылку на журналы доступа. Итак, здесь клиент может просмотреть эти данные на этой странице. Что происходит за кулисами, так это то, что мы на самом деле сталкиваемся с другим API New Relic. Это их NerdGraph API. Таким образом, агент мониторинга сайта отправляет запрос на получение этих данных и их отображение. И все это происходит, опять же, через API NerdGraph через New Relic.

Пара других вариантов использования, которые могут быть распространены, — это сценарий «Редактировать монитор». Таким образом, это может быть приостановка существующего монитора, и в этом случае агент отправит запрос на исправление в New Relic Synthetics API. Вы также можете отключить монитор. Это будет удаление монитора с той страницы портала, которую я показывал вам ранее. Это отправляет запрос на удаление в этот синтетический API. Клиент также может изменить конфигурацию. Возможно, вы хотите изменить URL-адрес домена, на который мы отправляем проверку связи.

В этом случае агент отправляет запрос на исправление для обновления этого монитора. Кроме того, пользователь может отменить сайт, на котором есть мониторинг сайта. И в этом случае мы бы просто автоматически отправили запрос на удаление в этот Synthetics API, чтобы деинициализировать этот монитор. Или в случае, если клиент может отменить всю учетную запись, в которой есть несколько разных мониторов сайта, запрос на деинициализацию всех этих мониторов отправляется автоматически при обнаружении этого. Таким образом, все эти вещи важны для пользовательского потока, и агент Site Monitoring Agent делает это возможным.

Все в порядке. Итак, я упоминал об этом ранее, но, поскольку мы смотрим вперед, мы, безусловно, планируем интегрировать Slack в качестве дополнительного канала оповещения. Мы также изучаем SMS, так что следите за обновлениями в будущем. Это наш V1. Мы в восторге от этого и очень рады, что можем запустить его здесь, в DE{CODE}. Но это действительно V1. У нас так много планов в запасе. Это лишь некоторые из них. Но также следите за обновлениями, чтобы узнать о дополнительных параметрах конфигурации с мониторингом, о других улучшениях пользовательского портала, и мы продолжим следить за итеративным процессом исследований и проектирования, который привел нас к этому моменту.

На этом спасибо другим ведущим, Кейт и Кэмерон. И спасибо всем за то, что присоединились к нам сегодня. Хорошего дня, и идите проверить мониторинг сайта Спасибо всем.