定制软件事故事后检讨怎么写
定制软件出了事故之后，事后检讨写下时间线、用户看得到的影响、当时怎样把影响停下来、目前查到的原因，以及后续事项由谁在哪一天前完成。维运手册管的是这一班谁接听；回滚计划管的是怎样退回一次发布；这一页管的是事故告一段落之后留下的记录。
目录
事后检讨和维运手册、回滚分开写
维运手册回答的是正式环境已经在用的时候，这一班谁接听、日志和看板在哪、已知故障先查哪一步、什么情况改找下一个人、什么情况改走回滚。回滚计划回答的是哪一个现象可以启动退回、谁做决定、这一次是还原数据还是关掉功能开关。事后检讨回答的是另一件事：事故的影响已经停下来，或已经转成持续处理之后，时间线、用户看得到的影响、当时采取的做法、目前查到的原因、后续事项由谁负责，写在哪一份记录。三份可以互相指到同一次事故的编号。值班表不改成检讨，回滚的触发也不抄进原因里。分别见 定制软件维运手册怎么写、定制软件上线回滚怎么写。
交接表仍写谁持有代码库。变更仍看规格要不要改。见 定制软件项目交接要准备什么、定制软件范围变更怎么管。交付仍走 定制软件、网站与应用程序。检讨封面写自己的版本、事故编号，以及它存放的路径。维运手册若已写事后检讨放在哪，这一页就用那个路径，不另开一个只有当班的人知道的位置。
什么情况要写，在事故发生前先定
2026年10月27日阅读的 Google SRE：Postmortem Culture 由 John Lunney 与 Sue Lueder 撰写，Gary O'Connor 编辑。该页没有刊登日期。该页把事后检讨定义成一份书面记录，写下事故、它的影响、为了减轻或解决而采取的行动、原因，以及用来降低再次发生的可能或影响的后续行动。该页写明，撰写的目的是把事故记下来、把促成事故的原因弄清楚，并把预防行动放进工作里。该页并写明，什么情况要写，应在事故发生前定义，让每个人都知道何时需要一份检讨；除了这些条件，任何利害相关的人也可以要求为某一件事写一份。
该页列出的常见条件，是该页对 Google 的写法：用户看得到的中断或变慢超过某个限度、任何一种数据遗失、当值的人介入（包括退回发布或改导流量）、处理时间超过某个限度、监控没有发出应有的呼叫。限度本身该页没有印成一个定制项目必须采用的数字。公司自己的条件写在检讨办法的封面，注明是谁在哪一天同意的：哪一种用户看得到的现象要写、数据遗失要不要写、当值的人做了回滚或改导要不要写。封面没有日期，这一次事故仍可以由利害相关的人要求撰写，但办法本身先补上日期，不把该页的例子填进封面。
时间线按当时的记录写
2026年10月27日阅读的 Google SRE：示例事后检讨 没有刊登日期。页上的范例把日期标成 2015-10-21，服务名称是一个教学用的搜索例子。该页把时间线称作事故的「分场」，并写明可以先用事故处理记录里的时间线，再补上其他相关的条目。时间写明时区。每一条是当时发生的事：呼叫在何时进来、谁宣布这是一次事故、谁做了哪一步、影响在何时停下来、事故在何时结束。条目来自日志、看板、呼叫记录或当时留下的消息，并写出处。
范例里的分钟数、查询量和收入说法留在该页，不抄进这一次定制事故。日志里读不出来的时刻，写「日志未载明」，不补一个整数。口头回忆和日志不一致时，两条并列，并写谁在哪一天对过。时间线不改写成原因。原因放在下一节。当值同事的名字留在时间线上，因为那是谁做了哪一步。
影响写用户看得到的现象
文化那一页把影响放在检讨必须写下的项目里。范例页的注记写明，影响是对用户、收入等方面的效果。定制检讨写用户看得到的现象：哪一个功能不能用或变慢、从时间线上的哪一个时刻到哪一个时刻、哪些已经在用的角色受影响。时刻以日志或看板上读得到的为准。读不到时长，这一栏写「时长未从记录读出」，不估一个数字。
收入、赔偿或罚则若公司没有在这次事故里核过，这一栏写「未记录」。不把范例页上的收入句子改填成零或改填成一笔金额。可能识别终端用户个人的数据不放进检讨。文化那一页写明，这类数据即使在内部文件里也不放入。受影响的范围用角色、功能或笔数来写，笔数要能指回统计所在的画面，并写读取日期。
把影响停下来的做法，和目前查到的原因分开
文化那一页把「为了减轻或解决而采取的行动」和「原因」分成两件事。检讨因此分两栏。第一栏写当时怎样把影响停下来：谁在何时做了哪一步，例如切回上一版、关掉某个开关、把流量改到仍可用的环境、或先停止写入。若走的是回滚计划，这栏指到那一版计划和当次的决定人，不把触发条件重写一遍。见 定制软件上线回滚怎么写。第二栏写目前查到的原因：哪些条件合在一起才发生，已知到哪一步。
范例页的注记写明，原因是说明事故在什么情况下发生，并说用例如「五个为什么」这类做法来理解促成因素常常有帮助。那是该页的建议，不是规定定制项目必须用同一种问法。已知的每一步各写一行，并写它依据的日志或变更记录。还没有查完的部分写「尚未查完」，加上谁在哪一天前继续查。不补一句听起来完整、却没有出处的原因。文化那一页把「原因是否够深」列为复核时要看的一点。深度不够时，复核的结果是补查，不是改写一句较短的话来结案。
后续事项写负责人，并写完成日
文化那一页写明，预防行动要放进工作里，用来降低再次发生的可能或影响。范例页的后续事项表有事项、类型、负责人和追踪编号。类型在范例里包括减轻、预防、流程和其他。该页注记写明，一时想到的事项常常过大或成本过高，需要再收敛；也有风险会为了单一个问题过度加强，例如只加一则监控，而较早的测试本来就能拦下。定制检讨沿用「每一项有负责人」。完成日该页的表没有印成固定栏，由这一次自己写：谁在哪一天前做完，做完的结果放在哪里。
没有负责人，或没有完成日，这一项留在未定，不算已经排进工作。负责人不在职或当天不在，栏上预先写代理人。事项若会改规格，另开变更请求，检讨只指到变更编号。见 定制软件范围变更怎么管。事项若是改维运手册上的第一步，指到那一条条目和改订日期，不在检讨里把手册重抄一遍。追踪编号用公司已经在用的工作单或缺陷单，没有单号就写存放这项的路径。
检讨写事件经过，名字用来对时间线
文化那一页写明，事后检讨要找出促成原因，而不把个人或团队写成行为不当。一份这样写的检讨假定参与的人出于好意，并按当时手上的信息做了当时该做的事。该页写明，若检讨变成指认谁做错，人们会因为担心受罚而不把问题说出来。检讨仍写谁在何时做了哪一步，因为时间线需要这些名字。名字用来对记录，不用来写处分。处分、考绩和奖金不放进这一份。
该页并写明，把检讨从责怪转成追问「为什么当时的信息不完整或不正确」，预防才写得下去。人改不了成另一个人，系统和做法可以改，让人在设计和维护时较容易做对。检讨里若出现对人的评语，复核时改回事件和信息：当时看得到哪一份看板、哪一条手册、哪一则告警。评语删掉之后，事件和后续事项仍在。
有人复核过，这份才算写完
文化那一页写明，没有人复核的事后检讨，等于不曾存在。该页列出复核时可以看的几点：关键的事故数据有没有留下、影响有没有写全、原因是否够深、后续事项是否合适且相关修正的优先顺序是否恰当、结果有没有分享给相关的人。定制检讨用这几点当复核清单，复核人写名字和日期。复核人不是时间线上唯一的作者；作者也写名字。两栏可以是同一人，栏仍分开。
时间线、用户看得到的影响、把影响停下来的做法、目前查到的原因或「尚未查完」、后续事项的负责人和完成日，有一项空着，状态停在草稿。草稿可以继续改。复核人签名之后，检讨放进封面写明的存放处，并把存放路径写回这一次事故的编号。分享的范围写谁收到、走哪一条已经在用的管道。终端用户的个人数据不随这份检讨送出。三件事都在，才把状态改成已复核：数据和影响写齐、原因写到已知的那一步并有人继续查未完的部分、每一项后续事项都有负责人和完成日。