DE{CODE}: Monitoring witryny: skrzyżowanie produktów, projektowania i badań UX

Czy nie nienawidzisz tego, gdy dowiadujesz się, że Twoja witryna lub witryna Twojego klienta nie działa… od Twojego klienta? Nigdy więcej nie daj się oślepić! Dołącz do starszego menedżera produktu WP Engine, Bryana Smitha, asystenta badacza UX Kate Meyer i starszego projektanta produktu Kamerona Fehrmanna, gdy omawiają rozwiązanie do monitorowania witryny WP Engine, dzięki czemu ten problem jest reliktem przeszłości. Podczas tej sesji szczegółowo przyjrzysz się, jak działa monitorowanie witryny i jak połączenie projektowania UX, badań i rozwoju UX połączyło się, aby zapewnić dopasowanie produktu do rynku.

Slajdy sesji

Transkrypcja pełnego tekstu

BRYAN SMITH : Witam wszystkich. Nazywam się Bryan Smith. Jestem menedżerem produktu tutaj w WP Engine. Dziękujemy bardzo za dołączenie do nas dzisiaj. Jesteśmy tutaj, aby porozmawiać z Tobą o monitorowaniu witryny, skrzyżowaniu produktu, projektowaniu UX i badaniach. Dziś dołączają do mnie Kate Meyer, jedna z naszych badaczek UX, oraz Kameron Fehrmann, jeden z naszych projektantów produktów. Na następnym slajdzie opowiem o tym, czym jest monitorowanie witryny. Więc właśnie wydaliśmy ten nowy produkt. Nazywa się to „monitorowaniem witryny”. Jest dostępny jako dodatek dla klientów WP Engine. Dzięki niemu będziesz mógł monitorować dowolne środowiska witryny, które są powiązane z Twoim kontem. Poinformujemy Cię, jeśli w witrynie lub na naszej platformie wystąpią jakiekolwiek przerwy w działaniu.

A potem przejdę przez nasz plan bardzo szybko. Omówię więc produkt i przedstawię przegląd, a także techniczne głębokie nurkowanie. Ale zanim to zrobimy, przekażę to Kate Meyer, aby opowiedziała nam trochę o tym, jak doszliśmy do tego produktu. Omówi kilka stosowanych przez nas technik badania użytkowników. Następnie przekaże to Kameronowi, który przejdzie przez nasz projekt i iteracje produktu. A potem zakończę to przeglądem produktów i głębokim nurkowaniem technicznym. Do ciebie, Kate.

KATE MEYER : W porządku. Dzięki, Bryan, jestem Kate. Jestem badaczem UX tutaj w WP Engine, obecnie skupiam się na ulepszaniu naszej oferty tworzenia witryn. Więc Bryan pokazał nam ten wspaniały nowy produkt, który mamy teraz. Ale jak się tu znaleźliśmy? Chcę wrócić do początku naszej osi czasu i zademonstrować, w jaki sposób wykorzystujemy myślenie projektowe, aby przejść od znajomości podstawowych informacji o naszych użytkownikach do wydania produktu w ciągu zaledwie kilku miesięcy. Skoncentruję się na aspekcie badawczym naszego procesu i podzielę się z Tobą tym, jak możesz wdrożyć te praktyki bez względu na to, jaka jest Twoja rola, nawet jeśli nie masz badacza UX w swoim zespole.

Jak wspomniałem, w tym projekcie wykorzystaliśmy te trzy fazy myślenia projektowego. Myślenie projektowe to standard branżowy. Zasadniczo jest to zorientowane na użytkownika podejście do rozwiązania problemu. Podzielę tutaj naszą pracę na te trzy fazy. Zeszłego lata chcieliśmy dowiedzieć się, jak nie tylko naprawić to, co było nie tak z portalem użytkownika WP Engine, ale dowiedzieć się, jak możemy przenieść go na wyższy poziom.

