华为云用户手册

护照识别约束 支持中国大陆护照的全字段识别。 支持含有完整机读码的中国-港澳台地区及外国护照识别。 只支持识别PNG、JPG、JPEG、BMP、TIFF格式的图片。 图像各边的像素大小在15到4096px8192px之间。 图像中护照首页区域有效占比超过25%，保证护照首页内容及其边缘包含在图像内。 支持图像中护照任意角度的水平旋转。 支持少量扭曲，扭曲后图像中的护照长宽比与实际护照相差不超过10%。 能处理反光、暗光等干扰的图片但影响识别精度。

机动车 行驶证识别 约束 只支持中国大陆行驶证的识别。 只支持识别PNG、JPG、JPEG、BMP、TIFF格式的图片。 图像各边的像素大小在100到8000px之间。 图像中行驶证区域有效占比超过5%，保证整张行驶证内容及其边缘包含在图像内。 支持图像中行驶证任意角度的水平旋转。 支持少量扭曲，扭曲后图像中的行驶证长宽比与实际行驶证相差不超过10%。 能处理反光、暗光、防伪标识等干扰的图片但影响识别精度。 目前只支持识别2008年版的行驶证。

服务韧性 华为云EdgeSec按规则部署在全球各地，所有数据中心都处于正常运营状态，无一闲置。数据中心互为灾备中心，如一地出现故障，系统在满足合规政策前提下自动将客户应用和数据转离受影响区域，保证业务的连续性。为了减小由硬件故障、自然灾害或其他灾难带来的服务中断，华为云EdgeSec提供灾难恢复计划。 当发生故障时，EdgeSec的五级可靠性架构支持不同层级的可靠性，因此具有更高的可用性、容错性和可扩展性。 华为云EdgeSec已面向全球用户服务，并在多个分区部署，同时EdgeSec的所有管理面、引擎等组件均采用主备或集群方式部署。 父主题： 安全

22 在什么情况下Scrum并不适用？ Scrum模式并不适用于所有的团队，特别当团队规模很大（几十上百上千）的时候，我们无法在整个团队范围内实施Scrum，而必须将团队分割成5-10人的小团队，并在团队间进行Scrum of Scrum 的实施。 Scrum也不适合跨部门、跨职能的协作，如果团队成员分散于不同的地理位置或者不同的部门，我们需要首先在组织结构上进行调整，至少需要合并开发和测试部门，组成按照特性或产品领导的团队，同时从其他不同部门抽调人员组成团队。

09 什么是Scrum扑克？ Scrum 扑克（计划扑克）是一种进行量化估算的方法和工具。 在团队进行规划的过程中需要对工作量（故事点）、商业价值等进行量化评估，为了达到“评估结果是团队的集体决策结果”的目的，Scrum中发明了这种方法和附带的工具（一种扑克），在扑克上使用斐波纳奇数列标识每张扑克，在进行规划的时候每个成员按照自己理解出牌，并由数值最大和最小的两名成员进行解释，大家进行讨论后得出最终的数值估计。 斐波纳奇数列的特性决定了每个数字之间的差异会越来越大，这对于我们进行相对值评估非常有效。

19 什么是Daily Scrum？ Daily Scrum 是一个简短的团队会议，由团队的所有成员在每天固定的时间和地点进行，会议上每个成员需要回答3个问题： 你昨天做了什么？ 今天计划做什么？ 是否遇到了障碍，需要其他人的帮助？ Daily Scrum 不是一个汇报会议，因为所有的参与者都必须抱着平等的心态参加，你所回答的3个问题是说给所有人听的，所有人的3个问题也都是说给你听的。Daily Scrum一般由Scrum Master进行协调和组织，但Scrum Master并不对成员所描述的业务特性/任务内容进行评价，而只关注会议本身是否高效。 Daily Scrum必须站立进行，所以很多人称之为Daliy stand-up，站立的目的是为了让会议高效并让每个人都集中精力，放下手头的工作。

18 什么是Sashimi和Impediments？ Sashimi的原意是“生鱼片”，在Scrum中是团队用来表达“完成”的一种说法。不同团队对于“完成”的定义可以是不一样的，但在一个团队内必须统一，在Scrum中一个团队需要定义不同级别的“完成规范”来统一这个概念。“完成规范”可以是任务级别的，团队级别的或者产品特定级别的。 Impediments的意思是“障碍”，是团队在向着“完成规范”所定义的状态努力过程中遇到的阻碍。一般来说，Scrum Master需要作为消除障碍的主要负责人。

14 Scrum中的冲刺和迭代有什么区别？ 迭代（Iteration）是一个通用词汇，表达的是开发过程中的某个循环过程的单元。这个单元可以是开发人员编写代码时的编写、编译、调试、重构，也可以是一个开发周期的规划、开发、测试、回归、发布。也就是说，这个单元可大可小，都可以使用迭代来进行描述。 冲刺（Sprint）特指在Scrum中的某个产品开发周期，是一个2-4周的规划、开发、测试、回归和发布过程。

