1.10.1.1. 后记

这本教程的编写花的时间比我想象的多，一方面是因为个人能力有限，另一方面不少内容是翻译自官方文档。由于官方文档类似于使用手册，不需要考虑阅读者循序渐进学习的顺序，所以花了不少时间斟酌和调整章节的顺序，以期能够使得初学者在按照顺序阅读时不至于会被尚未学习的概念所困扰。

在我编写本作时，其实已经在家里歇了很长一段时间了，有各方面的原因，其中有一部分原因是因为我在近些年以来越来越强烈地感觉到中国的软件行业，尤其是互联网产业出现了问题。当我们越来越依赖软件时，软件已经成为了像电力、自来水、道路桥梁这样关系到国计民生的重要基础设施，但如果我们仔细地观察许多的互联网公司的工作方式，经常会看到许多团队仍然停留在手工作坊的水准；这种问题并不只是小公司有，其实互联网巨头也有，我们不能把巨头看作是水平均匀分布的利维坦，其实巨头内部更像是部落联盟，不同的事业部，不同的产品线，不同的团队，可能理解、眼界和水平相差非常巨大。

大公司有一种精细化分工的倾向，总希望把软件生产过程细分成一个高度协同的流水线，但流水线却是根据技能来分隔成不同的团队的。这样的好处是每个功能团队都可以独立发展自己的技术栈、工具链，都可以独立安排各自的优先等级，另外把技能切分的非常细也有助于用流程和文档把技能沉淀下来，降低特定人员离职所引发的风险，但另一方面这种做法人为地在团队间建立了高高的部门墙，产品经理会说“我不管你怎么实现”；开发人员会不管测试团队如何测试，写出可测性很低的代码，同时视公认的开发最佳实践单元测试为测试的事从而跳过编写单元测试；测试人员很委屈，既然你不配合我做测试，那我索性也不专注于测试具体应用了，测试团队转型变成了测试工具开发团队，反正平台和工具我做出来了，开发不用那就不是我的事了；运维团队往往是最后才拿到要部署的应用，应用上线各种各样的故障运维团队能做的事不多，也只能疲于奔命。

我看了很多“团队”用这种低效的方式协同，造成了许多的问题，互相扯皮指责；管理者为了进度，无意挽起裤脚管下地去了解一线真正的现状，而是制定一些简单的量化指标，比如故障级别、故障率、故障时长、加班时长、BUG 率等等，希望简单粗暴的 996 就可以解决问题。我认为这一切都是非常荒唐的，就像盲人摸象，没有一个盲人认为自己有能力，或者有义务先去了解整个大象的全貌，再下定论。这种精细化分工和简单量化的方式是错误的。

我之所以对 Terraform 和 Pulumi 这样的基础设施即代码工具着迷，原因是我认为它们所指出的方向非常正确。在传统的软件开发，或者互联网开发中，开发多多少少会鄙视基础设施和运维，总觉得写代码的能力强，部署应用、配置服务器的那是比较低级的活；开发甚至内部都存在鄙视链，多少面试都是必问算法、原理、底层，考操作系统，考多线程高并发，考数据库锁，结果实际生产中写出来的代码连个像样的单元测试都没法编写，因为可测性太差了，就这样的水准，还会上知乎询问“业务代码写多了只会 CRUD 怎么办？”；写代码时完全不管安全性、高可用这些问题，因为这些问题都是“低级”的运维和基础设施团队该做的。这种认知是有毒的，是错误的，正确的方式应该是，围绕着一个产品，所有相关的人，不论他的技能特点如何，他们都是一个团队，他们的认知应该是统一的，信息是全面的，我们需要一种新的，覆盖全生命周期的软件研发方法论，技术人员和非技术人员要学会用一种统一的全面的视角来思考问题，眼界绝对不能局限于自己擅长的技能点上。基础设施即代码技术是一个很好的实践，它能使得开发、运维以及测试，对基础设施这件事有完全一样的认知，更好的是，它使得在传统软件开发中一些很好的实践，比如设计模式、SOLID 原则等，都可以应用到基础设施领域，我们甚至可以使用单元测试驱动开发的方式来编写基础设施代码。摸象的盲人们虽然还是盲的，但是这一次，盲人们至少认识到，长鼻子和大耳朵都是长在同一个象头上的。这算是我在技术方面的“天下大同”的梦想吧。

在本书的编写过程中，得到了许多师长朋友的鼓励和支持，尤其是我的太太，对于我这样闲居在家的人并没有给予什么压力，使我可以自由地思考和进行学习探索。得妻如此，夫复何求？我太太是一个特别热爱学习特别独立的优秀女性，我为她感到由衷的自豪。

愿中国互联网能够有一个更好的发展，愿中国技术人员不用再被强迫进行无意义的 996。