人件 – 是什么在阻塞智能与智能化进程

智能进程与智能化进程

《人件》作者汤姆·迪马可、蒂姆·李斯特在他们的书中,曾推崇人本管理思想,指出知识型企业的核心是人,而不是技术。而今天我希望从智能系统设计的角度,讨论一些“人件”相关的设计陷阱。

如果说“I/O(输入/输出)”是阻塞“系统进程”的最主要原因,那么在“智能进程”中,“人件”即“I/O”,它也常常阻塞智能进程的执行。在企业智能化过程中,通过重新设计人机交互,规避“人件”带来的效率阻塞,已经越来越常见,例如RPA(机器流程自动化)就是一种常见的技术方向,将原有的人工操作,转化为机器人自动流程,以提高流水线效率。而另一方面,过多地规避“人件”甚至完全去除“人件”,也可能因此错过许多智能化的推进机会,例如难以积累足够的原始数据和标注数据训练集,用于监督学习和模型测试。

因此企业智能化的核心问题之一,就是如何巧妙地取舍人在系统中所扮演的角色。Intelligence process(智能进程)与Intelligence empowerment process(智能化进程),这两者之间,存在着一些方向上的矛盾,也需要精心的设计来平衡两个目标,下面的几个例子,会着重谈谈观察到两者的矛盾点和一个常见的重构设计思路。

智能客服的数据采集难题

“智能客服”是AI技术的一个常见应用场景,非常多的企业在构建智能客服的过程中,几乎无一例外地面临一个难题,“数据从哪里来?”,我们发现在很多企业中,由于效率优先的人机设计,数据常常采用结构化的方式采集而来,而丢失原始数据,这无疑给智能化进程增加了难度。

例如,ThoughtWorks的请假系统在设计初期,支持员工通过Email直接发送请假邮件。系统中设计了简单的NLP模式识别,用于将文字转换为信息。原有流程为:(其中圆括号内的模块为智能化模块,而方括号的部分则是人件)

而由于HR频繁修正标注带来的工作量问题,现有的系统被设计成了如下的流程:

我们可以看到请假系统效率的提升,是来自人机交互的重新设计减少了软件中的人件模块。

但是从另一方面看,由于不再积累原始数据,我们错失了训练模型的机会,因而原本计划的“发个短消息请假”、“使用微信语音请假”的宏远目标也遭遇了滑铁卢。

针对这样的矛盾,我们看到在某些系统中,别出心裁地设计了巧妙的流程来采集原始数据。

例如Expensify提供了SmartScan功能,用户可以将发票上传至服务器进行OCR图像识别,完成数据结构化。而为了避免该功能完全阻塞用户提交报销申请的流程,Expensify同时也保留了结构化数据表单,鼓励用户对不准确的图像识别结果进行人工标注。

通过这样的巧妙设计Expensify完成了一个完整的“智能化”反馈环,并解决了智能进程阻塞的问题。

类似的重构设计有很多,它的一个常见思路,就是在保证原有进程效率的同时,非侵入地改变“人件”在系统中扮演的角色,例如将“数据填充者”,通过修正表单工具的支持,转变为“数据修缮者”,通过职能的转变,优化智能化反馈环。

去中心系统运营中的投票难题

EOS曾经是史上最大的ICO,也是号称采用性能最好DPOS共识的区块链之一,它通过投票的方式选举出21个节点,并在其之上构建起具有超高TPS的分布式账本。

然而,恰恰是这样一个设计了各种高效机制的系统,在主网上线的过程中,让众多超级节点头疼的问题,竟然是让社区引以为傲的“投票”机制:尽管EOS拥有非常多的投资人,最初却只有15%不到的用户知道应该如何使用交易所购买的通证参与超级节点的票选,而社区需要花费大量的人力物力,“去中心地”教育每一个用户,应该如何操作提币、使用钱包投票等事宜。

