面对Product上的Live Issue

通常我们做产品无法做到完美才发布，特别是互联网行业。无论你是做移动端还是PC端，或者是网页端，特别是网页端，迭代式特别快的。很多时候，我们都无法完成所有测试的情况下，可能产品就已经上线。不要问为什么，如果你是老总，你就会明白互联网行业的残酷性，上线时间如果只差一天，你就是已经处于劣势了。

但是面对这样的产品，我们无法保证产品不会出现Live Issue，何为Live Issue，就是线上产品出现的问题，当然不同公司的叫法不一样。正常情况下，互联网公司都会有对应的监控服务。一旦出现Live Issue，那么就会有Live Issue Call打到对应的值班人员的手机上，然后值班人员去查看问题，并解决问题或者找人解决问题。

当然，如果你第一次值班肯定会紧张，不知道该如何处理，即使公司会对你有一定的培训，但是仍然无法使你平静。正常的Live Issue会被老大们很看重的，因为会直接影响到用户的使用，损失也是各种各样。

不过做过几次实践之后，你就会熟悉流程也就慢慢的能够上手，最重要的还是总结经验，如果去处理这些事情。

举一个简单的例子，比如你公司的业务逻辑分为三层：数据层，业务逻辑层，展示层。业务逻辑层属于中间层，负责从数据层提取数据，并为展示层提供数据接口。当然一个Live Issue可能会出现在这三个层次的任何一层，但是通常情况下，三个层次上线的时间间隔是不固定的。一个正规的大公司，通常会有严格的Schedule去发布这三个层次。比如：数据层可能在2个小时内可以上线，而业务逻辑层可能需要2天（一天测试，一天上线，提交->测试->上线），而展示层通常也可以在2天上线。

所以一旦出现问题，那么你第一个想到的就是要找到原因出在哪里，如果是在数据层，那改好了就行了；如果是在业务逻辑层或者展示层，那就需要2天的时间才能上线，你的老板肯定不会同意的。所以这种情况下，我们该如何处理？

1. 首先找到问题出现在哪一层
2. 找到具体的问题
3. 确定能够尽快解决问题的方法

• 从最短上线的部分入手，看能够解决问题，在本例中，你可以看是否可以从数据层解决问题。
• 如果最短上线部分无法解决问题，看是否能有配置文件可以快速的禁掉对应的服务，或者修正问题。
• 尝试Revert原有的改动，一个正规的公司都会有对应代码和数据版本管理工具的。
• 最后和你的Boss谈，等待最终的Change上线。

可以参考一下一折购（http://www.ezhegou.cn），这里实现的就是只改变数据层的方法实现业务的不断变化，其实数据层，业务逻辑层和展现层都是固定的模板，以不变应万变。