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

智能进程与智能化进程

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

如果说“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

微网关与服务啮合

技术雷达:现在越来越多的大型组织在向更加自组织的团队结构转型,这些团队拥有并运营自己的微服务,但他们如何在不依赖集中式托管的基础架构下,确保服务之间必要的一致性与兼容性呢?为了确保服务之间的有效协作,即使是自组织的微服务也需要与一些组织标准对齐。服务啮合(SERVICE MESH)在服务发现、安全、跟踪、监控与故障处理方面提供了一致性,且不需要像API网关或ESB这样的共享资产。服务啮合的一个典型实现包含轻量级反向代理进程,这些进程可能伴随每个服务进程一起被部署在单独的容器中。反向代理会和服务注册表、身份提供者和日志聚合器等进行通信。通过该代理的共享实现(而非共享的运行时实例),我们可以获得服务的互操作性和可观测性。一段时间以来,我们一直主张去中心化的微服务管理方法,也很高兴看到服务啮合这种一致性模式的出现。随着linkerd和Istio等开源项目的成熟,服务啮合的实现将更加容易。

新瓶旧酒还是厚积薄发?

对于持续关注云服务架构设计最新发展趋势的同学来说,刚过去的2017年,最火的词莫过于CNCF了,这是一个专注于“云原生”(Cloud Native)的基金会,由众多战斗在云服务一线的公司(包括了谷歌、AWS、阿里云等等)组建而来,旨在推进云原生的架构标准化与最佳实践的普及。

而在最近一期的技术雷达中,“云原生”(Cloud Native)和 “微服务”(Microservices)也引出了许多相关的技术,随着 Kubernetes、Docker 等一众容器管理工具的普及,我们也看到在容器的内部,微服务的架构设计也发生着一些变化,其中“服务啮合”(Service Mesh)就成为了大家关注的热点。

那么这些变化到底是新瓶旧酒,还是厚积薄发?我们不妨先从一个更耳熟能详的架构——“网关”(Gateway)谈起。

网关(Gateway)的作用

作为微服务工具链中的元老,“网关”(Gateway) 的引入为微服务API提供统一的入口和平台,不同的服务可以得到一致的管理。使用网关的架构可以减少企业大量的重复开发。甚至有一些通用的逻辑也可以使用网关来承载(如Zuul、Enovy、OpenResty等)。

不论初心为何,这些网关们随着时光流转,功能也变得越来越丰富,网关可以负责解决不同服务的服务注册发现、负载均衡、配额流控、监控日志、缓存加速、配置分离、安全管控、跟踪审计等问题。这一系列的功能,我们可以大致分为两类:“数据面”和“控制面”。

数据面(Data Plane)负责在数据包粒度上进行筛选和处理

  • 路由转发
  • 负载均衡
  • 安全通信
  • 缓存加速
  • 认证鉴权
  • 日志审计
  • 健康检查
  • 熔断限流

控制面(Control Plane)负责在服务粒度上进行统筹和管理

  • 注册发现
  • 配置管控
  • 弹性伸缩
  • 统筹遥测
  • 容错自愈
  • 策略执行
  • 证书签发

这一系列的功能,就是网关面临的问题域。在了解问题域之后,让我们回归本篇的主题:继承了“网关”(Gateway)衣钵的“微网关”(MicroGateway)和“服务啮合”(Service Mesh),它们到底是什么?

什么是微网关?

随着微服务的普及,传统的中心化网关变得越来越厚重,由于与中心化节点通信,带来了大量网络、IO开销以及单点问题,往往无法满足我们对于实时性、高可用的要求。另外越来越多的自治化需求,与原有集权式微服务治理方法之间,也产生出许多冲突矛盾。因此,与微服务化相适应的,可以本地化、分布式部署的微网关(MicroGateway)也逐渐涌现出来。

什么是服务啮合?

服务啮合(Service Mesh)是一种为了保证“服务到服务”的安全、快速和可靠的通信而产生的基础架构层,区别于应用层、通信层的一种新的云原生上下文内的抽象层。如果你正在构建云原生的应用程序,在微服务拓扑结构日益复杂的今天,服务啮合层的提出,可以帮助开发者将服务的交互通信问题与微服务内部的业务问题隔离开来,专注于各自的领域。

