让你的系统在上线之前就接受炮火的洗礼-影子流量

随着持续集成,持续交付等理念的传播,很多软件开发团队都搭建了自己的staging、UAT等类生产环境。这些环境的软硬件及网络配置会尽量贴近真实的生产环境,起到沙盘演练的作用。

类生产环境毕竟前面还有一个类字,沙盘毕竟不是真实的战场,尽量贴近毕竟还不是完全吻合。

类生产环境与真实生产环境的一个重要差异就是访问量。稍具规模的互联网应用每天几百万访问量是很正常的,而类生产环境的访问量一般都会相形见绌。

有各种工具可以弥合这个差异,比如Apache JMeter,Gatling。测试人员可以和开发人员一起设计测试用例,以自动化或者半自动化的方式对类生产环境进行压力测试

不过即便是精心设计出来的用例也还是用例,不是真实请求。真实请求具有多样性,会随着昼夜交替而变化,会随着时事热点而波动,这是很难用工具模拟出来的。

这就引出了这篇文章的主角-影子流量(shadow traffic)。

简言之,影子流量(shadow traffic)就是将发给生产环境的请求复制一份转发到类生产环境上去,以此来达到压力测试和正确性测试的目的。

这就如同把真实战场上的敌方炮火投放到演习场里去。

实现方式

Shadow traffic通常有两种实现方式:服务端实现,客户端实现。

下图描述的是服务端实现的简化示例。

生产环境接收到来自于用户或者是上游系统的请求,在响应该请求的同时,将这个请求原封不动的也发送给类生产环境。

下图描述的是客户端的实现。

客户设备或者上游系统在发给生产环境请求的同时,给类生产环境也发送一个一模一样的请求。

这两种实现方式各有优劣,放到服务端做可以减少客户端设备的流量消耗,这一点对于移动应用很重要。

客户端的实现则较简单,通常只需要几行代码即可。如果后端架构较复杂,则可以选择前端实现。

无论前端还是后端实现,都需要遵循发射后不管(fire and forget)的原则,以免阻塞正常流程或者增加响应时间。

适用场景

笼统来说,shadow traffic可以适用于所有互联网应用。而在以下场景中,shadow traffic的作用格外明显:

  • 要用新系统替换掉老旧系统
  • 系统经历了大规模改造,直接上线面对客户风险较大
  • 系统更新,需要提供向后兼容性
  • 试验性质的架构调整

在以上场景运用shadow traffic,可以在不影响终端用户的情况下完成验证与测试。

启用时机

在上线之前一段时间集中地进行测试固然是一种可行的方式,不过我个人更倾向于在项目运转的早期引入shadow traffic。

这样做可以让开发团队尽早的并且持续的接触到真实的外界压力。相当于用一种成本并不怎么高的方式构建出了具有产品运维经验的开发团队。

配套机制

Shadow traffic的原理和实现方式并不深奥,但要让它发挥出应有的价值还需要一些前期工作的配合。

基础设施监控

要了解系统的表现,基础设施监控是必不可少的。

上图是我所经历过的一个项目的可视化监控界面。监控范围涵盖了docker container的数量,请求数量,响应时间,以4或者5打头的HTTP状态码的数量,网络、内存、CPU用量等等。

通过如上的可视化图表,开发团队可以实时得到反馈。

日志

基础设施监控可以提供一个外部视角,日志则能够窥见应用内部。

日志可以帮助开发团队定位shadow traffic中发现的问题,shadow traffic也可以促使开发团队提升日志的质量。这二者可以起到双向的积极促进作用。

下游系统的配合

如果一个系统开启了shadow traffic,可以想见它的下游系统所面对的压力也会陡升。

这时有必要与下游系统负责团队做好事先沟通。

用法变式

Shadow traffic并非是一成不变的技术实践,可以按需微调。

请求挑取

并非每一个请求都有被转发的必要。可以优先选取流量大或者业务价值高的请求。

流量控制

如果想做极限压力测试,可以把每一个请求重复发送多次给类生产环境。

当然也可以只挑取10%的请求来发送给类生产环境,随着团队信心的提升而逐步升高。

重播

可以截取并保存每天尖峰时刻的请求,在其他时段反复重播。

这种考验可以有效的锻炼团队的心理素质,并促使团队形成应急预案。

小结

如果明天要上线,今天会是一个让人惴惴不安的日子。

系统性能表现如何?会不会有奇形怪状的用户行为导致系统异常?与上下游系统的衔接会不会出现问题?

这些问题的答案,可以通过测试人员的精心模拟来寻找。但仍难免会挂一漏万。

启用shadow traffic,如果开发团队可以习惯于有shadow traffic的日常,也就具有了应对线上运维问题的能力。


更多精彩洞见,请关注微信公众号:思特沃克

Share

银行业如何建立科技生态圈

上周好几个同事和朋友转给了我一篇《麦肯锡重磅报告:银行业如何超越互联网巨头建立生态圈?》。话题很时髦,读后却印象寥寥,好像说的都对,然则没有什么观点是真正触及问题深度的。于是把这两年自己跟各家银行合作过程中形成的“执念”记录下来,抛砖引玉。

牵手BATJ,是合作还是心猿意马?

在国家的美好期待和祝福下,四大行从去年开始正式牵手互联网巨头。作为科技侧的顾问,这本身是一个利好消息,业务终于得向科技看了,老大难的协作问题终于有希望提上战略议事日程了,毕竟业务和科技总得融合吧!

当然时至今日,这个利好消息并没有变现,拿得出手的合作案例一个没有。问各大行的科技人员,充满了对互联网巨头们的失望;再问BATJ的前同事们,纷纷表示国企搞不定,流程长规矩多。究其原因,如果简单用银行需要从“霸气的主导者”,转变成“聪明的参与者”来形容未免就太过于草率了。

不可否认银行和互联网巨头有着巨大的文化差异,银行业的强风险管控和互联网的快速试错,驱动出了两种业态。是什么让国家都觉得这两种业态需要合作呢?答案显然是数字化。未来的金融服务必然需要依靠数字化技术和渠道,而互联网企业拥有更强大的数字化能力。中国移动支付被这几家互联网巨头雄霸就是最好的案例。