尽管如此,我们依然欣慰地看到EOS的社区有着远大的愿景,以吸引更多个体参与到社区运作和账本背书当中,避免传统POW机制下的算力集中带来的安全隐患和信任问题。

EOS保留了传统区块链的work-in机制,并且将其放大到整个社区运作当中,而几乎完全抛弃了don’t make me think的设计方向,因而实际的运转中,“投票”处处阻塞着平台的智能进程,这很类似《人件》这本书中谈到的“会议上瘾”,过多的人工决策点严重影响着运营效率。

在设计同样致力于群体性智慧的“雷达网络”时,我也在寻找一些手段来减少这种低效的沟通,使用一些智能模块来替代掉一部分重复劳动,包括按照媒体曝光度输出技术候选项列表等,并设计更顺畅的反馈环,让参与者在享受服务的同时,也可以贡献到智能化进程中。

人件的价值

最近的两年里,非常多的文章开始鼓吹智能化带来的颠覆性变化,甚至出现了非常多的“抛弃体”,像《人工智能干掉金融民工,他们是第一批被赶走的北漂》、《初中生已经会用人工智能识别水果了,你孩子的同龄人正在抛弃你》等等,仿佛社会对于一部分人员职责的定义已经变成了一种“有机验证码识别机”。

诚然,现实也确实如此,非常多的l工种都正被数字化、智能化浪潮影响到,而不管是《人件》中强调的人应该专注在知识与价值创造,还是《增强人类》中的利用科学技术克服人体局限性的想法,都在反复呼吁一件事,就是关注人在整个生态或系统中发挥的作用,和其本身的诉求。

我们渴望看到人类在系统中,经由设计的改良,不断发挥更大的价值,而非沦为智能化进程中的阻塞或可替代品。人类可以也应当驾驭智能,只因智能本就是人类的造物。

Share

中台是个什么鬼 | 白话中台战略

从去年开始,好像就有一只无形的手一直将我与“微服务”、“平台化”、“中台化”撮合在一起,给我带来了很多的困扰和思考与收获。

故事的开始源于去年的技术雷达峰会,我在会上做了一场关于平台崛起的主题分享(《The Rise of Platform》),这场分享主要是从技术的层面从Global的视角介绍了平台化的兴起,以及分享从基础设施到人工智能等各个领域不断涌现的各类平台,以及平台化对于软件开发人员及企业的影响。

(2017技术雷达峰会)

记得当时在做演讲彩排的时候,有同事就提到过,在中国提“数字化平台战略”可能大家会觉得比较抽象比较远大空,如果你提“中台”大家会更熟悉一些。

而这也是我第一次听到“中台”这个词,原来除了我们熟悉的“前台”和“后台”外,居然还有个“中台”这样一个神奇的存在。

那…… 中台到底是什么?会不会又是另一个Buzzword呢?这个从名字上看像是从前台与后台中间硬挤出来的新断层,它与前台和后台的区别和界限到底在哪儿?什么应该放到中台,什么又应该放到前台或是后台?它的出现到底是为了解决什么问题呢?

从那时开始,一个接一个的问题就不断的涌出并萦绕在我的脑子里。直到一年多后的今天,随着参与的几个平台化、企业中台相关的项目已经顺利地步上了正轨,终于可以坐下来回顾一下这一年的实践与思考,再次试图回答这些问题,并梳理成文,与大家交流探讨。

中台迷思

到处都在喊中台,到处都是中台,中台这个词在我看来已经被滥用了。

  • 在有些人眼里:中台就是技术平台,像微服务开发框架、Devops平台、PaaS平台,容器云之类的,人们都叫它“技术中台”。
  • 在有些人眼里:中台就是微服务业务平台,像最常见的什么用户中心,订单中心,各种微服务集散地,人们都叫它“业务中台”。
  • 在有些人眼里:中台应该是组织的事情,在释放潜能:平台型组织的进化路线图 (豆瓣)中就提出了平台型组织和组织中台的概念,这类组织中台在企业中主要起到投资评估与投后管理的作用,类似于企业内部资源调度中心和内部创新孵化组织,人们叫它“组织中台”

