構造化 · Why does the same outage keep recurring?

問い

Why does the same outage keep recurring?

一方は他方に大きく影響しますか？投じられた票の4分の3で決まります。

ゲストとして閲覧中。参加するにはユーザー名を入力してください。

問いはグループに分配されるので、あなたに届くのは自分のグループに割り当てられたものだけです（全180件ではありません）。

理由

数百ものペアに答えられる人はいません。各ペアは一つのグループに渡され、意見が割れたペアは他のグループに回されます。そのため、別のところで始まったペアが後からあなたの一覧に現れることがあります。決着の数にはすべてのグループの作業が含まれるので、自分の一覧が減るより速く増えていきます。

決着 176/180 あなたの回答待ち：0

前回の集計：決着 176 · グループ横断パネルへ回付 1 · 争いあり 0 · 定足数未満 3 — パネルには max(2, パネルの75%) 以上の票が必要です。最小のパネルのメンバーは15人です.

閉じる ✕

The incident channel fills with people asking for status instead of giving it → 影響する？ → Retries are unbounded, so a slow dependency becomes a flood

まだ発言はありません。

完了した段階です。ペアと投票の記録は上にあります。論理を確かめる ↗

Reliability has no budget line of its own	→	Feature flags are never cleaned up, so nobody knows which paths are live	未決	議論する
The same three services cause most of the pages	→	…	未決	議論する
The incident channel fills with people asking for status instead of giving it	→	The service map in the wiki is two years old	未決	議論する
The staging environment does not resemble production	→	Rollbacks take longer than the outage they are meant to end	未決回付済み	議論する
Tests that fail intermittently are retried until green	→	Customers report outages before monitoring does	✓ はい	議論する
Alerts fire so often that on-call mutes them	→	Customers report outages before monitoring does	✓ はい	議論する
Alerts fire so often that on-call mutes them	→	Every team has its own logging format	✓ はい	議論する
Every team has its own logging format	→	Customers report outages before monitoring does	✓ はい	議論する
The on-call rota has the same two people on it most weeks	→	Alerts fire so often that on-call mutes them	✓ はい	議論する
Feature work always outranks reliability work in planning	→	Post-mortem actions are written up and then never scheduled	✓ はい	議論する
One engineer knows how the payment path actually works	→	The on-call rota has the same two people on it most weeks	✓ はい	議論する
The on-call rota has the same two people on it most weeks	→	Post-mortem actions are written up and then never scheduled	✓ はい	議論する
Post-mortems assign actions to people who were not in the room	→	Post-mortem actions are written up and then never scheduled	✓ はい	議論する
The service map in the wiki is two years old	→	The staging environment does not resemble production	✓ はい	議論する
Rollbacks take longer than the outage they are meant to end	→	Reliability has no budget line of its own	✓ はい	議論する
Reliability has no budget line of its own	→	The staging environment does not resemble production	✓ はい	議論する
Retries are unbounded, so a slow dependency becomes a flood	→	The same three services cause most of the pages	✓ はい	議論する
Reliability has no budget line of its own	→	The incident channel fills with people asking for status instead of giving it	✓ はい	議論する
The same three services cause most of the pages	→	The staging environment does not resemble production	✓ はい	議論する
The service map in the wiki is two years old	→	Feature flags are never cleaned up, so nobody knows which paths are live	✓ はい	議論する
Feature flags are never cleaned up, so nobody knows which paths are live	→	Rollbacks take longer than the outage they are meant to end	✓ はい	議論する
Feature flags are never cleaned up, so nobody knows which paths are live	→	The same three services cause most of the pages	✓ はい	議論する
The on-call rota has the same two people on it most weeks	→	Customers report outages before monitoring does	✓ 推論	議論する
Retries are unbounded, so a slow dependency becomes a flood	→	The staging environment does not resemble production	✓ 推論	議論する
Post-mortem actions are written up and then never scheduled	→	Every team has its own logging format	✗ いいえ	議論する
Every team has its own logging format	→	Error budgets exist on a slide and nowhere else	✗ いいえ	議論する
Feature work always outranks reliability work in planning	→	Customers report outages before monitoring does	✗ いいえ	議論する
Error budgets exist on a slide and nowhere else	→	Tests that fail intermittently are retried until green	✗ いいえ	議論する
Error budgets exist on a slide and nowhere else	→	One engineer knows how the payment path actually works	✗ いいえ	議論する
Error budgets exist on a slide and nowhere else	→	Post-mortems assign actions to people who were not in the room	✗ いいえ	議論する
Customers report outages before monitoring does	→	Post-mortems assign actions to people who were not in the room	✗ いいえ	議論する
Post-mortem actions are written up and then never scheduled	→	Alerts fire so often that on-call mutes them	✗ いいえ	議論する
Post-mortems assign actions to people who were not in the room	→	Alerts fire so often that on-call mutes them	✗ いいえ	議論する
Error budgets exist on a slide and nowhere else	→	Customers report outages before monitoring does	✗ いいえ	議論する
Customers report outages before monitoring does	→	The on-call rota has the same two people on it most weeks	✗ いいえ	議論する
Post-mortem actions are written up and then never scheduled	→	Post-mortems assign actions to people who were not in the room	✗ いいえ	議論する
Feature work always outranks reliability work in planning	→	Tests that fail intermittently are retried until green	✗ いいえ	議論する
Tests that fail intermittently are retried until green	→	The on-call rota has the same two people on it most weeks	✗ いいえ	議論する
Post-mortem actions are written up and then never scheduled	→	The on-call rota has the same two people on it most weeks	✗ いいえ	議論する
Feature work always outranks reliability work in planning	→	Error budgets exist on a slide and nowhere else	✗ いいえ	議論する
Tests that fail intermittently are retried until green	→	Every team has its own logging format	✗ いいえ	議論する
The on-call rota has the same two people on it most weeks	→	Tests that fail intermittently are retried until green	✗ いいえ	議論する
Post-mortems assign actions to people who were not in the room	→	Every team has its own logging format	✗ いいえ	議論する
Feature work always outranks reliability work in planning	→	Post-mortems assign actions to people who were not in the room	✗ いいえ	議論する
Tests that fail intermittently are retried until green	→	Alerts fire so often that on-call mutes them	✗ いいえ	議論する
Post-mortems assign actions to people who were not in the room	→	Error budgets exist on a slide and nowhere else	✗ いいえ	議論する
Alerts fire so often that on-call mutes them	→	One engineer knows how the payment path actually works	✗ いいえ	議論する
Customers report outages before monitoring does	→	One engineer knows how the payment path actually works	✗ いいえ	議論する
Alerts fire so often that on-call mutes them	→	Post-mortem actions are written up and then never scheduled	✗ いいえ	議論する
Post-mortems assign actions to people who were not in the room	→	The on-call rota has the same two people on it most weeks	✗ いいえ	議論する
One engineer knows how the payment path actually works	→	Alerts fire so often that on-call mutes them	✗ いいえ	議論する
Customers report outages before monitoring does	→	Alerts fire so often that on-call mutes them	✗ いいえ	議論する
Error budgets exist on a slide and nowhere else	→	The on-call rota has the same two people on it most weeks	✗ いいえ	議論する
Feature work always outranks reliability work in planning	→	Every team has its own logging format	✗ いいえ	議論する
Customers report outages before monitoring does	→	Post-mortem actions are written up and then never scheduled	✗ いいえ	議論する
Customers report outages before monitoring does	→	Every team has its own logging format	✗ いいえ	議論する
Customers report outages before monitoring does	→	Error budgets exist on a slide and nowhere else	✗ いいえ	議論する
Post-mortem actions are written up and then never scheduled	→	One engineer knows how the payment path actually works	✗ いいえ	議論する
Customers report outages before monitoring does	→	Tests that fail intermittently are retried until green	✗ いいえ	議論する
Every team has its own logging format	→	The on-call rota has the same two people on it most weeks	✗ いいえ	議論する
Every team has its own logging format	→	Post-mortems assign actions to people who were not in the room	✗ いいえ	議論する
Every team has its own logging format	→	Post-mortem actions are written up and then never scheduled	✗ いいえ	議論する
Post-mortem actions are written up and then never scheduled	→	Tests that fail intermittently are retried until green	✗ いいえ	議論する
The on-call rota has the same two people on it most weeks	→	Error budgets exist on a slide and nowhere else	✗ いいえ	議論する
Alerts fire so often that on-call mutes them	→	The on-call rota has the same two people on it most weeks	✗ いいえ	議論する
One engineer knows how the payment path actually works	→	Tests that fail intermittently are retried until green	✗ いいえ	議論する
Tests that fail intermittently are retried until green	→	Post-mortems assign actions to people who were not in the room	✗ いいえ	議論する
Feature work always outranks reliability work in planning	→	Alerts fire so often that on-call mutes them	✗ いいえ	議論する
Customers report outages before monitoring does	→	Feature work always outranks reliability work in planning	✗ いいえ	議論する
One engineer knows how the payment path actually works	→	Customers report outages before monitoring does	✗ いいえ	議論する
Post-mortems assign actions to people who were not in the room	→	Customers report outages before monitoring does	✗ いいえ	議論する
Error budgets exist on a slide and nowhere else	→	Feature work always outranks reliability work in planning	✗ いいえ	議論する
Alerts fire so often that on-call mutes them	→	Post-mortems assign actions to people who were not in the room	✗ いいえ	議論する
One engineer knows how the payment path actually works	→	Post-mortem actions are written up and then never scheduled	✗ いいえ	議論する
The on-call rota has the same two people on it most weeks	→	One engineer knows how the payment path actually works	✗ いいえ	議論する
Tests that fail intermittently are retried until green	→	One engineer knows how the payment path actually works	✗ いいえ	議論する
The on-call rota has the same two people on it most weeks	→	Every team has its own logging format	✗ いいえ	議論する
Alerts fire so often that on-call mutes them	→	Tests that fail intermittently are retried until green	✗ いいえ	議論する
Every team has its own logging format	→	One engineer knows how the payment path actually works	✗ いいえ	議論する
The on-call rota has the same two people on it most weeks	→	Post-mortems assign actions to people who were not in the room	✗ いいえ	議論する
Post-mortems assign actions to people who were not in the room	→	Tests that fail intermittently are retried until green	✗ いいえ	議論する
Every team has its own logging format	→	Alerts fire so often that on-call mutes them	✗ いいえ	議論する
The on-call rota has the same two people on it most weeks	→	Feature work always outranks reliability work in planning	✗ いいえ	議論する
Tests that fail intermittently are retried until green	→	Feature work always outranks reliability work in planning	✗ いいえ	議論する
Tests that fail intermittently are retried until green	→	Post-mortem actions are written up and then never scheduled	✗ いいえ	議論する
Error budgets exist on a slide and nowhere else	→	Alerts fire so often that on-call mutes them	✗ いいえ	議論する
Error budgets exist on a slide and nowhere else	→	Post-mortem actions are written up and then never scheduled	✗ いいえ	議論する
Post-mortems assign actions to people who were not in the room	→	Feature work always outranks reliability work in planning	✗ いいえ	議論する
One engineer knows how the payment path actually works	→	Feature work always outranks reliability work in planning	✗ いいえ	議論する
Error budgets exist on a slide and nowhere else	→	Every team has its own logging format	✗ いいえ	議論する
Tests that fail intermittently are retried until green	→	Error budgets exist on a slide and nowhere else	✗ いいえ	議論する
Post-mortem actions are written up and then never scheduled	→	Error budgets exist on a slide and nowhere else	✗ いいえ	議論する
Post-mortem actions are written up and then never scheduled	→	Customers report outages before monitoring does	✗ いいえ	議論する
Every team has its own logging format	→	Tests that fail intermittently are retried until green	✗ いいえ	議論する
One engineer knows how the payment path actually works	→	Post-mortems assign actions to people who were not in the room	✗ いいえ	議論する
Feature work always outranks reliability work in planning	→	One engineer knows how the payment path actually works	✗ いいえ	議論する
Every team has its own logging format	→	Feature work always outranks reliability work in planning	✗ いいえ	議論する
One engineer knows how the payment path actually works	→	Error budgets exist on a slide and nowhere else	✗ いいえ	議論する
Alerts fire so often that on-call mutes them	→	Error budgets exist on a slide and nowhere else	✗ いいえ	議論する
Post-mortems assign actions to people who were not in the room	→	One engineer knows how the payment path actually works	✗ いいえ	議論する
Alerts fire so often that on-call mutes them	→	Feature work always outranks reliability work in planning	✗ いいえ	議論する
One engineer knows how the payment path actually works	→	Every team has its own logging format	✗ いいえ	議論する
Feature work always outranks reliability work in planning	→	The on-call rota has the same two people on it most weeks	✗ いいえ	議論する
Post-mortem actions are written up and then never scheduled	→	Feature work always outranks reliability work in planning	✗ いいえ	議論する
The same three services cause most of the pages	→	The service map in the wiki is two years old	✗ いいえ	議論する
Rollbacks take longer than the outage they are meant to end	→	The same three services cause most of the pages	✗ いいえ	議論する
Config lives in five places and drifts between them	→	Rollbacks take longer than the outage they are meant to end	✗ いいえ	議論する
…	→	The staging environment does not resemble production	✗ いいえ	議論する
The incident channel fills with people asking for status instead of giving it	→	Config lives in five places and drifts between them	✗ いいえ	議論する
Reliability has no budget line of its own	→	Retries are unbounded, so a slow dependency becomes a flood	✗ いいえ	議論する
The incident channel fills with people asking for status instead of giving it	→	Rollbacks take longer than the outage they are meant to end	✗ いいえ	議論する
The same three services cause most of the pages	→	The incident channel fills with people asking for status instead of giving it	✗ いいえ	議論する
The service map in the wiki is two years old	→	Retries are unbounded, so a slow dependency becomes a flood	✗ いいえ	議論する
Config lives in five places and drifts between them	→	Feature flags are never cleaned up, so nobody knows which paths are live	✗ いいえ	議論する
The incident channel fills with people asking for status instead of giving it	→	Feature flags are never cleaned up, so nobody knows which paths are live	✗ いいえ	議論する
Retries are unbounded, so a slow dependency becomes a flood	→	The service map in the wiki is two years old	✗ いいえ	議論する
…	→	Reliability has no budget line of its own	✗ いいえ	議論する
The service map in the wiki is two years old	→	Rollbacks take longer than the outage they are meant to end	✗ いいえ	議論する
Feature flags are never cleaned up, so nobody knows which paths are live	→	Reliability has no budget line of its own	✗ いいえ	議論する
Feature flags are never cleaned up, so nobody knows which paths are live	→	The incident channel fills with people asking for status instead of giving it	✗ いいえ	議論する
Rollbacks take longer than the outage they are meant to end	→	…	✗ いいえ	議論する
The incident channel fills with people asking for status instead of giving it	→	Reliability has no budget line of its own	✗ いいえ	議論する
Config lives in five places and drifts between them	→	The staging environment does not resemble production	✗ いいえ	議論する
…	→	Config lives in five places and drifts between them	✗ いいえ	議論する
Feature flags are never cleaned up, so nobody knows which paths are live	→	…	✗ いいえ	議論する
Reliability has no budget line of its own	→	Config lives in five places and drifts between them	✗ いいえ	議論する
The incident channel fills with people asking for status instead of giving it	→	Retries are unbounded, so a slow dependency becomes a flood	✗ いいえ	表示中 ↑ · 閉じる ✕
Rollbacks take longer than the outage they are meant to end	→	The incident channel fills with people asking for status instead of giving it	✗ いいえ	議論する
The same three services cause most of the pages	→	Reliability has no budget line of its own	✗ いいえ	議論する
…	→	Feature flags are never cleaned up, so nobody knows which paths are live	✗ いいえ	議論する
Feature flags are never cleaned up, so nobody knows which paths are live	→	The service map in the wiki is two years old	✗ いいえ	議論する
Config lives in five places and drifts between them	→	Reliability has no budget line of its own	✗ いいえ	議論する
The staging environment does not resemble production	→	Feature flags are never cleaned up, so nobody knows which paths are live	✗ いいえ	議論する
Rollbacks take longer than the outage they are meant to end	→	Feature flags are never cleaned up, so nobody knows which paths are live	✗ いいえ	議論する
Retries are unbounded, so a slow dependency becomes a flood	→	Config lives in five places and drifts between them	✗ いいえ	議論する
The service map in the wiki is two years old	→	Reliability has no budget line of its own	✗ いいえ	議論する
The service map in the wiki is two years old	→	Config lives in five places and drifts between them	✗ いいえ	議論する
The staging environment does not resemble production	→	Config lives in five places and drifts between them	✗ いいえ	議論する
Rollbacks take longer than the outage they are meant to end	→	The service map in the wiki is two years old	✗ いいえ	議論する
The staging environment does not resemble production	→	The service map in the wiki is two years old	✗ いいえ	議論する
The staging environment does not resemble production	→	Retries are unbounded, so a slow dependency becomes a flood	✗ いいえ	議論する
…	→	The same three services cause most of the pages	✗ いいえ	議論する
Retries are unbounded, so a slow dependency becomes a flood	→	Feature flags are never cleaned up, so nobody knows which paths are live	✗ いいえ	議論する
…	→	The service map in the wiki is two years old	✗ いいえ	議論する
Config lives in five places and drifts between them	→	Retries are unbounded, so a slow dependency becomes a flood	✗ いいえ	議論する
The staging environment does not resemble production	→	…	✗ いいえ	議論する
Reliability has no budget line of its own	→	…	✗ いいえ	議論する
The same three services cause most of the pages	→	Config lives in five places and drifts between them	✗ いいえ	議論する
…	→	The incident channel fills with people asking for status instead of giving it	✗ いいえ	議論する
Feature flags are never cleaned up, so nobody knows which paths are live	→	The staging environment does not resemble production	✗ いいえ	議論する
Retries are unbounded, so a slow dependency becomes a flood	→	The incident channel fills with people asking for status instead of giving it	✗ いいえ	議論する
Config lives in five places and drifts between them	→	…	✗ いいえ	議論する
The staging environment does not resemble production	→	The same three services cause most of the pages	✗ いいえ	議論する
Reliability has no budget line of its own	→	Rollbacks take longer than the outage they are meant to end	✗ いいえ	議論する
Config lives in five places and drifts between them	→	The same three services cause most of the pages	✗ いいえ	議論する
The staging environment does not resemble production	→	The incident channel fills with people asking for status instead of giving it	✗ いいえ	議論する
Rollbacks take longer than the outage they are meant to end	→	The staging environment does not resemble production	✗ いいえ	議論する
…	→	Rollbacks take longer than the outage they are meant to end	✗ いいえ	議論する
Config lives in five places and drifts between them	→	The service map in the wiki is two years old	✗ いいえ	議論する
The same three services cause most of the pages	→	Retries are unbounded, so a slow dependency becomes a flood	✗ いいえ	議論する
Rollbacks take longer than the outage they are meant to end	→	Config lives in five places and drifts between them	✗ いいえ	議論する
Reliability has no budget line of its own	→	The service map in the wiki is two years old	✗ いいえ	議論する
Retries are unbounded, so a slow dependency becomes a flood	→	…	✗ いいえ	議論する
Feature flags are never cleaned up, so nobody knows which paths are live	→	Config lives in five places and drifts between them	✗ いいえ	議論する
Config lives in five places and drifts between them	→	The incident channel fills with people asking for status instead of giving it	✗ いいえ	議論する
Feature flags are never cleaned up, so nobody knows which paths are live	→	Retries are unbounded, so a slow dependency becomes a flood	✗ いいえ	議論する
The service map in the wiki is two years old	→	…	✗ いいえ	議論する
The incident channel fills with people asking for status instead of giving it	→	The same three services cause most of the pages	✗ いいえ	議論する
Rollbacks take longer than the outage they are meant to end	→	Retries are unbounded, so a slow dependency becomes a flood	✗ いいえ	議論する
Reliability has no budget line of its own	→	The same three services cause most of the pages	✗ いいえ	議論する
Retries are unbounded, so a slow dependency becomes a flood	→	Rollbacks take longer than the outage they are meant to end	✗ いいえ	議論する
The same three services cause most of the pages	→	Feature flags are never cleaned up, so nobody knows which paths are live	✗ いいえ	議論する
The service map in the wiki is two years old	→	The incident channel fills with people asking for status instead of giving it	✗ いいえ	議論する
The service map in the wiki is two years old	→	The same three services cause most of the pages	✗ いいえ	議論する
The incident channel fills with people asking for status instead of giving it	→	…	✗ いいえ	議論する
The staging environment does not resemble production	→	Reliability has no budget line of its own	✗ いいえ	議論する
The incident channel fills with people asking for status instead of giving it	→	The staging environment does not resemble production	✗ いいえ	議論する
The same three services cause most of the pages	→	Rollbacks take longer than the outage they are meant to end	✗ いいえ	議論する
…	→	Retries are unbounded, so a slow dependency becomes a flood	✗ いいえ	議論する
Retries are unbounded, so a slow dependency becomes a flood	→	Reliability has no budget line of its own	✗ いいえ	議論する