然而看似合理的联姻背后却是两种业态的碰撞。这几家互联网巨头已经各自演变成了平台企业,某种程度上的领域寡头,比如腾讯的社交、京东和阿里的电商、百度的搜索。平台战略是一种经典的商业模式,成为寡头是保证盈利的核心策略之一,比如现在的滴滴。在这个数字化时代,这些巨头们都在想什么呢?答案也是比较明确的,希望自己成为一家科技企业,好像Google和Facebook,能够利用强大的技术力量进入(甚至于创造)新的领域,因为老平台总有一天会被新平台取代。阿里旗下的金融服务公司蚂蚁金服,拥有高达60%以上的科技人员就可见一斑。

自然在这两个业态联姻时,这几家互联网巨头最希望的是合作银行用他们的科技平台,比如云和技术中台。所以自然的结果就是今天一家银行宣布采用阿里云,明天另外一家银行决定腾讯云来试点。然而除了去IOE和国家要求的银行IT系统上云,采用这些巨头的科技平台真的对银行有帮助吗?银行业的安全及监管规则对互联网企业来说很多是完全陌生的,也自然不会存在于这些科技平台中,采用平台带来的风险谁来买单呢?

反观银行方面,最希望合作的是互联网巨头们的流量,能够利用客群资源进行业务的拓展和创新。但作为垄断寡头的BATJ会把流量倒灌给银行?会锁定一家或几家银行合作?这本身就是违背平台战略的问题,自然答案是不会。于是这样的合作从最开始就已经是心猿意马了。

也许现在对这种泰坦级合作下结论还为时尚早,但有一点是肯定的,双方都不会在合作中得到自己最想要的东西

独立科技公司,是破釜沉舟还是文化转型?

以建行和民生为代表的国有和股份制大行纷纷开始独立旗下IT力量,成立科技公司,一时间搞得银行业暗潮涌动,有实力的银行纷纷启动FinTech和数字化转型。多家银行拿出的预算都是按照自身年收入的百分之几计算,一副破釜沉舟的架势。

收集各大银行独立科技公司的初衷超出了我的能力范围,但就我自己的观察,其中一个核心问题就是解决科技生存的文化土壤。当数字化渠道成为银行服务的主流渠道时,原有的IT作为一个成本中心是不可能支撑业务发展需求的。这个矛盾也不是简单将行里的愿景写成“科技引领”就会发生变化的。毫不夸张的说,业务和科技的协作问题已经是银行高级管理者们最头疼的问题。

5年前提出的去IOE对银行IT的影响不大,大量的业务仍然依靠稳定的IBM大型机,数据库也照样是Oracle。短短5年,银行的业务发生了翻天覆地的变化,当然这一点不意外,中国经济超高速增长的大环境下,金融业务必然更快成长。时下去IOE已经不会写在谁的年度目标里了,成为了自然而然的事情。和5年前的差别在于,之前的去IOE并没有客观的业务诉求,而现在不去IOE,可能就支撑不了未来业务了。这实际上也带来了文化上的巨大转变,传统的银行IT职责是使用和运维IOE系统及应用,目标是保持系统的健壮性和稳定运行。而后IOE时代的银行IT必须扩充自身的科技实力,这意味着学习新的技术和培养更强的自研能力。

从银行IT到金融科技,这不应该是一场破釜沉舟的战役,而应该是一次银行组织的文化转型。

不管转型的手段是什么,成立独立科技公司,亦或是增强科技人员占比,都不应该仅仅聚焦于银行的IT部门和团队,银行领导者和业务团队如果不深度参与到这次转型过程中来,文化是不会改变的,而科技和业务不但不会融合,反而会形成更大的鸿沟。这一点上,国内已经有几家银行走在了业务科技融合的正确道路上,展开了广泛的科技赋能。

客户为中心,是时代口号还是业务创新?

大型国有行和股份制银行确实在获取客户的能力方面非常羡慕互联网企业。按照现代资本论的说法,资本的增长包含一个纯人口部分和一个纯经济部分。从这个角度出发,如果能够为一种服务获取更多的“人口” —— 客户,那么增长是自然而然的。

互联网时代在客户管理方面有很多的创新,总结出了不少的分析模型,例如大家比较熟悉的海盗模型 —— AAARRR,据说海盗是这么发声吓唬人的。但其实这些模型存在的目的是帮助大家建立科学的认知方法,套用模型很容易买珠还椟,只记住了这些方法框架,反而忘了真正的客户。比如当我走进银行网点办理开卡业务时,柜员会根据提示发现我有可能正在装修,礼貌询问我是否需要低息装修贷款。这个场景用这些经典框架分析可能是非常正确的,在整个服务流程中嵌入了贷款金融服务。但实际上之所以我来到网点的原因是银行为了满足监管要求不能只通过网络给我开卡,所以我——作为客户——来到网点唯一希望就是快速办理,这个过程中任何的“植入”都会让我反感。

我们很容易喊着客户为中心的口号,做着伤害客户体验的设计。而真正的客户为中心往往需要银行跳出现有的服务模式,从客户的真实述求出发去重新设计业务。

“趣分期”是趣店的前身,由于其目标客户是大学生,所以纳斯达克上市后赶快弱化了其小型借贷公司的身份,成了一家电商。但我们却可以从这个案例中,分析一下为什么各大银行都在做的校园银行没有如此成绩。网上公开的数据显示趣店的大学生客户有3000万,月活2000万以上,这个数字相信足以让各大银行汗颜。

同样是校园信贷服务,我们看到的差异点在于谁真正把客户放到了中心,校园里的客户就是学生,而学生们不是希望贷款,他们希望的是自己拥有一部iPhone,或是能够拥有一台随身笔记本。贷款只是帮助他们达成自己心愿的一种手段(向父母撒娇也许是另外一种)。思维观念的不同自然造就了新兴业务模式的出现,而新业务模式的成功会给缔造者带来高额的回报。

最近在澳洲一家金融机构的数字化转型过程中出现过同样的场景。其中一个目标是帮助这家金融机构推销更多的住房贷款,大家拿出了现在的市场数据和客群分析,也考虑了简化贷款流程,然而一位资深顾问的问题彻底改变了大家的认知,“我们是在讨论提高住房贷款销售,还是在分析如何帮助我们的客户拥有一个美好的家?”这个问题让大家意识到,我们并没有认真去了解客户,我们还是在以自己的服务为中心。

高盛成立零售银行Marcus,直指颠覆传统个人银行业务的当下,各大银行急需的是业务的创新,并且时刻思考客户那个“美好的家”,而不是“住房贷款”。

