Komunikaty błędów w praktyce

Projektując system bardzo rzadko zwraca się uwagę na komunikaty błędów. Nasza aplikacja przecież będzie zawsze działać poprawnie, czyż nie? Niestety testy (a czasem dopiero uruchomienie produkcyjne) rewiduje to życzeniowe podejście i okazuje się, że…

  • komunikat nic nie mówi użytkownikowi, 
  • co gorzej – nie mówi też nic administratorowi czy programiście, 
  • logi nie zawierają szczegółów, które pozwoliłyby namierzyć przyczynę problemu, 

Podzielę się z Wami paroma pomysłami na lepsze komunikaty błędów w aplikacjach biznesowych.

Nie strasz

Skonstruuj komunikat tak, aby był zrozumiały dla użytkownika i aby nie miał on poczucia winy. Warto użyć kilku słów pocieszenia i wziąć winę na siebie. To my, projektanci i administratorzy aplikacji czy infrastruktury, doprowadziliśmy do sytuacji, kiedy coś poszło nie tak. Jeśli aplikacja pozwala wykonać powtarzalny zbiór czynności prowadzący do błędu to coś jest z nią nie tak. 

Informuj

Komunika “Internal server error 500” nikomu niewiele mówi. Dla najczęstszych przypadków (których wystąpienia nie da się wyeliminować) przygotuj komunikat opisujący dokładnie co się stało i co należy dalej zrobić oraz czy istnieje jakieś obejście problemu. Często pozwoli to zmniejszyć ilość zgłoszeń jakie trafiają do firmowego centrum wsparcia.

w jednym z systemów częstą sytuacją było klikanie w link do już obsłużonego zadania, które trafiło do grupy osób. Pierwsza osoba wykonywała zadanie a reszta grupy dostawała błąd i zgłaszała usterkę na helpdesk. Po zmianie suchego komunikatu na szczegółowe objaśnienie co użytkownik ma zrobić (sprawdzić na liście zadań, czy takowe na pewno tam figuruje) ilość zgłoszeń tej kategorii spadła o ponad 90%. 

Nie zdradzaj za wiele

Użytkownika nie interesuje stack trace z Twojej aplikacji. Osobę mającą złe intencje już tak. Nie dodawaj “dla własnej wygody” żadnych informacji jakie zwraca serwer, kod, aplikacja. Przekieruj to do logów aplikacji.

Jeśli jesteś paranoikiem dodaj losowe opóźnienie przed wyświetleniem komunikatu błędu. Utrudni to życie złoczyńcom generującym specjalnie różnego rodzaju błędy i mierzącym czas odpowiedzi aplikacji – czasem można w ten sposób wywnioskować conieco o architekturze rozwiązania lub o istnieniu bądź nie istnieniu jakiegoś wpisu w bazie danych.

Klasycznym przykładem jest próbkowanie formularza resetu hasła adresami email i badanie czy dla (nie)istniejących adresów aplikacja odpowiada wolniej bądź szybciej. 

ułatwiaj sobie (i innym) życie

Jeśli błędy w Twojej aplikacji często trafiają do późniejszej obsługi, np. w ramach firmowego helpdesku albo na twoją skrzynkę mailową, możesz zastosować sztuczkę, która zaoszczędzi Tobie przeszukiwania logów, do których trafiają szczegółowe dane o błędzie. 

Dodaj do strony z komunikatem błędu przycisk “Zgłoś błąd do administratora”. Pod przyciskiem zabuduj wysyłkę maila na zdefiniowany w konfiguracji aplikacji adres, zawierającą np.:

  • adres, na jakim wystąpił błąd
  • dokładną datę i godzinę, 
  • login zalogowanego użytkownika a także, jeśli masz takie dane (możesz zintegrować się z jakąś usługą katalogową) jego Imię, Nazwisko, mail i telefon, 
  • dokładną treść błędu,
  • cały ciąg wywołań, stack trace, teksty jakie trafiły do logów,

Scentralizuj i zabezpiecz dane o błędach

Oczywiście dane występujące w komunikatach błędów są po części wrażliwe a po części to cenna wiedza. Warto się zastanowić, czy chcesz je zawsze w całości wysyłać na zdefiniowany mail (np. firmowy servicedesk).

Jeśli chcesz mieć nad tym większą kontrolę możesz zbudować sobie prostą aplikację, która wystawi serwisy przyjmujące dane o błędach z Twoich systemów. Po wystąpieniu problemu – oprócz pokazania strony użytkownikowi – wszelkie szczegóły będą wysyłane do centralnej bazy danych.

Po kliknięciu przycisku “Zgłoś błąd do administratora” zostanie wysłany tylko link do podglądu zdarzenia. Link ten nie będzie zawierał żadnych danych wrażliwych a otworzyć go będzie mogła jedynie osoba mająca stosowne uprawnienia.

Aplikacja taka zapewnia

  • większą kontrolę nad dostępem do błędów z poszczególnych aplikacji – możesz zdefiniować grupy administratorów i zarządzać ich składem, 
  • możliwość wyszukiwania, raportowania i korelowania błędów z wielu aplikacji, np. pod kątem częstotliwości lub rodzajów problemów

Unikaj… jeśli się to opłaca

Rób tak aby nie było błędów – to oczywista rada. Idealny świat to systemy bezusterkowe, samonaprawialne. Życie pokazuje że nie zawsze mamy wpływ na wszystkie komponenty które są częścią rozwiązania oraz te, z którymi ono współpracuje. Czasem jest też tak, że błąd zdarza się raz na miesiąc czy raz na rok i zwyczajnie nie opłaca się ich naprawiać. Taniej jest po prostu obsłużyć błąd ręcznie. To żadna ujma na honorze a zwyczajna kalkulacja zysków i strat.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *