休日のお昼、私は新大久保にある「明洞タッカンマリ」にいました。
タッカンマリの素材は潔いです。
鶏一羽、にんにく、じゃがいも、ねぎ。それだけです。スパイスでごまかさず、長時間煮込むことで、鶏の旨味をまっすぐに引き出します。複雑な味付けは要りません。素材と時間だけが、あの白濁したスープをつくります。
店員さんが鳥を鋏で切り落とし、ぐつぐつと煮込みます。ちょうど良い頃合いを見計らって、そっと提供してくれます。その一連の所作に、無駄がありません。熟練した手つきと、適切なタイミング。
でもわたしのアタマのなかは、明日からの障害対応のことを考えていました。
システム障害は、予告なくやってきます。
だいたい、メンテナンス起因の不具合、想定外の利用負荷、静かに積もった技術的な負債——原因はさまざまでも、着地点は同じです。
迅速に画面をもとの動きにすること。
なかでも人事や会計に関わる基幹系は別格です。動かないと給与計算が止まります。勤怠が締まりません。業者支払いが遅れます。システムの遅延は、そのまま会社の信頼を揺るがします。
そもそも可用性とは何か！？
利用者にとって、システムは「使いたい時に使えるのが当然」です。電気や水道と同じように、そこにあることが前提条件になってます。突然使えなくなったとき、利用者は理由を問いません。ただ、早く戻ることを待っています。
だからこそ、止まったシステムはベストエフォートで戻さなければなりません。その「戻す早さ」を支える概念が可用性です。よく使われる指標が稼働率です。
稼働率は、次の式で表されます。
稼働率 ＝ MTBF ÷ （MTBF ＋ MTTR）
MTBFは平均故障間隔、MTTRは平均修復時間です。つまり、障害と障害のあいだをどれだけ長く保ち、止まったときにどれだけ早く戻すか——その両方が、この一本の式に込められています。
年間99.9%であれば許容ダウンタイムは約8.7時間、99.99%になると約53分まで縮まります。小数点以下の数字が、現場の負荷を決めます。
ちなみに、わたしの勤めてる会社では、土日祝日は原則として基幹システムの利用を停止してるので、稼働率の指標から外れます。
可用性は大きく二つの考え方で支えられています。MTBFを伸ばすのがフォールトトレランス——障害が起きても止まらない設計。MTTRを縮めるのがフォールトリカバリ——止まっても素早く戻す設計。どちらが欠けても、数字は守れません。
わたしのスマホには障害を通知するアラートが届きます。メールに書かれたログを追います。そして原因を切り分けます。
そういうことを繰り返すうちに痛感するのは、可用性とは「止まらないこと」ではなく、「止まっても戻せること」ということです。どんなシステムも、いつかは揺らぎます。問題はそこからの迅速さです。
話をタッカンマリに戻します。
システム設計もそうでしょう。余計な機能を重ねるより、基本をきちんと積み上げたほうが、障害に強く、安定します。シンプルな構成は、障害の切り分けも早いです。タッカンマリの潔い素材は、そのことをよく教えてくれます。
酸味、辛味、甘み。すべてのバランスが、差し出された時点で整っています。障害対応では、すべてを自分で判断しなければなりません。ログも、設定も、責任も。けれどここでは「最適解はこちらです」と静かに提供されます。設計がよいシステムは、利用者に迷わせません。完成されたタレは、まるでよく設計されたUIのようです。
スープにはコラーゲンが溶け込んでいます。乾いた目、荒れた肌、削られた体——それをじわりと内側から修復していきます。
このお店独自ともいえる、人気のかぼちゃチヂミは、外がサクサク、中がほんのり甘いです。強い主張はないですが、確実に場を和ませる味です。
可用性は、稼働率の数字で語られます。だが人間の可用性は、数字では測れません。
いつもの残業と花粉で顔はかなり疲れてます。乾いた目と荒れた肌。
冷えた身体を温めるのは、コールドスタンバイしているシステムに電源を入れ、機能不全の身体を蘇らせる——それに近いです。タッカンマリの白濁スープが、静かに喉を通ります。それは、人間側の回復性（レジリエンス）を高めるための、ささやかな儀式だったかもしれません。
熟練した判断と、適切なタイミング。障害対応でいえば、ベテランのインフラエンジニアが静かにコマンドを打つ、あの感じに似ています。
締めはカルグクスです。
白濁したスープに、平打ち麺が沈んでいきます。
人事も会計も、止めてはいけません。だからこそ、止まりかけた自分は戻さなければなりません。
わたしのスマホには、週末のバッチ処理の異常を知らせる通知が来てます。鍋がいい香りの湯気を放ちますが、わたしのアタマのなかは明日からの障害対応を考えてます。
