背景

在《程序媛的人生观》这篇文章中，一些朋友提出了自己的疑问：“看起来静儿的发版上线很不规范，为什么一个大公司会允许这样的事情呢？”这是个很好的问题，值得我好好总结分享一下。

在考虑上线标准之前，先考虑这么一个问题，你处于哪个通道？

通道

前端通道、系统通道和后台通道的发版上线流程差别会很大。

前端通道：用户体验、视觉效果会占很大比重，一般来说需要依赖专业人员进行人工测试。

系统通道：产品流程的理解和把控是其中的一个关键点。自动化测试基础上还需要人工测试进一步验证。

后台通道：也是静儿所在的通道。业界有一个比较流行的理念：“开发人员应该测试自己的代码。”

我们团队中经常在说的一句话叫：“你不可能既当运动员又当裁判。”那怎么来解决这个冲突呢？

自动化测试。基础架构这边有专门的QA。他们大部分时间都在收集测试用例，开发自动化测试工具。

开发人员需要自己写单体测试，单体测试是在设计阶段，对功能进行建模阶段就写好的。所以对一个后台开发来说，完全可以在几分钟之内完成一套完整的上线前验收。

能否在几分钟之内就可以进行一套完整的上线前验收也和公司、部门或者团队的策略有关系。

策略

不知道有的朋友有没有注意到这个问题：有的公司虽然是大公司，但是门槛并不高。面试的时候着重考察面试者的理解力、沟通能力。如果背景不错，不会太卡技术这一块。当然，一般来讲这种公司给的待遇也比较一般。

这并不是说这个公司不够好，相反，正是因为公司有非常完善的流程把控，所以才摆脱了对成员个人能力的重度依赖。然而，一般来讲，流程是用来保证底线的。一个注重成员成长的团队希望的是能够激发成员的上限。

所以静儿所在的团队有这么一种策略：如果成员对自己的流程把握足够好，不出问题，上级会逐渐放宽对成员的监督。如果把控的不好，就会天天被盯流程。

这样的好处：做的好的成员的创造性可以充分得到发挥。对于上级自身，也可以抽身出来cover更大的事情。

在《程序媛的人生观》这篇文章中，静儿用了一个很不专业的词：「临时决定」。从另一个角度来看这个问题，什么事情是可以临时决定的？

定性

静儿之所以可以临时决定给序列化和反序列化接口新添加一个实现。这里面包含了两点信息：

1.这是添加实现，最最坏的情况下，实现出问题了，是可以开关切换切换回原来的实现的。

2.这不改变完成的功能，就是说这是一个重构。

在开发的时候「忍不住觉得之前的代码写的太烂了需要重构」是一个工程师的基本素养。如果回过头看觉得原来的代码写的不错，这是一个信号：同学，你该看书学习了。

所以，对于新功能，静儿团队中是需要开会一起做DEMO验收演示的。但是对于重构，开发人员完全有权利自己决定何时重构。因为功能不变，之前已有的自动化测试流程无需任何更改，完全可以覆盖重构后的场景。

背后的技术支撑

「技术强就是任性。」这句话不错的，但是技术强不是指静儿个人的技术能力。而是我司的整套基础设施。这里就不谈我们强大的DevOps这些东西。我们就说《程序媛的人生观》这篇文章中，静儿提到终于用了整个晚上，到凌晨5点完成上线，静儿最后把线上到哪里了呢？

上到了线下环境。这里线下环境是什么概念呢。静儿所在的团队负责的是容器的生命周期管理。容器有给广大用户直接访问的线上环境。还有一个环境，业务部门是我们的用户，他们用来测试、开发的容器，对我们来说是正式环境。如果线下环境出了问题，会影响我们的用户满意度。

一般来说，我们的代码想上到线上环境，至少要经常两天的线下环境观察。这个观察是什么意思呢？

发版前写好发版checklist，在一定范围内周知说我要发版了，如果有问题请及时联系我。

然后采用灰度发布，每发版一组机器就要进行整个流程的检验，如果有问题最快的解决方法是将有问题的机器禁用。每组发版之间有强制的时间间隔，在间隔内不能发版下一组。

发布完成后QA那边的自动化工具又一次起了作用，它会自动模拟用户完成所有分支的操作。然后给出报告。

各方面都OK之后，周知说发版完成符合预期。第二天一大早起来业务巡查，看看是否一切正常。

一天的午高峰和晚高峰监控数据是一定要看的。CAT、OCTO、业务大盘、监控大盘……

最重要的是及时看看是否有业务反馈问题。这都是在线下环境做的。

《程序媛的人生观》这篇文章中提到的那次发版，由于质量好。上周四发版线下，上到线上环境是这周一晚上9点后开始操作。

从「技术好就是任性」这个再延伸一下，为什么《程序媛的人生观》这篇文章中看起来编码很随意？这是因为设计架构做的好。临时决定给序列化和反序列化接口新添加一个实现。实现加在哪里了呢？每个产品至少有两个服务组成：核心服务和非核心服务。我们的MQ都是用来数据预处理用的，都是在非核心链路上。出问题了，半夜临时挂一下，就算有和静儿一样的程序员在半夜扩容测试机器。服务产生的最坏影响是数据反应有延迟