08 什么是故事点？ 在Scrum中使用用户故事（情景）作为描述一个产品特性的方式，同时使用“故事点”作为这个产品特性大小的定量估算单位，故事点的大小标识了一个产品特性的开发难度和所需要的投入（小时/人天等）。但我们一般不使用直接的小时或人天等时间单位来表示这个值，而是使用斐波纳奇数列中的数值来标识不同特性的相对大小，这样做的好处时我们可以屏蔽直接使用时间单位所造成的主观差异，更快更准确的进行评估（因为在没有进行实际开发之前是很难直接估算时间，但是不同特性的相对大小是比较容易评估的）。最终，我们可以使用数据分析手段在故事点单位和时间单位之间建立换算关系，帮助我们掌控项目进度。 在CodeArts中，可以通过需求的“详细信息”页面中编辑分配给它的故事点。

21 Scrum的不足 对于目标不够清晰的项目，Scrum Master比较难以把控。 Daily Scrum在开始阶段会让团队感受比较大的压力，并占用一定的工作时间。 对于团队成员的技术水平、协作水平有较高要求。 Scrum中对于变更的容忍度非常高，但这也会让项目干系人感受比较大的不安。 会暴露非常多的问题，如果组织对于变化的接受度不高，会有很大的组织性冲击。 会引发很多变革的发生，一定程度造成混乱的局面。

为什么敏捷开发可以帮到你？ 误解：敏捷开发是为了快速交付？ 敏捷开发不是一种为了快速交付而出现的方法，它之所以比较快则是因为避开了许多浪费的处理方式。 那么，敏捷改善了些什么？ 前置时间：传统开发法依循计划、分析、设计、程序开发、测试再进行修改整合后发布的步骤进行，是一种顺序性的开发模式，当前一个步骤用掉越多时间时，后面步骤的前置时间就会越长，而形成时间上越多的浪费。反观敏捷开发，实行的是一种务实的做法，当收集到足够一次迭代开发的需求时即向下一个步骤前进，尽量缩短前置时间的浪费，然后将"分析、设计、开发与测试"形成一个开发步骤，减少了步骤与步骤之间的衔接时间。 首次发布：敏捷开发采用迭代的开发方式，每个循环都会有一个潜在可发布版本用来展示开发成果，这种展示给了客户进行回馈和改进的机会，让客户体会开发成果的作法同时也给予了客户决定开发方向的绝对主权。 需求过程：敏捷开发不作完整的需求分析（因为计划总是赶不上变化的），当需求的搜集量和内容质量已经达到一定要求，已经足够一个开发周期的工作量时就可以开始开发工作。 测试方法：敏捷开发对软件带来的最大影响便是测试了。传统的α（内部测试）、β（交付客户测试）、γ测试（优化处理）方式在采用敏捷开发后几乎不存在了，因为敏捷开发在开发周期内不断的进行测试工作，因此也就没有了在交付做α、β、γ测试时必须停止开发、冻结开发的时间浪费了。

敏捷开发方法 除了《敏捷软件开发宣言》内所提到的价值观和原则以外，敏捷开发并没有一个完整的方法列表，因为所有的敏捷开发方法都是广大开发人员在日常的工作中摸索出来的，针对某种特定场景适用的方法。也就是说，以下所列出的敏捷开发方法并不一定适用于你的团队或者你的问题，但是敏捷鼓励所有人按照自己的方式尝试任何的方法，只要这种方法遵循以上价值观和原则，那么它就是一种敏捷方法。 Scrum Kanban（看板方法） Agile Modeling（敏捷建模） FDD（Feature-driven development，特性驱动开发） TDD（Test-driven development，测试驱动开发） XP（eXtreme Programming，极限编程） Lean Development（精益开发） Microsoft Solution Framework (MSF) for Agile（微软解决方案框架敏捷版） Agile Data Method（敏捷数据方法） ASD（Adaptive Software Development，自适应软件开发） Six Sigma Crystal（水晶方法） BDD（Behavior-driven development，行为驱动开发） DSDM（Dynamic Systems Development Method，动态系统开发方法） Exploratory Testing（探索性测试） 《2019年中国DevOps现状报告》中，针对国内各种敏捷开发方法的调研结果显示：在所有敏捷方法中，Scrum、看板方法、自定义混合模式是最受企业欢迎的前三种敏捷开发方法，占比分别为45.41%、41.23%、31.46%。 由CollabNet VersionOne发布的《第13届年度敏捷状态报告》中，敏捷方法应用状况的调研结果显示：Scrum和Scrum/XP混合（64%）仍然是受访者组织使用的最常见的敏捷方法。

