Stan systemu DI Cloud.

Ta strona pokazuje stan systemu DI Cloud w chwili jej otwarcia: każde wejście uruchamia zestaw kontroli od nowa, ponieważ widok powstaje po stronie serwera i nie jest zapisywany w pamięci podręcznej. Nie jest to archiwum incydentów ani deklaracja dostępności na przyszłość. Układ prowadzi od ogółu do szczegółu — najpierw wynik zbiorczy przy nagłówku, potem karty czterech usług produktowych: czatu AI, kreacji projektu, płatności i bazy danych, a na końcu lista pojedynczych kontroli, która obejmuje również warstwę aplikacji, czat, stan API, logowanie oraz wysyłkę maili. Ten sam wynik zbiorczy wraca niżej jako osobna karta, obok liczby kontroli zakończonych powodzeniem wobec ich łącznej liczby oraz godziny odczytu. Dostęp do tej strony nie wymaga zalogowania, więc pozostaje ona osiągalna także wtedy, gdy zalogowanie do obszaru roboczego jest niemożliwe.

Każda kontrola kończy się jednym z trzech wyników i według tej samej skali opisane są karty usług. „Działa” oznacza poprawną odpowiedź sprawdzanego elementu, „Uwaga” — odpowiedź niepełną albo konfigurację wymagającą wyjaśnienia, przy której korzystanie z produktu zwykle pozostaje możliwe, a „Problem” — kontrolę nieudaną. Wynik zbiorczy nie jest średnią pozostałych: spada do najniższej wartości wyłącznie wtedy, gdy zawiedzie kontrola oznaczona jako krytyczna, natomiast każde inne ostrzeżenie albo niepowodzenie obniża go o jeden stopień. Kontrole dzielą się na wewnętrzne, zewnętrzne i konfiguracyjne. Wewnętrzne potwierdzają wykonanie kodu po stronie serwera, zewnętrzne odpytują usługę spoza aplikacji i zwykle podają czas odpowiedzi w milisekundach, który dotyczy samego zapytania kontrolnego i nie opisuje szybkości pracy z produktem. Na stronie widoczne są nazwa, kategoria, czas odpowiedzi i wynik; komunikaty diagnostyczne poszczególnych kontroli trafiają wyłącznie do danych w formacie JSON, a ten sam zestaw kontroli zasila publiczny punkt końcowy, który przy nieudanej kontroli krytycznej odpowiada kodem 503.

Jeżeli któraś pozycja ma status inny niż „Działa”, pierwszym krokiem jest odświeżenie widoku: kontrole zewnętrzne mają krótki limit oczekiwania i pojedyncze jego przekroczenie bywa chwilowe, więc następny pomiar często wygląda już inaczej. Gdy wynik się utrzymuje, z listy daje się odczytać zasięg awarii, ponieważ każda pozycja dotyczy odrębnej usługi: ostrzeżenie przy płatnościach nie przerywa rozmowy w czacie, a niepowodzenie przy wysyłce maili oznacza zwykle opóźnione wiadomości, a nie utratę treści zapisanych w obszarze roboczym. Zgłoszenia przyjmuje adres kontaktowy podany w stopce. W wiadomości warto wskazać trzy rzeczy: której pozycji dotyczy zgłoszenie, jaki wynik był przy niej widoczny oraz godzinę odczytaną z pola „Wygenerowano”. Wcześniejsze pomiary nie są tutaj przechowywane, dlatego zrzut ekranu wykonany w chwili zaobserwowania awarii bywa jedynym śladem konkretnego odczytu.

Kontrole różnią się tym, co odpytują. Trzy pozycje wewnętrzne są zapisywane jako udane przy składaniu raportu i potwierdzają wykonanie kodu serwera; o stanie usług zewnętrznych nie mówią nic. Kontrola czatu AI odpytuje naraz czterech dostawców — trzech o listę modeli, jednego o stan konta i środki — i kończy się powodzeniem, gdy odpowie choć jeden. Kreacja projektu odczytuje listę modeli Google i sprawdza obecność modelu obrazów; jego brak daje status ostrzeżenia, a przy braku odpowiedzi Google odpytywani są dostawcy zapasowi. Płatności łączą zapytanie o konto Stripe z kontrolą identyfikatorów cen pięciu planów samoobsługowych; oba odczyty kont bywają użyte ponownie, gdy poprzedni ma mniej niż minutę. Baza danych to jedno zapytanie zliczające na jednej tabeli, bez pobierania treści; logowanie i maile to zapytania do punktu zdrowia oraz listy domen. Limit oczekiwania to dwie sekundy dla logowania i maili oraz od trzech i pół do pięciu sekund dla pozostałych usług systemu DI Cloud.

Pomyślny status kontroli znaczy mniej, niż sugeruje nazwa. Potwierdza odpowiedź odpytanej usługi na zapytanie kontrolne, a nie poprawność późniejszej pracy: odpowiedź dostawcy na pytanie o listę modeli nie przesądza o treści, jaką model zwróci w rozmowie, ani o tym, jak oceni ją weryfikacja twierdzeń w silniku DI Core — to osobny mechanizm produktu. Czas przy części pozycji dotyczy zapytania z serwera, który złożył raport, a nie z urządzenia czytającego stronę; pozycje wewnętrzne nie podają go wcale. Każda usługa jest odpytywana raz i zbiorczo, więc usterka widoczna tylko dla części użytkowników — jednego obszaru roboczego, jednego planu lub przeglądarki — nie pojawi się w tym zestawieniu. Kontrola bazy dotyka jednej tabeli i nie orzeka o pozostałych, kontrola maili kończy się na odpowiedzi usługi pocztowej, nie na doręczeniu, a kontrola płatności nie przesądza o powodzeniu transakcji. Poprawny stan wszystkich pozycji systemu DI Cloud jest warunkiem koniecznym pracy, nie jej gwarancją.

Jeżeli problem nie ma odzwierciedlenia w żadnej z kontroli, opis tego, co warto podać w zgłoszeniu, zebraliśmy na stronie wsparcia.