Aby rozwiązać ten problem, wykorzystaliśmy badania generatywne. Było to w formie wywiadów z różnymi naszymi użytkownikami. Zadaliśmy im wszystkim zestaw wstępnie napisanych pytań, takich samych pytań dla wszystkich użytkowników, aby uzyskać zrozumienie takich rzeczy, jak ich praca, cele, wyzwania itp. Jeśli proces rozmowy kwalifikacyjnej wydaje Ci się przytłaczający, możesz również skorzystać z narzędzia ankiety w tym samym celu. Właściwie wykorzystaliśmy SurveyMonkey wraz z wywiadami jako kolejny sposób na uzyskanie opinii.

Podczas tej fazy badań uznaliśmy za naprawdę interesujące, że pomimo różnic w rolach użytkowników, w rzeczywistości mieli oni wiele wspólnych celów i problemów. I to jest naprawdę świetny wzór do zobaczenia. Naprawdę chcemy zobaczyć te podobieństwa wśród różnych typów użytkowników, ponieważ pomaga nam to określić zakres naszej pracy. Podczas przeprowadzania tych wywiadów i ankiet zaczęliśmy zauważać pewne wspólne tematy w kontekście hostingu stron internetowych.

Dwa z celów, o których ciągle słyszeliśmy, to chęć posiadania tylko jednego narzędzia do monitorowania i utrzymywania witryn internetowych oraz wykrywania problemów, zanim klienci i odwiedzający witrynę zauważą, że coś jest nie tak. Jednak powszechny problem polegał na tym, że nasz portal użytkowników obecnie nie umożliwia użytkownikom osiągnięcia tych celów. I rzeczywiście, ten właściciel agencji podsumował to całkiem dobrze, mówiąc: „Jeśli mogę rozwiązać problem, zanim klient go zobaczy, to fantastycznie. Nie chcę odbierać tych telefonów od klientów w stylu: „Och, hej, zgadnij co? Weszłam na swoją stronę internetową. Nie ma go tam. Co dzisiaj robisz?'"

Kiedy widzisz, że te wspólne motywy pojawiają się raz po raz, gdy słyszysz od użytkowników, wiesz, że nadszedł czas, aby wymyślić. Wiedzieliśmy, że musimy ulepszyć portal użytkownika, aby pomóc użytkownikom aktywnie dbać o swoje witryny. Wiedzieliśmy również, że nasz zespół inżynierów może wykorzystać technologię partnerów, aby rozwiązać jeden z problemów użytkowników, a mianowicie monitorowanie czasu pracy.

Więc w tym momencie byłoby nam naprawdę łatwo po prostu zanurkować i natychmiast zacząć coś budować. Ale jeśli chcesz zbudować właściwą rzecz za pierwszym razem, ważne jest, aby nadal otrzymywać opinie i uwagi użytkowników podczas tej fazy. Na tym etapie bardzo ważne jest również zaangażowanie całego zespołu.

Chcesz mieć świetne pomysły, ale musisz też upewnić się, że są one wykonalne i nadal odpowiadają potrzebom użytkowników. Dlatego na tym etapie nasz projektant współpracował z zespołem inżynierów, aby wymyślić pomysł i zapewnić jego wykonalność w monitorowaniu terenu. Następnie wraz z kierownikiem produktu i projektantem planuję testy koncepcyjne, abyśmy mogli przedstawić nasz pomysł użytkownikom.

Testowanie koncepcji to rodzaj badań, które pomagają dowiedzieć się, czy pomysł odpowiada oczekiwaniom i potrzebom użytkowników. Pokazujemy im więc nasz pomysł i zadajemy pytania na jego temat. W tym konkretnym przypadku użyliśmy makiet średniego wypełnienia LE, jak widać po lewej stronie, które projektant stworzył z pomocą zespołu inżynierów. Ale wspaniałą rzeczą w tego typu badaniach jest to, że możesz pokazać coś tak prostego, jak po prostu ołówek na papierze. Nie musi nawet dobrze wyglądać.

Ta technika jest naprawdę świetna, ponieważ pozwala użytkownikom skupić się na pomysłach zamiast na wizualnej prezentacji. I ponownie, na tym etapie naprawdę chcemy się dowiedzieć, czy Twój pomysł zmierza we właściwym kierunku. Kolejnym aspektem jest to, że nie musisz pokazywać tego dziesiątkom czy setkom ludzi. Do tego typu badań możesz wykorzystać nawet pięciu uczestników, ponieważ do tego momentu powinieneś zacząć dostrzegać pewne wspólne motywy w ich reakcjach na Twój pomysł.