固本清源,从业务出发建立科技生态

科技能力的建设固然是有很多种方式的,比如时至今日我可能才基本理解为什么华为领袖任正非提出的“用西方的砖修中国的长城”策略。科技能力的建设在当下最挑战的是需要为自己的企业打造一个科技生态圈,每当我看到西班牙BBVA在过去3年打造的科技生态(下图)的时候,都感觉到咱们中国的银行还有相当长的能力建设之路。

https://www.finextra.com/newsarticle/31811/can-banks-be-a-threat-to-big-tech

不仅仅是银行业,在电信运营商领域,最近两年荷兰起家的KPN给我们深刻演义了科技的力量,他们在2个月内完成了跟微信的对接,其直接结果是目前卖给中国游客的预付费SIM卡比自己本国经营的还多。而其它的欧洲运营商,由于不具备这样的科技能力,只能眼睁睁看着业务机会流失。

从科技视角出发,互联网实际只是一个数字化渠道了。在不远的未来,当IoT设备普及,我们会有更多的数字化渠道。针对银行现在的挑战,我们认为以下关注点是当务之急:

  • 从客户视角简化端到端数字化体验
  • 从提升响应力出发打造跨职能团队
  • 从平台思考规划数字化能力,建立能力平台
  • 从业务创新思考合作生态(渠道)


更多精彩洞见,请关注微信公众号:ThoughtWorks商业洞见

Share

技术雷达第十九期正式发布,用百余个条目更新你的技能图谱!

ThoughtWorks每年都会出品两期技术雷达,这是一份关于技术趋势的报告,由ThoughtWorks 技术战略委员会(TAB)经由多番正式讨论给出,它以独特的雷达形式对各类最新技术的成熟度进行评估并给出建议,为从程序员到CTO的利益相关者提供参考。

它比那些我们能在市面上见到的其他技术行情和预测报告更加具体、更具可操作性,因为它不仅涉及到新技术大趋势,更有细致到类库和工具的推荐和评论,因此更容易落地。经过半年的追踪与沉淀,ThoughtWorks TAB(ThoughtWorks技术咨询委员会)根据我们在多个行业中的实践案例,为技术者产出了第十九期技术雷达,对百余个技术条目进行分析,阐述它们目前的成熟度,并提供了相应的技术选型建议。

本期主题

粘性十足的云平台

云提供商知道他们正在严峻的市场中进行竞争。为了获胜,他们需要吸引用户注册并长期留住他们。因此,为了保持竞争力,他们在新增产品特性上你争我抢,使得彼此不相上下。这一点可以从本期雷达试验环中以下云提供商的排名看出: AWS、 Google Cloud Platform 和 Azure 。然而,一旦用户注册,这些云提供商就倾向于与用户建立尽可能高的粘性,以阻止他们使用其他提供商的服务。这通常表现为其云服务会与其服务和工具套件紧密集成。用户只有继续使用其云服务,才能获得更好的开发者体验。通常在用户决定是否将其部分或全部工作负载移动到另一朵云上,或发现云服务的使用和账单多到失控时,就能明显感觉到这种粘性。我们鼓励客户使用 架构适应度函数度量成本 的技术来监控运维成本,并将其作为衡量云供应商粘性的指标。或者使用Kubernetes和容器,并通过运用基础设施即代码来提升工作负载的可移植性,降低切换到另一个云提供商的成本。在本期雷达中,我们还会介绍两个新的云基础设施自动化工具:Terragrunt和Pulumi。虽然我们支持通过粘性的高低来评估云提供商的新产品,但提醒你不要落入只使用通用云服务功能的陷阱。根据我们的经验,创建和维护与云无关的抽象层的开销,会超出退出某个特定云提供商的花费。

挥之不去的企业级应用反模式

无论技术如何快速变化,一些企业仍然想方设法地重新实现过去的反模式。雷达中的许多暂缓条目都在揭穿一些“新瓶装旧酒”的老把戏。比如:用Kafka重新创建ESB的反模式、分层式微服务架构、Data-hungry packages、过度庞大的API网关、Low-code 平台和一些其他有害的旧实践。一如既往的根本问题,是如何在隔离和耦合之间取得平衡:我们隔离组件,使其在技术角度便于管理。但是我们也需要协调组件,使其有助于解决业务问题。这就产生了某种形式的耦合。因此,上述旧模式就不断重新冒出来。新的架构和工具为解决这些问题提供了适当的方法,但这需要刻意去理解如何正确地使用它们,而不仅仅是使用崭新的技术去重新实现旧模式。

持之以恒的工程实践

随着技术创新步伐加快,新技术的发展呈现出一种从爆发到沉淀不断循环的模式。每当能够颠覆我们对软件开发固有认知的新技术出现时,都会引起业界的争相追捧,容器化、响应式前端和机器学习都是很好的例子。这时技术处在爆发阶段。然而,只有在明确如何与长期以来的工程实践(持续交付、测试、协作等)相结合之后,新技术才能真正的发挥功效,并进入沉淀阶段,为下一次爆发性扩张打下坚实的基础。在沉淀阶段,我们尝试在新技术的背景下应用实践,比如进行全面的自动化测试以及创建脚本代替重复操作,通常也会创造出新的开发工具。虽然表面看来技术创新是行业发展的唯一驱动力,但事实上,创新与持之以恒的工程实践相结合才是我们不断进步的基础。

速度 = 距离 / 时间

通常,我们会选取本期雷达中部分共性条目的精彩集锦展现在雷达主题中,但本主题涉及自技术雷达诞生以来出现过的所有条目。我们发现(并通过一些调研证明)雷达条目停留在雷达上的时间正在缩减。当我们在10年前启动技术雷达时,如果某个条目在雷达上的位置不再移动,它依然会保留两期(大约一年)时间,之后才会自动移出雷达。然而正如标题中的公式所说,速度 = 距离 / 时间: 软件开发生态系统中的变化一直在持续加速。在时间保持不变(依然是每年发布两次)的前提下,雷达中技术创新所跨越的距离明显地增大了。这为精明的读者提供了显著的证据:技术变革的步伐正在不断加快。我们不仅看到雷达中的各个象限在加速变化,也看到了客户对新兴的及多样化的技术选择所表现出的兴趣。因此我们将改变传统的默认模式:雷达不再默认保留其上的条目,它们是否出现在雷达上完全取决于它们当前的价值。我们在深思熟虑后做出了这项改变,并认为只有这样才能更好地跟上技术生态系统中前所未有的狂热变化节奏。