看完本篇你就会理解,上边的这几类“中台”划分还是靠谱的,更多我看到的情况是大家为了响应企业的“中台战略”,干脆直接将自己系统的“后端”或是“后台”改个名,就叫“中台”。

中台到底是什么?它对于企业的意义到底是什么?当我们谈中台时我们到底在谈些什么?

想要寻找到答案,仅仅沉寂在各自“中台”之中,如同管中窥豹,身入迷阵,是很难想清楚的。不如换个 ⾓度,从各类的“中台迷阵”中跳脱出来,尝试以更高的视角,从企业均衡可持续发展的角度,来思考中台的价值,来试图反推它存在的价值。

所以,为了搞明白中台存在的价值,我们需要回答以下两个问题:

  1. 企业为什么要平台化?
  2. 企业为什么要建中台?

第一个问题:企业为什么要平台化?

先给答案,其实很简单:

因为在当今互联网时代,⽤户才是商业战场的中心,为了快速响应用户的需求,借助平台化的力量可以事半功倍。

不断快速响应、探索、挖掘、引领⽤户的需求,才是企业得以⽣存和持续发展的关键因素。

那些真正尊重用户,甚⾄不惜调整⾃己颠覆⾃己来响应⽤户的企业将在这场以⽤户为中心的商业战争中得以⽣存和发展;⽽反之,那些在过去的成就上故步⾃封,存在侥幸⼼理希望⽤户会像之前一样继续追随⾃己的企业则会被用户淘汰。

很残酷,但这就是这个时代最基本的企业⽣存法则

数字化企业

⽽平台化之所以重要,就是因为它赋予或加强了企业在以用户为中心的现代商业战争中最最最核心的能力:⽤户响应力。这种能力可以帮助企业在商战上先发制⼈,始终抢得先机。

可以说,在互联网时代,商业的斗争就是对于用户响应力的比拼。

又有点远大空是不是,我们来看⼏个经典的例子:

1.说起中台,最先想到的应该就属是阿⾥的“⼤中台,⼩前台”战略。阿⾥⼈通过多年不懈的努力,在业务的不断催化滋养下,将⾃己的技术和业务能力沉淀出一套综合能力平台,具备了对于前台业务变化及创新的快速响应能力。

(阿里中台)

2.海尔也早在⼗年前就已经开始推进平台化组织的转型,提出了“平台⾃营体⽀撑⼀线⾃营体”的战略规划和转型⽬标。构建了“⼈单合一”、“⽤户付薪” 的创客文化,真正将平台化提⾼到了组织的⾼度。

(海尔组织中台)

3.华为在几年前就提出了“⼤平台炮火支撑精兵作战”的企业战略,“让听得到炮声的人能呼唤到炮火” 这句话形象的诠释了大平台⽀撑下小前台的作战策略。这种极度灵活又威力巨⼤的战法,使之可以迅速响应瞬息万变的战场,一旦锁定目标,通过大平台的炮火群,迅速精准对于战场进行强大的火⼒支援。

(⼤平台炮火支撑精兵作战)

可⻅,在互联⽹热火朝天,第四次工业革命的曙光即将到来的今日,企业能否真正做到“以用户为中心”,并不断提升自己的用户响应力来追随甚至引领用户的脚步,持续规模化创新,终将决定企业能否在这样充满挑战和机遇的市场上笑到最后,在商业上长久保持创新活力与竞争力。

(数字化平台战略)

而平台化恰好可以助力企业更快更好的做到这些,所以这回答了第一个问题,企业需要平台化。

第二个问题:企业为什么要建中台?

