3.2 以高度信任为基石的企业文化

创建对失败友好的架构与环境为企业文化的推行提供了整体保障，在此基础上进行企业文化建设会更加顺畅。

良好的企业文化的最终目标是，能够促进企业盈利和提升交付能力。在创建适应企业自身的DevOps文化方面，敏捷和精益管理、持续集成和持续交付都是其重要基石。而精益的实践，我们可以在制造业中获得很多经验。

（1）制造业的变革

让我们把目光投向20世纪80年代制造业的那场变革上。通过践行精益原则，制造业的生产效率显著提升，交付时间降低，产品质量及客户满意度提高，成功的企业在残酷的市场竞争中赢得了一席之地。

在这场变革开始之前，制造行业的产品平均交付时间为6周，而且只有少于70%的订单能够按时交付。而到了2005年，随着精益实践的广泛推行，制造行业的产品平均交付时间已经少于3周，而且95%的订单能够按时交付。

（2）软件行业的变革

20世纪七八十年代，大多数项目需要一到五年才能完成开发和部署，并且经常伴随着极其高昂的成本，而失败则会带来极其严重的影响。

随着敏捷管理思想的践行，新功能的开发周期已经缩短为几个月甚至几周，但是从部署到生产仍然需要数周甚至数月，而且经常还会伴随着灾难性的后果。随着软件和硬件的不断升级，实施永不停息的服务成为可能，云计算更是提供了弹性扩容、缩容的能力，使得业务和资源的投入能够更紧密地结合起来。包括云计算在内的诸如物联网、区块链、人工智能等技术对软件的开发测试部署和交付提出了更高的要求。

DevOps 的引入更是使得这些需要部署到生产的服务变成了以小时甚至以分钟计的常规操作，很多企业在这轮变革中已经先行。借助DevOps，这些企业甚至能够在实际的环境中先行验证它们的创意，以确认哪些创意能够带来最大的效益，并以此来决定所要开发的功能，而这些功能最终将非常安全地被部署到生产环境之中。

互联网行业的竞争异常激烈，究竟什么样的企业文化更适合DevOps？以下将结合制造业的经验及一些企业的实际经验进行说明。

3.2.1 传统制造业的惩罚文化

很多企业宣称，信任是企业文化中的重要组成部分，那么高度信任到底应如何贯彻？这是一个非常难以回答的问题。但反过来看，对于完全不信任员工的企业，执行信任的方式则非常简单，因为可以相信的只有规章制度，不遵守即严惩，这似乎并没有太多问题。而制造业同样有很多经验可供我们借鉴，让我们再次把目光转向制造业。

在传统的制造业中，工作内容被严格地定义，作业者必须遵从，他们基本无法从日常工作中学习并成长，更不可能将学到的内容或好的想法集成到现行系统中。对企业来说，个人完全就是工业时代舞动的扳手，个人对企业自然也漠不关心，冷漠是整个文化的主基调。

在这种环境中，除了冷漠，往往还包含另外两个字：“罚”与“怕”。前者是企业行为，后者是员工心理，两者共同构成了这种文化的主基调。企业有这种想法也很正常，出了问题的员工被惩罚确实合情合理。抛开容易引起争论的“应该怎样做”的话题，在这种情况下，从同理心的角度出发，一般有两种情形十分常见。

● 第一种情形：因为害怕被惩罚，出了错的员工可能会做两件事情，首先是瞒，能瞒多久就瞒多久；其次是推脱，瞒不住的时候开始找各种理由推脱，各种“背锅侠”纷纷涌现。

● 第二种情形：那些指出问题或者提出好建议的员工容易被孤立，因为他们被视为“麻烦制造者”。能够提出好建议是因为这些员工发现了目前做得不好的地方，做得不好就要被罚。提建议者被孤立，容易造成其他人的困扰，尽管大家都明白“孤立”的做法并非理性。

不可预测性是复杂系统的重要特点之一。成千上万种的可能性使得我们无法应对复杂系统可能出现的问题，即使我们在工作中已经谨小慎微，依然不能精确地判断变更会带来好处还是带来灾难。

一旦问题发生，我们会立即去寻找原因，而通常的原因是“员工的失误”，通常的解决办法也是对员工进行惩罚。做错事的人被惩罚是合乎情理的，为了防止类似的错误继续发生，一般会增加审批的程序。在项目中还可以增加一种叫作checklist的列表，修改一行代码可能需要确认1000行的checklist才能确保代码从设计到编码规范、测试质量、整体性能、科技人文和企业利润等不会受到影响。可惜的是，在大部分项目中这种方法似乎不是很奏效。

