辛苦了一晚上，系统终于上线了。尽管在计划的时候为发布预留了时间，但实际上我们依然处于紧张的进程中，可能唯一值得庆幸的是，不需要凌晨3点才能回家。

        每次的发布都注定不会平坦，鲜有一举成功的案例。昨晚的发布我心存侥幸，回想之前详尽的测试和试用，这次应该不会再有什么问题了吧。

        11点，把所有系统发布上线，貌似平静。正当大家松一口的时候，突然发现内测的app状态不正确。我拿到手里，3s钟就定位问题所在，修改了一个配置，以为大功告成，没想到却早上正式版都提示升级，但确认后却没有任何动作，我马上意识到问题所在，赶紧把配置修改回来。紧张的检查代码，肯定了自己的猜测，紧急开始修复起来。庆幸的是出问题的是内测版本，只在小范围传播。修复完发布，貌似一切正常，回家！

        到家后，一测试同事说发现线上ios版app总是crash，可这句话并没有引起疲惫的大家重视，以为只是偶然。

        早上9点半，我还在暖和的床上被电话叫起来，pd紧张的语气让我意识到问题严重了！ios crash的情况越来越频繁！

         我赶紧打开电脑，群里面大家已经吵翻了天。app开发的同事可能已经亚历山大了吧，而我丝毫没觉得这个问题跟我有关。

        一会儿，app的同事定位到问题，是服务端的一个接口返回的数据缺少一个文案字段，我才猛然想起昨晚最后发布的时候，我”顺手“把一个快要废弃的接口中一句文案删除了，而不够强健的app脆弱的倒在了一个空字段的获取上。

        bug的修复很容易也很快，但这次已经影响到了部分线上的用户。可以说app不够健壮，但事故直接原因却是我导致的。

        现在仍心有余悸，反思自己的做法，千万不能心存侥幸，一个小小的修改，却因牵一发而动全身导致整个系统的停滞。

        规范性不够，这是我现在一个比较大的问题。从传统的软件公司转型到大型的互联网公司，差别还是很大，需要学习的东西实在太多太多。

互联网公司的如履薄冰--从不一帆风顺的发布