True Causes
ZH
← 大厅
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?

把你认为相似的卡片归为一类。分类只为方便阅读,不决定任何事。

已关闭 · 返回行动阶段
正以访客身份查看。输入用户名即可加入并参与。
先按相似性形成类别,最后再命名
标准顺序:把你认为相似的想法两两关联——关联是对称的(A~B 即 B~A;方向无关紧要),一条关联在 2 名成员做出后成立。
为什么
关联是对称的——A~B 即 B~A。类别是从成立的关联中自然形成的分组,只有已形成的类别才能被人命名。你自己的关联带有 ✕,可以撤回;你不能移除别人的。类别只用于整理墙,从不限制投票——两张提出相同主张的卡片属于澄清阶段的合并。
关联和命名只能在归类阶段进行;主持人的 ← 可以重新开启它。
关闭 ✕
The service map in the wiki is two years old
类别 6
还没有人发言。
未命名类别 ——如果这一类有共同主线就为它命名,否则保持未命名 (2)
Alerts fire so often that on-call mutes them
~ Customers report outa…Customers report outages before monitoring does (12)
讨论
Customers report outages before monitoring does
~ Alerts fire so often …Alerts fire so often that on-call mutes them (12)
讨论
未命名类别 ——如果这一类有共同主线就为它命名,否则保持未命名 (2)
The same three services cause most of the pages
~ The on-call rota has …The on-call rota has the same two people on it most weeks (20)
讨论
The on-call rota has the same two people on it most weeks
~ The same three servic…The same three services cause most of the pages (20)
讨论
未命名类别 ——如果这一类有共同主线就为它命名,否则保持未命名 (2)
Every team has its own logging format
~ Reliability has no bu…Reliability has no budget line of its own (15)
讨论
Reliability has no budget line of its own
~ Every team has its ow…Every team has its own logging format (15)
讨论
未命名类别 ——如果这一类有共同主线就为它命名,否则保持未命名 (2)
Runbooks are out of date within a month of being written
~ The service map in th…The service map in the wiki is two years old (16)
讨论中(1)
The service map in the wiki is two years old
~ Runbooks are out of d…Runbooks are out of date within a month of being written (16)
当前焦点 ↑ · 关闭 ✕
未命名类别 ——如果这一类有共同主线就为它命名,否则保持未命名 (2)
Post-mortem actions are written up and then never scheduled
~ Post-mortems assign a…Post-mortems assign actions to people who were not in the room (9)
~ Feature flags are nev…Feature flags are never cleaned up, so nobody knows which paths are live (14)
讨论
Feature flags are never cleaned up, so nobody knows which paths are live
~ Post-mortem actions a…Post-mortem actions are written up and then never scheduled (14)
讨论
未命名类别 ——如果这一类有共同主线就为它命名,否则保持未命名 (2)
Config lives in five places and drifts between them
~ Migrations are run by…Migrations are run by hand from a laptop (21)
讨论
Migrations are run by hand from a laptop
~ Config lives in five …Config lives in five places and drifts between them (21)
讨论
· 尚未归类 (18)
Tests that fail intermittently are retried until green
Leadership asks for a root cause within the hour, so the first plausible one wins
Success is measured in features shipped per quarter
Dependencies are upgraded only when something breaks
Deploys go out on Friday afternoons because that is when the sprint ends
Rollbacks take longer than the outage they are meant to end
Post-mortems assign actions to people who were not in the room
~ Post-mortem actions a…Post-mortem actions are written up and then never scheduled (9)
讨论
Feature work always outranks reliability work in planning
There is no time set aside after an incident, so the write-up is done at midnight
Incidents are declared late because declaring one feels like blame
Load tests were last run before the customer base doubled
One engineer knows how the payment path actually works
Error budgets exist on a slide and nowhere else
The staging environment does not resemble production
The incident channel fills with people asking for status instead of giving it
Nobody owns the shared database schema
Retries are unbounded, so a slow dependency becomes a flood
Capacity is added after the outage, never before