谈DevOps是不是很难抓住要点？ 我们为您收集了生动的类比、引人注目的表述和专家的建议，即使是非专家也能帮助您明白要点。 最后，红帽员工自己的 DevOps 是红利。
DevOps 一词起源于 10 年前，已经从 Twitter 的话题标签发展成为 IT 世界中一场强大的文化运动，这是一种鼓励开发人员更快地完成工作、进行实验和迭代的真正哲学。 DevOps 已经与数字化转型的概念密不可分。 但正如 IT 术语中经常发生的那样，在过去十年中，DevOps 获得了许多关于其自身的定义、解释和误解。
因此，你经常会听到关于 DevOps 的问题，比如它和敏捷一样吗？ 或者这是某种特殊的方法论？ 或者它只是“协作”一词的另一个同义词？
DevOps 包含许多不同的概念（持续交付、持续集成、自动化等），因此提炼出重要的内容可能具有挑战性，尤其是当您对该主题充满热情时。 然而，无论您是想向上级传达您的想法，还是只是向家人或朋友讲述您的工作，这项技能都非常有用。 因此，让我们暂时抛开 DevOps 术语的细微差别，重点关注大局。
什么是 DevOps：6 个定义和类比
我们请专家尽可能简单、简短地解释 DevOps 的本质，以便任何技术知识水平的读者都能清楚地了解它的价值。 根据这些对话的结果，我们选择了最引人注目的类比和引人注目的表述，这将帮助您构建有关 DevOps 的故事。
1.DevOps是一种文化运动
“DevOps 是一种文化运动，双方（软件开发人员和 IT 系统运营专家）都认识到，除非有人开始使用软件，否则软件不会带来真正的好处：客户、客户、员工，这不是重点，”高级研究人员 Eveline Oehrlich 说道DevOps 研究所的分析师。 “因此，双方共同确保软件的快速、高质量交付。”
2. DevOps 是为开发人员赋能。
“DevOps 使开发人员能够拥有应用程序、运行它们并从头到尾管理交付。”
Liberty Mutual 保险公司 DevOps 平台总监 Jai Schniepp 表示：“通常，DevOps 被认为是通过构建和实施自动化流程来加速应用程序交付到生产的一种方式。” “但对我来说，这是更基本的事情。” DevOps 使开发人员能够拥有应用程序或特定软件，运行它们并从头到尾管理它们的交付。 DevOps 消除了责任混乱，并指导每个参与创建自动化、开发人员驱动的基础设施的人。”
3. DevOps 是关于创建和交付应用程序的协作。
BMC 总裁兼数字业务自动化主管 Gur Staf 表示：“简单来说，DevOps 是一种软件生产和交付方法，每个人都可以一起工作。”
4.DevOps是一个管道
“只有所有部件装配在一起才可能实现输送机组装。”
“我会将 DevOps 比作汽车装配线，”Gur Staff 继续说道。 – 这个想法是提前设计和制造所有零件，以便无需单独调整即可组装它们。 只有所有部件装配在一起才能组装输送机。 设计和制造发动机的人必须考虑如何将其安装到车身或车架上。 制造刹车的人必须考虑车轮等等。 软件也应该如此。
创建业务逻辑或用户界面的开发人员必须考虑存储客户信息的数据库、保护用户数据的安全措施，以及当服务开始为大量甚至数百万美元的用户受众提供服务时，所有这些将如何工作”。
“让人们协作并思考其他人正在做的工作部分，而不是仅仅专注于自己的任务，是需要克服的最大障碍。 如果你能做到这一点，那么你就有绝佳的数字化转型机会。”Gur Staff 补充道。
5. DevOps 是人员、流程和自动化的正确组合
DevOps Institute 执行董事 Jayne Groll 提供了一个很好的类比来解释 DevOps。 用她的话来说，“DevOps 就像一个包含三类主要成分的菜谱：人员、流程和自动化。 这些成分大部分可以从其他领域和来源获取：精益、敏捷、SRE、CI/CD、ITIL、领导力、文化、工具。 DevOps 的秘诀就像任何好的配方一样，是如何获得这些成分的正确比例和混合，以提高创建和发布应用程序的速度和效率。”
6. DevOps 是指程序员像一级方程式车队一样工作
“比赛不是从头到尾都计划好的，相反，是从结束到开始。”
“当我谈论 DevOps 计划的期望时，我会想到 NASCAR 或一级方程式赛车队作为例子，”红帽云平台营销高级经理兼 DevOps 时事通讯的出版商 Chris Short 说道。 – 这样一支团队的领导者有一个目标：在比赛结束时获得尽可能高的位置，同时考虑到团队可用的资源和面临的挑战。 在这种情况下，比赛不是从开始到结束进行计划，而是相反，从结束到开始进行。 首先，设定一个雄心勃勃的目标，然后确定实现该目标的方法。 然后它们被分解为子任务并委托给团队成员。”
“车队在比赛前花了整整一周的时间来完善进站。 他进行力量训练和有氧运动，以在艰苦的比赛日保持体形。 练习共同努力解决比赛中可能出现的任何问题。 同样，开发团队应该培养经常发布新版本的技能。 如果您拥有此类技能和运行良好的安全系统，那么新版本投入生产的情况也会更频繁。 在这种世界观中，速度的提高意味着安全性的提高。”肖特说道。
“这不是做‘正确的事’，”肖特补充道，“而是尽可能多地消除阻碍实现预期结果的因素。 根据您实时收到的反馈进行协作和适应。 为异常情况做好准备，并努力提高质量，尽量减少其对实现目标的影响。 这就是 DevOps 世界中等待着我们的东西。”
如何扩展 DevOps：专家的 10 个技巧
只是 DevOps 和大众 DevOps 是完全不同的东西。 我们将告诉您如何克服从第一个到第二个过程中的障碍。
对于许多组织来说，DevOps 之旅的开始是轻松愉快的。 充满激情的小团队被创建，旧流程被新流程取代，第一个成功很快就会到来。
唉，这只是一种虚假的浮华，一种进步的幻觉，北高地咨询公司董事总经理兼数字主管本·格林内尔 (Ben Grinnell) 表示。 早期的胜利当然令人鼓舞，但它们无助于实现在整个组织中广泛采用 DevOps 的最终目标。
不难看出，其结果是一种“我们”和“他们”之间的分裂文化。
“通常，组织启动这些开创性项目时，认为它们将为主流 DevOps 铺平道路，而不考虑其他人是否能够或愿意遵循这条道路，”Ben Grinnell 解释道。 – 实施此类项目的团队通常是从自信的“瓦兰吉人”中招募的，他们已经在其他地方做过类似的事情，但对您的组织来说是新手。 与此同时，他们被鼓励打破和破坏对其他人仍然具有约束力的规则。 很容易看出，结果是“我们”和“他们”的文化抑制了知识和技能的转移。
“这种文化问题只是 DevOps 难以扩展的原因之一。 DevOps 团队面临着越来越多的技术挑战，这是快速增长的 IT 优先公司所特有的。”Scalyr 创始人兼董事长 Steve Newman 说道。
“在现代世界，只要有需求，服务就会发生变化。 不断实现和实施新功能固然很棒，但协调这一过程并消除出现的问题却是一件真正令人头疼的事情，Steve Newman 补充道。 – 在快速发展的组织中，跨职能团队的工程师努力保持对变化及其产生的依赖级级联效应的可见性。 此外，当工程师被剥夺这个机会时，他们会感到不高兴，因此，他们更难理解所出现问题的本质。”
如何克服上述挑战并在大型组织中大规模采用 DevOps？ 专家敦促您保持耐心，即使您的最终目标是加快软件开发周期和业务流程。
1. 请记住，文化变革需要时间。
DevOps 研究所执行董事 Jayne Groll： “在我看来，DevOps 的扩展应该像敏捷开发一样增量和迭代（并且同样涉及文化）。 敏捷和 DevOps 强调小型团队。 但随着这些团队的数量和整合度的增加，我们最终会有更多的人采用新的工作方式，从而发生巨大的文化转型。”
2.花足够的时间规划和选择平台
Perfecto 首席技术布道师 Eran Kinsbruner： “为了扩展工作，DevOps 团队必须首先学会结合传统流程、工具和技能，然后慢慢培育和稳定 DevOps 的每个单独阶段。 这一切都从仔细规划用户故事和价值流开始，然后使用基于主干的开发或其他最适合分支和合并代码的方法编写软件和版本控制。”
“然后是集成和测试阶段，其中已经需要可扩展的自动化平台。 对于 DevOps 团队来说，选择适合他们的技能水平和项目最终目标的正确平台非常重要。
下一阶段是部署到生产，这应该使用编排工具和容器完全自动化。 在 DevOps 的各个阶段（生产模拟器、QA 环境和实际生产环境）都拥有虚拟化环境非常重要，并且始终仅使用最新数据进行测试以获得相关结论。 分析必须是智能的，能够处理大数据并提供快速且可操作的反馈。”
3. 消除责任中的愧疚感。
戈登·哈夫 (Gordon Haff)，红帽布道者： “创建一个允许和鼓励实验的系统和氛围可以避免敏捷软件开发中所谓的成功失败。 这并不意味着没有其他人对失败负责。 事实上，确定责任人变得更加容易，因为“负责”不再意味着“造成事故”。 即责任的本质发生了质的变化。 有四个因素变得至关重要：颠覆的程度、方法、生产流程和激励措施。” （您可以在 Gordon Huff 的文章“DevOps 课程：健康实验的 4 个方面”中阅读有关这些因素的更多信息。）
4. 扫清前进道路
North Highland 咨询公司董事总经理兼数字主管 Ben Grinnell： “为了实现规模化，我建议与开创性项目一起启动“道路清理”计划。 该计划的目标是清理 DevOps 先驱者留下的垃圾，例如过时的规则之类的东西，以便前进的道路保持清晰。”
“通过广泛庆祝新工作方式的成功，通过超越先锋群体的沟通，为人们提供组织支持和动力。 指导参与下一波 DevOps 项目并对首次使用 DevOps 感到紧张的人员。 请记住，这些人与先驱者非常不同。”
5.工具民主化
Scalyr 创始人兼董事长 Steve Newman： “工具不应该对人们隐藏，而且对于任何愿意投入时间的人来说，它们应该相对容易学习。 如果查询日志的能力仅限于“经过认证”使用某个工具的三个人，那么即使您拥有非常大的计算环境，您也始终最多只有三个人可以处理该问题。 换句话说，这里存在一个瓶颈，可能会导致严重的（业务）后果。”
6、为团队合作创造理想的条件
ITV 通用平台负责人 Tom Clark： “你可以做任何事情，但不能同时做所有事情。 因此，设定大目标，从小事做起，并快速迭代地前进。 随着时间的推移，您将获得完成任务的声誉，因此其他人也会想使用您的方法。 并且不用担心建立一支高效的团队。 相反，为人们提供理想的工作条件，效率就会随之而来。”
7. 不要忘记康威定律和看板
CollabNetVersionOne 软件交付和 DevOps 战略总监 Logan Daigle： “了解康威定律的后果很重要。 用我松散的话说，这条法律规定，我们创建的产品和我们用于创建产品的流程（包括 DevOps）的结构与我们的组织相同。”
“如果组织中有很多孤岛，并且在规划、构建和发布软件时控制权多次易手，那么扩展的效果将为零或短暂。 如果一个组织围绕以市场为重点的产品建立跨职能团队，那么成功的机会就会大大增加。”
“扩展的另一个重要方面是在看板板上显示所有正在进行的工作（WIP、workinprogress）。 当一个组织有一个让人们可以看到这些东西的地方时，它会极大地鼓励协作，这对扩展有积极的影响。”
8.寻找旧疤痕
Manuel Pais，DevOps 顾问和 Team Topologies 的合著者： “将 DevOps 实践超越 Dev 和 Ops 本身并尝试将其应用到其他功能并不是最佳方法。 这肯定会产生一些影响（例如，通过自动化手动控制），但如果我们从了解交付和反馈流程开始，可以取得更多成果。”
“如果组织的 IT 系统中存在旧伤痕——由于过去的事件而实施的程序和管理机制，但已经失去了相关性（由于产品、技术或流程的变化）——那么它们肯定需要被移除或平滑化，而不是自动化低效或不必要的流程。”
9. 不要滋生 DevOps 选项
Eggplant 运营总监 Anthony Edwards： “DevOps 是一个非常模糊的术语，因此每个团队最终都会有自己的 DevOps 版本。 当一个组织突然拥有 20 种不能很好地相处的 DevOps 时，没有什么比这更糟糕的了。 三个开发团队不可能在开发和产品管理之间拥有自己的特殊接口。 当转移到生产模拟器时，产品也不应该对处理反馈有自己独特的期望。 否则，你将永远无法扩展 DevOps。”
10.宣扬DevOps的商业价值
Scalyr 创始人兼董事长 Steve Newman： “努力认识 DevOps 的价值。 学习并随意谈论您所做的事情的好处。 DevOps 可以节省大量时间和金钱（想想看：更少的停机时间，更短的平均恢复时间），DevOps 团队必须不懈地强调（并宣传）这些举措对业务成功的重要性。 这样你就可以扩大 DevOps 的追随者圈子并增加 DevOps 在组织中的影响力。”
红利
上 我们自己的 DevOps 将于 13 月 XNUMX 日到来——是的，红帽作为软件制造商，拥有自己的 DevOps 团队和实践。
我们的工程师 Mark Birger 为整个组织的其他团队开发内部自动化服务，他将用纯俄语讲述他自己的故事 - 红帽 DevOps 团队如何将应用程序从 Ansible 管理的 Hat Virtualization 虚拟环境迁移到成熟的容器格式OpenShift 平台。
但这不是全部：
一旦组织将工作负载转移到容器中，传统的应用程序监控方法可能不起作用。 在第二次演讲中，我们将解释改变日志方式的动机，并展示引导我们采用现代日志记录和监控方法的道路的延续。
来源： habr.com