华为云用户手册

总结 以上三种没有人认领任务的情况，是比较常见的。但在真正的实际项目中，每个公司或团队的情况都不尽相同，无法穷举所有，应具体情况具体分析。比如，一个刚刚转型的敏捷团队，在开发任务的领取上可能会更偏向于半指派半领取的方式。这就好比中国经济一样 “以市场经济为导向，适当进行宏观调控”。但不管这个“调控”的力度如何，我们都应该鼓励团队成员能积极主动地领取任务，并随着任务的进展情况灵活调整，及时做好风险把控，必要的时候需要其他渠道的协调帮助或相关领导的介入，以保证迭代的目标不受影响。

问题分析 首先，相对于传统开发模式的指派开发任务，我们需要知道为什么在敏捷开发中是领取任务。在敏捷中，不管是敏捷宣言还是Scrum指南，都没有指派（assign）一词，而是使用了一个术语自组织，如下： 最佳的架构、需求和设计出自于自组织的团队（敏捷宣言12项原则）。 自组织团队自己选择以何种方式来完成工作，而不是由团队之外的人来指导（Scrum指南）。 开发团队是自组织的。没有人（即使是Scrum Master）有权告诉开发团队应该如何把产品待办列表变成潜在可发布的功能增量（Scrum指南）。 那么“自组织”是什么呢？ 从字面的意思来理解，自组织就是：安排分散的人或事物使其具有一定系统性或组成一个整体，而安排的人就是安排者自己。在敏捷开发中，自组织团队就是具备自我管理、自我驱动、自我学习等能力的敏捷开发团队本身，这样的团队一般具备如下特点： 团队成员自己“拉”工作，不是被动等待领导分配工作。 团队作为一个整体管理工作。 团队仍然需要辅导和指导，但不需要指挥和控制。 团队成员彼此沟通紧密，互通有无。 团队主动发现和提出问题并共同解决。 团队不断提高自己的技能，鼓励探索和创新。 更多关于自组织的相关内容不在本文的范围内，如感兴趣请参阅参考文档。 从敏捷宣言和Scrum指南关于任务的工作方式上来看，在我们践行敏捷的时候，主要发挥的是开发团队自身的主观能动性，开发团队由原来的控制性转变成了自组织性，而开发任务也就由原来的指派变为了领取。这样的好处是，领取任务就是发挥了人的主动性，而自主性是人们从事创造性和解决问题的动力之一，良好的自我组织能给团队和个人带来高绩效、出色的工作成果以及喜欢的工作环境。另外，每个人都是最了解自己的，也擅长为自己分配任务，相对于传统的指派开发任务所带来的易主观臆断、分配不当等更具有合理性。 然后，回到“计划会议认领任务的时候，有几个任务没人认领怎么办？”这个问题上。 在此之前需要先澄清的一个观点：在计划会议中，不一定非要全部领取完开发任务。在Scrum指南中指出“领取工作在Sprint计划会议和Sprint期间按需进行。”可以理解为，在每日Scrum站会上基于目标领取任务。另外，Mike Cohn也表示过，不建议在计划会议中领取开发任务，这样可能会导致目标由团队变为了个人，进而违背了敏捷的本意，降低了灵活性。 一般来说，开发任务没人认领的原因主要有： 开发任务的难度大：当开发任务比较难以解决，超出了团队大部分成员的能力时，团队成员可能会存在担心加班加点而不愿意认领。 开发任务超范围：当开发任务的内容超出团队成员所掌握的范围时，如开发不会测试，就可能会出现“我是想认领的，但能力有限”的情况。 担心受到他人指责：工作内容存在一定的挑战性，担心由于自己没有做好，导致团队目标没有达成而受到指责。 那么应该如何解决呢？