演进中的微网关与服务啮合

当我们了解到微网关与服务啮合的作用之后,就可以一起来看一下微网关与服务啮合架构是如何一步步设计出来的。

低侵入性组件(Low-Invasive Component)

最初的服务间互访,常常由于业务尚不清晰,给标准化带来了障碍。因此我们常常见到一些由领域专家提供的低侵入性的组件,为服务的开发者提供抽象的规范,使其能轻松获得定制化能力。

组件可以更好地规范问题,并且尽可能地将组件封装为简单的接口,早期的服务发现常常通过该类方式实现,例如 Eureka 套件通过引入 Client 来获得完整的如报告、监控、熔断等能力。

我们在一些 IAM (Identity Access Management)的服务设计中采用了这种模式,为各个业务服务提供了一致的认证鉴权接口,由领域专家驱动,设计规范化的调用模式。由于该类组件尽可能设计为低侵入性的接口,因此微服务团队也可以更加便利地根据不同场景取舍是否使用该组件提供的功能,例如通过配置文件加 feature toogle 简单地在开发环境中关闭认证鉴权的功能,以加快开发进程。

反向代理(Reverse Proxy)

随着服务成熟度的提高,我们可以发现一些常见的非业务强相关的逻辑,可以从原有的服务中剥离出来,通过反向代理统一进行过滤处理。

反向代理,可以为微服务处理请求的前后环节增添通用逻辑,例如 apigee 提供的 API proxy 封装,通过反向代理模式为原有的服务添加 PreFlow、PostFlow,解决请求生命周期前后常见的问题,例如检查配额和记录调用频度,对 CORS 等 Http Header 的添加和消费,这些功能有些类似于传统的 Filter 模型,但是却可以独立部署。

反向代理可以提供更高的可用性,并帮助微服务开发者从这些常见细节中解脱出来。

侧车模式(Sidecar Pattern)

准确来说,侧车模式(Sidecar Pattern)本身并非微网关或者服务啮合技术独有,它只是一种特定的软件模块共生关系。侧车模式可以是一个反向代理,也可以作为一个服务存在。

作为反向代理使用的Sidecar进程可以过滤请求与返回内容,实现如安全通信、认证鉴权、服务端/客户端负载均衡、自动路由等功能。

作为服务使用的Sidecar进程可以为主服务提供额外能力,实现分布式缓存同步、配置文件拉取、日志搜集等功能。

侧车模式常见于分布式缓存和安全基础设施网关,通过与微服务进程共同启停的服务或容器,可以更方便地与微服务一并调度,享受微服务管理平台本身提供的服务发现、注册、配置、扩容能力。通过共享生命周期,在简单部署和灵活应用中寻找一个平衡

我们在微服务框架 Jhipster 提供的基础能力中,可以直接通过注解使用 Hazelcast 的分布式缓存,正是通过 Sidecar 模式实现的,拥有共生的分布式缓存实例后,可轻松实现服务接口的缓存,而分布式缓存自身的同步策略等问题都被封装在 Sidecar 进程中,无需开发者花费大量时间重新开发和调试。Sidecar也可以用于实现例如OAuth等安全相关的守护服务,帮助微服务处理业务界限外的专项问题。

原生的基础设施(Native Infrastructure)

服务啮合带来的最大的不同就是原生无感知,通过侧车模式部署的反向代理,与一些容器系统级的配置结合,更彻底地解决微服务在数据面与管理面的能力一致性问题。

服务啮合框架 Istio 提供了 Istio-Initializer 和 istioctl 工具,你可以在Kubernetes的容器整备过程中,注入所需的配置和 Envoy 容器,将Sidecar Proxy、Sidecar Service注册为容器集群中的原生服务,可以在享受弹性部署的同时,享受数据面和控制面协同提供的标准化能力。无痛地加入Istio提供的功能,如 iptables 代理转发、双向TLS认证、限流策略、日志收集等等。

图片来自:http://t.cn/RETWzGV

我们在设计服务啮合层时也可以考虑使用更原生的服务组织与部署策略,例如将微服务容器注册为系统服务、通过控制流对容器进行编排、尽可能与微服务共享生命周期和运行环境来提高可用性与性能等等。

