CEO请读《架构即未来》-技术与商业须融汇贯通！前eBay CTO的实战真经

首先要解释一下文章的标题，为什么是CEO必读，然后又特别强调“技术无关”呢？因为我们都知道在过去的双十一中，在一天时间之内互联网用户（C端）、电商平台（B端）、所有平台上的商家以及支付&物流系统（B端）在强大的技术平台（T端）支撑下，单一平台实现了超过3000亿规模的交易，众多电商平台完成了超过5000亿规模的交易，这应该可以说是非常让人叹为观止的T2B2C的实战案例。在这个过程中，所有企业的CEO都一定要去关注一个问题：如此庞大的交易是如何做到平稳有序进行的呢？这中间的技术能力如何强大，众多的企业如何构建出一个强大的技术平台用于企业的数字化升级（员工在线、产品在线、客户在线、管理在线）呢？与其羡慕，不如进来一探究竟吧。

同时也说一下在金融行业正在发生的事情，一边是金融企业大量的裁员，另一边是大量招聘具有FinTech的专业人才，所有在职人员都必须会用SPSS、PYTHON（人工智能领域的编程语言，没错，要求金融行业人群也要会编程），例如：JP Morgan首席运营官马特·泽玛斯曾表示：“我们要保证行业领头羊地位，就必须得在金融科技上先拔头筹。”像JP Morgan在金融技术领域也走在行业前沿的金融公司专门设立了技术中心，聘用约4万名技术工作者，技术预算达96亿美元，专攻大数据，机器人和云基础设施。此外，它还和英特尔、微软等30多家企业组成了一个新的区块链联盟，以开发相关的标准和技术。

虽然传统行业的CEO不用在金额行业对于IT技术的要求这么极端，但许多CEO有着丰富的商业背景，并不具备IT与互联网技术的背景啊，一说到强大的IT系统，大家就立即就浮现出了一行行的代码，一排排的服务器，虽然这是真实的代码世界。但我们就在代码世界里仍然是有许多可以进一步进行抽象、构建成为模型的领域知识，用于各位CEO进行商业决策时的技术指导思路参考。

如：CEO在面向企业的CIO或是CDO向自己汇报需要构建系统的时候，除了关注系统好不好用之外，还需要进一步关注系统的架构设计，是否在安全、可扩展性、高性能层面有所保障？过往的决策逻辑似乎很简单，只要选择国外知名厂商的系统平台就可以支撑自己企业内部的应用了，即便系统出问题了也不是做选择的那个人技术负责人的问题，因为这里有一句潜台词：我已经选择了全世界最牛B的系统，如果还出问题就不能怪我能力不行了吧。

但如今从中国双十一的实践来看，能够进行支撑海量大规模交易的系统并不是一个中心化的、大而全的统一化平台，而是基于众多生态企业进行紧密协作的，形成生态协作网络的“松散组合”的生态平台，在统一的接口与技术规范下各自发挥的平台，那我们还能用简单的一句“国外的月亮就是圆的”来做技术平台的选择吗？从这个视角来看，未来商业企业的CEO必然要面对企业的数字化升级、转型的问题，必须要对IT技术领域要有一个初步的认知与了解。

从这个视角来看，我们不妨先看似最神秘的“系统架构”来看一下，CEO在没有技术背景下，如何去理解一个软件平台称的上“高大上”呢？借用前eBay、Palpay CTO在《架构即未来》（《THE ART OF SCALABILITY》）一书的观点来告诉各位CEO，其实技术架构没有这么复杂，甚至从某种程度上来说，技术架构与组织架构一样也是要符合一些基本原则的。（注意：这也是真正CTO的能力，将一个CEO不懂的技术领域用商业语言进行有效表达，做好技术创新与商业价值之间的转换及平衡）

好的IT系统架构原则是什么？首先，这是需要符合SMART原则的架构设计，是可以影响团队的行为和文化的，它们应该帮助指导设计，并以此测试和确定这些设计是否符合公司的目标和需求，有效的架构原则与公司的目标、愿景和使命紧密地结全在一起。一个好的架构原则有以下几个特点：

1、具体的：原则不应该被混淆在它的措辞中，如果一个系统架构只是说明了技术很牛B，但不能举例说明具体场景的，那可能这只是“看起来高大上，但实际上没有什么用”；

2、可度量的：原则不应包含“无限”这样的词汇，如可支持无限扩展，毕竟任何的技术架构实现都是会有资源与成本投入的，一个可度量的目标是技术架构规划的商业限制边界所在。

3、可达到的：尽管原则应该是鼓舞人心的，它们应该能够在设计和执行上实现，只能画饼不能兑现的目标不设也罢。

4、现实的：团队应该有能力达成目标。有些原则是可以实现的，但是需要时间和天赋。

5、可测试的(Test)：修改后的原则可以用于测试设计 ，以验证它是否答规整需要，如果最后的这一个环节中，我们没有办法做到可测试的话，那意味着我们仍然没有形成校验的闭环，仍然是一个假设的架构规划。

谈起来可衡量这个事情，对于非IT领域的CEO来说心里就算是有底了，就是拿个尺子去量呗，那具体应该怎么量呢？

对于架构设计的原则，主要是从三级指标来衡量，首先系统要能用、可以用，别这么轻易地就挂掉，所以第一组指标是可扩展性、可用性、质量；再者系统应该是符合财务投资视角的“成本/效率比“的，那第二组指标为成本和效率性相关指标；最后一组指标则更为高级一些，是指开发、运行的处理能力的，第三组指标就是为TTM（设计响应时间），当然也会有在这个三个要素下的综合类指标，包括异步设计与自动化等，这些要点可以从上述的架构原则维恩图来确定，以下内容是对于架构设计原则的详细内容展开：