Dlatego podczas testów koncepcyjnych dowiedzieliśmy się, że oczekiwania naszych użytkowników pokrywają się z naszymi planami dotyczącymi tego produktu. Dzięki temu jesteśmy w dobrej pozycji do rozpoczęcia budowy. Nadal jednak chcieliśmy zebrać opinie, więc zdecydowaliśmy się na zamkniętą wersję beta. Wyglądało to tak, jakby niektórzy użytkownicy wyrazili zgodę, dodali tę funkcję do swojego konta, a następnie poprosili ich o opinie podczas całego procesu korzystania z nowej funkcji. Tak więc posiadanie tej małej grupy użytkowników z dostępem do produktu to naprawdę świetny sposób na przetestowanie jego użyteczności, wyeliminowanie błędów i po prostu zrozumienie, w jaki sposób możesz lepiej spełnić ich oczekiwania, zanim produkt zostanie udostępniony wszystkim użytkowników.

Więc Kameron będzie kontynuował historię stąd. Ale zanim zostawimy za sobą część badawczą, chcę podsumować to, co mam nadzieję wyniesiesz z mojej historii. Ponownie, ta struktura może pomóc Ci przejść od zrozumienia potrzeb użytkowników do zbudowania nowego produktu. Każdy członek Twojego zespołu może uczyć się od użytkowników różnymi metodami i na wszystkich etapach projektu. Utrzymując użytkowników w centrum procesu tworzenia, zapewnisz, że Twój produkt będzie dla nich jak najłatwiejszy i zapewnisz sobie przewagę nad konkurencją. Dziękuję. Kameron.

KAMERON FEHRMANN : Wielkie dzięki, Kate. Cześć wszystkim. Jestem Kameron. Jestem starszym projektantem produktu w WP Engine. Pracuję również z narzędziami do tworzenia i naszymi produktami e-commerce i nie mogę się doczekać, aby porozmawiać z wami dzisiaj o monitorowaniu witryny. Więc tutaj jesteśmy w pewnym miejscu na naszej osi czasu. Przeszliśmy przez to, przeprowadziliśmy badania generatywne, przeprowadziliśmy kilka testów koncepcyjnych, a teraz udostępniliśmy wersję beta. Mamy ankietę, że w pewnym sensie słuchamy ludzi i to był właściwie punkt, w którym dołączyłem do projektu.

Szybko wciągnęłam się w poprzednie badania. Kate i Bryan byli w tym bardzo pomocni. Szczerze mówiąc, gdybyśmy nie ustalili już niektórych kadencji współpracy między projektowaniem a badaniami, produktem a inżynierią, sprawy nie potoczyłyby się tak gładko. Byli więc świetnymi partnerami w doprowadzeniu mnie do przyspieszenia w środku. Wiem, że niektórzy z Was pewnie rozumieją, jak to jest, pracując w agencji. Wiedzieliśmy, że ta podstawa była świetna dla naszej wersji beta, ale chcieliśmy zrobić z nią coś więcej.

Więc zrobiliśmy szybkie śledzenie po wydaniu wersji beta, aby jeszcze bardziej ulepszyć projekt. Przede wszystkim zaczęliśmy od naszego statusu WP Engine. Słyszeliśmy od użytkowników, że nie byli do końca pewni, czy awarie, których doświadczali, były wynikiem czegoś, co zrobili wewnętrznie, czy też był to problem z silnikiem WP, który, szczerze mówiąc, był poza ich kontrolą. Dodaliśmy więc ten status dla ludzi, aby mogli zobaczyć, hej, coś się dzieje z WP Engine. To my, nie ty i odwrotnie.