而这种惩罚的方式所带来的后果则是，它会使得那些容易出错的员工更加恐惧而不是更加仔细，整个组织也会变得更加官僚化，“自我保护”现象也会变得更加常见。

“惩罚文化”大行其道给员工带来了恐惧情绪，当问题出现或者出现征兆的时候，甚至到灾难发生的那一刻，员工的做法常常是视而不见。而这一点也得到了2018年DORA调查报告的支持：企业最高管理层比团队成员对 DevOps 进展更加乐观。而这份乐观很大程度上来源于我们讨论的“惩罚”与“害怕”文化所导致的信息无法自下而上完整传递，信息传递过程中可能存在“过滤”和“消毒”，导致阻碍进程的问题及瓶颈都无法被真实地看到。企业最高管理层对现状的认识是不完整的，所以在某些数据上显示出了和团队成员之间的较大不同。例如，在关于安全团队是否介入了设计和部署过程的问题上，管理层中有64%持肯定看法，而团队成员中则只有39%持肯定看法，这是需要认真对待的。

科技是第一生产力，而技术的提升需要不断地学习、需要试错。企业文化的作用就是创建一种高度信任的宽松环境，使得员工敢于也甘于通过持续学习来促进自身成长，而这个过程就在日常琐碎的工作之中进行，因为要进行试验，自然会有风险，如果没有高度的信任，是难以做到的。通过试验，会知道哪些流程或者知识能够在实际的生产环境中奏效，哪些没有效果。有想法的员工将自己的想法付诸实施之后，自然也会判断哪些可能有用哪些不正确。而且，经验的分享和全局利用也是文化的重要组成部分，如何将较好的实践经验推广到整个组织，也是企业文化需要考虑的事情。

3.2.2 聚焦改善的免责事后分析

在一个高度信任的组织中，除个别员工自身确实存在诚信问题外，很多管理人员都认为员工所犯错误的真正根源在于所使用的工具。相对比地，传统的企业文化是揪出“害群之马”对其进行惩罚。而更好的处理方法则是将其视作学习的机会。

一旦员工在所犯的错误上感到安全，他们就会有意愿改正错误，甚至还会热情帮助公司的其他成员，以避免他人再犯同类错误。这样可以将免责的事后分析流程作为持续学习探索的开始，从而不再聚焦于“惩罚”，而聚焦于如何进行改善。

这里使用Netflix的一个案例来进行说明，一位在18个月内使Netflix宕机了两次的工程师，未受惩罚并仍被企业重用。因为这个工程师使得系统能够安全地部署，并完成了极大数量的生产环境部署，他为公司带来的价值非常之高。

2014 年 DORA 的 DevOps 研究报告同样给出了数据上的支持。该报告指出，高绩效的DevOps组织犯错和失败的次数更多。这是可接受的，也是组织所需要的，比如高绩效组织的效率是低绩效组织效率的30倍时，即使失败率只有低绩效组织的一半，他们失败的次数仍然远远大于低绩效组织。

对失败友好的架构与环境，因为具有弹性，因此可以包容一定程度的失败，这就给予了DevOps实践在基础架构上的保障。而允许适当风险和失败的企业文化则将失败视作持续学习的机会，不会过度聚焦于对犯错员工的惩罚，这种氛围会使员工更能坦言自己的行为，甚至过失，因为这是一次组织改进的机会。在这样的基础之上进行聚焦并改善问题的事后分析会事半功倍。

为了做好问题的事后分析，在问题解决之后要召开事后“免责分析会议”，最好在大家的相关记忆还没有消失的时候进行。这样的事后免责分析会议一般有以下主要原则。

● 设定时间限制，从不同角度获取相关的详细信息，确保不会因犯错而惩罚员工。

● 鼓励犯错的员工成为相关专家，以帮助和教育组织其他成员不犯同样错误。

● 提出预防同类问题再次发生的应对措施，确保问题有负责人，并将应对措施在目标日期内记录下来。

为了达到更好的效果，参加会议者可以包括如图3-4所示的成员。

从图 3-4 中可以看到，参加会议的包括发现问题者、响应问题者、故障诊断者、问题影响人、可能对问题解决有帮助的人及有兴趣参加会议的其他任何人，这就保证了问题分析的全面性，进行事后免责分析的要点如下。

（1）做记录，包括问题发生的时间、采取了什么举措（最好能在诸如IRC或者Slack等工具的聊天记录中进行管理）、观察到了什么样的结果（最好能够在生产环境的监控指标中进行确认）、进行了什么样的调查、考虑到了哪些应对方法。

