一文解析区块链可运维性的六大误解

本文涉及的产品
云解析 DNS,旗舰版 1个月
全局流量管理 GTM,标准版 1个月
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
简介: 可运维性的诉求是一个很重要的诉求,它在币圈的缺位不是因为币圈不需要它,而是因为币圈有难言之隐。

40


什么是IT系统的“可运维性”?通俗地讲,IT系统的可运维性就是一个IT系统自身所提供的确保该系统的正常运行状态、排除该系统的异常运行状态、应对突发的运行需求的能力。当然,这种能力,需要最终与从事运维工作的人相结合才能真正发挥其预期效果,但是如果系统提供的“可运维性”能力很差,就会导致从事运维工作的人有劲使不上或者只能用非常低级原始的办法来达成运维目标的情况。从这个意义上讲,IT系统的可运维性是它得以付诸安全平稳高效运行的前提。

笔者在传统金融行业从事过多年IT运维管理,深知可运维性对于金融机构的重要性。让我们来看一看可运维性在金融行业是如何体现的。

在金融行业,确保系统的正常运行状态的主·要途径是架构手段,即通过高可用架构实现尽量短的故障恢复时间目标(RTO)和可容忍故障恢复点目标(RPO)。很多关键业务系统的RTO为秒级,RPO为0,这意味着不容许任何数据丢失和业务状态错乱,业务的短暂中断不会造成普通用户感官上的明显停顿。为此在高可用架构中要有大量的冗余设计和接管(failover)措施,从机房、电力、网络、主机、存储、数据库、中间件、域名解析到应用,都需要在架构设计上一体化考虑,都不允许出现单一故障点(Single Point of Failure) 。

在金融行业,排除系统的异常运行状态是监控手段和应急操作特权入口,提供详尽、可理解、可视化的直观监控信息,可帮助运维人员实时了解系统和网络的真实健康状况,以便及早发现并应对异常;提供应急操作特权入口,可以为例如改错、选择性关停、限流等应急手工操作提供一个安全方便的操作环境。

在金融行业,应对突发的运行需求的主要途径,在架构层面是参数化设计,在操作层面是保留最终干预权。灵活的参数化设计可在短时间内通过参数调整来应对突发的业务改变。比如2015年,证券市场的“熔断”机制推出后数天即被要求叫停,借助于参数化设置的这种灵活性,技术系统仅仅需要把熔断触发条件设置成逻辑上不可能的参数值就可以很快满足这一突发的运行需求。最终干预权则是对关键业务系统的核心模块提供人工干预的应急接口,来进行满足突发的运行需求的操作。注意,突发运行需求的起因并不是系统发生了异常,而是系统运行的宏观外部条件(如政策)发生了异常,迫使系统必须以非常规的手段进行应对。

区块链是一种基于密码学和分布式共识机制为一个特定用户群提供信任服务的基础设施。近年来,区块链技术得到了迅猛发展,不仅在民间有基于“虚拟货币+社区+区块链平台”的“币圈”打法,在传统金融机构和其他行业也出现了仅利用区块链平台服务于业务目标的“链圈”打法。随之,区块链语境下如何体现可运维性也开始浮出水面。

不要以为区块链技术从其架构本性上来讲就是高可用的,因此就可以忽视可运维性的问题。实际上,区块链技术发展的现状为区块链的可运维性提供的技术资源还太少太少。从区块链领域遇到的大大小小涉及可运维性的问题当中,笔者深深地体会到,区块链的可运维性既需要大力度借鉴传统金融机构管理可运维性的一系列理念和做法,也需要基于区块链语境本身的特殊性发展一系列原创性的运维管理做法,尤其是要纠正区块链领域的一些错误的认识和做法。

2016年The DAO事件余波未平,2017年以太坊又爆出了Parity多重签名合约误锁漏洞。区块链的可运维性又一次引起热议。去年比特币社区还在嘲笑以太坊社区一言不合就分叉,今年分叉的事情就轮到了比特币社区自己的头上。每次看到社区出现这样的情况,总会有传统金融机构的朋友出来说:看看,幸亏链圈没有这么玩,否则指不定死多少回了!

