写这篇文章的动机来源于知识星球一位同学的反馈。
他说线上系统出现了资损，原因是有一个MySQL查询语句用了limit分页但是没用order by，数据重复了。
按理来说像这种低级的错误不应该犯的，但在真实工作场景中，这种低级错误总是会时不时的出现。
由此我在思考一个问题：为什么当一群有经验的人一起协作共事时，依然会犯一些很常见的错误？
最后我得出了这样一个结论：当每个人都为一件事负有责任时，则每个人都不用这件事的结果负责。不用对结果负责，自然而然容易造成工作过程中的敷衍和应付，最后必定会出问题。
对于上述问题，我也给了这位同学一个建议：将每次发布变更的影响范围，涉及到的配置、参数以及sql语句等，都罗列出来整理成 CheckList。
在发布前评审，并且加入签名审核机制，审核通过的事项如果出现问题，则由审核签名的人负直接责任。
CheckList机制作为一种风险评估机制和质量控制策略，由来已久，但很多时候在具体执行中，往往变为形式主义。由上面的问题进而可以衍生出很多其他问题，比如：
1、上线后若出现问题，如何排查确认哪部分问题？
上线后发布出现问题，则是线上应急响应和业务止损要解决的问题。排查确认和改进，是复盘归因和落地推进要解决的问题。
世界上从来没有一道机制就可以解决所有问题，人生也好工作也罢，绝大多数时候，都是吃一堑长一智，不断打补丁积累经验，降低犯错成本和概率的过程。
2、签名确认并不能完全避免问题，如何解决这个问题？
没有完美的软件产品，人也无法保证自己不犯错误，因此无论在工业界还是软件研发交付领域，都很注重流程规范。
流程规范的最大作用，不是让产品不出问题，而是降低犯错的几率以及出了问题可以有更好搞快的解决方式。
比如需求评审，一般都要求产品、开发、测试都参与其中，只有对需求有较为深入的理解且理解保持一致，才能降低后续开发和测试过程中的修复成本。
再比如架构设计和技术实现方案评审，按理来说测试也应该参与其中，但很多时候测试由于技术问题就很难深度参与并提出合理有效的建议，久而久之技术方案评审变成了研发内部的自留地。
即使在研发团队内部，技术方案评审有时候也沦为了形式主义，可有可无。
3、是否要制定严格的研发测试交付规范和评审签名机制？
如果你所在团队和企业对质量有较高的要求，那制定并严格执行流程规范还是很有必要的。
质量本质上是一个成本和收益的平衡结果，关于质量保障的方法论和优秀的落地实践案例其实很多，能落地能拿到好结果的反而并不多。
但无论如何，严格的研发测试交付规范和评审签名机制的必要性在于：责任到人，减少人浮于事的形式主义以及责任均摊的大锅饭现象。
为什么近几年很多互联网公司都在治理各种会议乱象？背后的原因在于一群人在会议室讨论半天，最后没有明确的结论和行动步骤。都参与其中，其实谁都没深度参与；因为都对其负责，最后都没人负责。
如果责任到人，反而从产品到研发再到测试，都在想办法改善流程，优化技术，提高交付质量，减少线上问题的出现。
最后回到本文的标题，为什么要制定流程规范？因为从管理者的角度来说，不能完全相信员工的自驱力。虽然可能员工都是很优秀的人，但每个人的工作习惯，行为喜好方式，对需求的理解，对目标的认同都不一致。
而流程规范的价值就在于通过一个较为标准的方式约束大家天马行空的各种想象和行动，保持对目标的一致理解，辅助大部队不会偏离目标。
而评审签名机制的价值在于，分工明确，责任到人，没有模糊地带，自然就能减少摸鱼和稀泥的的现象发生，线上业务的稳定性自然而然就会提升上来。
标签：流程,规范,评审,问题,签名,测试,制定 From： https://www.cnblogs.com/imyalost/p/18234918