好久没有写文章了，最近的半年真是如同一场梦一样，各个场景快速地变换着。一直希望有一块时间来整理一下思路，沉淀一些东西，但没想到即使这篇简短的文章，也是在原本要拿来准备材料的周末时间挤出来的。

结识红帽

关注我朋友圈的朋友一定知道，3.18 号我从 ThoughtWorks 离职后加入了 Red Hat，即红帽软件。当时红帽的 HR 在领英给我发来邀请说红帽在构建一个名为“开放创新实验室”的业务。跟进看了一下之后，发现是个很有意思的想法，我也就继续聊了一下，最终敲定了新的旅程。

人们对红帽的第一印象是企业 Linux 服务器的主要玩家之一。不巧的是，我本人并不是 Linux 的狂热分子，顶多算得个入门级用户。曾一度连 CentOS/Fedora 和 Red Hat Enterprise Linux（RHEL）的关系都弄不清楚。不过，除了特定优秀的产品口碑之外，红帽的声望之所以高，还得益于他长期在开源社区上的贡献卓著。

我自己最近关于红帽的了解，是试用 OpenShift 产品，大概了解了一下它是红帽的产品。当时我正在香港为一个客户实施团队敏捷导入。可能是出于一种技术人员的焦虑吧，我总是习惯性地学习一些新东西，即使可能并不直接能用在当下的工作当中。却没有料到自己会在下一份工作与它产生诸多关联。

风生水起的容器技术

我到 2016 年才开始接触容器，当初我并不太理解为何人们对容器技术那样热情。那时，人们在提到容器时，总是提到它如何令环境自动化工作变得简单，但自动化对于我来说并不是一种陌生的技术。在此之前，我所在的团队基于 Chef、PowerShell DSC 和 Ansible 实现的自动化早已有效地提高了系统运作和维护效率。因此，我一开始对容器对自动化帮助不以为然，也并没有太意识到它将会助推一场多么深远的产业发展。直到自己第一次体验，可以说当时感觉到的是一种“惊呆了”的冲击感。这种感受到现在仍然记忆尤新：通过几个简单的命令行，一个软件在几秒钟之内就启动完成！

现在看来，容器技术不仅在技术社区推动了一轮又一轮的潮流，连敏捷这类曾经被认为“孤芳自赏”的方法论也在这几年里随着与容器一起兴起的 DevOps 运动又重回了一次前台。

容器当然是好，但运用容器却没有那么简单：它要求开发团队在编写应用程序时，按照特定的方式开发（比如，一个容器包含一个服务），并遵照特定的规格发布应用（容器镜像镜像）。这一点与当初基于虚拟机的云迁移是截然不同的。基于虚拟机的云迁移过程中，应用开发人员并不一定需要把应用程序重构为符合云环境的架构，把从前在虚拟机、实体机运行的应用直接搬迁上云后并不能自动获得“弹性伸缩”、“故障转移”、“灵活资源供给运维”等能力——但现实中他们往往有更紧迫的业务功能开发需要优先实施；同时云厂商的职责是让人们搬到自家云上，并不会关心应用运营企业和开发团队的是否真正享受到迁移到云带来的好处。

容器技术以一种尽乎完美的方式提供了细粒度的可调度计算单元、内置基于容器镜像的自动化技术让人们以“眼见为实”的方式感受到了云的力量。开发人员终于开始对云产生了渴求。很快人们发现，容器提供的快速启停、服务自托管和配置注入等特性简直与微服务是天生一对——然后很快问题就归结为，而容器加上微服务之后带来的各种运维技术、开发方法，甚至是团队管理等方面的变化，好像有点超出开发人员能掌控的范筹。最常见的问题就是，单体应用如果不重构成微服务，在使用容器之后仍然无法享受它带来的“快速和频繁更新版本”的好处；再比如，微服务改造一开始就要面临的微服务边界识别和对应的业务需求切分问题。

很多开发人员为此感到困惑。原因是，开发团队以及团队所在的组织的组成结构和工作方式无法与容器带来的灵动性相称，不能充分发挥容器技术的优势。容器可以做到相当灵活，可以为微服务提供良好的基础，但是开发人员的技能和团队协作方式却难以在短时间内完成升级。这些正是“新的生产力”与“旧的生产关系”之间发生阻抗的直接实证。

红帽开放创新实验室

事实上，适应容器与微服务的团队协作方法正是敏捷和 DevOps。围绕敏捷提倡的“客户合作”、“响应变化”，以加强协作的方式尽早发布软件等思想发展出的项目管理和需求分析方法、投资决策框架等一系列方法，以及对团队协作关系的深入探讨和大量工程实践的实施经验，都与容器和微服务等实现技术相互适应。

红帽敏锐地意识到这一点，把上述这些方法放在一起，将它们定义为共同构成“云原生开发”的技术栈。并从 2016 年开始在全球组建红帽开放创新实验室这项业务。红帽认为，如果红帽期待容器技术市场的成就，期待 OpenShift 尽快获得市场接受，就要主动帮助企业的开发团队完成上述能力的建设，而不是等待市场自然成熟。

红帽提炼出敏捷社区和 DevOps 运动中积累和涌现的大量优秀实践，以开放创新实验室的方式帮助企业团队构建端到端的敏捷和 DevOps 能力：

  • 产品设计方法（设计思维，愿景分析，决策方法等）
  • 迭代运作机制（敏捷交付和精益度量）
  • 日常协作方法和工程实践

为了让人们对这些方法有个快速的整体体验，红帽设计了专门的 DO500 课程，同时把开放创新实验室项目和 DO500 课程实施过程中涉及的种种团队方法总结为开放实践库，供人们学习和运用。根植于红帽的开源基因着实令人感动。

过去几个月以来，我参加了两个开放创新实验室项目，以及两次 DO500 课程。我最近正在开展 DO500 课程的讲师培训，接下来很快就会把这个课程带回中国来。在我参与的红帽实验室项目和 DO500 培训来看，我能感受到红帽确实是在精益求精地在打造这一系列业务。这正好与我个人的愿望不谋而合。我个人，也十分期待能以一种方式为企业和社区做出贡献。

写在最后

本来打算在加入红帽之后就写一篇针对在 ThoughtWorks 工作的总结。接下来也还是可能会写，但暂时，我想先让关注红帽、关注我的朋友先了解一下我在红帽开放创新实验室的工作。

离开 ThoughtWorks 之前，最后一个项目是在为一家大型保险公司的核心系统开展微服务化改造工作。这个项目是在 ThoughtWorks 咨询团队遇到的最有技术范的项目，非常有挑战，也非常有成就感，我其实是不太忍心离开的。项目当时缺人缺的正紧，我的离开想必也会让情况进一步堪忧，农历年之后上班第一天，感受着清晨的暖阳的同时，我却在想怎么去约项目并肩作战的兄弟们聊聊我的离职。

可以说，在 ThoughtWorks 咨询和交付团队的历练直接帮助我建立了成体系的敏捷开发理论和丰富的实践方法。而红帽拥有雄厚的技术实力、一流的产品平台和广阔的企业市场，在红帽推动面向容器的现代化软件开发团队的建设服务，对我来说是相当难得的机会。我将与红帽的兄弟们一道，借助红帽开放创新实验室帮助更多企业和社区成就更多成功故事。

 

最后，ThoughtWorks 把（前）员工近年来在敏捷实践过程中总结的各类思考编纂为文集《深入核心的敏捷开发》，书中“核心原则”部分收录了我的文章《开发人员的客户思维》一文，欢迎参阅。