用工具堆砌的DevOps 幻觉（下）

质量內建于开发流程中（building quality into the development process） DevOps文化的转变带来的一个效果是让新代码进入生产环境更加容易。这使一些未来的 DevOps 文化转变非常必要。为了确保生产环境的变更稳妥。团队需要重视“将质量构建在开发过程中”，这包括很多跨功能的考虑例如性能和安全，持续交付和自我测试的代码会形成一个允许频繁且低风险部署的基础。

反馈（Feedback) 团队也要重视反馈，为了持续改进， Dev和 Ops 就像系统自身一样，紧密的工作在一起。产品环境的监控是一个对于诊断错误和曝光潜在改进的非常有帮助的反馈环。

自动化（Automation） 自动化是 DevOps运动以及促进合作的基石。将测试、配置和部署自动化可以让人们释放出更多的精力，并专注于更有价值的活动，此外还能减少人为失误。而且，自动化脚本和自动化测试可以成为一个活文档，实时跟踪在线系统配置的变更历史。举个例子，通过自动化的服务器配置可以避免在雪花服务器上排除故障和解决问题的工作量浪费。这意味着 Dev 和 Ops 同样可以理解一个服务器的变更是如何配置的了。

营造 DevOps的文化：奖励持续的“改进冒险”

“你无法直接改变文化，但你可以改变行为，行为会变成文化。”

以上一切的发生，都需要从组织内部做出改进。但每个组织有每个组织的特性，改进的方式和方法也不一样。在这样一个变动而开放的时代，没有什么是绝对正确的。每一个改进的尝试都是一场“改进冒险“。

在冒险中，失败并不可怕，可怕的是失去了继续改进的动力。所以我们要鼓励”改进冒险“的行为。

在很多组织中，变革的动力往往来自于上层的压力。而在集权的组织中，一切权力都属于上级管理者。一切权力都属于上级管理者的另外一个意思就是一切责任也都由上级承担。这样会在组织内出现一个“承担高风险和责任”的个人，而非共同分散风险的团队。这是一个脆弱的组织结构，而在这样一个结构下，往往会出现管理人员短视的投机行为，而给整体企业带来更大的风险。

而DevOps不仅仅能通过技术手段降低变更的风险，更是构造一系列的实践和制度来分散这种因高度集中化和集权化所带来的风险。

首先就是要充分给团队授权，让团队能够在有限的风险控制中开展改进。改进是不断小步进行的，如果步子太大，往往适得其反。

其次，就是要有明确的目标和度量方法。“没有度量，改进就无从谈起”，改进之前，一定要设定好度量指标。以跟踪并收集相关的数据。

最后，无论成功还是失败，都需要有产出，让团队通过自我激励的方式持续形成凝聚力。而不要因为一次的失败就全盘否定改进。如同上文提到的，在一个对失败不宽容的文化氛围中。相较于承担风险的改进尝试，人们往往倾向于不作为。

但是，对失败宽容并不意味着不需要为失败承担责任。而是要要从失败中学习到经验，向成功的目标不断的努力。进行下一场“改进冒险”。成功很可能是巧合，但失败必然有原因，避免了那些失败的原因，就有很大的机会走向成功。

营造 DevOps文化的几点提示

文化的改变是困难的，这并不是一个一蹴而就的行为。需要长期不断坚持才会有效果。而带来的收益非常值得。

“文化是你奖励和惩罚的行为”，要对那些符合 DevOps 文化的行为给予奖励，对于那些违反 DevOps 给予一定的警告或处罚。

以好的出发点推测人的行为而不是坏的出发点，这会破坏信任。

经常质疑制度是否有问题，而不是质疑人是否有问题。有问题的行为一定是有问题的制度造成的。

不要吝惜你的表扬和赞美，但请保管好你的刻薄，指责和冷嘲热讽。

对失败的宽容是强调反思和学习，而不是惩罚。

多想想自己能为他人做什么，而不是要求别人做什么。

集体庆祝每一个成功，集体反思每一个失败。

DevOps文化落地很难，但是收益巨大。你仍然愿意去做吗？