SLA na integrację - czego nie ma w umowie, a powinno

Dostępność to nie poprawność

Cała pułapka siedzi w tym jednym rozróżnieniu.

Sklep może być dostępny w 100% i jednocześnie kompletnie bezużyteczny. Strona się ładuje, katalog działa, klient składa zamówienie i dostaje potwierdzenie. Tylko że most do ERP-a stanął o 3 w nocy i od tej pory nic nie idzie dalej. Magazyn nic nie widzi, faktury nie powstają, a klient jest przekonany, że kupił.

Monitoring nie zapali się na czerwono, bo monitoruje HTTP 200. SLA jest dotrzymane. Straty są realne.

Dlatego SLA napisane wyłącznie o dostępności sklepu jest w projekcie z integracją SLA na niewłaściwą rzecz.

Pięć brakujących zapisów

1. Maksymalne opóźnienie synchronizacji. Nie „synchronizacja działa", tylko: zamówienie ma być w ERP w ciągu X minut od złożenia. To jest mierzalne i to jest to, co obchodzi biznes.

2. Maksymalny rozmiar kolejki. Kolejka rosnąca w nieskończoność wygląda jak działający system dokładnie do momentu, w którym przestaje. Alert ma być przy tysiącu oczekujących komunikatów, a nie przy pięćdziesięciu tysiącach.

3. Definicja „nieudane". Ile razy ponawiamy? Po ilu próbach uznajemy, że dokument nie powstanie i wołamy człowieka? Bez tego zapisu wiadomość krąży w kolejce tydzień, a wszyscy myślą, że „system się tym zajmuje".

4. Kto patrzy na dead letter queue. To jest miejsce, gdzie lądują komunikaty, których nie da się przetworzyć. W większości projektów odpowiedź na to pytanie brzmi „nikt" - i wychodzi to po pół roku, gdy ktoś tam zajrzy z ciekawości i znajdzie czterysta zamówień.

5. Czas reakcji na rozjazd danych. Cena w sklepie różni się od ceny w ERP. To nie jest awaria w rozumieniu SLA - nic nie leży. To jest coś gorszego: system działa i kłamie.

Punkty 2 i 4 zakładają, że w ogóle masz co obserwować. Jeśli nie masz, to jest osobny temat - opisany w tekście o observability.

Kto odpowiada, gdy ERP leży

To jest pytanie, które w umowach zwykle nie istnieje, a w rzeczywistości pada zawsze.

Dostawca sklepu mówi: sklep działa, nasza część jest OK. Dostawca ERP-a mówi: ERP działa, wasza część jest OK. Most stoi między nimi i nie ma właściciela, bo powstał „przy okazji wdrożenia".

W praktyce sprowadza się to do jednej rzeczy: czyj numer telefonu dzwoni o 17 w piątek. Jeśli w umowie tego nie ma, odpowiedź brzmi „prezesa".

Warto zapisać coś prostszego, niż wygląda: kto jest właścicielem warstwy pośredniej i kto ma obowiązek zdiagnozować, po której stronie jest problem - zanim rozpocznie się spór o to, kto go naprawia. To jeden z realnych argumentów za tym, żeby warstwa pośrednia w ogóle była wydzielona, o czym piszę w tekście o middleware.

Minimum, które warto wpisać

Nie potrzeba trzydziestostronicowego załącznika. Cztery zdania załatwiają 90% problemu:

• Zamówienie trafia do ERP w ciągu 15 minut od złożenia. Przekroczenie to incydent, nie ciekawostka.
• Kolejka powyżej 1000 komunikatów albo starsza niż 30 minut generuje alert do konkretnej osoby.
• Komunikat w dead letter queue jest przeglądany w każdy dzień roboczy przez wskazaną rolę.
• Rozjazd ceny sklep-ERP jest incydentem krytycznym, nie zgłoszeniem o niskim priorytecie.

Wpisanie tego kosztuje jedno spotkanie. Niewpisanie kosztuje pierwszą awarię plus tydzień ustalania, czyja to była wina.

Co dalej

• Bez tego nie masz czego obserwować: Observability - logi, metryki, tracing
• Dlaczego warstwa pośrednia potrzebuje właściciela: Middleware vs. bezpośrednio
• Pełny przegląd integracji: pillar /integracje