信息爆炸?云上的机器人连接一切

前段时间,一条科技新闻惊爆整个互联网:微软举债262亿美元现金收购LinkedIn,创下科技史上收购价第三高的纪录。

为何要收购?微软CEO Satya Nadella在公开信中指出,“This deal brings together the world’s leading professional cloud with the world’s leading professional network.”依托世界上最大的专业化服务云与最大的专业化关系网,微软与LinkedIn走到一起,应用、数据与人连接在一起,将有可能构筑一个前所未有的智能、专业化生态。

无独有偶,在同一天的苹果WWDC大会上,苹果一口气发布了MacOS、iOS、WatchOS、tvOS四大操作系统。其中,最受关注的却是Siri、iMessage等软件的开放API。

1-api

从iPhone 4S时代走来的Siri第一个扛起“AI个人智能助理”的大旗,却接连被Microsoft Cortana、Amazon Echo、Google Allo等甩在身后。于是,苹果正式发布了Siri API,不久之后便可用它叫车、外卖、搜图、支付等。这一次,苹果希望以Siri为中心,将应用、数据连接在一起,重新构建真正的智能生活。

人类的历史就是一部信息传递与处理的历史。长城上的烽火把帝国的边疆阡陌连在一起,丝绸之路上的商人旅客让欧亚大陆连在一起,电话让登月的人类第一次从太空与地面进行沟通,互联网更是让人足不出户了然天下事……信息的载体从光、人、物、电磁波进化成了现代0和1的bit数字。与此同时,信息的范畴外延无比放大,从军情公文、家书鱼雁、各种软件数据到量化物体(物联网)、量化人类自己(可穿戴设备)……信息外延到了宏观的宇宙世界,又触及了微观的纳米世界。两波浪潮碰撞在一起,人类面对的是一个海量、碎片、实时、数字化的信息爆炸时代。

“弱水三千,取一瓢饮”,信息爆炸时代,人类要如何完成信息的高效处理?曾经的人类通过层级化的组织结构来小心地控制信息的输入与输出,现在的人类通过资源池化的信息引擎来完成信息的屏蔽过滤。然而,当万物连接的信息洪潮遮天蔽日地过来,曾经的组织和个体仿佛风雨中飘摇的枯叶一般弱不禁风,人类需要如何应对?在电影《环太平洋》中,面对宇宙中的洪荒巨兽,人类的机甲猎人被摧枯拉朽。这是否是人类的最终命运?

%e5%b1%8f%e5%b9%95%e5%bf%ab%e7%85%a7-2016-09-13-%e4%b8%8a%e5%8d%8811-47-45

问题太宏大,人类仍然需要回顾过去的经验,从历史的幽光中挖掘可能的解决办法。刘慈欣在科幻作品《三体》中讲述了一个科幻的故事:秦始皇的千万大军,通过黑白小旗和士兵矩阵,组建了与、或、非门,设计了一款人体计算机对微积分方程进行求解。这让我们不由沉思——低效的人类组织和协作,只要通过一些简单的规则,就可以对复杂的问题进行计算;同样,基于这些简单的规则,简单的元组件组合在一起,就能代替低效的人类组织和协作。

我们再来看看传统信息传递和处理的典型案例“长城烽火”。当敌人侵犯,守卫发现敌情,点燃烽火;附近的烽火台守卫看到烽火,点燃第二级烽火……以此类推,直到军队支援,消灭入侵敌人,消灭险情,烽火熄灭。整个过程主要涉及了如下的要素:

对象 职责 角色
烽火 烽火即警报,点燃烽火即为告警 信息协议,包括接口和格式
守卫 向烽火台网络里面输入敌情的告警信息 信息输入者
军队 处理烽火台网络输出的敌情告警信息 信息处理者
烽火台网络 确保敌情告警信息的正确传递和处理 信息传递、升级和协作体系

因此,我们可以抽象出信息处理的四个基本要素:协议、监控器、处理器,以及基于协议、由监听器和处理器组成的网络。无论是烽火狼烟,抑或是模电数电,都是基于下面的范式进行信息的采集、传递和处理,区别只在于效率和规模。面对“海量、碎片、实时、数字化”的信息洪潮,人类的终极信仰跃然纸上:云、机器人、API。

1-cloud

KK在《失控》中指出,“人造物越来越接近生命体,生命体越来越程序化。”连接和智能成为时代的主旋律,微软、苹果、腾讯、谷歌、阿里、百度……这些科技界巨头们无不提前进行结构性布局。多边平台的参与者越多,边际成本越低,网络效益最高。这也是为什么我们看到,微软不惜举债收购LinkedIn和Skype、苹果将Siri作为下一代个人智能助理的核心、腾讯将微信定位为“连接一切”……

