无需 KYC 的加密货币GPU 租赁 · 3、7 或 30 天
Capordia
语言: 简体中文
菜单
团队 / 交接

以状态、行动和负责人完成交接。

一次成功的交接能让下一位同事了解哪些任务正在运行、哪些在等待、他可以决定什么。仅提供文件链接是不够的。请准备一份简短说明,让接收方实际使用,并共同确认交接时间。目标是在人员之间实现工作的连续性,前提是访问权限和环境已准备就绪。

01

界定实际交接的责任范围

明确所涉及的项目、任务批次和时段。交接可以涵盖对某个批次的监控、对其结果的验收或导出准备。它不会自动转移业务决策权、购买新时段的权限或更改软件的权限。请指定接交工作的人、替补人员,以及超出范围事项需请示的负责人。

请将访问权限的准备与责任的移交区分开来。专门针对访问权限的指南涉及身份与权限;而在这里,请确认接收方懂得使用既定的方式,并能找到正确的信息。不要在交接单中传递密码。下单账户的标识与运维访问权限承担着不同的职能。

02

在特定时刻记录工作状态

交接说明应展示已完成的任务、进行中的任务、等待中的任务以及未解决的偏差。请注明该记录的时间、当前生效版本、最后一次变更和下一项操作。像「一切正常」这样的表述在任务一旦失败时就会过时。标识符和带时间戳的状态能让同事将说明与其实际观察到的情况进行比对。

《Site Reliability Workbook》描述了在交接开始时阅读上一班次的交接记录,以及在下一班次前准备书面交接的做法。对于您的 GPU 任务批次,请将这一原则调整为几项有用的事实:预期进展、受阻的工作、已尝试的操作以及已获通知的人员。说明应引导下一项决策,而不是变成每条消息的详尽日志。

03

编写区分观察、操作与停止的规程

运维规程(即 runbook)描述某种情况和一项获准的操作。对于每项操作,请注明其前提条件、预期效果、执行后的检查以及停止条件。将「如有需要则重启」替换为一条规则,明确所涉及的任务、核实尚无已被接受的结果,并禁止并发重启。如果规程未覆盖所观察到的情况,接收方应知道该联系谁。

所提出的表格用于组织您团队的决策;它不会在 Capordia 中创建任何权限。阈值、人员和工具都应适应具体项目。同时,请将技术上执行某条命令的能力与获准执行该操作的授权区分开:拥有可用的访问权限并不足以批准删除或新增一笔支出。

由团队补充完善的行动边界示例
情况预定操作需获得的决定
任务始终处于活动状态观察其状态和最近一次结果在任何中断之前
规程已覆盖的失败检查输出后重启所确定的任务若原因与已记录的情况不同
结果偏差将输出单独保留并通知负责人在发布或验收之前
时段临近结束准备导出并说明剩余需求在新下单之前
04

让接收方解释下一步操作

安排一次简短的结对交接。接手工作的同事打开说明,找到一项任务,并解释他接下来会做什么,以及哪些事他不会独自决定。让他指出导出目标位置和所采用的恢复状态。完全由交接人主导的演示可能会掩盖文件中仍然缺失的信息。

对于刚接触该项目的人,请通过一次有边界的实操来补充这次交接。Google SRE 关于学习的章节区分了需要掌握的资料、可请教的专家以及理解性问题。此处请在试验范围内选择一项常规操作;无需制造真实故障或停止有用的处理来评估理解程度。

05

已解决的示例:移交 128 个任务且不重复重跑

在这个虚构示例中,Camille 于 14:00 UTC 向 Noor 交接。该批次包含 128 个任务:96 个已接受、8 个进行中、24 个等待中。96 + 8 + 24 = 128 与清单一致。然而八个活动任务中有两个刚刚失败。如果交接瞬间不做核对,Noor 可能把一份已经过期的快照当作当前状态来处理。

于是 Camille 更新了记录:96 个已接受、6 个进行中、2 个已失败、24 个等待中。这两个失败属于已获授权的续接情形;Noor 核实没有已接受输出、也没有仍在运行的进程,然后将它们重新置为等待中。状态变为 96 + 6 + 26 = 128。六个活动任务继续进行。Noor 确认接手,并记下下一次检查;Camille 停止在这一范围内发起任何操作。

交接时的虚构状态
时刻已接受进行中已失败等待中
核对前968024
更新后966224
经授权重新置为等待中后966026
06

应对缺席、变更与交接结束

如果接收方无法确认交接,请启用预定的替补人员,并明确在过渡期间由谁负责。避免向多人发送消息却无人明确接收。当已有未关闭的事件时,也要一并移交已排除的假设和正在进行的操作;接手的人不应悄悄重做已经尝试过的处置。

每次变更软件基准版本时,都要更新流程,并标明哪些内容已失效。需求结束时,把已接受的导出、剩余操作和截止期限归入项目台账。3 天、7 天或 30 天的周期不会仅因同事接手工作而自动延长。如有必要进行下一次租用,那仍是一项独立的决定和独立的订单。

决策要点

交接需要一份冗长的文档吗?

不需要。一份简短的记录就足够,只要它说明范围、带日期的状态、下一步操作、授权边界和必要的联系人。详细流程仍可从该记录链接访问。最重要的是测试接收方能否复述并解释下一步。

可以仅通过口头消息交接工作吗?

口头交流有助于理解细微之处,但要留下带日期的状态记录和接续确认。这样可以区分哪些已经完成、哪些尚待完成,尤其是在交接后还有第三人介入的情况下。

当流程中缺少某项指令时该怎么办?

接收方应记录这一差异,并在执行可能改动数据或中断工作的操作前,先向预定的负责人请示。随后将这一决定连同其适用范围补充进流程。一次成功的临场发挥不会自动变成通用规则。

继续处理查看配置查看常见问题