客製軟體維運手冊怎麼寫
客製軟體已經在正式環境之後，維運手冊先寫這一班誰接聽、日誌和看板在哪、已知故障先查哪一步，以及什麼情況改找下一個人、什麼情況改走回滾。交接寫的是誰持有程式庫；回滾寫的是怎樣退回一次發布；這一頁寫的是當值的人在那兩份之前先做什麼。
目錄
維運手冊和交接、回滾分開寫
交接表回答的是上線之後誰持有系統、程式庫和權限在哪、殘餘缺陷列在哪張表。回滾計畫回答的是哪一個現象可以啟動退回、誰做決定、這一次是還原資料還是關掉功能開關。維運手冊回答的是另一件事：正式環境已經在用的時候，這一班誰接聽、日誌和看板在哪裡打開、已知故障先查哪一步、什麼情況改找下一個人、什麼情況改走已經寫好的回滾。三份可以互相指到版本。交接名單不改成值班表，回滾的觸發也不抄進每一條故障。分別見 客製軟體專案交接要準備什麼、客製軟體上線回滾怎麼寫。
上線當晚的順序仍在切換手冊。範圍要不要改，仍看變更紀錄。見 客製軟體上線切換怎麼做、客製軟體範圍變更怎麼管。交付仍走 客製軟件、網站與應用程式。手冊封面寫它自己的版本和生效日，並指到交接表、回滾計畫各自的版本。三份版本對不上，當值的人先讀手冊封面寫明的那一版，不在呼叫裡臨時拼。
這一班的主要接聽人和備援寫上名字
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 自己的寫法，留在該頁。公司若要為這套系統寫服務目標，另紙寫明數字和日期，手冊只指到那一紙在哪。那一紙還沒有，手冊不填可用度。
名字、位置、第一步和去向寫上，才把這份交給當值的人
主要接聽的人、接不上時改找的人、這一班的起迄日期、日誌和看板的位置、至少一條已知故障的第一個檢查、什麼情況找下一個人、什麼情況改走回滾，有一項空著，這份還不能交給當值的人使用。狀態寫待補手冊。交接表上的系統負責人不自動當成這一班的接聽人，除非兩欄都寫了同一個名字和生效日。
交給當值的人之前，用三件事看：這一班的兩個名字和日期是否都在、告警點得開的日誌和看板是否寫到路徑、升級和回滾是否各指到一個已經存在的條件。三件事都在，手冊才標成這一班使用的版本。版本改了，下一班開始前先讀新的那一版。上一班口頭說過的步驟，以手冊上有日期的那一條為準。