前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
社区首页 >专栏 >DevOps到底是什么?2个基础1个核心

DevOps到底是什么?2个基础1个核心

作者头像
九零后在互联网
修改于 2023-02-22 12:17:56
修改于 2023-02-22 12:17:56
1.1K0
举报

“ 通过一篇文章介绍清楚DevOps整个思想体系,包括精益生产、敏捷、价值流、关键实践等。”

01 背景

一直从事研发效能相关的产品策划工作,DevOps是研发领域最近几年最热的一个概念。我参加过一些讲座,也看过不少的书籍,经常听到以下说法:

  • DevOps是没有明确定义的,一千个研发心中就有一千个Devops;
  • DevOps是一种文化,每个团队的DevOps实践都不一样;
  • DevOps就是消除Dev与Ops之间的壁垒,让两者通力合作;
  • DevOps就是业内敏捷、精益等各种优秀实践的混合体;
  • DevOps就是工具和自动化。

相信很多人听完和我感觉一样,感觉自己就像是盲人摸象,管中窥豹,在似懂非懂的边缘徘徊,无法系统地了解到DevOps的全貌。

我在前年参加了EXIN DevOps Foundation证书的培训和考试(注:EXIN全称是国际信息科学考试学会,创立于1984年,是一家面向全球IT从业人员的中立认证考试机构),后续又参加了DevOps Professional和Master的培训,并获得了DevOps Master的证书。这三次培训让我对DevOps的理念和实践清晰了很多。故总结课程要点,分享给大家。

02 DevOps是什么?

本次课程开门见山地提出,只有那些非常自信或极不称职的大师,才会在不下定义或不依赖于一个定义的情况下严肃讨论一种现象。因此,课程首先给出了一个清晰的DevOps定义,那就是:

DevOps是对①敏捷软件开发和精益生产思想的一种演进,应用于②IT端到端的价值流中,使得③业务基于现代信息技术,并通过④文化、组织和技术变革来获得更大的成功。

这一句话信息量很大,基本上把DevOps的关键都点出来了。

①DevOps不是一个完全新的概念。它是由于敏捷软件开发方法的演进,加上以代码形式管理基础设施成为可能,逐渐产生出IT管理的新方法,最后激发出现了DevOps。它的理论基础是敏捷软件开发+丰田精益生产。

②DevOps的本质在于基于这样一个事实,即IT部门与业务部门所考虑的不仅是软件开发,而是整个价值链。价值链始于产品同学产生的新想法,经过开发、测试和部署,最后到运维。

③一般来说,信息技术能为组织带来更多收益(通过创造新机会或者消除现有约束)、降低风险并优化资源。

④DevOps并不是简单的流程自动化。DevOps领先者的经验表明,文化(人)、组织(流程)、技术(自动化)这几个因素都至关重要。

03 为什么要实施DevOps?

DevOps不是某个作者或大师想象出来的管理框架或产品,而是诞生于对实际问题的解决。目前不同组织应用DevOps所试图解决的问题,主要有3类。

缩短市场响应时间

传统IT部门遵循“为成本而优化(optimize for cost)”的模式,而DevOps组织遵循“为速度而优化(optimize for speed)”的模式(这句话说到互联网人的心坎里了)。具体包括:

  • 减少批量大小
  • 减少交接次数
  • 持续识别和消除损失
  • 自动化所有例行的运维工作
  • 团队内部专业人员可替换
  • 自给自足的团队(包含了产品、开发、测试、运维、安全人员等,上线产品不需要依赖外部团队)

减少技术债务

技术债务在团队成员选择一个非最优的方式解决问题以缩短开发时间时产生。这是一个自然的过程,问题是累计的非最优方案导致了IT产出的逐步退化,并且因此降低了产品质量。

  • DevOps讲求持续重构程序代码,重视在操作中取得经验,以及与构造新功能同等重要的、计划一些用来消除之前所造成的瓶颈的工作;
  • DevOps强烈推荐应用“尽可能频繁地直面问题”的实践,以防出现这样一种情况:每个人都知道问题就在那儿,却没有人着手去处理。

