DevOps文化如何帮助将人员，流程和工具调整为更统一的客户关注点。
DevOps是一种敏捷的组织变革方法，旨在弥合团队之间传统的孤立鸿沟，并建立促进更大协作的新流程。尽管新工具和敏捷工程实践使DevOps成为可能，但这些不足以获取DevOps的好处。如果没有正确的思维方式，仪式和文化，很难实现DevOps的全部承诺。
人员和文化是成功实施DevOps的首要因素。
什么是DevOps文化？
本质上，DevOps文化涉及开发和运营之间为其创建和维护的产品之间的紧密协作和共同责任。这有助于公司调整人员，流程和工具，以更加统一地关注客户。
它涉及培养负责产品整个生命周期的多学科团队。DevOps团队可以自主工作，并拥护软件工程文化，工作流和工具集，从而将运营需求提升到与架构，设计和开发相同的重要性水平。开发人员也可以运行它的理解使开发人员更贴近用户，从而更好地了解用户的需求。随着运营团队更多地参与开发过程，他们可以增加维护需求和客户需求，以获得更好的产品。
DevOps文化的核心是提高传统上在孤岛上工作的团队之间的透明度，沟通和协作。但是，需要发生重要的文化转变，以使这些团队更紧密地联系在一起。DevOps是一种组织文化转变，强调持续学习和持续改进，特别是通过团队自治，快速反馈，高度同理心和信任以及跨团队协作。
DevOps需要分担责任。开发和运营人员都应对产品的成败负责。开发人员不仅要做构建和交付运营的工作，还应该承担整个产品生命周期内监督产品的责任。他们测试和操作软件，并与QA和IT Ops进行更多协作。当他们了解运营面临的挑战时，他们更有可能简化部署和维护。同样，当操作人员了解系统的业务目标时，他们可以与开发人员合作以帮助定义系统的操作需求并采用自动化工具。
自主团队是DevOps的另一个重要方面。为了使开发和运营团队有效地进行协作，他们需要制定决策和实施更改，而无需繁琐且漫长的审批流程。这涉及将信任移交给团队，并建立一个不必担心失败的环境。这些团队应具有正确的流程和工具，以针对客户面临的每个风险级别更快，更轻松地做出决策。
例如，典型的开发工作流程可能需要来自不同团队的多个贡献者的参与才能部署代码更改。开发人员进行代码更改，并将其推送到源代码控制存储库，构建工程师构建代码并将其部署到测试环境，产品所有者在问题跟踪工具中更新工作状态，等等。自治团队将负责自动化这些过程的工具的优势，以便推送新代码会触发将新功能构建和部署到测试环境中，并且问题跟踪工具会自动更新。
例如，一个团队受困于诸如必须与一个单独的运营团队一起开票以进行琐碎的基础架构更改（例如新的DNS条目）之类的要求。一个需要几秒钟才能完成的任务最终要花几天或几周才能完成。自治团队有能力自己执行此类更改，无论是由团队中具有正确技能和经验的个人，还是可以使用自助工具。
DevOps团队文化重视快速反馈可以帮助不断改进统一的开发和运营团队。在开发和运营团队处于孤立的孤岛的环境中，关于生产中应用程序软件的性能和稳定性的反馈通常很慢，很难反馈给开发团队。DevOps通过在设计和实施应用程序监视和报告策略时要求操作人员之间的协作，确保开发人员获得快速迭代和改进应用程序代码所需的快速反馈。例如，任何具有足够功能的持续集成工具都将能够自动构建和测试新的代码推送，并为开发人员提供有关其代码质量的即时反馈。
自动化对于DevOps文化至关重要，因为它可以实现出色的协作并释放资源。在软件开发和IT团队之间实现流程的自动化和集成可帮助他们更快，更可靠地构建，测试和发布软件。
DevOps文化的好处是什么？
拥抱DevOps文化最明显，最有意义的好处是简化，频繁且高质量的软件版本。这不仅可以提高公司绩效，而且可以提高员工满意度。
根据“加速：建立和扩展高性能技术组织”一书，DevOps文化可以培养高度的信任和协作，从而导致更高质量的决策制定，甚至更高的工作满意度。
拥抱DevOps文化是在不牺牲员工满意度的前提下建立一个高性能工程组织的关键。这是双赢。对于工程师而言，没有什么感觉像经常和轻松地部署和运行稳定，高性能的软件，使用户感到满意，而对于高管而言，改进的业务成果无疑是一个打击。
有哪些挑战？
全面拥抱DevOps文化通常需要个人和团队对其工作方式进行重大更改，因此需要组织最高层的支持。
基层的努力可以而且通常是获取DevOps转型的管理和执行层认可的重要起点。赞成采用更广泛的DevOps的最引人注目的论点通常是少数个人或小团队采用DevOps方法并开始证明成功。
如果所涉及的个人或团队之间存在冲突历史，那么在DevOps文化中典型的高度自治和信任就很难培养。在尝试采用DevOps方法之前，团队越孤单，建立联系就越困难。
改变很难。即使在现有个人和团队之间存在高度和谐的环境中，如果不能清楚地表达和理解变更的好处，也可能难以推动接受和愿意投入工作。
可以理解的是，具有强烈工程学思维的组织通常会立即跳入使用工具和技术来解决业务挑战的过程。是的，有一些工具和技术可以帮助您的组织过渡到DevOps方法。但是，在不改变文化的情况下改变工具和技术通常被称为“载运人的DevOps”，因为它在不解决基础缺陷的情况下改变了外观。
过渡到DevOps文化的注意事项
公开交流
DevOps试图应对的最基本挑战之一是孤立不同组织单位中的知识，经验和工作。当编写代码的程序员与部署和维护代码的系统管理员之间无法进行通信时，您可能效率低下。
犯错的能力
许多组织，团队和个人对自己和彼此施加极大的压力，以致永不犯错。如果失败不是一种选择，那么个人或团队就不太可能尝试采用新颖的方法来解决问题或开发创新功能。
这种心态反映在过去对“平均故障间隔时间”（MTBF）而非“平均恢复时间”（MTTR）的衡量上。MTBF使用“根本原因分析”之类的工具来识别故障的来源，并尝试防止它们再次发生。MTTR反映了将软件应用程序视为易于以无法预测的方式失败的复杂系统的观点，并着重于在失败时进行快速恢复。
“无懈可击的回顾”是DevOps文化的共同特征。当团队在sprint或项目结束时开会讨论在开放和安全的环境中进展顺利以及可以改进的地方时，可以改善结果。
一无所知的失败之所以行之有效，部分是因为它采用了成长的思维方式，承认错误会发生，但在假设人员和组织都有能力学习，成长和进步的前提下运作。
– “有效的DevOps”詹妮弗·戴维斯和丹尼尔斯凯瑟琳
一套新的流程
培养DevOps文化需要开发解决旧问题的新方法。DevOps要求改变程序员编写应用程序代码并将其“扔到墙上”的孤零零的过程，该团队将负责部署和操作应用程序。DevOps方法要求开发和运营在项目的整个生命周期中协同工作。
通常认为，持续整合和持续交付（CI / CD）对于DevOps文化而言是必需的。Netflix等大型组织采用并推广了第三种过程，即持续部署，但在大多数小型公司中并不普遍采用（或要求）。这是因为将新功能连续部署到生产环境中需要高度确信新代码已经过全面测试并且可以安全部署（例如，在功能切换之后）。因此，除非您的组织每天进行多次部署，否则可能不值得在支持该方法的流程上进行投资。
在大多数情况下，对“基于主干的开发”进行一些更改将大大简化您的CI / CD工作。在此模型中，团队取消了长期存在的功能分支，并频繁提交代码的“ trunk”分支。
基于主干的开发的重要组成部分是全面的自动化测试：单元，集成和回归。这有助于确保在将所有新提交提交到存储库后，对主干分支的所有新提交都进行了彻底审查。
持续集成是自动集成来自软件项目中多个贡献者的代码更改的过程。这不仅包括开发团队，还包括组织的其余部分。例如，产品团队协调何时顺序启动功能和修复以及由哪些团队成员负责。
持续交付是一种组织方法，它将设计，产品和市场营销等工程和非工程团队聚集在一起来交付产品。没有CD的环境会鼓励开发人员将质量保证团队作为主要用户体验的“墙外”行为。这意味着您的存储库的“中继”分支始终处于“可部署”状态。
连续部署允许在进行代码更改时将它们自动部署到生产中，这些更改可以隐藏在功能标记后面，可以部署到一小部分客户，和/或可以轻松回滚。由于团队可以对客户反馈做出反应并快速部署和验证新功能，因此这使团队具有更大的灵活性来应对不断变化的市场和客户需求。他们还可以轻松地回滚功能，从而不会因破坏构建而妨碍团队。
特征标记，特征切换或深色部署是确保将新应用程序功能部署到生产环境时不出现或无法正常工作的常见方法，但只需花费很少的精力即可将它们打开。由于几乎没有负面影响用户的风险，因此该策略可以实现连续部署。通常，通过按地理区域对功能进行细分或运行单独的服务器实例，然后将功能仅发布给用户可访问的一台服务器，将功能限制为一部分用户。
更新的工具链
大多数软件开发团队至少使用某种类型的版本控制，问题跟踪和应用程序监视工具。所有这些都是支持DevOps文化的重要工具，但是传统工具集最重要的补充也许是支持CI / CD的软件。拥有一个可以进行提交，测试和部署的自动化工作流，实际上是获得DevOps文化所需的快速反馈的唯一方法。
DevOps-产生成果的文化转变
数十年来，开发人员一直追求实现更频繁地交付软件，减少工作量和减少错误的梦想。现在，终于可以实现这一目标的工具和实践了。
调查发现，从事DevOps的组织表示，他们交付了更高质量的交付成果（61％），部署频率更高，上市时间更短（49％）。
从业人员说，获得收益的不只是组织，从业者还说他们已经学会了新技能（78％）并获得了加薪（48％）。
培养DevOps文化可能具有挑战性，但是值得开发人员，管理人员和客户提高满意度的回报是值得的。