象限亮点抢先看

Event Storming(事件风暴)

快速市场响应能力是组织进行微服务转型的主要驱动之一。然而只有沿长期业务领域边界对服务(及其支持团队)进行清晰划分时,这种期望才可能实现。否则,现实需求只有在跨组织和跨服务的通力合作才下能完成,这自然会在规划产品路线图时产生冲突。良好的领域模型设计是解决此问题的方案,事件风暴(EVENT STORMING)也迅速成为我们最喜爱的方法之一,它使我们能够迅速识别问题领域中的关键概念,并用最好的方式与各方利益相关人制定解决方案。

Microservice Envy

微服务已成为现代云计算系统中的领先的架构模式,但我们依旧认为团队在使用该架构时应谨慎。 MICROSERVICE ENVY特指那些盲目追赶微服务潮流的现象,很多团队在实践微服务时并没有简化其系统架构,大多数的实践方案只是将一些简单的服务聚合在一起而已。目前,Kubernetes等平台简化了复杂的微服务系统的部署问题,其他服务提供商们也正在推进他们的微服务治理方案,这些强大的工具都可能裹挟团队走上微服务之路。 但请千万谨记,微服务是通过开发复杂度来换取运维复杂度,并需要自动化测试、持续交付和DevOps文化提供坚实的支撑。

Observability as Code(可观测性即代码)

可观测性是运转分布式系统与微服务架构必不可少的一部分。我们依赖不同的系统输出来推断分布式组件的内部状态,比如分布式追踪、日志聚合、系统指标等,进而诊断问题所在,并找到根本原因。可观测性生态系统的一个重要方面就是监控——可视化以及分析系统的输出——并且在检测到异常时报警。传统的监控报警配置,都是通过图形界面的操作完成。这种方法导致控制面板页的配置不可重复,从而无法持续测试和调整报警,来避免报警疲劳或错过重要的报警,进而偏离组织的最佳实践。我们强烈建议使用代码来配置可观测性生态系统,称为可观测性即代码(OBSERVABILITY AS CODE),并且采取基础设施即代码的方式搭建其基础设施。因此,在选择提供可观测性的工具时,要选择支持通过代码版本控制进行配置,并能通过基础设施持续交付流水线执行API或命令行的产品。可观测性即代码,是基础设施即代码中经常被遗漏的一部分,我们认为这一点非常重要,需要明确指出。

Four key metrics(四个关键指标)

2014年首次发布的DevOps状态报告指出,高效团队创造了高效的组织。最近,该报告背后的团队编写了Accelerate一书,描述了他们在报告中使用的科学方法。两份材料的核心点都支持了软件交付性能的四个关键指标(FOUR KEY METRICS):前置时间,部署频率,平均恢复时间(MTTR)和变更失败百分比。作为帮助许多组织转型的咨询公司,反复使用这些指标测量,可以帮助组织确定他们是否在提高整体效能。每个指标都创造了一个良性循环,并使团队专注于持续改进:缩短交付周期,减少浪费的活动,从而使你可以更频繁地部署;部署频率迫使你的团队改进他们的实践和自动化流程;通过更好的实践,自动化和监控可以提高你从故障中恢复的速度,从而降低故障频率。

Run cost as architecture fitness function(架构适应度函数)

随着软件架构及其业务的演进,我们理应密切关注应用的运行成本,但发现并非所有的组织都如此。尤其是在使用无服务器架构时,开发者们认为无服务器架构会更便宜,因为他们只需按消耗的计算时间付费。然而几家主要的云服务提供商在热门的无服务器函数上定价十分精明,虽然无服务器在快速迭代上很有优势,但与专属云(或内部私有云)相比,它的开销可能随着使用量迅速增长。我们建议团队将应用的运行成本纳入架构适应度函数(RUN COST AS ARCHITECTURE FITNESS FUNCTION)来考量,这意味着:追踪并权衡应用的运行成本与交付价值;当它们之间产生较大出入时,就需要考虑改进软件架构了。

Debezium

DEBEZIUM是一个change data capture (CDC)平台,可以将数据库的变更以流的形式传入 Kafka 主题中。CDC是一种流行的技术,具有多个使用场景,包括将数据复制到其他数据库中,为分析系统提供数据,从单块系统中提取微服务,以及令缓存数据无效等。我们一直在寻找这个领域的工具或平台(包括在之前的技术雷达中讨论过的 Bottled Water),而Debezium 是一个极佳的选择。它使用了基于日志的CDC方法,意味着能以对数据库日志文件的变更进行响应的方式进行工作。Debezium使用了Kafka连接,这使得它具有高度的容量伸缩性,以及对故障的系统韧性。它拥有包括Postgres、Mysql和MongoDB在内的多个数据库的CDC连接器。目前,我们正在一些项目上使用该平台,并取得了很好的效果。

Quorum

在区块链技术领域,Ethereum(以太坊)是一个领先的开发者生态系统。我们看到了一些新兴的解决方案,它们旨在将Ethereum这项技术传播到一些企业环境中。这些企业通常需要网络权限和交易隐私管理,另外还需要更高的吞吐量和更低的延迟。 QUORUM 就是其中的一个解 决方案。Quorum最初由J.P. Morgan开发,其定位是“企业版的Ethereum”。与创建了新的以太坊虚拟机(EVM)的Hyperledger Burrow 节点不同,Quorum的代码源自以太坊官方客户端的一个分支,所以能与以太坊一起进化。在保留了以太坊账本的大多数功能的前提下,Quorum将共识协议从工作量证明机制更改为更高效的协议,并增加了私有交易支持。使用Quorum,开发人员可以使用他们的以太坊知识来构建企业级的区块链应用,这些知识包括 Solidity语言和 Truffle 合约。然而根据我们的经验,Quorum还没有为应用于企业做好充足的准备;比如:它缺乏针对私有合约的访问控制机制,无法用于负载均衡,并且只支持部分数据库。所有的这些限制都为用户的部署与设计带来显著的负担。我们建议在使用Quorum的时候保持警惕,同时密切关注它的后续发展。

IPFS

