问题
Why does the same outage keep recurring?
一方是否显著影响另一方？达到所投票数的四分之三即为定论。
已关闭 · 返回行动阶段
正以访客身份查看。输入用户名即可加入并参与。
问题在各小组之间分配，所以你拿到的是分给你们小组的那些——不是全部 180 个。
已定 176 / 180 0 个待你回答 为什么
没有人能回答几百个卡片对。每个卡片对交给一个小组；意见分裂的卡片对会再转给其他小组，所以它可能稍后出现在你的列表中，即使它起初在别处。已定数量包括所有小组的工作，所以它增长得比你自己的列表缩短得快。
上次计票：176 个已定 · 1 个上交跨组评审组 · 0 个有争议 · 3 个未达法定人数 — 每个评审组至少需要 max(2, 评审组人数的 75%) 张票；你们最小的评审组有 15 名成员.
One engineer knows how the payment path actually works → 有影响？ → Customers report outages before monitoring does
还没有人发言。
已完成的阶段——卡片对和投票的记录见上方。检查逻辑 ↗
| 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 | ✗ 否 | 讨论 |