为什么回馈对于 DevOps 文化至关重要

在 DevOps CALMS 模型（代表文化、自动化、精益、度量和共享）中，共享常常被忽视或误解。虽然 CALMS 的每个要素都与其他要素同等重要，但知识共享是我们经常忽略的事情。

如果我们不分享会发生什么？

Jeff Smith，Centro 的生产运营总监，讲述了这样一个故事

我们对其中一个报告表中存储的粒度级别进行了更改。此更改使数据库实例上的磁盘空间使用量增加了 8 倍。这不仅导致我们现有的数据库实例迅速被填满，而且还让运营部门质疑这种设计模式是否合理。由于他们没有参与如此重大的更改，因此新流程架构的所有设计决策都被视为可疑，并不断受到运营部门的重新审查。简而言之，一点信任和信心丧失了。

侵蚀信任造成的损害不可低估。协作基于信任。每次这种信任被削弱，能量就会被消耗在质疑他人决策的有效性上。

分享的好处是什么？

今天的系统非常复杂。一个人可以将整个基础设施和系统相互依赖性记在脑海中的日子早已过去。跨越专业知识边界的沟通使我们的整个组织更加强大和更有弹性。

然而，分享不仅仅关乎技术数据或访问权限。“团队间的沟通应该始终从目标开始，而不是从一个团队提出的问题解决方案开始，”Jeff 说。“当你从解决方案开始时，对话就会朝着错误的方向发展。”

Emily Freeman，Microsoft 的 CloudOps 倡导者说：“没有信息共享，协作是不可能的。” 她指出，拥有其他团队的技能和知识的“思维导图”“使人们能够更有效地提问，并减少了他们担心问太多问题或看起来很愚蠢的恐惧。”

我们如何才能更好地分享？

“分享不必是每周二上午 10:30 的击鼓圈，”Emily 说。“它是开放和真诚。它是消除组织中的阴影，并确保每个人都诚实、坦率和负责任。”

至少，每个人都应该拥有对日志、代码和事件后报告的只读访问权限。在您惊呼“关注点分离”之前，请考虑一下，不能与组织中每个人共享的数据集比我们通常认为的要小得多。与默认“除了他们的小部分之外，没有人可以看到任何东西”相比，清理和保护这个小子集可能需要付出额外的努力，但好处大于努力。

“如果有人被排除在外，那么无论组织结构图怎么说，他们都不是您团队的一员，”Emily 提醒我们。

然而，它不仅仅是日志和工具。“‘S’ 通常只被视为知识共享、培训等，”Jeff 说。“但是，如果不包括责任和所有权的共享，那么您的组织很难达到下一个生产力水平。”

我们为什么不分享？

知识工作者不将信息和知识共享作为默认立场有很多原因，但 Emily 和 Jeff 都认为这通常归结为恐惧。

“团队可能认为只有他们的小圈子才能够以应有的热情和技巧来执行特定的任务，”Jeff 说。“因此，信息被孤立，访问受到限制，并且设置了障碍。但这削弱了我们构建安全系统的责任，反而依赖于‘操作员专业知识’作为拐杖。”

Emily 同意。“DevOps 文化从不寻求改变过去，”她说。“相反，那些在拥抱 DevOps 理念方面蓬勃发展的公司对自己的现状持现实态度，并努力不断改进他们的流程，以便团队中的每个人都能蓬勃发展。”