文档结构  
可译网翻译有奖活动正在进行中,查看详情 现在前往 注册?
原作者:Anders Wallgren (2016-12-30)    来源:Dzone [英文]
CY2    计算机    2016-12-30    3评/780阅
翻译进度:已翻译   参与翻译: vincentsun (22)

2016年底将近。随着2017年到来,我们开始反思2016年DevOps世界的一些进展,有待解决的挑战,以及一些将在未来改变软件交付行业的趋势。

为告别2016年并迎接新年,我们主办了一个特别的持续讨论特辑(#c9c9),由业界名人和专家回顾2016年DevOps的状态,并探讨他们认为2017年将会流行的趋势。

第 1 段(可获 1.26 积分)

我们的专家组包括Robert Stroud,Forrester首席分析师;Nicole Forsgren,DORA CEO和首席科学家;Chris Riley,fixate.io分析师;Alan Shimel,DevOps.com主编;Manuel Pais,InfoQ和Skelton Thatcher上的文章作者;以及我们的Sam Fell和Anders Wallgren。下面我们将介绍,对于DevOps将要在2017年发生的事情,各位专家独特的观点,以及他们在2017年DevOps方面的一些决策。

slide7

回顾2016年

Pais 回顾了2016年,认为这一年DevOps从草根运动,转变为一个管理导向的转型:我认为2016年我们看到了DevOps跨越了从青涩到成熟的鸿沟。我喜欢做个区分,因为我认为在不同的团队中有不同的趋势发生。对大多数DevOps的早期采用者——就是那些已经进行DevOps一段时间的组织——我经常看到他们正聚焦于什么是组织团队的最好方式的问题上。他们的团队基本上都从仅有几个人了解持续交付、DevOps等概念,到真正建立了嵌入了所有他们希望开发组使用的服务的平台组,这在某种程度上实现了精简。

第 2 段(可获 2.66 积分)

对于DevOps的后期采用者,我们现在看到很多大型组织试图采用DevOps。这很有意思,因为我看到很多客户的管理层都认为“好吧,我们需要使用DevOps”。在此之前,早期采用者,如在DevOps 企业峰会发言的公司,通常底层的人员先开始使用DevOps。当有结果的时候,管理层再来支持他们。但现在,管理层引入了使用DevOps的想法,而底层的人有的时候会有点疑惑,因为没有一个DevOps对他们来说意味着什么的解释。因此这就是就组织而言,我看到的主流趋势。

第 3 段(可获 1.53 积分)

比起运营团队来说,开发团队仍是2016年主要采用DevOps的人, Stroud解释道:“在2016年,更多说法是:‘我怎样建立一个DevOps组织,来跟上开发进度和改变的步伐?’我们获取的统计数据之一是关于DevOps在开发和运营团队中采用情况的。这是不是很讽刺?因为DevOps的名字是dev(开发)和ops(运营)。我们仍看到在开发中采用DevOps的情况远多于在运营中,但好消息是根据Forrester的数据来看,这个差距正在缩小。这是正在发生的一种情况,但我们同时看到容器和容器化的出现对DevOps的影响。”

第 4 段(可获 1.59 积分)

Riley 对2016年DevOps的“性感程度”和容器环境的评论:DevOps已经不再性感了。在2016年,对于DevOps到底是什么,我们的感觉已经真实多了。我认为2016年中,我们开始看到有人要么已经开始搭建成功的环境,要么最后失败了。我认为这与敏捷模型的采纳非常类似,我们会很快知道人们是在使用瀑布模型2.0,还是他们确实在实践DevOps。这不是一种技术。

对我个人来说,2016年我对Docker更为认同了。我很高兴地看到很多伴随Docker而来的进化。我认为Docker将在2017年带来巨大影响。Docker不会变成容器的同义词,我认为容器化环境很有可能被大家认同。

第 5 段(可获 2.01 积分)

Forsgren来说,还不知道DevOps到底是什么的组织的数量令人担忧:在我来看,2016年人们跟上了步伐。那些知道他们在干什么的人真的跟上了步伐,而且似乎表现优秀的人真的腾飞了,他们很喜欢DevOps。这很神奇,我们听说过一些很有趣的故事,我们在数据里面能看到它。但你还是听说很多组织还没听过DevOps。他们不太清楚这到底是什么。他们相信DevOps会很不错。这倒是没问题,我本不该因此吃惊,但我还是有些担忧。我们看到越来越多的人被说服他们应该跳上DevOps的列车,否则他们会被远远落在后面,但我们还知道有些公司不在意这一点,只是认为“我们没问题的,我们已经这样做20年了”。

第 6 段(可获 2.24 积分)

Fell强调了小型的、增量的改变的重要性,因为这些改变会带来巨大的提升:这种情况非常真实:从小型的、增量的流程或工具等方面的改进中,产生了令人惊叹的价值、生产力的进步,这是一个加速的循环。Gene Kim说每日工作质量的提升实际上比每日工作的绝对质量更重要。我相信这是真的。如果你持续地提高,你最后会比那些每天都做得不错,但从来不前进的人变得更好。

第 7 段(可获 1.44 积分)

反思2016年,Shimel 在DevOps的使用方面建立了自己的理论:我称我的理论为DevOps的口袋。将DevOps的口袋想象为气泡,就像小孩子玩耍的气泡一样。对于比其余组织先走一步的组织来说,组织内部有多个DevOps的口袋,小型组织,不是很高层的行政主导,而是中层管理或是自底向上,至中层为止。我们看见这些人过去三年在Gene和Electric Cloud的DevOps企业峰会上发言。我们看到的是,在这些起步较早的组织里面,可以说他们DevOps的口袋现在结合在一起,形成了更大的气泡。我们还是有一些只有一两个DevOps口袋——小气泡——的组织。但这其中有些气泡爆裂了,我们再没有听说过它们。

第 8 段(可获 1.73 积分)

Wallgren 讨论了2016年兴起的容器和微服务:2016年有几件事情得到了深入讨论。容器是一件大事。与之相关地,我认为微服务也是。我觉得即将发生的,以及大多数人都开始意识到的(有些人很艰难地意识到)事情是,你很难基于一个蹩脚的体系结构来把事情做好,无论那是一个对于流水线还是应用的蹩脚体系结构。应用体系结构同样在你执行DevOps的能力中起到重要作用。如果想要处理一堆遗留下来的软件,而且可能有很多人还没有做过DevOps,那这些人要怎么做呢?对于一个遗留下来的需要10个小时来搭建、三星期来测试的应用来说,你要做些什么呢?你最好是从头搭建一个新的应用,但我认为如何处理遗留下来的软件才是未来比较有趣的方面。

第 9 段(可获 2.26 积分)

下一步是什么?展望2017年

Stroud 认为2017年主要有三大趋势:首先,我看到一些组织希望使用DevOps方法论来驱动主机研发,不仅仅是主机的发展,同时能够加速开发转化到生产的过程,将一个组织每年发布一两个主要的发布版本,变为利用DevOps实践、实验和技术实现的季度甚至月度发布。第二件事情我称之为BizDevOps。我确实开始看到,随着low code和no code等解决方案的出现,业务分析师能够自己写出业务应用,并使用API来将各部分连接起来,在其上搭建新的用户接口。我们开始看到我们称之为BizDevOps的真实实验,但这种实验是基于一个假设:横跨CI、CD和发布的流水线实现了自动化。容器开始驱动我们走向那个里程碑,并转变我们做事情的方式。

第 10 段(可获 2 积分)

Shimel 讨论了DevOps工具的残酷和整合: “在2017年,我想专注于两件事。一是我所谓的DevOps工具库的打破。讽刺的是,DevOps等类似的做法想要打破Dev和Ops、Dev和QA、QA和安全之间的孤岛,但我们做的事情是我们搭建了新的DevOps工具仓库。因此我们有用于配置管理的DevOps解决方案。我们有CI/CD DevOps解决方案。我们有APN DevOps解决方案。ARA和“Alphabet soup” DevOps解决方案。他们全存在于仓库中。现在我们有更多的仓库,这实际上与DevOps理念是相反的。第二,作为一个业务分析师,我有点惊讶于直到现在,我们都没有看到DevOps空间更多的整合。随着有些大型的项目积聚一个端到端的DevOps故事,我们将看到很多的DevOps整合,这将驱动DevOps工具共同工作。

第 11 段(可获 2.1 积分)

Forsgren说,战略性的DevOps转移将会是2017年的关键:我认为我们将开始看到一些公司在DevOps的旅程和技术转型的过程中更具有策略性。在过去,这个过程做得很不好。你可以从任何地方开始,你会变得更好。但现在,如果你已经开始转型了,你需要认真地以及策略性地对待你要修复的事情。如果你还没有开始转型,你就落后太多了,你必须从开始就要具有策略性和非常认真。我认为这将是一个非常巨大的趋势:你将对你目前的状态进行认真和策略性的评估,设置优先级和策略来了解你的约束和限制在哪里,从而能够进行策略性地能力开发,继续前行。

第 12 段(可获 1.85 积分)

Fell 意识到仍有很多组织没有采用敏捷模型或DevOps,在未来的一年希望这会有所改变:我们生活在这个气泡中,快乐的气泡中,即认为所有人都在用DevOps以及我们都在用敏捷模型。但我与Rust Belt的工作人员以及很多其他人聊过天,他们都在说:“哦是的,我们进行nightly build,而且我们很期待去进行持续集成。”你的下巴可能会掉下来,你会回复:“哦是的,这是个好办法,你应该这么做!”

Riley讨论说,2017年将是DevOps突破性的一年:在2017年,我们将会停止定义DevOps,而且我们希望能少用一点这个词汇。我们将会真实地了解它到底是什么,以及如何做到它。将会有更少的讨论,更多的实践。我很愿意听到一些失败案例,因为只有我们面对这些,我们不仅仅能从中学习,而且才能够阻止组织做“我们失败了,我们放弃了,”这样的事情。

第 13 段(可获 2.44 积分)

我最害怕的问题之一,是我们只是创建了旧环境的一个现代版本,在其中人们被困在了环境的配置中。在三到五年内,会有人回顾然后说:“哦,现在这是一个老事情了,我们要从头开始。”但是真实的DevOps意味着你要准备好去适应环境,并随着环境成长。我同时认为组织架构将会大幅改变。我觉得我们将看到更多的共享的服务业务单元。我们将会看到DevOps头衔,更多的工程师具有DevOps头衔,更多的跨功能的职员。

第 14 段(可获 1.35 积分)

这将是突破性的,同时也会很有趣,因为我们能看到工程师团队们是如何适应以及人们的事业如何随之改变。最后,我希望能扩展工具市场。我认为在2017年的第一个季度或上半年,我们仍将看到大量的工具涌入。我是说,我每天都会遇到一个新的工具,尤其是在发布自动化领域里面。我相信将会持续发展的,是容器原生工具、容器原生安全、以及容器原生发布自动化。

Pais 评论说,在2017年,我们将会看到更多协作方式,更多DevOps的认证出现:我没法准确知道它会如何成型,但我觉得有引入新方法的空间来让人们进行协作,让很多不同领域的专家一起工作,从而带来更快的交付。对我来说,这是很多组织不清楚如何解决的问题。

第 15 段(可获 2.14 积分)

这些组织将引入的另一件事情是,传统的厂商——你的CRM、ERP——将开始被催促做得更好,解决方案更透明,对快速交付更具可塑性,因为这是这些传统组织面对的主要问题之一。他们不知道如何在这些系统中提升交付能力。我同时想提到另一件事情,这有点像Srcum曾遇到的情况。我认为我们将看到更多的DevOps教育和认证。举例来说,我知道有一个正在策划中的DevOps的IEEE标准。

第 16 段(可获 1.4 积分)

Wallgren表示DevOps将在FinServ组织中起到更大的作用:我认为2017年我们将开始听到一些失败案例,这是好事,因为我们能从中学习。但是我认为同时会有人说,“我试过DevOps了。没成功。完全是炒作。它只对巨头们适用。它只对新软件适用。它只,它只,它只,它只。”任何新的事物都会有这样的事情,我认为这是时间问题。

然后,我希望我们能看到在金融技术领域的有趣突破,因为我认为金融机构总是将技术作为自己竞争优势的一个关键。现在它们存在问题是,它们的文化整体来说很糟糕。因此那个领域可能会出现突破。更多的金融技术、新的在线银行、新公司会被迫互相协作。总有人不得不这么做。

第 17 段(可获 2.11 积分)

新年决心

Pais 希望2017年DevOps中有三件事情做的更好:第一,交付团队的价值流映射。即使只是一天或者一个下午,召集团队的人到一起,看看你的交付流水线到底如何工作。这会带来巨大的好处,很多组织认为他们知道发生了什么,但实际上他们不清楚。即使你在讨论之后不会做什么事情,但至少你能看到一些新事物。

另一件事情是,当你有更重要的事情时,不要优化小的事情,如开发时间或测试时间。比如,如果你的基础设施供应仍要花费几天甚至几周,首先解决这个问题。很多组织都关注局部优化,因为其中有很多可以做的事情。最后,让所有人都被同一种刺激笼罩。是什么形式不重要,无论是KPI、金钱激励或是绩效评估,让所有人(开发、运营、安全等)共享一个目标,即交付速度、平均恢复时间、更牢固的安全——确保这对所有人都是一样的。

第 18 段(可获 2.58 积分)

Wallgren 建议确保你的目标保持在正轨上:我认为我们所需要做的就是关注一个目标。这涉及到整个实验和战略战术,只关注一个想法,“为什么我们这样做?” 我们这样做是为了给我们的客户,员工带来更多的价值,让事情变得更好。我认为这是必须记住的,如果你在任何一天做的事情没有让你们离目标更进一步,那有什么意义?我认为我们需要集中更多的精力。

Riley建议组内有一个DevOps管理者(而不是老板): 我想说促进管理是非常重要的。你不需要一个人“拥有”DevOps,而应该有人有意识地在整个环境中管理DevOps。在某些组织里,我看到这一点做的很好,通过云服务或共享服务类型业务单元的模式。他们不是DevOps的老板。

第 19 段(可获 2.28 积分)

DevOps里面没有老板。而是有一个对DevOps的管理者,帮助确保所有人都有工具以及说明书,来在全组构建DevOps。我最后的决心是关注战术。我认为策略非常重要。我认为我们讨论要做什么的时间有点多,我希望看到更多人一步一步向前走。持续集成是一个相对安全的起点。

Shimel 说,在组内所有人中培养同理心:对你的同事有同理心,对你的同伴有同理心。不要认为因为你是开发者,你做的事情就要比运营者的事情要重要。当质保同事说“天啊,我害怕我会失去工作,因为我们把我测试的那一套自动化了”的时候,你不要说,“天啊,太糟糕了。别担心,你会找到另一份工作的。”你的同事是一个人,有孩子和配偶。同情他们的感受。和安全的同事一起同情。安全的同事只会说“不,”对吗?那就是他们所知道的事情。放过他们吧。因此在2017年,同情你的同事,从他们的角度考虑问题。试图让所有事情正常工作。

第 20 段(可获 2.94 积分)

Stroud 希望能看到协作的文化继续发展:没有执行的策略制定就是在浪费时间。我们一定要去执行。我们一定要准备好失败。我们一定要准备好过来分享我们的经验。这些都是良好文化的一部分,我们要将这种文化融入实践。让我们把赌注放在地上,然后为之努力。我也喜欢协作的想法。根据我们在DevOps企业峰会中学到的,DevOps环境中的文化是社区、分享、与人交流。我已经在这个行业中很长时间了,我还没有看到到很多协作的文化。我希望继续鼓励协作。随着DevOps成为主流,我们移除掉这个术语,它将转变成培训课程,我们都将成为DevOps大师,让我们不要丢掉我们已经拥有的协作文化。

第 21 段(可获 1.9 积分)

Forsgren 表示,评估是关键:一步一步变得更好——你的实验,实现策略的战术,你的支持商业目标的领导力。你不知道你做得怎么样,除非你有很好的评估方法来告诉你每一小步是否有效。所以那将是我的目标,让我们所有人想想如何聪明地评估,从而使我们能够做微小的允许失败的实验,因为大的失败是可怕的,但那些是我们可以用差劲的方式评估出来的。当你遇到了很大的失败时,你知道你遇到了很大的失败。

点击查看完整特辑

第 22 段(可获 1.71 积分)

文章评论

vincentsun
这篇有点口语化,我能力有限,请大神们后续继续吧~同时欢迎纠正!
vincentsun
不想烂尾所以还是硬撑着翻译完了。。这种对话啊发言稿啊什么的,都是口语,翻译真别扭。。欢迎大家纠正!但是文章还是很有意思的!
CY2
牛逼