解决方案 在一个敏捷Scrum团队中，Scrum Master扮演着重要的角色，该角色一部分的作用就是要帮助团队成为自组织型团队，以便让团队能以积极的心态去面对冲刺的开发任务。此外，当出现任务没有人愿意认领的情况时，首先Scrum Master应该帮助团队弄清楚没有人认领的原因是什么再对症下药，下面基于分析中的三种情况分别给出解决措施。 开发任务难度大 对于开发任务难度大的情况，Scrum Master应该组织团队进行有效的任务分解，使用探针Spike技术，探索出解决措施以降低任务的难度，再由团队去认领；或者鼓励技术能力较一般的成员和技术大牛通过结对编程的方式来一同认领任务。 在华为云CodeArts中，可以对该类难度大的用户故事通过子工作项的方式进行拆分，同时在基本信息中通过设置处理人和抄送人的方式以记录结对编程的人员配对情况： 图1 Story内容介绍 除此以外，在每日Scrum站会的时候要留意和了解该开发任务的情况，进行风险评估，如有问题及时帮助协调解决。在回顾会议中，应对该类情况进行分析并能输出基于团队的一套标准工作方式方法，然后将解决方案记录在团队知识库中，华为云CodeArts提供了知识库的功能，可以为团队很好的整理和记录工作方式，如图2所示。 图2 任务认领说明 开发任务超范围 敏捷提倡的团队是跨职能团队，但是团队的跨职能并不意味着一个人能做所有的事情，我们希望的跨职能团队往往是由掌握多项技能的T型人才（每个成员在一个专业领域具有深度，而在其他领域具有广度）所组成的。首先需要Scrum Master能够和团队整理和维护成员技术矩阵，把个人技能掌握情况对团队公开（知道团队欠缺什么、知道可以和谁学等），然后定期组织技术分享等活动以帮助团队成员学习（主要以学习一项新的技术后的分享方式），这样可以在一定程度上提升成员在冲刺中愿意领取其他任务的热情。另外，还可以由专长成员和意愿成员组队，采用结对编程的方式领取任务，以实现个人技术的扩充。团队成员的T型能力建设，不仅仅能让团队领取任务的时候有更多的选择，也提供了成员的backup能力，减少无人认领的情况发生。此外，同样也需要Scrum Master留意日常评估风险和引导团队回顾该事项并维护团队知识库。 担心受到他人指责 工作内容存在一定的挑战性，担心由于自己没有做好，导致团队目标没有达成而受到指责。Scrum Master应该对团队贯彻以团队为整体的思想，并指导和强调Scrum的价值观，尊重团队的每一个成员的背景、经验，也包括开发任务的选择，还要鼓励成员能有勇气去选择和尝试。在实际的工作中，我们可以通过在墙上、白板等贴上标语（如“尊重他人”、“只有团队没有个人”等）的方式，让团队从思想意识方面发生转变，慢慢敢于去领取有挑战性的任务。此外，Scrum Master要充分保护好成员对有挑战工作认领的热情。如防止在回顾会议上出现指责和批斗的情况，回顾和总结永远应该聚焦的是做事的方式方法而不是对人的苛刻和指责。

原始需求管理介绍 成功产品的核心特征是满足客户需求，客户需求是华为发展的原动力。CodeArts Req打破了传统需求管理工具仅在研发阶段发挥作用的限制，将客户与市场需求也同步覆盖，提供了完整的客户需求采集、价值需求决策、交付与验收流程，让需求进展和动态客户实时透明，市场需求流动提速70%。 RR客户原始需求来自公司内部和外部的客户诉求，以客户视角描述的原始问题或者原始诉求，客户需求属于原始需求的一种类别。此类需求需要对应承接人分析后作出决定。RR客户原始需求的主要流程分为：提交、分析、规划、实现、交付、验收、关闭。 图1 原始需求状态转换流程图 父主题： 原始需求管理实践

分析原始需求 责任人在原始需求“分析”阶段定位诉求价值，分析决策后可选择“接纳”、“退回”或者“挂起”需求。 图1 分析原始需求 如果责任人分析后选择“接纳”需求，则必填对应的字段，明确需求后续的工作计划。 图2 接纳需求 如果责任人分析后选择“退回”需求，则必填对应的字段，分析不合理的因素。 图3 退回需求 当分析决策认为该需求处于非紧急状态，可选择“挂起”需求，并填写挂起原因，使需求进入挂起状态，暂时停止作业。 图4 挂起需求