从现在开始,拥抱微服务的云原生生态

既是新瓶旧酒,又是厚积薄发,云原生趋势下的微服务也在不断的演进,逐渐变成我们最初希望的“会呼吸”的模样。我们建议您考虑在一些适用的场景,尤其是微服务化的架构设计中,考虑使用微网关与服务啮合,并总结最佳实践与我们交流。

让我们一起期待云原生生态下的微服务,为数字化时代提供更多的想象力。


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

Share

去中心化组织的三大生产力与康威逆定律

针对国有企业改革,2015年国家提出了“要有利于国有资本保值增值,有利于提高国有经济竞争力,有利于放大国有资本功能”的“三个有利于”标准。这三大标准映射到国有组织的生产力层面,就成为了对国企的价值力、竞争力与控制力这三大生产力提升的要求和挑战。

而在其他组织结构的背景下,我们可以观察到去中心化组织也面临着广泛的价值力、竞争力与控制力相互制约的问题,如何平衡三者,在组织价值上达成共识、激励组织的竞争意识、控制组织的发展方向,无疑是组织规模化过程中必须考虑的问题。在ThoughtWorks最近的邮件列表和领导会议中,我们自驱动的管理者们也在努力地谈这三点,而我希望在本文中,从康威逆定律谈谈怎么在技术层面上度量去中心化组织的成熟度,并且思考如何影响组织,帮助组织完成这三大生产力的增长。

价值力与共识分叉Value force and Consensus Forking

去中心的共识一旦形成,在技术层面上是难以全局更新的。这也可以映射到区块链的分叉问题,当价值判断发生了分歧,就需要通过共识分叉的方式进行大规模的组织演进。

以太坊对于“code as law”信条在DAO盗窃事件的道德考验下,最终形成了两派不可调和的共识分叉。尽管共识分叉会导致组织的短时间分化,却并不一定会导致组织消亡、削弱,它也有可能会使得分化后的“微组织”内部各自的价值点认同感更坚定,成为更focus的“微组织”。

去中心化组织在识别价值的过程中,决定了最长远的组织愿景,在组织愿景的最初基调下,组织领导者、组织参与者与市场的价值博弈,常常会在相对模糊的边界下达成共识。例如,在ThoughtWorks的背景下,我们存在着“3 Pillars”(可持续发展业务、技术卓越、社会公正)这样的价值共识,一方面约束着TWer的准入,另一方面也时时提醒着我们的行为以及我们对市场的判断,必须考虑组织的这三大价值支柱。

然而当规模化袭来,模糊的准线成为了可能被冲破的价值点边界,领导者们需要开始思考如何维护3 Pillar的原有定义,例如P1、P2共识下的交付项目敏捷实践,是否仍然能在组织层面达成价值共识;而参与者也在另一方面思辨求新,倡导跳出原有的价值产物边界,去寻求更“合理的价值交付”。“交付”与“敏捷”这两个原本不存在博弈的问题,在最初设定的模糊准线下,随着企业规模化,就发生了共识分歧。

但是频繁的共识分歧,也会影响组织的规模化和效率提升,及时约束价值、更快地拉通解决价值共识分歧问题,才能帮助组织摆脱长期受制于价值模糊状态下的低效运作。

竞争力与价值锚定Competitive force and Value Pegging

去中心化技术里,存在着名为“侧链”的机制,其核心特性就是对多个分布式网络的价值进行双向锚定,建立组织间、个体间价值转化的通道,从而帮助价值锚定后的各体的竞争力得到充分发挥。

ICO(Initial coin offering),常常将早期投资人、创始团队的投入进行组织价值绑定,如通过“早期股权锁定3年以上”的规约,无形中对组织管理者提出了竞争力要求。与此同时,对后续参与者的加入,也需要设计适当的补偿机制,防止组织由于资本倾斜而导致竞争力堕化。

对组织全体竞争的激励方式,让组织成员勇于和乐于承担责任,这无疑需要将组织价值与个人价值进行一个转移。华为在组织上就采用了“奋斗者协议”与“虚拟股分红”等形式,在经济与职位提升上给予员工竞争力与个体价值的锚定,这样的全组织范围价值锚定,无疑为华为在近年来的输出了大量的竞争力。

