True Causes
JA
← ロビー
7/7 · 対策
30人 · アイデア30件
完了した段階をタップすると見られます
✓
アイデア出し
✓
明確化
✓
分類
✓
選択
✓
構造化
✓
マップ
7
対策
実演 · 集計対象外
障害 · リンクを知っている人 · 公開一覧に掲載 · 連合あり
進行役:そのルームの進行役(封印済み)
30人 · アイデア30件 · 2グループ
パスポート → · 論理 → · 記録
↗ このマップを共有
他のサイトにライブマップとして:
画像として: https://truecauses.org/d/6708d57/map.svg
データとして: このルームで判断されたすべてのペア(CSV). 各主張には固有のアドレス /c/6708d57/<card> があり、マップの下に一覧があります。
公開するときのクレジット表記: Causal map: True Causes, https://truecauses.org/d/6708d57
問い

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 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 議論する✗ いいえ、減らしません
はい 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件には直接働きかけません。
対策の段階でルームが決着させたマスだけから読み取っています。緑の根本原因は、表示中の対策の少なくとも1つで軽減されます。灰色は、どの対策も直接働きかけません。赤い枠線は、いずれかの対策が悪化させることを示します。
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②表示中の対策がこの根本原因に及ぼす効果1件の対策で軽減The service map in the wiki is two years oldThe service map in the wikiis two years old表示中の対策がこの根本原因に及ぼす効果直接働きかける対策なしFeature flags are never cleaned up, so nobody knows which paths are liveFeature flags are nevercleaned up, so nobody knowswhich paths are live表示中の対策がこの根本原因に及ぼす効果直接働きかける対策なしThe on-call rota has the same two people on it most weeksThe on-call rota has thesame two people on it mostweeks表示中の対策がこの根本原因に及ぼす効果直接働きかける対策なしRollbacks take longer than the outage they are meant to endRollbacks take longer thanthe outage they are meantto end表示中の対策がこの根本原因に及ぼす効果直接働きかける対策なしAlerts fire so often that on-call mutes themAlerts fire so often thaton-call mutes them表示中の対策がこの根本原因に及ぼす効果直接働きかける対策なしThe 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
マップ上の各番号は、その対策が減らす根本原因を示します。
① 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)