devops 文化_Devops有文化问题吗？

devops 文化

在山景城的Devopsdays会议上，Spike Morelli主持了关于文化重要性的开放空间讨论。 他担心，当人们思考和谈论开发人员时，他们思考和谈论的工具和实践过多，而对文化，协作和沟通的思考不足，对使人们紧密合作并关心紧密合作的关注不足–随着越来越多的供应商将自己投入发展，这种情况变得越来越糟。

在开放空间上，我们讨论了定义文化并将其与其他“软弱多变”的事物进行交流的问题。 重要的是什么，为什么。 是什么让人们对开发人员感到兴奋，以及如何将其传播给更多的人，以及如何在不敏捷和透明的公司中坚持下去。

文化不是您通过谈论而建立的

文化就像质量。 您不会通过谈论文化或质量来建立文化或质量。 您通过做事，行动，使事情发生和使事情发生变化并耐心地，不断地加强这些行动来构建它。

谈论很重要，但是谈论正确的事情。 讲一些好故事，讲述有关人员和组织如何使事情变得更好以及他们如何做的故事。 他们所做的工作是有效的，而他们所做的却是无效的–他们是如何失败的，以及他们从失败中学到的知识以及如何通过失败进行学习，以便他人可以向他们学习。 这种透明和诚实是使devop社区如此引人注目和令人信服的原因之一–相互竞争的组织争夺客户和人才并提供资金，公开分享他们的运营失败和经验教训，以及分享一些他们曾经建立自己的成功。

您需要工具来使Devops正常工作

Devops需要良好的工具才能成功。 涉及软件工作的任何事情也是如此。 进行敏捷开发。 敏捷是关于“人员超过流程和工具”。 放置某种敏捷工具无法获得敏捷。 开发人员可以并且通常更喜欢使用非正式和低技术含量的方法，例如在卡片墙上组织工作。 但是我不知道有没有成功的敏捷开发团队至少不依赖良好的持续集成平台和自动化测试工具。 没有这些工具，敏捷开发将无法扩展，敏捷团队也无法成功交付软件。

对于开发人员而言，情况更是如此。 Puppet和Chef和cfengine，statsd和Graphite等工具以及不同的日志管理工具集都是devop的必要组成部分。 没有像这些devops这样的工具就无法工作。 工具不能做出改变，但是如果没有合适的工具，人们就无法改变工作方式。  

Devops没有文化问题-尚未

据我所知，devops并没有文化上的问题-至少现在还没有。 在本次会议，Velocity或其他会议，聚会或论坛上，与我谈论过开发问题的每个人（也许只有少数供应商正在寻找一个角度），似乎都对实现更好的运营，并且所有人都在与其他人认真，诚实地合作，以实现这一目标。

我听到有人谈论部署和配置，监控，指标和自助服务API，自动化操作测试框架以及创建操作体系结构模式目录的问题。 关于工具和实践。 但是每个人都在以认真，开放，透明和协作的方式来做到这一点。 他们生活在文化中。

随着Devops理念逐渐流行并最终成为主流（我认为它将成为现实），devops将会发生变化，就像敏捷开发已成为主流一样已经发生了变化。 在具有成千上万开发人员的大型官僚企业中，敏捷更重，更正式，而且没有那么有趣。 但是它仍然是敏捷的。 开发人员仍然能够更快地交付工作软件。 他们彼此之间以及与客户之间进行更多的交谈，以了解他们的工作并解决问题，并找到更好，更快地工作的新方法。 他们更多地专注于完成工作，而较少关注推纸和处理。 这是一件好事。

随着较大的公司了解更多关于devops的知识并采用和适应它，它将变得与众不同。 随着devop应用于在线Web服务之外的不同行业，并且对于风险的不同限制具有不同的容忍度，因此它将改变。 随着时间的流逝，devops社区不断壮大，参与其中的人们发生了变化，更多的人找到了更多从devops赚钱的方法，devops将更多地涉及培训和认证，教练和咨询，以及更多有关商业工具或通过开源工具赚钱。

开发人员将发生变化-并非总是会变得更好。 那会很烂。 但从本质上讲，我认为devop仍将是使dev和op在一起解决操作问题，获得反馈和对变更进行响应，使操作更简单，更透明。 那将是一件好事。

参考： Devops是否有文化问题？ 来自我们的JCG合作伙伴 Jim Bird在Building Real Software博客中获得。

翻译自: https://www.javacodegeeks.com/2012/07/does-devops-have-culture-problem.html

devops 文化