【CJ 上級編 続編 14/30 · 通算第42編】

プログラムが最も犯しやすい間違いは、答えのない状態を無理に「失敗」か「成功」に分類することです。

リクエストがタイムアウトしても、注文が約定していないとは限りません。インターフェースが異常を返しても、ポジションがすでに解消されたとは限りません。このときシステムが失敗として再試行すれば、注文を重複して出す可能性があります。一方、成功として処理を続ければ、対処が必要なエクスポージャーを見落とすかもしれません。未知の状態が危険なのは、プログラムに事実を把握しているふりをさせてしまうからです。

より堅実な方法は、未知を一つの正式な状態として扱うことです。関連する操作を一時停止し、リクエストの識別情報と時刻を保持したうえで、独立した照会によって実際の結果を確認し、再開するか、取り消すか、あるいは人の介入を求めるかを判断します。確認を待つ時間も監視対象にすべきで、いつまでも保留にしてはいけません。

結果を照会できても、元のリクエストの識別情報を無視してはいけません。まず照会結果がどの注文に対応するのかを確認し、それから残りの処理を行うことで、よく似た別の注文を答えと取り違えずに済みます。処理を再開する根拠は、確認済みの事実でなければならず、長く待った末の推測であってはいけません。

取引システムから未知の状態をすべてなくすことはできません。しかし、未知のままリスクを拡大し続けるのは防げます。「わからない」と認めることが、最もプロフェッショナルな自動化の判断となる場合もあります。

次回：部分約定は、ひとつのヘッジを二種類のリスクに分けてしまいがちです。

#状态机 #システム信頼性