Dodaliśmy również funkcję Dodaj, Usuń lub Wstrzymaj do monitorowania. Zasadniczo był to sposób, w jaki ludzie mogli dodawać lub usuwać monitory, a następnie wstrzymywać monitorowanie w razie potrzeby, i był to po prostu sposób, aby ludzie mogli nieco bardziej dostosować swoje wrażenia. I wreszcie, jak widać tutaj, dość często ujawnialiśmy awarie. Chcieliśmy mieć pewność, że ludzie będą mogli wyraźnie zobaczyć, co dzieje się z ich witrynami i zdecydowanie komunikować się z nimi. I to też słyszeliśmy, że chcieli widzieć swoje awarie i jak najszybciej zająć się problemami.

A oto rodzaj przed i po, gdzie zaczęliśmy od wersji beta i gdzie skończyliśmy przed wydaniem. Jak widać, dość duże różnice. Szczególnie skupiliśmy się na kolumnach. Słyszeliśmy od ludzi, że nie do końca rozumieli, czym są kolumny, do czego służą lub co oznaczają jakiekolwiek elementy w nich zawarte.

Dlatego stan awarii był o wiele bardziej przejrzysty, jeśli chodzi o to, czy coś było w stanie awarii i co to oznaczało. A potem dodaliśmy także kilka bardziej przydatnych linków. Dodaliśmy w definicji tego, czym jest awaria, a następnie link do artykułu pomocy dotyczącego monitorowania witryny, aby ludzie mogli znaleźć więcej informacji, jeśli chcieli.

Inną rzeczą, którą zrobiliśmy, było ściślejsze powiązanie tego z naszym wewnętrznym systemem projektowania. Wspaniale było móc czerpać z pewnego rodzaju biblioteki komponentów dla siebie jako projektanta i jako programistów, dzięki czemu wszyscy mogliśmy przyspieszyć przepływ pracy. Jeśli nie masz jeszcze systemu projektowania, z którym pracujesz, bardzo go polecam. Po prostu znacznie ułatwiają przepływ pracy i sprawiają, że wszystko przebiega znacznie szybciej. Dzięki temu systemowi projektowania byliśmy w stanie dość szybko przejść od tego, co widzisz po lewej stronie, do prawej.

A oto jak wyglądał ten przepływ pracy, ta iteracja, gdy pracowaliśmy nad wersją beta. Więc zaczęliśmy. wypuściliśmy. Otrzymałem informacje zwrotne od naszych użytkowników w naszej ankiecie, a także od programistów pracujących nad produktem. Wprowadziłem kilka zmian projektowych. Porozmawiałbym z triadą. Moglibyśmy mieć jakieś opinie tylko wśród nas, a następnie przekazałbym je programistom. Może mają jakieś opinie. Moglibyśmy trochę omówić, a potem wypuścilibyśmy wersję beta i cykl zacząłby się od nowa.

Więc tylko po to, żeby się tutaj zameldować, przeszliśmy, wydaliśmy do wersji beta. Słuchaliśmy ludzi w naszej ankiecie beta. A teraz jesteśmy gotowi, aby rozpocząć alerty i zacząć korzystać z tego doświadczenia. Więc alerty, wiedzieliśmy, że ludzie chcą alertów, potrzebują alertów. To było coś, co usłyszeliśmy od użytkowników, było bardzo ważne i sprawiłoby, że monitorowanie byłoby dla nich jeszcze bardziej wartościowe.

Wiedzieliśmy również, że użytkownicy chcą być powiadamiani o problemie, zanim stanie się on problemem dla ich klientów, tak jak słyszeliście w naszym cytacie. Nie chcą otrzymać telefonu od klienta, że ​​wystąpił problem lub awaria w ich witrynie, a tak naprawdę sami o tym nie wiedzieli. To nie jest dobrze.

Inną rzeczą jest to, że faktycznie włączyliśmy do tej pracy dwa dodatkowe zespoły programistów, ponieważ chcieliśmy być w stanie dotrzymać harmonogramu wydania. Ten cykl, który w pewnym sensie widziałeś, stał się bardzo ważny, ponieważ było więcej drużyn. Więcej rąk sprawia, że ​​praca jest lżejsza, ale może też sprawić, że wszystko stanie się bardziej skomplikowane. Ale na szczęście byliśmy w stanie zająć się tym dla ich kadencji. Rzeczą, którą musieliśmy wymyślić za pomocą alertów, były kanały, których chcieliśmy użyć.

