Czy to dziura w całym? Przekonajmy się.
Case study: Szereg zależności w systemie rezerwacyjnym.
W systemie rezerwacyjnym pojawił się problem. W niektóre dni część okienek czasowych była niedostępna do rezerwacji.
Zwykle są to całe dni, wyjęte z „życiorysu firmy”
Pierwszy trop: system umożliwia tworzenie spotkań dłuższych niż standardowy czas trwania spotkań, załóżmy 1h. Blokada godzinowa nie została ustawiona. Któryś z rekordów zajmuje więcej niż jeden slot.
Skutek: Można zarezerwować wizytę całodniową, mimo że usługa trwa tę jedną godzinę.
Rozwiązanie wstępne: Włączenie ograniczenia umówienia wizyty do jednej godziny (jednego okienka czasowego).
Drugi trop: Błąd systemu: Stare rezerwacje na więcej niż jedną godzinę (czasem kilkudniowe), pozostają w bazie danych, ale system nie wymusza ich edycji – zamiast tego: system pokazuje je na sztywno jako jednogodzinne. Na pierwszy rzut oka nie widać błędu.
Jak wykryć problem? Wszystko zostaje w bazie danych, ale nie wszystko widać na pierwszy rzut oka – choć w widoku harmonogramu widać spotkania zajmujące więcej niż jeden slot czasowy. To jeszcze nie rozwiązanie, ale poszlaka, wskazówka, że w harmonogramie i w bazie istnieją rekordy które nie spełniają kryteriów domyślnych.
Rozwiązanie: Usunąć błędne rekordy, ale nie z bazy, lecz ręcznie przez aplikację. Wtedy pozostaje ślad po nich, ale nie blokują już realnie wolnych slotów czasowych w widoku klienta.
Luka w systemie dopuściła błąd konfiguracji, który dopuścił do błędu użytkownika.
Konkluzja: Nie wszystko jest wynikiem intencji użytkownika.
Czasem konfiguracja systemu, czyli zaistniałe warunki pozwalają pewnym błędom zaistnieć.
Czasem system nie weryfikuje zaistnienia konfliktu – zarówno ustawień (warunków), jak i działań które powstały w złych warunkach.
Nauka: Najciekawsze błędy rzadko wynikają z jednego miejsca. Zwykle są efektem kilku pozornie poprawnych decyzji, które dopiero razem tworzą problem.
Czas trwania diagnozy i naprawy: 45 minut.
