Deterministyczna detekcja i ograniczona diagnoza

Monitoring produkcji powinien rozstrzygać o potrzebie diagnozy przez deterministyczne, testowane reguły. Po triggerze agent może zebrać logi, ostatnie zmiany i hipotezy, lecz nie definiuje wystąpienia anomalii ani nie dostaje uprawnień produkcyjnych z powodu severity. Maksimum wymaga wersjonowanej polityki, odtwarzalnych dowodów, ograniczonej tożsamości i ludzkiej bramki.

Pytanie scorecardu: Jak monitorujesz stan produkcji i wykrywasz anomalie wymagające działania?

Maksymalna odpowiedź: Wersjonowana polityka monitoringu ma testowane progi, diagnozę read-only, zachowanie dowodów i routing według poziomu ryzyka.

Wersjonuj politykę, nie magiczną nazwę

Użyj systemu monitoringu istniejącego w repo. Plik taki jak monitoring-policy.yaml jest przykładem, nie standardem:

signals:
  checkout_error_rate:
    source: metrics/checkout/errors
    window: 10m
    baseline: same_weekday_28d
    trigger:
      type: relative_and_absolute
      minimum_events: 100
      relative_increase: 2.0
      absolute_rate: 0.02
    action:
      risk_tier: 1
      identity: incident-diagnoser
      permissions: [read_metrics, read_logs, read_deployments]
      output: incident-intake
      dedupe_window: 30m

Dobierz sezonowość, liczebność próby, burn rate, reguły statystyczne lub progi statyczne do sygnału. Nie kopiuj uniwersalnej drabiny 1σ/2σ/3σ: progi odchylenia standardowego nie są automatycznie właściwe dla danych skośnych, rzadkich lub sezonowych.

Wymagana ścieżka wykonania

1. Platforma monitoringu ocenia wersjonowaną regułę.
2. Trigger tworzy trwałe zdarzenie z oknem metryki, query, deployment IDs i czasem.
3. Osobna tożsamość read-only zbiera ograniczoną telemetrię i kontekst repo.
4. Agent szkicuje hipotezy oraz rekord zgodny z intent.md ze źródłami.
5. Człowiek lub zadeklarowana polityka niskiego ryzyka akceptuje, odrzuca albo eskaluje rekord.
6. Zmiana kodu, rollback, merge i deploy przechodzą własne bramki.

Detektor i diagnoza muszą być testowalne niezależnie. Odtworzenie historycznego okna ma dać tę samą decyzję triggera; narracja modelu może się różnić i pozostaje analizą, nie prawdą detekcyjną.

Prompty do skopiowania

Analizuj wyłącznie dostarczony alert, metadane deploymentu i logi read-only.
Oddziel obserwacje od hipotez. Każdą obserwację podeprzyj query,
timestampem lub commitem. Zwróć wpływ, pewność, braki i bezpieczne checki.
Nie zmieniaj kodu, konfiguracji, ruchu ani stanu produkcji.

Zamień zaakceptowaną diagnozę w artefakt intake incydentu.
Uwzględnij wpływ na użytkownika, linki do dowodów, podejrzany zakres,
non-goals, ludzkiego ownera i następną bramkę SDLC.
Nie deklaruj root cause bez wystarczających dowodów.

Gdy detekcja zawodzi

Szum zalewa triage. Dodaj minimalne próbki, burn rate lub persistence, deduplikację i replay tests. Podsumowanie agenta nie naprawi złego detektora.

Logi zawierają prompt injection. Traktuj telemetrię i treści użytkowników jako niezaufane dane. Ogranicz narzędzia i nie wykonuj instrukcji znalezionych w dowodach.

Severity daje write access. Usuń to sprzężenie. Severity może zmienić odbiorcę alertu, lecz nie może tworzyć credentials ani omijać bramki produkcji.

Agent zbyt wcześnie ogłasza root cause. Wymagaj osobnych pól na obserwacje, hipotezy, kontrdowody i brakujące dane.

Weryfikacja kontroli

• Historyczne okna normalne, drift, spike i missing data mają testy.
• Decyzja triggera jest odtwarzalna bez modelu.
• Credentials diagnostyczne są read-only i rozróżnialne w audycie.
• Linki do dowodów i output narzędzi podlegają retencji.
• Dry run nie może mergować, wdrażać, cofać ani mutować produkcji.
• Zaakceptowany incydent wraca do łańcucha artefaktów przez triage.

Powrót do cyklu

Skieruj zaakceptowany intake do etapu Maintain i zastosuj poziomy z Governance i autonomia.

Q23 · Powrót do pętli Zmień zaakceptowane dowody w następną intencję.

Metryki Mierz użyteczną detekcję i odzyskiwanie.