外面的Interface很简单,但背后不显山不露水的恰恰是里子——微软的Azure和Office365云、苹果的iCloud、腾讯的腾讯云……微软、苹果、腾讯背靠各自的云和服务,坐拥无数的用户,或许正如唐太宗看见新晋进士鱼贯而出,得意洋洋地说道,“天下英雄,入吾彀中矣”。

尾声

在行文结束之前,我们再回顾一下本文的主要观点:

  • 人类需要处理的信息源将来自于自然万物:机器、软件应用、人体自己等等;
  • 海量、碎片、实时、数字化信息处理的核心在于云、程序性机器人和API接口;
  • 领先的科技公司都在这一战略逻辑之下进行结构性布局:建设云平台、将各种服务固化为程序性机器人、扩展与人类的信息输入和输出接口。

如果说微软通过Azure、Office365与LinkedIn连接是帮助职场专业人士更高效地完成办公信息的传递和处理,苹果的Siri API连接是帮助普罗消费者更高效地完成个人生活信息的传递和处理,软件研发运维的信息传递和处理如何实现呢?我们能否让每一位ThoughtWorker,从TechOps、到PS、再到TOC人员,都生出三头六臂?

 

Share

云与大数据,商业创新的加速杠杆

引言

「互联网+」的浪潮正在冲击传统的商业模式和商业组织。支付宝与天弘基金开发的余额宝在短短一年之内,吸引用户数超过1个亿,资金量超过5742亿,一跃成为全国最大的货币基金 。2013年成立的菜鸟网络将传统的「四通一达」快递公司整合进其统一信息云平台,迄今已经实现了全中国超70%快递包裹的跟踪管理微信在短短三四年之内,月活用户量达到6亿,2014年春节顶峰时间每分钟微信数量超过1000万条,与此同时,传统电信运营商的短信量剧减41.57% 。这些新兴公司,背后依托着云与大数据,更快地响应市场,建立起巨大的竞争优势,从而颠覆了传统的商业公司。

商业史是一场关于「优胜劣汰,适者生存」的进化史,「唯有偏执狂才能生存」 。进入21世纪,商业公司的更迭变得愈加频繁,「企业的平均寿命从1920年的65年降到了2015年的15年」 。初创公司更是如此。哈佛商学院教授Shikhar Ghosh的研究表明,在美国风险投资进入的初创企业中,四分之三以破产告终 。无论经验丰富的成熟公司,抑或充满活力的初创公司,在面对商业市场的不确定性时,无法建立有效的竞争优势,难以延续或扩张。在这个高度不确定的时代,第一时间拥抱云与大数据,建立商业创新的先发优势和加速杠杆,是所有企业CIO乃至CEO的必修课。

商业创新的挑战和企业策略

大量的案例表明,创新是商业公司建立竞争优势、持续扩张的关键方法。然而,创新者如过江之鲫,成功者寥寥。美国市场研究公司CB Insights通过分析101家科技创业公司的失败案例,总结出了创业失败的20大主要原因,其中「没有市场需求」以42%的比例排名榜首,「耗尽资金」以29%的比例位居第二 。面对「创新者的窘境」,商业公司最迫切的目标就是在人力资金等资源投入的有限时间之内,尽快找到创新产品与市场的契合点,建立竞争优势。emagazine pics-09

