True Causes
NO
Bahasa IndonesiaDanskDeutschEnglishEspañolFrançaisItalianoNederlandsNorskPolskiPortuguêsSrpski (latinica)SvenskaTiếng ViệtTürkçeΕλληνικάРусскийСрпски (ћирилица)Українська中文日本語한국어
← lobby
7/7 · Tiltak
personer: 30 · idéer: 30
prøverunde · telles ikke
hindringer · alle med lenken · offentlig oppført · føderasjon på
vert: verten dets (forseglet)
personer: 30 · idéer: 30 · 2 grupper
Pass → · Logikk → · protokoll
↗ del dette kartet
På et annet nettsted, som levende kart:
Som bilde: https://truecauses.org/d/6708d57/map.svg
Som data: alle vurderte par i dette rommet (CSV). Hver påstand har sin egen adresse, /c/6708d57/<card>, oppført under kartet.
Kreditering når du publiserer: Causal map: True Causes, https://truecauses.org/d/6708d57
SPØRSMÅLET

Why does the same outage keep recurring?

Foreslå hva som bør gjøres, og vurder så om hvert tiltak ville flytte hver rot.

Forseglet for 23 dager siden: dette rommet vet ikke lenger hvem som satt i det; bare verten er fortsatt navngitt. Det rommet kom frem til, blir stående.
ved bordet: 30 (simulerte: 29) · 3 tiltak foreslått mot 6 rotårsaker. Legg til ett, og vurder så om hvert tiltak flytter hver årsak.
Du ser på som gjest. Skriv inn et brukernavn for å bli med og delta.
Gi poeng til røttene først
hvorfor
Metodens egen praksis, før noe tiltak foreslås: hver rotårsak får poeng 1–5 for hvor gjennomførbart det er å ta tak i den, hvor stor virkning det ville ha, og hvor sannsynlig det er at den løser seg selv uten inngrep. Prioritet går til røtter med stor virkning, høy gjennomførbarhet og lav sannsynlighet for å løse seg selv — prioritet = virkning + gjennomførbarhet − sannsynlighet. Poengene snittes over gruppen og vises med hvor mange som ga poeng.
1 = lav, 5 = høy. Dine egne poeng; gruppens snitt ved siden av.
rotårsakgjennomførbartvirkningløser seg selvprioritet
The service map in the wiki is two years old––––
One engineer knows how the payment path actually works––––
Feature flags are never cleaned up, so nobody knows which paths are live––––
The on-call rota has the same two people on it most weeks––––
Rollbacks take longer than the outage they are meant to end––––
Alerts fire so often that on-call mutes them––––
Ville hvert tiltak flytte hver rotårsak?
Nedover siden: tiltakene folk foreslo. Bortover toppen: rotårsakene kartet fant. Hver rute er én avstemning om ett spørsmål — ville dette tiltaket redusere den årsaken i betydelig grad? Én side må nå 75% av de avgitte stemmene for å avgjøre det; ellers forblir ruten delt. Hver rute viser hvordan stemmene falt — ja / verre / nei — og en rute er avgjort når ett av dem når tre firedeler av stemmene.
hvorfor
Besvart ved 75% av avgitte stemmer, som alle andre spørsmål her. Delt betyr at folk stemte og ingen av sidene nådde den grensen — det er et resultat, ikke en kø, og det forblir delt til nok folk ombestemmer seg. En rute ingen avgjør, forblir uavgjort; den blir aldri til et nei. Å vurdere hvert par for seg er det som hindrer at et populært tiltak får æren for å løse ting det ikke berører.
TILTAKROTÅRSAKER · reduserer tiltaket til venstre det?
The service map in the wiki is two years oldOne engineer knows how the payment path actually worksFeature flags are never cleaned up, so nobody knows which paths are liveThe on-call rota has the same two people on it most weeksRollbacks take longer than the outage they are meant to endAlerts fire so often that on-call mutes them
No production deploy after 14:00 on Fridays unless the on-call engineer agrees diskuter✗ nei, det gjør det ikke
3 ja / 0 verre / 26 nei
⚑ gruppen ble delt
21 ja / 0 verre / 8 nei
ikke avgjort ennå
ikke avgjort ennå
ikke avgjort ennå
ikke avgjort ennå
Give the shared schema one named owner and a migration tool with rollback diskuter✗ nei, det gjør det ikke
6 ja / 0 verre / 23 nei
✓ ja, det reduserer dette
24 ja / 0 verre / 5 nei
ikke avgjort ennå
ikke avgjort ennå
ikke avgjort ennå
ikke avgjort ennå
Reserve one engineer-week per sprint for post-mortem actions, first in the sprint, not last diskuter✗ nei, det gjør det ikke
4 ja / 0 verre / 25 nei
✗ nei, det gjør det ikke
3 ja / 0 verre / 26 nei
ikke avgjort ennå
ikke avgjort ennå
ikke avgjort ennå
ikke avgjort ennå
Størst effekt så langt
Give the shared schema one named owner and a migration tool with rollback reduserer 1 av 6 rotårsaker
TILTAKENE PÅ KARTET
Viser alle tiltak rommet vurderte: det virker direkte på 1 av de 6 rotårsakene. Det virker ikke direkte på 5.
Lest ut fra rutene rommet avgjorde i fasen Tiltak, ingenting annet. En rotårsak i grønt reduseres av minst ett av de viste tiltakene; i grått virker ingen av dem direkte på den; en rød kant betyr at ett av dem gjør den verre.
Del denne visningen: som bilde · som levende kart for et annet nettsted
The same three services cause most of the pages → The staging environment does not resemble productionFeature work always outranks reliability work in planning → Post-mortem actions are written up and then never scheduledRollbacks take longer than the outage they are meant to end → Reliability has no budget line of its ownEvery team has its own logging format → Customers report outages before monitoring doesReliability has no budget line of its own → The incident channel fills with people asking for status instead of giving itReliability has no budget line of its own → The staging environment does not resemble productionPost-mortems assign actions to people who were not in the room → Post-mortem actions are written up and then never scheduledTests that fail intermittently are retried until green → Customers report outages before monitoring doesRetries are unbounded, so a slow dependency becomes a flood → The same three services cause most of the pagesAlerts fire so often that on-call mutes them → Every team has its own logging formatThe on-call rota has the same two people on it most weeks → Post-mortem actions are written up and then never scheduledThe on-call rota has the same two people on it most weeks → Alerts fire so often that on-call mutes themFeature flags are never cleaned up, so nobody knows which paths are live → The same three services cause most of the pagesFeature flags are never cleaned up, so nobody knows which paths are live → Rollbacks take longer than the outage they are meant to endOne engineer knows how the payment path actually works → The on-call rota has the same two people on it most weeksThe service map in the wiki is two years old → Feature flags are never cleaned up, so nobody knows which paths are liveFeature work always outranks reliability work in planningFeature work alwaysoutranks reliability workin planningPost-mortems assign actions to people who were not in the roomPost-mortems assign actionsto people who were not inthe roomTests that fail intermittently are retried until greenTests that failintermittently are retrieduntil greenRetries are unbounded, so a slow dependency becomes a floodRetries are unbounded, so aslow dependency becomes afloodOne engineer knows how the payment path actually works ② Give the shared schema one named owner and a migration tool with rollbackOne engineer knows how thepayment path actually works②hva de viste tiltakene gjør med denne rotårsakenREDUSERT AV 1 TILTAKThe service map in the wiki is two years oldThe service map in the wikiis two years oldhva de viste tiltakene gjør med denne rotårsakenINGEN TILTAK VIRKERDIREKTE PÅ DENFeature flags are never cleaned up, so nobody knows which paths are liveFeature flags are nevercleaned up, so nobody knowswhich paths are livehva de viste tiltakene gjør med denne rotårsakenINGEN TILTAK VIRKERDIREKTE PÅ DENThe on-call rota has the same two people on it most weeksThe on-call rota has thesame two people on it mostweekshva de viste tiltakene gjør med denne rotårsakenINGEN TILTAK VIRKERDIREKTE PÅ DENRollbacks take longer than the outage they are meant to endRollbacks take longer thanthe outage they are meantto endhva de viste tiltakene gjør med denne rotårsakenINGEN TILTAK VIRKERDIREKTE PÅ DENAlerts fire so often that on-call mutes themAlerts fire so often thaton-call mutes themhva de viste tiltakene gjør med denne rotårsakenINGEN TILTAK VIRKERDIREKTE PÅ DENThe same three services cause most of the pagesThe same three servicescause most of the pagesPost-mortem actions are written up and then never scheduledPost-mortem actions arewritten up and then neverscheduledReliability has no budget line of its ownReliability has no budgetline of its ownEvery team has its own logging formatEvery team has its ownlogging formatThe incident channel fills with people asking for status instead of giving itThe incident channel fillswith people asking forstatus instead of giving itThe staging environment does not resemble productionThe staging environmentdoes not resembleproductionCustomers report outages before monitoring doesCustomers report outagesbefore monitoring does
Hvert tall på kartet markerer en rotårsak som det tiltaket reduserer.
① No production deploy after 14:00 on Fridays unless the on-call engineer agrees
② Give the shared schema one named owner and a migration tool with rollback
③ Reserve one engineer-week per sprint for post-mortem actions, first in the sprint, not last
Hva vi venter vil følge
Forutsigelser om tiltakene: hva hvert av dem skal endre, hvordan det måles, og når det skal kontrolleres. På datoen skriver noen som var i rommet, hva som faktisk skjedde, ved siden av.
hvorfor
Et kart sier hvilke tiltak som flytter hvilke årsaker. Det sier ikke om noen gjennomførte dem, eller om noe endret seg. En oppføring her er en forutsigelse med en dato og noe å måle, skrevet etter at kartet ble avgjort. Når datoen kommer, skrives det som faktisk skjedde ved siden av, og forutsigelsen blir stående som den var: en feil forutsigelse er den nyttige typen. Ingen stemte over noe av dette, og det endrer ingenting av det rommet fant.
frist 23 Jan 2027
tiltakNo production deploy after 14:00 on Fridays unless the on-call engineer agrees
vi venterthe same cause stops coming back once fixing it is in the sprint
målt medrepeat outages with the same cause, per quarter
gjetningerrommet: 3 (median av 15, spredning 1 til 6)