Od użytkowników usłyszeliśmy przede wszystkim, że e-mail jest ich preferowanym kanałem w stosunku do Slacka lub SMS-ów, więc zdecydowaliśmy się najpierw pozostać przy e-mailach. A potem musieliśmy przejść od tego momentu i przemyśleć wszystkie różne scenariusze e-maili. Chcieliśmy mieć pewność, że nasze wiadomości są bardzo jasne i wykonalne dla ludzi, aby byli w stanie zrozumieć i podjąć działania tak szybko, jak to możliwe, gdy otrzymają alert.

Inną rzeczą, o której musieliśmy pomyśleć, było to, że gdy ktoś zapisuje się na alert, chcemy mieć pewność, że potwierdzamy jego subskrypcję. Jest to po prostu najlepsza praktyka z doświadczeniem użytkownika. A potem na drugim końcu, upewniając się, że funkcja anulowania subskrypcji jest w rzeczywistości całkiem bezproblemowa dla ludzi i jest to całkiem łatwe i dobre doświadczenie, biorąc wszystko pod uwagę. Więc tak, przeszliśmy i przeprowadziliśmy więcej testów użytkowników i trochę więcej badań w tym zakresie. I naprawdę chcieliśmy się upewnić, jak powiedziałem, że wiadomość była zrozumiała i wykonalna.

Więc tutaj znowu, tylko obok siebie przed i po testach. Nie ma tu zbyt wielu szalonych różnic. Przede wszystkim słyszeliśmy od użytkowników, że chcą wiedzieć, jakie są konkretne błędy i chcą więcej informacji, więc to właśnie staraliśmy się im przekazać. Próbowaliśmy podać im kody błędów i wszelkie inne informacje, jakie mogliśmy, i po prostu trochę wyjaśnić tę treść. A potem, szczerze mówiąc, była to tylko kwestia pracy nad wydaniem. Szczerze mówiąc, chcę tylko podkreślić niektóre z tych kluczowych wniosków, o których mówiłem, oraz te kluczowe punkty współpracy, które mamy w całym tym projekcie.

Przede wszystkim bardzo ważny był dla nas model działania triady. Po raz kolejny był to projekt i badania, produkt i inżynieria wszelkiego rodzaju współpracujące ze sobą jako zespół, aby wprowadzić ten produkt na rynek. Często mieliśmy synchronizacje i kontakty dotykowe dotyczące projektowania, badań i inżynierii. I zadawalibyśmy pytania, współpracowali.

Założyliśmy nawet własny kanał Slack. Zdaję sobie sprawę, że nie każdy może lub jest w stanie to zrobić, ale tworzenie tych wspólnych relacji między projektem a produktem jest naprawdę ważne. Są one naprawdę kluczowe dla zapewnienia zgodności i odpowiedzialności na poziomie przedsiębiorstwa lub agencji podczas tworzenia produktów.

Inną rzeczą, o której wspomnę, jest tak bliskie partnerstwo między projektowaniem i badaniami. Zdaję sobie sprawę, że nie każdy współpracuje z projektantem lub badaczem, ale jeśli chcesz, nadal możesz być rzecznikiem doświadczeń użytkownika. Istnieje wiele grup UX, które zapewniają świetne zasoby i najlepsze praktyki, więc nadal możesz być orędownikiem użyteczności, nawet jeśli nie jest to twoja główna rola lub nie jest to coś, co często robisz.

Inną rzeczą, o której wspomnę, jest właściwie partnerstwo z rozwojem. Bardzo ściśle współpracowałem ze wszystkimi zespołami programistycznymi nad tym projektem. Często przychodziłem do nich, pytając, czy oszalałem na punkcie tworzenia projektu czy coś, a oni zawsze byli bardzo otwarci na współpracę ze mną i zapewniali różnego rodzaju spostrzeżenia, zadając pytania.