消除系统脆弱性

在组织中最重要的和业务收益相关的系统往往是最脆弱的。由于业务中断的高风险,对停机的零容忍,以及持续发生的变更和改进与这些系统关联紧密,所以降低这些系统的脆弱性非常困难。

DevOps以最激进的方式反对脆弱性:完全排除。

  • 在DevOps中,代码和系统作为一个整体,在某个时刻是全功能的,如果接下来的变更破坏了性能,就要马上回滚并且让系统持续正确地工作
  • DevOps的实践,有意的引入混乱和不稳定性到生产环境,例如猴子军团等,目标IT系统必须以独立和快速的方式做出反应,探测到故障并恢复它们的正常运作,理想情况下最终用户是无感知的,当然数据也不会丢失。

04 DevOps的理论基础

DevOps不是凭空产生的,而是有其坚实的理论基础。主要包括精益和敏捷两大部分。

精益生产

丰田式生产管理(Toyota Management),或称丰田生产体系(Toyota Production System,TPS)由日本丰田汽车公司的副社长大野耐一创建,是丰田公司的一种独具特色的现代化生产方式。精益生产( Lean Production)管理是美国麻省理工学院给丰田式生产管理的名称。

精益生产的理论框架包含“一个目标”、“两大支柱”和“一大基础”。

一个目标

“一个目标”是低成本、高效率、高质量地进行生产,最大限度地使顾客满意。

两大支柱

“两大支柱”是准时化与人员自主化。

准时化(JIT-Just in time)生产。即以市场为龙头在合适的时间、生产合适的数量和高质量的产品,JIT需要以拉动生产为基础,以平准化(Leveling System)为条件。所谓拉动生产是以看板管理为手段,采用“取料制”即后道工序根据“市场”需要进行生产,对本工序在制品短缺的量从前道工序取相同的在制品量,从而形成全过程的拉动控制系统,绝不多生产一件产品。平准化是指工件的被拉动到生产系统之前要进行人为的按照加工时间、数量、品种进行合理的搭配和排序,使拉动到生产系统中的工件流具有加工工时上的平稳性,保证均衡生产,同时在品种和数量上实现混流加式运动,起到对市场多品种、小批量需要的快速反应和满足功能。

人员自主化是人员与机械设备的有机配合行为。生产线上产生质量、数量、品种上的问题机械设备自动停机,并有指示显示,而任何人发现故障问题都有权立即停止生产线,主动排除故障,解决问题。该系统在丰田被称为安灯系统。也是我设计的“质量红线”产品的思想来源。

一大基础

“一大基础”是指改善(Improvement)。改善是丰田式生产管理的基础。据说丰田的主管如果两周之内团队没有任何改善将会直接被辞退。这里的改善是指这样的含义:

①从局部到整体永远存在着改进与提高的余地。在工作、操作方法、质量、生产结构和管理方式上要不断地改进与提高。

②消除一切浪费。丰田式生产管理哲理认为不能提高附加价值的一切工作(包括生产过剩、库存、等待、搬运、加工中的某些活动,多余的动作,不良品的返工等)都是浪费。这些浪费必须经过全员努力不断消除。每一种浪费对应到IT领域都是可以找到对应关系的,例如库存,可以对应我们平时部分未完成的工作,这些工作不能给最终客户带来价值,但是资源已经被消耗了。具体如下图所示。

③连续改善 (Continuous Improvement)是当今国际上流行的管理思想。它是指以消除浪费和改进提高的思想为依托,对生产与管理中的问题,采用由易到难的原则,不断地改善、巩固,改善、提高的方法,经过不懈的努力,以求长期的积累,获得显著效果。

敏捷