在组织结构上,不同部门、角色的分工合作,也需要考虑到价值锚定的问题。大到IT部门与销售、财务、HR、运营等部门的关系,小到IT部门下的安全团队与研发、运维、合规等团队的合作,甚至销售、售前与技术这样一个小团队之中的价值锚定,都需要一个定位。价值锚定后的一个收益就是为“个体诉求”转变为“组织诉求”提供通道,从而也能将个体竞争力更大程度地转化为组织竞争力。

《哈佛商业评论》就提出将激励参与列入了“成功CEO的过人之处”,尽管去中心化组织的管理者主要由自驱动力决定,但也需要思考如何激励组织参与者释放竞争力,那么在去中心化组织中,由于价值共识更多由自底向上的反馈得来,个体竞争力可以得到更充分的体现,而组织的管理者们需要更多考虑如何将组织高层面的价值与个体价值锚定,最大化展示和输出组织的竞争力。

控制力与健壮敏捷Control force and Robust agility

去中心化的组织中,“白皮书”成为了至高法则,一切行为在白皮书的愿景下开展,计划按照白皮书的描述执行,尽管白皮书尽可能地从高阶预估了项目进程中可能存在的风险与困难,在组织的运作过程中仍然难以避免不可预知的风险发生,因此组织必须寻求一套健壮敏捷的举措来控制组织的方向调整。

DASH网络通过去中心的决策层参与与投票方式,以99%的支持率及70%以上参与率的主节点网络投票通过了执行去中心化管理制度以及新的基金制度,在可控的范围内完成决策,及时避免了主力节点的由于政见不合导致的共识分叉。

避免过度的“微观管理”(MircoManagement)已经成为一项管理共识,而随着“扁平化”、“微服务”、“可轮换职能”等思想的渗透,经由价值共识与价值转化而确定的去中心组织关系,也逐渐在组织管理者与参与者的思想里生根。那么去中心化的自治组织(DAO)技术,可以在一定程度上映射和支持我们组织的流程自动化,此外去中心化的组织,还需要考虑做好规模化过程中带来的人员融入问题,例如快速激活“空降管理者”、“空降团队”的竞争力,并且约束、鼓励其在组织原有的价值共识下,有所创新地解决问题和创造价值。

映射到技术上的组织控制力度量,可以参考控制系统的鲁棒性(Robustness),在组织的敏捷(Agility)改进过程中,从价值共识出发,基于反馈、激活通道,通过规范流程将鲁棒性落实到实践中,持续设计更健壮的组织架构,以应对市场和能力的变化。

另外针对组织之间的信任关系,我们也看到一些组织在创新性地使用技术手段加强跨组织间合作的稳固性(Securement),利用开放的数字化平台,包容组织的外部利益联系,通过技术的透明化,换取更强的联盟信任关系。

原力与你同在May the force be with you

关于去中心化的组织的提升生产力、应对规模化仍然有非常多需要探索的议题,在这里我仅以去中心化自治组织为原型结合区块链业界的一些实践作为参考,想必有许多的不足与片面,还希望得到大家的指正与更多意见。

愿数字科技发展浪潮能为我们的自驱动管理者们带来更多的启发和实践,愿原力与你同在。


更多精彩内容,请关注微信公众号:软件乌托邦

Share

基于密码学的数据治理Crypto-based Data Governance

最近得益于区块链在金融领域的火爆效应,Crypto-based currency&transaction改变了金融圈原本“数字货币=数字游戏”的印象,密码学货币不再只是数字货币,它还被赋予了“防篡改、去中心”的特性,但是本质上这些事务都是数据治理问题,只不过从原本的“服务级别”的访问权限校验转入了“数据级别”的完整性校验。其实密码学不只可以在金融业务方面做出贡献,在其他一系列数据治理难题中,我们也可以借鉴其中的一些思路。

下面让我们来回顾一些常见的数据治理问题,以及我们如何使用密码学来解决这些问题。

数据私密性

