请选择 进入手机版 | 继续访问电脑版

设为首页 收藏本站
思科社区 关注
思科社区

  思科 CCO 登录 推荐
 找回密码
 立即注册

搜索
热搜: 邮件服务器
查看: 385|回复: 0

【小目标,一个“译”】+ 有关高效项目交付的DevOps最佳实践(1)

[复制链接]
发表于 2018-12-10 17:07:54 | 显示全部楼层 |阅读模式
引言:缺乏最佳实践的DevOps,会给你的企业带来缓慢的发布周期,甚至是灾难性的错误。本文向你介绍一些能够充分使用DevOps的小技巧。

本文会分享一些有趣的DevOps原则,并展示通过应用它们给高效的项目交付与转化所带来的好处。这里所提及的概念都源于John Willis。他有着丰富的IT管理经验,同时也是DevOps运动的最初倡导者。当一个组织考虑去实践DevOps的时候,他们需要掌握一些相关术语和实用方法。因此,本文会谈及如下的方面:

·        骑士资本的故事
·        
·        DevOps的术语
·        
·        价值流(value stream)/交付(lead) 时间/周期时间(CycleTime)
·        
·        高绩效组织与低绩效组织
·        
·        对精益模型的学习
·        
·        持续交付模型
·        
·        DevOps的实践
·        
骑士资本的故事

在开始讨论DevOps的最佳实践之前,让我们先来看看IT流程和技术的失败是如何导致企业的各种业务问题与损失的。为了深入理解这一点,我们会引入一个发生在2012年的骑士资本的失败案例。

骑士资本集团曾是一家美国本土的全球金融服务公司。其业务涉及到开拓市场、电子交易、机构销售和交易。2012年8月1日,骑士资本在其系统的生产环境中部署了带有倒退功能、且未经测试的软件。该事故的发生是由于技术人员忘记将新的零售流动性计划(Retail Liquidity Program,RLP)代码拷贝到八台SMARS服务器中的一台之上,而这台服务器正是骑士用于处理股权订单的自动路由系统之一。  

当代码被发布到生产环境中以后,此举导致了154只股票的4百万宗交易,在大约45分钟内有超过3.97亿的换手,其直接损失为4.4亿美元。骑士资本的这一异常交易行为被定性地描述为“技术故障。”这充分地表明了:将带有bug的软件部署到生产环境中所能够造成的严重程度。

反观此事,如果他们当时遵循了DevOps的基本原则,该事故时可以完全避免,而且无用功也会降低许多的。这里的无用功意味着他们完全可以使用自动化的部署,来取代引发人为错误的手动部署。我们接下来看看各种DevOps的实践。

DevOps的术语

Chef的创始人Adam Jacob将DevOps定义为一种文化和专业的运动。

通常,影响一个项目的三个因素分别是速度(时间)、可靠性和成本。开发需要有按时交付的速度,而运营需要有可靠性。DevOps可以保证以低成本的方式实现速度和可靠性。

DevOps会涉及到各种模式,包括:持续改进、组织文化、学习曲线、持续交付、持续学习、持续协作、和自动化。

与DevOps相关的术语有:

·        价值流 - 它是指一个组织针对其客户需求,所执行的各项交付活动的顺序。也就是指:你如何把一个想法最终变现的过程。
·        
·        交付时间 - 价值流从开始到结束,全程转化的耗时。一般情况下,交付时间是指呈现到客户眼前所花费的时间。
·        
·        周期时间 - 始于按照需求所开展的工作,终于准备好交付项目的时候。
·        
·        交付时间的掌控能力意味着我们对DevOps的运用水平。
·        
·        部署交付时间则反映了我们在自动化方面的水平。
·        
可见,组织应遵循DevOps的模式和实践方式,以减少交付的时间。他们完全可以从中选取诸如:放大反馈、或加强持续学习文化等一个或多个适合自身的DevOps方法。有关这些方法的详细信息请往下阅读。

高绩效组织与低绩效的区别

在2016年的DevOps状况报告中,有着关于如何区分出高绩效与低绩效的组织研究。该研究指出:高绩效的组织更接近于DevOps的文化,而低绩效的组织则不太适合。以下便是从那些高绩效组织中所观察到的DevOps文化和实践:

·        更高的员工参与程度
·        
·        内部质量方面的建设
·        
·        遵从精益产品的管理原则
·        
o  注重客户反馈意见的收集、传播与实施
o  
o  分解整体工作成各个小的部分,并能使交付流程的工作流可视化
o  
·        在计划外的工作和返工上花费的时间最少
·        
总结起来,他们具有如下的实践和文化:

·        更高的部署频率
·        
·        更短的变更交付时间
·        
·        更短的平均恢复时间(Mean Time To Recover,MTTR)
·        
·        更少的变更故障率
·        
下面是有关此类高绩效组织的详情:

·        范例:亚马逊、谷歌、Facebook、Etsy和Netflix
·        
·        在2015年,谷歌已经表示:他们每天会提交5000行代码,75万次用例测试;亚马逊,每天会进行13.6万行代码的部署,平均每年1500万行;Netflix,每天部署500行代码;Etsy则每天数百行以上。具体内容,请参阅2015年的DevOps状况报告。
·        
·        相对于低绩效的组织来说,他们的部署频率多了200倍以上、交付时间快了2555倍、恢复时间快24倍,而故障率则只有三层以下。
·        
·        他们往往有更多的合作、培训、风险信息分享、并且更鼓励沟通。同时他们面对各种故障也有着健康的心态。
·        
而对于低绩效的组织来说:

·        此类组织只能努力实现一年两次以上的部署,并只有一种瀑布式的部署模型。
·        
他们的执行力缓慢、且不太可靠。在合作方面他们的水平较低,沟通并不顺畅,对失败常会产生消极和畏难情绪,且不愿意尝试新鲜的事物。


系列文章
【小目标,一个“译”】+ 有关高效项目交付的DevOps最佳实践(2)

  • 1
  • 2
  • 3
  • 4
  • 5
  • 1
  • 2
  • 3
  • 4
  • 5
平均得分0 (0 评价)
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

Archiver | 思科社区  

GMT+8, 2019-1-18 02:23 , Processed in 0.074030 second(s), 28 queries .

京ICP备09041801号-187

版权所有 :copyright:1992-2019 思科系统  重要声明 | 保密声明 | 隐私权政策 | 商标 |

快速回复 返回顶部 返回列表