我们如何灵活使用这些概念，让需求管理更为高效？ 为了加深对Epic、Feature、Story和Task的理解，本文对一个案例进行需求拆分，过程中会结合CodeArts需求管理服务进行展示。 案例： 某大型商超受互联网的冲击，营业额大幅下滑。 为了减少门店消费者流失，保有市场地位和份额，决定用6个月的时间建立自己的网上商城。 第一步：Epic确定和创建 根据前面的介绍，在进行需求确认的时候先看颗粒度，然后再考虑其承载意义。 此处需要考虑一个问题：一个产品是一个Epic吗？产品的每个业务模块是Epic还是Feature？ 产品通常具有战略意义，从这个角度看，产品适合作为一个Epic。但是不是所有的产品都适合，还要看产品是什么，它的颗粒度有多大。在本文的实例中，网上商城周期是6个月，目的是保有市场份额，从颗粒度和战略意义上，网上商城适合作为一个Epic。 每个业务模块具体是Epic还是Feature要分情况。比如：构建智慧城市是一个愿景目标，下面包括智慧交通、智慧政务、智慧社区等，这些每个业务模块都很大，用Epic进行需求占位合适一些。 在CodeArts创建一个Scrum项目，命名为“某大型商超网上商城”。进入“需求规划”界面，新建Epic： 图2 新建Epic 新建之后，单击进入到详细编辑界面。将描述信息填写完整，可以使用CodeArts提供的模板： 作为：对于这个Epic来说，用户角色是整个公司。 我想要：想要的结果就是建造网上商城。 以便于：目的是想要减少消费者流失，保有市场地位和份额。 同时在基本信息中设定这个Epic的起止时间、优先级、重要程度、预计工时等信息。这些信息对于团队理解产品、理解项目起到至关重要的作用，所以要进行详细填写。 图3 编写Epic 第二步：将Epic分解为Feature 客户要求在6个月内交付5个功能模块：促销管理、会员管理、订单管理、配送管理和客户端。团队的一个Sprint是2个星期，每个模块大概需要2-3个Sprint完成，从颗粒度和承载的意义，这5个模块适合作为Feature。 图4 Epic分解为Feature 创建之后，如需要填写详细信息，可以在详细页面进行编辑。界面信息项和前面Epic的相同，此处不再赘述。 第三步：Feature分解为Story 敏捷开发是渐进明细的，不要求所有需求在相同时间做到同样详细，只要求当前Sprint和未来的一个或两个Sprint的Story是详细的。将来Sprint的Story可以是一个大概的情况。进入到当前Sprint的Story要符合INVEST原则。开发团队要在Sprint结束时完成交付。 客户优先级中，会员管理Feature优先级高，会员管理这个Feature就要在需求梳理会议上详细分解为Story放入到产品Backlog中。经过分解后，需要包含和管理员相关的功能：积分管理、会员级别管理、用户分析、用户管理。这些具体的功能就可以作为Story。需要注意的是，我们分解出的Story要尽量在一个迭代内完成交付，如果无法完成就尝试继续分解。因为只有交付的Story才是有价值的，无法交付的Story对于当前Sprint来说就是浪费。分解后的Story如图5所示。 图5 Feature分解为Story 第四步：将Story划分为Task 在Sprint计划会议上，团队和PO要共同从产品Backlog中按照优先级顺序选择本次Sprint需要完成的Story，进入到冲刺Backlog中。团队成员认领后，将Story分解为Task，并进行估算。 此时面临一个问题：Story和Task如何区分？ Story聚焦价值，需要在Sprint中完成，要用数天的时间，要符合INVEST原则。Story的描述是一个名词，如积分管理这个Story的完整描述是：作为管理员，我能够进行会员的积分管理，以此来划分消费等级提供不同增值服务。 Task聚焦实现价值，通过过程性的任务来实现Story的功能。通常是1～8个小时。Task的描述是一个动作。如积分管理这个Story，功能的实现需要通过业务逻辑开发、积分规则设计和积分数据库设计这几个过程来完成，这些就是Task。如图6所示。 图6 Story分解为Task 这样，从Epic开始，到Task结束，我们完成了网上商城的需求拆分。

小结 使用Epic、Feature、Story、Task管理需求时，需要注意以下几个方面： 敏捷开发中需求是逐步细化的，遵循自上而下的方式去分解需求。 Epic和Feature都是颗粒度比较大的需求，是用户对于产品的期望和功能特性的描述。 分解为Story的时候，目前正在进行的Sprint需要分的更小更细，将来的Sprint需求（可能是3个及以上）就不需要那样细分。当进行到某个Sprint时，再进行分解，细分成一组更小、更细的条目。 Task是对当前Sprint的Story进行的分解。 所有这些粗略和详细的Story都放在产品Backlog中，整个列表要遵循DEEP（Detailed appropriately、Emergent、Estimated、Prioritized）原则，定期梳理和排序优化，保证高优先级的需求优先实现和交付。 在整个过程中需要和客户一直保持沟通合作，这样才能保证我们实现的功能是客户真正想要的。