图1. 创业失败的20大主要原因(图片来源:https://www.cbinsights.com/blog/startup-failure-reasons-top/)

然而,传统商业公司的产品研发和运营往往以年或者季度为周期单位,公司业务、技术等部门的管理者们根据前一周期研发经营的情况,整理后一周期的目标和计划。一是研发周期漫长,运营的反馈很难及时到达研发部门进行调整,二是产品的概念来自于业务部门的专家意见,没有进行用户问题的真实验证,需求存在偏差。商业创新闭环的缺失,导致创新容易落后于时势,抓不住市场需求,徒然耗尽公司的资源和时机。

无论针对新兴市场的探索模式,抑或针对已有业务的拓展模式,商业产品的创新需要打通从概念到开发、运营的端到端闭环,形成快速的反馈。如何能够有效地支撑精益的商业产品创新?作为组织的CIO,需要尽早解决两个关键挑战:

  • 如何快速构建可工作的产品?
  • 如何快速验证并推广产品的概念?

幸运的是,随着技术的爆发式发展以及技术标准的演进,组织的CIO们有了更丰富的选择和更高效的工具。

云加速商业创新的构建交付

在IT技术领域,集约化与专业化成为技术服务市场的发展趋势。越来越多的专业软件服务团队颠覆起传统的基础设施或者软件服务,开发并公开运营标准的服务组件或者云服务,建立起庞大的生态系统。据ProgrammableWeb统计,截止2014年公共API(Application Programming Interface,应用编程接口 )的数量超过了10000项 。据分析公司Bessemer的统计,市场上存在着数百家成熟的云服务厂商在提供各类云服务,涵盖了从开发者服务到最终用户服务的各类场景。

以云计算的引领者Amazon WebService为例,我们来看看云服务提供了哪些产品服务 :

emagazine pics-10图2. 亚马逊云产品服务(信息来源:https://aws.amazon.com/products/)

  • 快速的研发测试环境:AWS EC2弹性云主机将一台新服务器的创建缩短到1分钟,基于Docker(容器虚拟化)的EC2 Container Service则能在几秒钟内启动数千个容器。
  • 高可用的弹性生产环境运维:AWS EC2满足99.997%的SLA服务标准成本降低到每小时只有数美分
  • 智能的业务流程引擎:AWS Lambda提供了标准的业务流程引擎,基于其API只需要几行程序即可创建一套比较完整的业务处理流程。
  • 丰富的基础性服务:AWS上也提供了移动应用后台平台(简称MBaaS)、物联网IoT SDK、智能分析API等。

借助于标准的云服务与公共API服务,产品创新依赖的诸多功能模块、基础环境、开发活动等都成为「标准件」,产品的构建过程成为了「搭积木」的过程。商业产品创新的构建交付,从某种意义上变成了业务问题,而非单纯的技术问题。

斯情斯景,组织的CIO需要有大智慧,跳出思维定式,将云服务和公共API视为工具箱的一部分,从生态系统的角度来思考产品的构建策略,满足商业创新产品快速构建和投放市场的目标,获得真实用户的反馈和验证。

大数据加速商业创新的分析验证

在传统的商业组织内部,数据的采集、存储、分析和展现往往会由专门的数据分析部门和IT部门来负责。业务部门提出分析的需求和目标。数据分析部门设计相关的数据分析模型。IT部门进行数据的埋点、采集、清洗和结构化。数据分析部门再测试和调整数据模型,争取在一定的拟合度之下,收敛到业务部门的目标。整个周期往往从数周到数月之久,牵扯大量的人员和资源投入,如服务器计算资源、协作成本等,只有很少的组织才能承担

随着大数据技术的成熟,通用的数据挖掘分析算法被数据科学家们封装成了单独的程序模块,数据挖掘分析的门槛大大降低。业界成熟的Google Analytics、Hadoop、Mahout、Spark内置了大量的数据分析算法,能够满足大部分的分析场景和需求。如下图所示,Hadoop生态系统几乎满足了大数据处理的全部场景。

emagazine pics-11

图3.  Hadoop生态系统 (信息来源:http://hadoop.apache.org/)

大数据具体提供了哪些典型功能?

  • 用户行为分析:分析真实用户的真实行为,了解用户「在何时哪个页面离开网站」、「从哪些渠道进入网站」、「购买最多的产品是什么」等;
  • 系统异常分析:分析系统的异常,及时预警,提高系统的可用性和业务连续性;
  • 系统安全审计:分析潜在的安全风险,避免恶意入侵、代码注入等行为。

因此,千人一面的网站服务向个性化转变,单一网站渠道向全渠道转变。粗放的运营管理更加精细化,从Google、Facebook等互联网公司传出的「增长黑客」(Growth Hackcking) 职位成为互联网时代的运营标配。增长黑客们建立产品业务的运营转化模型,专注于通过快速的数据与试错提高业务的用户量、活跃度、粘性等指标的增长。

商业组织拥抱云与大数据的模式

云与大数据对于商业创新的成功发挥着关键性的作用。《荀子•劝学篇》说,「君子生非异也,善假于物也。」善于利用杠杆效用的商业公司,能够避免「重复制造轮子」的成本和风险,从而加速了产品的创新和市场竞争优势的建立。

那么,CIO要如何在组织里面引入成熟的云和大数据技术呢?根据我们的实践经验,商业公司对云与大数据的采纳策略,大体上可以遵循如下的模式:

图4.  企业云与大数据应用模式

  1. 开发测试云模式:以开发测试的环境和流程为应用目的,采用云进行开发测试,大幅节约研发成本,并缩短产品上市时间。
  2. 新业务运维云模式:把所有新的应用和服务都放到云平台,而不再使用遗留基础设施或采购新硬件;利用云的快速弹性提升创新业务的响应性。
  3. 大数据分析云模式:根据计算的需要,快速灵活增减大量分析计算资源,使用大数据平台提供标准的分析算法和API,降低大数据分析对资源的依赖和时间成本。
  4. 移动应用支撑云模式:通过MBaaS等的支持,完成应用的部署、管理,并实时获取管理的参数和指标,能够快速地打造和部署移动应用。
  5. 核心企业级应用云模式:使用云上其它服务商提供的企业级ERP、CRM、数据库等服务,或者将这些企业级应用搬迁上云。
  6. 数据中心云升级模式:借助云服务商实现数据中心的整合、迁移和变更,提升现有数据中心的效率、可用性、可靠性。
  7. 企业整体云化模式:在云平台进行应用的开发,进行混合云的部署等,将通用的IT能力抽象为统一的云平台,应用的生命周期只需要使用云提供的服务和API。

云与大数据绝对不是一蹴而就。由于组织文化、能力模型的差异性,所以企业CIO们需要针对自己企业的特点对症下药,选择合适的模式切入。一方面,CIO可以在内部寻找合适的变更种子;另一方面,可以借助于外部业务的压力对云与大数据进行初步的尝试。必要时,企业可以寻找外部专业服务公司的帮助,减少新技术与方法的引入风险,提高云与大数据的落地效率。

商业组织拥抱云与大数据的案例

背景

在互联网金融的浪潮之下,某民营银行希望针对个人客户和企业客户的完整生命周期,为个人和企业客户提供定制化、全方位的惠民服务。围绕着这一目标,该银行采取了诸多创新项目。其中之一便是结合「银行级安保」的概念,采用国密算法向个人与企业客户提供安全可靠的网络保险箱移动互联网产品。

云服务加速了创新产品的构建

该网络保险箱的交付面临着如下的挑战:

  • 如何让产品在3个月之内完成所有模块(手机App、网站、存储等)的上线?
  • 如何让产品满足互联网的用户体验,比如图像、语音识别、社交分享等功能?
  • 如何让产品能够随着用户的增加,无缝扩展存储的容量(目标容量为50T)?

面对上述的挑战,ThoughtWorks推荐该银行其尽可能采用成熟的云产品服务,缩短新产品的上线周期。因此,该银行一方面选择了敏捷开发方法,通过迭代和持续交付减少需求变更以及等待的浪费;另一方面,该银行使用了ScaleWorks云解决方案:

  • 开发测试云,提高了开发测试的效率,减少等待资源的浪费;
  • 混合云,开发、生产分别使用不同服务标准的云平台,提供一致的管理;
  • 分布式云存储节省了昂贵集中式存储的采购,无缝支撑未来的扩展。 此外,该银行还选择了大量的第三方云服务,如card.io提供的银行卡图像识别SaaS云服务,减少了自研的成本和风险。
大数据分析支撑了创新产品的运营

网络保险箱产品上线之后,两个运营的新挑战又浮现出来:

  • 产品App的性能如何优化,提升用户的体验?
  • 用户的行为数据如何挖掘,提升产品的用户数和规模?

该银行将应用的日志和其他运行的数据一起采集、汇总,使用ScaleWorks Analytics大数据方案进行分析。ThoughtWorks的数据专家与该银行的业务人员、运营人员以及开发人员沟通,对采集的数据进行清洗、结构化、分析和可视化,设计了「产品是否存在性能瓶颈」、「用户量是否保持增长」、「用户活跃度是否保持活跃」、「用户来自哪些渠道」等一系列指标。

结果

三个月之后,互联网保险箱产品顺利完成了上线。仅在上线第一周,超过100个真实用户,上传了接近10G的文件量——完成了产品从0到1的跨越。该银行的CIO表示,「没有云和大数据,我们不可能在短短三个月之内完成产品的上线和推广。」

结语

由于来自新兴商业公司的「门外的野蛮人」 ,商业公司面临着比以往任何时候更大的压力和挑战。「生存,还是死亡?」在这个竞争异常激烈的时代生存,CIO乃至CEO都需要更加深刻地意识到创新的紧迫性。如何提高商业创新的效率和效果,在云与大数据的时代,CIO需要更加深刻地认识到技术的价值。引入合适的技术和工具,借助外部专业服务公司的能力,在商业公司内部打通端到端的创新从概念到落地、到运营的闭环,是CIO乃至CEO的最高优先级之一。

《荀子•儒效》中提出,「不闻不若闻之,闻之不若见之,见之不若知之,知之不若行之」。商业公司的管理者们,「一万年太久,只争朝夕」,是时候拿起云与大数据的加速杠杆,让自己立于市场竞争的不败之地了!

Share

小数据:理论和架构

大数据是当下最热门的IT主题之一。据麦肯锡的分析,大数据能使信息更透明、能让决策者获得更精确翔实的绩效信息、能针对客户群体提供更准确的定制、能提升组织决策能力、能帮助开发下一代产品和服务。新时代里与互联网联结的组织不论大小,都需要这些能力。

然而与此同时,大数据的“大”并非适用于所有组织。Gartner认为,大数据具有“3V”的特征:多样性(Variety),数据来自多种不同来源、具有多种不同形态;速度(Velocity),数据形态和呈现形式的变化快且频繁;量级(Volume),数据量非常巨大。然而对于众多的中小型企业及非营利组织而言,这三个特征有两个未必适用。很多中小型组织只有为数不多的几个IT系统,数据都保存在为数不多的几个关系型数据库中,数据量不超过数百万条记录。只有变化速度快这一特征,对于中小型组织仍然适用。从这个意义上,这些中小型组织需要的是一个“小数据”解决方案:

小数据:聚焦中小型组织和新兴业务,在数据量较小、数据来源较简单的情况下,提供非常灵活、非常简便易用、使用过程中对IT技能要求非常低的数据分析和商业智能,为应对多变且未知的外部环境提供决策支持。

传统上,很多小数据场景的分析和商业智能需求以“报表”的形式呈现在IT项目中:在开发OLTP系统的项目中列出一组报表需求,由交付OLTP系统的团队以直接SQL查询的形式实现报表。这种做法贴合了数据量小、数据来源简单的特征,但损失了灵活性,报表的定制和修改需要技术人员介入,因此又无法满足对速度的要求。为了赢得灵活性,小数据分析也同样需要首先建模OLAP Cube,然后通过不同维度的切片和钻取进行分析。

什么是Cube?按照维度建模方法,数据可以分为“事实”和“维度”两类。事实数据代表“发生了什么事”,维度数据则从各个角度描述这件事。如果以电商为例,事实数据是“销售记录”(卖了一个东西),常见的维度数据可能包括“产品”(卖的是什么)、“门店”(在哪里卖的)、“时间”(什么时候卖的)、“售货员”(谁卖的)、“顾客”(卖给了谁)等等。不难想象,事实数据表将只有一个主键、一个值、以及一大堆外键指向各个维度表;维度表也可能有外键再指向更多的描述性的子维度表(例如“产品”有外键指向“类别”)。于是我们就会得到一个星型表结构(或叫雪花型表结构)。

Star-schema-example

 

星型表结构的优势在于,分析操作会变得非常简单:你关心哪些信息,就直接用JOIN子句把这些维度表关联进来;只要在JOIN子句里指定WHERE条件,就可以快速缩减结果集。在星型表结构里,一个事实会被若干个维度修饰,因此可以把整个数据集想象成一个立方体(或超立方体,当维度多于三个时)。例如当只考虑“产品”、“城市”、“时间”这三个维度时,“销售记录”的数据集就可以被建模为一个立方体。

QQ20160126-0@2x

随后就可以在这个立方体上对数据进行各种分析。例如你可以锁定“城市”这一维度,从而得到“某城市各种产品历史销售报表”——“锁定某一维度取值”这一操作也叫“切片”(slice),因为它在这个例子中产生的效果就是从三维的立方体中切出一个二维的数据平面。同样的,我们也可以从“产品”维度切片,从而得到“某产品各市历史销售报表”。当维度具有“分级汇聚”的特性时,我们还可以进行“钻取”(drill)操作,例如当“地区”维度分为“市”和“省”两级时,我们就可以在“地区”维度上进行钻取:首先从产品维度切片得到“某产品各省历史销售报表”,然后选择一个省下钻得到“某产品在某省内各市历史销售报表”。

小数据系统设计原则1:建模一个Cube,就可以快速实现一系列分析操作(及对应的报表)。小数据系统应该支持简便且易于修改的Cube建模。

基于这个设计原则,我们可以大概推知小数据系统的架构:首先,根据指定的Cube描述信息,把业务数据建模成Cube;然后,通过RESTful API对Cube进行切片、钻取和聚合等操作,并取回二维平面表或透视表形式的结果集;最后,根据指定的报表定义信息,把结果集渲染成报表。

architecture

从上图不难看出,在这个架构中,必须由用户(不论是开发者或最终用户)提供的信息只有三项:(1)Cube的描述;(2)数据分析操作对应的URL;(3)呈现分析结果的报表定义。并且第三项信息(即报表定义)与具体业务是完全解耦的,因此理应可以用分别的开源软件组合形成轻量级的小数据解决方案。在下一篇文章中,我将具体介绍一个基于开源软件的小数据解决方案实现。

Share