devops 开源
您可能以为我将要讨论为什么要使用开放源代码工具作为组织中有效的DevOps文化的基础的所有原因，但这不是要解决的问题。 不能将与我一起工作的团队所面临的挑战的复杂性边缘化，但是我相信工程师会弄清楚工具的一部分。 信不信由你，令人生畏的部分包裹在文化变革中。
我花了很多时间阅读有关文化变革的信息 ，拥有有效的DevOps社区所需的知识 ，如何组建功能强大的团队 ，并提出以下问题：“ 我如何开发DevOp？ ”我在工具带上贴了一些新东西。 但是，没有什么比这更能引起我的共鸣了：
公开交流
当信息开放时，我们可以彼此学习更多。 自由交流思想对于创建允许人们学习和使用现有信息来创造新思想的环境至关重要。
参与性
当我们有自由进行协作时，我们就可以创建。 我们可以解决任何人都无法独自解决的问题。
快速成型
快速的原型会导致快速的失败，但这会导致更快地找到更好的解决方案。 当您有空进行实验时，可以用新的方式看问题，并在新的地方寻找答案。 你可以边做边学。
功权主义
在精英管理中，最好的想法会取胜。 在精英管理中，每个人都可以访问相同的信息。 成功的工作决定了哪些项目兴起，并需要社区的努力。
社区
社区是围绕共同的目的而形成的。 他们汇集了各种想法并共享工作。 一个全球社区可以共同创造超越任何个人能力的东西。 它使工作倍增，并分担工作。 在一起，我们可以做更多的事情。
这就是您获得有效的DevOps文化的方式。 您采用开源方式。
如果您没有握拳，请记住您过去曾经喜欢过的工作，然后再读一遍。
在Red Hat之前的职业生涯充满了诸如“只做你的工作”和“就是这样，你不能改变它”之类的陈述。 我内心感到非常恐惧，不得不告诉某人他们没有主意，不是因为这不能解决很多问题，而是因为他们不认识合适的人或不知道获得想法的最佳方法跨越。
当您进行公开交流时 ，我们鼓励所有人参加 ：
人们彼此交谈，并建立在彼此的集体经验的基础上。
人们在共同努力时赢得彼此的尊重。
当彼此了解并互相尊重时，人们不太可能说“这是某某一项工作，而不是我的工作”。
如果有人说“一起工作，否则”，没有团队会相信他们处于最佳工作环境中。 是的，他们会一起工作，但是您是否不想给他们一个想要一起工作的理由？ 原因可能很简单，例如帮助两个人在相似的利益上建立联系，也可能难以使拥有长期不喜欢彼此的团队合作在一起。 但是，这里的关键要素是通向他人并尊重与您共度一周的人的道路。 归根结底，您需要营造一个可以发表意见，可以发表想法，可以分享的环境。
即使在我正在研究的团队中 ，开源方式的价值都得到了单独体现，我们也必须努力工作，以继续培养这种全球性的社区和协作意识。 即使在Red Hat，也很难 。 我每天都在努力为我们的团队提供尽可能多的可见性，而不管它看起来多么琐碎。 结果呢？ 人们正在分享他们的想法，并帮助建立我们都可以为之骄傲和支持的东西。
快速的原型制作和精英管理
与我合作的工程师团队很早就发生了一件很棒的事。 他们使我想起完成某件事的重要性。 我们花了很多时间试图弄清楚我们可以处理的事情及其结果？ 好吧，坦率地说-很多话题。
能够向某人展示您在做什么，并能收到有关该事情的反馈，这比说话要令人满意得多。 快速成型？ 能够看到代码 ，而不是让想法消失在需求漏洞中并在质量保证体系中重新出现，真是令人满足，我无法为此大喊大叫。 根据我过去在封闭源代码项目中的经验，我没有看到交付的代码，收到的更改输入以及随后很快进行的修改。 因此，这对我来说仍然是变革性的。
不要误会我的意思，这不是一件容易的事。 团队早期就做出了一项技术决定，即继续开发自定义应用程序 ，该应用程序可以提供某些系统信息 （例如正在运行的软件版本），而无需对服务器进行根访问。 我知道已经有工具可以做到这一点，但是团队希望能够快速采取一些措施来减轻这种痛苦 。 完成后，我们同意我们将开始寻求长期解决方案以提供帮助。 我们仍然感到该决定带来的痛苦； 在这个项目涉及的范围内， 精英管理处于全功能模式，没有人会害羞地分享有关对其服务器产生的影响的详细信息。 但是，我仍然可以说这项工作是成功的，因为归根结底，它使最需要它的人们感到高兴，并且肯定会引起人们与我交谈。
考虑一下
如果员工感觉不舒服，无法分享想法，因为不是工作而被告知不进行协作，或者暗示其财务状况围绕着绩效，您会认为DevOps转型有多难？一种功能，整个系统的思维方式没有重点吗？
开源方式并不是成功的捷径。 但是，它可以做的是为个人和群体提供一套价值观念，使您的组织踏上通往有效DevOps社区的道路。 请帮我一个忙，然后回去再次阅读这些值。 您和您的组织是否足够开放以采用开源方式？
翻译自: https://opensource.com/business/14/4/devops-adopts-open-source
devops 开源