什么是Epic、Feature、Story和Task？ Epic、Feature、Story和Task用来划分需求颗粒度的标签，可以看作需求占位符，分别代表需求颗粒度从大到小。每个层级的需求本身又承载着一些意义，在进行需求划分的时候可以进行参考。 Epic：史诗，是项目的愿景目标。通过Epic的落地达成，使公司可以获得相应的市场地位和回报，具有战略价值。通常需要数月完成。 Feature：可以带来价值的产品功能和特性。相比Epic，Feature更具体，更形象，客户可以感知，具有业务价值。通常需要数周，多个Sprint才能够完成。 Story：通常所说的用户故事，是User Story的简称。Story是从用户角度对产品功能的详细描述，承接Feature，并放入产品Backlog中，持续规划，滚动调整，始终让高优先级Story交付给客户，具有用户价值。Story要符合INVEST原则（Idependent、Negotiable、Valuable、Estimable、Small、Testable），通常需要数天，并在一个Sprint中完成。 Task：是团队成员要完成的具体任务。在Sprint计划会议上，将Story分配给成员，然后由成员分解为Task，并预估工时，通常在一天内完成。

协同下发缺陷 前面说到，对于系统设备类的项目，通常研发周期较长，涉及部门、团队较多，各个组织互相依赖，互为前提，因此常常出现一个缺陷涉及多个部门的情况。这时可以通过协同下发功能，将同一个缺陷下发给各相关方，下游项目收到该缺陷后，将启动各自的缺陷修复作业流程，各部门互相协作、跟进，共同推动缺陷的修复。同时，还可以在关联项中对自己的协同上游缺陷、协同下游缺陷进行跟踪，随时查看修复进度。 图1 协同下发缺陷 父主题： 模拟案例

缺陷管理实践概述 在产品研发过程中，往往存在各团队、各项目各自为战，产品质量难管控、缺陷修复进度难追踪的问题，严重影响产品交付效率。缺陷管理严格把控缺陷提出、分析、修复、测试、验收、关闭的完整流程，提供跨项目的缺陷作业跟踪追溯能力，实时识别产品缺陷风险，为组织的产品交付质量提供保障。 图1 缺陷管理流程 本文将基于系统设备类项目，介绍缺陷管理流程中涉及的主要阶段的最佳实践。 父主题： 缺陷管理最佳实践

监控和跟踪项目状态 每日站立会议跟踪任务进度。 迭代开始后，项目组通过每日站立会议沟通每个工作项的当前进展，并对工作项状态进行更新。 使用卡片模式能够简单直观的查看迭代中各工作项的当前状态。 进入“迭代”页面，单击图标，切换到卡片模式。页面中展示了处于每种状态下的工作项卡片，通过拖拽工作项卡片即可更新其状态。 迭代评审会议验收迭代成果。 在到达迭代的预计结束时间前，项目组召开迭代评审会议，展示当前迭代的工作成果。 “迭代”页面提供了迭代统计图表，团队可以方便的统计当前迭代的进度情况，包括需求完成情况、迭代燃尽图、工作量等。 进入“迭代”页面，单击“统计”，即可展开迭代进度视图。 仪表盘跟踪项目进展。 仪表盘提供了强大的项目进度跟进能力，包括需求进度统计、燃尽图、工作完成度、工时统计等，可随时查看项目的当前进展。 您可以使用内置的仪表盘报表卡片（详细使用方法请参考使用仪表盘），也可以根据需要自定义报表。