好,想明白了第一个问题,为什么需要平台化。但是平台化并不是一个新概念,很多企业在这个方向上已经做了多年的努力和积淀。那为什么最近几年“中台”这个相对较新的概念又会异军突起?对于企业来讲,传统的“前台+后台”的平台化架构又为什么不能满足企业的要求呢?

好,这就引出了我们的第二个问题:企业为什么要建中台?

来,先定义一下前台与后台

因为平台这个词过于宽泛了,为了能让大家理解我在说什么,我先定义一下本篇文章上下文下我所说的前台和后台各指什么:

  • 前台:由各类前台系统组成的前端平台。每个前台系统就是一个用户触点,即企业的最终用户直接使用或交互的系统,是企业与最终用户的交点。例如用户直接使用的网站,手机App,微信公众号等都属于前台范畴。
  • 后台:由后台系统组成的后端平台。每个后台系统一般管理了企业的一类核心资源(数据+计算),例如财务系统,产品系统,客户管理系统,仓库物流管理系统等,这类系统构成了企业的后台。基础设施和计算平台作为企业的核心计算资源,也属于后台的一部分。

后台并不为前台而生

定义了前台和后台,对于第二个问题(企业为什么要建中台),同样先给出我的答案:

因为企业后台往往并不能很好的支撑前台快速创新响应用户的需求,后台更多解决的是企业管理效率问题,而中台要解决的才是前台的创新问题

大多数企业已有的后台,要么前台根本就用不了,要么不好用,要么变更速度跟不上前台的节奏。

我们看到的很多企业的后台系统,在创建之初的目标,并不是主要服务于前台系统创新,而更多的是为了实现后端资源的电子化管理,解决企业管理的效率问题。这类系统要不就是当年花大价钱外购,需要每年支付大量的服务费,并且版本老旧,定制化困难;要不就是花大价钱自建,年久失修,一身的补丁,同样变更困难,也是企业所谓的“遗留系统”的重灾区。

总结下来就两个字“慢”和“贵”,对业务的响应慢,动不动改个小功能就还要花一大笔钱。

有人会说了,你不能拿遗留系统说事儿啊,我们可以新建后台系统啊,整个2.0问题不就解决了。

但就算是新建的后台系统,因为其管理的是企业的关键核心数据,考虑到企业安全、审计、合规、法律等限制。导致其同样往往⽆法被前台系统直接使用,或是受到各类限制⽆法快速变化,以⽀持前台快速的创新需求。

此时的前台和后台就像是两个不同转速的⻮轮,前台由于要快速响应前端用户的需求,讲究的是快速创新迭代,所以要求转速越快越好;⽽后台由于⾯对的是相对稳定的后端资源,⽽且往系统陈旧复杂,甚至还受到法律法规审计等相关合规约束,所以往往是稳定至上,越稳定越好, 转速也自然是越慢越好。

所以,随着企业务的不断发展,这种“前台+后台”的⻮轮速率“匹配失衡”的问题就逐步显现出来。

随着企业业务的发展壮大,因为后台修改的成本和⻛险较⾼,所以驱使我们会尽量选择保持后台系统的稳定性,但还要响应用户持续不断的需求,自然就会将大量的业务逻辑(业务能力)直接塞到了前台系统中,引入重复的同时还会致使前台系统不断膨胀,变得臃肿,形成了一个个⼤泥球的“烟囱式单体应用”。渐渐拖垮了前台系统的“⽤户响应⼒”,用户满意度降低,企业竞争力也随之不断下降。

对于这样的问题,Gatner在2016年提出的一份《Pace-Layered Application Strategy》报告中,给出了一种解决方案,即按照“步速”将企业的应用系统划分为三个层次(正好契合前中后台的三个层次),不同的层次采用完全不同的策略。

而Pace-Layered Application Strategy也为“中台”产生的必然性,提供了理论上的支撑。

Pace-Layered Application Strategy

(Gatner: Pace-Layered Application Strategy)