其实,可运维性不仅是链圈、也同样是币圈所追求的区块链特性。在解决了不可撤销、不可仿冒、不可篡改、不可抵赖、不可双花、不可透支这些价值传输最基本的问题之后,人们的目光停留在了隐私保护和可运维性上面。说起隐私保护特性,币圈有ZCash这样的虚拟货币推出。说起可运维性呢?也许是去中心化的观念先行,排除了大量在链圈看来很平常的运维手段的使用,从应急处置和审计追责的角度,我们还没有看到币圈有有份量的可运维性技术解决手段的推出。但是,从预防为主的角度,至少智能合约的形式化验证问题和在线升级的问题,已经在币圈引起了足够的重视,这一迹象是正面的。

链圈呢?在这里我们必须提到链圈的两个值得一提的努力。

第一个努力是埃森哲公司提出的“可编辑的区块链”概念。在埃森哲的材料中,他们开宗明义,把可编辑区块链的推出和传统金融机构的可运维性需求挂起钩来,从不当得利、错账冲正到乌龙指,各种必须修改的错,都不能将错就错,需要得到授权的操作人员把错账改过来。如果区块链承担了记账的任务,那么改错账就应该是区块链必备的功能。以比特币、以太坊为典型代表的币圈平台做不了这件事情,除非分叉。埃森哲提出的解决手段则是使用基于“变色龙哈希”的“可编辑的区块链”。从数学原理上看,可编辑的区块链确实可以不分叉就能改错,但是代价是开了一个既能篡改历史又不可审计的后门。这样一个东西的存在,不仅秉持坚定去中心化理念的币圈不可接受,就算是在一定程度上容忍中心化要素存在的链圈,接受的人也不是很多。

第二个努力是R3联盟去年底推出的Corda平台。在Corda上,智能合约代码和对应该合约的正式有效的法律文本是互相勾稽的。合约法律文本的存证形态是合约代码的不可缺少的附件,并以数字签名存证。通过对附件的验证,给予合约代码所代表的“本意”一个抓得住的抓手。一旦合约在运行中出现问题,至少可以通过查验来确定这到底是法律合约原本就有的,还是合约的代码实现没有忠实地体现法律合约的“本意”造成的。某种程度上,这也算是对此前一段时间以来合约代码单兵突进、法律法规没有同步跟进结果形成畸形生态的一个弥补。此外,Corda上并不存在一个“我的银子我做主”的基础账本,任何单据(状态)都可以在合适的条件下经公证被废止。这也为改错账留下了可以运作的空间。可以说R3这些业务大咖们对于分布式账本的可运维性的意义还是心中有数的。

由此可见,可运维性的诉求是一个很重要的诉求,它在币圈的缺位不是因为币圈不需要它,而是因为币圈有难言之隐,在目前技术条件下无法把这个诉求落到实处,而只能诉诸分叉这样无奈而又笨拙的手段。链圈对于可运维性的诉求来源于传统金融机构使用者对于合规性的发自本能的自觉遵守,但并没有形成一个完整的技术体系和技术方法论。

首先,“我的资产我做主”绝不是一个与现行法律体系完全兼容的做法。如果在技术上把“我的资产我做主”做实,“做主”在技术上体现为“掌握私钥”,那么在一些场合下,执法措施就落不到实处,就必须事实上迁就区块链的技术设定。在需要进行应急处置的场景,尤其是需要对涉及资产余额的错账、乌龙指、非法所得、不当得利等进行冲正、追究、查封、充公等操作的时候,这样的做法在法律上有明显的缺陷。所以,从区块链底层把执法措施支持到位,是区块链应用单位满足合规要求的起码要求。如果说在之前以借鉴为主的阶段大家还顾不上法律合规性的话,那么当区块链进入以技术上自主创新、自主掌控为主,应用上以合规发展、为我所用为主的阶段时,这样的要求再不得到满足就说不过去了。