需求变更情况下的移动 不接受变更 当一个Sprint的Sprint Backlog和Sprint目标确认后，为了保持团队在很短的时间内，全力以赴的向着Sprint目标冲刺，一般情况下不接受PO提出的需求变更。在很短的周期内，PO是有责任负责整理好Sprint Backlog的，进一步说，PO至少应该整理好接下来1-3个Sprint需要做的Product Backlog，然后按优先级，挑选出最近一个Sprint的Product Backlog形成Sprint Backlog，因此经常性的需求变更建议团队不接受，另一方面也是一个好习惯的养成，促进PO对需求的把控能力。所以这种情况下，团队正常移动看板中的卡片就好。 拥抱变更 完全拒绝需求变更是不现实的，有的时候高优先级的需求一定要满足变更的要求。比如，有市场时效性的，本Sprint不能完成，不能抢占市场先机，但变更需要遵循“NO CHANGE”原则。接到需求变更后，首先不是直接接受或者拒绝，而是先对需求进行分析，分析对当前迭代的影响。一般分析结果为以下几种情况： 无价值需求 与PO沟通协商，对于无价值需求果断拒绝，看板中的卡片不做任何移动。至于这些无价值的需求怎么来的，情况比较多，这里不做讲解了。 变更少，影响小的需求 高优先级的，对Sprint影响小的需求变更，可以柔和接纳，但要评估工作量，做等价交换。简单说，就是把未做的优先级低的需求从看板中替换出来，移动到Product Backlog中，这也是Product Backlog Refinement的过程，然后看板中加入高优先级需求的卡片就好。如果是交换已经产生工作量的需求就需要分情况处理：一种是移回到Product Backlog列，这种情况多于以完成特性需求为目标，更符合敏捷。另外一种是移到Done列，这种情况多见于物理看板中对统计度量数据比较看中的团队，团队需要对工作量进行有效统计。第二种情况在有些电子看板中也可以灵活统计来满足团队需求，那么就可以直接移动到Product Backlog列。 变更多，影响很大的需求 高优先级的，对Sprint影响很大的需求变更，需要停止当前Sprint，重新规划新Sprint。这里的影响很大情况是指当前Sprint中的需求可能再做下去也没有价值，这时果断停止当前Sprint，另外一种情况也可能是变更的需求本身确实需要很大的工作量才能完成，也需要停止当前迭代。这时根据最新的Sprint Backlog布置看板中的卡片就好。

检查规则 用户在发起访问请求时，系统根据用户被授权的访问策略中的action进行鉴权判断。检查规则如下： 图1 请求鉴权逻辑图 用户发起访问请求。 系统在用户被授予的访问策略中，优先寻找基于 IAM 项目授权的策略，在策略中寻找请求对应的action。 如果找到匹配的Allow或者Deny的action，系统将返回对请求的鉴权决定，Allow或者Deny，鉴权结束。 如果在基于IAM项目的策略中没有找到请求对应的action，系统将继续寻找基于企业项目授权的策略，在策略中寻找请求对应的action。 如果找到匹配的Allow或者Deny的action，系统将返回对请求的鉴权决定，Allow或者Deny，鉴权结束。 如果用户不具备任何策略，系统将返回鉴权决定Deny，鉴权结束。

基本概念 账号 用户注册时的账号，账号对其所拥有的资源及云服务具有完全的访问权限，可以重置用户密码、分配用户权限等。由于账号是付费主体，为了确保账号安全，建议您不要直接使用账号进行日常管理工作，而是创建用户并使用用户进行日常管理工作。 用户 由账号在IAM中创建的用户，是云服务的使用人员，具有身份凭证（密码和访问密钥）。 在我的凭证下，您可以查看账号ID和IAM用户ID。通常在调用API的鉴权过程中，您需要用到账号、用户和密码等信息。 区域（Region） 从地理位置和网络时延维度划分，同一个Region内共享弹性计算、块存储、对象存储、VPC网络、弹性公网IP、镜像等公共服务。Region分为通用Region和专属Region，通用Region指面向公共租户提供通用云服务的Region；专属Region指只承载同一类业务或只面向特定租户提供业务服务的专用Region。 详情请参见区域和可用区。 可用区（AZ，Availability Zone） 一个可用区是一个或多个物理数据中心的集合，有独立的风火水电，AZ内逻辑上再将计算、网络、存储等资源划分成多个集群。一个Region中的多个AZ间通过高速光纤相连，以满足用户跨AZ构建高可用性系统的需求。 项目 区域默认对应一个项目，这个项目由系统预置，用来隔离物理区域间的资源（计算资源、存储资源和网络资源），以默认项目为单位进行授权，用户可以访问您账号中该区域的所有资源。如果您希望进行更加精细的权限控制，可以在区域默认的项目中创建子项目，并在子项目中创建资源，然后以子项目为单位进行授权，使得用户仅能访问特定子项目中的资源，使得资源的权限控制更加精确。 图1 项目隔离模型 同样在我的凭证下，您可以查看项目ID。 企业项目 企业项目是项目的升级版，针对企业不同项目间的资源进行分组和管理，是逻辑隔离。企业项目中可以包含多个区域的资源，且项目中的资源可以迁入迁出。 关于企业项目ID的获取及企业项目特性的详细信息，请参见《企业管理用户指南》。 父主题： 使用前必读