敏捷宣言 “敏捷”一词来源于2001年初美国犹他州雪鸟滑雪圣地的一次敏捷方法发起者和实践者（他们发起组成了敏捷联盟）的聚会。雪鸟会议共同起草了《敏捷软件开发宣言》，其中最重要的部分就是对一些与会者一致同意的软件开发价值观的表述。 价值观 个体和互动 高于 流程和工具 工作的软件 高于 详尽的文档 客户合作 高于 合同谈判 响应变化 高于 遵循计划 也就是说，尽管右项有其价值，我们更重视左项的价值。 原则 敏捷宣言中还包括以下原则： 对我们而言，最重要的是通过尽早和不断交付有价值的软件满足客户需要。 我们欢迎需求的变化，即使在开发后期。敏捷过程能够驾驭变化，保持客户的竞争优势。 经常交付可以工作的软件，从几星期到几个月，时间尺度越短越好。 业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。 围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，满足他们的需要，并相信他们能够完成任务。 在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。 可以工作的软件是进度的主要度量标准。 敏捷过程提倡可持续开发。出资人、开发人员和用户应该总是维持不变的节奏。 对卓越技术与良好设计的不断追求将有助于提高敏捷性。 简单——尽可能减少工作量的艺术至关重要。 最好的架构、需求和设计都源自自我组织的团队。 每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为。

小结 持续交付、持续部署、持续发布，更多的是技术行为与业务决策的区别。 解耦不是分家，最终整体团队的衡量，还是要由业务形成闭环。持续发布是以持续部署为基础，持续部署提供技术能力，使得业务可以根据市场需要，随时进行特性发布，或是进行特性实验。 正是因为技术的支持，持续部署到生产环境，才能让业务前所未有的具备如此灵活的能力，任何业务的决策，可以不再如此紧耦合的依赖于IT。 这也是DevOps Handbook全书的重点，关注在“部署前置时间”，而并非前置时间。即全书都在围绕着代码提交那一刻往后的过程，因为作者们认为，在提交前的阶段，需要更多的创造性，具有更多不确定因素。而提交后的阶段，则相对是确定的，力求可预见性和自动化，将可变现降到最低，以此来支撑业务需要。

对持续交付与持续部署的解读 对于持续交付以及持续部署等概念的解读，核心就是一句话：将技术行为与业务决策解耦。持续集成是一个开发实践，持续部署是一个技术操作，持续交付是一个业务行为。 “持续交付是指，所有开发人员都在主干上进行小批量工作，或者在短时间存在的特性分支上工作，并且定期向主干合并，同时始终让主干保持可发布状态，并能做到在正常工作时段里按需进行一键式发布。开发人员在引入任何回归错误时（包括缺陷、性能问题、安全问题、可用性问题等），都能快速得到反馈。一旦发现这类问题，就立即加以解决，从而保持主干始终处于可部署状态。” “持续部署是指，在持续交付的基础上，由开发人员或运维人员自助式的定期向生产环境部署优质的构建版本，这通常意味着每天每人至少做一次生产环境部署，甚至每当开发人员提交代码变更时，就触发一次自动化部署。” “持续交付是持续部署的前提，就像持续集成是持续交付的前提条件一样。” 这里面涉及到的有几个概念：持续集成、持续交付、持续部署，以及持续发布。