其次,可运维性的要求应该非常清晰地传导到开发方。一是在开发方中逐渐形成基于最佳实践的模板,把有共性的可运维性的功能(比如应急处置特权下的冲正机制、冻结机制、刹车机制以及在线升级机制等)作为模板的标配代码嵌入其中。二是在开发方中逐渐形成基于业内风控理念和通过历史教训积累下来的业务流程参考约束标准,把重要的业务步骤之间共性的合理顺序固化下来。秉持同样运维理念的开发方应该联合起来,形成共享可运维性模板的联盟。通过这样的做法,让区块链应用少走弯路。ChinaLedger白皮书2016版中系统阐述了如何在智能合约层面支持应急处置的问题,有兴趣的读者可以参阅。

第三,区块链绝不可以看成是一个“数据库”,更遑论“分布式数据库”。拿区块链当数据库用,就会发现区块链只有创建和读取功能,没有修改和删除功能,就会得出“区块链不如数据库”的错误结论。其实,并不是区块链不如数据库,而是压根儿不应该把区块链这样来用。区块链上记录的不应该是业务数据,而只能是操纵业务数据的指令序列(或其日志)。区块链不是要取代数据库,而是要作为数据库的高可靠性的前置。我们要求日志不可遗漏、不可篡改,但并不是说数据本身不可改动。把一系列操作依序记录在区块链上,然后到真正的数据库中依序执行这些可留痕、可审计、可追责的正常操作和应急操作,操作的最终结果写在真正的数据库而不是区块链中。一旦数据库发生问题需要回滚,只需从区块链的特定高度进行重演,数据库本身的高可用架构也可因此大大简化。应急处置中如果需要对数据进行冲正,只需通过区块链增加一条冲正的数据操纵指令,这个应急处置行为本身既是需要特权许可的,也是留痕的、可审计的。

第四,通过分叉来修正区块链数据,即使在币圈,也绝对不是值得提倡的事情。分叉本身意味着账本的分裂,但在多条区块链通过跨链机制互联的场景下,会导致与之跨链互联的账本也跟着分裂。也就是说,当分叉遇到跨链,分叉会把本来在一条区块链内的运维问题传导到另外的区块链中去,变成一个全网的运维问题,从而大大增加全网的运维难度。所以,从可运维性的基本理念出发,不应该听任动辄分叉,而应该利用互联互通来反制那些轻率的分叉举动。

第五,有缺陷的区块链应用特别是智能合约应用上线,是一件十分危险的事情。它不仅可能影响自身的用户群和业务生态,还可能影响其他的用户群和业务生态。由此看来,当区块链技术和应用发展到一定阶段,对承载重要业务、运作重要资产的区块链实行某种形式的应用准入制,要求应用自带某种形式化验证的过程与结果,要求应用具备某种标配的应急处置功能,是十分必要的。

第六,区块链可运维性应该成为区块链正规教育和区块链技术培训的必选内容。只有让可运维性的理念和最佳实践深入人心,只有把不注重可运维性导致的后果充分揭示出来,才能使区块链技术人才建立关于区块链技术的正确的知识结构。这些人到了应用开发第一线,才会更加自觉地为区块链应用扎牢可运维性的篱笆。

总的说来,笔者认为,可运维性是区块链应用中不应被忽视的重要诉求,必须从法律层面、行业最佳实践及标准化层面、用法层面加以引导和约束,使可运维性的诉求贯穿区块链应用的始终。

原文发布时间为:2018-02-17
本文作者:AI金融评论
本文来源:雷锋网,如需转载请联系原作者。