响应示例 状态码： 200 执行基本信息 { "data" : { "execute_uuid" : "SCT2023102211473xxxxxxxxxx", "gmt_created" : 1697946452186, "gmt_finished" : 1697946763469, "execute_costs" : 311282, "creator" : "xxxxxxxxxxxcontainer1", "status" : "CANCELED", "properties" : { "script_uuid" : "SC2023101717xxxxxxxxxxxxx", "script_name" : "xjptxxxxxxxx", "current_execute_batch_index" : 1, "execute_param" : { "resourceful" : true, "timeout" : 300, "execute_user" : "root", "success_rate" : 100, "script_params" : [ ] }, "script_source" : "CUSTOM_SCRIPT" } } }

响应参数 状态码： 200 表2 响应Body参数 参数 参数类型 描述 [数组元素] Array of JobScriptBatchListModel objects 批次列表 表3 JobScriptBatchListModel 参数 参数类型 描述 batch_index Integer 批次索引，从1开始 total_instances Integer 批次内实例节点数量 rotation_strategy String 暂停继续策略 枚举值： CONTINUE PAUSE properties String 批次标签：

错误码 错误码 状态码 错误码 错误信息 描述 处理措施 400 COC.00040601 Exist script with same name: test1111_param. 存在相同名称的脚本 修改脚本名称 400 COC.00040701 Internal server error 服务内部错误 联系客服 400 COC.00040601 The paramValue is invalid. 脚本参数错误 修改脚本参数，满足填写规范 父主题： 附录

URI GET /v1/job/script/orders/{execute_uuid}/batches/{batch_index} 表1 路径参数 参数 是否必选 参数类型 描述 batch_index 是 Integer 批次index 最小值：1 最大值：20 execute_uuid 是 String 脚本工单的执行Id，取自executeJobScript和ListJobScriptOrders返回体中 最小长度：1 最大长度：26 表2 Query参数 参数 是否必选 参数类型 描述 status 否 String 实例执行状态 READY：待执行 PRO CES SING：执行中 ABNORMAL：异常 CANCELED：已取消 FINISHED：成功 枚举值： READY PROCESSING ABNORMAL CANCELED FINISHED limit 是 Integer 分页参数：每页返回记录个数限制 最小值：1 最大值：50 marker 是 Long 分页参数：上一页最后一个记录id 最小值：0 最大值：2147483647

响应参数 状态码： 200 表3 响应Body参数 参数 参数类型 描述 batch_index Integer 批次索引，从1开始 total_instances Integer 批次内执行实例数量 execute_instances Array of ExectionInstanceModel objects 执行实例列表，分页 表4 ExectionInstanceModel 参数 参数类型 描述 id Long 主键id target_instance ResourceInstance object 目标实例 gmt_created Long 创建时间 gmt_finished Long 完成时间 execute_costs Long 耗时时间，单位:秒 status String 实例执行状态 枚举值： READY PROCESSING ABNORMAL CANCELED FINISHED ROLLBACKED message String 实例执行日志 表5 ResourceInstance 参数 参数类型 描述 resource_id String ecs对应的主机id agent_sn String agent纳管id agent_status String agent纳管状态 properties ResourceInstanceProp object 主机附加属性 表6 ResourceInstanceProp 参数 参数类型 描述 host_name String 主机名 未校验：长度 fixed_ip String 内网ip 未校验： 格式，长度 floating_ip String 弹性公网ip 未校验： 格式，长度 region_id String 区域 未校验： 长度 zone_id String 可用区 application String CMDB应用，CMDB应用视图才有值。类似管理面的云服务 group String CMDB分组，CMDB应用视图才有值。类似管理面的schema project_id String 实例的 project_id 需要消费，建议必填 未校验长度

响应示例 状态码： 200 返回结果 { "data" : { "batch_index" : 1, "total_instances" : 1, "execute_instances" : [ { "id" : 1588, "target_instance" : { "resource_id" : "resource_id", "agent_sn" : "agent_sn", "agent_status" : null, "region_id" : null, "project_id" : null, "properties" : { "host_name" : "host_name", "fixed_ip" : "x.x.x.x", "floating_ip" : null, "region_id" : "cn-north-7", "zone_id" : "cn-north-7c", "application" : null, "group" : null, "project_id" : null } }, "gmt_created" : 1697946452436, "gmt_finished" : 1697946763467, "execute_costs" : 311031, "status" : "CANCELED", "message" : "Script execution result" } ] } }