To było wspaniałe. Mieliśmy naprawdę świetny rodzaj współpracy. Powiem więc, że jeśli pracujesz z projektantem, nie wahaj się ubrudzić sobie rąk i współpracować z nim. Uwielbiamy pracować z programistami, którzy są gotowi usiąść i zrozumieć problemy, które próbujemy rozwiązać, i wspólnie pracować nad tym wspólnym celem.

Inna sprawa, że ​​faktycznie zaangażowałem się w wiele ceremonii Agile i kadencji, które mają te zespoły. Tak więc możliwość siedzenia, udoskonalania zaległości lub planowania sprintu i zadawania pytań, proszenia ich o zadawanie mi pytań w kontekście prac rozwojowych była bardzo cenna. I wreszcie, asynchroniczna współpraca. To było naprawdę kluczowe. Jesteśmy firmą globalną. Mamy zespoły na całym świecie i wszyscy jesteśmy bardzo zajęci.

Tak więc możliwość tworzenia specyficznych kanałów Slack w różnych zespołach, aby wszyscy mogli ze sobą współpracować, była naprawdę kluczowa. Kate i ja moglibyśmy pisać o badaniach i projektowaniu. Mogliśmy uzyskać informację zwrotną, zadawać pytania bez konieczności czekania na recenzję czy spotkanie. I myślę, że chcę to tylko zasygnalizować, że sytuacja nie musi być idealna – przepraszam, idealna, żebyśmy mogli współpracować. Możesz to zrobić asynchronicznie. Nie musisz czekać na spotkanie. Nie wszystko musi być dokładnie w porządku, aby wszystko było zrobione. Więc to jest mój czas. Bardzo dziękuje Wam wszystkim. Bryan, pozwolę ci to zabrać i porozmawiać o przeglądzie naszych produktów.

BRYAN SMITH: Wielkie dzięki, Kameron. W porządku. Zgodnie z obietnicą przejdę do omówienia produktu, a następnie dokonamy głębokiego przeglądu technicznego przed zamknięciem. Więc monitoring strony i portal. Osoby, które dodadzą dodatek, będą miały dostęp do nowej strony portalu. Nazywa się to „monitorowaniem witryny”. Na tej stronie możesz dodawać monitory, wstrzymywać i usuwać. Kameron nawiązywał do tego trochę, ale to jest strona, z której to robisz.

Ponadto na tej stronie można wyświetlić przerwy w działaniu, czas pracy i średni czas odpowiedzi dla wybranego zakresu dat. Będziesz także mógł połączyć się z dziennikami błędów specyficznymi dla witryny, gdy wykryjemy awarie, więc wszystko to jest możliwe z tej strony. Znajdą się tam również łącza do strony Preferencje alertów, do której przejdziemy tutaj za chwilę.

OK. Więc chcę szybko przejść do filmu, a potem wrócimy do slajdów, ale to będzie rzeczywisty przewodnik demonstracyjny tego, jak ta strona wygląda w portalu. Tylko jedna rzecz do przywołania, została nagrana przed niektórymi z tych obrazów, które widzieliście z Kameron. Więc aktualizujemy to. Nie traktuj tego dokładnie tak, jak to wygląda, ale jest to dobre przybliżenie tego, co zobaczysz w portalu.

Menu. Zobaczysz link do monitorowania witryny. Otworzymy tę stronę tutaj i zobaczysz, że mam listę wszystkich środowisk witryny, które monitoruję. Widzę te czasy odpowiedzi i listę wszystkich, które są aktualnie monitorowane. Kliknąłem ten link statusu WP Engine u góry i zabrał mnie do tej strony Stan silnika WP. Kameron wspomniał o tym wcześniej, ale to jest tam dostępne.

Kiedy klikam przycisk Dodaj monitor, mogę to łatwo zrobić jednym kliknięciem. Powiedziałbym, że to ogromny element tego produktu i integracji, to po prostu łatwość, z jaką można wstrzymywać, usuwać lub udostępniać monitory. Wstrzymuję monitor. Zobaczysz tam mały przycisk Wznów. Tak. Jeśli kliknę Wznów, to wznowi to.

