PAS · HVAD DETTE RUM GJORDE
Why does the same outage keep recurring?
Hver linje stammer fra historikken. Intet er beregnet til denne side, og intet er glattet ud: en kort liste over uenigheder betyder et rum, der var enigt, ikke et rum, hvis uenigheder blev ryddet af vejen.
| strukturerer | forhindringer |
| åbnet | 08 Sep 2026 |
| hvem svarede | personer: 30, grupper: 2 · deltager: 30 |
| skrev blindt | ikke registreret |
| påstande | skrevet: 30, struktureret: 20 |
| godkendte koblinger | 20 |
| rum om dette spørgsmål | 1 · tæller ikke med i det fælles kort |
| afgjort ved | 75 % af de afgivne stemmer |
| forseglet | ja, medlemmerne er glemt |
Hvad det hviler på- 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
Hvad det ikke kunne afgøreOffentliggjort som omstridt, aldrig registreret som et nej.
- ingen: hvert par, rummet nåede til, blev afgjort
Hvad der blev forudsagt at følgeSkrevet, efter kortet var afgjort. Ingen stemte om det.
- No production deploy after 14:00 on Fridays unless the on-call engineer agrees — forventet: the same cause stops coming back once fixing it is in the sprint — frist 23 Jan 2027
Hvad rummet ville gøreHver handling vurderet over for hver grundårsag, ved tre fjerdedele af de afgivne stemmer.
- No production deploy after 14:00 on Fridays unless the on-call engineer agrees
delt: One engineer knows how the payment path actually works - Give the shared schema one named owner and a migration tool with rollback
mindsker: One engineer knows how the payment path actually works - Reserve one engineer-week per sprint for post-mortem actions, first in the sprint, not last
mindsker ingen grundårsag
← dialogen