System handlowy Solana może mieć dokładne dane rynkowe, sensowną strategię i niezawodny komponent podpisujący, a nadal gubić własne zamiary. Niepowodzenie często występuje między komponentami: jeden proces roboczy zakłada, że działania nie przesłano, inny zakłada, że budżet zwolniono, a pulpit pokazuje uproszczony stan, którego nie uzasadnia żadne z tych założeń.
Trwałe zapisy i jasna odpowiedzialność pozwalają sprawdzać te granice. System musi wiedzieć, który komponent może zmienić każdy stan, jakie dowody dopuszczają zmianę i jak zapis przetrwa awarię lub opóźnioną odpowiedź. Potrzebuje też historii incydentu zachowującej ówczesne przekonania zamiast zastępowania ich końcowym poprawionym widokiem.
Poradnik śledzi fikcyjny incydent jednego zamiaru zakupu i niepewnego przesłania. Przykład dotyczy projektu systemu i przeglądu. Nie opisuje działającej usługi ani nie sugeruje, że trwałe zapisy usuwają ryzyko rynkowe lub gwarantują udane wykonanie.
Odpowiedzialność za stan systemu Solana zaczyna się od znaczenia
Stan jest twierdzeniem o procesie: propozycja oczekuje na przegląd, zamiar ma rezerwację budżetu, próba pozostaje nierozstrzygnięta lub pozycję uzgodniono. Każde twierdzenie powinno mieć definicję i podmiot odpowiedzialny za zmianę. Etykieta bez zdefiniowanego przejścia może znaczyć coś innego dla różnych komponentów.
Oddziel fakty rynkowe, fakty konta i decyzje reguł. Obserwacja kwotowania jest dowodem rynkowym. Saldo tokena jest dowodem konta w określonym kontekście obserwacji. Zgoda jest decyzją według reguł. Jeden typ zapisu nie powinien po cichu zastępować drugiego tylko dlatego, że interfejs potrzebuje jednego statusu.
Wcześniejszy poradnik trwałej automatyzacji Solana wyjaśnia zamiary, rezerwacje, ponowienia i uzgadnianie. Odpowiedzialność za stan systemu Solana dodaje do każdego pojęcia pytanie: który komponent może stwierdzić ten stan i jakie dowody musi przy tym zachować?
Nadaj każdemu zamiarowi trwałą tożsamość
Zamiar reprezentuje jedno proponowane działanie ekonomiczne w określonym zakresie. Jego tożsamość powinna przetrwać ponowienia procesów roboczych, restarty procesów i powtórne wiadomości. Nowe żądanie sieciowe nie musi tworzyć nowego zamiaru, a istotnie zmieniona kwota lub zakres uprawnień mogą wymagać nowego przeglądu.
Zapis zamiaru powinien odsyłać do aktywa, konta, kierunku, proponowanej kwoty, wersji reguły, dowodów i statusu autoryzacji. Może ewoluować przez udokumentowane przejścia, zachowując historię dojścia do obecnego stanu. Oceniający powinien móc śledzić historię bez polegania na procesie roboczym, który obecnie obsługuje zadanie.
Poradnik bota kryptowalutowego Solana przydziela obowiązki pierwszego uruchomienia. Trwała tożsamość zamiaru łączy te role. Pozwala komponentom obserwacji, strategii, autoryzacji i wykonania odnosić się do tego samego działania bez wymyślania osobnych niepowiązanych pojęć transakcji.
Przechowuj próby pod zamiarem
Próba jest konkretnym wysiłkiem przesłania lub zakończenia autoryzowanego działania. Ma własną tożsamość, czas, kontekst transakcji i dowody wyniku. Kilka prób operacyjnych może dotyczyć jednego zamiaru według określonej reguły odzyskiwania, lecz nie powinno reprezentować niepowiązanych decyzji ekonomicznych.
Rozróżnienie ma znaczenie w niepewności. Po utracie pierwszej odpowiedzi przesłania proces roboczy powinien najpierw sprawdzić istniejący zamiar i zapis próby. Nie powinien uznawać, że należy wykonać nowy zakup tylko dlatego, że sygnał strategii nadal jest obecny.
Zapisuj historię prób trwale przed uznaniem działania za bezpiecznie przekazane dalej. Technika przechowywania może być różna, ale odzyskiwanie musi ustalić możliwość wcześniejszego przesłania. Zapis istniejący tylko w pamięci nie wspiera takiego wniosku po awarii.
Wybierz jednego odpowiedzialnego za rezerwacje budżetu
Księga budżetu powinna mieć jedną miarodajną ścieżkę zmian rezerwujących, zużywających i zwalniających zasoby. Wiele komponentów może żądać zmian, ale nie powinny niezależnie nadpisywać dostępnej kwoty ze swoich widoków podręcznych. Tworzy to wyścig przekonań o koncie.
W fikcyjnym incydencie zamiar I7 rezerwuje osiemdziesiąt jednostek budżetu. Proces wykonawczy odwołuje się do tej rezerwacji, natomiast komponent odpowiedzialny za uzgadnianie ustala jej ostateczne rozliczenie na podstawie dowodów potwierdzających wynik. Limit czasu harmonogramu nie powinien niezależnie zwalniać rezerwacji przez zbyt długie trwanie zadania.
Zapis powinien też wyjaśniać częściowe zwolnienia i korekty. Gdy koszt końcowy różni się od rezerwowanego szacunku, uzgadnianie może zaktualizować księgę z powodem. Zachowanie pierwotnej rezerwacji i korekty odróżnia oczekiwane różnice szacunków od niewyjaśnionych zmian budżetu.
Traktuj obserwacje konta jako datowane dowody
Migawka konta ma źródło, kontekst obserwacji i czas. Nie jest wieczną prawdą tylko dlatego, że kiedyś udało się ją odczytać. System powinien zachować migawkę autoryzacji i późniejszą migawkę uzgodnienia wraz z lukami lub niespójnościami.
Nowa migawka może nie zgadzać się z księgą przez przelewy zewnętrzne, działania ręczne, opóźnioną interpretację lub nierozstrzygniętą próbę. Odpowiedzialny za uzgadnianie powinien badać relację, zamiast bez wyjaśnienia dopasowywać jeden zapis do drugiego.
System musi też odróżniać obecne aktywa od pozycji strategii. Import konta nie ustala pełnej historii nabycia. Trwała księga może oznaczać aktywa zewnętrzne lub nieznane, aby strategia nie zakładała przynależności każdego obserwowanego tokena do utworzonego przez siebie zamiaru.
Oddziel zapis zdarzeń od obecnego widoku
Widok bieżącego stanu jest użyteczny operacyjnie: co jest teraz otwarte, oczekujące, dostępne lub wstrzymane? Historia zdarzeń wyjaśnia zmiany stanów. Zachowaj oba. Odbudowa obecnego widoku nie powinna wymagać usuwania historii wyjaśniającej wcześniejsze decyzje.
Korekta może zmieniać obecną interpretację przy zachowaniu pierwotnej obserwacji i decyzji. Na przykład transakcja początkowo nierozstrzygnięta może później zostać potwierdzona i uzgodniona. Obecny widok powinien pokazywać rozstrzygnięcie, a historia zachować okres niepewności i wstrzymane wtedy działania.
Rozróżnienie chroni też analizę incydentów. Nadpisanie każdego pośredniego stanu końcową odpowiedzią uniemożliwia wyjaśnienie tego, dlaczego operator widział ostrzeżenie lub dlaczego proces roboczy podjął próbę przywrócenia działania. Czysty końcowy ekran nie zastępuje wiernego zapisu ścieżki.
Wymagaj konkretnych dowodów dla przejść
Każda zmiana stanu powinna nazywać warunek wstępny. Propozycja uzyskuje autoryzację po bieżących kontrolach reguł. Zamiar staje się przesłany, gdy zapis próby ustala odpowiednie przekazanie. Pozycja jest uzgodniona po ustaleniu skutku na koncie według reguły dowodowej procesu.
Unikaj przejść opartych wyłącznie na upływie czasu tam, gdzie czas nie dowodzi wyniku. Przekroczenie czasu przesłania może uzasadniać badanie lub obsługę wygaśnięcia, ale nie dowodzi braku transakcji. Rezerwacja nie powinna znikać tylko przez upływ ogólnego terminu zadania.
Wcześniejszy poradnik odzyskiwania API Solana wyjaśnia różne traktowanie błędów chwilowych, ponowień i nieznanych wyników. Przejścia stanów powinny zachowywać różnice, aby system odzyskiwał świadomie, zamiast zamieniać każdy błąd w ten sam status niepowodzenia.
Nie pozwalaj brakowi statusu dowodzić nieistnienia
Zapytanie o status ma udokumentowany zakres i może zwracać niepełne dowody dla danego pytania. Metoda statusu podpisu Solana odróżnia pamięć podręczną niedawnych statusów od opcjonalnego wyszukiwania historii transakcji. Braku wyniku w pamięci podręcznej niedawnych statusów nie należy uznawać za uniwersalny dowód nieistnienia transakcji. Dokumentacja statusów podpisów Solana.
System powinien zapisywać kontekst zapytania i wnioski wspierane przez odpowiedź. Jeśli potrzeba dodatkowych dowodów, próba pozostaje nierozstrzygnięta podczas ograniczonej procedury odzyskiwania. Zapis powinien podawać niewystarczalność obecnych dowodów, zamiast pozwalać pustemu polu stać się definitywnym niepowodzeniem.
To ogólna zasada analizy incydentów: brak wyniku i dowód braku to różne rzeczy. System zachowujący to rozróżnienie może wyjaśnić, dlaczego czekał lub eskalował problem. System scalający je może tworzyć podwójne działanie w przekonaniu, że tylko odzyskał nieudane żądanie.
Analiza incydentu systemu Solana wymaga osi czasu
Oś incydentu powinna obejmować zdarzenia źródłowe, obserwacje systemu, decyzje, próby, działania operatora i korekty. Zachowaj odpowiednie zegary, zamiast wymuszać jedną kolejność przybycia. Sekwencja powinna pokazywać wiedzę systemu przy każdej decyzji.
Dla fikcyjnego incydentu I7 zapisz otwarcie propozycji, rezerwację osiemdziesięciu jednostek, możliwe przesłanie próby, przekroczenie czasu odpowiedzi i wznowienie zadania przez drugi proces roboczy. Fakty ustalają granicę możliwego podwójnego działania.
Analiza incydentów systemu handlowego Solana powinna też obejmować decyzje, które nie nastąpiły. Odrzucona druga propozycja lub świadoma pauza mogą pokazać działanie kontroli. Zapis skupiony tylko na błędach może pominąć mechanizmy ograniczające skutek, które należy zachować.
Polecaj i zarabiaj USDC
Polecaj i zarabiaj USDCNasz program partnerski wypłaca prowizje w czasie rzeczywistym.
Odtwórz fikcyjne nieznane przesłanie
O 14:00 strategia tworzy I7 z kwalifikujących obserwacji. O 14:01 autoryzacja rezerwuje osiemdziesiąt jednostek i zatwierdza działanie. O 14:02 proces wykonawczy zapisuje próbę A7 i ją wysyła. Ścieżka odpowiedzi zawodzi przed ustaleniem końcowego wyniku.
O 14:03 drugi proces roboczy przejmuje zadanie po zatrzymaniu pierwszego. Znajduje I7, A7 i istniejącą rezerwację. Poprawny następny krok to badanie A7 i uzgodnienie konta, a nie utworzenie I8 dla kolejnego zakupu osiemdziesięciu jednostek, bo pierwotny sygnał nadal się kwalifikuje.
O 14:05 odpowiednie dowody pozwalają ustalić wynik próby i skutek na koncie. Odpowiedzialny za uzgodnienie aktualizuje pozycję i rezerwację. Incydent może wyjaśnić przedział niepewności, ścieżkę odzyskiwania i ewentualne powielenie próby lub zamiaru. Oś czasu pozwala ocenić wynik, zamiast jedynie deklarować odzyskanie systemu.
Ustal odpowiedzialność procesów roboczych bez utraty tożsamości ekonomicznej
Procesy robocze mogą używać blokad lub dzierżaw do koordynacji wykonywania zadań. Mechanizmy te wskazują, który proces może działać w danej chwili, ale utrata dzierżawy nie usuwa zamiaru ani nie dowodzi, że wcześniejsza próba nie wywołała skutku. Trwała tożsamość ekonomiczna musi przetrwać tymczasowe przypisanie zadania do procesu roboczego.
Gdy inny proces roboczy przejmuje zadanie, powinien wczytać istniejący zapis i ustalić kolejne dozwolone przejście stanu. Uruchomienie nowego procesu roboczego nie powinno oznaczać nowej transakcji. Ścieżka przywracania działania wymaga wystarczającego kontekstu, by odróżnić nieprzesłaną propozycję od przesłanej próby, której wynik pozostaje nierozstrzygnięty.
Zapisuj zmiany odpowiedzialności w historii incydentu, gdy mają znaczenie. Pomaga to ustalić, czy dwa procesy robocze działały jednocześnie, czy też przejęcie zadania respektowało wcześniejszy stan. Celem nie jest rejestrowanie każdego drobnego zdarzenia wewnętrznego, lecz zachowanie przejść potrzebnych do wyjaśnienia zachowania o istotnych skutkach.
Sprawdzaj spójność między księgami
System może sprawdzać spójność zamiarów, prób, rezerwacji i pozycji. Przesłana nierozstrzygnięta próba powinna mieć odpowiedni zamiar i obsługę zasobów. Zamknięta pozycja nie powinna zachowywać niewyjaśnionych otwartych rezerwacji wyjścia. Zwolniona rezerwacja powinna mieć uzasadniony dowodami powód.
Kontrole wykrywają relacje niewidoczne dla pojedynczego komponentu. Usługa strategii może tworzyć prawidłowe propozycje, gdy osobna księga nie zwalnia rezerwacji. Usługa wykonania może poprawnie śledzić transakcje, gdy widok pozycji się nie aktualizuje. Kontrole między zapisami ujawniają niedopasowania.
Po nieudanej kontroli zachowaj dowody i ogranicz działanie procesu, którego dotyczy rozbieżność. Nie naprawiaj automatycznie każdej rozbieżności przez usuwanie zapisów aż do zgodności sum. Poprawna naprawa zależy od przyczyny, a agresywne porządkowanie może zniszczyć historię potrzebną do ustalenia zdarzeń.
Stosuj tę samą dyscyplinę zapisu do działań ludzi
Operatorzy mogą wstrzymywać, wznawiać, nadpisywać, poprawiać lub ręcznie zmieniać konto. Działania należą do historii systemu, gdy wpływają na decyzje lub stan. Interwencja człowieka nie powinna stawać się niewyjaśnioną różnicą księgi i konta.
Zapis powinien wskazywać działanie, zakres, czas i powód bez ujawniania zbędnych danych osobowych lub tajnych. Jeśli operator zwalnia rezerwację po przeglądzie, należy podłączyć dowody wyboru. Jeśli zmienia limit, obowiązująca wersja konfiguracji powinna być jasna.
Wcześniejszy poradnik sesji operacyjnej Solana omawia przekazywanie obowiązków. Zapisy incydentów powinny zasilać przekazanie, aby następna sesja znała nadal aktywne pauzy, nadpisania i nierozstrzygnięte ograniczenia. Nowy operator nie powinien musieć odgadywać ich z rozproszonych wiadomości.
Oddziel dowody strategii od przyczyn incydentu
Sygnał strategii może błędnie oceniać rynek bez powodowania incydentu systemowego. Z kolei zyskowny wynik może nastąpić po nieautoryzowanym lub podwójnym działaniu i nadal oznaczać poważną wadę kontroli. Oceniaj wynik ekonomiczny i poprawność systemu jako osobne pytania.
Poradnik sygnałów handlowych Solana wyjaśnia związek prognoz z decyzjami i kosztami. Analiza incydentu powinna wskazywać wadliwy etap, zamiast obwiniać sygnał za każdy niekorzystny wynik. Stara migawka konta i niedokładna prognoza wymagają innych środków zaradczych.
Rozdzielenie zapobiega też ukrywaniu wad przez korzystne wyniki. Jeśli podwójny zakup przypadkowo zyskał na wartości, system nadal przekroczył zamierzone działanie. Raport incydentu powinien oceniać zachowanie względem uprawnień i reguł stanu, zamiast rozstrzygać wystąpienie wady na podstawie późniejszego zarobku konta.
Zachowuj przypisanie źródła kopiowanych decyzji
Proces kopiowania dodaje warstwę obserwacji i interpretacji przed powstaniem propozycji. System powinien zachować zdarzenie źródłowe, klasyfikację, opóźnienie obserwacji i własną decyzję naśladowcy. Transakcja źródła nie jest tym samym obiektem co zamiar naśladowcy.
Poradnik oprogramowania kopiowania transakcji Solana bada różnice. Trwałe zapisy pozwalają ustalić, czy rozbieżność naśladowcy wynikała z późnego odkrycia, innej wielkości, nieobsługiwanej interpretacji źródła czy własnej ścieżki autoryzacji i wykonania naśladowcy.
Nie pozwalaj tożsamości zdarzenia źródła zastąpić tożsamości zamiaru naśladowcy. Kilku naśladowców lub strategii może reagować różnie na tę samą obserwację, a jeden całkowicie się wstrzymać. System potrzebuje wspólnego odniesienia dowodowego i niezależnego zapisu działania właściwego kontu.
Kończ odzyskiwanie uzgodnieniem
Odzyskiwanie powinno ustalić obecny stan konta, rozstrzygnąć lub jawnie zachować nieznane próby, uzgodnić zobowiązania zasobów i zweryfikować gotowość przed wznowieniem zależnych działań. Restart usług i wyzerowanie liczników błędów nie wystarczą przy nadal niespójnym zapisie ekonomicznym.
Ograniczone wznowienie może być poprawne. Obserwacja rynku może trwać przy wstrzymaniu nowych przesłań, a strategia działać na aktywach, których problem nie dotyczy podczas przeglądu jednej pozycji. Podaj zakres, aby obecny widok dokładnie opisywał możliwości systemu.
Zapis zakończenia odzyskiwania powinien wskazywać nierozstrzygnięte ograniczenia i odpowiedzialnego za dalsze działania. Zapobiega to zamianie chwilowego obejścia w niewidoczne trwałe zachowanie. System może iść dalej przy uczciwym zapisie pozostałej niepewności.
Przekształć incydent w konkretną zmianę
Przegląd powinien wskazać najwcześniejszy wykrywalny objaw, wadliwą zmianę stanu, skutek i kontrolę, która zapobiegłaby mu lub go ograniczyła. Przydatna naprawa zmienia zapis, regułę odpowiedzialności, wymaganie przejścia lub przypadek weryfikacji.
Dla I7 poprawą może być trwały zapis próby przed przekazaniem, ściślejsze przejęcie lub kontrola spójności blokująca zwolnienie rezerwacji przy nieznanym statusie. Zmiany są konkretniejsze niż zalecenie ostrożniejszych ponowień lub ogólnej poprawy monitoringu.
Zachowaj kontrolowane odtworzenie błędu i oczekiwane poprawione zachowanie. Test powinien weryfikować przetrwanie przerwy przez ten sam zamiar i brak podwójnego działania ekonomicznego. Łączy to ustalenie incydentu z dowodem naprawy rzeczywistej przyczyny.
Zachowaj przydatność zapisów po zmianie programu
Eksportuj lub zachowuj trwałe zapisy handlowe z niezmiennymi tożsamościami, znacznikami czasu, jednostkami, wersjami reguł i relacjami korekt. Późniejszy oceniający powinien móc odtworzyć incydent nawet przy innych etykietach obecnego interfejsu. Historyczne znaczenie nie powinno zależeć od konkretnego układu ekranu.
Zapis powinien wykluczać tajne dane, zachowując ścieżkę uprawnień i istotne odniesienia konfiguracji. Zrozumienie incydentu nie powinno wymagać klucza podpisującego. Rozdzielenie umożliwia współpracę i przegląd bez rozszerzania kontroli nad kontem.
Systemowi handlowemu Solana łatwiej ufać operacyjnie, gdy jego stan można wyjaśnić w trudnych momentach. Jasna odpowiedzialność, trwałe zamiary, powiązane próby i wierne historie incydentów umożliwiają wyjaśnienie. Pozwalają odzyskiwać po niepewności przy zachowaniu dowodów potrzebnych do nauki.