在这份报告中Gatner提出,企业构建的系统从Pace-Layered的⾓度来看可以划分为三类: SOR(Systems of record ),SOD(Systems of differentiation)和SOI(Systems of innovation)。

处于不同Pace-Layered的系统因为⽬的不同,关注点不同,要求不同,变化的“速率”自然也不同,匹配的也需要采⽤不同的技术架构,管理流程,治理架构甚至投资策略。

⽽前面章节我们提到的后台系统,例如CRM、ERP、财务系统等,它们⼤多都处于SOR的Pace-Layered。这些系统的建设之初往往是以规范处理企业底层资源和企业的核⼼可追溯单据(例如财务单据,订单单据)为主要⽬的。它们的变更周期往往比较⻓,⽽且由于法律律审计等其他限制,导致对于它们的变更需要严谨的申报审批流程和更高级别的测试部署要求,这就导致了它们往往变化频率低,变化成本高,变化⻛险高,变化周期⻓。⽆法满⾜由⽤户驱动的快速变化的前台系统要求。

我们又要尽力保持后台(SOR)系统的稳定可靠,⼜要前台系统(SOI)能够⼩而美,快速迭代。就出现了上文提到的”齿轮匹配失衡“的问题,感觉鱼与熊掌不可兼得。

正当陷入僵局的时候,天空中飘来一声IT谚语:

软件开发中遇到的所有问题,都可以通过增加⼀层抽象⽽得以解决!

⾄此,⼀声惊雷滚过,“中台”脚踏七彩祥云,承载着SOD(Systems of differentiation) 的前世寄托,横空出世。

中台才是为前台而生

我们先试着给中台下个定义:

中台是真正为前台而生的平台(可以是技术平台,业务能力甚至是组织机构),它存在的唯一目的就是更好的服务前台规模化创新,进而更好的响应服务引领用户,使企业真正做到自身能力与用户需求的持续对接。

中台就像是在前台与后台之间添加的⼀组“变速⻮轮”,将前台与后台的速率进行匹配,是前台与后台的桥梁。它为前台而生,易于前台使用,将后台资源顺滑流向用户,响应用户。

中台很像Pace-Layered中的SOD,提供了比前台(SOI)更强的稳定性,以及⽐后台(SOR)更高的灵活性,在稳定与灵活之间寻找到了⼀种美妙的平衡。

中台作为变速齿轮,链接了用户与企业核心资源,并解决了配速问题

有了“中台”这⼀新的Pace-Layered断层,我们即可以将早已臃肿不堪的前台系统中的稳定通用业务能力“沉降”到中台层,为前台减肥,恢复前台的响应⼒;又可以将后台系统中需要频繁变化或是需要被前台直接使用的业务能力“提取”到中台层,赋予这些业务能力更强的灵活度和更低的变更成本,从而为前台提供更强大的“能力炮火”⽀援。

所以,企业在平台化的过程中,需要建设自己的中台层(同时包括技术中台,业务中台和组织中台)。

总结

思考并回答了文初提出的两个关于中台价值的核心问题,解决了我对于中台产生的一些困惑,不知道对你有没有启发,让我最后再来总结一下:

  • 以用户为中心的持续规模化创新,是中台建设的核心目标。企业的业务响应能⼒和规模化创新能力,是互联⽹时代企业综合竞争⼒的核⼼体现。平台化包括中台化只是帮助企业达到这个目标的⼿段,并不是⽬标本身。
  • 中台(⽆论是技术中台、业务中台还是组织中台)的建设根本上是为了解决企业响应⼒困境, 弥补创新驱动快速变化的前台和稳定可靠驱动变化周期相对较慢的后台之间的⽭盾,提供⼀个中间层来适配前台与后台的配速问题,沉淀能⼒,打通并顺滑链接前台需求与后台资源,帮助企业不断提升用户响应⼒。
  • 所以,中台到底是什么根本不重要,如何想方设法持续提高企业对于⽤户的响应⼒才是最重要的。⽽平台化或是中台化,只是恰巧走在了了这条正确的⼤道上。