（2）注意事项：确保成员不会担心被惩罚，要在免责的方式下进行，避免使用“本来可以”“本来能够”等表述方式；避免员工过度自责，要将问题聚焦到“当时为什么觉得采取那个举动是自然而然的”上；避免“认真一点”“聪明一点”等不具可操作性的应对措施；避免从“明天的我们一如今天一样愚蠢”这样的角度去考虑应对举措。

（3）公开事后分析结论，为了使整个组织都能从中学习获益，在事后免责分析会议结束之后需将结论在组织内部进行公开。

3.2.3 多角度的知识与经验分享

对于企业来说，知识和经验是重要的组织资产。当下，知识和经验的共享已经变得非常重要，而且共享的过程也可以通过各种方式来实现，如图3-5所示。

1.尽可能地进行内部信息的共享

包括事后免责分析会议的记录与结论在内，尽可能地进行内部信息的共享能够快速地分享知识和经验。例如，Google的员工对公司内所有的事后分析文档都可以搜索查看，当同类问题发生时，这些文档会最早被研究和比较。

当然，当共享的内容非常多的时候，在整个企业内部一定会积累大量的记录信息，堆积在Wiki或者相关的知识共享平台上。我们需要意识到共享信息的获取和操作的便捷化也会直接带来良好的效应，使用新的工具或者自行开发相关的、适应自己企业的平台都是值得的。例如，Esty公司就遇到了进行大量信息共享时效率低下的问题，于是开发了一款名为Morgue的工具，用它来记录每一个事件的重要因素，如平均修复时间和严重程度等。使用 Morgue 可以使相关信息更容易被记录，比如：

● 问题发生的原因（定期操作或非定期操作引起的）；

● 事后分析的负责人；

● 相关IRC（Internet Relay Chat）工具保存的聊天记录；

● 相关Jira（Atlassian公司的项目管理工具）的任务单；

● 相关客户的事件报告信息。

Morgue的开发和使用使得对严重等级稍低的问题（P2、P3、P4）的事后免责分析记录越来越多。这证明了如果有类似 Morgue 这样方便的工具用于管理事后免责分析结果，员工会更多地记录结果，能更好地促进组织的学习。尽可能地进行内部信息的共享，同时使用适合自己企业的工具，在知识和经验的积累方面能起到很好的作用。

2.结合工具进行进一步的集成（ChatOps）

DevOps有一个分支被称为ChatOps，可以通过即时聊天工具（如聊天机器人）集成自动化操作工具，在保证了工作透明性的同时，又能记录实际的文档（聊天记录）。

ChatOps 还能间接起到分享的作用。比如，即使是团队的新成员，也可以通过查看聊天记录来了解一些事情是怎么完成的，就好像一直在和聊天记录里的人员进行结对编程一样。通过这种方式，可以获得多种收益，相关收益罗列如下。

● 透明性：每个人都能看到所有发生的事情。

● 培训：第一天上班的工程师能看到日常工作是怎样的，以及是如何实施的。

● 协作：当人们看到其他人在相互帮助时会倾向于同样发出求助，这有助于团队间的协作。

● 文档化：相较于邮件，信息更容易被记录和共享。

● 虚拟团队的知识分享：如果很多工程师都在不同的城市，使用聊天室能更好地推动知识的分享。

● 快速地帮助：通过快速问答和信息全体可见进行知识的分享。

GitHub曾声称，Hubot是自己企业最忙碌的员工，而Hubot正是这样一个强大的聊天机器人。GitHub可以利用Hubot进行自动化集成和信息分享，如图3-6所示。

Hubot用于集成自动化操作工具，这些工具包括Puppet、Capistrano、Jenkins、Resque、Graphme等。通过集成这些工具，Hubot不仅可以实现信息的共享和团队的协作，还可以实现更多操作，比如：

● 检查服务的健康状况；

● 进行Puppet操作；

● 部署代码到生产环境；

● 系统进入维护模式后进行警告通知；

● 当部署失败后取得“冒烟测试”的日志；

● 源代码提交信息的显示；

● 触发生产环境部署信息的显示；

● 部署流水线执行导致的状态变化的显示。

3.进行技术栈的标准化

复杂的系统往往使用了很多的技术，对那些被维护了较长时间的大型项目来说，这是十分常见的事情。多种操作系统、多种编程语言、多种框架、多种中间件、多种硬件设备共存的情况使得整体的应用架构非常复杂。而这往往会极大拖慢 DevOps 实践的进度，仅自动化推动方面也会遇到非常大的阻碍，降低整体复杂度对这种系统来说已是当务之急。