技术域 “客户并不一定需要每一个green build，PM/发布经理按业务需求可选择任意一个，在任何时候自动化交付给客户；在部署、交付、发布的上下文里，dev和ops的最高境界是无为，赋能PO那帮人做业务决策，别烦我。”——Martin Liu。 从这句话中我们可以看出，从业务上，并非每一个功能都需要发布给每一位用户，而是根据不同的业务上下文，来决定哪些功能发布出来，针对哪些用户进行开放。发布决策，由业务来做。而技术需要的，是提供高效的交付能力，并保持随时可发布的版本状态。 技术层面的核心，在于保障价值的交付能够顺畅、频繁且快速的通过整个价值交付流水线 。 SAFe的持续交付流水线 下面让我们看看SAFe对持续交付流水线的划分，事实上，“Develop on Cadence, Release on Demand”也是来自于SAFe的内容。中间的持续集成与持续交付，正是关系部署前置时间的部分。前端的持续探索，属于产品、设计与开发内容，而这三部分，组成了技术域的发布火车。后面何时发布、如何发布，则是按业务的需求决定。 聚焦于部署前置时间 "How long would it take your organization to deploy a change that involves just one single line of code? Do you do this on a repeatable, reliable basis?" ——Mary Poppendieck 修改一行代码，上线需要多少时间？这一指标决定了你能多持续、多稳定的交付，决定了MTTR，多久服务可以恢复、多快能够上线一个严重的缺陷修复、多快能够发布一个服务并获取价值反馈。这一指标，就是部署的前置时间。 部署前置时间，开始于工程师在版本控制系统中提交一个变更，截止到变更成功的在生产环境中运行、为客户提供价值，并生成有效的反馈和监控信息为止。 部署前置时间将整个价值流交付过程分成了两段，前一段的活动，主要是产品、设计和开发，具有高度的不确定性和变化性，需要创造性的工作，且很多工作无法复制。后一段的活动，主要在集成、测试和部署运维，相比起来，相对技术更可控。 所以部署前置时间的核心，是把可控的部分做到极限，力求可预见性和自动化，将可变性降到最低，来支撑变化的部分。 目标是分钟级的部署前置时间 通过小批量代码交付，在不同环境中通过不同层级的自动化测试与探索性测试，快速进行验证，同时持续将成功验证的变更部署到下一环境，从而在DTAP（开发、测试、验收、生产）不同环境中形成自动化的测试和部署节奏，这也就是部署流水线的概念。为实现部署流水线，需要版本管理、自动化测试、持续集成、自动化部署、环境管理，以及松耦合架构等的协调统一。 分层分级的部署流水线 “高质量的交付”，质量如何界定？功能和非功能的都算上，质量验证的手段也是分层的，验证就是反馈，为了快速获取反馈，这些手段分布在整个流水线的各个阶段。 部署流水线，是保障质量并缩短部署前置时间的有效支撑。同时，部署流水线，是分层分级的。 从影响范围来看，分为个人级、项目级、版本级、解决方案级的流水线。 执行的频度单位，分别是分钟级、小时级、以天为单位、和以周为单位。 分别对应不同的环境（DTAP）：Development、Testing、Acceptance、Production。 各个层级，在不同的环境上，执行不同的测试，这也与理想的测试金字塔分层测试相互对应。 每个层级的目的、和预设的反馈回路、涉及的范围、验证的方法与内容、定位问题区间都有所不同。 流水线越来越成为开发运维一体化的代名词 开发与运维之间“不可调和的矛盾”，可以通过流水线来解耦。流水线成为开发和运维人员最常使用的平台，从日常的提交代码自测，到提交到主干的持续集成，到测试和准生产环境的自动化与手工的验证，以及各级环境之间的部署和环境拉平。 很多人对于自动化都喜欢强调或追求“一键”的概念，然而一键只是方式，不是目的，更不是唯一。事实上，在部署流水线里面，甚至可以消除掉一键那个动作。 流水线的存在，接管了底层的基础设施，包括计算、存储、网络，无论是On Premise，还是On Cloud；接管了PaaS层，开发人员无需太关注是虚拟机，还是容器，也不必太多了解K8s的配置和编排，以及DTAP不同的环境的配置和差异；甚至接管了上面使用的自动化工具，包括版本库、制品库、持续集成、自动化构建、自动化测试工具、自动化部署工具。 这些都将成为流水线的一部分，所以流水线越来越不可或缺。不同的语言也好、架构也好、环境也好、容器也好、微服务也好、K8s也好，都可以往流水线上挂，流水线也就成为Dev to Ops事实上的标配和代名词。 所以流水线的作用，第一，接管和屏蔽底层环境的差异；第二，自动化流程引擎；第三，挂载执行分层分级的流水线任务。 流水线也是“持续稳定可重复的提供高质量的价值”的重要不可或缺的实践，服务于持续交付，同时也是DevOps的最终目标。 流水线确保代码和基础设施始终处于可部署状态，所有提交到主干的代码都可以安全的部署到生产环境。 所有在流水线上面挂载的任务，理论上都应该服务于这一目的，所有不对这一目的提供价值的任务，理论上都不应该存在于流水线之上，都应该被消灭。 说到这里就不得不说一说能支持自动化部署流水线的工具——CodeArts。 在流水线方面，CodeArts提供可完全自定义的自动化部署流水线，关联版本库、编译构建、部署等多环节的功能，提交代码自动触发流水线，帮助团队轻松实现持续交付。任务配置中支持挂载子流水线，流水线分层分级管控。 解决开发与运维之间“根本的、长期的冲突” 通过流水线，让部署成为日常的、低风险的工作，来解决开发与运维之间“根本的、长期的冲突”：开发负责对市场变化做出响应，以最快的速度将新功能或者变更上线，而IT运维则需要为客户提供稳定、可靠和安全的IT服务；同时公司对不同部门的考核和激励不同，更是让开发部门与运维部门的目标和动因之间存在巨大的冲突。 通过小批量的、独立的快速交付周期，让各个功能/服务团队之间彼此解耦，快速获取反馈，快速验证问题，DevOps并不能解决问题，它只是让你快速失败，If you fail，fail fast。（所以在DevOps里，失败原本就是学习的一种方式） 通过频繁、快速的生产环境部署，保证稳定可重复的自动化部署。 通过Feature Toggle（功能开关/特性开关）、Dark Launch（灰度上线），让功能早在发布之前，就已经部署到生产环境中，并已经进行了多次小范围验证。为下游工作而优化，从而在业务需要时，可以不依赖于技术，可以自行进行功能的发布。 因此技术提供给业务的是一个自服务平台，正如将运维能力封装成自服务提供给开发一样。

小结 量变产生质变，每100天一次发布，与每天100次发布，无论是从技术上、实践上，还是对业务的帮助上，都不可同日而语。更重要的，是mindset的转变，做具体的一个工程实践不难，但要把它做好做到极限很难，这里面的困难更多不是技术本身，而是思维方式的转变。 持续交付流水线，将整个价值交付过程贯穿起来，即使只是后半段的DevOps实践，也同样的牵一发动全身，发布频度这一个关键指标，就需要分支策略、测试自动化、部署自动化、架构解耦、发布策略、数据库等多方面的支持。

