定制软件维运手册怎么写
定制软件已经在正式环境之后，维运手册先写这一班谁接听、日志和看板在哪、已知故障先查哪一步，以及什么情况改找下一个人、什么情况改走回滚。交接写的是谁持有代码库；回滚写的是怎样退回一次发布；这一页写的是当值的人在那两份之前先做什么。
目录
维运手册和交接、回滚分开写
交接表回答的是上线之后谁持有系统、代码库和权限在哪、残余缺陷列在哪张表。回滚计划回答的是哪一个现象可以启动退回、谁做决定、这一次是还原数据还是关掉功能开关。维运手册回答的是另一件事：正式环境已经在用的时候，这一班谁接听、日志和看板在哪里打开、已知故障先查哪一步、什么情况改找下一个人、什么情况改走已经写好的回滚。三份可以互相指到版本。交接名单不改成值班表，回滚的触发也不抄进每一条故障。分别见 定制软件项目交接要准备什么、定制软件上线回滚怎么写。
上线当晚的顺序仍在切换手册。范围要不要改，仍看变更记录。见 定制软件上线切换怎么做、定制软件范围变更怎么管。交付仍走 定制软件、网站与应用程序。手册封面写它自己的版本和生效日，并指到交接表、回滚计划各自的版本。三份版本对不上，当值的人先读手册封面写明的那一版，不在呼叫里临时拼。
这一班的主要接听人和备援写上名字
2026年10月26日阅读的 Google SRE：Being On-Call 由 Andrea Spadaccini 撰写、Kavita Guliani 编辑。该页没有刊登日期。页末注记写明，较早的版本曾刊于 ;login:，2015年10月，第40卷第5期。该页把值班写成在工作时间和非工作时间都能接听。呼叫收到并确认之后，当值的人分诊并着手处理，必要时找其他人，并升级。许多团队同时有主要和备援：有的把备援写成主要没接上时的下一个人，有的让主要只处理呼叫、备援处理不紧急的正式环境工作。相关的两个团队也可以互为备援。
手册因此为一个写明起讫的时段填两个名字：这一班主要接听的人，以及接不上时改找的人。两栏可以是同一个人兼任，栏仍分开。只写「工程组」，下一通呼叫就不知道打给谁。人当天不在，时段上预先写代理人。班次开始，当值的人先读上一班留下的记录；班次结束，把还没做完的事写给下一班，并写日期。2026年10月26日阅读的 Google SRE：On-Call 把这种交接写成一个团队在开始值班前复核过的做法：班次开始先读上一班的交接，先把对用户的影响压下来，班次结束再写给下一班。该页没有刊登日期。作者列为 Ollie Cook、Sara Smollett、Andrea Spadaccini、Cara Donnelly、Jian Ma、Garrett Plasky（Evernote），并有 Stephen Thorne 与 Jessie Yang。那是该章里一个团队的例子。定制手册沿用「开始先读、结束写给下一班」，邮件格式由公司自己定，并注明日期。
响应时间用公司自己写下的窗口
Being On-Call 那一页写明，当值的人按团队和业务负责人已经同意的响应时间，在正式环境上动手。该页接着给出 Google 自己的响应时间、可用度例子、工程时间所占比例、值班人数和每班事故上限。那些是该页对 Google 的写法。定制手册把公司自己的窗口写在封面：这一班适用哪一个时段、呼叫之后多久内要有人确认、这个窗口是谁在哪一天同意的。窗口没有日期，不把该页的例子填进去。
同一页写明，最重要的值班资源是清楚的升级路径、写明的事故处理步骤，以及事后检讨看事件而不是看人。手册把这三项放在固定位置：升级路径见后文、事故里先做哪一步见故障条目、事后检讨另表存放并写存放路径。该页没有要求定制项目设置专职编制，也没有写必须有第二个机房。封面只写公司自己的窗口和同意日期。Google 的例子留在该页，要对照时打开那一页。
日志和看板写在告警点得开的位置
On-Call 那一章写明，呼叫要连到相关的监控画面，画面标出系统哪里越出既定范围，并把告警和图放在一起看。手册为每一类告警写三样：日志在哪一个路径或哪一个查询、看板在哪一个画面、这一班的人用哪个已经核发的账号打得开。路径写到打开之后就是这套系统的正式环境。产品名称留在公司已经在用的那一套。这篇不比较哪一家看板较完整。
账号打不开该路径，这一条不算已写上。权限沿用交接表里已经交给当值的人的那一组，不在故障当中共用别人的登录。交接表怎样写代码库和权限在哪，见 定制软件项目交接要准备什么。看板若要对回一次发布，版本号用回滚计划和切换手册已经写下的那一个。画面打得开、却对不上这次发布的版本，条目里写明看的是哪一个环境。
已知故障写第一个检查
On-Call 那一章把 playbook 写成对自动告警的高层说明：严重程度、影响、排查建议，以及可以怎样缓解、怎样做完。该章写明，建立一则告警时，通常同时建立对应的条目；并写明这些条目用来降低当值时的压力、缩短修复时间、减少人为出错。那是该章的说法。手册把每一种已知故障写成一条：这则告警叫什么、影响的是哪一种用户能看到的现象、第一个检查是打开哪一个日志或哪一张图、做完这一步之后现象应有什么变化。第一个检查写成旁人打得开的位置。
条目和正式环境一起旧。该章写明，条目过时的速度和正式环境的变更一样；每天发布时，任何一天都可能要改。当班发现步骤和现场不符，由当班的人改这一条，写上日期和改了哪一句。改条目不改回滚的触发，触发仍在回滚计划。该章也写明，若一条只是每次告警都要照跑的命令清单，就做成自动执行，而不是把清单再加长。固定命令因此写成自动执行的名称、谁可以启动、失败时第一个检查是什么。名称还没有，这一格写「尚未自动化」，并写谁负责把它做成自动执行。
什么情况改找下一个人，什么情况改走回滚
Being On-Call 写明，事情复杂到要两个以上的团队一起处理，或查了一段之后仍无法估计这件事还要多久，就适合改用写明的事故处理。手册把这一句落到名字上：第一个检查做完，现象仍在，而且要另一个团队才能继续，或仍写不出大概还要多久，就通知时段上的下一个人，并写通知时间。下一个人的名字在时段上已经有了，不在呼叫当下现编。
回滚是另一条。回滚计划上已经写成可以启动的现象对上了，当值的人改走那一页：谁宣布退回、这一次是还原数据还是关掉功能开关、决定之后通知谁。手册只指到那一版计划。见 定制软件上线回滚怎么写。现象对不上回滚，也还没到要找下一个人的条件，就留在这一条的第一个检查，并在交接里写还没做完。口头上的「好像不稳」不写成升级，也不写成回滚。
呼叫留给接了就能做第一步的告警
Being On-Call 写明，呼叫类告警应对齐会威胁服务目标的现象，而且每一则都要是接到之后可以动手的。低优先、每隔不久就响、却没有对应动作的告警，会让当值的人把真正要处理的也一并看轻。同一页写明，一个异常不应拆成多则互相重复的呼叫；重复的先合并，让当值的人处理的是这一件事。
手册因此只为有第一个检查的现象保留呼叫。没有对应条目的告警，不送进这一班的呼叫，先改成白天有人看的记录，并写谁负责补条目。该页举的服务目标和每班呼叫上限是 Google 自己的写法，留在该页。公司若要为这套系统写服务目标，另纸写明数字和日期，手册只指到那一纸在哪。那一纸还没有，手册不填可用度。
名字、位置、第一步和去向写上，才把这份交给当值的人
主要接听的人、接不上时改找的人、这一班的起讫日期、日志和看板的位置、至少一条已知故障的第一个检查、什么情况找下一个人、什么情况改走回滚，有一项空着，这份还不能交给当值的人使用。状态写待补手册。交接表上的系统负责人不自动当成这一班的接听人，除非两栏都写了同一个名字和生效日。
交给当值的人之前，用三件事看：这一班的两个名字和日期是否都在、告警点得开的日志和看板是否写到路径、升级和回滚是否各指到一个已经存在的条件。三件事都在，手册才标成这一班使用的版本。版本改了，下一班开始前先读新的那一版。上一班口头说过的步骤，以手册上有日期的那一条为准。