在2018年的DORA的研究报告中也明确指出了构建标准化技术栈的重要性，很多人认为自动化应该是最初的切入点。而实际上如果事前的准备工作没有做好，直接切入自动化，很多时候这种急功近利的期望并不一定能够得到满足。因为在一个技术栈非常复杂的情况下，自动化本身将会变成一个不可控的需求，而如果不对这种复杂技术栈进行控制，后续的投入很有可能会大幅增加。所以规范化整体的技术栈更多的是为了简化系统，降低依赖，正所谓磨刀不误砍柴工。

在很多 DevOps 实践的项目中也是如此，虽然会将自动化作为一个很重要的目标，但还是要对整体的流程、可改善的环节、改善的计划和重点、技术架构进行讨论，明确并降低系统整体的复杂性，以期能够持续稳定地投入并获得持续稳定的回报。

构建规范的技术栈，不应局限于某一个应用或者某种服务，而应着眼全局，从整体角度进行考虑。对技术栈进行规范化和标准化，从长远来看会取得很好的效果。但是对于拥有复杂度很高的老旧系统，确定如何实施才是关键所在。影响太大、改动成本过高往往是对老旧系统技术栈进行标准化的阻碍。构建标准化的技术栈势在必行，但是如何实施，以什么样的规划实施才是首先需要考虑的。

之所以把标准化技术栈作为知识和经验分享的一个重要方式，是因为它不但对构建整体架构具有指导作用，而且由于复杂度的降低可使壁垒大幅度减少，沟通的效果会明显改善。随着技术栈的简化，往往在成本方面诸如各种授权费用或版权费用也会有所降低。例如，对于整体的技术栈来说，Google 提倡使用一种官方编译语言，一种官方脚本语言，一种官方 UI 语言，紧跟这“大三样”，既能保证得到库和工具的支持，也能更容易地找到协作者。

4.单体共享源代码仓库

当企业规模很大的时候，其拥有的系统往往也很多，而这些系统有可能使用了相同的框架，比如Java的Web开发框架Spring Boot。如果不同的系统能统一使用相同的版本，同时框架有专人负责，那么一旦出现安全问题，或者需要升级版本，整体使用单一的共享源代码仓库来进行管理可以使知识和经验的积累更加有效。但是在实际的企业中，很难做到统一共享源代码仓库，这些企业往往有多个源代码仓库，以及不同的框架和版本，升级和安全问题也难以统一管理。由组织级别创建单一的共享源代码仓库，能够很好地推动知识的分享。

虽然这看起来很难做到，但以Google为例，在2015年，Google用单一的共享源代码仓库管理着超过10亿个文件和20亿行代码，超过2.5万名工程师在使用这一仓库。

Google的众多核心功能在此仓库中被管理着，包括：

● Google搜索；

● Google地图；

● Google文档；

● Google+;

● Google日历；

● Gmail;

● YouTube.

共享源代码仓库中不仅保存源代码，同时还管理着其他内容，比如：

● Chef recipe或者Puppet manifest这样的有关基础框架和环境的配置标准；

● 部署工具；

● 包含安全在内的测试标准；

● 部署流水线工具；

● 监控和分析工具；

● 教程文档。

Google所有的库，诸如OpenSSL或者Java线程都有专门的负责人，可以保证此库不仅能通过编译，还能通过所有的相关测试。同时，当版本升级也由该负责人负责。Google正是通过这样的方式，保证了知识和经验分享的顺畅进行。

5.结合自动化测试和社区活动扩展知识

为了将知识和经验扩展至整个组织，还可以采用自动化测试和社区实践的方式。这听起来会有点奇怪：自动化测试为何能够作为知识扩展的方式？在组织级别往往有一些共享的库文件，若想使用这些共享的库文件则需要进行信息的共享。而使用共享的库文件的前提是确保这些库都有大量的自动化测试。如果结合一些工具或者在测试的时候考虑到分享的因素，就可以将这些测试用例直接做成可供用户学习的文档。例如，工程师可以通过确认测试用例去探索如何使用REST API，这时结合Swagger等工具往往更为方便。往往这种情况都伴随着TDD（Test Driven Development，测试驱动开发）实践的发生，在理想情况下，每个库都有一个负责人或者负责的团队，另外在生产环境中只允许一个版本被使用，这样能确保组织级别中共享知识和经验，基于TDD的自动化测试也能在组织内扩展知识。

关于社区实践，可以对每一个库或者服务创建讨论组或者聊天室，在这样的环境下，提问者得到的回答往往来自其他使用者而不是该库的负责人或者开发者，通过社区实践，使用者能够相互帮助，从而更好地在组织内进行知识的扩展。