业务域 我们再来看看业务域。 “持续交付跟这三个（持续集成、持续部署、持续发布）都不同，它是一种组织的能力，这种能力让组织可以持续的交付价值，具体是否采用以上三种技术实践并不一定，而且还必须考虑其他非技术因素，比如团队管理模型，需求结构，项目管理方式，人员能力等等。所以这个持续交付和以上3个不是一个层次的问题，但他们之间确实有互相推动影响的关系。”——徐磊 发布策略与发布节奏 持续集成与持续部署是技术域的事情，持续交付是业务域的。而持续发布，本文认为两者都有，但偏业务层面多一些。按需发布，因此发布还是业务的决策。 业务需要决定发布策略： 什么时候发布？ 发布哪些特性？ 发给哪些用户？ 发布节奏不需要与开发节奏保持一致，开发保证环境和功能是随时可用的，业务来决定发布策略。 假设驱动开发 持续交付流水线是Flow，是价值交付的过程，但如何确定交付的就是客户想要的价值？ 所有交付的功能特性都是基于假设：We believe that [building this feature] [for these people] will achieve [this outcome]. We will know we are successful when we see [this signal from the market]. 这就是假设驱动开发的概念。所以单向的不叫持续交付（价值），要实现闭环还需要反馈回路来验证假设。完整的闭环才是价值交付的过程，只有验证了假设，才能说将价值交付给了客户。通过发布，获取反馈，验证假设，进一步完善价值，进而提出新的需求（假设）。 SAFe的DevOps理论，大多来自于DevOps Handbook。SAFe的模型，是DevOps Handbook三步工作法的另一种解读。 多快的频度算是持续 什么叫持续交付？多快的频度算是持续？一周一个版本还是一天多个版本？ 视不同类型的产品，在类生产环境验证之后，有两条路径：一条是传统的软件模式，部署到生产环境，或是商业软件产品的客户交付过程，就意味着发布给最终客户，那么这里需要有一个业务的决策过程，是否可以将特性交付给最终客户。另一条是通过技术解偶的手段，实现即使是部署到了生产环境，也并不意味着发布给了最终客户，例如特性开关和Dark Launch。相较于第一种，这里业务决策过程就相对灵活一些。 以上两条路径，均需要技术手段来支撑，实现将特性先行发布给一部分用户，以及功能对用户是否可见。 持续部署对业务的赋能 “黑启动已经让每个人的信心达到几乎对它冷漠的程度…...大家根本就不担心…...我不知道，在过去5年里的每一天中，发生过多少次代码部署…...我根本就不在乎，因为生产环境中的变更产生问题的概率极低……”，John Allspaw在Flickr担任运营副总裁时说了上述的话，随后他发表了一天十次部署的著名演讲，随后他来到Etsy，Etsy的自助式部署流水线，使得“任何想要执行部署的人都能直接部署……董事会成员也可以执行部署……甚至连小狗都可以！……在一个普通的工作日里，刚到上午8点整，就有大约15个人和小狗开始排队……” 2010年时，Etsy的持续部署流水线工具已经将ChatOps集成进去，“提交代码之前，在自己开发环境执行了4500多个单元测试……UT运行仅需要不到1分钟，外部调用打桩……提交到主干后，CI服务器上立即执行7000多个自动化测试用例…...通过并行测试，11分钟执行完毕，MTTR20分钟……到2011年，每天25-50次部署”。 从上述的例子，可以看出技术对业务极大的赋能。如果我们能做到每天几十次的部署到生产环境，那么每次的变更又能有多大，一个月一次的版本，发布的时候的确需要严格审核，一天几十次呢？不难想象，此时的业务决策该有多简单，甚至可能不需要决策过程，这就是技术能力赋能给业务决策的体现，也是精益中强调小批量的原因。 低风险发布 按需发布，让特性发布成为业务和市场决策，而不是技术决策。 通过金丝雀发布，可以小批量的选择环境进行试验，待金丝雀验证通过再发全量。而滚动发布，使得这一流量切换过程更加平缓，一旦出现问题，可以自动回滚。 通过特性开关，可以保证应用上线后，功能开关先不打开，然后由业务人员根据场景进行决策，通过开关中心打开新功能，经过流量验证新功能。特性开关将部署与特性发布解耦，结合基于环境和用户群的蓝绿或是滚动发布，可以实现对不同的用户群进行不同功能的投放，实现A/B测试，进一步增强了假设驱动开发的能力，可以基于不同的假设路径，进行快速灵活的发布验证。

DevOps与云 DevOps要支持云，虚拟化与云技术可以带来DevOps要求的标准化以及自动化。 环境标准化 无论是针对基础设施还是运行时环境都要求环境标准化，并把这些环境投入开发、QA和IT运维的日常使用，这样就能消除大部分在部署流程中因为差异而导致的问题。不仅应该拿出可部署的代码，还应该拥有部署这些代码的确切环境，并在版本控制中一并控制与检查。 混合云下的DevOps诉求 在云的场景下，如何利用虚拟化、容器等技术加速环境的创建以及标准化，如何通过自动化的方式加快环境搭建，如何在On-Prem、私有云、公有云，不同厂商不同类型的云的混合模式下，统一流程，统一DevOps的用户感受。 同时，由应用层的自动化部署，同样可以发现Infrastructure层、Runtime层的问题，虚拟化与云的技术也与DevOps相辅相成，相得益彰。 华为云CodeArts服务 CodeArts提供软件开发全生命周期的云端DevOps工具链，帮助团队真正实现自动化，标准化，配置化。 CodeArts提供基于Git的版本控制系统，不只将代码版本化，而是版本化管理一切与环境有关的配置。 CodeArts提供可自定义的自动化部署流水线，提交代码自动触发，帮助团队实现持续交付，为团队带来自动化，标准化。

