疫情缘故迟迟不能上班，有人开玩笑说“再不上班就会被发现公司没有我也能正常运作了”。说笑归说笑，这话却说的在理，因为我们工作的目的不就是让公司能够没有自己而正常运作么？那一天不正是共产主义的理想吗？

如果说效率是商业的基本逻辑，那么效率同样是组织的基本逻辑，无论是改善工具，还是改善流程，亦或者是采用新的技术，终究都是为了提升工作效率，在单位时间内产出更多的结果，甚至是自动化所有的工作，自己只需要靠在椅背上看着电影、磕着瓜子，等着系统报警。这也是DevOps出现的初衷，即自动化所有手动的工作，让开发的结果替代人为的操作，所以它不仅仅是一个和运维相关的概念，而是切实和组织效率或者技术组织效率相关的概念。

DevOps有三个原则，分别是流动原则，即从业务侧向运维侧的交付流动；反馈原则，即从运维侧向业务侧反馈问题或异常；持续学习与实验原则，即持续试错、持续创新和持续学习，改善和提升组织效率。

在落地和实践DevOps时，难免会遇到与常规做法不同或与现状不同的阻碍，这需要选择合适的团队作为切入点，也就是变革的能力（关于变革推荐《冰山是怎样融化的》）。切入点可以选择大业务大团队，也可以选择小业务小团队，但重点是依据团队特点来选择，选择那些愿意尝试、愿意改变、愿意试错的团队，只要有一个成功的落地，便会吸引更多团队的加入。

相比工厂里的流水线，IT技术的产出过程具有不可见性，因此让一切可视化，让所有人都能看到、理解过程的状态至关重要。这也是为何近年来各种可视化工具层出不穷，所见即所得，可以让相关人快速做出反应，就像流水线工人看到事故或故障时立即暂停作业。

好的组织架构能够节省沟通成本，反之亦然。康威定律指出，系统设计受限于组织的沟通结构，组织规模越大，灵活性越差，这种现象也越明显。也就是系统设计会受到组织结构的影响，如果产品是分移动端、前端、后端三个团队开发，为了边界清晰，系统设计会逐渐倾向于此，如果团队更为复杂，也同样道理。组织结构有三种类型，业务型、职能型和矩阵型，三者各有优劣，但很多人只看到职能导向带来的人员成本的节省，职能专注带来的公司成本节省，却忽略了由于过度职能导向，职能部门的人只关注自己眼前的工作（他让我干啥我就干啥），由此阻碍了更高目标的实现，而这个机会成本远大过节省的成本。典型的情况是，运维不了解业务、测试不了解业务、安全不了解业务，大家只是就技术论技术，被动接受业务侧的需求（往往是要求），代价是用专业的技术实现了不专业的结果。

无论是职能导向或业务导向，都不重要，重要的是能够在各部门间建立起快速传递和快速反馈的机制。徐克曾经在《晓说》里提到自己拍电影时很羡慕TVB拍电视剧，因为电视剧可以拍一集播一集，并根据观众反应立即调整下一集的拍摄。而快速的前提是，建立高度信任的文化，即每个部门要为自己的输入和输出负责，这些年去QA的原因之一正是开发人员会把测试的工作丢给QA，觉得反正有人会给自己捡漏。

DevOps的第一个原则是建立从业务到运维侧的流动机制，包括自动化部署环境、自动化测试、自动化持续集成、自动化发布。其中发布模式有基于环境的发布模式（对环境进行变更）和基于应用的发布模式（对应用进行变更），基于环境的发布模式又可以用蓝绿部署、 金丝雀发布、集群免疫系统。

蓝绿部署，顾名思义是指有两套部署环境，通过路由可以将流量进行切换，新的变更部署完毕后通过路由将流量进行切换，但难点是需要对两个环境的数据库设计同步及回滚机制，比如备份/同步操作、应用和数据库解耦。

金丝雀发布，类似防止栈溢出的金丝雀设计，同样参考了被带下矿井的金丝雀。它是指，通过流量路由和控制，由内到外，逐渐扩大流量，测试新的部署的功能和性能，直到全部部署完毕。

集群免疫发布，是扩展金丝雀发布的做法，将发布与监控进行关联，当性能不足时自动回滚。

DevOps的第二个原则是建立各个环节的反馈机制。通过埋点也好、监控也罢，将部署、测试、发布、运维、安全等环节需要监测的内容进行可视化展现，或者进行自动化关联分析，目的是为了能够让故障或问题在被用户发现之前被自己人发现。相关的指标如平均故障恢复时间（MTTR）、平均无故障时间（MTBF）。

DevOps的第三个原则是建立持续学习和试验的环境。通过将局部的经验分享至全局，可以将经验沉淀于组织内部，而无需顾虑某个关键节点的人的“故障”，同时建立学习文化、预留一定的时间用于解决和填补技术债务有助于更好的创新。学习型组织的特点之一，是不会重蹈覆辙。

对于安全工作而言，由于天然的抵触心理，利益共融并不适合安全工作的推进，此外在人员配备上，安全人员<运维人员<研发人员。因此安全工作的推进需要全员参与，全员监督，这需要安全部门做好除技术工作之外的运营工作，比如抓住每个微小的机会普及安全常识，将原本落于纸面的安全概念开发成工具或公共服务，没有什么比让研发人员直接使用现成的安全的工具、服务更能够让他们接受的了。

以上，是《DevOps实践指南》读后的一点点感悟，其核心思想正是本文标题：持续反馈、持续改进、持续学习，它与PDCA、DMAIC、精益创业等理念一脉相承。还有很多实践并未在文中指出，这是我读过的最好的DevOps的书（毕竟几位作者正是发起DevOps概念的人），在这里强烈推荐。