谈谈如何管控项目上线过程中的风险

最近公司各个产品线上线不很多项目版本，出了不少事故。想起原来在刚毕业的前几年拍脑袋切换的一个项目是血淋淋的教训，当时连续几个月中被采购、品管、财务和供应商追杀，电话被打爆，通宵开会讨论解决方案，鸡飞狗跳的场景都历历在目。幸好有那次的教训，在后续产品/版本上线会格外注意上线风险管控，也总结了一些经验，刚好借这个机会总结分享下自己对管控项目上线过程中风险的心得

在对风险评估前务必要保持敬畏的心态，敬畏用户、敬畏风险、敬畏对公司/客户产生的影响，很多同事经常问我的一个问题：“对自己做的项目版本要有信心啊！”如果你从内心里盲目的自信并且又不做任何防控措施，那基本上可以猜到上线后的结果了。有句老话叫“战略上藐视敌人，战术上重视敌人”，版本切换上线也是一样，战略我们需要保持高度的自信，战术上需要敬畏所有的用户和风险，端正心态正式风险后才能管理控制风险，特别是缺乏重大项目经验的同学务必要重视，如果切换前不重视，相信出现问题后一定会让自己终身难忘，即使再自信也需要做好假想情况下的风险风控机制。另外一个就是保持谨慎，小心驶得万年船（好像用这个描述有点不太合适~~），墨菲定律说明，如果你担心某种情况发生，那么它就更有可能发生。

这里回到正题，下面总结了下日常项目中常见的风险和应对方案，参考下图

第一类是流程性风险：这类风险也是大家最常见的也是风险性最大的一部分，日常生活中常见的包括APP下不了订单或者支付不了，甚至支付后订单还是待支付的，商家上架不了商品，或者公司管理系统没办法制单流转的都算这类风险，针对这类风险可以用下面几种策略来应对

• 制定回滚方案，这是最彻底也是最可靠的应对策略，制定回滚策略时需要考虑下回滚依赖条件，在有些特殊场景下可能无法回滚，比如对上下游、外部强依赖的时候，比如APP一旦发布到应用市场是无法回滚的；

• 设置切换开关，这是保证项目版本平稳切换非常好用的利器，可以非常快速灵活甚至对用户无感的的切回，能有效应对切换风险，可以当做是混滚的一个升级方案

• 邀请公司部门/员工/用户内测体验，一方面能检验出产品流程或者体验问题，另外也能增强公司内部或者与用户的沟通，促进产品影响力和宣传的效果，越是大型的产品或者项目切换越有必要，只有好处，没坏处（坏处可能仅仅是需要多点时间）

• 制定灰度策略机制，这个在C端产品方面运用的特别多，先小范围试点，试点无误后再逐步覆盖，能有效的避免大规模系统事故的产生

• 分步/分批上线切换，当项目涉及流程或领域较长，且某些领域依赖关系不大的时候，可以采取分步/分批切换上线，分散风险，各个击破，避免密集发布切换造成的问题

• 人肉操作，最原始最粗暴，可能是最有效的办法，预备这种方案前需要确保控制在一定数量级范围以内，否则砸成肉饼也无济于事

第二类是体验风险，比如用户习惯、文化道德、交互设计、理解认知差异造成的风险，比如16年支付鸨时间是一个非常典型的事件，在中后台估计更是案例也不少，这类最好的风险控制措施是上面提到的 “邀请公司部门/员工/用户内测体验”，能非常有效收集到涉众的反馈，还能加强相互之间的沟通，促进产品影响力和宣传的效果，不管是C端产品还是中后台产品都非常适用。当然如果是C 端产品采取灰度策略机制也是个不错的选择

第三类是数据风险，包括切换前后数据差异导致的风险以及数据准确性风险

• 切换前后数据差异导致的风险是可以很充分的预测以及准备应对的，比如说切换前后数据差异导致单据无法扭转进行下去的，这种性质的风险可以通过制定详细的策略来应对，比如取消未完成的单据，如果无法取消的，可以做初始化数据迁移。

• 针对数据准确性风险风险，可以采用并轨运行的机制来监测检验新产品数据质量，降低准确性风险，如果已经切换后上线的，这里可以指定相应的报警监控机制来进行保证，做到事中控制，事后处理

第四类是时间风险，或者叫过程控制风险，一方面指是项目进度的时间性风险，另外一方面是预留给预料外突发情况应对的时间风险

• 关于项目进度的时间性风险，最好最有效的策略是做好过程跟踪和控制，如果有时间延误或者超出预期时间的的要及时通报风险，也没有其他更好的办法

• 更重要的是预留给预料外突发情况应对的时间风险，在做各类计划时务必预留好充分的时间，同时针对未知情况可以想办法进行模拟或者演练，特别是针对不熟悉或者依赖外部不确定环境的情况下，尽可能减少预料外的突发事件。

第五类是资金风险，资金风险也算是数据准确性风险的一种，不过非常重要又比较特别的一种（直接的现金损失），所以需要针对性应对，包括会造成用户多付少付或者公司资金损失的风险，特别是涉及用户支付、积分券、金额计算、付款、理财过程中的资金风险，一旦发生可能就是大金额的损失。针对资金风险，除了上面应对数据风险策略外，可以建立多维度的强校验机制，比如每个维度的错误率是0.1%，三种维度同时错误的概率就是 0.001%，只要有一个维度有问题即及时中止交易，不过这种方案需要耗费的成本比较大，其实我也一直好奇支付公司或者银行是怎么来控制资金风险的，也欢迎相关了解的同学也可以来探讨下

第六类是沟通协作风险，这类风险也是大家经常遇到的风险之一，怎么沟通怎么协作就不说了，我们重点说下如果是比较大型或者牵扯到领域部门比较多一定要实行定期例会制度来review各个领域的进展和依赖关系，例会的主要目的在于统一大家的思想和行动，互通有无，保持一致节奏。像之前我司切换供应商登录平台事件是个深刻的教训，涉及领域到，没有一个核心牵头人统领全局，大家信息、步调都不一致，最终导致切换了三次才切换上去。

最后给大家看下安全工程学上的“海恩法则”，也同样适用于软件工程，每一起严重事故后面是1000次事故隐患，所以不要抱有侥幸心理，认为某次事故的偶然性。