小服AI 
一次评审会上，有人问了一句：可靠性到底是谁的事？
后面跟着这三种回答：质量部、可靠性工程师、做分析的人。
这三个答案都不算错，但三个都没答到点上。
因为这个问法本身，就预设了一件事——可靠性可以像预算、像工时一样，被划给某个部门，但事实是这样的吗？
可靠性到底是谁的责任
最常见的回答是：质量部。
于是可靠性变成质量部的一项职能：出规范、盯试验、写报告。
那设计部门可以继续按性能指标做选择，采购继续按价格和交期做选择——因为这些选择带来的可靠性后果，已经被划给别人了。
所有真正影响可靠性的决定，却都不是在质量部在做的。
材料选型、降额余量、结构密封方式、软件异常处理策略，这些在设计评审上就定了。质量部能做的是事后测量，不是事前决定。
问「谁的责任」，最后得到的是一张分工表：谁负责的清清楚楚，负责人能做什么却依旧模糊。
可靠性是谁在管
最常见的答案是可靠性工程师，但事实真的是这样吗
可靠性工程师最常做的事是收数据、跑模型、解释结果。他手上没有设计的决定权，没有采购的否决权，也没有售后记录的决定权。
他能算出结论，却常常无法让结论改变任何一个决定。
于是出现一种熟悉的场面：报告做得很专业，会上大家点头，但方案照旧。
谁来做分析
谁做分析？谁出这份报告？
这个问法把可靠性等同于计算。
计算当然重要。但一次分析的价值，取决于它前面三段输入：失效怎么定义、在役时间怎么算、这些失效是不是同一个机理。
这三段，没有一段是计算环节能自己决定的。
口径定错了，后面算得再准也只是把一个错误的输入精确地放大。
所以很多报告的真实命运是：做完就归档。不是因为它算错了，而是因为它回答的问题不是决策者此刻要回答的问题。
不问「谁」，问「哪个节点由谁负责」
换一个问法，事情就清楚了：
不是「可靠性是谁的事」，而是「在哪个环节、由谁、拿什么数据、做什么判断」。
沿着产品的一生，只有三个节点必须有人签字。
卡点一
设计冻结之前——谁定假设
要定的不是参数，是三件事：
1 怎么算失效（判定准则，书面化）
2 时间坐标用什么（小时、公里、循环、启停次数）
3 使用条件按什么假设（工况、负载谱、环境）
失守的后果：后面所有数据都在一个没人承认的假设上运行。
卡点二
验证与试验之前——谁批口径
要批的也不是方法，是四件事：
1 样本量与时长够不够支撑结论
2 试验条件与实际使用条件怎么对应
3 通过与否的判据是什么
4 结论能外推到哪个范围，不能外推到哪个范围
失守的后果：试验通过了，上市后照样批量失效——因为验的不是同一个东西。
卡点三
上市之后——谁维护
这一环最容易被忽略，也最容易失真：
1 失效事件的记录标准是否与设计阶段一致
2 返修更换件怎么计（更换是否重置寿命，直接改变在役年龄结构）
3 在役暴露量谁来维护（生产日期、投产延迟、存量台数）
失守的后果：数据越积越多，判断越来越难，最后只能靠经验拍板。
一个可以立刻用的自查方法
下次评审，不问「谁来负责」，改问这三句：
设计冻结前
失效判定准则和时间坐标，是谁签的字？
试验开始前
这套结论能外推到哪、不能外推到哪，是谁批的？
上市之后
返修和在役暴露的口径，是谁在维护？
做好可靠性不用新设岗位
把可靠性落实，通常不需要新增部门，也不需要再多一个头衔。
需要的是把上面三个卡点写进已有的评审节点：
设计评审加一页「假设与判定准则」
试验评审加一栏「外推边界」
售后月度会加一行「暴露量与口径变更」
然后，要求签字。
签字的力量在于：它把「大家都觉得差不多」变成「我确认过这个前提」。一旦有人签了，后端数据出错时，讨论的就不再是「谁的责任」，而是「那个问题需要更正」。
最后
可靠性不属于任何部门。
它是每一个做决定的时刻——设计师在选材料的那一刻，试验工程师在定样本量的那一刻，售后在记录第一起故障的那一刻。
所以，「可靠性是谁的事」这个问题，是问不出可靠性的。问「这个节点该做什么判断、谁来签」，才有用。