私密性(Confidentiality),数据作为企业的重要财产已经得到足够的重视,同时作为业务必须的原料又不得不分发到终端。我们既要做好必要的安全防护工作,同时也希望尽可能地灵活管理访问权限,在需要的时候能及时地送达业务场景中消化。

这个防护工作的目的也就是保护数据的私密性。通常有两种方式保障,授权与加密,随着数据量级的增长,私密性变得越来越细粒度。如何划分授权与加密这两种有着明确区分的方案往往被大家混淆,甚至不少开发人员认为授权是加密的一种。

常见的授权(Authorization),包含了验证(Authentication)与访问控制(Access Control)两个部分,验证是指用户或者业务模块通过一个私密的凭证来确保身份,它可以是一个密码,可以是一类数字签名(包括证书),也可以使用相对复杂的双向动态授权协议。

验证后的访问控制则是将数据权限更细粒度地拆分,提供一次性或者短暂性的访问权限,Token作为一个权证只能用来访问其对应权限下的数据,可以防止私密数据过量泄露。而目前一些新的方法中,权证分发本身被改善成了一个数字签名的过程,通过完全的非对称密码系统,让数据提供方原本需要保存的Token,转变为只需要验证访问请求所携带的数字签名就可以获知权限的Certificate/Signature,例如Hyperledger区块链平台就采用这种方式,分别签发Enrollment Certificate和Transaction Certificate为不同的业务场景提供不同的数据访问权限。

授权方案的发展历经了几个阶段(如上图),虽然和出现时间并没有太大关系,TLS早就定义了第三种形式作为分发证书链的模式,我们可以看到在第二种方案中,通过采用token的授权,使得细粒度的授权分发可以和验证分离开来。而第三种方案则更进一步,让双方不需要再传输存储授权凭证,而且整个授权过程可以是一次性的,而不会影响到数据访问。

随着高阶密码学原语的引入,我们甚至可以在验证授权的过程中为用户的访问提供隐私保护,例如通过Dual Receiver Encryption配合Ring Signature可以实现匿名组策略等效果。

加密(Encryption),往往是较为耗时和受限制的数据治理手段,尤其是非对称加密算法,只能针对少量的数据集执行,而对称加密又存在交换秘钥、存储管理秘钥时的隐患。因此作为保护数据私密性的最后手段,我们应该尽量避免滥用误用,常见的误用场景包括试图通过在客户端加密Token来防止用户篡改数据访问权限、试图用加密应用代码的方式保护数据、试图仅依靠对称加密分发数据等等。

常见的加密确保私密性,常常是基于“数据被盗”或者“数据集必须存放在用户端”的假设,“数据被盗”决定了每个数据池都有必要对基础设施进行预防,例如对硬盘加密、选择安全的通信信道和协议、避免秘钥泄露、避免系统人为操作、避免内网服务对外开放、减少私有网络的威胁等等。而“数据集必须存放在用户端”则需要考虑到恶意软件、逆向工程、暴力破解可能造成的数据损失。

数据完整性

完整性(Integrity),说到区块链的一大卖点就是不可篡改,通过确定交易双方身份的Signature、交易顺序的Merkel Hash tree、Block前向完整性(Forward integrity)Hash,三者(如图)组成了一套完整的分布式账本链条,其中每一条、每一页的交易记录之间、页与页之间都由密码学原语保护。这样的一种数据结构设计,为区块链带来了更灵活的去中心结算方案。

将区块链解构之后,我们也可以灵活地将这些密码学原语用于保障常规数据的完整性,尤其可以应对B2B场景下,企业联盟之间的数据共享信任问题,通过完整性校验,可以实现竞争关系下的同业数据融合;通过数字签名,可以为如票据交易、款项去处之类的数据审计提供证据。

大数据分析提高了对数据真实性的要求,密码学提供的完整性校验方案,可以为外来数据治理提供额外的保障。同时由于密码学原语位于设施的底层,因而这一系列的验证审计操作都可以自动化执行,而不需要额外的人力来管理校对。

数据可用性

