True Causes
SR
← početna
7/7 · Akcije · pregled: Grupisanje
osoba: 30 · ideja: 30
probni prolaz · ne računa se
prepreke · svako sa linkom · na javnom spisku · federacija uključena
vodi: njen voditelj (zapečaćeno)
osoba: 30 · ideja: 30 · 2 grupe
Pasoš → · Logika → · zapis
↗ podeli ovu mapu
Na drugom sajtu, kao živa mapa:
Kao slika: https://truecauses.org/d/6708d57/map.svg
Kao podaci: svi ocenjeni parovi u ovoj sobi (CSV). Svaka tvrdnja ima svoju adresu, /c/6708d57/<card>, navedenu ispod mape.
Navedite izvor kada objavljujete: Causal map: True Causes, https://truecauses.org/d/6708d57
PITANJE

Why does the same outage keep recurring?

Grupišite kartice koje smatrate sličnim. Klasteri olakšavaju čitanje; ništa ne odlučuju.

Gledate kao gost. Unesite korisničko ime da biste se pridružili i učestvovali.
Klasteri nastaju iz sličnosti, imena dolaze na kraju
Ustaljen redosled: povežite parove ideja koje smatrate sličnim — veze su simetrične (A~B je isto što i B~A; smer nikad nije važan), a veza važi kada je napravi dovoljno članova (2).
zašto
Veze su simetrične — A~B je isto što i B~A. Klasteri su skupovi koji nastaju iz veza koje važe, i samo nastali klaster može da dobije ime, i to od osobe. Uz vaše veze stoji ✕ za povlačenje; tuđe veze ne možete da uklonite. Klasteri uređuju zid i nikad ne ograničavaju glasanje — dve kartice koje iznose istu TVRDNJU spajaju se, i to u fazi Pojašnjavanje.
Veze i imena se prave dok je faza Grupisanje otvorena; voditeljevo ← je ponovo otvara.
zatvori ✕
Config lives in five places and drifts between them
I mean the pattern over the last two quarters, not a single incident.
klaster 3
Još ništa nije rečeno.
klaster bez imena — dajte mu ime ako grupa u njemu vidi zajedničku nit, ili ga ostavite bez imena (2)
Alerts fire so often that on-call mutes them
~ Customers report outa…Customers report outages before monitoring does (12)
diskutuj
Customers report outages before monitoring does
~ Alerts fire so often …Alerts fire so often that on-call mutes them (12)
diskutuj
klaster bez imena — dajte mu ime ako grupa u njemu vidi zajedničku nit, ili ga ostavite bez imena (2)
The same three services cause most of the pages
~ The on-call rota has …The on-call rota has the same two people on it most weeks (20)
diskutuj
The on-call rota has the same two people on it most weeks
~ The same three servic…The same three services cause most of the pages (20)
diskutuj
klaster bez imena — dajte mu ime ako grupa u njemu vidi zajedničku nit, ili ga ostavite bez imena (2)
Every team has its own logging format
~ Reliability has no bu…Reliability has no budget line of its own (15)
diskutuj
Reliability has no budget line of its own
~ Every team has its ow…Every team has its own logging format (15)
diskutuj
klaster bez imena — dajte mu ime ako grupa u njemu vidi zajedničku nit, ili ga ostavite bez imena (2)
Runbooks are out of date within a month of being written
~ The service map in th…The service map in the wiki is two years old (16)
diskusija (1)
The service map in the wiki is two years old
~ Runbooks are out of d…Runbooks are out of date within a month of being written (16)
diskutuj
klaster bez imena — dajte mu ime ako grupa u njemu vidi zajedničku nit, ili ga ostavite bez imena (2)
Post-mortem actions are written up and then never scheduled
~ Post-mortems assign a…Post-mortems assign actions to people who were not in the room (9)
~ Feature flags are nev…Feature flags are never cleaned up, so nobody knows which paths are live (14)
diskutuj
Feature flags are never cleaned up, so nobody knows which paths are live
~ Post-mortem actions a…Post-mortem actions are written up and then never scheduled (14)
diskutuj
klaster bez imena — dajte mu ime ako grupa u njemu vidi zajedničku nit, ili ga ostavite bez imena (2)
Config lives in five places and drifts between them
~ Migrations are run by…Migrations are run by hand from a laptop (21)
u fokusu ↑ · zatvori ✕
Migrations are run by hand from a laptop
~ Config lives in five …Config lives in five places and drifts between them (21)
diskutuj
· još nije u klasteru (18)
Tests that fail intermittently are retried until green
Leadership asks for a root cause within the hour, so the first plausible one wins
Success is measured in features shipped per quarter
Dependencies are upgraded only when something breaks
Deploys go out on Friday afternoons because that is when the sprint ends
Rollbacks take longer than the outage they are meant to end
Post-mortems assign actions to people who were not in the room
~ Post-mortem actions a…Post-mortem actions are written up and then never scheduled (9)
diskutuj
Feature work always outranks reliability work in planning
There is no time set aside after an incident, so the write-up is done at midnight
Incidents are declared late because declaring one feels like blame
Load tests were last run before the customer base doubled
One engineer knows how the payment path actually works
Error budgets exist on a slide and nowhere else
The staging environment does not resemble production
The incident channel fills with people asking for status instead of giving it
Nobody owns the shared database schema
Retries are unbounded, so a slow dependency becomes a flood
Capacity is added after the outage, never before