I pamiętaj, że tak naprawdę pauza powstrzymuje monitor ping przed wysyłaniem polecenia ping do witryny. Więc ilekroć jest to wstrzymane, tak naprawdę nie wysyła tego pingu. Tutaj usuniemy monitor. Zobaczysz ekran potwierdzenia. Ponieważ usunięcie jednego z tych monitorów powoduje usunięcie całej powiązanej z nim historii przestojów. Więc po prostu miej to na uwadze.

A to strona w portalu. W porządku. Teraz przeskoczę z powrotem do slajdów i opowiem trochę o alercie e-mail, więc istnieje kilka różnych szablonów. Kameron nawiązywał do tego nieco wcześniej, ale tutaj zagłębię się nieco głębiej. Gdy więc zdecydujesz się na wysyłanie alertów e-mailem, otrzymasz szablon wiadomości e-mail, który wygląda mniej więcej tak, i pokazuje, że subskrybujesz alerty monitorowania dla swoich witryn. Otrzymasz link do artykułu w naszym Centrum pomocy, w którym znajdziesz więcej informacji na temat działania tego produktu. A na dole znajduje się link do strony monitorowania witryny, którą właśnie ci pokazałem.

OK. Kiedy więc wykryjemy awarię w Twojej witrynie, otrzymasz wiadomość e-mail wyglądającą tak. Będzie zawierać nazwę witryny, gdy wykryliśmy awarię. Pokaże również ten stan WP Engine. Teraz ten status jest ważny, ponieważ pokaże ci aktualny status platformy, platformy hostingowej. Więc jeśli to wygląda dobrze, ale nadal otrzymujesz ten e-mail, wskazuje to, że w rzeczywistości występuje problem specyficzny dla witryny.

Nie jest to specyficzne dla infrastruktury hostingowej, ale faktycznie coś jest w Twojej witrynie lub domenie. A w treści e-maila tutaj zobaczysz ten kod odpowiedzi, który widzimy. A potem na dole będzie link do tej strony monitorowania witryny. Jest tam również link do dzienników dostępu, ponieważ będzie to Twój kolejny najlepszy krok do zdiagnozowania, co się dzieje i dlaczego widzisz tę wiadomość e-mail o awarii.

W porządku. A kiedy to się rozwiąże, zobaczysz kolejną wiadomość e-mail z informacją, że Twoja witryna została utworzona. Awaria już nie występuje. Już go nie wykrywamy. Dzięki temu dowiesz się również, która witryna została utworzona. Powie ci, jak długo ta witryna była niedostępna, i znowu linki na dole. Te same linki na dole.

Wspomniałem więc, że jest to strona, do której można przejść ze strony i portalu monitorowania witryny. W tym miejscu faktycznie konfigurujesz preferencje alertów. Stąd możesz włączać lub wyłączać kanały alertów. Możesz wprowadzić kontakty e-mail. Kontakty e-mail pochodzą z listy użytkowników portalu, więc zobaczysz to na dole po lewej stronie. To tylko pole wyboru.

Mamy już nazwę i adres e-mail. Nie musisz tego wpisywać. Ponownie pobiera to z kontaktów w portalu. Ale wspomnij tutaj, że będzie to strona, z której możesz włączyć integrację Slack. Jeszcze tego nie mamy, ale jest to na naszej mapie drogowej. To coś, nad czym właśnie zaczynamy pracować. Tak więc obecnie tylko powiadomienia e-mail, ale Slack jest na mapie drogowej.

W porządku. Wspomniałem, że zajmiemy się tutaj niektórymi szczegółami technicznymi, aby dać wam wyobrażenie o tym, jak to wszystko działa za kulisami. Wszystko to jest więc możliwe dzięki temu, co nazywamy naszym „agentem monitorowania witryny”, i jest to warstwa pośrednia między naszym portalem użytkownika i tym, co użytkownik tam robi, a naszym partnerem New Relic, którego interfejsy API do monitorowania i ostrzegania wykorzystujemy. Tak więc Site Monitoring Agent zasadniczo centralizuje zasoby New Relic.