可用性(Availablity),在数据治理中是一个非常困难的话题,我们可以将数据副本分发到业务微服务中缓存,也可以采用分布式的存储方式,这些都是为了解决单点故障、减少大量数据同步的时间开销,其中Hash Table作为最常见的检索方式,可以同时保障数据的完整性和可用性,数据池可以使用分块的方式将数据分散存储,同时使用Hash来计算出摘要以供后续的检索,通过额外的加密手段,甚至可以实现对等节点的全量和增量数据同步,而不必担心数据的私密泄露。

DynamoDB采用了这种Hash一致性算法,“均匀”地管理数据分片(如图)。Bittorrent网络采用Hashtable来寻找目标文件。Spark-mllib也使用了Hash来进行词频统计,达到数据分治的效果,避免了维护全局term-to-index map的麻烦。

此外,加密后的数据由于可读性问题,很难再做重用,而常见的保护用户敏感信息,并且同时保护数据分析可读性的方法,在微软和苹果等公司都有所尝试,称为Differential privacy(如图),数据分析师在提取数据时,Privacy Guard评估Query Privacy impact,为反馈的数据加上噪音,例如可以使用Hash替换掉真实信息,只保留数据“特征”,减少用户隐私泄露的风险,同时又能保留数据的分析价值。

重返焦点

如果说数据湖是每个企业的金库,那么数据治理的安全措施就是用于搭起金库壁垒的一砖一瓦,每个安全措施之间的紧密粘合都依托于完善和牢固的密码学设计,随着“安全无小事,商场入战场”的警钟不断敲响,从基础设施建设上对数据治理的不断规范化和标准化呼声越来越高,密码学重回技术焦点的日子应该不会太远。


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

Share

区块链之问—产业应用的机遇与挑战

