一键测量让智能手表重回便捷，Amazfit以“小步”跃进下一阶段
06-21
“通过一篇文章清晰地介绍DevOps的整个思想体系，包括精益生产、敏捷、价值流、关键实践等。” 01 背景一直从事研发效率相关的产品规划。
DevOps是研发领域近年来最热门的概念之一。我听过一些讲座，读过很多书，经常听到这样的说法：DevOps 没有明确的定义，一千个研发头脑里就有一千个 DevOps； DevOps 是一种文化，每个团队的 DevOps 实践都不同； DevOps是消除Dev和Ops之间的障碍，让两者协同工作； DevOps是业界敏捷、精益等多种优秀实践的混合体； DevOps 是工具和自动化。
相信很多人听了之后都有和我一样的感受。他们感觉就像盲人摸象，隔管窥豹，徘徊在半懂半懂的边缘，无法系统地理解DevOps的全貌。
前年参加了EXIN DevOps基金会证书的培训和考试（注：EXIN全称是国际信息科学考试协会，成立于2007年，是面向全球IT从业者的中立认证考试机构），随后参加DevOps Professional和Master培训并获得DevOps Master证书。这三场培训让我对DevOps的概念和实践更加清晰。
因此，我总结了课程的要点并与大家分享。 02 什么是DevOps？本课程直言不讳地指出，只有非常自信或极其无能的大师才会认真讨论一种现象，而不对其进行定义或依赖。
因此，课程首先给出了DevOps的明确定义，即：“DevOps是①敏捷软件开发和精益生产思想的演变，应用于②IT端到端价值流，使得③业务基于现代信息技术，并通过④文化、组织和技术变革取得更大的成功”这句话信息量很大，基本上点出了DevOps的要点。 ①DevOps并不是一个全新的概念。
正是由于敏捷软件开发方法的演变以及以代码形式管理基础设施的可能性，逐渐催生了新的IT管理方法，并最终激发了DevOps的出现。其理论基础是敏捷软件开发+丰田精益生产。
②DevOps的本质是基于IT部门和业务部门考虑的不仅仅是软件开发，而是整个价值链。价值链从产品同学产生的新想法开始，经过开发、测试和部署，最后到达运维。
③一般来说，信息技术可以给组织带来更多的好处（通过创造新的机会或消除现有的限制）、降低风险和优化资源。 ④DevOps 不仅仅是流程自动化。
DevOps 领导者的经验表明，文化（人员）、组织（流程）和技术（自动化）都至关重要。 03 为什么要实施DevOps？ DevOps并不是作者或大师想象出来的管理框架或产品，而是从实际问题的解决中诞生的。
目前，不同组织正在尝试通过应用 DevOps 来解决三类主要问题。缩短市场响应时间传统IT部门遵循“针对成本进行优化”的模式，而DevOps组织则遵循“针对速度进行优化”的模式（这句话道出了互联网人的心声）。
具体包括： 减少批量 减少交接次数 持续识别并消除损失 将所有日常运维工作自动化 团队内部专业人员可更换 自给自足的团队（包括产品、开发、测试、运营、安全人员等，上线产品 否需要依赖外部团队）减少技术债务 当团队成员选择非最佳方式来解决问题以缩短开发时间时，就会出现技术债务。这是一个自然的过程。
问题在于，非最佳解决方案的积累会导致 IT 产出逐渐下降，从而导致产品质量下降。 DevOps强调对程序代码的不断重构，注重获得运维经验，并规划一些工作来消除以前产生的瓶颈，这与构建新功能一样重要； DevOps 强烈建议应用“尽可能经常正面面对问题”的做法，以防止出现每个人都知道问题存在但没有人致力于解决的情况。
消除系统漏洞 组织中最重要且与业务利益相关的系统通常是最容易受到攻击的。由于业务中断的高风险、对停机的零容忍以及与这些系统相关的持续变化和改进，减少这些系统的漏洞非常困难。
DevOps 以最激进的方式反对漏洞：完全排除。在 DevOps 中，代码和系统作为一个整体在某个时刻完全发挥作用。
如果后续的更改损害了性能，必须立即回滚，系统将继续正常工作； DevOps的实践故意给生产环境引入混乱和不稳定，例如Monkey Army等，目标IT系统必须以独立且快速的方式做出反应，检测故障并恢复正常运行，最好是在最终用户不知情的情况下，以及当然数据不会丢失。 04 DevOps的理论基础 DevOps并不是凭空产生的，而是有其扎实的理论基础的。
主要包括精益和敏捷两部分。精益生产丰田管理（丰田管理），即丰田生产方式（TPS），是由日本丰田汽车公司副总裁大野耐一创立的。
它是丰田公司独特的现代生产方法。 。
精益生产管理是美国麻省理工学院对丰田式生产管理的称呼。精益生产的理论框架包括“一个目标”、“两大支柱”和“一个基础”。
一个目标“一个目标”就是以低成本、高效率、高品质生产，最大限度地提高客户满意度。两大支柱 “两大支柱”是及时制和人员自治。
准时制（JIT-Just in time）生产。也就是说，市场是在正确的时间生产出正确数量、高质量产品的主导者。
JIT需要以驱动生产为基础，以均衡系统为调节。所谓拉动式生产，以看板管理为手段，采用“取料制”，即后续工序按照“市场”需要进行生产。
针对本工序产品不足的情况，从前工序中取出与前工序相同数量的产品，从而形成整个工序。控制系统永远不会生产超过一种产品。
平整化是指工件在拉入生产系统之前，必须根据加工时间、数量、品种进行人工匹配和排序，使拉入生产系统的工件流具有加工工时的稳定性，保证平衡。生产在品种、数量上实现混流增材运动的同时，能够快速响应和满足市场多品种、小批量的需求。
人员自主化是人员与机械设备的有机配合。如果生产线上出现质量、数量、品种问题，机器设备会自动停机，并显示指示。
任何人发现故障都有权立即停止生产线，主动排除故障、解决问题。该系统在丰田被称为 Andon 系统。
也是我设计的“品质红线”产品的创意来源。大基础 “大基础”是指进步。
Kaizen 是丰田式生产管理的基础。据称，如果两周内团队没有任何起色，丰田经理将被直接解雇。
这里的改进是指以下含义：①从局部到整体，总有改进和改进的空间。在工作、操作方法、质量、生产结构、管理方法等方面必须不断改进和提高。
② 消除所有废物。丰田生产管理理念认为，一切不能增加附加值的工作（包括生产过剩、库存、等待、运输、加工中的某些活动、冗余动作、不良品返工等）都是浪费。
这些浪费必须通过全体员工的努力不断消除。每种类型的废物都可以映射到IT领域。
例如，库存可以对应我们的一些未完成的工作。这些任务不能给最终客户带来价值，但资源却被消耗掉了。
详细信息如下图所示。 ③持续改进是当今世界流行的管理理念。
是指本着消除浪费、改进的思想，采用由易到难的原则，通过不懈的努力，对生产经营中存在的问题不断改进、巩固、改进、提高的方法，以达到长期的目标。 - 长期结果。
积累取得了显著成效。敏捷对于大家来说并不陌生，它的很多核心思想和实践已经融入到我们的日常工作中。
但敏捷并不是关于用户故事卡、站立会议或软件开发方法。它是一套价值观和原则。
让我们回顾一下敏捷宣言： 个体和交互 胜过 流程和工具 工作软件 胜过 全面的文档 客户协作 胜过 合同谈判 响应变化 胜过 遵循计划 这就是说，虽然右边的项目有其价值，但我们更关注价值左侧项目的。 DevOps很大程度上以敏捷为基础，将“敏捷开发”的思想延伸到整体敏捷IT交付、整个组织、整个流程、整个价值链。
05 核心原则是价值流。价值流起源于精益，这个概念本身已经使用了很多年。
我们从响应客户要求创造价值的角度来考虑组织中的工作，并按顺序安排完成客户要求所需的相关行动。这就是价值流。
致力于可视化价值流的工作称为“价值流图”。如上图所示，是软件开发流程的价值流图示例。
有几个关键指标： 交付周期 (LT)。这是每个链接从开始到交付所花费的时间。
处理时间 (PT)。也就是每个环节实际处理事情所花费的时间。
LT-PT为等待时间，应尽可能短。 PT/LT也是实际操作中经常用来衡量排队和等待损失时间的一个值。
完整和准确的百分比 (%C/A)。可以理解为返工。
越接近%，返工越少。经过价值流图之后，我们可以很好地识别浪费，以便我们进行下一步的改进，无论是工具还是文化。
改进后，还可以通过比较前后的价值流来评估改进的好处。可以看到，价值流图就像是一张施工图和一个指南针。
这就是为什么DevOps顾问在加入团队后首先要做价值流分析。06 关键实践课程涵盖了DevOps的许多关键实践。
这里我只描述给我印象深刻的做法。发布是日常活动（想发布就发布，大声发布），由业务决定（如果你要发布三次产品，何必把版本留到中午）一切都是自动化的（代码检查、测试） 、发布、监控都需要自动化） ） 事件应该立即解决（如果发生基本故障，立即回滚，因为之前的版本必须稳定可用） 缺陷应该立即修复（让缺陷闭环在最短路径内，通过自动化手段发现系统问题并立即修复）流程不断更新（通过价值流识别流程缺陷并立即消除，使有问题的流程尽可能重复）工作可视化（通过看板可视化构建拉动系统，提高任务透明度，提高对剩余工作和当前状态的了解）了解，提高优先级，减少交接次数）限制WIP（一次做一件事，便于提前期估计，减少损失）转换工作的生产力）减少批量大小（采取小步骤而不是阻止大动作）。
首先，它可以提高工作节奏，使其在各方面都更加稳定和可预测；其次，可以缩短交货时间，加快产出的交付速度；第三，小批量可以减少正在进行的任务总数；第四，小批量减少了缺陷数量，因此即使返工也更少浪费。）关注运维需求（在DevOps中，主要关注点从可靠性转向可恢复性，或者说反脆弱性，即系统应该有能力在不造成明显性能损失、不影响用户的情况下，检测并纠正故障，恢复到正常运维状态） 07 我的见解：让缺陷在最短路径内闭环。
在DevOps的关键实践中，要求“尽早发现并纠正缺陷”。因为随着交付管道阶段向后移动，识别和消除缺陷的成本就会增加。
一旦缺陷流入生产环境，就会造成重大损失，DevOps快速交付带来的好处将变得毫无意义。 Capers Jones 的《Applied Software Measurement》一书中，通过曲线图详细解释了不同开发阶段的缺陷修复成本。
以我负责的代码检查平台CodeCC为例。它一直主张“用最短路径封闭缺陷”，这与上述思想非常一致。
由于很多团队在上线之前并没有使用代码检查工具，很多缺陷都是在系统测试等后续阶段才发现的，导致返工、扯皮。 CodeCC自身的产品演进也经历了三个阶段，也在朝着“更短路径内的闭环”和“尽早发现并纠正缺陷”的思路迈进。
第一阶段推出CodeCC独立服务，重点关注日常计划构建的代码检查；第二阶段是与Blue Shield持续交付管道集成，可以支持代码提交、代码集成、版本转移测试、旧代码的发布和上线。检查。
第三阶段是研发质量保障进一步“左移”，推出IDE插件。从上图我们可以看出，85%的缺陷是在编码阶段产生的。
如果在代码提交到代码库之前能够在IDE中进行足够的代码检查、单元测试、自测试等质量保证活动，将会对产品质量产生影响。一个很大的进步。
如果一个工具检测到缺陷，但一些开发人员就是不处理它，我们该怎么办？那么优质的红线就可以派上用场。它可以为关键节点（即控制点）设定质量标准，并控制交付管道的行为，使每个阶段的进入/退出质量必须满足质量标准。
不符合质量标准的输出不得在线发布。有一本著名的畅销书叫做《反脆弱》，内容是尽可能多地直面问题。
在DevOps中，还有一个简单实用的反脆弱理念激励着我，那就是“尽可能多地正面面对问题”。我曾经有一个朋友，在打篮球时右腿受伤，接受了膝盖半月板手术。
经过一个月的休养，他逐渐能够放下拐杖，但右腿的肌肉明显萎缩，他心里也产生了阴影，对自己的右腿失去了信心。于是他从轻轻发力，到慢慢走，到正常走，到小跳，到大跳，到上篮跳投。
当他继续使用它时，他感觉到了它的状况并进行了纠正。姿势，最终朋友们重拾信心，重返球场。
事实上，这同样适用于 DevOps 中的反脆弱性。如果一个过程经常出错，那就再做一次，再做一次。
出现问题，立即优化问题，不断重复。为什么一开始大家都在讲持续集成（CI）？因为在瀑布式开发模式下，将代码合并在一起并发布到测试/生产环境是一个巨大的陷阱，并且需要很长时间。
既然融入环境已经成为一个陷阱，那么我每天都会融入它。提交代码后我会整合它。
如果失败，我会立即修复错误。如果太慢，我会优化流程和工具。
经过上千次的持续集成，回过头来看，一天发布几个版本已经不是问题了。 DevOps 反脆弱性对工具和自动化仍然有很高的要求，像 Blue Shield DevOps 这样的平台是必不可少的。
因为工具最擅长重复做一件事。而且，要持续监控是否有问题，立即回滚。
如果没有自动化系统，很难手动完成。 DevOps不仅仅是打破研发和运维之间的障碍。
网上很多文章和视频简单地将DevOps解释为将Dev和Ops合并，打破开发和运维之间的障碍。我认为这种观点是比较片面的。
DevOps是一套针对研发效率的思想和原则，其应用不仅仅局限于研发和运维。以安全为例。
在各类公司中，大家都非常重视软件安全。Exin课程中举了一个例子：有时开发同学写的软件未能通过安全团队审核，最终被发回重做。
那么如何解决这个问题呢？大家可以一起集思广益。我们公司的安全还是很好的。
因此，结合实际工作经验，我个人的想法如下：从组织（过程）的角度来看，要做到“尽早发现缺陷、尽早纠正缺陷”，安全宣传和审核应按以下要求进行：尽早。安全学生更早参与研发过程，如项目立项、技术选型、代码审查等，宣传安全指南，及早发现和暴露风险。
从文化（人）的角度来看，要实现“自给自足的团队”，研发学生需要更多地了解安全，能够理解安全准则，并选择更安全的技术。安全专业的学生更懂研发，能够针对安全漏洞提供很好的修复建议。
从技术（自动化）角度来看，安全审计可以工具化、自动化，并集成到整个研发流程中。例如，如果开发人员编写了高风险函数或使用了高风险组件，那么IDE插件在提交代码之前就已经对其进行了检查。
如果这个安全漏洞不修复，就无法跨越质量红线，无法将代码合并到主干，更谈不上转入测试或发布。因此，可以看出DevOps的思想是一个完整的体系，可以应用于研发的各个领域。
安全就是一个例子，对于产品经理和测试生的工作也有启发。 DevOps的核心是价值流，从用户的请求开始，到向用户交付价值结束。
价值流中存在浪费的任何环节都应该进行优化。所以我们大部分互联网人的工作其实都是在DevOps。
DevOps知识体系非常庞大。以上主要总结了一些要点。
希望对大家有所帮助。参考书及文章：《DevOps精要：业务视角》——Oleg Skrynnik（本书为EXIN指定教材，内容不多，比较通俗易懂，建议初学者阅读。
版权声明：本文内容由互联网用户自发贡献，本站不拥有所有权，不承担相关法律责任。如果发现本站有涉嫌抄袭的内容，欢迎发送邮件 举报，并提供相关证据，一经查实，本站将立刻删除涉嫌侵权内容。
标签：
相关文章
06-06
06-17
06-18
06-18
06-17
06-18
最新文章
【玩转GPU】ControlNet初学者生存指南
【实战】获取小程序中用户的城市信息（附源码）
包雪雪简单介绍Vue.js：开学
Go进阶：使用Gin框架简单实现服务端渲染
线程池介绍及实际案例分享
JMeter 注释 18 - JMeter 常用配置组件介绍
基于Sentry的大数据权限解决方案
【云+社区年度征文集】GPE监控介绍及使用