响应示例 状态码： 200 { "data" : { "total_instance" : 1, "execute_statistics" : [ { "instance_status" : "READY", "instance_count" : 0, "batch_indexes" : [ ] }, { "instance_status" : "PROCESSING", "instance_count" : 0, "batch_indexes" : [ ] }, { "instance_status" : "ABNORMAL", "instance_count" : 0, "batch_indexes" : [ ] }, { "instance_status" : "CANCELED", "instance_count" : 1, "batch_indexes" : [ 1 ] }, { "instance_status" : "FINISHED", "instance_count" : 0, "batch_indexes" : [ ] } ] } }

响应参数 状态码： 200 表2 响应Body参数 参数 参数类型 描述 total_instance Integer 实例总量 execute_statistics Array of ExectuionStatistic objects 每个状态一个count，里面记录该状态的总数量，以及包含该状态的批次列表 表3 ExectuionStatistic 参数 参数类型 描述 instance_status String 执行实例状态 instance_count Integer 该状态下执行实例个数 batch_indexes Array of integers 该状态下批次index列表

URI GET /v1/external/resources 表1 Query参数 参数 是否必选 参数类型 描述 resource_id_list 否 Array 资源id列表 provider 是 String 云服务名称 type 是 String 资源类型名称 limit 是 Integer 最大的返回数量 marker 否 String 分页参数，通过上一个请求中返回的marker信息作为输入，获取当前页

请求参数 表2 请求Body参数 参数 是否必选 参数类型 描述 batch_index 否 Integer 适用于批次操作时 最小值：1 最大值：20 instance_id 否 Long 适用于实例操作时 非script_execute_instance_do中iD，需要新增字段 最小值：1 最大值：9223372036854775807 operation_type 是 String 操作类型：取消实例、跳过批次、取消整个工单、暂停整个工单、继续整个工单 CANCEL_INSTANCE：取消实例 SKIP_BATCH：跳过批次 CANCEL_ORDER：取消整个工单 PAUSE_ORDER：暂停整个工单 CONTINUE_ORDER：继续整个工单 枚举值： CANCEL_INSTANCE SKIP_BATCH CANCEL_ORDER PAUSE_ORDER CONTINUE_ORDER

响应示例 状态码： 200 执行分页数据 { "data": { "total": 222, "data": [ { "order_id": 74, "order_name": "071201", "execute_uuid": "SCT20230724201xxxxxxxxxxxx", "gmt_created": 1690200829451, "gmt_finished": 1690200850293, "execute_costs": 20842, "creator": "xxxxxxxxxxxcontainer1", "status": "CANCELED", "properties": { "region_ids": "cn-north-7" } }, { "order_id": 73, "order_name": "071201", "execute_uuid": "SCT2023072411xxxxxxxxxxxxx", "gmt_created": 1690168434460, "gmt_finished": 1690168443277, "execute_costs": 8817, "creator": "xxxxxxxxxxxcontainer1", "status": "FINISHED", "properties": { "region_ids": "cn-north-7" } }, { "order_id": xx, "order_name": "xxx", "execute_uuid": "SCT2023072217181xxxxxxxxxx", "gmt_created": 1690017490247, "gmt_finished": null, "execute_costs": null, "creator": "xxxxxxxxxxxcontainer1", "status": "ABNORMAL", "properties": { "region_ids": "cn-north-7" } }, { "order_id": 71, "order_name": "patch_730", "execute_uuid": "SCT2023071915xxxxxxxxxxxxx", "gmt_created": 1689753553241, "gmt_finished": 1689753579363, "execute_costs": 26122, "creator": "xxxxxxxxxxxcontainer1", "status": "FINISHED", "properties": { "region_ids": "cn-north-7" } }, { "order_id": 70, "order_name": "111", "execute_uuid": "SCT2023071915xxxxxxxxxxxxx", "gmt_created": 1689751168547, "gmt_finished": null, "execute_costs": null, "creator": "xxxxxxxxxxxcontainer1", "status": "ABNORMAL", "properties": { "region_ids": "cn-north-7" } } ] } }