KPI与度量 为了促进DevOps战略，调整绩效考核和激励机制是必要的，按各自为政的KPI考核只会造成部门之间的隔阂，只根据敲出代码的生产力来奖励开发人员，或者根据基础设施的可靠性来奖励运维人员，什么都无法改变；围绕业务系统而不是职责来组织工作，这就是DevOps打破IT分组壁垒的寓意。 团队一起协作，共同为他们的应用和系统负责。 以下是部分度量参考： 开发应用所花费的最高时间（开发速率） 失败部署的百分比（部署成功率） 客户产生了多少问题（客户接受度） 故障恢复的平均时间（团队解决故障的能力） 用户数（用户欢迎度）

DevOps不只是开发与运维的问题 一般而言，开发与运维有着不同的文化：开发部门的驱动力通常是“频繁交付新特性”，而运维部门则更关注IT服务的可靠性和IT成本投入的效率，降低风险。两者目标的不匹配，在开发与运维部门之间造成了鸿沟，从而减慢了IT交付业务价值的速度。运维从维稳出发，自然希望生产系统部署上线次数越少越好，而上线频度降低，对开发人员是一个负激励：反正我发布的版本也不会上线，反正我再积极也不能实时的体现出来，团队积极性和人员士气都会受到打击。 与此同时，业务部门则希望业务需求尽快的推向市场，而维稳的要求导致价值交付用户的速度被延缓，价值无法迅速得到反馈验证。 当发布列车变成3个月一趟车次时，业务人员习惯于自己的需求无法快速得到满足，能想出的方法就是把所有的业务需求都设置成最高优先级，去抢占发布窗口。所有人都这样想这样做，拥堵就此产生，真正高价值的需求无法得到快速交付。（试想，如果每天有十次发布，大家还会拼得头破血流去抢一个发布窗口么？） 上线频度低的另一个副作用是，单次上线中包含的变更规模变大，风险也随之增加。事实上，减少上线次数不仅不会降低风险，反而让每一次上线都变得像一个火药桶，危机四伏。

DevOps与精益、敏捷 DevOps是基于敏捷与精益原则的方法。DevOps是软件开发生命周期（SDLC）从瀑布式到敏捷再到精益的发展。 DevOps超越了敏捷，它的关注点是从SDLC中移除浪费。通常情况下，发现浪费或者瓶颈的形式包括：不一致的环境、人工的构建和部署流程、差的质量、IT部门之间缺少沟通和理解、频繁的中断和等待、部分完成的工作、额外的功能、任务切换等。 DevOps强调流水线，交付管道，与传统生产与制造业有着千丝万缕的联系。 DevOps实施中，可以借鉴精益理论中的很多思想，例如：降低批量规模、减少半成品、缩短并增强反馈回路、价值流图分析、时间线分析、消除浪费，以及敏捷中持续集成、持续测试、持续交付、持续监控、A/B测试、灰度发布、滚动更新等。

从小处下手 理解了DevOps是一个端到端的过程，我们就会发现整个交付链条涉及太多的领域，导致问题也层出不穷，无从下嘴。因此在实际操作中，我们需要有一个切入点 DevOps的思想以精益与敏捷为核心，通过暴露问题、解决问题，从而实现持续改进。从精益的角度看，在代码投产之前，实际上未产生任何价值，都只是半成品。 要限制半成品，即在制品（WIP）数量，让其尽快流过生产线，让投入产生交付价值。 DevOps是一个复杂问题，我们却希望可以把一个复杂的问题简单化：正如装修时通过加压检查管道是否泄露，是否有阻塞，我们也通过加压的方式来暴露软件交付管道的问题。那么如何加压？以终为始，我们选择业务价值交付的那个点，也就是部署与发布来对整个交付管道进行加压。团队可以简单的问自己一个问题：“能不能一天部署10次？”如果没有办法？那么原因何在？流程不规范？自动化不够？沟通导致效率低下？过程无法复用？环境差异导致回归出错？逐一的暴露问题，解决问题，交付能力自然提升。 需要注意的是，根据《凤凰项目》中提到的TOC约束理论（Theory of Constraints），在瓶颈之外的任何地方做出的改进都是假象，在瓶颈之后做的任何改进都是徒劳的，因为只能干等着瓶颈把工作传送过来，而在瓶颈之前做的任何改进则只会导致瓶颈处堆积更多的库存。所以如何识别真正的瓶颈变得尤为重要，在发现问题之后多问几个为什么，力求找到根源原因。 DevOps的由来 Flickr公司的约翰·阿尔斯帕瓦和保罗·哈蒙德在2009年Velocity技术大会关于开发速率的一场演讲，“一天十次部署”，是2009年前后兴起的DevOps运动的一部分，提倡开发和IT运维通力协作，在完成高频率部署的同时，提高生产环境的可靠性、稳定性、灵敏性和安全性。2009年一天十次部署就算很快了，但现在只能算平均水平，2012年亚马逊公司宣布，他们平均每天能开展23000个部署。 公司 部署频率 交付周期 Amazon 23000次/天 分钟 Google 5500次/天 分钟 NetFlix 500次/天 分钟 Facebook 1次/天 小时 Twitter 3次/周 小时 一般企业 1次/9个月 月、季度 Wikipedia上说，有以下几方面因素可能促使一个组织引入DevOps： 使用敏捷或其他软件开发过程与方法 业务负责人要求加快产品交付的速率 （新兴技术趋势，例如云计算、移动应用、大数据和社交媒体） 虚拟化和云计算基础设施（可能来自内部或外部供应商）日益普遍 数据中心自动化技术和配置管理工具的普及 传统的管理方式导致“烟囱式自动化”，从而造成开发与运维之间的鸿沟

