任何在我出生时已经有的科技都是稀松平常的。

任何在我15到35岁之间诞生的科技都是将会改变世界的革命性产物。

任何在我35岁之后诞生的科技都是违反自然规律要遭天谴的。

将道格拉斯·亚当斯这句话中的“科技”替代为“工作”或许同样适用：

任何在我出生时已经有的工作都是稀松平常的。

任何在我15到35岁之间诞生的工作都是将会改变世界的革命性产物。

任何在我35岁之后诞生的工作都是违反自然规律要遭天谴的。

在之前的文章中笔者试图论证，对于“重复性工作”的优化，于公司而言是创造价值的最根本形式，而于员工而言可以让工作成为一种游戏，甚至说“优化”，而非“工作”本身，才是真正值得员工去做的。

本文试图在时间维度上将“优化”行为展开，深入探究其在宏观层面所展现出的形态。

技术所带来的持续重构

在前文中笔者提到，“自动化”是最显而易见的一种优化“重复性工作”的方法，然而其所带来的结果却是非常违反直觉的，哈默所说：

福特公司的经理原本认为，他们的问题是需要找到一个“如何使用较少人手快速处理货物费用清单”的办法。而他们最后发西安的办法则让他们彻底取消了费用清单。

IBM信贷原先以为他们的问题是“如何加速不同专职人员之间的信息移动”。而信息技术让公司取消了专业分工的职位，于是根本不需要让信息移动了。

柯达公司原先以为，问题是“如何让设计师快速工作”，以便后续设计步骤能够早些启动。而他们的科技解决方案几乎不再需要后续设计了。

从现有流程的视角审视科技的作用是大多数公司的根本性错误。他们问的是：“我们如何使用这些科技来增强、简化或改进我们正在做的事情？”然而，他们应该这样问：“我们如何利用科技来做一些我们以前做不到的事情？”

大多数人对于“自动化”的直觉认识，就是“机器取代人类”，然而事实并没有这么简单。《企业再造》一书中，哈默就将“自动化”纳入“企业再造”的范畴之中：

再造不同于自动化，再造是创新。

再造是利用最先进的科技实现全新的目标。

再造里最难的部分就是思考创新的、不为人知的科技用途，而不是在旧流程里使用科技手段。

想要理解“自动化”所扮演的角色，我们还是要回到企业这一“系统”上。

笔者之前提到，所有的工作，其本质上都是为了服务于企业这一“系统”的存在，而工作本身也是由“系统”而产生。“自动化”这一行为主要改变的不是工作本身，而是其背后的“系统”，因而当我们谈论“自动化”的时候，会无法避免地谈及到其他的几个概念：像是“组织”、“流程”等概念。

以“DevOps”为例，其所提倡的“自动化一切” （Auto everything)让很多人都将这一概念等同为“自动化”，然而刘湘就强调：

DevOps不仅仅是自动化。毫无疑问，自动化是DevOps非常重要的一部分，但不是唯一的部分，一定程度的部署自动化往往会与DevOps混为一谈，实施DevOps需要从敏捷、持续、协作、系统性、自动化五个维度进行建设与改进。

DevOps

他建议，企业落地DevOps，要从组织、技术、流程三方面落实，而技术实际上是最简单的。

落地DevOps的三个方面

但是“自动化”对于“系统”的改变绝不是一次性的，实际上这种改变就如同拨倒了一块多米诺骨牌，会引起持久的、一系列的改变，让企业进入到一种“改进形”（反过来说，如果企业无法进入到“改进形”中，那便是失败的“自动化”）。Mik Kersten 就在《从项目到产品》一书中特别指出，将 IT 改进视为一次性项目是一种谬论，因为这是一个持续的过程。

既然企业会进入到一种“改进形”的重构模式中，那么这种模式会呈现出何种样态呢？

重构所展现出的形态

这里以IT运维工作为例。

运维发展的历程 by 万金

前三个阶段都很好理解：运维工作自出现之后，很快就进入到“专业化”的模式中，随后又出现大量辅助运维工作的各种工具，实际上各行各业都是如此，但随后的“平台化”则十分耐人寻味。

如何理解所谓“平台化”呢？

百度在对外讲解其“DevSecOps”实践时这样描述：

作为一家大型互联网公司，百度具备着所有大型公司和互联网公司的典型特点：业务体系繁多、业务数量庞大、业务迭代迅速。