1、N+1设计：这个原则所表达的就是要确保任何你所开发的系统在发生故障时，至少有一个冗余的实例。应用三规则为一个为自己，一个为客户和一个为失败。

2、回滚设计：无论你构建什么，都要确保它可以向后兼容。回滚设计是提供网络、Web2.0或者SaaS服务公司的一个重要架构原则。

3、禁用设计：当设计系统，特别是与其他系统或服务通信的高风险系统时，要确保这些系统能够通过开关来禁用。这将为修复带来额外的时间，确保系统不因为错误引起的诡异需求而宕机。

4、监控设计：如果监控做的好，不仅能够发现服务的死活，检查日志文件，还能收集系统相关的数据，评估终端用户的响应时间，如果系统和应用在设计时就考虑好监控，那么即使不能自我修复，也至少可以自我诊断。

5、设计多活数据中心：必须拥有多个数据中心，以便向股东保证可以渡过任何在地理上可以隔离的灾难和危机。开始考虑数据中心运维策略的时间，不是在部署数据中心的时候，而是在设计数据中心的时候。

6、使用成熟的技术：新技术往往可以帮助我们降低成本、减少产品上市时间，降低开发成本、提高可扩展能力、减少终端用户的响应时间。

7、异步设计：异步系统对于速度减缓更加宽容，在某些情况下，反应可能会有所减缓，但整个系统不会停顿下来，这种方法可能会给你几天时间来“解决”一个扩展性的瓶颈问题，而不是像一个同步系统那样需要立即采取行动。

8、无系统状态：状态系统中的操作都是在前后关联的情况下进行的，因此对于任何给定的执行或系列的请求，其过去的操作信息必须要暂时存储在某个地方，尽管在许多情况下状态是有价值的，但应该密切评估其投入产出效益。状态通常意味着需要额外的系统和同步的调用，也使得设计多活数据中心更加的困难，所以只要有可能就要避免开发需要状态的产品。在必要的情况下，可以考虑存储在客户端，而不是在系统里。当然，尝试把状态信息按照客户或交易类别分割以便于更方便地分布存储在多个数据中心，并尽可能把某个客户或某交易类别的数据存储在一个数据中心，只需为灾备复制数据。

9、水平扩展而非垂直升级：如果你想达到近乎无限的扩展，那么就必须分散系统、组织和流程以利于扩展。特别是当利用IaaS厂商提供的弹性和自动扩展功能时，水平扩展而不是垂直升级的能力非常重要。

10、设计至少要有两个步骤的前瞻性：领导者、管理者和架构师都要考虑未来，对于任何服务都应该考虑如何进行下一个分割。

11、非核心则购买：无论你和你的团队有多么聪明，你不可能什么事都做得最好，因此非核心购买是一个成本效益原则，它也影响可扩展性，可用性及生产力。

12、使用商品化硬件：类似于使用成熟技术的原则，硬件，特别是服务器的商品化迅速，基于成本原则以市场购买为特征的趋势很明显。

13、小构建、小发布、快试错：小版本的失败率较低，因为失败率与解决方案中的变更数量直接相关。

14、隔离故障：我们要认识到工程们懂得该如何把事情做好，但是往往很少花时间去思考清楚系统是怎么失败的，故障隔离的原则类似于建立一个有断路器的电气系统。

15、自动化：设计和构建自动化的过程，如果机器可以做，就不要依赖于人。所有系统都应该在开始设计的阶段就要考虑自动化。自动部署、构建、测试、监控甚至报警。

许多架构设计原则也只是原则，无法有效执行落地，那就要从技术团队的运营管理机制上来保障，因此可以有两个积极的软件工程过程来保障，事前规划所需的联合架构设计（Joint Architecture Design,JAD）和事后审查的架构审查委员会（Architecture Review Board，ARB），这两个过程本质上是跨部门并交织在产品或软件开发的生命周期中，JAD是一个协同设计的过程，所有的工程人员一起共同设计和开发一些符合架构原则的主要新功能。而ARB是一个架构设计得到最终签署之前，要由该委员会确定设计符合公司所有的架构原则和业界的最佳实践。

JAD是一个协同设计过程，它集中所有工程需要的资源共同完成新功能或进行架构修改所需要的设计工作，这些设计必须符合公司的架构原则和最佳实践要求，JAD的目的就是通过跨部门的认知型冲突（认知型冲突是一个良性冲突，而恶性冲突则为情感冲突）来增加创新。JAD团队应该包括一个未来负责编码的软件工程师、一位架构师、至少一个运维工程师、产品经理、项目经理和质量保证工程师。

而ARB的团队成员都需要展示自己的专长，无论是在工程、架构还是业务方面，这就需要有以下人选侯选人，包括：首席架构师、可扩展性架构师、基础设计架构师、工程副总或董事、运维或基础设施的副总裁、高级系统管理员\DBA、高级工程师、CTO和CIO、事业部总经理、产品或业务负责人。ARB团队最好是由4-8人组成，需要每周一次会议来审视JAD的工作成果，因此考虑到团队中人员的精力投入，可以考虑设定一部分人员为ARB的常设人员，另一部分则为轮换，每季度调整一次ARB委员会的轮换成员。

当我们要对IT系统构建做决策时，我们在技术选择上仍然是使用了最常见的商业逻辑：首先界定一个符合SMART原则的技术目标，在这个技术目标之后构建一个完整的技术架构能力评估框架，并通过联合架构设计（JAD）和架构审核委员会（ARB）的工作机制来确保决策能够得到有效落地，看起来很简单不是吗？在数字化时代生存，CEO也要懂点技术，这是必须的！

作者：童继龙

来源：继龙书享汇