敏捷是大家比较熟悉的,它的很多核心思想和实践已经融入到了我们日常的工作中。不过敏捷并不是用户故事卡片、站立会议或开发软件的方法,而是一套价值观和原则。

我们不妨一起来回顾一下敏捷宣言:

个体和交互 优先于 流程和工具 可工作的软件 优先于 面面俱到的文档 客户协作 优先于 合同谈判 响应变化 优先于 遵循计划 也就是说,尽管右项有其价值,我们更重视左项的价值。

DevOps很大程度上基于敏捷,并把“敏捷开发”的想法延展到了整体的敏捷IT交付、整个组织、整个流程以及整个价值链。

05 核心原则是价值流

价值流源自精益,这个概念本身已经使用了很多年。我们从创造价值以响应客户请求的角度来考虑组织中的工作,将完成客户请求所需要实施的相关行动,按照顺序排列起来,这就是价值流。而致力于可视化价值流的工作被称为“价值流映射”。

如上图所示,就是一个软件开发过程的价值流图样例。

其中有几个关键指标:

  • 前置时间 Lead Time (LT)。即每个环节从开始到交付所花费的时间。
  • 处理时间 Process Time (PT)。即每个环节真正处理事情的时间。LT-PT就是等待时间,应该越短越好。PT/LT也是一个实际操作中经常用到的值,用于衡量队列和等待损耗时间的情况。
  • 完整性与准确性占比 Percent Complete and Accurate (%C/A )。可以理解为返工情况,越接近于100%说明返工越少。

在进行价值流映射之后,我们可以很好识别出浪费,以便于进行下一步的改进,无论是工具还是文化上的。在改进之后,也可以通过前后价值流的对比,来评估出改进的收益。可以看到价值流图就像是施工图,也像是指南针,这也是DevOps咨询师进入一个团队后首先做价值流分析的原因。

06 关键实践