Jest to warstwa, która tworzy, aktualizuje i usuwa monitory oraz alerty. Jest to również miejsce, w którym możemy po prostu pogodzić się i wyłapać wszelkiego rodzaju błędy, upewnić się, że nic nie zostanie przypadkowo usunięte. To jest ta warstwa śródmiąższowa, więc przejdźmy trochę do niektórych rzeczy, które dzieją się w przepływie użytkowników. Przejdźmy więc przez typowy przepływ użytkowników. Więc użytkownik się zarejestruje. To, co się tam dzieje, polega na sprawdzeniu uprawnień do portalu, aby sprawdzić, czy mają dostęp do monitorowania witryny.

A jeśli to zrobią, sprawdza usługę uprawnień WP Engine, aby uzyskać OK. Po pomyślnym przejściu kontroli użytkownik może utworzyć monitor ze strony monitorowania witryny, którą pokazałem wcześniej w portalu. Dlatego ręcznie udostępniają ten monitor, klikając ten przycisk Dodaj monitor. A za kulisami wysyła żądanie do interfejsu API New Relic Synthetics w celu faktycznego udostępnienia tego monitora.

Teraz, gdy jesteś również na tej stronie w portalu, możesz przeglądać dane. Możesz przeglądać dane historyczne. Z tego, co widzieliśmy podczas pingowania witryny, którą skonfigurowałeś, możesz również zobaczyć średni czas odpowiedzi, połączyć się z dziennikami dostępu. Więc tutaj klient może przeglądać te dane na tej stronie. To, co dzieje się za kulisami, polega na tym, że w rzeczywistości uderzamy w inny interfejs API New Relic. To ich API NerdGraph. Dlatego Site Monitoring Agent wysyła żądanie pobrania tych danych i wyświetlenia ich. I wszystko to dzieje się ponownie za pośrednictwem interfejsu API NerdGraph za pośrednictwem New Relic.

Kilka innych przypadków użycia, które byłyby powszechne, to scenariusz edycji monitora. Może to oznaczać wstrzymanie istniejącego monitora, w którym to przypadku agent wyśle ​​żądanie poprawki do interfejsu API New Relic Synthetics. Możesz także anulować obsługę administracyjną monitora. Byłoby to usunięciem monitora z tej strony portalu, którą pokazywałem ci wcześniej. To wysyła żądanie usunięcia do tego API Syntetyki. Klient może również zmienić konfigurację. Może chcesz zmienić adres URL domeny, do której wysyłamy ten test ping.

W takim przypadku agent wysyła żądanie poprawki, aby zaktualizować ten monitor. Ponadto użytkownik może anulować witrynę, która ma monitorowanie witryn. W tym przypadku to, co byśmy zrobili, to po prostu automatyczne wysłanie żądania usunięcia do tego interfejsu API Synthetics w celu anulowania obsługi administracyjnej tego monitora. Lub w przypadku, gdy klient może anulować całe konto, na którym znajduje się kilka różnych monitorów witryn, żądanie anulowania obsługi administracyjnej wszystkich tych monitorów jest wysyłane automatycznie po wykryciu. Tak więc wszystkie te rzeczy są ważne dla przepływu użytkowników, a Site Monitoring Agent umożliwia to.

W porządku. Wspomniałem o tym wcześniej, ale patrząc w przyszłość, z pewnością planujemy integrację Slacka jako dodatkowego kanału alertów. Badamy również SMS-y, więc bądź na bieżąco z kolejnymi dodatkami w przyszłości. To jest nasz V1. Jesteśmy tym podekscytowani i bardzo się cieszymy, że możemy uruchomić go tutaj, w DE{CODE}. Ale to naprawdę jest V1. Mamy tyle planów w zanadrzu. To tylko kilka z nich. Ale bądź na bieżąco, aby uzyskać więcej opcji konfiguracji z monitorowaniem, więcej ulepszeń portalu użytkownika, a my będziemy nadal śledzić iteracyjny proces badań i projektowania, który doprowadził nas do tego punktu.

A więc dzięki pozostałym prezenterom, Kate i Kameronowi. I dziękuję wszystkim za dołączenie do nas dzisiaj. Miłego dnia i sprawdź monitorowanie witryny. Dziękujemy wszystkim.