在百度内部，业务研发模式有别于传统的 SDLC 模型，更接近于 DevOps 模式，CI/CD 工具集成和自动化程度高，产品迭代频次多、周期短。

面对这样的业务研发场景，传统通过输出人力到业务团队，全流程跟进和解决业务研发生命周期的安全问题的方式已经不再适合。安全团队不能、也不可能将人力覆盖到所有业务。

因此，安全团队势必需要构建通用性的产品安全基础设施，将其嵌入到产品研发流程中，然后配合重点业务的小范围安全评估，来实现高可用、高自动化的软件研发生命周期安全保障。

在百度，我们将这种方式称之为轻量级 SDL，即通过少量的人力投入，以高自动化、高 CI/CD 集成的方式解决业务产品的安全问题。

可见，这种“平台化”实际上就是将自己的一部分工作沉淀下来，形成某种“基础设施”。这种“基础设施”可以同时服务于业务团队自身与其他团队，这种“基础设施”成为了企业“系统”的一部分，而由于“系统”的改变，工作本身自然也就发生巨大改变。

这里所谓的“平台”，其实可以用另外一个概念来表示：“产品”。

在《从项目到产品》一书中，Kersten 指出，企业的思维模式要从以项目为中心转变为以产品为中心。

产品思维模式的一个例子是让负责 CPQ（配置 - 定价 - 报价）系统的团队负责随着时间的推移构建和维护该系统——“谁构建，谁负责”（相对于以项目为中心的一次性工作）。

作者强调，这种思维模式的力量在于保证所构建系统的稳定性和灵活性，因为当一个团队需要长期负责构建和维护产品，并获得关于产品实际使用情况的反馈时，这将极大地增加该产品为组织带来持久价值的机会。关于系统生产使用情况的反馈是持续改进的基本输入。

可见，在本文的语境下，所谓“以产品为中心”的思维模式即“以系统为中心”的思维模式——通过构建产品的方式，团队的工作结果能够成为系统的一部分，从而能够系统性地、持续地提供价值，并要求团队根据现实反馈，不断完善产品——其实也就是完善系统本身。

平台之深意

笔者之前提到“工作由企业系统决定并产生”，平台作为“系统”的重要组成部分，同样在很大程度上决定了我们的工作。

Melvin Conway 在 1967 年提出所谓康威法则，指出组织架构和系统架构之间有一种隐含的映射关系：

Organization which design system […] are constrained to produce designs which are copies of the communication structures of these organization.

设计系统的组织其产生的设计等价于组织间的沟通结构。

康威定律

平台一方面反应了组织的形式，一方面也决定了组织的形式，进一步决定了我们工作的形式。

与此同时，平台上面所集成的大量工具同样决定了我们的工作形式。

以Github为例，很多人都知道这是一个在线代码库，但是所产生的价值远超乎存储代码，实际上Github在很大程度上决定了人们的工作内容与工作形式。

Sendachi 的 Steven Anderson 指出，Github 是一个协作平台，但它也是一个和你一起工作的工具（准确地说是一个“工具包”），它不仅可以帮助协作和持续集成，还影响了代码质量。

由此不难理解为什么各种讲解DevOps的书中都会特别强调“培养一种接纳改变、持续学习的文化”。

学习与适应

在Brent Aaron Reed《DevOps 思维模式的 5 个基本价值观》中有这样两个非常重要的价值观：学习与适应。

DevOps 思维模式的 5 个基本价值观

结合笔者上面的论述不难理解它们的重要性：当企业进入到一种“改进形”，决定员工工作内容与形式的平台会不断改变，而员工自然要通过不断地学习来适应不断变化的环境。

“DevOps”会特别强调所谓环境即代码：系统管理员已经写了 shell 脚本和 Python 程序去处理他们重复的任务，而员工要不断学习更多的知识从而使用已有的工具处理他们的更多问题 —— 编排、部署、维护即代码。

到这里，我们终于理解了Chris Collins的这句话：

然而，事实上，DevOps 是 “一个跨学科的沟通实践，致力于研究构建、进化、和运营快速变化的弹性系统”。

 DevOps 意味着终结 “筒仓”，但并不专业化。它是受委托去做苦差事的自动化系统，解放你，让你去做人类更擅长做的事：思考和想像。

至于为什么说“DevOps 意味着终结 ‘筒仓’”，很值得另拿一篇文章来讨论。