mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-13 22:30:37 +08:00
98 lines
12 KiB
Markdown
98 lines
12 KiB
Markdown
技术如何改变敏捷的规则
|
||
======
|
||
|
||
|
||
|
||
越来越多的企业正因为一个非常明显的原因开始尝试敏捷和[DevOps][1]: 企业需要通过更快的速度和更多的实验为创新和竞争性提供优势。而DevOps将帮助我们得到所需的创新速度。但是，在小团队或初创企业中实践DevOps与进行大规模实践完全是两码事。我们都明白这样的一个事实，那就是在10人的跨职能团队中能够很好地解决问题的方案，当将相同的模式应用到100人的团队中时就可能无法奏效。这条道路是如此艰难，以至于IT领导者很容易将敏捷方法的推行再推迟一年。
|
||
|
||
但那样的时代已经结束了。如果你已经尝试过，但是没有成功，那么现在是时候重新开始了。
|
||
|
||
直到现在，DevOps需要为许多组织提供个性化的解决方案，因此往往需要进行大量的调整以及付出额外的工作。但在今天，[Linux容器][2]和Kubernetes正在推动DevOps工具和过程的标准化。而这样的标准化将会加速整个软件开发过程。因此，我们用来实践DevOps工作方式的技术最终能够满足我们加快软件开发速度的愿望。
|
||
|
||
Linux容器和[Kubernetes][3]正在改变团队交互的方式。此外，你可以在Kubernetes平台上运行任何能够在Linux运行的应用程序。这意味着什么呢？你可以运行大量的企业及应用程序(甚至可以解决以前令人烦恼的Windows和Linux之间的协调问题)。最后，容器和Kubernetes将能够满足未来所有运行内容的需求。它们正在经受着未来的考验，以应对机器学习、人工智能和分析工作等下一代解决问题工具。
|
||
|
||
**[ 参考相关文章,[4 container adoption patterns: What you need to know. ] ][4]**
|
||
|
||
让我们以机器学习为例来思考一下。今天，人们可以在大量的企业数据中找到一些模式。当机器发现这些模式时(想想机器学习)，你的员工就能更快地采取行动。随着人工智能的加入，机器不仅可以发现模式，还可以对模式进行操作。如今，三个星期已经成为了一个积极的软件开发冲刺周期。有了人工智能，机器每秒可以多次修改代码。创业公司会利用这种能力来“打扰你”。
|
||
|
||
考虑一下你需要多快才能参与到竞争当中。如果你对于无法对于DevOps和每周一个迭代周期充满信心，那么考虑一下当那个创业公司将AI驱动的过程指向你时会发生什么？现在是时候转向DevOps的工作方式了，否认就会像你的竞争对手一样被甩在后面。
|
||
|
||
### 容器技术如何改变团队的工作？
|
||
|
||
DevOps使得许多试图将这种工作方式扩展到更大范围的团队感到沮丧。即使许多IT(和业务)人员之前都听说过敏捷相关的语言、框架、模型(如DevOps)等承诺将会彻底应用程序开发和IT过程的全部相关内容，但他们还是对此持怀疑态度。
|
||
|
||
**[ 想要获取来自其他CIO们的建议吗？不放参考下我们的综述性资源, [DevOps: The IT Leader's Guide][5]. ]**
|
||
|
||
向你的涉众“推销”快速开发冲刺也不是一件容易的事情。想象一下，如果你以这种方式买了一栋房子：你将不再需要向开发商支付固定的金额，而是会得到这样的信息：“我们将在4周内浇筑完地基，其成本是X，之后再搭建房屋框架和铺设电路，但是我们现在只能够知道地基完成的时间表。”人们已经习惯了买房子的时候有一个预先的价格和交付时间表。
|
||
|
||
挑战在于构建软件与构建房屋不同。同一个建筑商往往建造了成千上万个完全相同的房子，而软件项目从来都各不相同。这是你要克服的第一个障碍。
|
||
|
||
开发和运维团队的工作方式确实不同，我之所以知道这一点是因为我曾经从事过这两方面的工作。企业往往会用不同的方式来激励他们，开发人员会因为更改和创建而获得奖励，而运维专家则会因降低成本和确保安全性而获得奖励。我们会把他们分成不同的小组，并且尽量减少互动。而这些角色通常会吸引那些思维方式完全不同的技术人员。但是这样的解决方案注定会失败，你必须打破横亘在开发和运维之间的藩篱。
|
||
|
||
想想传统情况下会发生什么。业务会把需求扔过墙，这是因为他们在“买房”模式下运作，并且说上一句“我们9个月后见。”开发人员根据这些需求进行开发，并根据技术约束的需要进行更改。然后，他们把它扔过墙传递给运维人员，并说一句“搞清楚如何运行这个软件”。然后，运维人员勤就会奋地进行大量更改，使软件与基础设施保持一致。然而，最终的结果是什么呢？
|
||
|
||
通常情况下，当业务人员看到需求实现的最终结果时甚至根本辨认不出。在过去20年的大部分时间里，我们一次又一次地目睹了这种模式在软件行业中上演。而现在，是时候改变了。
|
||
|
||
Linux容器能够真正地解决这样的问题，这是因为容器缩小了开发和运维之间的间隙。容器技术允许两个团队共同理解和设计所有的关键需求，但仍然独立地履行各自团队的职责。基本上，我们去掉了开发人员和运维人员之间的电话游戏。
|
||
|
||
因为容器技术，我们可以使得运维团队的规模更小，但依旧能够承担起数百万应用程序的运维工作，并且能够使得开发团队可以更加快速地根据需要更改软件。(在较大的组织中，所需的速度可能比运维人员的响应速度更快。)
|
||
|
||
使用容器，您可以将所需要交付的内容与它运行的位置分开。你的运维团队只需要负责运行容器的主机和安全的内存占用，仅此而已。这意味着什么呢？
|
||
|
||
首先，这意味着你现在可以和团队一起实践DevOps了。没错，只需要让团队专注于他们已经拥有的专业知识，而对于容器，只需让团队了解所需集成依赖关系的必要知识即可。
|
||
|
||
如果你想要重新训练每个人，往往会收效甚微。容器技术允许团队之间进行交互，但同时也会为每个团队提供一个围绕该团队优势而构建的强大边界。开发人员会知道需要消耗什么，但不需要知道如何使其大规模运行。运维团队了解核心基础设施，但不需要了解应用程序的细节。此外，运维团队也可以通过更新应用程序来解决新的安全问题，以免你成为下一个数据泄露的热门话题。
|
||
|
||
想要为一个大型IT组织，比如30000人的团队教授运维和开发技能？那或许需要花费你十年的时间，而你可能并没有那么多时间。
|
||
|
||
当人们谈论“构建新的云原生应用程序将帮助我们摆脱这个问题”时，请批判性地进行思考。你可以在10个人的团队中构建云原生应用程序，但这对《财富》杂志前1000强的企业而言或许并不适用。除非你不再需要依赖现有的团队，否则你无法一个接一个地构建新的微服务：你最终将得到一个竖井式的组织。这是一个诱人的想法，但你不能指望这些应用程序来重新定义你的业务。我还没见过哪家公司能在如此大规模的并行开发中获得成功。IT预算已经受到限制；在很长一段时间内将预算翻倍甚至三倍是不现实的。
|
||
|
||
### 当奇迹发生时: 你好, 速度
|
||
|
||
Linux容器就是为扩容而生的。一旦你开始这样做，[Kubernetes之类的编制工具就会发挥作用][6]，这是因为你将需要运行数千个容器。应用程序将不仅仅由一个容器组成，它们将依赖于许多不同的部分，所有的部分都会作为一个单元运行在容器上。如果不这样做，你的应用程序将无法在生产环境中很好地运行。
|
||
|
||
思考一下有多少小滑轮和杠杆组合在一起来支撑你的业务，对于任何应用程序都是如此。开发人员负责应用程序中的所有滑轮和杠杆。(如果开发人员没有这些组件，您可能会在集成时做噩梦。)与此同时，无论是在线下还是在云上，运维团队都会负责构成基础设施的所有滑轮和杠杆。做一个较为抽象的比喻，使用Kubernetes，你的运维团队就可以为应用程序提供运行所需的燃料，但又不必成为所有方面的专家。
|
||
|
||
开发人员进行实验，运维团队则保持基础设施的安全和可靠。这样的组合使得企业敢于承担小风险，从而实现创新。不同于打几个孤注一掷的赌，公司中真正的实验往往是循序渐进的和快速的。
|
||
|
||
从个人经验来看，这就是组织内部发生的显著变化：因为人们说：“我们如何通过改变计划来真正地利用这种能力进行实验？”它强制执行敏捷计划。
|
||
|
||
举个例子，使用DevOps模型、容器和Kubernetes的KeyBank如今每天都会部署代码。(观看视频[7]，其中主导了KeyBank持续交付和反馈的John Rzeszotarski将解释这一变化。)类似地，Macquarie银行也借助DevOps和容器技术每天将一些东西投入生产环境。
|
||
|
||
一旦你每天都推出软件，它就会改变你计划的每一个方面，并且会[加速业务的变化速度][8]。Macquarie银行和金融服务集团的CDO，Luis Uguina表示：“创意可以在一天内触达客户。”(参见[9]对Red Hat与Macquarie银行合作的案例研究)。
|
||
|
||
### 是时候去创造一些伟大的东西了
|
||
|
||
Macquarie的例子说明了速度的力量。这将如何改变你的经营方式？记住，Macquarie不是一家初创企业。这是CIO们所面临的颠覆性力量，它不仅来自新的市场进入者，也来自老牌同行。
|
||
|
||
开发人员的自由还改变了运营敏捷商店的CIO们的人才方程式。突然之间，大公司里的个体(即使不是在最热门的行业或地区)也可以产生巨大的影响。Macquarie利用这一变动作为招聘工具，并向开发人员承诺，所有新招聘的员工将会在第一周内推出新产品。
|
||
|
||
与此同时，在这个基于云的计算和存储能力的时代，我们比以往任何时候都拥有更多可用的基础设施。考虑到[机器学习和人工智能工具将很快实现的飞跃][10]，这是幸运的。
|
||
|
||
所有这些都说明现在正是打造伟大事业的好时机。考虑到市场创新的速度，你需要不断地创造伟大的东西来保持客户的忠诚度。因此，如果你一直在等待将赌注押在DevOps上，那么现在就是正确的时机。容器技术和Kubernetes改变了规则，并且对你有利。
|
||
|
||
**想要获取更多这样的智慧吗, IT领导者? [订阅每周邮件][11].**
|
||
|
||
--------------------------------------------------------------------------------
|
||
|
||
via: https://enterprisersproject.com/article/2018/1/how-technology-changes-rules-doing-agile
|
||
|
||
作者：[Matt Hicks][a]
|
||
译者：[JayFrank](https://github.com/JayFrank)
|
||
校对：[校对者ID](https://github.com/校对者ID)
|
||
|
||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||
|
||
[a]:https://enterprisersproject.com/user/matt-hicks
|
||
[1]:https://enterprisersproject.com/tags/devops
|
||
[2]:https://www.redhat.com/en/topics/containers?intcmp=701f2000000tjyaAAA
|
||
[3]:https://www.redhat.com/en/topics/containers/what-is-kubernetes?intcmp=701f2000000tjyaAAA
|
||
[4]:https://enterprisersproject.com/article/2017/8/4-container-adoption-patterns-what-you-need-know?sc_cid=70160000000h0aXAAQ
|
||
[5]:https://enterprisersproject.com/devops?sc_cid=70160000000h0aXAAQ
|
||
[6]:https://enterprisersproject.com/article/2017/11/how-enterprise-it-uses-kubernetes-tame-container-complexity
|
||
[7]:https://www.redhat.com/en/about/videos/john-rzeszotarski-keybank-red-hat-summit-2017?intcmp=701f2000000tjyaAAA
|
||
[8]:https://enterprisersproject.com/article/2017/11/dear-cios-stop-beating-yourselves-being-behind-transformation
|
||
[9]:https://www.redhat.com/en/resources/macquarie-bank-case-study?intcmp=701f2000000tjyaAAA
|
||
[10]:https://enterprisersproject.com/article/2018/1/4-ai-trends-watch
|
||
[11]:https://enterprisersproject.com/email-newsletter?intcmp=701f2000000tsjPAAQ
|