你可能认为我会谈论为什么你应该使用开源工具作为组织中有效 DevOps 文化的基础，但这并不是本文的重点。并非要轻视 我所在的团队 所面临挑战的复杂性，但我相信工程师们会解决工具问题。信不信由你，真正令人望而却步的部分是文化变革。
我花了大量时间阅读关于 文化变革、如何拥有一个 有效的 DevOps 社区、如何 建立高效的团队，以及提出问题，“我该如何 DevOp？”。我读到的这些想法给我提供了一些新的工具。然而，没有什么比以下内容更能引起我的共鸣：
开源之道是...
开放交流
当信息开放时，我们可以从彼此身上学到更多。自由的思想交流对于创建一个允许人们学习和利用现有信息来创造新想法的环境至关重要。
参与
当我们能够自由协作时，我们就能进行创造。我们可以解决任何人都无法独自解决的问题。
快速原型
快速原型可能会导致快速失败，但它会导致更快地找到更好的解决方案。当你能够自由尝试时，你可以用新的方式看待问题，并在新的地方寻找答案。你可以通过实践来学习。
精英体制
在精英体制中，最好的想法获胜。在精英体制中，每个人都可以访问相同的信息。成功的工作决定了哪些项目会崛起并聚集社区的力量。
社区
社区是围绕共同目标形成的。它们汇集了不同的想法并分享工作。一个全球社区可以创造出超越任何个人能力的东西。它可以成倍增加努力并分担工作。在一起，我们可以做得更多。
这就是你如何获得有效的 DevOps 文化。你拥抱开源之道。
如果你没有兴奋地挥拳，请回想一下你过去曾经有过的工作，让你感觉像这个人一样，然后重新阅读一遍。
开放交流、参与、社区
我在 Red Hat 之前的工作经历充满了“做好你的工作”和“事情就是这样，你无法改变它”之类的说法。我曾发自内心地感受到那种可怕的感觉：不得不告诉别人他们不能提出自己的想法，不是因为这个想法不能解决很多问题，而是因为他们不认识合适的人，或者不知道以最好的方式表达他们的想法。
当你拥有 开放交流 并且每个人都被鼓励 参与
- 人们互相交谈，并在彼此的集体经验基础上进行构建。
- 人们在共同工作时赢得彼此的尊重。
- 当人们了解并尊重彼此时，他们不太可能说“这是某某的工作，不是我的”。
如果有人说“一起工作，否则...” 那么任何团队都不会相信他们处于最佳工作环境中。是的，他们会一起工作，但是难道你不希望给他们一个想要一起工作的理由吗？这个理由可以简单到帮助两个人建立在相似兴趣上的联系，也可以困难到让长期以来一直不喜欢彼此的团队一起工作。但这里的关键因素是通往同理心的道路，以及尊重你一周都在一起的人。归根结底，你需要营造一种可以表达观点、可以拥有想法...可以分享的环境。
即使在我工作的 团队 中，开源之道的价值观也得到了个人的拥抱，我们仍然必须努力继续培养全球社区和协作意识。即使在 Red Hat，这也很难。我每天都在努力尽可能地展示我们团队正在做的事情，无论它看起来多么微不足道。结果是什么？人们分享他们的想法，并帮助构建我们可以引以为豪并支持的东西。
快速原型和精英体制
我和我正在合作的工程师团队早期发生了一件很棒的事情；他们提醒我完成一些事情的重要性。我们花了很多时间试图理清我们可以做的大量事情，结果是什么？坦率地说，就是大量的谈话。
能够向别人展示你正在做的事情，并收到关于这件事的反馈，比谈话更有意义。 快速原型？ 能够 看到代码，而不是让一个想法消失在需求漏洞中并在 QA 中重新出现，这真是太令人满意了，我都无法说够。在我过去的项目经验中，我没有看到代码被交付、收到更改的输入以及随后被快速修改。所以，这对我来说仍然是变革性的。
不要误会我的意思，这并不是一件容易掌握的事情。早些时候，该团队做出了一项技术决定，即继续开发一个 自定义应用程序，该应用程序可以提供某些 系统信息（如正在运行的软件版本），而无需对服务器进行 root 访问。我知道已经有工具可以做到这一点，但该团队想要一些快速的东西来缓解痛苦。完成之后，我们同意开始研究更长期的解决方案来提供帮助。我们仍然能感受到这一决定带来的痛苦；就该项目而言，精英体制 处于全面模式，没有人羞于分享其对服务器的影响的细节。但是，我仍然可以说这项工作是成功的，因为归根结底，它让最需要它的人感到高兴，并且肯定会让人们与我交谈。
考虑一下
如果你认为员工不够自在而无法分享想法，或者被告知不要协作因为它不是他们的工作，或者暗示他们的经济福祉与执行一项功能有关，并且没有强调整体系统思考，那么你认为 DevOps 转型会有多困难？
开源之道并不是成功的简易按钮。然而，它可以做的是为个人和团体提供一套价值观，遵循这些价值观可以将你的组织带上通往有效的 DevOps 社区的道路。帮我一个忙，回去再读一遍那些价值观。你和你的组织是否足够开放以拥抱开源之道？
15 条评论