透明思考


Transparent Thoughts


  1. 数字化企业的交付基础设施

    前文中我们说到,传统企业在逐步建设自己的数字平台过程中,需要抓住交付基础设施、API和架构治理、数据自服务、创新实验基础设施和监控体系、用户触点技术这五个支柱。那么,当我们谈“交付基础设施”,我们究竟在谈什么?怎样的交付基础设施能加速数字化项目的交付?

    什么是交付基础设施

    云时代的研发环境应该以原生支持云计算的方式提供、管理和维护。在提供基础的弹性计算能力的IaaS平台之上,交付基础设施负责为交付团队提供便利的、最好是自助式的工作环境,让交付团队专注于交付软件的功能性需求,而不必操心软件功能之外的“脚手架”工作。按照ThoughtWorks数字平台战略的定义,这些脚手架包括:

    • 弹性基础设施,即交付团队使用底层云计算平台的方式,既包括各种虚拟机和镜像的管理,也包括生产环境的水平伸缩能力。
    • 持续交付流水线,交付团队编写的代码需要通过这条流水线最终变成可以上线运行的软件。
    • 部署运行时,软件在开发、测试、试运行、用户验收、培训、生产等各种环境需要部署的环境。
    • 监控,为交付团队提供生产环境(及其他环境)的可观测性,方便他们发现和解决问题。
    • 安全,把安全内建在软件的研发过程中,尽量避免因为人为失误造成安全隐患。

    从前这些交付基础设施脚手架通常是由每个交付团队的技术领导者(Tech Lead)来负责搭建和维护的。并且由于软硬件资源的稀缺和不灵活,团队经常需要微调自己的实践来适应不同的环境。所以,即使在同一家公司,各支团队所使用的交付基础设施也可能大相径庭。交付基础设施不一致、不规范的情况会迫使团队花费额外的精力去操心脚手架工作,并且使最佳实践不易推广普及。走上数字化道路的企业必定有大量的软件项目,尤其是微服务架构风格的引入会使企业拥有数量更多、单体规模更小的软件应用,此时交付基础设施不一致、不规范的情况就会对企业的数字化进程带来更大的阻力。

    云计算带来的弹性和灵活性让组织级的交付基础设施标准化、规范化成为可能。一个跨越项目团队的、组织级的交付基础设施团队现在可以在IaaS的基础上封装标准的脚手架,甚至把脚手架本身以PaaS的形式提供给交付团队。通过把整个企业优秀技术领导者的知识与经验内嵌在交付基础设施脚手架中,就降低了对单个交付团队的技术要求,帮助企业缓解优秀技术领导者难以获得的人才挑战。从这个意义上,以PaaS形式提供的交付基础设施本质上是技术领导者作为服务(Tech Lead as a Service)的云计算应用形式,它解决的是优秀技术人才的弹性和灵活性问题,让企业能够以一种创新的方式使用这些人才。

    架构师写代码吗?

    关于“架构师是否应该写代码”这个问题,业界有各种不同的声音。在敏捷的社区里,意见倾向于认为架构师需要写代码,因为这是他们获得关于技术决策的反馈和建立技术领导力的重要方式。将交付基础设施明确提出来,就给了架构师又一个清晰的编程目标——他们需要用代码的形式描述软件交付中的基础设施和最佳实践。除了培训、开会、代码评审等我们已经知道效率并不太高的方式以外,架构师对交付团队的指导和监管现在可以用实实在在的代码来承载。当交付团队不理解架构师说的某件事应该怎么做,现在他们更有理由要求架构师“show me the code”。

    交付基础设施解读

    下面我们来看看,在“交付基础设施”这顶帽子下面,架构师/技术领导者们究竟应该关心哪些问题,又有哪些最佳实践应该被纳入他们的视线。

    弹性基础设施

    允许交付随需获得计算能力。在微服务语境下,这种弹性有两层常见的含义:在生产环境下,服务可以随负载动态获得和释放计算资源,从而更高效地使用计算资源,更自动化地应对负载变化;在研发环境下,开发、测试、运维等不同角色可以随需动态获得完整的环境,从而统一环境、标准化研发实践、规范化研发能力,并且给研发提供体验更好的开发环境。

    为了实现弹性基础设施,一方面基础设施需要支持弹性,例如使用支持弹性计算的公有/私有云,并且有对生产环境的监控和自动化手段;另一方面应用本身需要有可扩展性,例如服务能分别独立部署、无状态化、容器化、有透明的前端负载均衡机制。有状态服务(比如数据库服务)的弹性伸缩问题是特别需要考虑的重要挑战。

    持续交付流水线

    用持续交付实践打通微服务的开发、构建、验证和部署流程。在数字化、服务化的背景下,众多互相依赖的微服务形成的系统架构,对构建、验证和部署造成更大的压力:各个服务有独立的代码库和构建流程,又需要随时能组合成可用的软件;构建产物需要有统一的存储管理;完整的运行时环境应该能按需获得;配置和部署应该能快速准确地完成。

    为了应对这些挑战,交付基础设施中应该包含完整的持续交付概念:流水线、环境管理、构建产物管理等。应该鼓励对服务虚拟化,最好是每个主机运行一个微服务,而不共享使用主机。应该包含配置自动化工具,例如Chef、Puppet等。在服务化的背景下,持续交付流水线需要体现服务间的依赖关系和团队间的协作关系,设计一个运转良好的流水线不是容易的任务。

    部署运行时

    交付基础设施应该包含生产系统所使用的运行时环境,并把生产环境前向拉通到验证和研发环节。为了在研发流程的出口得到服务化友好的交付物,最好是在整个开发过程中一直使用与生产环境近似的环境。例如开发人员应该使用全套环境随时验证,自动化测试和手工测试都基于全套环境开展。在这种情况下,环境的设置、管理、更新不可能由每个开发人员和测试人员自己进行,所以环境的管理更新必定是集中进行的,环境的设置必定是自动化的。

    在《技术栈管理:云时代的研发环境》一文中,我们已经介绍过“一个平台、两个PaaS服务、三个运行时环境”的技术栈管理理念。特别需要注意的是,如何将生产数据拉通到验证和研发环节。

    监控

    在微服务架构中,系统由多个小服务组成,且广泛使用异步通信,使问题和故障更难定位。因此交付基础设施需要提供全面可靠的监控机制,帮助交付团队了解系统的整体状况。

    监控的实现涉及日志、服务指标跟踪、业务语义综合监控等方式。在云环境下如何划分和管理监控的层级,监控系统如何无侵入的在各个微服务体系中收集故障和信息,如何有效管理监控的反馈环,如何在前后端分离和移动应用情况下收集和监控客户端日志,都是常见的挑战。

    安全

    当数字化、服务化IT系统的数量剧增,安全的设置会变得更加复杂。在微服务架构下,系统的安全性需要有一个整体的考虑。例如单点登录、服务间的身份验证和授权、各种防御措施等安全考量不应该下放到交付团队,而应该被涵盖在交付基础设施中统一提供、统一管理、统一更新。

    交付基础设施还应该鼓励安全实践内建(Build Security In),例如团队应该熟悉OWASP安全列表和测试框架、需求分析中应该包含安全需求和恶意用户需求、测试过程中应该包含安全性测试、应该进行自动化安全性测试并纳入持续交付流水线。这些流程与工作方法虽然不能完全以软件代码的形式承载,但它们同样是交付基础设施的重要组成部分。

    小结

    数字化、服务化的IT大背景会让企业开发和拥有的IT系统数量剧增。当企业IT交付更多地以“两个pizza团队”的形式组织,依赖于每个交付团队的技术领导者来搭建和维护一套完整高效的交付基础设施脚手架,这种期望即使不是完全不现实,也会对企业的人才积累提出非常高的要求。因此,企业应该集中优秀的技术人才(包括架构师们),打造一套标准的交付基础设施,充分考虑生产环境与研发环境的弹性、持续交付、部署运行时的统一、监控、安全等因素,并借助云计算的弹性和灵活性将其提供给交付团队。用便利的脚手架赋能一支能快速交付的团队,这是企业的数字化旅程的第一步。


  2. 技术栈管理与云时代的持续集成

    在刚刚发布的第16期技术雷达中,我们看到ThoughtWorks在“技术”象限里旗帜鲜明地列举了几项与持续集成相关的反模式。这些存在多年的实践和现象被放在了“暂缓”一环中,意味着ThoughtWorks正式向我们的客户指出:如果你的组织仍在这样实施持续集成,我们认为你应该考虑改变了。那么,这些被批评的点背后映射出哪些问题,基于技术栈管理的云时代研发环境又能带来什么新的思路?我们一起来深入分析。

    持续集成的反模式

    最需要被点名批评的现象莫过于“持续集成剧场”了:

    很多开发者只是简单的搭建了持续集成服务器就以为在做“持续集成”,但他们实际上会遗失持续集成的关键优点而导致失败。常见的失败模式包括:虽然在一个共享的主分支上运行持续集成,但是代码提交不频繁,所以集成并没有真正的“持续”。以及在一个测试覆盖率不足,甚至是长期状态为红的情况下进行构建;或者在功能分支上运行持续集成,这会导致持续隔离。

    简而言之,这些团队并没有真正体会到持续集成的好处,而是为了完成上级的任务而演一场“我们在持续集成”的戏——这也正是这个反模式的名字由来。过去十年中,我们在众多刚开始实施持续集成的企业见过这一幕。领导认识到持续集成的好处,但是推行成了个大问题:推轻了,下面团队不愿动,技术问题解决不了;推重了,下面团队来个上有政策下有对策,领导想看什么就给你演什么——持续集成剧场就此落成。比如说你见过一个表面看起来一直是绿色但是背后连编译都不敢跑的持续集成吗?我见过。真是一场好戏。

    为了解决持续集成演戏的问题,一些规模较大的企业开始建设持续集成中心。想法很符合直觉:既然团队自己做持续集成有技术困难、还有可能变成演戏,那么我就组建一支团队专门帮他们一个个把持续集成跑通、帮他们管理持续集成服务器,持续集成的运行和统计数据都在这个中央团队手里,下面的团队总没办法演戏了吧?于是,他们又遭遇了第二个持续集成反模式:“所有团队共用一个持续集成实例”。

    那些必须使用中心化持续集成服务器的交付团队,常常依赖中心的团队去完成小的配置任务,或者在共享的基础设置和工具中排查问题,这给他们在进度上带来长时间的滞后。

    这次是康威定律带来的困难:如果每个团队使用的技术栈配置不同、技术栈配置和管理的职责仍然在每个团队中,那么技术栈演进与持续集成的演进就难免出现节拍不一致。于是管理着持续集成中心的中央团队开始疲于奔命,帮一个个项目团队修持续集成,而项目团队还感到没有得到足够的支持。

    第三个反模式是“企业级集成测试环境”,这也是很多组织建设持续集成中心的初衷之一:由于能执行完整端到端测试的环境稀缺,各个团队的集成测试无论如何也必须在一个瓶颈处统一调度,所以中心化管理持续集成也就顺理成章。然而,

    这些企业集成测试环境通常称为 SIT 或预生产环境)是当下持续交付常见的瓶颈。环境本身很脆弱而且维护成本很高,而这些环境通常存在一些需要由单独的环境管理团队手动配置的组件。在预生产环境的测试给出的反馈慢且不可靠,而且会重复测试那些在隔离的组件上已经测过的功能。

    云时代的新思考

    技术雷达中批评的这些持续集成的反模式,是过去的时代背景造就的。尤其是以下几点约束条件,造成了今天我们看到的持续集成的形态(以及长久以来存在的挑战):

    1. 计算资源短缺。这个约束条件决定了完整的、与生产环境相似的、能执行端到端验证的环境必定是稀缺品,因此一个组织中多个团队的集成必定会受限于某个瓶颈,或是企业级集成测试环境、或是持续集成中心。
    2. 计算环境没有弹性。不仅硬件资源短缺,而且环境的开通、配置和管理很麻烦,所以团队会调整自己的技术实践去适应已有的环境,而这个调整的动作主要由团队内的技术领导者来执行。其结果是即便多个团队开发的软件在技术栈上非常相似,他们的持续集成实践也可能相当不同,在技术能力不足的团队就会变成持续集成剧场。
    3. 版本控制工具的局限性。Subversion(以及其他更早的版本控制工具)在pre-commit阶段通过服务器端回调钩子很难——如果不是完全不可能的话——得到完整的“提交后版本”,因此svn的pre-commit钩子基本只能用于检查提交信息是否符合规范,完整的验证则必须在代码已经合入代码库之后才能——在一台独立的“持续集成服务器”上——进行,而此时如果构建失败就会阻塞整个团队的工作。这也导致更多的团队倾向于放松持续集成的要求、甚至沦落成持续集成剧场。

    而这几个约束条件在今天的时代背景下已经不复存在:计算资源仍然不能说极大丰富,但企业应用开发所需的x86架构计算资源在云环境下已经不再短缺;在IaaS的基础上,技术栈管理的PaaS提供了计算环境的弹性,使用相同技术栈的多个团队可以轻易地获得完全一样的环境,因此团队也可以采用标准的技术实践,而不必为了将就手边的环境而调整实践。而git对svn的全面取代尤为值得玩味:由于可以在pre-commit阶段直接获得完整的待提交快照、并在这个版本基础上执行测试,不符合持续集成要求的代码将直接被拒绝提交——而不是在提交后才把问题暴露出来。于是,以下两个要素的结合:

    1. 每个开发人员(以及自动构建)都可以在PaaS云上获得完整的技术栈运行时环境;以及,
    2. pre-commit阶段可以对待提交的代码进行完整的构建

    将带来两个重要的影响。首先,持续集成不再需要一个“服务器”。从它发展的早期开始,持续集成这个概念就一直与各种“持续集成服务器”软件工具紧密关联:从早期的CruiseControl、Bamboo到后来的Jenkins、GoCD,以及云上提供服务的TravisCI、SnapCI,持续集成中的“集成”这个动作一直发生在代码已经提交之后、发生在一个团队共有的服务器上。而现在,持续集成可以在代码提交之前发生、在一个从PaaS云上弹性生成的环境中发生。

    这个技术性的改变带来的组织性改变将有着重要的意义:保证持续集成通过将会彻底变成每个开发人员自己的责任,没有折扣可打,没有其他地方可以推卸责任——现在构建不通过不会阻碍其他人提交代码了,只有这个开发人员自己不能提交代码。由此,持续集成将由一项团队实践变成一项个人实践、由一项有较大妥协空间的实践变成一项强制性的实践。正如IntelliJ之类现代IDE把“通过编译”这项要求变成了程序员感知不到的、而又不可妥协的质量要求,技术栈管理PaaS平台将把持续集成也变成程序员感知不到的、而又不可妥协的质量要求。

    持续集成是如此重要,以至于我们不应该把它交给程序员自己去做。

    在这样的一个研发环境下,每个开发人员从写下第一行代码开始就必须遵循组织的质量规范,能够被提交到团队代码库的代码都是通过了验证流程、符合质量要求的。6年前当我构想这样一个研发环境,我觉得它更像是一个遥远的梦想。然而今天,支持这样研发环境的技术栈管理PaaS平台已经被实现出来了。你需要的就是在你的研发云上实施它。


  3. 什么是数字平台战略

    传统企业正在面临IT新技术的挑战——单从“传统企业”这个居高临下的称谓,你就能读出“非传统企业”(也就是IT企业、互联网企业)满满的优越感。每天在各种新媒体平台看着BAT们又掌握了什么黑科技、又颠覆了哪个行业,“云大物移”已经成了高频出现的热词,传统企业们愈发清晰地感受到IT的重要性与挑战。数字化浪潮躲不过,和BAT拼技术又拼不过,传统企业的出路在哪里?

    目光投向大洋彼岸,最传统的传统企业、年收入数千亿美元的沃尔玛在过去几年中的数字化历程颇有可玩味之处。直到2011年,沃尔玛还不是出色的数字化玩家,只能算有个电商网站的线下零售商而已。正因为如此,当沃尔玛的电商收入在2011年至2014年的三年间增长150%、从年销量49亿美元增长到122亿美元、超过史泰博(Staples)成为亚马逊和苹果之后美国第三大在线零售商时,这一变化才更令人惊叹。像沃尔玛一样的数字化转型先行者,能给我们带来哪些启示?

    数字化企业的三个关键字

    首先,传统企业们需要清楚一件事:“传统”不应该是贬义词,它同时意味着数十年积累的宝贵资产,包括客户关系、数据、品牌形象、供应链、渠道等等。传统企业要在互联网时代的竞争环境中占得一席之地,靠的不是突破最高精尖的技术领域,而是以数字化的形式激活自己多年累积的核心资产,将核心资产转变为可以在互联网上使用的服务,使其焕发新的价值。

    对众多成功的数字化企业的调研显示,这些企业有着一些引人注目的共性。在“激活核心资产”的过程中,他们对三个关键字的关注特别值得我们关注:IT效能;生态系统;创新实验。

    首先,这些成功的数字化企业重视提升IT团队的效能。正如ThoughtWorks在第16期技术雷达中所指出的,技术人员的工作体验正在成为科技企业的差异化竞争优势。这里所说的“体验”不止是给程序员舒适的座椅和人体工学键盘,更重要的是消除IT团队在工作中遇到的阻力和摩擦,尤其是充分利用云计算的弹性能力大量简化和自动化与实现业务功能无关的基础设施性工作,让IT团队将注意力集中在真正与业务相关的工作上。这里涉及的一些技术和实践(例如技术栈管理)乍听起来可能困难重重,但为提升IT团队效能付出的成本终将物有所值。

    随后,这些成功的数字化企业把他们的核心商业能力与资产以服务的形式在互联网上提供出来,构建本行业的数字化生态系统,使新的服务和产品能够在这些服务的基础上被创造出来。同样是在技术雷达中,我们看到了“平台的崛起”:几年前只有亚马逊这样的巨头企业能在互联网上提供各种云服务;而现在有更多原本不太有“互联网基因”的企业围绕自己的核心资产建立起了数字化平台,不仅对内、而且对外提供服务。在国内,我们看到华为把软件开发能力变成了云服务海航建立了自己的云生态。我们相信,更多的企业也能从核心资产的服务化中受益良多。

    最后但绝非最不重要的,这些成功的数字化企业养成了创新实验的习惯。在互联网中弄潮的经验让他们承认,自己不能预先掌握所有需求、做好所有设计。因此他们转而打造组织的响应力,致力于缩短精益创业的“构建-度量-学习”周期。他们知道成千上万的用户不会明明白白地说自己想要什么功能,于是他们监控用户行为、用A/B测试等方法进行受控实验,用“假说-实验”代替了“需求-实现”,在不断的反馈中完善自己的产品和服务。

    数字平台战略的五大支柱

    以提升IT效能、构建行业生态、促进业务创新为目标,有志于迈出数字化步伐的企业应该立即开始制订自己的数字平台战略蓝图。不要被“平台”和“战略”这样的大词欺骗:这个以增强企业响应力为目标的平台战略不应该是漫长的规划之后建设出一个庞然大物,而应该是迭代的、精益的、价值驱动的。更多的时候,我们谈论的“数字平台”更像是一系列IT技术与实践的落地结合。这些技术与实践有机构成的五个支柱,让数字化的企业能快速交付IT系统、围绕核心资产构建云上生态系统、从线上系统和用户行为中获得洞察、开展受控实验、并为顾客创造全渠道统一的用户体验。在成功的数字化转型案例(例如沃尔玛的案例)中,我们就能看到这五个支柱的投影。

    第一个支柱是支持云和敏捷的交付基础设施。为了让IT团队快速交付,他们使用的基础设施应该具有弹性,开发、测试、运维等不同角色应该可以随需动态获得完整的应用环境,从而统一环境、标准化研发实践、规范化研发能力。他们开发的应用程序应该用持续交付实践打通开发、构建、验证和部署流程,使软件随时处于可发布状态。他们的交付流程中应该内建对安全的考量,而不是依赖最后的整体安全检查。生产系统所使用的运行时环境应该前向拉通到验证和研发环节,保障运行时环境的一致性。需要对系统的IT运维和业务运营进行全面的监控,聚合起来了解系统整体状况。

    第二个支柱是以微服务为核心的API和架构治理。为了鼓励不仅企业内、还包括企业外的开发者在平台上发挥创造力,平台架构和API的设计应该注重开发者体验。在API的背后,应该从业务功能的角度出发划分合理的限界上下文和服务边界,对外提供高内聚低耦合的服务。在服务边界之间,应该考虑使用异步的事件机制实现服务之间的通信,来客观地描述运行时间比较长、甚至本质上不可能立即完成的操作(例如涉及人工操作)。为了方便使用者,应该提供API网关作为所有服务使用者的单一入口点,在API网关背后去处理众多内部IT系统的复杂性。整个API架构应该以微服务的风格呈现,避免典型SOA架构中普遍存在的过于复杂的ESB编排逻辑。

    第三个支柱是允许开发团队数据自服务。为了让业务和研发团队获得关于生产环境、关于线上业务、关于顾客的洞见,他们需要首先定义数据流水线,使数据能够顺畅地流过收集、转换、存储、探索/预测、可视化等阶段,产生业务价值。他们需要用实时的架构和API在短时间内处理大量、非结构化的数据,从中获得洞见,并“实时”影响决策。为了提高应变能力,系统中的数据不做ETL预处理,而是以“生数据”的形式首先存入数据湖,等有了具体的问题要回答时,再去组织和筛选数据,从中找出答案。IT团队会更进一步把数据包装成能供外人使用的产品,让第三方从数据中获得新的洞见与价值。为了支持数据产品的运营,他们需要实现细粒度的身份认证,针对不同的用户身份,授权访问不同范围的数据。

    第四个支柱是创新实验基础设施和监控体系。为了让创新真正基于数据(而非拍脑袋)来开展,IT团队需要从多种来源采集关于系统、关于顾客的数据。需要根据业务目标在系统中埋设监控点,并及时把监控结果可视化呈现给业务用户。为了降低实验试错的风险,在把新版本发布给全部用户之前,应该以“金丝雀发布”的形式首先发布给一小部分用户,确保新版本不造成重大损害。系统需要支持功能切换开关(toggle),允许团队在不修改代码的前提下改变系统的行为,再加上用路由技术支持蓝-绿部署和A/B测试,方可高效地开展受控实验。

    第五个支柱是支持全渠道的用户触点技术。为了通过多样化的触点技术向顾客提供随时随地、连贯一致的用户体验,整个企业需要建立对其顾客和目标顾客的唯一、连贯、准确、整体的视图,从而更好地了解和服务顾客。他们需要结合顾客的特征和不同数字渠道的特征建立连贯的内容策略,在多种渠道(例如电脑、智能手机、门店等)之间引导顾客的消费旅程,与顾客产生正确时间、正确地点、正确方式的交互。基于从各种渠道获得的顾客本人及其行为的数据分析,他们可以向顾客提供定制化的内容、服务和产品推荐。作为必要的技术保障,所有数字渠道的软件应用(尤其是原生的Android和iOS应用)都应该实践持续交付,这样才能实现全渠道的快速响应。

    小结

    在数字化的浪潮面前,传统企业不必恐惧于互联网企业的技术优势。只要抓住交付基础设施、API和架构治理、数据自服务、创新实验基础设施和监控体系、用户触点技术这五个支柱,逐步建设自己的数字平台,不断提升IT效能、构建本行业的数字化生态系统、养成创新实验的习惯,传统企业同样可以用数字技术激活自己多年积累的核心资产,在新的竞争环境中找到自己的一席之地。

    (更多关于数字平台战略的信息,请关注ThoughtWorks数字平台战略网站。)


  4. 云时代的研发环境:实施路径

    前文讲到,在云计算的时代大背景下,我们推荐采用研发技术栈管理平台来集中管理组织中的技术栈,允许基于一个技术栈创建开发测试PaaS和生产PaaS两个PaaS服务,从而支撑开发、测试、生产三种运行时环境。通过三种运行时环境的区分,技术栈管理平台实质上设置了一条标准的精益软件生产流水线,为软件研发生命周期中的三个核心工种——开发、测试、运维——布置了标准的“工位”。在实施技术栈管理平台时,从这三个核心工种之中的任何一个切入,都可以优先建设该工种对应的工位,从而拉动整条云化生产流水线的实施。

    从开发切入,打造规范的软件开发底座

    在数字化的大背景下,众多IT组织都面临技术能力短缺的境况。尤其是传统企业的IT部门,需要用有限的研发专业技能交付越来越多、变化越来越频繁的IT系统,还需要管理外包合作方的团队,对于开发底座规范化的要求日益显著。这些开发团队常见的一些挑战包括:

    • 技术实践能力有限,不能保证每个项目采用业界最佳的框架与工具组合。
    • 开发流程不规范,代码质量关注不够,技术债累积严重。
    • 外包团队管理乏力,对外包团队的开发实践缺乏约束。

    实施技术栈管理平台以后,整个组织可以识别并聚焦几种具有普遍代表性的软件形态(例如“Java微服务”、“Java Web应用”、“安卓移动应用”等),集中技术骨干力量,搭建项目基础架构,以技术栈的形式固化下来。开发团队要启动一个项目时,只需要从技术栈管理的PaaS平台上选择自己需要的技术栈,就可以立即生成自己的构建运行时,其中包括代码仓库、应用基础框架、依赖软件、自动化构建工具等。基于这个构建运行时,开发团队可以基于已经搭好的脚手架立即开始编写代码,并在PaaS云上进行基本的验证,然后提交到团队代码仓库。团队的技术领导者不需要考虑开发环境应该如何配置,开发人员也不需要在自己的电脑上做任何环境准备工作,从而极大地降低了项目启动的技术门槛。

    作为对开发工位的规范要求,技术栈中会规定“提交门”的质量标准,达不到质量标准的代码将无法提交到团队代码库中。这个实践与持续集成一样,都是源自丰田生产方式的“安灯”实践:如果出现质量隐患,应该立即停线修复,而不是让带着质量隐患的生产线继续运转。在一般的开发团队中,提交门的质量标准至少包括(1)代码能通过编译;(2)代码能通过静态质量检查。通过引入代码复杂度、代码规范性检查等基本质量标准,能促使开发团队关注代码质量,避免基本的技术债不断累积。水平较高的团队会在提交门中包含单元测试,单元测试不通过、或单元测试覆盖率达不到标准的代码将无法提交。

    如果需要引入外包团队来协助开发,外包团队可以直接从技术栈管理PaaS服务商获得自己的构建运行时,绝大部分的开发规范可以用提交门验证的形式来承载,从而将组织的质量要求固化到开发环境中,降低规范化管理外包团队的难度和成本。

    在开发工位实施技术栈管理后,随着开发规范化底座的建立和开发阶段质量要求的逐渐提升,开发团队将具备逐步缩短交付周期的能力。随着开发交付周期缩短,待测试、待发布的版本会累积起来,对后续的测试和运维工位形成压力。此时研发管理者应该密切留意测试工位的累积情况。如果测试团队抱怨转测版本太多、人手不足,都反映出工位之间产能失衡的问题。当这一问题出现时,就应该抓住契机,提升测试工位的标准化和自动化程度,使测试工位能跟上开发的交付周期。

    从测试切入,建立云测试平台

    在数字化、互联网化的IT大背景下,软件系统上线的周期不断缩短,两周一迭代已经成为众多团队的标准配置,一些创新型业务已经要求将上线周期缩短到一周、几天、甚至一天几次。不断缩短的上线周期,使很多IT组织在测试方面的问题暴露出来:

    • 测试自动化程度低,手工回归测试跟不上频繁上线的节奏。
    • 测试环境争用,环境管理工作量大。
    • 性能、安全等非功能性需求的测试投入不足,到项目晚期才开始测试。

    如果这些问题是一个组织当前最大的痛点,技术栈管理平台的实施也可以从测试工位开始入手,为整个组织打下坚实的质量保障基础。测试和开发的技术骨干可以一同选择适宜的自动化测试工具,将其连接配置好,准备好自动化测试的脚手架,打包到技术栈的验证运行时中。测试人员只需按照业务需求编写自动化测试例,并放在技术栈中规定的“验证门”环节自动执行。当系统最重要的功能都能被自动化测试覆盖,测试人员就能从繁重的手工回归测试中解脱。

    自动化测试需要可靠且可复制的测试环境来执行,这正是云计算的优势所在。在技术栈管理PaaS中定义了测试运行时环境后,每当测试人员或自动化的验证门要执行自动化测试例时,就会从云中取出一个测试运行时,其中除了被测系统的依赖软件外,还包含了配置好的各种测试工具。被测系统会被加载到测试运行时环境中,执行自动化测试例,收集测试报告,然后测试运行时环境就会被销毁回收。整个过程中不需要测试人员手工管理测试环境,也不需要与其他测试或开发人员共用一套环境。

    一旦测试人员不用“人肉回归”大部分软件功能,他们就可以把更多的精力投入非功能性测试。性能测试、安全性测试等非功能性测试所需的工具集同样可以被内建在技术栈中,方便测试人员日常工作。同时,测试人员还可以把非功能性测试编写成自动化的测试例,将其加入验证门的测试集,从而使非功能性需求也持续得到保障,以免在项目晚期才发现重大性能或安全问题。

    当云测试平台建立起来,有了基本的自动化测试覆盖,测试人员就可以起到质量监督和建议的作用,而不是跟在开发后面做简单重复的手工验证。由于软件产品必须在验证运行时上通过测试,研发管理者就可以借此拉动开发团队使用云测试平台进行自验证,在习惯养成后再逐步在开发过程中推广使用构建运行时,从而用一个技术栈拉通开发和测试的工作环境。

    从运维切入,构建高响应运维能力

    同样,数字化、互联网化的大背景也对运维团队提出了新的挑战。从业务客户的角度,他们不仅希望自己的需求能尽快上线被用户使用,而且还希望及时获得来自用户的反馈,帮助他们做出调整。在一些领先的企业,运维更是能支持业务客户针对真实用户进行快速的受控实验,从而验证自己的业务假设。在这些新的要求下,很多IT组织的运维团队暴露出了能力上的不足:

    • 运维自动化程度低,需要大量手工操作,工作量大,可靠性低,容易出错。
    • 系统监控不完备,出现故障时不能及时发现和快速排错。
    • 生产系统的信息不能快速转换成业务洞见,无法支持频繁的线上受控实验。

    技术栈管理平台的实施同样可以从运维工位入手,以打造高效的DevOps体系为优先目标。

    你说的是哪种DevOps?

    由于历史原因,如今大家在谈起“DevOps”这个词时,其中包含的可能是三重相关但不同的含义:

    1. 如何借助基础设施即服务、运维自动化等手段,加快代码部署到生产环境的速度。
    2. 如何借助日志和监控手段,及时把生产环境的情况反馈到开发团队。
    3. 如何借助端到端的埋点、数据采集、分析和可视化,把用户行为反馈到业务。

    以运维视角优先切入时,技术栈的建设就自然地偏向运维工具。在支持计算资源弹性分配的IaaS层(例如基于ScaleWorks的私有云)之上,将自动化配置管理工具(例如Chef、Puppet、Ansible)及其他常用的运维工具打包在应用运行时中,运维人员可以随时从技术栈管理的PaaS服务中获得完整且配置好的应用运行时,再从通过了测试验证(可能是手工验证)的发布候选版本中选择一个放入应用运行时,即可快速完成应用的部署上线。生产环境的配置以代码形式记录,可以由技术能力较强的DevOps团队专门维护,从而省去了大多数运维人员手动管理运行时环境的工作量与风险。

    在应用运行时环境中,可以根据软件系统的特征预先配置好日志工具(例如ELK、Splunk)和服务指标监控工具(例如Collectd),使开发团队无需额外工作就能获得丰富有用的生产环境信息。一些水平更高的团队会在应用运行时环境中设置更智能化的运维功能(例如基于Hystrix的服务熔断机制),使运维更具响应力。

    应用运行时环境中还可以植入端到端综合语义监控所需的工具设置,从而支持对业务场景埋点和分析,甚至是结合流量路由技术进行受控实验,用数据为业务决策提供支撑。业务有了缩短反馈周期的诉求,运维有了快速响应变化的能力,两端夹击可以倒逼研发环节提升响应力、缩短交付周期,这也是研发组织变革的一个套路。

    运维工位采用技术栈管理平台以后,研发管理者可以从交付物入手倒逼开发和测试环节,要求通过测试的发布候选版本以容器镜像的形式交付,以保证上线效率和可靠性;同时提供基于技术栈管理PaaS的构建和镜像版本管理基础设施,方便开发和测试团队构建符合要求的交付物。等开发和测试团队养成基于云和容器环境的交付方式,就可以逐步实施云测试平台和基于技术栈的开发底座。

    小结

    技术栈管理平台的目标是为现代IT组织创造云环境下的精益软件生产流水线。但对于很多组织而言,这条流水线并非一步到位,而是一个分阶段建设的过程。在这条流水线上,开发-测试-运维三个核心工位都可以成为实施技术栈管理的切入点。从组织当前最显著的痛点出发,选择一个工位开始实施云化的技术栈管理平台,并依循瓶颈理论拉动其他工位的逐步改进,这对于众多不以IT能力见长的组织而言,是一条可行的云化、数字化道路。


  5. 沃尔玛的数字化平台分析

    尽管2009年就已上线了电商平台Marketplace,但直到2011年,沃尔玛在数字化领域也不能算成功者。当时他们的电商网站只有相当基本的功能,用户体验不算方便,搜索不太好用,也不能与店面或供应链无缝对接。之前的几年,沃尔玛的电商收入跟其他零售商(例如西尔斯、梅西)一样缓慢线性增长。正因为如此,当沃尔玛的电商收入在2011年至2014年的三年间增长150%、从年销量49亿美元增长到122亿美元、超过史泰博(Staples)成为亚马逊和苹果之后美国第三大在线零售商时,这一变化才更令人好奇。

    数字化之旅

    沃尔玛的全球电商部门主要有三方面的责任与行动:

    1. 运营沃尔玛全球10个网站,在线提供超过700万种SKU,无缝连接门店与仓库,给顾客提供多种购物选择。
    2. 通过@WalmartLabs这个创新孵化器,不断更新网站和移动应用,利用顾客数据和社交网络洞察预测顾客行为,给顾客提供更好的在线和在店购物体验。
    3. 对内打造沃尔玛的电商能力,在全美国建设线上业务服务中心,建设新的电商操作系统Pangaea。

    为了达到这些目标,沃尔玛在几年中收购了多家IT企业,光是作为创新引擎的@WalmartLabs就收购了14支科技团队,为整个企业的数字化转型提供了能力上和文化上的支撑。2013年,沃尔玛收购了提供云计算解决方案的OneOps公司。该公司拥有成熟的PaaS和私有云IaaS能力,支持多种公有和私有云平台,包括Azure、Rackspace、AWS、OpenStack等,与沃尔玛的云化、服务化趋势相符。到2016年,沃尔玛全公司有超过3000名工程师基于OneOps平台开发和管理IT系统。

    在电商销量猛增的过程中,沃尔玛的IT系统遭遇了性能瓶颈,这也是他们开始将IT系统服务化的重要出发点。他们希望“系统拥有足够的弹性去处理峰值,同时不产生负面的用户体验”。事实证明,微服务架构带来的效果是明显的:

    • 销售提升:转化率在一夜之间提升了20%,移动端的订单立即增长了98%;
    • 可靠性提升:黑色星期五或节礼日等大型购物节期间,再没有出现过宕机;
    • 运维成本降低:将昂贵的硬件换成了便宜的X86服务器,节省了40%的计算资源,总成本下降了20-50%。

    沃尔玛还把自己的数字化能力提供给自己的供应商。2014年,他们上线了自己的广告平台Walmart Exchange(WMX),用自己门店和线上电商的数据帮助供应商更有效地投放广告(包括沃尔玛网站、第三方网站和邮件广告)。

    数字平台战略视角分析

    数字平台战略的角度分析,沃尔玛在构建自己的数字平台能力支柱方面已经取得了令人瞩目的成绩,这也是其电商销量能大幅提升的重要原因。

    交付基础设施

    • 通过将业务系统改造为大量、小规模、无状态的服务,使系统可以部署到廉价服务器的集群上。同时弹性基础设施也允许随需增减计算节点。
    • 没有应用服务器。所有服务以standalone的形式通过docker部署。
    • 全面的监控机制(使用ConductR),当服务失败时能自动响应,并提供排错所需的信息。在集群层面汇集日志,避免需要分别查看每个节点的日志。
    • Akka可以把一个交易建模为一个有穷状态机,可以在中途持久化状态,可以取回状态,提供了一种错误恢复的机制。
    • Akka的监控(supervisor)机制类似于Erlang:“let-it-crash”,不需要假设虚拟机或计算节点可靠。

    API和架构治理

    • 用Play实现API Gateway,以RESTful API的形式为其背后的系统提供统一的入口。
    • 原来的大块系统按照业务领域划分为小块,团队也随之划分,例如搜索团队、商品团队等等。每个bounded context有它自己的词汇表、拥有自己的数据。
    • 服务切分不仅仅是IT系统的事,而是组织、代码、数据库三个层面的重构。一开始不先直接做“硬”的切分,而是先从逻辑上做划分(例如数据库的schema命名规则、代码的包),然后检查是否有循环依赖;等依赖关系逐渐理清了,再分解成独立的服务、独立的数据库、甚至NoSQL数据库。
    • 解决性能问题的主要方式是通过异步操作(使用Akka):把数据库写操作异步化,从而减少对JVM线程的占用,并且使能并行处理,极大地提升系统的性能和可扩展性。

    数据自服务

    • 因为数据量太大,必须改变ETL、数据预处理的思路,对数据做真正意义上的实时处理(使用Akka Streams)。
    • 用Spark对数据进行单件流处理,数据处理的延迟由6小时(ETL过程)缩短到10秒。

    数据方面的架构如图:

    创新实验基础设施

    • 组织层面上,@WalmartLabs是一个创新的孵化器机制。
    • 技术层面上,OneOps提供了路由技术和监控能力,使在线的快速实验成为可能。
    • WMX能统一收集和利用各种渠道(门店和电商)的用户数据。

    客户触点技术

    • @WalmartLabs对整个组织输出全渠道、移动、响应式设计等能力。
    • 沃尔玛的电商平台支持多种客户触点(电脑、移动)。Walmart.com在美国的流量超过一半来自移动设备,Walmart Pay应用部署到4600多家门店。
    • 使用大数据(购买行为、搜索历史等)个性化顾客的交互体验。个性化搜索引擎Polaris提升了20%在线销售转化率。
    • WMX支持单一顾客视图,形成对顾客的全面理解。

    参考材料


  6. 技术栈管理:云时代的研发环境

    前文介绍了云计算大背景对研发环境的影响。我们已经指出,现代IT组织应该把研发技术栈以PaaS的形式提供给开发人员,其中的要点是:

    • 将标准的研发环境封装为虚拟化、云化的技术栈,由技术专家管理维护;
    • 核心业务价值与技术支撑解耦,工程师专注于业务系统的开发;
    • 自动化研发流程,降低研发管理成本。

    如何实现这样一个研发技术栈管理的平台?我们的观点是,这样一个平台应该集中管理组织中的技术栈,允许基于一个技术栈创建开发测试PaaS和生产PaaS两个PaaS服务,从而支撑开发、测试、生产三种运行时环境

    一个平台

    在一个典型的敏捷软件开发场景(例如更具体的“用Java开发微服务”的场景)中,开发者需要频繁地用到下列工具:

    • 编程框架,提供基础的结构与功能来支撑业务逻辑代码,例如Spring Boot和Jersey。
    • 版本控制工具,例如git。
    • 依赖软件,例如PostgreSQL数据库。
    • 自动测试工具,包括单元测试工具(TestNG)和功能测试工具(Concordion、Selenium)。
    • 自动构建工具,Maven或Gradle。
    • 持续集成工具,Jenkins或GoCD。

    所有这些工具以及它们适当的组合与配置,我们把它称为一个技术栈。我们上面的例子就是“Java微服务开发技术栈”,类似的,一个组织中还可以有“Java Web应用开发技术栈”、“H5前端开发技术栈”、“ReactNative移动应用开发技术栈”等等若干个技术栈。对于一般的IT组织而言,有限的几种技术栈就可以覆盖大部分软件项目的形态。体量大如有数万研发员工的某IT巨头,提出的主要技术栈也只有十余种。

    在传统的软件开发团队中,技术栈的组合与配置是由团队的技术领导者负责的。在云计算的大背景下,将基础设施作为源代码的思想再往前推一步,我们就会很自然地得出技术栈作为源代码的想法:使用Docker和Ansible等技术,将技术栈的结构以源代码的形式描述。在“基础设施作为源代码”的阶段我们已经知道,以源代码形式管理环境会带来很多好处,例如更高的自动化程度、允许版本控制等。把技术栈作为源代码以后,会带来几个重要的收益:

    1. 技术栈可以很容易地复用,因此可以把搭建技术栈的工作收拢到较少数技术领导者手中,研发团队则只需在技术栈基础上开发业务功能,降低了研发团队的技能门槛。
    2. 最佳实践可以被内嵌到技术栈中,并通过持续集成的形式对研发团队形成约束,从而使研发改进举措更容易推行。
    3. 缩短研发实践的实验和创新周期,可以对多个研发团队开展受控对比实验,团队中自发产生的优秀实践可以被快速抽取并固化到技术栈中。

    技术栈管理平台作为组织级的研发管理载体,承载的是组织对研发团队的引领和治理形式。在这个平台上,技术领导者会创建并维护技术栈,项目团队则可以根据自己的需要选择适合的技术栈,跳过大部分迭代0的技术准备工作,直接进入功能开发,并在整个产品生命周期中享受云化开发环境带来的收益。

    两个PaaS

    基于已经定义好的技术栈,当项目团队开始研发工作时,技术栈管理平台可以为他们创建两个PaaS服务:一个是研发过程中使用的开发测试PaaS,另一个是真实上线用的生产PaaS。两个PaaS的协作关系如下:

    • 开发人员从开发测试PaaS中获得一个开发环境,在这个环境中编写代码;
    • 新编写的代码被提交到代码库中,后台的服务自动运行“提交门”测试,测试通过后,把代码构建成可运行应用;
    • 后台服务针对可运行应用自动运行“验证门”测试,测试通过后,这个版本的可运行应用即被标记为可发布应用,并被存入构建产物仓库;
    • 测试人员针对通过了“验证门”测试的可发布应用进行必要的手工验证;
    • 生产环境与开发/测试环境基于同一个技术栈(运行时环境上有具体的差别),开发测试PaaS中构建出的可运行应用可以直接部署到生产环境;
    • 随不同组织的发布流程不同,构建产物仓库中的可发布应用可能直接(自动或手动)发布到生产环境,也可能被同步到生产PaaS的产品仓库,以后再手动发布到生产环境。

    可以注意到,这个流程、尤其是在开发测试PaaS中发生的流程,与Dave Farley在《一键发布》文中介绍的持续集成流水线非常相似。我们相信:持续集成对于现代软件开发是如此重要,以至于它不应该以独立的工具形式存在(因为这样人们就有可能不用或者误用)。持续集成应该被内建在软件开发的工具和过程中,使它不被开发者注意、同时又不能被绕开——正如Spring内建了面向接口编程、IntelliJ IDEA内建了编译和代码格式检查。

    三个运行时环境

    前面介绍的流水线已经暗示,在整个软件交付周期中,存在三个不同的运行时环境。这三个运行时环境都有同样的基础,例如操作系统、依赖软件等。同时它们也有一些重要的差异:

    1. 构建运行时:包含开发工具、构建工具和(可能是部分)测试工具,这是开发人员编写代码的主要环境——需要注意,“编写代码”在敏捷软件开发的上下文中意味着“编写代码并频繁进行提交门测试”,这是为什么这个运行时环境中必须包含(至少部分)测试工具。
    2. 验证运行时:包含全部测试工具及其他质量保障工具,这是对软件质量进行全面验证的主要环境。
    3. 应用运行时:包含运维工具,这是软件真正运行的环境。这个运行时可能被应用于生产环境,也可能仅用在组织内部(例如UAT测试环境、培训环境、demo环境等)。这个运行时中的依赖软件(尤其是数据库)也有可能被替换为环境之外独立运行的软件。

    尽管为了支持不同环节的工作要求而有这些差异的存在,底线是:构建运行时构建出来的可运行应用,可以在验证运行时中接受完整的验证,也可以被部署到应用运行时正常运行。这与持续交付中“制成件流过整个流水线”(而非在各个构建步骤中分别生成制成件)的理念是一致的。

    制成件的形式

    前文中我们已经提到:软件包是一种对云环境不友好的交付形式,理想的研发交付物应该是容器镜像(很可能是一组彼此连接的容器镜像),可以在云上直接运行。Docker等容器技术使我们可以把所有软件(不论背后使用什么编程语言、实现什么功能)都抽象为“IP地址+端口”的服务;再加上例如Docker Swarm或Kubernetes之类集群工具的支持,更可以把服务进一步简化为一个端口。于是,技术栈管理的基础设施可以得到更大程度的复用:不同的技术栈(不管编程平台是Java、NodeJS还是Python)构建出的应用都是一个(或一组)Docker镜像,从而将“产物的形态”与“生产流程的结构”解耦。

    小结

    针对前文提出的云计算大背景下对软件研发提出的挑战,本文提议了一种解决方案:技术栈管理平台。通过实施技术栈管理平台,为研发团队提供开发测试PaaS和生产PaaS两个PaaS服务、构建/验证/应用三个运行时环境,研发组织能够将技术栈的搭建和管理与业务系统的研发解耦,从而降低研发团队技能门槛、快速有效地推广研发最佳实践、使研发过程中的技术与流程实验和创新成为可能。


  7. 云时代的研发环境长什么样?

    云计算正在毫无疑问地成为企业IT的主流。据麦肯锡调查,六成以上的企业计划在两年内将某种形式的云作为主要IT平台。在国内银行业,中国银行业信息科技“十三五”发展规划监管指导意见中明确提出:到2020年,国内银行业面向互联网场景的重要信息系统应全部迁移至云计算架构平台,其他系统迁移比例不低于60%。其他行业也有同样的趋势。信息系统云化的大背景给软件系统的研发流程带来了什么挑战,作为软件研发组织的领导者应该如何应对这些挑战?这是本文试图回答的问题。

    首先,有必要回顾云计算给企业IT带来的收益。IBM认为云计算有三大优势:

    1. 更灵活。用户可以根据需要,“弹性地”获得IT服务。
    2. 更高效。减少IT团队管理和维护底层基础设施的工作量,IT服务可以更快推向市场。
    3. 战略价值。通过灵活组合现有IT资产与新兴数字渠道,支撑企业业务创新。

    云计算与虚拟化的区别

    有很多企业已经采用了虚拟化技术:将企业的计算资源(服务器、存储等)集中管理,以虚拟机的形式分配给使用者。虚拟化与云计算的区别在于:虚拟化是指“用软件管理硬件资源”,而云计算是指以虚拟化方式管理硬件资源之后能够对外提供的服务。

    除去这个概念上的差异,我们注意到一些企业在谈论“虚拟化”的时候,背后隐含着一个自动化程度不高的、需要人工参与的虚拟机申请和开通的流程。在这样的流程下,获得一台虚拟主机需要的时间通常以天计。因此,虚拟机的使用者倾向于预先申请虚拟主机并长期占用。在这种情况下,“虚拟化”往往意味着缺乏弹性(elasticity)的计算资源分配——尽管虚拟化技术本身并不妨碍弹性。

    可以看出,为了兑现云计算的三大优势,企业IT系统必须云化:软件的形态由从前需要在本地安装的软件包,转变为透过网络在线使用的服务,让使用者随时能够获得;原来体型巨大的单体(monolithic)应用,需要转变为细粒度的服务,从而支持灵活的组合与复用。

    原来习惯了开发本地安装的软件包和/或巨大的单体应用的研发团队,现在要转为开发云化的软件服务,这个转变并非总是无痛的。首先,研发交付物的形态应该是对云环境友好的。从前研发交付物通常是以软件包的形式提供给用户或是运维团队,例如平台特定的JAR、WAR、EGG等软件包,或是RPM、DEB、MSI等操作系统特定的软件包。软件包是一种对云环境不友好的交付形式,因为它没有包含软件运行的环境。例如一个软件需要用到PostgreSQL数据库和monit作为监控工具,平台特定的软件包无法确保这些软件依赖的存在;某些操作系统特定的软件包可以描述软件依赖,但也无法确保依赖软件被正确地配置。过去一段时间里,自动化的配置工具(例如Chef/Puppet/Ansible)被用于解决运行时环境的问题。而在今天的技术背景下,理想的研发交付物应该是容器镜像(很可能是一组彼此连接的容器镜像),可以在云上直接运行。

    对研发交付物的要求随即会影响到研发过程。为了在研发流程的出口得到服务化友好的交付物,最好是在整个开发过程中一直使用与生产环境近似的环境。例如开发人员应该使用全套环境随时验证,自动化测试和手工测试都基于全套环境开展。在这种情况下,环境的设置、管理、更新不可能由每个开发人员和测试人员自己进行,所以环境的管理更新必定是集中进行的,环境的设置必定是自动化的。而且,如果环境固定分配、长期使用,对计算资源的占用可能很大,所以环境应该是云化的、弹性的、按需获得的。

    云计算的大背景还会影响研发实践。为了降低搭建研发环境的技术难度,云化的研发环境应该内建研发工具链(包含开发工具、质量保障工具、持续集成/持续交付工具、DevOps工具、项目管理工具等)。为了规范团队研发质量水平,良好的研发实践(例如代码静态检查、自动化测试等)和流程要求应该固化在工具的日常操作中。理想的情况下,研发团队应该只聚焦关注业务功能开发。开发工具的组合、生产环境的配置、持续集成和持续交付流水线的搭建等工作都应该被标准化和自动化。

    综上所述,在云计算的大背景下,IT组织需要将更多的软件应用部署在云上。云化的IT系统对软件研发的交付物、研发过程、研发实践都提出了新的要求。我们认为:现代IT组织应该从研发环节开始,以原生支持云计算的方式提供、管理和维护研发环境,从而在研发过程中利用云环境的弹性,确保研发交付物对云环境友好,并把优秀的研发实践和流程要求内嵌到研发环境之中。IT组织可以通过以下方式管理其研发环境:

    • 将标准的研发环境封装为虚拟化、云化的技术栈,由技术专家管理维护;
    • 核心业务价值与技术支撑解耦,工程师专注于业务系统的开发;
    • 自动化研发流程,降低研发管理成本。

    在下一篇文章里,我将介绍如何具体实现技术栈的云化管理,把研发技术栈以PaaS的形式提供给开发人员。


  8. Cybersyn的系统架构

    前文《半个世纪前的大数据时代》讲到,1970年代初,英国的控制论学者斯塔福·比尔应阿连德总统之邀,远赴智利去开发一套用于管理国有经济的大数据IT系统。本文将介绍这套远远超前于时代的系统是如何在当时的技术条件下架构和建设起来的。

    生产大战中的控制论

    在阿连德执政的第⼀年,智利政府开始将国内最重要的⼀些⼯业收归国有。到1971年底,政府已经把所有主要矿业公司和68家最重要的⼯⼚由私有转为公有。智利正在打⼀场“⽣产⼤战”,提⾼⼯业⽣产⽔平被视为智利社会主义成功的关键。管理已经成为国有化进程的⼀个核⼼问题,政府计划把⼯业管理作为第⼆年的⼯作重⼼。国有经济的⾼速发展创造了⼀个笨重的、智利政府从未⻅过的怪兽,这是问题的根本所在。

    在这样的大背景下,斯塔福·⽐尔于1971年11⽉4⽇星期⼆抵达智利,邀请他的是智利国家开发公司(CORFO)的技术主管费尔南多·弗洛雷斯。经过弗洛雷斯的介绍,比尔对智利面临的挑战有了一个大体的理解。控制论思考帮他识别出如何改进智利政府管理经济的⽅式。例如,⽐尔发现政府可以建⽴新的通信渠道,促进数据交换,提升政府决策速度。同时他也认识到⾃⼰⾯临的约束。成⽴新的政府部⻔或是对现有政府机关进⾏根本性重组可能可以极⼤提升管理能⼒,但当前的关键是要快速⻅效,政府没有时间来成⽴新的调控部⻔,也⽆法⼤规模修正和重建现有的机构。

    在⽐尔和弗洛雷斯的构想中,控制论科学扮演着双重⾓⾊。控制论的管理视⾓,尤其是可⽣存系统模型,能够指导CORFO所需的组织变⾰、避免实施⻓远来看低效甚⾄有害的权宜之计。同时,控制论中关于反馈与掌控的思想能够指导开发⼀套新的科技系统来改善国有经济的管理,从⻋间直到CORFO办公室。发源于⽐尔的“⾃由机器”思想,这样⼀个系统将会搭建起实时信息交换的网络,其中会⽤到⼤型主机技术。管理者和政府官员将能够基于实时数据来做决策,并能够快速调整⾏动⽽不被政府官僚体系束缚。管理控制论还能改善政府从国营企业获取信息的⽅式。当这些数据流得到改善,弗洛雷斯和⽐尔相信政府能加强对智利⼯业的管控,并最终赢得⽣产⼤战。

    基于这一构想,比尔提议建设Cyberstride项目,后来这个项目改名为“Cybersyn”。Cybersyn系统结合了比尔早期著作中的思想,包括他的文章《自由机器》中提到过的控制室。这个系统将依赖于每天从国有产业采集来的数据,用大型主机对未来经济行为进行统计学预测。随着智利的计算机操作员输入更多来自企业的最新数据,系统每天都会对预测做出更新。

    只有一台计算机的网络

    Cybersyn的骨干是一个支持实时数据交换的通信网络。将国家开发公司(CORFO)与工厂车间连接起来,就能建立“向上滚动”式管理所需的条件,使政府能够快速处理诸如原材料短缺等紧急状况,并及时调整政策。最新的生产数据还让经验丰富的管理者(通常位于行业委员会或更高的级别)能帮助缺乏经验的干预者识别他们工厂里的问题,并在必要时调整生产行为以达到国家的目标。按照比尔的构想,这种信息交换会以很快的速度持续发生,并且总是以指导行动为目标。通信、适应和行动,这些都是管理控制论的核心要素,它们就是比尔在组织与生物有机体之间发现的共性:两者都需要快速适应,才能在变动的环境中生存。弗洛雷斯与比尔一样重视时间,两人都认为:数据如果不能指导行动,那就是被浪费了。

    除了通信网络和用于生成经济预测的软件,Cybersyn项目还需要一个计算机程序来模拟智利经济。另外,CORFO成员会把生产数据汇总,并以直观的形式显示在指挥室里,以便政府的决策者理解。这些数据显示会帮助决策者看清国家经济形势,并基于智利工业的现状制定政策。

    按照比尔的提议,Cybersyn项目的设计考虑到了智利科技的局限。国家计算机公司(ECOM)的主管雷蒙多·贝卡只给比尔提供了一台大型主机的处理时间,这是一台IBM 360/50,ECOM当时性能最强的主机。鉴于计算机公司只有4台主机,全都非常繁忙,贝卡只能提供一台机器是完全能理解的。但这就意味着比尔的团队必须用一台计算机来建设一个计算机网络。

    对这个看似不可能的要求,比尔给出了设计方案:他为Cybersyn项目设计了一个通信网络,整个网络都连接到这一台大型主机。为了实现这个非传统的网络架构,比尔和团队需要找到一种便宜的方式来实时、长距离传输数字数据和文本。他们找到的办法是电传机(电传打字机),这些机器已经通过现有的电话线、卫星或微波通道联网。在1970年代初,电传机已经在全世界广泛使用,不是什么高新科技。每台电传机都有一个身份识别号,就跟电话号码类似,用户拨打这个号码,就可以在两台机器间建立连接。然后用户可以用电传机的键盘输入信息;信息会被翻译成纸带上的打孔,再通过网络把打孔纸带的信息传输出去;另一端的电传机则读取纸带,翻译出原来的信息,从而完成信息的传播。用户往往会预先准备好纸带,以便尽量减少连接网络的成本,不过电传机也允许两端的用户通过打字来回交谈。一旦收到信息,接收方的电传机就会在一串嘈杂的咔嗒声中打出一行行文字,听起来不像是传真机,倒更像是电子打字机。在1970年代初的智利,电话尚属稀缺资源,电话网络也不够可靠。电传机提供了另一种国内乃至国际通信的方式。所以,比尔提议在电传机网络的基础上建设Cybersyn项目,于是整个通信网络就只需要一台IBM大型主机。

    比尔提议的系统工作方式如下:干预者用电传机从各自的企业将生产数据发送给国家计算机公司的电传机,计算机专家们再把数据以打孔卡片的形式输入到主机系统中;计算机会运行统计软件,将新的数据与过往采集的数据对比,寻找显著的差异;如果发现重大差异,系统会向计算机操作员告警,后者则通过电传网络把数据发送给CORFO和相关的干预者,随后CORFO会联络这些干预者,以便更好地了解现状并帮助解决问题。

    统计软件

    在部署电传网络的同时,比尔向安达信请求帮助,希望他们参与到后台软件的开发中。安达信的评估结果是,他们可以在1972年3月中旬之前编写并安装一个“临时套件”。这个临时的软件只能接受限定范围内的输入值,但至少能在原定的期限之前给智利人一套软件先用起来。为了在3月的交付期限前完成这个临时套件,他们需要砍掉很多边角。同时安达信会负责设计功能完备、长期使用的软件套件,但长期套件的开发和实施由智利团队负责。在此过程中,三名安达信咨询师会出差到圣地亚哥提供支持:一人负责安装临时套件,一人帮助智利程序员编写长期套件,另一名高级合伙人会为团队提供指导、并在项目结束时签字代表咨询公司正式签字。

    Cybersyn的软件系统是控制论管理领域的新突破。它是比尔的可生存系统模型的第一个软件实现。这个程序还实现了一个新的、从未实验过的贝叶斯统计预测方法,这个名为哈里森-史蒂文斯方法的统计预测方法1971年12月才首次发表在《运筹学季刊》上。安达信的咨询师阿兰·邓斯缪尔在为项目做文献综述时偶然发现了这个新方法。他说服比尔这个方法可以识别生产数据中的显著变量,并根据初始数据点预测未来的趋势:是线性趋势、指数趋势、还是步进函数、或者只是暂时的异常数据。用这个方法,软件就不止能记录和汇总历史数据,还能对未来作出预测。而且一旦计算机操作员输入新的生产数据,软件就能自动调整其预测。

    哈里森-史蒂文斯方法的提出者之一杰夫·哈里森是华威大学统计学系的创始人和首任系主任。在大学给他的讣告中说“他远远超前于他的时代”,这话绝非溢美之词。如果你看Wikipedia的“统计学历史”词条,其中有这样一段话:“1965年……林德利把贝叶斯方法介绍给更广泛的听众;1980年代,贝叶斯方法的应用大幅增加。”似乎贝叶斯方法在1970年代没有取得重要的进展。然而哈里森于1971年发表的文章《一种用于短期预测的贝叶斯方法》可能是首次将贝叶斯函数用于统计预测,Cybersyn则可能是第一个实现贝叶斯预测方法的计算机程序。然而在他的年代,因为计算能力的局限,贝叶斯方法不被学界主流认可;等到1980年代计算能力提升、尤其是马尔科夫链蒙特卡洛方法的发现解决了大量计算问题使得贝叶斯方法受到重视,哈里森就直接被历史跳过了。考虑到现在贝叶斯预测方法在机器学习领域的热门程度,哈里森近乎默默无闻的一生不禁令人唏嘘。

    【杰夫·哈里森可能仅有的一次出现在学术领域之外的出版物上是在一本叫做《难以置信的巧合》的伪科学著作上。这本书收录了很多奇妙的偶然事件,其中一个故事讲到哈里森在给某一届学生上第一堂概率课的时候抛了一个硬币,本打算借此讲解概率的基本概念例如硬币正反面落地的概率各为1/2,没想到硬币落下以后不偏不倚地立在了桌上。】

    经济模拟器

    统计软件运行的结果会进入一个经济模拟器,用于模拟智利经济状况并预测未来走势。比尔希望经济模拟器成为“政府的实验室”。一旦完成,这个模拟器能帮助政府决策者跳出日常事务进行全局决策,并实验多种不同的长期经济政策。所以这个模拟器需要反映不断变化的经济行为,尤其考虑到智利经济正处于转型期,这一点就愈发困难:它不仅要接受不断变化的输入值,还要不断调整变量之间的关系,并引入新的考虑因素。在真实世界中,这些变化不断在发生,因此模拟器的模型也需要能处理动态的变化。

    比尔决定采用一种不太常见的建模方式。当时大多数经济模拟都采用“输入-输出”方法,用庞大的数据集来计算不同生产过程之间的相关性。这种分析方法可能需要几年时间来采集数据,然后用固定的方程式计算系统行为。比尔批评这种方法“死板得无可救药”。如果“目标是重组经济”,比尔写道,那么这种刻板的方法就是“糟糕的工具”。为了寻找不同的方法,比尔把眼光投向了著名的MIT工程师杰·福瑞斯特的研究。

    在计算史上,福瑞斯特最广为人知的成就是发明了磁芯存储器,以及领导了“贤者”陆基防空系统的计算机设计团队。从1950年代后期开始,福瑞斯特的研究重心已经转移到工业管理领域。他对建模随时间变化的复杂系统尤为感兴趣,并把这个这个领域称作“系统动力学”。福瑞斯特鼓励政策制定者借助模型来识别出为数不多的一些关键参数,通过调节这些参数就能获得期望的结果。随后政策制定者就可以集中精力在这些领域。为了编程实现他的动态系统模型,福瑞斯特发明了DYNAMO编程语言,比尔发现这种语言很适合用来编写新的经济模拟器。

    比尔找到了罗恩·安德顿,一位系统工程师、运筹学家、以及英国首屈一指的DYNAMO专家,请他投入到经济模拟项目中。到1972年3月,安德顿已经实现了经济模拟器的最初版本,这个软件被命名为CHECO(“智利经济模拟器”的英文缩写)。最终,安德顿写道,这个模拟器将使CORFO“对包含10到100个变量的系统逐步获得动态的理解,作为对比,缺乏系统指导的大脑只能理解5到10个变量。”同时,邓斯缪尔带着完成的临时软件套件从伦敦来到了圣地亚哥。3月中旬,第一批结果数据从工厂车间传到了CORFO。Cybersyn系统的流程走通了。


  9. 印度儿童诗雅拉尔之死

    来自里格瓦尔村、6岁大的诗雅拉尔·雅达夫已经发烧和头疼三天了。当他的皮肤开始浮现病态的黄色,他的父母找了一个巫医来进行“jhar-phook”(把魔鬼的灵魂赶出孩童的身体)。然后他们又带着孩子去看了一个村里的无证医生,他给孩子打了一针,退烧效果维持了一天。第二天,诗雅拉尔的父亲阿南德从农田里回家,发现孩子发着高烧、呼吸困难。恐慌的父亲想带孩子去拉坦浦尔镇的基层卫生中心去,但拉坦浦尔镇远在25公里外,当天最后一班去镇上的大巴早已发车。村长热心地给他们找了摩托车。基层卫生中心的值班医生做了简单的检查,叫阿南德赶快带孩子去比拉斯浦尔县上的医院——又是30公里路程。阿南德身上只有200卢比(约合20元人民币),于是他恳请医生照顾孩子一夜,他自己回去筹钱,但医生拒绝了他。阿南德只好带着诗雅拉尔赶最后一趟大巴回到村里,此时孩子的意识已经模糊。孤注一掷的阿南德用家里的一亩地和地里的所有庄稼做抵押,借到了8000卢比(约合800元人民币)。一家人紧握着钞票,与轻声喘息的男孩一起等待太阳升起。凌晨4点,诗雅拉尔说想喝水。当母亲端来水,孩子已经离世了。

    在包括中国在内的很多国家,疟疾几乎已经绝迹。但在印度中部的恰蒂斯加尔邦,它仍在投下死亡的阴影。2010年10月到12月之间,恰蒂斯加尔邦爆发了恶性疟疾流行。据邦政府的统计,两个月中全邦共有32人因疟疾死亡。然而,仅比拉斯浦尔县的加尼亚黎村一地就有7例死亡病例。“人民健康扶助团”(Jan Swasthya Sahyog,简称“JSS”)在这个村里设有医院。在附近的科塔乡,JSS的社区医疗团队进行了250例口述验尸,其中200人被证实死于疟疾。如果一个县一个乡就有这么多人死亡,整个邦的数字恐怕只有天知道。

    根据政府的官方数字,印度全国每年有200万人患上疟疾,约700人因此丧生。然而据世界卫生组织的估计,印度每年有1500万病例,其中2万人死亡。由加拿大一家机构发起的“百万死亡研究”的估计是每年有15万到22.5万人死于疟疾——印度传染病控制部门则对这个研究项目表达了强烈的抗议。大多数疟疾死亡发生在家里,因此不会被计入正式的统计数据。正式的数据来源仅限于公立卫生机构,并且要求疟原虫阳性涂片作为证据,然而大部分病人根本没有进行这项化验。

    在缺乏正确信息的情况下,公共卫生政策必然是错误和低效的。而且越是偏远贫困的人群,遭受的损害就越是严重。政府的官方数据显示,50%的恶性疟疾病例和90%的死亡病例发生在被称为“阿迪瓦西”的部落民当中,而他们仅占全国人口的8%。缺乏公共卫生基础设施使得偏远贫困地区大部分病痛与死亡无人知晓,而统计数据的缺失又使得政府疏于投资基础设施建设。这成了一个难解的死结。

    * * *

    黄昏的阳光穿过柚木和娑罗的树叶,在车窗前洒下斑驳的光影。越野车二档通过安查纳克玛老虎保护区泥泞的道路。JSS的医院位于恰蒂斯加尔邦西北部的加尼亚黎村,离比拉斯浦尔县城23公里。进村的道路需要穿过玛尼亚黎河,当季风带来大量雨水,这条道路就会被河流阻断。在降雨稀少的旱季,越野车能够平稳地驶过河水,在日落前进入村庄。

    村边的几栋水泥房屋本来是为一个灌溉项目而建的。这个政府投资的灌溉项目无疾而终,于是JSS把这几栋房屋改造成了转诊医院,包括门诊部、70张床位的住院病房、一个功能齐全的化验室和两个手术室。现在这家医院每天接诊400名病人,并在三个偏远地区设立分中心,向居住在森林边缘的人群提供基本医疗服务。

    现代科技与这里的环境显得有些格格不入。基础设施的薄弱当然是原因之一:这里没有3G信号,2G信号时断时续,停电也是家常便饭;另一方面,村里人识字的不多,医院的医生、护士和工作人员也几乎从未接触过智能手机。病人拿到的药品用塑料袋装好,药盒上贴着一张纸,上面画着代表服药时间的太阳/月亮图标和代表剂量的药片图标。一个房间里纸质病历堆积如山,接诊时护士就要去这个房间里翻找病人的病历交给医生。这是JSS医院的日常。

    Bahmni(读作“巴姆尼”)的目标是让JSS医院、以及其它成千上万类似的医院实现信息化。ThoughtWorks印度公司从2013年开始的这个产品,其核心是一个开源的电子病历(Electronic Medical Record)系统OpenMRS。这个软件内建了一套标准的医疗信息记录数据体系,在北美和南美的一些医院里的实施收到了很好的反馈,并且有一个活跃的社区(包括医学专家、公共卫生专家和IT专家)在不断完善它。但OpenMRS缺省的用户体验不是为JSS这样的医院设计的:它假设了IT水平较高的用户,界面是针对电脑屏幕设计,而且使用过程中需要一直连接网络。于是ThoughtWorks的团队与JSS的医生们协作,在OpenMRS的基础上开发了适合低资源环境的前端用户体验:在平板电脑上使用,界面操作简洁易懂,断网情况下照常工作,等连上网再同步数据。这就是Bahmni的雏形。

    随后,为了让医院信息化端到端拉通,Bahmni产品又整合了几个其它的开源软件。Odoo(曾经叫OpenERP)提供了药房库存管理、账目管理、财务会计的功能;dcm4chee实现了放射影像的信息化集成;OpenELIS打通了化验流程。今天的Bahmni已经是一个完整的一站式医院信息化系统,覆盖挂号、门诊、化验、影像、住院、诊断、手术、处方、取药、预后跟踪的整个医疗服务流程。有了及时准确的信息在手边,医生的诊疗能够更加精准、更加高效。

    一家区级转诊医院的信息化能够积累一个区、几个乡、几十个村的电子病历。如果一个邦的几十个区都有这样一家医院,把它们的电子病历信息汇总起来,政府卫生部门就能得到完整真实的公共卫生数据。如果全国的几十个邦能做到医疗信息联网,国家的公共卫生政策和基础设施投资就能有的放矢。在雅鲁藏布江下游和喜马拉雅山南麓,孟加拉和尼泊尔的政府都有着这样的愿景。他们与ThoughtWorks的咨询师一起,规划为期数年的IT项目,目标是建设全国联网的医疗信息交换(Health Information Exchange,简称“HIE”)体系。

    HIE是一个世界级的难题。医疗信息的联网需要打破卫生、财政、人力资源、社会保障等多个领域的壁垒,需要解决可用性、可靠性、可维护性、信息安全等技术挑战。美国政府每年投入到HIE的投资平均到每个临床医生身上达1.7万美元,至今也未能实现全国联网的目标。孟加拉和尼泊尔这两个位列世界银行中低收入列表的国家希望达成这个梦想,Bahmni是他们选择的武器之一。这个开源、易于配置、易于管理的软件系统,使两国国内的软件团队也能掌握实施和维护能力,从而极大地降低了实施成本,而且——更重要的是——最大程度地避免了对外国高科技企业的依赖。Bahmni采用国际通行的医疗信息交换开放协议HL7 FHIR(读作“fire”),所有主流电子病历系统都能与之集成交换信息。ThoughtWorks的团队与世界各国的HIE实践者紧密协作,将Bahmni融入了OpenHIE信息架构,使国家的HIE建设成为了一个开放的产业生态,政府、企业、研究机构、非营利组织、国际发展机构都能参与和贡献。

    * * *

    诗雅拉尔死后3天,他的小表弟,1岁大的提拉克兰也出现了同样的症状。提拉克兰的父母已经提前找人借了钱,他们立即租了一辆轿车把孩子从卡吉路的社区卫生中心送去比拉斯浦尔。但社区卫生中心没有空闲的氧气瓶给这个呼吸困难的婴儿。提拉克兰没有挺过去比拉斯浦尔的这段路程,给他的父母留下了1万卢比(约合1000元人民币)债务,和无尽的悲伤。

    JSS医院的医生们和Bahmni的开发者们希望,在不远的将来,政府卫生部门能从及时准确的公共卫生数据中窥见恶性疟疾爆发的前兆,及早把青蒿素等药品和预防、诊断、治疗疟疾的知识送到每个村庄,让诗雅拉尔和提拉克兰这样的孩子不再因为疟疾而夭折。

    我们在为这个梦想奋斗。


  10. 2016年,读过的那些好故事

    2016年是忙碌的一年。为了MBA毕业论文,大半年里所有的业余时间都被耗尽。好在总算功不唐捐,战胜了各种拖延症,写出一篇还算对得起自己的论文,同一个主题在QCon做了一次演讲。而且托东野大神的福,竟然还读了64本书,其中颇有不少打得出5星的好故事。

    中国的故事

    • 大唐李白(少年游、凤凰台、将进酒) - 既有精彩的故事,又有旖丽的文字,典故又多,读起来觉得身轻如燕。我唐啊,真是繁华瑰丽,美不胜收!
    • 叫魂 - 重要的不在于那个事本身是什么,而在于当时的人是怎么看那个事,并从这个“怎么看”折射出当时的制度环境。方法真好!
    • 天国之秋 - “这个故事说明了我们认为跨越文化与距离的联结有时其实我们虚构的东西。当我们庆幸终于看透将我们与另一个文明隔开的那扇阴暗的窗户,心喜于在另一边的阴影之间发现隐藏其中的类似形体时,有时我们不晓得自己只是在凝视我们自己的倒影。”
    • 乱世潜流 - 罗大师一贯的风格,从时人眼光看当时事。讲辛亥到北洋一段时人的思想变迁,与《大波》放一起看,正是相映成趣。

    外国的故事

    • 巨人的陨落 - 好像以前没有这种全球视野的演义小说吧?细节很靠谱。要是笔锋再好一点就能写成一战背景的冰与火之歌了。
    • 古拉格群岛 - 本来只想给四星,但是当看到作者说“并不是什么人都宽恕,我只宽恕倒下的人”,就决定给他五星了。真实的信息有最大的力量。
    • 周期表 - 漂亮的小故事,没有特别着意写奥斯维辛,可是那种深远的影响随处可见。
    • 新自由主义简史 - 知道它的历史,才知道所谓“市场主导”、“自由至上”等观念是多么新鲜、多么人为。
    • 生命如歌 - 震撼人心。强烈推荐所有对国际发展和全球医疗感兴趣的人看。
    • 底特律 - 我们太习惯于经济的高速增长,以至于我们忘记了盛衰有时。一座曾经拥有上千万人口的城市如何衰落成不到70万人口,这是当代人几乎无法想象的幻景。
    • 资本的终结 - 简洁的理论,清晰的数据,有力地阐释今天世界的种种现状。要多么努力地自我欺骗才能死守住自由主义经济学观点而不信这么明显的道理?正如齐泽克所说,freedom hurts。

    虚构的故事

    • 没有女人的男人们 - 虽说都是小故事,可是写得很真挚,而且致敬变形记那篇相当妙。
    • 银河帝国(8~12卷) - 什么机器人三定律,其实只是写好玩的本格推理可以用到的一组预设条件而已。幻想的前提条件用好了以后,写出来的本格推理小说果然严密又精彩,连悬疑感都写出来了。但是仍然不怎么喜欢“人类整体”这个概念…而且心理史学必须建立在心灵控制的基础上,这样合适吗?
    • 解忧杂货店 - 很感人的小故事,而且结构很周密
    • 恶意 - 写作手法真漂亮,不但推理层层推进,叙述的视角也不断切换,佳作。
    • 歪笑小说 - 不剧透,不过最后一页的大反转可真是令人感动啊,满满的都是温情啊。

    科技的故事

    • 凤凰项目 - 很棒的故事。可惜的是,最后那段介绍的持续交付,需要相当高的技术能力。所以,雇不起优秀的技术人才、玩不转docker的企业,就只能眼睁睁看着比自己强且敏捷的对手屠杀自己,毫无反抗可能性。
    • 精益企业 - 套路非常清晰,材料非常齐全,Jez桑的集大成之作,IT驱动组织转型的必读
    • Cybernetic Revolutionaries - 尝试用政治与技术的合力建设一个更公正的社会,这样的努力会打开很多新的可能性:技术的、知识的、政治的、等等。Cybersyn是重要的技术和历史遗产,即使它的宏大愿景从未实现。
    • 控制论 - “预测一个消息的未来,就是用某种算符去运算这个消息的过去……最优预测问题的解决仅仅取决于要加以预测的时间序列的统计性质”——写于1948年,跪了。