我的高质量软件发布心得

译者按: 好好写代码，充分做测试，和小伙伴沟通清楚，灰度发布，上线后要有监控和一键启停。

原文: A framework for shipping high quality software)
译者: Fundebug

为了保证可读性，本文采用意译而非直译，并且对源代码进行了大量修改。另外，本文版权归原作者所有，翻译仅用于学习。

无论是软件攻城狮还是技术主管都为了一个共同的目标：准时发布高质量的产品。但是各种雄心勃勃的需求，严格的截止日期和之前没有理清楚的技术债总会打乱开发团队原本规划好的任务优先级。不过，软件质量很重要，否则无数的bug将会让开发团队忙得一团糟，是的原本就很紧张的开发日程变得更加紧张。

这篇博客提出了一个用于稳定发布高质量软件的模式。

来源

这个框架式是我在开发一个超级具有挑战的项目中所积累下来的。我的目标是让一个网站应用可以全球访问，要满足可扩展性和可信性。这样一个简单的目标却花了我们好几个月的时间，并要完成一下任务：

从单一服务器扩展到服务器集群
横跨所有微服务，对平台级的基础性服务做改动
一直保持和不同的团队协作来获得更多的见解

所有的服务部署都要无缝衔接，否则服务将会宕机。

拉姆斯菲尔德(Donald Rumsfeld)会怎么做？

姆斯菲尔德是谁？

Donald Rumsfeld为德裔美国人，1954年毕业于普林斯顿大学，同年开始在美国海军服役，1962年当选为伊利诺州的共和党联邦众议员，此后4次当选连任。1969年辞去联邦众议员职务，加入理查·尼克松总统内阁，成为白宫经济机会办公室的主任和总统助理。1973年出任美国驻北约大使，1974年被拉尔德·福特总统任命为白宫办公厅主任。1975年被任命为国防部长，成为美国历史上最年轻的国防部长。2001年再度出任美国国防部长，由此成为史上最年长的国防部长。

前国防部长拉姆斯菲尔德在83岁时曾这样说到：”人生足迹遍布商场、战场和政界的我，决定尝试开发一款移动游戏应用。“

他不是一个专业的软件开发者，不过他下面这段话却十分中肯：

There are known knowns. These are things we know that we know. There are known unknowns. That is to say, there are things that we know we don’t know. But there are also unknown unknowns. There are things we don’t know we don’t know.

这是哲学里面Johari window的一个简化版本。我们将它应用到软件开发，如下表：

标题	开发者知道的	开发者不知道的
其他开发者知道的	大家都知道	不知道大家知道
其他开发者不知道	知道大家不知道	所有人都不知道

大家都知道

需求特性、已经发现的bugs、用户的需求等等，这些都是我们都知道的。但是，一个用代码实现的特性并不一定按照预想的行为来。比如，没有测试的代码可以归类到”知道大家不知道“，直到你十分清楚代码的工作原理，并把文档写清楚。

你认为代码会按照你写的行为执行是一回事，如何证明的确是这样是另一回事。单元测试，功能测试，甚至手动的单步调试来增加你知道的部分，减少不知道的部分。

知道大家不知道/不知道大家知道

我将这两条合并到一起，因为它们是相关的。

知道大家不知道

这部分是指开发者自己很清楚，但是一起工作的其他开发者不知道。一个好的例子就是：创建了一个新的API代替了原来的旧的的功能，但是另一个开发者还一直在用旧的API；另一个例子是：将某些共有的代码的行为修改了。
不知道大家知道

这部分是指开发者不知道团队里面其他开发者知道。举个例子：一个对核心部件看似很小的更新，可能会连锁式的触发其它队友们重写很多代码。或则只有几个攻城狮才知道的奇怪的特性之类的。

清晰的沟通很重要！甚至可以过度沟通也没关系！勤发邮件，经常检查设计，保持和用户沟通。如果要做一些大的设计变动，作为一个开发者/团队领导/管理人员，你需要花充分的时间和用户沟通，充分理解他们的使用场景。通过用户访谈，可以优化设计，也可以提前防止未来可能出现的问题。

所有人都不知道

这是最具有挑战的部分。目前还没有一个模型可以为哪些不可预测的事件做准备 -- 比较它从未发生过。那些不知道包括：黑客攻击，数据丢失，盗窃，蓄意破坏，软件bug等等。不要为此苦恼，我们可以用两个指标来量化：1. 平均修复时间(mean time to repair)；2. 平均检测时间(mean time to detect)。

最好的办法就是保证这两个时间尽量小。可以想象一下修复数据破坏耗费5分钟和一个小时对业务的影响。

平均检测时间

一个监控系统是很有必要的，那些基本的指标(内存、CPU、硬盘读写率等)，HTTP请求状态(500、400等)和其它。最好的情况是：一个有问题的发布立马触发报警发送给管理员。这样保证及时对问题作出反应，并迅速恢复。（线上bug可以用我们fundebug实时监控喔）

平均修复时间

在系统里面对某些属性配置一个开关，如果该属性在某次发行导致严重问题，可以立即将其关闭来防止造成严重损害。

另外，你需要有一个敏捷发布系统。如果你花两天时间才能成功把修复发布出去，那么你的平均修复时间则是2天+。你需要优化整个发布流程。

还有什么要说的？

在攻城狮发布一个核心更新之前，一定要问自己这几个问题：

是否有充分的日志监控系统来方便debug？
对于那些有风险的特性，是否有配置一个线上开关？如果遇到状况，需要花多久时间才能关闭？
一个特性发布后，如果出了状况，是否有足够的指标来辅助分析？

在此推荐一个发布方法：灰度发布。

版权声明:
转载时请注明作者Fundebug以及本文地址：
https://blog.fundebug.com/2017/09/27/a-framework-for-shipping-high-quality-software/