DevOps要实现：自动化、标准化、配置化 自动化：全面自动化，构建、部署、测试、升级、扩展、维护、监测、安全和策略管理。通过自动化，倒逼团队高效沟通，倒逼流程规范；自动化手段确保部署任务的可重复性、减少部署出错的可能性。 标准化：（流程，环境，配置）基础环境标准化，运行环境标准化，应用环境标准化/多样化。 配置化：通过配置，尽量避免代码，通过功能开关或者参数设置，来支持A/B testing、灰度发布。

DevOps实践 不做什么比做什么更重要：相比起向系统中投入更多的工作，将无用的工作剔出系统更为重要；无用的工作、无用的项目、无用的产品，排优先级，筛选出哪些是真正重要的工作。 运维参与研发评审：常见的现象是，运维人员很少被邀请参与架构决策或代码评审，开发代码是否会影响运维环境前期无人知晓，需要让运维人员参与架构评审，从运维角度提出对系统的要求。 非功能性需求同样重要：偿还技术上的债务。每个人都像重视功能性要求一样重视非功能性要求QoS（质量、稳定性、可维护性、持续性、可扩展性、可管理性、安全性、可操作性），非功能性需求对于实现业务目标同等重要，要把非功能性需求设计到产品当中。 整体协作：产品所有者、开发部、QA、IT运维部以及信息安全部通力协作，帮助彼此乃至整个企业取得胜利。 质量为先：上游团队不再给下游团队造成麻烦，开发部将20%的时间用于帮助确保工作顺利的通过整个价值流，加快自动化测试，改进部署基础架构，并确保所有应用程序建立有用的产品遥测。 基础架构即代码（Infrastructure as a Code）： 把创建和部署流程自动化，把基础架构当成代码一样对待。 各套环境之间，代码版本、运行时、环境配置需要匹配。 需要将基础环境配置化、版本化管理。 运维服务化：DevOps会让开发部门承担更多的代码部署和维持服务水平的责任，要求把许多IT运维任务转变为自助服务。 版本化一切（Versionlize Everything）：应该把所有东西都进行版本控制，不只是代码，而是创建环境所需的每一样东西。 ITIL：为了适应DevOps更短的交付周期和更高的部署频率，ITIL流程的很多方面都需要自动化，特别是变更、配置和发布流程等。 云计算：有效的利用云技术，可以为开发和测试人员动态设置基础架构资源，快速获得测试环境。 针对类生产系统进行开发和测试 （环境的标准化），利用可重复的可靠流程进行部署，监控并验证运维质量； 放大反馈回路：快速反馈回路，防止问题代码进入生产环节，并且让代码能够迅速部署投产，从而迅速发现并修复任何产品问题。（编写代码时，单元测试、集成测试、验收测试一直在类生产环境运行，不断确认，代码和环境将会按照预先设定的运行，并且总是处于可部署状态）

三步工作法 目前行业中通常采用三步工作法以实现DevOps： 第一工作法：帮助理解在工作从开发移向IT运维时该如何建立快速工作流。 从开发到IT运维再到客户的整个自左向右的工作流。为了使流量最大化，需要小的批量规模和工作间隔，绝不让缺陷流向下游工作重心，并且不断为了整体目标（相对于开发功能完成度、测试发现/修复比率或运维有效性等局部目标）进行优化。 必要的做法是：看板、持续构建、集成以及部署，按需创建环境，严控半成品，以及构建起能够顺利变更的安全系统和组织。 第二工作法：如何缩短以及放大反馈环路，从而在源头解决质量问题。 价值流各阶段自右向左的快速持续反馈流，放大其效益以确保防治问题再次发生，或者更快的发现和修复问题。这样我们就能在所需支出获取或潜入知识，从源头上保证质量。 必要的做法是： 在部署管道中的构建和测试失败时“停止生产线”。 日复一日的持续改进日常工作。 创建快速的自动化测试套装软件，以确保代码总是处于可部署的状态。 在开发和IT运维之间建立共同的目标和共同解决问题的机制。 建立普遍的产品遥测技术，让每个人都知道，代码和环境是否在按照设定运行，以及是否达到了客户的目标。 第三工作法：如何建立文化，既能鼓励探索，从失败中吸取教训，又能理解反复的时间是精通工作的先决条件。 创造公司文化，带动两种风气的形成：不断创世，这需要承担风险并从成功和失败中吸取经验教训；理解重复和练习是熟练掌握的前提。不断加压，从而强化习惯并加以改进。（系统里要经常出些故障，长此以往，再遇到困难就没原来那么痛苦了。） 必要的做法是：营造一种勇于创新、敢于保险以及高信任度的文化，把至少20%的开发和IT运维周期规划给非功能性需求，并不断鼓励进行改进。

