一个授权授权是一份持久性说明,明确了在没有人主动提出需求时Coroid应开展的工作:包括工作目标、覆盖的项目、每周或每月的预算上限以及终止条件。来自系统的请求——工作接收入口API、自动化流程、集成模块和监控数据——会依据现有授权予以受理;而人工提出的请求则不在此列,详见某授权涵盖哪些请求。
授权决定了可启动的工作范围。但它并不允许Coroid直接合并或部署任何内容。详见Coroid的决策范围以及仍需由你掌控的部分。
何时需要设置授权
当工作无需逐个请求即可流入Coroid,且你希望提前确定可处理的工作量时,便可编写授权:
- 通过工作接收入口API上报异常信息的错误追踪器或监控工具;
- GitHub发出的通知,或是Slack、Telegram和Jira中的消息,均可作为工作资格判定自动化流程会将其转化为请求;
- 用于传递客户反馈的支持或意见反馈工具;
- 逐个上报发现结果的扫描仪或CI任务。
若没有授权,这些请求将与其他请求同等对待:一旦符合资格,便会排入与人工请求共享的代理插槽队列,且没有独立的预算支持。警报频发的忙碌周可能会导致队列堵塞。授权则能对其进行约束:明确可涉及的项目、每周或每月的支出上限,以及同时占用的代理插槽数量。
请求的处理流程
无人提交的情况
- 错误追踪器发出的警报,会发送至工作接收入口 API 并附带相关信号。
- 通过资格审核自动化流程处理的 GitHub 工单。
- 来自客服工具的客户反馈,会通过工作接收入口 API 提交。
有人在 New Work 中提交的请求也会经过资格审核,但无需受指令约束。
资格审核
清理数据、检查当前发布版本、去重、验证、评估并路由。
受理
确保 API 路由中不存在未处理的异常。
- 项目
- 计费 API
- 预算
- 每周 100 美元及 10 个代理工时
- 指令分配槽位
- 2 个槽位中已用 1 个,4 个代理槽位中占用一半
- 同一事件是否已在任何项目中被处理?
- 评估结果是否表明该行为属于预期范畴?
- 指令分配的份额内是否有空闲槽位?
- 本周是否仍有剩余预算?
- 能否衡量成果?指令是否允许处理无法衡量成果的工作?
任务会占用一个预留槽位及本周的部分预算并被创建。
该请求会关联到正在处理的相关工作,不会创建新任务。
该行为属于预期范畴,不会创建任何任务。
每分钟会重新检查一次;一旦有槽位或预算空闲,或等待满一周后,便会予以受理。
受理之后
任务
包含规格说明、计划和代码,与普通任务无异。
验证
包括测试、质量门控、QA 和评审。
拉取请求
请求会在独立分支上针对你的分支提交。
成果合同
在其路由上收到 500 次请求后,24 小时内该事件不再出现新记录。
以图中的授权为例,该授权针对名为账单API的项目。其错误追踪器针对发票导出环节的新异常发出警报。警报规则的Webhook通过你自行搭建的小型中继,将其提交至工作接收入口API,其中会标注追踪器的问题编号作为信号指纹、受影响的路由路径,以及需达到500次请求量才能判定修复有效的暴露阈值。
- 资格判定会像处理其他请求一样执行操作:移除敏感信息和个人数据,检查当前发布版本,排查重复项,验证报告内容并评估其价值。
- 受理会定位到覆盖账单API的授权,并按顺序核查:同一问题是否已在当前项目或其他项目中被处理;评估结果是否表明该行为属于预期范畴;授权的两个插槽是否有空余;本周预算是否还有余地;以及能否对结果进行量化衡量。
- 已受理,该请求会变为带有预留插槽和本周预算份额的任务。它会走常规流程——需求定义、编码、测试、质量门控、QA和审核——最终成为pull request。
- 由人员执行合并操作。该任务的 成果约定会记录此次合并应实现的目标:即该路由路径上出现500次请求后,24小时内不再出现该问题的新事件。
若同一警报再次触发,第二个请求会被视为已解决并关联到第一个请求。若一次不良部署导致同时出现六个新问题,同一时间最多只有两个会在授权范围内处理;其余请求则延后处理,随后待授权任务的空位释放后,再逐一受理。另外两个代理空位则预留给团队在“新任务”中提交的需求。
示例授权任务
防止生产环境错误不断累积
API服务会将错误信息上报至错误追踪器,修复工作需等到相关人员有空时才会开展。
| 设置 | 数值 |
|---|---|
| 类型 | 持续进行 |
| 目标 | 确保账单API的路由中没有未处理的异常 |
| 项目 | 账单API |
| 预算 | 每周100美元及10个代理工时 |
| 受理无法衡量成果的工作 | 关闭 |
| 审核日期 | 四周后 |
请求会通过工作受理API从错误追踪器传入,每条请求都包含signal用于标识追踪器中问题编号、相关路由及请求次数的信息。每个问题最多只会生成一份工作任务,无论其触发频率有多高。每周最多产生100美元的成本。若发送的警报未附带路由信息,则会先被搁置而非立即启动,因为无法确认修复是否有效;需提供路由信息,或开启受理无法衡量成果的工作。
处理GitHub中上报的漏洞
用户在网页应用仓库中提交问题的速度,远快于人员分类处理的速度。
| 设置 | 数值 |
|---|---|
| 类型 | 持续进行 |
| 目标 | 修复网页应用中用户上报的漏洞 |
| 项目 | 网页应用 |
| 预算 | 每月200美元及30个代理工时 |
| 受理无法衡量成果的工作 | 开启 |
一个对工作进行资质审核在新的GitHub上,自动化流程会为每个问题创建文件。资质审核机制能避免重复创建问题、排除当前版本已修复的问题,还能标记无法复现的问题。由于该问题未指定路由或流量信息,其成果约定无法被衡量,因此开启了可衡量性开关;若关闭该开关,所有问题都将处于等待状态。拥有写入权限的人员发起的问题会自动启动,其余问题则需等待有人手动启动,具体规则如工作启动时。
根据客户反馈采取行动
您的支持工具会收集客户提交的报告,其中紧急报告送达工程团队的时间会有延迟。
| 设置 | 数值 |
|---|---|
| 类型 | 持续进行 |
| 目标 | 修复客户门户中客户反馈的问题 |
| 项目 | 客户门户 |
| 预算 | 每周150美元及15个工程师工时 |
| 受理无法衡量成果的工作 | 开启 |
支持工具会通过工作受理API以服务账号的形式录入每份报告。资质审核机制会过滤掉无法复现的问题,同时该授权机制会确保一周内收到的繁忙报告不会占用超过一半的工程师工时或超出既定预算。
在截止日期前完成清理工作
您使用的支付SDK将于下季度停止维护,其已弃用的调用逻辑分散在两个服务中。
| 设置 | 数值 |
|---|---|
| 类型 | 有限 |
| 目标 | 移除所有对已弃用支付SDK的调用 |
| 目标值 | 已弃用SDK调用次数最多为0 |
| 项目 | 结账、账单API |
| 预算 | 每月300美元及40个工程师工时 |
| 受理无法衡量成果的工作 | 开启 |
CI任务会为每个调用站点创建一个请求,以文件和行号作为信号指纹,这样下次运行时再次发现的调用站点就能关联到已处理该问题的任务。Coroid暂未读取目标内容:当最后一个调用被移除后,请选择完成自行操作。
当您无需授权时
- 他人请求的工作。在“新任务”中提交或导入的请求,符合条件即被受理,绝不会推迟,也不会占用授权预算。
- 日程安排与钩子后续处理。它们会直接创建任务,无需经过资格审核,因此不受授权限制。不妨给它们设定较低的优先级;详见日程安排。
- 一次性专项工作。形态明确且有终点的工作 计划而非授权。
- 重叠的授权。当多个生效中的授权覆盖同一项目时,最旧的授权决定其请求的处理方式。每个项目应仅对应一个授权。
授权的存放位置
打开Quality Control → 授权。Quality Control中的每个范围——组织默认范围及各个项目——都指向同一列表,因为授权属于组织,且由组织自行指定其涵盖的项目。打开某个项目的范围并不会过滤该列表。
所有者和管理员可创建及修改授权。成员可查看授权。代理和服务账号完全无法更改授权。
授权包含的内容
类型。 有限类授权有明确目标,达成目标后即终止,例如“将未修复的安全隐患数量降为零”。持续类授权属于维护性工作,例如“确保生产环境路由中不存在未处理的异常”;它们以审核日期而非目标作为终止依据。
目标。用一句话说明预期达成的状态。这是人们解读授权的方式;授权的受理依据是范围、预算和状态。
基准。授权所依据的衡量指标及其来源。您需指定指标名称,读数由Coroid自动采集,无需手动输入。这些读数不会出现在设置导出文件中。新建授权时会显示暂无读数。
目标。对于有限类授权:指衡量指标及代表完成状态的值。
优先级。每行一个优先级。当工作争夺资源时,优先级靠前的任务优先执行。
范围。
- 项目。授权涵盖的项目。若未勾选任何项目,则涵盖组织的所有项目,包括后续创建的项目。请勾选您指定的项目;针对单个代码库的授权应注明对应的项目。
- 领域。这些项目内的路径模式,每行一个,例如
apps/api-*/src/**。留空则表示任意位置。 - 更改类别。该指令所适用的变更类型,例如
exception_fix。 - 允许接收无法衡量成果的工作。默认关闭。当该选项关闭时,若请求的成果约定无法被 衡量,则会暂停而非启动。
预算。每个时间窗口内,Coroid 可用于该指令的预算,以美元和代理工时计,按周或按月核算。一周从周一00点开始:00;一个月则从当月第一天开始。预算会自行重新生效。
停止条件。当预算耗尽、目标达成、连续出现多次无法确定的结果,或到达指定日期时停止。
审核日期。对于正在执行的指令:相关人员更新或 终止它的日期。
偏差规则。对于正在执行的指令:基准指标的限定值。若在某时间窗口内超出该值,则会向负责人发起升级请求。
状态与版本
指令初始为草稿。发布会将其设为活跃,仅有活跃指令才允许接收工作。
| 操作 | 效果 |
|---|---|
| 暂停 / 恢复 | 暂停并重新开始接收工作。已在运行的工作会继续完成。 |
| 挂起 | 在查明原因前,暂停受理请求。 |
| 完成 | 终止已达成目标的指令。 |
| 停用 | 永久终止该指令。已停用的指令无法恢复;其版本和历史记录会保留。 |
修改已发布的指令会生成新版本。早期版本会留存,同时标注发布人和发布时间。
每次发布和状态变更都是指令中的一项决策。来源,标注操作人以及组织审计流中的相关事件(mandate.created、mandate.published、mandate.paused等等)。
指令管控哪些请求
指令适用于在 Coroid 中没有指定负责人的请求:这些请求来自工作受理 API、自动化和集成系统(如 GitHub 或 Jira 工单),以及监控系统。
人员在新任务中提交的请求,或导入的请求,不受指令约束。只要符合条件就会直接受理,不会延迟,也不会占用指令的预算。因为是人员主动发起的,代理队列会直接将其排入队列。
无人工干预的请求会匹配到最旧且处于活跃状态的指令,且该指令的项目范围包含该请求所属项目,或覆盖所有项目。没有指令匹配的请求会作为普通请求受理。
受理结果说明
受理是资格审核的最后一步。它不会调用模型,会对每个请求判定以下结果之一:
- 已受理。该工作会被创建,预留代理队列位置,若受指令约束还会预留部分指令预算。是否自动启动取决于源头设置,具体说明见 工作何时启动。
- 已解决。同一信号——即跟踪系统或监控系统中的同一问题/故障——已在组织的其他项目中被处理。该请求会关联到已有工作,不会创建新内容。
- 无需更改。资格审核判定该上报行为属于预期情况,因此不会创建任何内容。
- 延迟。该请求符合受理条件但暂不能启动:指令分配的代理队列已被占用,该时间段的预算已耗尽,或该请求的结果无法量化,而指令不允许受理此类请求。
每项决策及其原因都会记录在请求详情中。
延迟的请求
Coroid 每分钟会重新检查一次延期的请求,一旦有可用的插槽或预算,就会立即受理这些请求,且需符合当前版本的指令要求。提高该指令的预算,或者暂停占用插槽的其他指令,就能在下一次检查时释放被延期的请求。不存在可直接启动此类请求的覆盖机制。
如果请求等待的时间超过了其所属指令规定的时限——一周或一个月——或者其所属指令已不再生效,那么该请求最终将无法得到处理。
指令任务如何共享处理能力
指令任务最多可占用贵组织一半的代理插槽同时,该数值包含正在运行的任务以及已受理但尚未启动的任务。剩余的处理能力则留给用户提出的其他需求。如果您的套餐包含无限插槽,那么相同的占比规则将适用于您的月度预算。
已受理的请求在任务启动时会保留30分钟的预留名额;超过该时限后预留名额即失效:尚未创建任务的请求会重新变为延期状态,而已存在的任务则会像其他任务一样等待插槽分配。
在设置导出文件中
指令会随设置导出文件一同导出: 类型、目标、范畴、优先级、范围、预算、终止条件、审核日期以及偏差规则。项目通过稳定的密钥进行匹配,所有者则按角色对应。基准数据不会随指令导出;它们是对指令所属组织的实际测量值。带有新目标的指令会以草稿形式呈现,供相关人员发布;若某指令的目标与现有指令匹配,则会更新该指令:如果仍是草稿则更新草稿,否则发布为新版本。