Skoči na glavni sadržaj
Natrag na OpenClaw vodič

Oriphiel OpenClaw vodič

Incident response za CRM

Kako klasificirati kvar ili sigurnosni događaj, zaustaviti štetu, sačuvati dokaz, vratiti uslugu i spriječiti ponavljanje.

Oriphiel stručni tim Ažurirano 22. 7. 2026. 3 min čitanja

Odgovor ukratko

Runbook unaprijed definira tko odlučuje, kako se gasi slanje, gdje su logovi i kako se komunicira; incident nije trenutak za traženje lozinki i vlasnika.

Ključne odluke

  • Koja ozbiljnost se dodjeljuje
  • Tko je incident commander
  • Koji kill switch postoji
  • Kada se obavještavaju korisnici ili nadležni

Provedba korak po korak

Cilj ove lekcije je Kako klasificirati kvar ili sigurnosni događaj, zaustaviti štetu, sačuvati dokaz, vratiti uslugu i spriječiti ponavljanje. Korake treba provoditi redom i svaki potvrditi prije širenja opsega.

Preporučeni redoslijed

  • Definirati scenarije za data leak, pogrešan batch, auth failure i outage
  • Uvježbati zaustavljanje queuea
  • Sačuvati timeline i dokaze
  • Nakon oporavka dodati trajnu korektivnu mjeru

Praktičan primjer

Nakon neočekivanog skoka SMTP rejecta dežurni pauzira sve outbound workere, čuva correlation ID-eve, provjerava reputaciju i nastavlja samo na malom canary batchu.

Kontrolna lista prije nastavka

Ova provjera odvaja završenu implementaciju od postavke koja samo izgleda dovršeno.

Provjerite

  • Kontakti i eskalacije su aktualni
  • Kill switch radi i za workere
  • Backup logova nije promijenjen
  • Postmortem ima vlasnika svake akcije

Najčešće pogreške i rizici

Rizike treba provjeriti prije povećanja prometa, automatizacije ili ovlasti sustava.

Na što treba paziti

  • Incident se rješava brisanjem loga
  • Komunikacija nema jednog vlasnika
  • Queue nastavlja raditi nakon gašenja UI-ja
  • Isti uzrok se ponavlja

Mjerenje rezultata

Učinak se procjenjuje kroz mali skup metrika koje su povezane s ciljem lekcije i stvarnim poslovnim ishodom.

Metrike koje imaju smisla

  • Mean time to detect
  • Mean time to contain
  • Mean time to recover
  • Ponovljeni incidenti

Česta pitanja

Koji je prvi korak za temu „Incident response za CRM”?

Definirati scenarije za data leak, pogrešan batch, auth failure i outage Prije nastavka potvrdite odluku: Koja ozbiljnost se dodjeljuje

Kako provjeriti da je provedba uspješna?

Kontakti i eskalacije su aktualni Nakon toga pratite metriku: Mean time to detect.

Koju pogrešku treba prvo spriječiti?

Incident se rješava brisanjem loga Problem ispravite prije automatizacije ili povećanja budžeta.

Službeni i stručni izvori

Sučelja, pravila i preporuke mogu se mijenjati. Prije produkcijske izmjene provjerite aktualnu dokumentaciju.

Primijenite lekciju na stvarni projekt

Pošaljite postojeću konfiguraciju, cilj i problem koji želite riješiti. Dobit ćete prijedlog sljedećeg tehničkog ili operativnog koraka.