URI GET /v1/job/script/orders 表1 Query参数 参数 是否必选 参数类型 描述 limit 否 Integer 分页参数 最小值：1 最大值：100 marker 否 Long 分页参数 最小值：1 最大值：2147483647 start_time 否 Long 创建时间开始 最小值：1 最大值：2147483647 end_time 否 Long 创建时间结束 最小值：1 最大值：2147483647 creator 否 String 创建人 最小长度：1 最大长度：64 status 否 String 工单状态 READY：待执行 PROCESSING：执行中 ABNORMAL：异常 PAUSED：暂停 CANCELED：已取消 FINISHED：成功 枚举值： READY PROCESSING ABNORMAL PAUSED CANCELED FINISHED

响应参数 状态码： 200 表2 响应Body参数 参数 参数类型 描述 total Long 总条数 data JobScriptOrderListModel object 单页数据列表 表3 JobScriptOrderListModel 参数 参数类型 描述 order_id Long 主键id，对应job_order_do的主键 最小值：1 最大值：9223372036854775807 order_name String 工单名称 最小长度：1 最大长度：64 execute_uuid String 列表跳转到详情时，用这个uuid，对应execute_data_do的execute_uuid gmt_created Long 创建时间 gmt_finished Long 完成时间 execute_costs Long 执行耗时，单位：秒 creator String 创建人 status String 工单状态 枚举值： READY PROCESSING ABNORMAL PAUSED CANCELED FINISHED properties JobScriptOrderListProp object 标签：区域信息等 表4 JobScriptOrderListProp 参数 参数类型 描述 region_ids String CMDB服务实例区域id，可能有多个

概述 云运维中心（Cloud Operations Center，简称COC）为用户提供集中、简化、一站式的运维工作台，满足客户集中运维诉求。承载华为云确定性运维业务场景，提供变更管理、批量运维等核心特性，实现在安全合规的前提下，提升用户运维能力成熟度和云上运维效率。 COC提供以下功能： 运维 态势感知 大屏，面向不同角色运维人员的专属运维BI看板，辅助管理层洞察决策和优化改进。 资源全生命周期管理，提供资源定义、申请、发放、运维、变配&续期、回收等全生命周期管理，构筑资源管理驾驶舱。 变更风控&作业可信，融合华为SRE安全生产最佳实践的变更管控模型，助力客户作业可信和稳定可靠。 标准化故障管理，加持WarRoom作战驾驶舱，实现故障高效协同和快速恢复。 智能化混沌演练，全旅程混沌工程解决方案，颠覆传统被动运维模式，推动客户向主动运维变革。 父主题： 使用前必读

规则评估结果 当触发规则评估后，会生成相应的评估结果（PolicyState）。 使用JSON表达式来表示一个评估结果，如表1所示。 表1 规则评估结果-JSON表达式格式 参数 定义 说明 domain_id 帐号ID 用于区分用户。规则评估结果的domain_id不会为空。 resource_id 评估结果所属资源的ID - resource_name 评估结果所属资源的名称 - resource_provider 资源所属的服务 - resource_type 资源类型 - trigger_type 触发类型 包含如下值： resource period compliance_state 合规结果 包含如下值： Compliant：合规 NonCompliant：不合规 policy_assignment_id 评估结果对应合规规则的ID - policy_definition_id 评估结果对应合规策略的ID - evaluation_time 评估时间戳 - 如下JSON表示了一个不合规的评估结果： { "domain_id": "domainidforpolicy", "resource_id": "special-ecs1-with-public-ip-with-tag", "resource_name": "ecs1-with-public-ip-with-tag", "resource_provider": "ecs", "resource_type": "cloudservers", "trigger_type": "resource", "compliance_state": "NonCompliant", "policy_assignment_id": "5fa9f8a2501013093a192b07", "policy_definition_id": "5fa9f8a2501013093a192b06", "evaluation_time": 1604974757084 } 父主题： 合规规则概念详解

由周期执行触发的评估的示例事件 Config以您指定的频率（如每24小时）评估您的帐号时，它会发布一个事件。下面的示例事件演示自定义合规规则被周期执行所触发。 { "domain_id": "domain_id", "policy_assignment_id": "637c6b2e6b647c4d313d9719", "policy_assignment_name": "period-policy-assignment", "function_urn": "urn:fss:region_1:123456789:function:default:test-custom-policyassignment:latest", "trigger_type": "period", "evaluation_time": 1669098286719, "evaluation_hash": "3bf8ecaeb0864feb98639080aea5c7d9", "rule_parameter": {}, "invoking_event": { "id": "domain_id", "name": "Account", "provider": null, "type": null, "tags": null, "created": null, "updated": null, "properties": null, "ep_id": null, "project_id": null, "region_id": "global", "provisioning_state": null } }