在多数情况下,区块链不适合存储 blob 文件 (例如:图像,音频),当人们开发 DApp 时,一种选择是将blob文件存放在一些链下的集中式数据存储中,这种做法通常会导致信任缺失,另一种选择是将它们存储在星际文件系统 IPFS上,这是一种内容可寻址、版本化、点对点的文件系统。它旨在高效地分发大规模数据,并能阻止任何中心化机构删除数据,文件存储在不需要相互信任的对等节点上。IPFS 保存文件的每一个版本,这样你将永远不会丢失重要文件,我们将IPFS视为区块链技术的好的补充。除了区块链应用程序外,IPFS还有一个愿景是对现有的网络基础设施进行去中心化重塑。

Resin.io

RESIN.IO 是一个物联网(IoT)平台。虽然只做把容器部署到设备中这一件事,但它做得很好。开发人员使用一个软件即服务( SaaS)的门户来管理设备,并为这些设备分发由 Dockerfile 定义的应用。该平台可以为多种硬件类型构建容器,并通过无线的方式部署容器镜像。Resin.io 使用balena 来管理容器。而balena是一个基于 Mobby 框架的容器引擎,由Docker 出品。该平台仍在开发中,有些功能尚需完善,也缺少一些特性(比如与私有容器注册服务协同工作)。但是目前的特性集(包括从 Web 门户使用 ssh 访问一 个设备上的容器)表明它的未来充满希望。

Knative

作为应用开发者,我们喜欢专心解决核心业务问题,而让底层平台来处理那些枯燥且困难的任务(如部署、容量伸缩及应用程序管理)。虽然无服务器架构往这个方向迈出了一步,然而大多数流行的产品都会与某个专有实现绑在一起。而这意味着供应商绑定。KNATIVE试图以开源无服务器平台的方式来解决此问题。它良好地集成了流行的Kubernetes生态系统。利用 Knative ,可以对随时请求的计算进行建模(其间可以从一些框架中进行选择,如 Ruby on Rails、Django和Spring 等),可以订阅、交付和管理事件,可以集成用户所熟悉的 CI和CD 工具,可以从源代码构建出容器。该平台提供一组中间件组件,来构建以源代码为中心且基于容器(能够实现资源伸缩性)的应用。这使得它成为一个颇有吸引力的平台,当有无服务器需求时,值得对其进行评估。

Apache Atlas

随着企业数据需求的不断增长和多样化,对元数据管理的需求也在不断地增长。APACHE ATLAS 是一款用于满足企业数据治理需求的元数据管理框架。Atlas支持元数据类型建模、数据资产分类、数据来源追踪和数据发现。但是,在搭建元数据管理平台的时候,我们也必须小心避免重蹈主数据管理的覆辙。

Cypress

运行端到端测试时经常会遇到一些棘手的问题,比如运行时间过长,测试过于零碎,还需要修复无头模式下运行的测试所导致的 CI 失败。我们的团队借助 CYPRESS 很好地解决了性能差、响应时间长、资源加载慢等常见问题。Cypress 是一款很有用的工具,可以帮助开发者构建端到端测试,还可以将所有测试步骤保存为 MP4 视频,便于检查错误。

VS Live Share

VISUAL STUDIO CODE 是微软推出的免费 IDE 编辑器,可以跨平台使用。我们曾用它同时进行前端 React、TypeScript 和后端 GoLang 的开发,而无需在不同的编辑器之间切换,体验很好。 Visual Studio Code 中的工具、语言支持和扩展插件数量都在迅猛增长,也越来越好用。我们要特别推荐在实时协作及远程结对编程时使用 VS Live Share 。固然微软或 Jetbrains 成熟的 IDE 对使用静态类型语言(如 Java 、 .NET 或 C++ )的复杂项目支持得更好,但我们也发现 Visual Studio Code 正逐渐成为基础设施开发组和前端开发组的首选工具。

Stanford CoreNLP

越来越多的项目需要处理非结构化的数据,而从文本中提取出有意义的业务信息是一项关键技术。 STANFORD CORENLP 是一组基于 Java 的自然语言处理(NLP)工具集,支持英语、汉语和阿拉伯语等多种语言的命名实体识别、关系抽取、情感分析与文本分类,也提供了用于标记语料库和训练模型的工具。 Stanford CoreNLP 协助我们使用NLP 领域的最新研究成果来解决各种业务问题。

LocalStack

使用云服务时面对的一个挑战是如何在本地进行开发和测试。 LOCALSTACK 为 AWS 解决了这个问题。它提供了各种 AWS 服务的本地 测试替身 实现,包括 S3 、 Kinesis 、Dynamodb 和 Lambda 等。它基于现有的最佳工具如Kinesalite 、 Dynalite 、 Moto 等构建,并增加了进程隔离与错误注入的功能。 LocalStack 的使用很简单,并附带了一个简单的 JUnit 运行器以及 JUnit 5扩展。我们在一些项目中使用过 LocalStack ,并对它印象深刻。

Bitrise

构建、测试和部署移动应用,尤其是由一条流水线从代码仓库打通到应用商店的时候,会涉及许多复杂的步骤。虽然这些步骤可以由脚本或普通 CI/CD 工具提供的流水线自动完成,但对于专注移动应用开发,而不需要与后端的构建流水线做集成的小组来说,使用专用工具可以降低复杂度和维护开销。 BITRISE 配置简单,并预置了一组完整的步骤,可以满足绝大多数移动应用开发所需。

PredictionIO

PREDICTIONIO 是开源的机器学习服务框架。无论是普通开发者还是数据科学家,都可以利用它创建用于预测的智能应用。和所有其他智能应用类似,PredictionIO 由三个部分组成:数据收集和存储、模型训练以及模型部署和服务暴露。开发者只需要基于它提供的相应接口实现数据处理逻辑、模型算法和预测逻辑,无需在诸如存储数据以及训练模型之类的事情上投入额外精力。从我们的经验来看,在不要求高并发处理的情况下,PredictionIO 能支持不同大小的数据集。大多数时候我们使用 PredictionIO 来为中小企业构建预测类智能服务,或者在构建复杂定制化预测引擎的过程中进行概念验证。

Q#

量子计算目前已经可供测试,但何时真正到来尚未明确。在硬件到位之前,我们已经可以通过语言和模拟器来实验和学习它。尽管IBM等公司已经取得了不错的进展,我们对微软在 Q# 语言及其模拟器(本地32量子比特,Azure云上40量子比特)方面的工作更加关注。如果你想开始了解这项编程的前景,请查看他们在 GitHub 上的范例。

