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