如果说2016年Fintech前沿有什么有趣的话题榜单,你一定会在其中看到区块链,这样一个最初被视作“娱乐大于实际”的比特币所采用的结算系统,现如今已跻身于Fintech的最前沿。之所以会有这样的骤然变化,是基于实实在在的技术创新。伴随着以太坊(Ethereum重新定义区块链应用场景,R3、金链盟等联盟链的成立,可信可控云计算 、终端安全存储等技术的演进,以及众多机构加入探索,区块链应用步伐大大加快,甚至引起了央行的注意。我们可以看到越来越多金融相关领域的龙头企业尝试拥抱这项技术,用于解决行业难题。

与此同时,我们看到区块链目前仍然缺乏标准化和落地实践,业内有一些盲目跟风的现象,强行将该技术用于不匹配的业务场景,使得区块链就像“一把仍在寻找钉子的锤子”。毫无疑问,区块链已经成为FinTech业界热烈讨论的焦点,但是它究竟从何处而来,为解决什么问题而生?又将向何处去,是颠覆行业还是被人淡忘?我们不妨将繁复的概念营销先放在一边,一起来探寻这些本质之问的答案。

从何处而来

区块链,最初只是比特币的结算系统,其本质是基于密码学的去中心账本方案,区块链本身所使用的技术并不是新概念,而是基于一系列密码学技术的集合,通过巧妙的设计,使之实现了去中心化的结算需求,然而伴随而来的是一些衍生问题。区块链并不是“一把仍在寻找钉子的锤子”,而是一把“专门为某种钉子设计的锤子”,所以要了解区块链的本愿,我们需要先从“比特币之父”中本聪的论文说起。

中本聪的比特币

2008年,中本聪(化名)第一次在Metzdowd的密码学邮件列表中发表了比特币相关的建议书,其中包含了他之前的一篇论文--《比特币—P2P下的电子货币系统》,论文中阐述了如何使用密码学原语与特定的数据结构,在不可信的环境下建立分布式对等节点的结算系统,区块链的三层密码学结构、工作量证明与拜占庭容错难题都是由这篇文章引出的。


图1:区块链的三层密码学结构

比特币已解决的问题:

  • 记录的内容完整性
  • 记录之间的顺序不可篡改
  • 记录的去中心化同步容错

比特币待解决的问题:

  • 去中心同步带来的性能问题
  • 工作量证明导致的复杂性与算力垄断隐患
  • 更新迭代愈发困难
  • 应用场景的局限性

这些“已解决的问题”正是区块链技术所提供的业务价值,而从区块链的最新发展来看,具有独创性的一系列改进,大都是围绕着“待解决的问题”而展开的。

很遗憾的是这篇论文很少被媒体引用,原因或许是密码学概念仍然很难为大众理解,但是另一个很重要的讨论前提也由此被掩盖:区块链的最初设计,目的是支持P2P(对等节点)之间记录不可信赖的去中心交易环境,而“不可信的对等节点”这一前提在传统金融领域有着不同的阐述和限制,忽略这一差异而讨论区块链,就是引发误解的原因之一。

对区块链的误解

当前许多新兴的产业应用场景,套用区块链作为防篡改的记录系统,例如通过区块链来确保交易、票据、合同、供应链等记录的完整性。然而,在实际的使用过程中,仍存在着非常大的误区。

事实上区块链作为防篡改方案,仅仅使用了其中的三层密码学结构,而去中心容错问题则是由其分布式结构决定。区块链记录一旦产生,便可以具有前向完整性,即对于已经产生并记录在案的数据,可以通过密码学检验确保其内容难以被篡改。这一要求,不需要基于去中心点对点的场景便可以实现,在这样的应用场景中,工作量证明等容错方案便成为了冗余的设计,无形中增加了落地的难度。

因此,我们可以看到新兴应用场景中“广义的区块链”,和比特币等去中心化场景中“狭义的区块链”,实际上有着巨大的应用场景差异。

相似的,区块链与“数字货币”也不可一概而论。作为比特币的基础设施的区块链,常常也伴随着“数字货币”的方案一同出现,然而“数字货币”对于应用场景有着非常高的要求,其发行与管理都需要经济领域专家的设计,同时也面临着政策监管的敏感风险,因此产业急需将“数字货币”与区块链解耦,以拓宽区块链的应用面。

进化中的竞争币与以太坊

随着时间推移,比特币也显现出了一些问题,例如保密性和公平性都受到了质疑。我们看到使用“零知识证明”代替有缺陷的签名系统的方案“ZeroCoin”,试图通过分成协议吸引更多持续维护者参与其中的“Dash”,同时社区也不再满足于结算交易,涌现出了不少其他的应用场景,如代替传统域名解析服务的“Namecoin”、用于票据交易的“Ripple”,以及提出了链上代码概念的“以太坊(Ethereum)”。

以太坊通过提供图灵完备的运行环境,使得区块链从原有的数据存储结构进化为了可以约束合约行为的平台,从这一点上看,以太坊的区块链已经脱离了原本的“交易结算”场景,随之而来的,我们在以太坊之上看到了许多富有想象力的新应用,其中最著名的即是DAO。DAO采用了以太坊的智能合约平台,实现了提供数字凭据的股权众筹体系。受到以太坊启发,R3和Hyperledger也纷纷引入了“智能合约”的概念,并不断提高其拓展能力,也造就了当前区块链百家争鸣的局面。

将向何处去

目前我们看到的一些区块链的产业应用主要包括以下领域:

  • 财务结算
  • 票据交易
  • 金融资产
  • 合作合约
  • 供应链审计
  • 元数据管理
  • 共享经济
  • 物联网

而对于不同的产业领域,我们可以看到区块链提供了不同的帮助,有些是保障记录完整性的,有些是希望打造更灵活自动的合约平台,有些是针对不可信环境的数据治理。由于产业需求的不一致,我们也看到碎片化的平台不断被开发出来,最终行业间的适配就成为了广泛存在的问题,业界逐渐开始考虑标准化和落地的解决方案。

标准化与落地

货币结算的标准化方案其实很早就已经在金融IT系统中存在了,例如SWIFT(环球同业银行金融电讯协会),它是目前使用最为广泛的银行间结算协议,为银行间结算提供了标准化的报文格式和安全方案,其服务已经遍及207个国家,接入的金融机构超过8100家。

随着区块链技术越来越被重视,SWIFT与埃森哲在今年四月共同推出了分布式账本系统报告,这一20页的报告体现出了SWIFT对目前分布式账本的研究和推动货币结算标准化的意愿。其中,有一个采纳了分布式账本的“身份和访问管理”的概念应用,展示了SWIFTNet PKI 分布式账本解决方案,以及访问控制机制(如封闭用户组和RMA),是SWIFT利用现有的平台和资源,解决身份和访问管理问题很好例证。

但是即便是SWIFT,也仍然面临着标准化推动缓慢,产业应用缺乏落地实践的问题,由Linux基金会与IBM、Intel等科技组织参与的Hyperledger超级账本开源项目由此应运而生,Hyperledger旨在推进跨行业的区块链技术发展,是一个全球合作的组织,涵盖了金融、银行、物联网、供应链、制造和技术等领域。相应的还有R3联盟区块链,由R3cev发起,至今已吸引了数十家巨头银行的参与。我们可以看到各界都在努力地将产业应用标准建立起来,以便后续的行业间交互合作。

图2Hyperledger为基础设施的产业间合作网络

困难与挑战

在区块链技术落地的环节,我们仍然面临着许多的困难和挑战,其中最为紧迫的是将业务需求映射到技术方案上,并基于这些需求对现有的区块链实现进行改造和精简,以应用于实际的业务环境。甚至对于区块链现有的密码学结构做出适当的修改,以满足不同场景的具体需求。

另一方面,区块链原有的问题,以及长期以来基于社区的松散结构,造成产业应用缺乏快速原型、敏捷迭代的最佳实践,如何更快地将区块链应用于业务原型,并构建完善的持续交付流程,尤其是针对开发和运维阶段的实践,是非常值得投入的领域。

解构与重构

由于区块链本身的密码学和共识方案分别用于解决不同领域的问题,从比特币的最初设计到后续区块链的各方改进,我们可以看出,不同技术对所解决的问题具有非常强的针对性,并非可以照搬利用。我们常常看到许多大型组织对区块链技术表示好奇,却缺乏对其业务应用场景的思考,尤其是行业对于区块链技术的理解仍然需要解耦。

例如,针对智能合约的场景,我们需要实现一套安全可控的执行沙盒来部署一次性或多次性的合约解释器(intepreter)服务,基于领域概念设计的DSL和API将有助于业务人员更灵活地设计合约条款和执行方式。

智能合约基于其自动化效用,对我们的业务抽象能力也提出了新要求,如何设计更完备的区块链智能合约机制以映射业务场景,需要对原有的业务流程进行拆分,并且落实到规约层面,这与传统Fintech系统方式有所不同,标准化与规范化在这一场景下显得尤为重要,数字化平台思维也必不可少。

图3:智能合约场景常见技术架构

相对应的,针对更注重审计的供应链场景,我们则应该把重心放在记录的完整性和审计可视化上,这就要求区块链提供更丰富的查询、校验接口。同时对于有分布式需求的供应链环节,如物流运输等环节,设计完善的同步共识算法就显得尤为重要

此外在供应链应用中,区块链的核心价值之一--“分布式记录完整性”得到了充分的体现,但是由于参与供应链的企业和行业数量繁多,统一的成员管理就成为了必须考虑的课题。

图4:供应链场景的成员管理服务

另外,区块链所面对的问题,本质上是“不受信任”的场景下的“数据治理”问题,因此,企业对于区块链的研究投入不应该只局限在技术层面,更应当着眼于“数据价值”,从“安全可信”的需求出发,对区块链进行重构,以胜任自身以及行业联盟的业务需要

展望

区块链不仅为可信金融领域提供了新的模式,还为其他各类产业应用引入了新思考,同时业务与技术设计也面临着新的难题。如何拥抱数字化平台带来的机遇,直面挑战,正是产业应用对区块链和Fintech提出的问题,如果能在以下这些领域取得突破,相信区块链在未来会给我们带来更多激动人心的颠覆性创新:

  • 将不同场景的业务需求映射到技术方案,并基于这些需求对现有的区块链实现进行改造和精简。
  • 积累快速原型、敏捷迭代的最佳实践,更快地将区块链应用于业务,并构建完善的持续交付流程。
  • 对于记录的完整性和审计可视化,设计更直观的展示方式。
  • 完善区块链的成员管理能力,基于标准协议形成联盟,满足更多企业和行业间的信息交流。
  • 着眼于“数据价值”,从“安全可信”出发,对区块链进行重构,以胜任业务需求。
Share