Zbudować czy kupić: śledzenie błędów

Każdy zespół kiedyś dodał try/catch, który wysyła wiadomość do webhooka Slacka, i uznał śledzenie błędów za rozwiązane. Działa, zajęło dwadzieścia minut i w przypadku projektu pobocznego to rzeczywiście właściwa decyzja. Kłopoty zaczynają się mniej więcej sześć miesięcy później.

Czego nie uwzględniają te dwadzieścia minut

• Grupowanie, bo inaczej kanał staje się bezużyteczny przy pierwszym złym wdrożeniu.
• Ograniczenie częstotliwości, żeby jedna pętla nie wysłała dziesięciu tysięcy wiadomości.
• Retencja i przechowywanie, bo ktoś w końcu zapyta, co się stało w marcu.
• Dashboard, bo przewijanie kanału Slacka to nie triage.
• Reguły routingu, bo nie każdy błąd zasługuje na to samo miejsce docelowe.
• Ponowienia i eskalacja oraz proces dyżurów wokół nich.

Kiedy budowanie wciąż jest słuszne

Jeśli obsługa błędów jest Twoim produktem, zbuduj ją. Jeśli masz ograniczenie dotyczące rezydencji danych, którego żaden dostawca nie spełnia, zbuduj ją. W przeciwnym razie uczciwe porównanie nie brzmi „webhook kontra subskrypcja”, tylko trzeci rok utrzymywania listy powyżej kontra brak tej listy.

Zobacz, ile to kosztuje →