Badaj i naprawiaj

Przebiegi naprawy

Jeden agent na problem dochodzi do werdyktu, namierza przyczynę i otwiera pull request, w jednym wątku, który czytasz od początku do końca.

Przebieg naprawy to agent pracujący nad jednym problemem. Każdy problem dostaje najwyżej jeden: wątek typu fix_run, który dochodzi do werdyktu, a w przypadku potwierdzonego problemu dalej prowadzi go do poprawki w tej samej rozmowie.

Co robi

Wątek jest miejscem, w którym czytasz całą historię: pracę w trakcie, dowody o jedno kliknięcie dalej w jego rodowodzie i wynik na końcu. Przebieg czyta alert albo ustalenie, stojące za nim zapytanie, ostatnie metryki i logi z okolic uruchomienia, ostatnie zmiany i twój kod. Zanim zadziała, spisuje w wątku łańcuch przyczynowy: sygnał, mechanizm, komponent i ścieżkę w kodzie, które go wywołują, wyzwalacz i blast radius, a każde ogniwo jest poparte nazwanym dowodem albo oznaczone jako nieznane.

Jak to działa

  1. Przebieg zaczyna się, gdy kontrola albo połączony alert daje ustalenie, gdy agent w wątku czatu otwiera problem z kłopotu, o którym rozmawiacie, albo gdy wybierzesz Investigate na problemie.
  2. Agent czyta dowody i dochodzi do jednego z dwóch werdyktów: confirmed albo dismissed. Ustalenie pasujące do istniejącego problemu dołącza do niego, zamiast rozpoczynać drugi przebieg.
  3. W przypadku potwierdzonego problemu ten sam agent namierza przyczynę i spisuje łańcuch przyczynowy.
  4. Gdy przyczynę naprawia zmiana w kodzie w połączonym repozytorium, przebieg otwiera pull request przez autofix. Gdy żaden pull request nie może jej naprawić, przebieg zgłasza eskalację, która nazywa, co musi zrobić człowiek.
  5. Każdy krok trafia na oś czasu aktywności problemu, obok wykryć, ponownych wykryć i twoich własnych notatek.

Wyniki

Po każdej turze agenta Polylane klasyfikuje przebieg.

WynikOpis
resolvedPrzyczyna źródłowa znaleziona, a problem jest naprawiony albo ustąpił.
diagnosedPrzyczyna źródłowa znaleziona, ale poprawka jeszcze nie trafiła na miejsce.
inconclusiveAgent nie zdołał ustalić przyczyny.
false_positiveUstalenie nie wskazywało prawdziwego problemu.
failedPrzebieg zakończył się błędem.

Przebieg może też zostać odłożony, co powstrzymuje monitorowanie przed ponaglaniem go do ponownego dochodzenia, dopóki problem się nie rozwiąże.

Stan odłożeniaOpis
needs_human_actionNaprawa wymaga czegoś, co możesz zrobić tylko ty.
needs_decisionAgent potrzebuje twojej decyzji, zanim będzie kontynuować.
awaiting_changeAgent czeka, aż poprawka trafi na miejsce, na przykład pull request czeka na przegląd. Ten stan odkłada przebieg po cichu.
failedPrzebieg napotkał błąd, którego nie zdołał obejść.

Trzy stany wymagające człowieka są zapisywane jako eskalacje, pokazywane na karcie wyniku w wątku i wymieniane w presecie Needs you, więc ta sama prośba nigdy nie powiadamia cię dwa razy.

Gdzie to znaleźć

Przebiegi naprawy pojawiają się w sekcji Threads obok wątków czatu, a preset Needs you wymienia te, które czekają na osobę. Lineage w panelu bocznym wątku zawiera rekord stojący za przebiegiem: Issue otwiera dowody i oś czasu problemu, Escalation otwiera to, o co agent cię poprosił, z przyciskiem Mark as handled, a Check otwiera ocenę, która wykryła problem. Menu problemu zawiera Investigate, Investigate again, View investigation i View triggering check.

Konfiguracja

W Settings > Workspace karta Investigations ustawia Investigate automatically from: najniższą krytyczność, od której przebieg naprawy startuje samoczynnie. Problemy poniżej niej zachowują werdykt i są wstrzymane, a ich wątek oferuje Start investigation, żeby ktoś z twojego zespołu mógł je podjąć. Werdykty nigdy nie są wstrzymywane: każdy potwierdzony problem jest widocznie potwierdzony, a próg odracza tylko pracę, która następuje potem.

Powiązane

  • Problemy: rekord, nad którym pracuje każdy przebieg naprawy.
  • Threads: czytanie, zatrzymywanie i udostępnianie przebiegu.
  • Escalations: prośby, które zgłasza odłożony przebieg.
  • Autofix: pull request, który otwiera przebieg.