程序员架构修炼：架构的保障，质量与风险 内建质量体系
架构的保障：质量与风险
内建质量体系
成本理论告诉我们，设计和开发是成本控制的源头，一般而言，成本随着项目的推进，在不同的阶段会呈现几何级的增长。实践证明，如果在前期设计时没有考虑周全，则用户往往抱怨不断，甚至导致项目返工。所以如何实现前期预防，对项目的成功至关重要，我们将 这 种 前 期 预 防 的 质 量 管 理 模 式 称 为 “ 内 建 质 量 （ Built-inQuality）”。
内建质量是所有质量思维中最难实现的，也是质量挑战的终极目标。举个例子，一个简单的排线连接器是有正反两面的，如果将其正反面装反，则需要到电流测试时才能发现该问题，但如果将接头做成不对称的形状，在装反时让插头插不进去，就可以预防该问题的发生。这种防呆装置在组装设计上使用普遍，其实就属于内建质量的范畴。
每个公司都希望以最快的速度可持续地交付新功能，并应对瞬息万变的商业环境，这些都有赖于解决方案的质量。内建质量则有助于减少需求召回、返工及缺陷修复相关的延迟成本，非常适用于大规模系统，并且是强制性实施的。
内建质量强调“三不原则”：不接受不良品，不设计或制造不良品，不流出不良品，如图6.1所示。其特定范围可大可小，小到一个人，大到一个工厂。在流水线生产模式下，要想做到每个工位的内建质量是非常困难的，所以其下游布置了许多检测来找出这些不良品。
从整个工厂来看，如果这些不良品都能被拦下来，不流到客户端，则也算是工厂整体做到了内建质量。虽然搭建一套真正持续有效的内建质量体系是极其困难的，但即便是一个很难企及的目标，我们也不该放弃。
图6.1
内建质量思维就是激发全员追求完美的工匠精神，唯有所有环节的人（包括企业家、领导）都能找回这种带有某种偏执狂的执着、认真、负责、追求完美的精神，才能将内建质量思维落实到业务当中，将其转化为企业的核心价值观。内建质量思维只有体现在产品和服务上，能让客户感受到，才能成为竞争对手极难模仿和跨越的核心竞争力。
“早发现、早解决”的难点在于发现而不是解决，质量管理的基本思路是上游管控，但要建立有效的“早发现、早解决”机制并不那么容易。就拿生产来说，对来料的抽检不能保证100%上线的料没有不良品；生产线上的工人也不可能不出错；机器用久了更不会没有瑕疵；测试仪器也有校准或量测不到位的时候；品检也有眼花误判的时候，等等，这些都会导致不良品的流出。要想杜绝不良品的流出，就得从头到尾设置许多风险预警、识别装置等。
“早发现、早解决”体现在能够在表面正常的情况下嗅到发生危机的风险，从而及早采取防范或应变措施，大大降低发生损害的程度。所以，从事质量工作的人除了要能解决问题，还要能识别发生质量风险的征兆。
虽然质量改进永远不能停止，但是追求持续改进不能操之过急，应从小处着手，慢慢扩展。PDCA循环正是推动持续改进的重要方法之一，如图6.2所示。
图6.2
PDCA代表了持续改进的如下4个主要步骤。
（1）P（Plan）：指仔细分析现状，并将现状与目标进行对比，看看缺口在哪里，然后详细规划改善的步骤。可以分几个步骤：一是将问题和目标定义清楚；二是利用各种工具，例如作业流程图、鱼骨图等，将问题相关的流程和因素梳理出来，定下优先顺序；三是进一步拆解流程，仔细分析各个步骤，看看问题可能出在哪里。
（2）D（Do）：指根据计划动手改进。需要事先想好退出计划，在动手时应从小处切入，谨防破坏现有流程，造成系统瘫痪。如果解决方案不止一个，就应该设计一个实验，评估各方案的优劣。
（3）C（Check）：指监控改进过程。需要确认测量工具和方法维持不变，否则可能误判。在结果数据出来后，需要仔细分析，看看哪种方案比较有效，而且对原来流程的变更幅度最小。
（4）A（Act）：指确认改善的确有效，在不良和缺陷已经消除后，导入及固化流程，改写规范。若改善无效，则检讨原因、修改计划，重新启动一轮PDCA循环。
PDCA循环是爬楼梯上升式的循环，每转动一周，质量就提高一步。在一轮循环结束后，也许只解决了一部分问题，或者在解决的过程中又衍生出新的问题，因此必须再进行一轮PDCA循环。如此循环迭代，不断提高软件的质量。
对于整个软件开发生命周期而言，软件质量贯穿于各个环节当中，从需求分析开始，一直到发布上线，PDCA循环则是项目迭代顺利完成的重要保障，如图6.3所示。
图6.3
从黑天鹅事件到墨菲定律
软件系统的稳定性，主要取决于整体的系统架构设计，然而也不可忽略编程的细节，所谓“千里之堤，毁于蚁穴”，一旦考虑不周，看似无关紧要的代码片段便可能导致软件系统的整体崩溃。
本节主要介绍几个重要的理论，分别是黑天鹅事件、蝴蝶效应和墨菲定律。这些理论在软件开发领域尤其是质量方面都至关重要。在了解这几个理论后，我们会发现，保证软件系统的质量其实并不容易。
黑天鹅事件
黑天鹅寓意不可预测的重大稀有事件，它在意料之外，却又改变着一切。人类总是过度相信经验，殊不知其实一只“黑天鹅”的出现就足以颠覆一切。所以，黑天鹅事件一般指难以预测且不寻常的通常会引起市场连锁负面反应甚至颠覆的事件。泰坦尼克号沉没、9·11事件、美国的次贷危机、2008年中国的雪灾，都是比较典型的黑天鹅事件。
黑天鹅事件通常具备如下三个特点：
（1）稀缺、史无前例（Rarity）；（2）影响很极端（Extreme Impact）；
（3）具有意外性，但人的本性促使我们在事后为它的发生编造理由，并且或多或少认为它是可解释和可预测的。
“黑天鹅”存在于各个领域，无论是金融市场、商业、经济还是个人生活，都有它的踪迹。最近几年发生的几个IT领域相关的黑天鹅事件如下。
◎ 2015年5月27日下午5点左右，某支付平台出现网络故障，导致账号无法登录，无法完成线上支付。后经证实，该故障是由于杭州市萧山区某地光纤被挖断导致的，这一事件造成部分用户无法使用该支付平台，其影响辐射到全国范围内的各个领域。
◎ 2016年3月15日，Google DeepMind公司开发的围棋人工智能程序AlphaGO和韩国著名的围棋专业选手李世石进行了对决。最终双方总比分为4：1，AlphaGo取得了人机围棋对决的胜利。2017年5月23日，AlphaGo再次与人类围棋高手柯洁展开对决，最终柯洁中盘投子认输。
赛后柯洁表示：“它太完美，我看不到希望。”
◎ 2017年5月，一种名“WannaCry”的蠕虫式勒索病毒利用NSA（National Security Agency，美国国家安全局）泄露的危险漏洞EternalBlue（永恒之蓝）进行传播，全球150多个国家和地区超过30万台电脑遭到了勒索病毒攻击，影响到金融、能源、医疗、教育等众多行业，损失高达80亿美元。
◎ 2018年6月10日，韩国交易所Coinrail宣布其系统检测到黑客攻击，NPXS已经受损，被盗虚拟货币的价值达到400亿韩元（约人民币2.4亿元）。CoinMarketCap的数据显示，从交易量来看，Coinrail刚排进全球前100名，但是其被黑客攻击所导致的影响是非常巨大的。
在Coinrail遭受攻击后的24小时内，市值前100的加密货币有99种价格下跌，总市值缩水约316亿美元，首当其冲的比特币跌破7000美元，比特币的价格在三个交易日下跌了近12%，引发了价值460亿美元的抛售，并将自2018以来比特币的跌幅扩大至50%以上。近三年来，在IT领域比较大的4起黑天鹅事件中，有3起是因为软件系统的可用性、安全性等受到挑战导致的，后果相当严重。
英国著名哲学家弗朗西斯·培根就曾发出这样的警告：我们要当心被自己思想的丝线束缚。无论是泰坦尼克的沉没，还是中兴被制裁，如果业界没有类似的案例，那么几乎无从借鉴。即使有业界案例，不同的组织、公司未必有相应的处理经验，所以自己的思想、经验也是非常有局限性的。有时我们太看重自己知道的事，却没发现我们不知道的事比我们知道的事更有意义，所以只有反常地思考一切，才有可能发现更多的“我们不知道的事”。
蝴蝶效应
20世纪70年代，美国气象学家洛伦兹在解释空气系统理论时说：“亚马孙雨林中的一只蝴蝶偶尔振动翅膀，也许会引起两周后美国得克萨斯州的一场龙卷风。”
这就是著名的蝴蝶效应，意思是初始条件十分微小的变化经过不断放大，也许会对未来造成极大的影响。
图灵奖得主Tony Hoare在Null References：The Billion DollarMistake文章中写到：“我将 Null 引用称为自己的 10 亿美元错误，它的发明是在 1965 年，那时我用一种面向对象语言（ALGOL W）设计了第1个全面的引用类型的系统，目的是确保所有引用的使用都是绝对安全的，编译器会自动进行检查。但是我未能抵御住诱惑，加入了Null 引用，仅仅因为实现起来非常容易。Null引用导致了数不清的错误、漏洞和系统崩溃，可能会在之后40年里造成10亿美元的损失。”
Null引用在 Java中的表现就是可能抛出 NullPointerException异常，这是一种非预期的异常。对于 IT 系统而言，还有很多非预期的错误及异常，都可能是蝴蝶效应引起的大故障，例如非预期error、非预期的调用抖动、极少数场景下的规则未被正确处理、错误的优惠处理逻辑、未正确设置的营销活动，等等。如果不具备快速、智能的感知能力，那么可能影响更多的用户，使资金损失增加、业务不可用时间变长，等等。
墨菲定律
“墨菲定律”是一种心理学效应，由爱德华·墨菲（EdwardA.Murphy）提出。它的原句描述为：如果有两种或两种以上的方式去做某件事情，而其中一种选择方式将导致灾难，则必定有人做出这种选择。
墨菲定律（Murphy’s Law）的主要内容如下：
◎ 任何事都没有表面看起来那么简单；
◎ 做所有的事花费的时间都会比你预期的时间长；
◎ 会出错的事总会出错；
◎ 如果你担心某种情况会发生，它就更有可能发生。
爱德华·墨菲是美国爱德华兹空军基地的上尉工程师。1949年，他和他的上司斯塔普少校参加美国空军进行的 MX981 火箭减速超重实验。这个实验用于测定人类对加速度的承受极限。其中有一个实验项目是将 16 个火箭加速度计悬空装置在受试者上方，当时有两种方法可以将加速度计固定在支架上，而不可思议的是，竟然有人有条不紊地将 16 个加速度计全部装在错误的位置。于是墨菲做出了这一著名的论断，意思是如果做某项工作有多种方法，而其中有一种方法将导致事故，那么一定有人按这种方法去做。
在IT系统中有很多关于墨菲定律的案例，接下来会列举其中的两个案例。
这里列举第1个案例。笔者曾遇到一位经验丰富的架构师，他对系统迁移过程中的自校验、核对、切流策略、灰度能力、回滚机制、容错处理等都进行了充分考虑，但未充分考虑老系统的一种流程处理缺陷的备案或者处理方案，因为老系统在上线的一年内只发生了1起相关故障。但该缺陷的影响在新系统中被无限放大，很快就导致1起严重的线上故障。
这里列举第2个案例。很久以前，笔者所在的公司来了一位专家级别的开发人员，他面对的第1个小需求就是把搜索结果列表从每页10条改为每页50条。他认为只改一个分页的pageSize就可以了，于是很快就改完了，并且没经过测试就发布到线上，结果导致公司整个网站的搜索结果跌零。
后来经排查发现，因为老系统的性能不高，所以开发人员做了一个设置：当搜索结果不少于 50 条的时候，就直接返回 0条搜索结果。暂且不论这种设置是否合理，这种故障之所以发生，就是因为开发人员过于自信，疏忽了重要的测试环节。所以，在软件测试方面，没有经过测试的功能往往会出问题。
由于认知的局限性、骄傲心态、问题域的复杂性及不可把握性等因素，软件行业发生问题的概率很高。墨菲定律告诉我们：事情往往会朝着我们所能想到的不好的方向发展，只要存在这种可能性。所以，无论是开发人员还是测试人员，都需要谨记墨菲定律，莫存侥幸心理，要把自己的系统设计得足够强壮。