PS: 本文是《白话中台战略》的第一篇,后续还打算继续写,总结分享介绍从问题到解决方案,从技术到业务到组织的一些实践经验。会涉及到企业技术中台规划,业务中台规划,遗留系统微服务化改造落地一系列内容,先立个Flag,希望大家看后能给一些反馈,谢谢。


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

Share

Autonomous bubble pattern | 雷达哔哔哔

写在前面

ThoughtWorks每年都会出品两期技术雷达,这是一份关于科技行业的技术趋势报告,在四个象限:技术、平台、工具以及语言和框架对每一个条目(Blip)做采用、试验、评估、暂缓的建议。(第十九期雷达已发布,可至官网下载

一直以来,我们都未对每一个Blip做进一步的解读,而这次决定尝试一个新的专栏——《雷达哔哔哔》,由作者根据自己实践与理解,对雷达中部分条目作出解析,致力于用一篇篇短小精悍的文字,帮助读者加深对雷达的理解。

今天是《雷达哔哔哔》的第四篇,依然关注架构,Blip是Autonomous bubble pattern

位置

2018年5月第18期技术雷达,技术象限,建议试验

标签

遗留系统、DDD、Bounded Context、ACL、Eric Evans

目标受众

系统架构师

关注问题

如何在遗留系统上继续保持构建新功能的能力,不受自身的限制与拖累,可以采用全新的架构甚至工程方法,同时保持相对独立的快速演进?

解决方案:

将新的功能和能力封装到新的独立上下文中,建立独立且完全自主控制的数据存储,采用同步的机制保证与其他上下文的数据一致性,形成完整独立的Autonomous bubble,用同步复杂性换取上下文完整性。

解读

之前在介绍Architectural fitness function时,我们谈到无论一个系统初建时多么新潮且纯粹,都会随着时间的洗礼,慢慢成熟,慢慢衰老,就像我在《技术的一生》中描述的场景一样。

碰到这种情况,我们通常会首先想到推倒重建,希望可以重回初生时的美好。但往往斥重金重建系统、短暂享受重获新生的喜悦之后,依然无法逃离时间和需求的侵浊,再一次走向衰老,成为另一个崭新的遗留系统。

有没有两全其美的方法,既能保持对于遗留系统足够敬畏,不用花费大量成本冒风险重建;又能应用新的技术和架构甚至工程方法为系统构建新的功能和能力,在老树上开出“新花”?

我们发现DDD(Domain-Driven Design)的作者Eric Evans早在2012年就提出的一种叫做Autonomous bubble pattern(自治气泡模式)的模式,对于解决这样的问题越来越有其用武之地。

这种模式乍一看,并无新奇之处,无非就是为新的功能或是应用创建一个新的限界上下文(Bounded Context),在新的上下文里采用全新的设计,并通过Anticorruption Layer(ACL:防腐层)匹配旧的遗留系统而已,常见的应用场景就像Eric Evans在视频中展示的一样:

但Eric Evans提出的Autonomous bubble pattern并不止于此。 精妙之处在于,他提出了另一种看似更复杂的解决方式,即为新的上下文提供完整的数据存储能力。并通过同步(Synchronizing)的方式保持新的上下文与遗留系统中的数据一致性,如下图。

Eric Evans在视频中也坦言,这种方式相比与第一个方案会更加“昂贵”,需要一些额外的工作来处理开发者们最为头疼的“同步”问题。

但我们认为由此带来的“上下文自主性”和“对于开发摩擦力(development friction)的减少”,是迈向现代化甚至未来架构的第一步,也是重要且勇敢的一步。

支持工具:

DDD

延展阅读:


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

Share

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

随着持续集成,持续交付等理念的传播,很多软件开发团队都搭建了自己的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