MockK

MOCKK 是用 Kotlin 编写的模拟库。它的核心理念是像 Coroutines 和 Lambda 表达式一样,为 Kotlin 提供一等公民级别的语言特性支持。不同于 Mockito 或PowerMock 的蹩脚封装,作为原生的开发库,它能帮助开发团队在测试 Kotlin 应用时编写干净、简洁的代码。

WebFlux

Spring Framework 5 已发布一年有余,它采用了响应式流 —— 一套非阻塞背压(backpressure)式异步流式处理标准。在传统的 Spring MVC 模块之外,WEBFLUX 为在 Spring 生态下编写 Web 应用提供了一个响应式替代品。经过一系列应用的试用,WebFlux 给我们的团队留下了深刻的印象,并汇报说这种响应式(函数式)实现增强了代码的可读性和系统的吞吐量。但他们也确实注意到,采用 WebFlux 需要在思维方式上做出一些重大转变,建议在WebFlux vs. Spring MVC 的技术选型中考虑这一点。

Jepsen

随着 微服务 架构越来越多地被采用,相比以前,我们构建了更多的分布式应用程序。尽管解耦架构带来了许多好处,但证明整个系统正确性所需的工作量和复杂程度正急剧增加。 JEPSEN 提供了许多我们所需要的工具,来帮助我们验证协调任务调度程序的正确性,测试分布式数据库的最终一致性、 线性一致性 ( Linearizability)和 可串行性(Serializability)。我们在一些项目中使用了 Jepsen,令人惊喜的是,我们可以测试驱动配置,注入和修复故障,验证系统恢复后的状态。


以上是我们在最新一卷技术雷达中随机摘取的几个Blip,欲获取整版技术雷达,请点击技术雷达官方网站进行下载!

Share

ThoughtWorks的专业服务模式是否面临颠覆

我们总在说运用颠覆性思想,帮助客户实现他们颠覆性的愿景和业务。回过头来看看我们所从事的业务 – Professional Service,在其悠久的历史当中却一直没有经历太大的模式上的变化。

以大名鼎鼎的麦肯锡为例,自上世纪20年代中期开始,虽然牛人辈出,引导了企业、行业乃至是国家政府的变革,其当下的业务模式仍然跟九十几年前成立时差不太多。

百年长青的业务模式不意味着永远不会被颠覆,科技创新带来的跨界竞争者已经引起金融、零售、旅行等行业的格局剧变。我们立身的业务模式是否还具有持续的生命力呢?让我们从检视ThoughtWorker服务如何创造客户价值出发,尝试验证一下ThoughtWorks能够继续刷存在感所基于的假设吧。

当我们试图去解决客户的一个商业问题,总是要经过数轮发散和聚焦的过程,探测问题的正确定义,并把问题降解为可以分析的对象,然后形成各自的解决方案,最后用技术的手段实现这些解决方案,以达到客户价值的创造。Roger Martin用知识漏斗(Knowledge Funnel)描述知识的演进。这个漏斗模型展示,一个复杂问题的解决需要经过谜题(Mystery)、启发(Heuristic)和算法(Algorithm)三个阶段,我们面临的问题大多处于谜题和启发之间。

我们的不可替代性基于的假设是,我们要解决的问题具有如下几个特点。

  1. 重复性低——定制软件项目中可以算法化的问题,大多已经被套装软件,软件库,以及各自的自动化脚本所解决,ThoughtWorks团队关注的是那些需要依赖上下文来探索、分析的问题。而且问题的解决不仅仅需要分析性的方法,还需要大量社会化的能力,跟各种相关方协作,总是在与人的沟通中遇到不可预测的反应。
  2. 效果模糊性高——软件开发的结果很难度量。我在《精益软件度量》一书里尝试从价值、效率、质量、能力几个维度设计了一套度量体系。结果有读者在豆瓣上评价:“这本书写得很好,看得出作者有很多实践的经验,书中列举的有些案例简直与我看到的一模一样,可是,为什么我看完之后这么绝望呢?! ”其实我写得也挺绝望的,给不出直接答案的感觉挺不爽。正因为如此,客户也很难对我们的服务绩效形成客观有效的评价,以至于在相当程度上不得不依赖品牌和声誉等社会证据,以及跟我们直接接触的直观、主观体验做出判断。
  3. 学习的价值——不管是在一个领域积累,把趟过的坑变成自己的深沉,把伤疤变成勋章,还是把从另一个行业、客户、项目上学到到运用到新的项目上,以他山之石攻玉,ThoughtWorker是业务模式中资产的主体,快速学习的能力让我们能够应对不断变化的客户需求和商业环境,同时,在技术和方法的更新换代中持续获得新的创造价值的能力。
  4. 影响客户对问题的定义——解决摆在面前的问题经常不是最大化价值的方式,我们要看到客户的盲点,发掘更深层次的问题,展现更大的格局和不同的视角。

如果我们的假设遇到挑战,一些征兆就会很直接地浮现在客户的日常反应当中。

  1. 重复性变高,意味着我们工作内容被算法化的可能性增加,这也意味着我们的工作内容被产品化,被机器替代的可能性增加。征兆通常是客户把我们跟产品厂商对比,或是被要求跟产品厂商合作,采用一些成型产品,替代我们方案中定制的部分。
  2. 效果模糊性降低的征兆,一般是客户越来越难以被满足,并且能为其不满提出清晰客观的度量依据;也可能是一些更加专业化的细分竞争对手出现,以承诺精准的目标,将我们挤出竞争。
  3. 学习价值的降低则体现在客户用低成本的竞争对手逐渐替代我们的工作,我们被定位在越来越窄的范围里。因为领域足够成熟,变化足够缓慢,低成本的竞争对手用工具和流程固化了知识,作为学习价值的替代。
  4. 当我们不能影响客户对问题的定义的时候,就发现只能被动响应客户的需求,而即使做了客户要求的事情,客户反而斤斤计较,越来越难以被满足。我们要问问自己,这些征兆是否已经出现。

除了这些客户的反应,外部环境出现的多重挑战,让我们有理由相信,当前业务模式确实会面临时代的冲击。

首先,当今获取知识极为便捷,一招鲜的价值大大降低。很多咨询公司的知识和经验都存放在公司的数据库里,过去凭借几个新名词,攒几个新框架,似乎就能引起客户的兴趣。今天,各种知识在互联网上唾手可得,严肃的客户稍作研究,就能初步验证服务内容的来龙去脉,业界格局,以及未来趋势。

