在 DevOps CALMS 模型(代表文化、自动化、精益、度量和分享)中,“分享”常常被忽视或误解。虽然 CALMS 的每个要素都与其他要素同等重要,但知识分享是我们经常忽略的事情。
如果我们不分享会发生什么?
Jeff Smith,Centro 的生产运营总监,讲述了这个故事:
我们对一个报表表中所存储的粒度级别进行了更改。此更改使数据库实例上的磁盘空间使用量增加了 8 倍。这不仅导致我们现有的数据库实例迅速被填满,还使运营部门质疑这种设计模式是否合理。由于他们没有参与如此重大的更改,因此所有用于新流程架构的设计决策都被视为可疑,并不断受到运营部门的重新审查。简而言之,信任感和信心都丧失了一点。
侵蚀信任造成的损害不可低估。协作是建立在信任的基础上的。每次这种信任被削弱,精力就会被花在质疑他人决策的有效性上。
分享的好处是什么?
今天的系统非常复杂。一个人可以将整个基础设施和系统相互依赖关系都记在脑海中的日子早已一去不复返了。跨越专业知识边界进行沟通使我们的整个组织更加稳健和富有弹性。
然而,分享不仅仅是关于技术数据或访问权限。“团队间的沟通应该始终从目标开始,而不是从一个团队提出的问题解决方案开始,”Jeff 说。“当你从解决方案开始时,对话就会朝着错误的方向发展。”
Emily Freeman,Microsoft 的 CloudOps 倡导者说:“没有信息共享,协作是不可能的。”她指出,对其他团队的技能和知识有一个“心智地图”, “使人们能够更有效地提问,并减少他们担心问太多问题或看起来很愚蠢的恐惧。”
我们如何才能更好地分享?
“分享不必是每周二上午 10:30 的鼓圈活动,”Emily 说。“它是开放和真诚。它是消除组织中的阴影,并确保每个人都诚实、坦率和负责任。”
至少,每个人都应该对日志、代码和事件后报告具有只读访问权限。在您高呼“关注点分离”之前,请考虑一下,不能与组织中每个人共享的数据集比我们通常认为的要小得多。与默认“除了他们的小部分之外,没有人可以看到任何东西”相比,清理和保护这个小子集可能需要付出更多努力,但收益大于付出。
“如果有人被排除在外,那么无论组织结构图怎么说,他们都不是您团队的一员,”Emily 提醒我们。
然而,这不仅仅是日志和工具。“‘S’ 通常只被视为知识共享、培训等,”Jeff 说。“但是,如果不包括责任和所有权的分享,就很难让您的组织达到下一个生产力水平。”
我们为什么不分享?
知识工作者不默认分享信息和知识的原因有很多,但 Emily 和 Jeff 都认为这通常归结于恐惧。
“团队可能认为只有他们的圈子才有能力以应有的热情和谨慎来执行特定任务,”Jeff 说。“因此,信息被孤立,访问受到限制,并且设置了门槛。但这削弱了我们构建安全系统的责任,反而依赖于‘操作员专业知识’作为拐杖。”
Emily 表示同意。“DevOps 文化永远不会着眼于改变过去,”她说。“相反,在拥抱 DevOps 理念方面蓬勃发展的公司对自己的现状持现实态度,并努力不断改进流程,以便团队中的每个人都能蓬勃发展。”
3 条评论