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

我们不分享知识的习惯正在伤害我们。
180 位读者喜欢这个。
Bubble hands

Opensource.com

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

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

Jeff SmithCentro 的生产运营总监,讲述了这个故事:

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

侵蚀信任造成的损害不可低估。协作是建立在信任的基础上的。每次这种信任被削弱,精力就会被花在质疑他人决策的有效性上。

分享的好处是什么?

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

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

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

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

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

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

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

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

我们为什么不分享?

知识工作者不默认分享信息和知识的原因有很多,但 Emily 和 Jeff 都认为这通常归结于恐惧。

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

Emily 表示同意。“DevOps 文化永远不会着眼于改变过去,”她说。“相反,在拥抱 DevOps 理念方面蓬勃发展的公司对自己的现状持现实态度,并努力不断改进流程,以便团队中的每个人都能蓬勃发展。”

接下来阅读
标签
Matty Stratton
Matty Stratton 是 PagerDuty 的 HumanOps 倡导者,他在那里帮助开发和运营团队提升他们的技能实践,并变得在运营上更加成熟。他与 PagerDuty 客户和更广泛的 DevOps 社区的行业思想领袖合作,并且在他开车的时候,他的车牌实际上写着“DevOps”。

3 条评论

有时候人们想分享,但他们不知道如何分享。您在解决这些案例方面有什么经验吗?

使用 Twitter 作为一种简洁的博客平台。仅仅是关于您今天所做事情的快速提示就足够了!除此之外,您可以尝试使用 WordPress 或 Gatsby 构建博客,使其更有用。

通常,最好写一篇博客并引用自己,而不是引用一年后可能不存在的资源。

希望这有帮助。

回复 作者 Nelson Marcos (未验证)

这是真的。我真的相信分享可以使事情变得更好。我尝试做的是鼓励越来越多的开发人员和 DevOps 人员拥有博客。这些博客总是很有趣的——有时比公司的工程博客更好。

与您处境相似的人分享的经验——在帮助建立他们 + 您(有时甚至是您为之工作的公司)之间的信任方面发挥着重要作用。

和平!✌️

知识共享署名-相同方式共享许可协议本作品根据知识共享署名-相同方式共享 4.0 国际许可协议获得许可。

下载终极 DevOps 招聘指南

使用这些针对潜在员工和招聘经理的最佳实践来构建您的 DevOps 团队。

© . All rights reserved.