질문
Why does the same outage keep recurring?
할 일을 제안한 뒤, 각 대책이 각 근원을 움직일지 판단하세요.
봉인됨 23일 전: 이 방은 더 이상 누가 참여했는지 알지 못합니다. 진행자의 이름만 남아 있습니다. 결론은 그대로 남습니다.
참여자 30명 (시뮬레이션 29명) · 근본 원인 6개에 대해 대책 3개 제안됨. 대책을 하나 더하고, 각 대책이 각 원인을 움직이는지 판정하세요.
게스트로 보는 중. 참여하려면 닉네임을 입력하세요.
근원 점수부터 매기기
이유
대책을 제안하기 전에 이 방법이 쓰는 절차입니다. 각 근본 원인에 1~5점을 줍니다. 해결하기가 얼마나 쉬운지, 해결하면 효과가 얼마나 큰지, 아무것도 하지 않아도 저절로 해결될 가능성이 얼마나 되는지입니다. 효과가 크고, 쉽고, 저절로 해결될 가능성이 낮은 근원이 우선입니다. 우선순위 = 효과 + 실현 가능성 − 저절로 해결될 가능성. 점수는 그룹 전체의 평균이며, 점수를 준 사람 수와 함께 나옵니다.
1 = 낮음, 5 = 높음. 내 점수 옆에 그룹 평균이 나옵니다.
| 근본 원인 | 실현 가능성 | 효과 | 저절로 해결 | 우선순위 |
|---|---|---|---|---|
| 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 | – | – | – | – |
각 대책이 각 근본 원인을 움직일까요?
세로: 사람들이 제안한 대책. 가로: 지도가 찾은 근본 원인. 칸 하나가 질문 하나에 대한 투표입니다 — 이 대책이 그 원인을 크게 줄일까요? 어느 한쪽이 던진 표의 75%에 이르러야 확정되고, 그러지 못하면 의견이 갈린 칸으로 남습니다. 각 칸에는 표가 어떻게 나뉘었는지 나옵니다 — 예 / 악화 / 아니요 — 그중 하나가 4분의 3에 이르면 그 칸이 확정됩니다.
이유
다른 모든 질문처럼 던진 표의 75%로 답이 정해집니다. 의견이 갈림은 사람들이 투표했지만 어느 쪽도 기준에 이르지 못했다는 뜻입니다. 대기 상태가 아니라 결과이며, 충분한 사람이 생각을 바꿀 때까지 그대로입니다. 아무도 확정하지 않은 칸은 미결로 남고, 아니요로 바뀌지 않습니다. 쌍마다 따로 판단하기 때문에, 인기 있는 대책이 건드리지도 않는 문제를 고친 것으로 인정받지 않습니다.
| 대책 | 근본 원인 · 왼쪽 대책이 이것을 줄입니까? | |||||
|---|---|---|---|---|---|---|
| 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 | |
| No production deploy after 14:00 on Fridays unless the on-call engineer agrees 논의하기 | ✗ 아니요, 줄이지 않습니다 예 3 / 악화 0 / 아니요 26 | ⚑ 그룹 의견이 갈림 예 21 / 악화 0 / 아니요 8 | 아직 결정 안 됨 | 아직 결정 안 됨 | 아직 결정 안 됨 | 아직 결정 안 됨 |
| Give the shared schema one named owner and a migration tool with rollback 논의하기 | ✗ 아니요, 줄이지 않습니다 예 6 / 악화 0 / 아니요 23 | ✓ 예, 이것을 줄입니다 예 24 / 악화 0 / 아니요 5 | 아직 결정 안 됨 | 아직 결정 안 됨 | 아직 결정 안 됨 | 아직 결정 안 됨 |
| Reserve one engineer-week per sprint for post-mortem actions, first in the sprint, not last 논의하기 | ✗ 아니요, 줄이지 않습니다 예 4 / 악화 0 / 아니요 25 | ✗ 아니요, 줄이지 않습니다 예 3 / 악화 0 / 아니요 26 | 아직 결정 안 됨 | 아직 결정 안 됨 | 아직 결정 안 됨 | 아직 결정 안 됨 |
지금까지 가장 효과가 큰 대책
Give the shared schema one named owner and a migration tool with rollback 근본 원인 6개 중 1개를 줄임
지도 위의 대책
표시 중: 방이 판정한 모든 대책. 근본 원인 6개 중 1개에 직접 작용합니다. 5개에는 직접 작용하지 않습니다.
대책 단계에서 방이 확정한 칸만 보고 그렸습니다. 초록색 근본 원인은 표시된 대책 중 하나 이상으로 줄어들고, 회색은 어느 대책도 직접 작용하지 않으며, 빨간 테두리는 그중 하나가 더 나빠지게 한다는 뜻입니다.
이 화면 공유: 이미지로 · 다른 사이트에 넣는 실시간 지도로
지도의 각 번호는 그 대책이 줄이는 근본 원인을 표시합니다.
① 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
이어질 것으로 예상하는 일
대책에 대한 예측: 각 대책이 무엇을 바꿔야 하는지, 어떻게 측정하는지, 언제 확인하는지. 그날이 오면 방에 있던 사람이 실제로 일어난 일을 옆에 적습니다.
이유
지도는 어떤 대책이 어떤 원인을 움직이는지 보여 줍니다. 누가 그 대책을 실행했는지, 무엇이 달라졌는지는 보여 주지 않습니다. 여기 항목은 날짜와 측정할 것이 있는 예측이며, 지도가 확정된 뒤에 씁니다. 날짜가 되면 실제로 일어난 일을 옆에 적고, 예측은 그대로 남습니다. 틀린 예측이 오히려 쓸모 있습니다. 여기에는 아무도 투표하지 않았고, 방이 찾은 결과를 바꾸지 않습니다.
기한 23 Jan 2027
대책No production deploy after 14:00 on Fridays unless the on-call engineer agrees
예상the same cause stops coming back once fixing it is in the sprint
측정 기준repeat outages with the same cause, per quarter
예측값방 전체: 3 (15명의 중앙값, 범위 1~6)