从大处着眼 究其根本，DevOps目的是提升业务交付能力： 如何快速的交付想法？ 如何让客户进行尝试（从而获取反馈）？ 如何快速响应客户反馈？ DevOps不应该只是IT内部的几个部门玩的游戏。必须跳出IT的角度，端到端（业务端到客户端）分析，才能弄清公司需要依靠IT的哪些工作来支撑业务目标，支撑企业战略 ，从而实现更完整、真正的DevOps。需要将IT变成一种能力，融入公司的日常运作中，融入业务活动中。在快鱼吃慢鱼的时代，需要快速试错，不断整合来自市场的反馈。 所以最终，DevOps是一个端到端的问题，是产品管理部、开发部、测试部、IT运维部、信息安全部协同工作、共同支持。DevOps尝试建立一个业务价值交付管道，业务规划、需求梳理、计划、开发、构建、测试、部署、运维、监控 ，在此交付过程中涉及到的部门/团队、过程、系统、方法都归属于DevOps关心的内容。

通过加大部署/发布频度来撬动整个交付过程 以应用部署自动化作为切入点，由部署自动化，往前倒逼测试自动化、构建自动化；进一步往前，配置管理、变更管理是基础要求；再往前，业务需求与敏捷计划同步关联，通过短周期迭代交付与反馈，加强业务与开发的协作沟通。 同样的，往后端与运维衔接，更小、更频繁的变更，需要让开发人员更多地控制生产环境，更多地以应用程序为中心来理解基础设施；需要定义简洁明了的流程，并尽可能地实现自动化，从而在完成高频率部署的同时，提高生产环境的可适应性。与此同时，可靠性、稳定性、弹性和安全性也同时提升。 由此也促成了开发与运维的协作，通过不断缩减批量规模，实现快速工作流，确保了部署环境时刻准备就绪，按需投产。频繁的发布、意味着每次发布包含的变化更少，每次部署不会对生产系统造成巨大影响，应用程序会以平滑的速率逐渐生长，逐步协调和弥合开发与运维之间的技能鸿沟和沟通鸿沟。

什么是DevOps？众说纷纭 WikiPedia上说：“DevOps是软件开发、运维和质量保证三个部门之间的沟通、协作和集成所采用的流程、方法和体系的一个集合。它是人们为了及时生产软件产品或服务，以满足某个业务目标，对开发与运维之间相互依存关系的一种新的理解。” 百度百科说：“DevOps（英文Development和Operations的组合）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运营工作必须紧密合作。” IBM这样说：DevOps是企业必备的持续交付能力，通过软件驱动的创新，保证组织抓住市场机会，同时减少反馈到客户的时间。

用户故事地图，既见树木又见森林 由影响地图得到了What部分，也就是我们要做什么，是不是就可以当成用户故事（User Story）排进产品待办事项（Product Backlog）开始开发了呢？答案是还不可以。 用户故事是敏捷开发中普遍使用的实践，但常见的困惑是：产品负责人整理了一大堆的产品Backlog，还编排了优先级，过早地陷入到细节的讨论中，只见树木不见森林。 传统敏捷开发中，扁平的产品待办列表，存在很多问题：它很难解释产品是做什么的。对于一个新的系统，扁平化待办列表无法帮助我们确认是否已经识别出全部故事。同样的，扁平化待办列表也无法帮助制定发布计划，用户故事少则几十，多则上百，详细分析每一个用户故事并且做出是否采纳的决定是非常乏味并且低效的。 用户故事地图是一门在需求拆分过程中保持全景图的技术，目的是既见树木，又见森林，聚焦于故事的整体，而不是过早的纠缠于细节，在看到全景图的同时，逐层进行细节拆分。采用用户故事地图，跳出了扁平化的产品待办列表，看到了产品的全景图，可以真正聚焦于目标用户以及产品最终的形态。产品待办列表只是一维的，而用户故事地图是三维的，这是高维与低维的比较，高维恒胜。 用户故事地图基于简单的网格结构，规则是从左到右讲述故事，即按照叙事主线顺序；自上向下的拆分，即由大到小的细节展现。其中最关键的部分是产品的构思框架，贯穿整个产品的发布地图，可以帮助团队以可视化方式展示依赖关系。此外，更多的背景信息可以摆放在地图的周边，例如产品目标、客户信息等，这几乎就是用户故事的全部了。这也恰好是用户故事地图的魅力所在，好的东西通常都很简单而有效。