你可以信賴嘅運行
到嗰陣就人人留意到。呢一頁嘅四個機制之所以存在，係因為呢類軟件嘅失敗永遠都係同樣四種，而佢哋全部都可以靠設計避免，唔使靠小心。
將一條真實記錄推入一個已關閉嘅工作流程，然後讀返究竟會發生乜：行咗邊條路、每一步嘅每一個值、每個訊息嘅用字，同埋會發畀每個外部系統嘅請求。
乜都唔會離開呢度。唔會發電郵、唔會開發票、唔會嘗試收費、唔會寫入任何一行。外部調用會以「意向」形式記錄，連同本來會發送嘅資料，咁你就可以喺佢變成某個人嘅麻煩之前，睇清楚映射啱唔啱。
模擬就係你回答嗰個令人唔敢開啟自動化嘅問題嘅方法：佢實際上會做啲乜？
POST 去開發票系統。Payload 全文顯示。送出：乜都冇收費：乜都冇
發佈工作流嘅改動唔會影響已經喺入面行緊嘅 run。每個 run 都鎖定喺佢開始嗰個版本，行完嗰個版本為止，無論要幾耐、無論你中途改幾多嘢。
所以你可以喺一萬個人行到一半嘅時候重組工作流，而每一個人都會完成佢當初承諾咗嗰個流程。另一種做法 — 入場嗰刻就將成條下游路徑實體化 — 就係喺大部分工具入面改一個運行緊嘅自動化會覺得好危險嘅原因。喺呢度呢樣嘢冇乜特別。
新嘅 run 由你發佈嗰一刻開始就用新版本。每個 run 用緊邊個版本會寫喺 run 上面，所以九月問三月嘅行為都有答案。
每個 run 都記錄咗版本舊版本保留
一步係輸入嘅純函數，佢嘅效果同 run 自己推進到下一步一齊提交。唔會出現訊息已經發咗出去但 run 唔知嘅空窗。
呢個就係成個竅門，而且係結構性質而唔係承諾。一個 worker 喺一步中途被殺 — 部署、當機、一部消失嘅機器 — run 會留喺原處。另一個 worker 接手重行嗰步。因為效果同推進係一齊提交，要麼兩樣都發生咗，要麼兩樣都冇。
對支援冪等鍵嘅系統發出嘅外部請求會帶一個，由 run 同步衍生出嚟，等對方都認得重複嘅請求。
效果同推進一齊提交每個 run 同每步一個冪等鍵
每個 run、每一步、行咗邊條分支、決定嗰下嘅數值。每步嘅時間。每個外部請求嘅 request 同 response，憑證已遮走。個 run 用緊嘅版本。個 run 等緊邊度、等到幾時。
有人問十四號落嗰張單點樣，就有答案，而且搵到只需一分鐘，唔使花成個晏晝對三個系統嘅日誌。
失敗嘅執行會集中喺一個地方,原因會歸埋一組,所以「一夜四十一宗失敗」會變成「一個供應商回傳 503 九分鐘」,而唔係四十一宗要分開查嘅個案。
503。憑證已遮蔽版本已記錄
我哋唔會喺宣傳頁面度發布在線率數字,因為一個冇量度時段、冇「在線」定義嘅數字只係裝飾。如果你合約上需要,開聲啦,我哋會傾下實際可以承諾啲乜。
我哋亦都冇辦法令到人哋嘅 API 變得可靠。如果供應商死咗,依賴佢嘅工作流程會等、會重試,最後停低並講清楚原因。我哋可以承諾嘅係:失敗會看得見、唔會整爛任何嘢,而且恢復嗰陣唔會將條訊息再發一次。
關於等待:一個等咗兩日嘅執行,係執行上面嘅一個 wake_at,唔係排隊入面坐緊嘅工作。所以一個工作流程可以喺三星期嘅等待期間容納十萬個執行而完全唔使錢,亦都所以而家等緊嘅執行數量你根本唔使理。