目录
相关文章
|
14天前
|
运维 监控 安全
运维技术——从基础到高阶的全面解析
本文是一篇技术性文章,主要探讨了运维技术。运维不仅仅是保持系统的稳定运行,更包括优化、预防故障和应对突发事件的能力。本文将从运维的基本概念入手,逐步深入到高阶技术和策略,为读者提供一个全面的运维知识体系。希望通过这篇文章,读者能够更好地理解和应用运维技术,提升自己的运维能力。
|
2天前
|
供应链 安全 分布式数据库
探索区块链技术:从原理到应用的全面解析
【10月更文挑战第22天】 本文旨在深入浅出地探讨区块链技术,一种近年来引起广泛关注的分布式账本技术。我们将从区块链的基本概念入手,逐步深入到其工作原理、关键技术特点以及在金融、供应链管理等多个领域的实际应用案例。通过这篇文章,读者不仅能够理解区块链技术的核心价值和潜力,还能获得关于如何评估和选择适合自己需求的区块链解决方案的实用建议。
8 0
|
4天前
|
存储 运维 监控
运维技术深度解析:构建高效、稳定的运维体系
【10月更文挑战第22天】运维技术深度解析:构建高效、稳定的运维体系
26 0
|
4天前
|
人工智能 运维 监控
运维技术深度解析:构建高效、稳定的IT基础设施
【10月更文挑战第22天】运维技术深度解析:构建高效、稳定的IT基础设施
13 0
|
4天前
|
机器学习/深度学习 边缘计算 运维
运维技术深度解析:构建高效、稳定的IT基础设施
【10月更文挑战第22天】运维技术深度解析:构建高效、稳定的IT基础设施
10 0
|
3月前
|
图形学 开发者 存储
超越基础教程:深度拆解Unity地形编辑器的每一个隐藏角落,让你的游戏世界既浩瀚无垠又细节满满——从新手到高手的全面技巧升级秘籍
【8月更文挑战第31天】Unity地形编辑器是游戏开发中的重要工具,可快速创建复杂多变的游戏环境。本文通过比较不同地形编辑技术,详细介绍如何利用其功能构建广阔且精细的游戏世界,并提供具体示例代码,展示从基础地形绘制到植被与纹理添加的全过程。通过学习这些技巧,开发者能显著提升游戏画面质量和玩家体验。
115 3
|
3月前
|
区块链 C# 存储
链动未来:WPF与区块链的创新融合——从智能合约到去中心化应用,全方位解析开发安全可靠DApp的最佳路径
【8月更文挑战第31天】本文以问答形式详细介绍了区块链技术的特点及其在Windows Presentation Foundation(WPF)中的集成方法。通过示例代码展示了如何选择合适的区块链平台、创建智能合约,并在WPF应用中与其交互,实现安全可靠的消息存储和检索功能。希望这能为WPF开发者提供区块链技术应用的参考与灵感。
58 0
|
存储 前端开发 安全
DAPP区块链商城系统开发(方案逻辑)丨区块链DAPP商城系统开发(案例设计)/开发项目/源码部署
 区块链(Blockchain)是一种由多方共同维护,使用密码学保证传输和访问安全,能够实现数据一致存储、难以篡改、防止抵赖的记账技术,也称为分布式账本技术(Distributed Ledger Technology)。从本质上看,区块链是通过去中心化和去信任化,集体维护、分布式存储的可靠数据库。
|
开发框架 安全 前端开发
区块链财务管理平台如何开发?区块链财务管理平台开发源码规则解析
开发一个区块链财务管理平台需要多个方面的技术和知识,以下是一些可能的步骤和考虑因素:
|
存储 安全 区块链
区块链游戏系统开发(开发详细)/案例开发/设计功能/逻辑方案/源码平台
  区块链游戏系统开发是一个复杂而精密的过程。首先,需要进行需求分析和规划,确定游戏系统的功能和特性。然后,进行技术选型和架构设计,选择适合的区块链平台和开发工具。接下来,进行系统的搭建和编码,实现游戏逻辑和用户交互功能。最后,进行测试和优化,确保系统的稳定性和性能。

推荐镜像

更多