客户日渐成熟,对服务理解更深,因此会在性价比上提出更高的要求。不少客户尝试过多个厂商,久经各种忽悠的考验,甚至有很多客户的高管是从乙方跳槽过去,对厂商策略了如指掌。信息不对称大幅降低,导致缺乏实力支撑的偶像派溢价急剧衰退。

日趋复杂的商业环境使咨询服务出现了分解的趋势,模块化、专业化的服务可能是由术业有专精的服务商提供,而日常重复的工作可以被专业的工具所替代。在这种情况下,如果做的事情缺乏复杂度或缺乏创新,就很容易被算法化。

除此之外,像很多被颠覆的其它行业一样,我们也会面对跨界的竞争者。从高端复杂场景出发,麦肯锡在2007年开始成立了McKinsey Solutions,利用基于软件工具和分析技术等手段,将曾经存在于高管和顾问脑中的隐性的知识和能力转化成固化下来的资产。从低端简单场景出发,阿里钉钉以席卷天下之势迅速获取了一百五十万企业用户。从技术发展的角度来看,虽然MDA(Model Driven Architecture)运动一度甚嚣尘上,但是除了产生了一些华而不实的代码生成工具以外,并没有能走多远,而未来能写代码的人工智能似乎又比较遥远,但是我们还是不能掉以轻心。

最后,还是列出我心中的疑惑,向大家求助。

  1. 我们当前的核心业务是从大型客户那里获得持续性的收入,但颠覆的活动其实是从稍小一些的客户那里发生的。我们的策略是不是先和较小型的客户一起探索新的颠覆性的方法,然后推广到战略性的客户,最终达到推动行业的变革?
  2. 在很多新技术还只是buzz word的时候,我们作为最贴近客户,最贴近商业场景的实践者,如何发挥布道者的作用? 我们是不是应该寻求产品或规模化合作伙伴,主动以产品和流程替代可以算法化的活动,或是自己主动做产品或建立流程,完成这些活动?
  3. 我们是不是应该寻求特殊专业领域的合作伙伴,或是我们自己建立术业有专精的团队,达到服务的模块化,专业化。

或者大家有什么奇葩的脑洞推荐?


推荐阅读

The Design of Business: Why Design Thinking is the Next Competitive Advantage. Harvard Business School Press


点击此处下载MD脑洞-《管理的迷思》完整电子书(请用手机微信打开)

Share

微服务测试的思考与实践

最近几年,微服务架构越来越火爆,逐渐被企业所采用。随着软件架构的变化,对应的软件测试策略需要作何调整呢?本文将介绍微服务架构下的测试策略,并结合分享在业务和架构演变过程中,一个历经九年的项目测试策略的演进。

关于微服务

微服务架构是一种架构模式,它提倡将单一应用程序划分成一组小的服务,每个服务运行在其独立的进程中,服务间采用轻量级通信机制互相沟通(通常是基于HTTP协议的RESTful API)。每个服务都围绕着具体的业务进行构建,并且能够被独立部署到生产环境、预生产环境。

从微服务的概念可以看出它有如下好处:

  • 每个服务可以独立开发
  • 处理的单元粒度更细
  • 单个服务支持独立部署和发布
  • 更有利于业务的扩展

同时,独立开发导致技术上的分离,HTTP通信加上Queue的机制增加了问题诊断的复杂度,对系统的功能、性能和安全方面的质量保障带来了很大的挑战。另外,服务间的复杂依赖关系带来了很多的不确定性,要实现独立部署,对运维也提出了更高的要求。微服务架构的系统要特别关注这几个方面:

  • 服务间的依赖、连通性
  • 服务的容错、可用性
  • 数据的最终一致性
  • 独立部署
  • 不确定性

测试策略的选择

谈到微服务的测试策略,很容易就想到了老马推荐的文章《Microservices Testing》,该文推荐的微服务框架下的测试策略是这样的:

(经典策略模型)

这个策略模型强调测试分层以及每一层的恰当覆盖,整体符合金字塔结构。它是最优的吗?

有人对此提出了质疑…认为策略模型应该是蜂巢形状的(请参考文章):

(蜂巢模型)

这个模型重点关注服务间的集成测试,两端的单元测试和UI层E2E测试较少。

也有同事提出微服务下的测试结构应该是钻石形状的,服务间的集成依然是重点,单元测试较少,而顶层增加了安全和性能等非功能测试。

(钻石模型)

好像都有道理,到底选择什么样的策略模型好呢?不禁陷入了困境……怎么办?不妨先来听听我们项目的故事吧!

项目的故事

测试策略的演进

还是那个蓝鲸项目,不知不觉进入了第九个年头。在这九年里,随着业务的不断发展,系统架构也进行了多次演进和调整。相应的,测试策略也发生了有意思的演进变化。

(测试策略的演进)

最初单一用户系统、单体架构的时候,严格按照测试金字塔来组织各层的自动化测试。随着功能的扩展,大量mock的单元测试给重构带来了很大的不便。

企业系统开始开发的时候,我们调整了策略,减少单元测试的编写,增加UI层E2E测试的覆盖,测试结构由原来的金字塔演变成上面梯形下面倒三角的形式。

后来,架构调整,开始服务化。此时,大量的E2E测试渐渐暴露出问题:

  • CI上的测试执行时间越来越长,而且定位问题的能力很弱,测试一旦失败需要很长时间修复,测试人员好几天也拿不到可以测试的版本,反馈周期过长;
  • 由于服务化带来的不稳定因素增加,E2E测试没法很好的覆盖到需要的场景,测试人员就算拿到可测的版本也总有各种缺陷发生。

因此,项目引入契约测试,停止编写新的E2E测试,将测试下移,分别用API测试和契约测试取代。

随着功能的不断增加,虽然E2E测试的量并不增加,但是其不稳定性、维护难、定位难的问题有增无减,此时已经很难由自动化测试来保证产品的质量。为了平衡成本和收益,项目考虑去掉大部分E2E测试,只保留少量的Smoke测试,将更多的测试下移。

同时,技术雷达上新的技术“生产环境下的QA”出现,项目也开始关心生产环境,并且在QA测试阶段结合微服务的特点进行对应的探索式测试。

应对微服务的挑战

