寓話
宿がメニューを替えるとき、食事中の客を追い出さなかった
宿は毎日多くの客を迎える。厨房には固定メニュー、火加減、提供順があり、店主が過去にメニューを変えると、半日休業して看板を貼り替えねばならなかった。
商売が大きくなると、休業の代償はますます高くなる。料理名を一つ変える、割引を一つ替える、忌避ルールを一つ調整するだけでも、店全体を待たせてしまう。店員はまず厨房の奥で口頭で新規則を密かに伝えた。その結果、前厅はまだ旧メニュー、厨房はすでに新メニューで調理し、会計はまた第三の価格で締めた。
ある時、アレルギーのある客が危うく間違った料理を食べそうになった。店主は気づいた。問題は変更できないことではなく、変更が一貫して制御可能な形で稼働中の店に入らないことだと。彼はメニューをホットスワップする仕組みを設計した。新しいルールはまず形式とリスクを検査し、それから厨房に試験投入される。通過すれば一卓ずつ適用され、失敗すれば即座に旧メニューへ戻せる。
食事中の客は中断されない。新しく来た注文は新しいメニューを使い、既に注文した料理は元の規則で完成させ、すべての切り替えにはバージョン記録がある。後に、宿はプロンプト、ツール設定、ルーティング規則、マシンバージョンを素早く調整でき、毎回店全体を再起動する必要がなくなった。
店主は急いで再び口頭命令を出すことはしなかった。彼は経理係にまずメニュー切り替え用の木札を作らせ、どの卓には旧ルールを、どの卓には新ルールを適用するか、誰が承認するか、いつ撤回するかを明確に書かせた。
翌日、彼らは窓際の三卓だけで試行した。料理人はある料理が炉口を詰まらせることに気づき、木札を旧面に戻し、前厅は接待を続け、客は提供が少し遅くなっただけだと感じた。何度か繰り返すうちに、店員たちは変更を店に来た新しい客のように扱うことを学び、宿屋全体を壊して建て直すのではないとわかった。小さな変更は入ってこられ、見られ、撤回もできる。
この小さな事故で人々は立ち止まり振り返った。彼らは急いでより耳障りのよい言い方に変えるのではなく、誤った入口、誤解されたルール、保持すべき境界を一つずつ書き出した。後に同様の状況に再び遭遇すると、まず現場の制約と失敗の痕跡を見てから、緩めるべきか、厳しくするべきか、別のやり方に変えるべきかを決めた。
店主は、稼働中のシステムには制御可能な変更能力が必要だと理解した。ホットロードの価値は、小さく頻繁な更新をサービス中断や状態混乱に変えないことにある。