课程中讲到了不少DevOps关键实践,此处仅阐述我印象比较深刻的实践。

  • 发布是日常活动(想发就发,发得响亮
  • 发布是业务决定的(产品想要三更发,何必留版到午时
  • 一切都是自动化的(代码检查、测试、发布、监控都要自动化
  • 事件要立即解决(出现基础故障先立即回滚,因为上一个版本肯定是稳定可用的
  • 缺陷是立即被修复的(让缺陷在最短路径内闭环,通过自动化的手段发现系统问题并立即修复
  • 流程是持续更新的(通过价值流识别出流程短板并立刻消除,让有问题的流程尽可能重复执行
  • 工作可视化(通过看板可视化构建拉动系统,改善任务透明度,改善对剩余工作以及当前状态的了解,改善优先级排序,降低交接次数
  • 限制在制品(一次只做一件事,促进前置时间估算,减少切换工作丢失的生产率
  • 减少批次大小(小步快跑,而不是憋大招。一是可以改善工作的节奏,使其变得更稳定并且在各方面都更可预测;二是缩短前置时间,加快产出的交付;三是小的批次减少进行中的任务总数;四是小的批次降低了缺陷的数量,这样即使返工浪费也少。
  • 留意运维需求(DevOps中,最主要的关注点从可靠性转移到可恢复性,或反脆弱性,即系统应该能检测到并更正故障,恢复到正常的运维状态,过程中没有明显的性能损失,同时也不会影响到用户

07 我的感悟

让缺陷在最短路径内闭环

在DevOps的关键实践中,要求“尽早检测并修正缺陷”。因为随着交付流水线阶段向后移动,识别和消除缺陷的成本也随之增加。缺陷一旦流入生产环境,将会造成重大的损失,那么DevOps快速交付的好处也失去意义了。在Capers Jones的《Applied Software Measurement》一书中,就通过曲线图对在不同研发阶段的缺陷修复成本进行了较为细致的说明。

以我负责过的代码检查平台CodeCC为例,它一直以来主张的“让缺陷在最短路径内闭环”,与上述思想是非常一致的。因为在它推出之前,很多团队都没有使用代码检查工具,不少缺陷流入系统测试等后续阶段才被发现,导致返工和扯皮。

CodeCC本身的产品进化也经历了三个阶段,也是朝着“更短路径内闭环”、“尽早检测并修正缺陷”的思路去走的。

  • 第一阶段是推出CodeCC独立服务,主打每日定时构建的代码检查;
  • 第二阶段是与蓝盾持续交付流水线融合,能够支持代码提交、代码合入、版本转测、发布上线等环节之前的代码检查。
  • 第三阶段是研发质量保证的进一步“左移”,推出了IDE插件。从上述图中可以看到编码阶段产生了85%的缺陷,如果能在代码提交到代码库之前,在IDE中进行充分的代码检查、单元测试、自测等质量保证活动,将对产品质量有很大的提升。

如果工具检查出了缺陷,但是部分开发同学就是不处理,那该怎么办呢?那么质量红线就可以派上大用场了。它可以为关键节点(即控制点)设置质量标准,控制交付流水线的行为,使得每一阶段的入口/出口质量都必须符合质量标准的一种服务。不满足质量标准的产出不得发布到线上。

尽可能频繁地直面问题

有一本著名畅销书叫做《反脆弱》。在DevOps中,也有一个质朴实用的反脆弱思想,让我很受启发,那就是“尽可能频繁地直面问题”。

曾经有一位朋友,打篮球右腿受伤了,做了膝关节半月板手术。在休养了一个月之后,逐渐可以抛开拐杖了,但是右腿肌肉已经肉眼可见地缩小了,而且他心里也有阴影,对右腿有些丧失信心。于是他从轻轻用力,到慢慢走路,再到正常走路,再到小跳,再到大跳,再到上篮和跳投,随着他不断去使用它,感受它的状态,修正它的姿势,最终朋友重拾自信,重回球场。

其实DevOps中的反脆弱也是同理,一个流程经常出问题,那就把它再做一遍,再做一遍,出了问题就立即优化其中的问题,不断重复做。为什么一开始大家都讲持续集成(CI)呢,因为瀑布流开发模式下把代码合并到一起,发布到测试/生产环境,巨坑无比,要花费很长的时间。既然集成到环境已经成为了一个坑,那么我就每天都集成,提交了代码就集成,失败了我就立刻修复报错,太慢了我就优化流程和工具。持续集成千百遍,蓦然回首,一天发几个版本也不成问题了。

DevOps反脆弱对于工具化和自动化的要求还是很高的,类似于蓝盾DevOps这样的平台必不可少。因为重复做一件事,工具是最擅长的。而且要持续监控是不是有问题,并且立即回滚,没有一套自动化的体系,人工是很难去做的了。

DevOps不只是打破研发和运维的壁垒

很多网上的文章和视频把DevOps简单地解释成合并Dev和Ops,打破开发与运维的壁垒。我觉得这个观点是比较片面的。DevOps是一整套面向研发效能的思想和原则,它的应用绝不止研发和运维这2个角色。

以安全为例,在各类公司大家都是非常重视软件安全的。在Exin课程中举了个例子:有时会出现开发同学写的软件未通过安全团队审计,最终被打回重做。那么怎么解决这个问题呢?大家可以一起脑暴下。

我们公司安全做得还是很不错的。因此结合实际工作经验,我个人思考如下: 从组织(流程)的角度,要实现“尽早检测并修正缺陷”的实践,应该尽早进行安全宣导和审计。安全同学更早地参与到研发流程中去,例如立项、技术选项、代码检视等,进行安全准则宣导,及早地发现并暴露风险。 从文化(人)的角度,要实现“自给自足的团队”,需要研发同学更懂安全,能够了解安全准则,选用更加安全的技术。安全同学更懂研发,能够为安全漏洞提供好的修复建议。 从技术(自动化)的角度,可以把安全审计工具化、自动化,融入到整个研发流程中去。比如开发同学写了一个高危函数或使用了某个高危组件,还没提交代码,IDE插件就已经检查出来了。而这个安全漏洞未被修复的话,他是无法通过质量红线,合入代码到主干的,更无法转测或发布了。

因此可以看到,DevOps的思想是一整套体系,可以应用到研发的各个领域中。安全是其中一个例子,对于产品经理、测试同学的工作,也是有指导意义的。DevOps的核心是价值流,讲究的是从用户提出需求开始,到最后交付给用户价值。在价值流中任何环节存在浪费,都应该被优化。因此我们大部分互联网人的工作,其实都在DevOps里了。


DevOps知识体系非常庞大,上面主要总结了一些要点,希望能对大家有所帮助。

参考书籍和文章: 《DevOps精要:业务视角》——Oleg Skrynnik著(这本书是EXIN的指定教材,内容不是很多,比较通俗易懂,推荐入门者阅读。) 《凤凰项目:一个IT运维的传奇故事》——Gene Kim等著 《持续交付:发布可靠软件的系统方法》——Jez Humble等著,乔梁译 《腾讯荣获全球首个 DevOps 标准认证 4级》 https://cloud.tencent.com/developer/article/1371895 蓝盾DevOps https://github.com/tencent/bk-ci

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2023-02-05,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 九零后在互联网 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
精益思想如何加速企业的全局价值流动?
精益思想(Lean Thinking)在数字化转型中一直扮演着重要的角色。精益源自20世纪50年代日本丰田发明的生产方法(TPS),即精益生产。基于这套方法论丰田实现了成本效益结合,大大提升了日本汽车的质量与成本优势,使得世界汽车工业重心开始由美国向日本倾斜。
嘉为蓝鲸
2022/08/01
6700
精益思想如何加速企业的全局价值流动?
为什么精益与DevOps相得益彰?
所有利益相关者的需求模式在快速发展,客户、合作伙伴和监管机构都有迫切地需求。例如,投资者要求业务和规模增长,导致企业收购和重组的发生;竞争对手和合作者要求采取行动以适应快速变化等。
嘉为蓝鲸
2022/04/02
4870
为什么精益与DevOps相得益彰?
DevOps推动科技管理敏捷转型
银保监会2022年2号文中提到,要大力推动金融企业科技管理敏捷转型,建立双态数字管理体系,建设企业级一站式研发协同平台,并结合精益生产管理理念,实现企业全方位转型升级。
嘉为蓝鲸
2022/08/29
1.2K0
DevOps推动科技管理敏捷转型
精益产品开发 —— 丰田生产系统 & 精益生产
准时制又被成为 JIT(Just In Time),是指仅在需要的时间生产需要数量的需要的产品。准时化的目的是灵活应对变化,消除生产过剩的浪费,以缩短前置时间。
腾讯云 CODING
2022/03/16
1.4K0
精益产品开发 —— 丰田生产系统 & 精益生产
TW洞见 |建设DevOps能力到底有多重要?典型问题+对症方法
当软件行业进入互联网时代,市场对软件产品和服务的交付提出了更高的要求:不仅要快速实现需求,而且要快速发布上线,并且必须保证业务可靠、高效运行。为了满足这些要求,IT组织需要强有力的流程、技术和人员作为保障。 ThoughtWorks很早就认识到发布与运营对于成功交付的重要性。我们的创始人Roy Singham在《走完业务软件的“最后一公里”》一文中指出: 所谓[软件开发的]“最后一公里”,是指软件满足了功能需求之后,尚未投入实际运行并创造业务价值的阶段。软件开发者──尤其是面对交付压力的软件开发者──
ThoughtWorks
2018/04/16
8490
TW洞见 |建设DevOps能力到底有多重要?典型问题+对症方法
《DevOps实践指南》第一部分
《DevOps实践指南》第一部分 第一部分 DevOps 介绍 DevOps 的三步工作法:流动、反馈以及持续学习与实验 简史 DevOps 基于精益、约束理论、丰田生产系统、柔性工程、学习型组织、安全文化、人员优化因素等知识体系,并参考了高信任管理文化、服务型领导、组织变动管理等方法论。把所有这些最可信的原则综合地应用到 IT 价值流中,就产生出 DevOps 这样的成果 精益运动 精益的两个主要原则包括:坚信前置时间(把原材料转换为成品所需的时间)是提升质量、客户满意度和员工幸福感的最佳度量指标之一;小
yeedomliu
2019/12/10
9660
DevOps 温故知新
【引】伴随着微服务架构以及云技术的广泛使用,DevOps相应地引起了人们的关注,尤其在互联网企业展开了大量的探索和实践。去年赋闲在家的时候, 有幸精读了三本书,分别是《持续架构实践——敏捷和DevOps时代下的软件架构》,《精益DevOps——快速安全的IT交付宝典》和《基础设施即代码——模型驱动的DevOps》, 于是,温故知新,老码农对DevOps 又有了不同的体会。
半吊子全栈工匠
2024/05/14
1360
DevOps 温故知新
什么是 DevOps 三步工作法?
本文将介绍《DevOps Handbook》全书的核心:三步工作法。《DevOps Handbook》全书就是从三步工作法的思路出发,进行知识体系的组织和实践的编排。 简单说一下拆书联盟的活动,目前有几位小伙伴一起做拆书活动,首先由我做来第一期,然后是石雪峰,他是乐视配置管理和持续交付部门总监,他会给大家带来第二期拆书活动,后面还有王磊、大梁、景韵、赵班长等同学,都会参与到读书分享过程中。如果大家有兴趣可以联系我们,继续扩大阵容。 三步工作法是什么?如何通过三步工作法来指导DevOps的整体实施?以及它的核
DevOps时代
2018/02/02
4.5K0
什么是 DevOps 三步工作法?
精益产品开发 —— 精益思想 & 精益价值观
精益思想源于丰田的精益生产方式,1996 年 James Womack 和 Daniel Jones 的《精益思想(Lean Thinking)》一书问世,精益生产方式由经验变成为理论,新的生产方式正式诞生。从上述精益思想发展的历程说明,精益思想是人、过程和技术的集成。无论是丰田生产方式、还是后来的精益生产,都是从技术的改变和技术的可行开始的。过程的思想则是丰田生产方式产生的基础。而人则是决定性的因素。精益思想比大批量生产关键性的改革是组织结构和分工原则的变化,这是解放被大量生产的分工和等级制度所束缚着的员工积极性的重要进步。
腾讯云 CODING
2022/03/16
1.3K0
精益产品开发 —— 精益思想 & 精益价值观
【扯淡篇】DevOps,值得运维拥抱!
原计划是写名字服务相关的一篇文章,但因为周末出去培训,实在没法完成。公司组织大家出去讨论关于协同效率问题,之前在腾讯也讨论过部门墙的问题。随着公司的日益增大,这类问题会一直存在,且一直在解决而不能彻底
用户1593318
2019/11/18
7160
什么?DevOps 已经是哲学啦?
摘要——本文从一个新的角度审视了 DevOps 的实践,一个理解其哲学和科学本质的角度。DevOps 从根本上改变了基于指导哲学和科学原则的研究和开发领域。先进的计算技术和领域采用 DevOps 来实现先进的解决方案工程,以实现高效、质量有保证的输出。作者简要描述了DevOps 的哲学和科学如何协同定义其本质。
DevOps时代
2021/10/27
7230
精益产品开发 —— 精益软件开发 & 精益产品开发
2003 年《精益软件开发》书籍的问世,标志着精益理念和实践正式引入软件开发领域,与敏捷软件开发平齐(2001 敏捷宣言),成为新的软件开发方法。敏捷软件开发继承和吸收了众多的精益思想和理念,精益软件开发对敏捷软件开发产生了重大的影响。
腾讯云 CODING
2022/02/13
1.3K0
精益产品开发 —— 精益软件开发 & 精益产品开发
一分钟告诉你究竟DevOps是什么鬼? 转
为了能够更好的理解什么是DevOps,我们很有必要对当时还只有程序员(此前还没有派生出开发者,前台工程师,后台工程师之类)这个称号存在的历史进行一下回顾。
wuweixiang
2018/12/24
4430
红灯区:DevOps 建设的思考和实践
众所周知,在丰田精益生产中,核心观念包含对人的尊重、消除浪费、持续改善,只有这样,企业才能保持良性运转,竞争力才会提升。而具体的浪费场景,被总结为「制造过剩、等待、搬运、库存、加工、额外动作、次品」七种,后来又增加了「管理」的浪费。
测试开发社区
2020/02/12
4610
微信支付团队精益研发实践总结
作者:宿海成 微信支付爆发式增长下潜藏怎样的效能「危机」?研效提升过程中,微信支付的策略及措施?人与工具如何有机结合,实现“稳又快”的精益研发?揭秘微信支付的精益研发破局之道。 一、背景介绍 1.1 微信支付爆发式增长下的效能问题及解决思路 微信支付有着持续保持金融级高可用和业务高速发展双重要求。随着业务复杂性的提高和技术债务的不断增加,质量和速度在发展上的矛盾被不断激化,解决“效能问题”,提升系统应对不确定性的能力成了微信支付研发团队的燃眉之急。 为了从根本上改善研发效能,微信支付研发团队参考了来自
腾讯技术工程官方号
2021/12/10
9720
DevOps最全术语汇总
使用A/B测试的技术将新功能或某项功能的不同变体推向不同组别的用户,这些功能可通过比较指标和用户行为进行评估。
TestOps
2022/04/07
5440
运维助力敏捷交付-我们的运维看板
导言: 在许多工作场景中运维经常遇到的很多问题实际上和研发、质量、测试是有关联的,运维作为产品交付的最后环节遇到的很多问题其实和研发遇到的也非常类似。于是我向廖君仪老师询问能不能把敏捷看板带到运维团队内部,使用敏捷的方法来解决这些问题。 接下来我们会从上到下跟大家分享以下五部分:运维面临的挑战,敏捷开发方法,还有我们的运维看板,以及敏捷软件生命周期,最后是我们的结论:运维也可以敏捷。我们希望通过这次分享向大家交付两个内容,第一点,理解敏捷是什么,第二点大家回去后能尝试进行看板实践。 运维的挑战 运维到底能在
DevOps时代
2018/02/02
3K0
运维助力敏捷交付-我们的运维看板
DevOps 转型手记:关注价值流
这是个我曾经在做各种调研时,为了了解对方的端到端工作流程而习惯问的问题,当然收到的回答也是如上面一样相当的一致。
DevOps时代
2018/12/18
1.3K0
DevOps 转型手记:关注价值流
有料|微信支付精益研发背后那些事儿
微信支付有着持续保持金融级高可用和业务高速发展双重要求。随着业务复杂性的提高和技术债务的不断增加,质量和速度在发展上的矛盾被不断激化,解决“效能问题”,提升系统应对不确定性的能力成了微信支付研发团队的燃眉之急。
TAPD敏捷研发
2021/12/09
9930
有料|微信支付精益研发背后那些事儿
落地DevOps的路线图
老实说,这是一个很大的命题,而且也并没有标准答案。一个软件工程实践理念能否在企业内落地并达到一定效果,取决于很多因素,比如是否有上层领导支持,是否有足够的资源投入,是否采取了正确且适合自己的方法,团队是否认可这项实践带来的价值等很多因素。
老_张
2023/03/01
3890
落地DevOps的路线图
相关推荐
精益思想如何加速企业的全局价值流动?
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档