前文提到过微服务带来的挑战,下面来看项目是如何应对这些挑战的。

服务间的依赖、连通性

微服务架构下,独立开发的服务要整合起来最具挑战,如何保证服务间的依赖关系和连通性非常关键。前面已经讲过E2E集成测试有很大的挑战,并不适合,而消费端驱动的契约测试是个不错的选择。项目正是利用契约测试去保证服务间的连通性,取代一部分E2E集成测试。

服务的容错、可用性

在系统负荷达到一定程度或者某个服务出现故障的时候,微服务架构有两种技术来确保系统的可用性:服务的熔断和降级。服务的熔断是指当某个服务出现故障时,为了保证系统整体的可用性,会关闭掉出现故障的服务;服务的降级则是当系统整体负荷过载的时候,考虑关闭某些外围服务来保证系统的整体可用性。

对应的测试包括:

  1. 熔断:从性能角度,当系统负载达到某个熔断状态的时候,服务是否能正确熔断;同时,从功能角度验证熔断后系统的行为是否跟预期相符;
  2. 降级:从业务的角度,要能区分出核心业务和外围业务,在需要降级的时候不能影响核心业务;当某个服务降级后,从功能角度验证系统行为是否跟预期相符。

数据的最终一致性

(数据一致性)

数据一致性是微服务特别需要关注的。举个例子,电商平台某个订单支付成功以后,需要更新积分和订单状态,当订单服务或者积分服务其中有一个出现故障的时候,就会导致最终的数据不一致性。

测试这种情况,从业务的角度分析哪些服务会导致数据不一致性,制造对应的异常情况去测试数据的最终一致性。

独立部署

微服务的独立部署需要有CI、CD的支持,跟DevOps实践分不开。同时,更为关键的是需要契约测试来验证独立部署后服务行为的正确性。项目在这方面的工作,请参考王健的文章:你的微服务敢独立交付吗?

不确定性

微服务架构使得系统复杂度增加不少,很多的事情发生都是不可预测的,只能在其发生以后找到产生的原因。因此,也就没法在预生产环境通过测试去发现在真实生产环境才会发生的issue,我们需要把目光转移到生产环境,利用生产环境的不确定性、微服务的不可预测性来构建反脆弱的系统。

项目在这方面主要采用的技术是生产环境下的QA,请参考文章:生产环境下的QA

项目测试策略

从前面介绍的演进过程可以看到,项目测试策略在不同阶段结合参考了不同的策略模型:金字塔->近似钻石(除非功能测试外,类似于钻石模型)->蜂巢。后期全面服务化的时候,我们认为蜂巢模型是比较适合的。

当然,光有符合这个策略模型的自动化测试是远远不够的,我们项目还采用了针对微服务特点的探索式测试,保持持续交付节奏,践行DevOps实践,结合生产环境下的QA等技术把关注点右移到生产环境。

现在,项目整体测试策略演变成下图的形式:

(项目测试策略)

  1. 项目采用的是敏捷迭代开发和持续交付的模式,每四周一个发布周期。
  2. 在开发过程中实现的自动化测试是分层实现的:底层少量的单元测试,中间量最多的是API测试(类似于老马策略模型里的组件测试),上面有一部分契约测试和少量的Smoke测试来保证服务间的契约和集成。除此之外,QA有手动的探索式测试,其中包括针对微服务特点进行的一些测试。整个测试结构是类似于蜂巢模型的。
  3. 采用生产环境下的QA技术,利用生产环境,进行error监控、用户行为分析、用户反馈收集,从而来影响和指导预生产环境的开发和测试工作。
  4. 利用DevOps实践,做到高效的部署和监控,跟生产环境下的QA结合,形成良性的环路,保证项目的正常交付。

测试策略再思考

项目上多次测试策略的调整,看似很简单,其实每次调整并不是一个轻松的过程,都是平衡利弊、综合考虑多个因素才做出的决定。

分析整个调整过程,最后突然发现:当我们面对多个策略模型不知道如何选择的时候,其实我们陷入了一个太过于关注测试结构的误区,忘记了最初的目标是什么。

影响测试策略的因素

跳出误区,回到原点,重新思考测试策略的目标。影响策略的最关键因素是业务价值、质量要求、痛点。

(影响测试策略的因素)

业务价值

带来更大的业务价值、帮企业赢得更多的利润,是软件系统的目标;软件测试是软件系统成功的保障之一,业务价值也是测试策略的终极目标。所有测试活动都要围绕这个目标开展,考虑业务优先级,有效规避业务风险。

质量要求

不同的系统、同一系统的不同利益干系人(参与的不同角色)对于质量的定义和要求都可能是不同的,这毫无疑问是影响测试策略的一个关键因素。

对于仅有内部用户的系统,关注的重心可能是系统的功能;而对外发布的产品,则要求更高,一个按钮位置的不恰当都可能带来大量用户的流失。

痛点

真正的痛点往往也是优先级最高,迫切需要解决的。那些可以通过测试策略的调整来解决的痛点,自然成为了关键的影响因素之一。比如,CI Pipeline出包太慢,为了提高出包的效率,一方面在Pipeline本身想办法,另一方面调整自动化测试的比例、执行频率等也是解决方案之一。

演进式测试策略

处在不同阶段的项目,在业务价值这个大目标下,其他影响因素也是会不一样的,跟技术架构的演进一样,测试策略也应该是演进式的。

从目标出发,综合所处阶段各个方面的影响因素,制定出适合当时的测试策略。随着时间的推移,对策略进行评估和度量,并进一步改进、提高,以更好的满足需求。这就是目标驱动的演进式测试策略。

(演进式测试策略)

总结

微服务架构下多个服务的整合是最具有挑战的,对此最重要的是契约测试。契约测试有效保证服务间的契约关系不被破坏,确保服务的连通性,有助于实现真正的独立部署和独立交付。

微服务架构引入的不确定性并不是坏事,可以利用这些不确定性,采用生产环境下的QA等技术,增强系统的反脆弱性,从中获益。

测试策略的影响因素不是唯一的,技术架构并不是最关键的因素。微服务架构下的测试策略跟其他架构下的并不会有本质的区别。

业务价值始终是我们的终极目标。在这个终极目标的驱动下,测试策略不是制定完了就可以束之高阁的,需要在整个软件系统构建过程中不断的度量和改进,是演进式的。


更多精彩洞见,请关注微信公众号:思特沃克

Share