主が落ちた日、予備も落ちていました
私たちの運用には、主の経路が失敗したときに切り替わる予備の経路があります。ある日、まさにその場面が来ました。主が失敗し、処理は予備に切り替わりました。そして、予備も落ちました。
切り替わった先が動かない。これは、いちばん避けたい形の失敗です。主が落ちただけなら、予備が受け止めてくれるはずでした。受け止める側まで壊れていたので、逃げ場がありませんでした。
予備のログを見ると、提供元から 400 のエラーが返っていました。内容は「このアカウントでは使えない」というものです。つまり、予備が頼んでいたモデルを、提供元が断るようになっていたのです。
厄介なのは、いつからそうだったのかがはっきりしないことです。予備はふだん使われません。壊れていても、何も起きないように見えていました。昨日から壊れていたのかもしれませんし、もっと前からかもしれません。私たちには、それを確かめる手がかりがありませんでした。
原因は、使われない道には誰も気づかないこと
直接の原因は、予備が頼んでいたモデルを提供元が受け付けなくなっていたことです。ただ、私たちはもう一段手前に本当の原因があると考えています。予備が壊れていても、誰にも見えない仕組みだったことです。
予備は、主が動いている限り一度も通らない道です。主が元気なあいだ、予備の不調はどこにも現れません。エラーも出ませんし、利用者から苦情が来ることもありません。画面はずっと静かなままです。
しかも、予備が要るのは主が落ちた瞬間です。いちばん困っているときです。そのときに初めて「予備も壊れていた」と分かります。気づく時点が、いちばん悪いところに固定されているわけです。
設定ファイルには、予備の行が確かにありました。だから「予備はある」と思い込んでいました。けれども、行があることと、それが動くことは別の話です。提供元の都合のように、こちらの手が届かないところで変わるものもあります。こちらが何も触っていなくても、予備は壊れます。
予備の行が設定にあることは、予備が動くことの証拠にならない。
この一文が、今回いちばん強く残った学びです。
直し方は、入れ替える前に実際に動かすこと
直す手順は単純でした。提供元が使えるとしているモデルの一覧を見て、その中から別のモデルを選びます。そして、入れ替える前に 1 回だけ実際に動かして、正常に終わることを確かめました。確認が取れてから、設定を入れ替えています。
順番を逆にしなかったのが、今回の大事なところです。設定を書き換えて「直しました」と言うのは簡単です。しかし、それでは前回と同じ状態をもう一度作っているだけかもしれません。選んだモデルが本当に通るかどうかは、動かしてみるまで分からないからです。
だから私たちは、設定を書き換えただけでは「直った」と言わないことにしました。直ったと言えるのは、実際に通って、正常に終わったのを見たあとです。小さな決まりですが、これで報告の意味がはっきりしました。
手順をまとめると、次のとおりです。
- 使えるモデルの一覧を確認し、別のモデルを選ぶ
- 入れ替える前に、1 回だけ実際に動かす
- 正常に終わったのを見てから、設定を入れ替える
防ぎ方は、予備を「ある」ではなく「動く」で見ること
直したあとで、同じことを繰り返さない方法を考えました。結論は、予備は定期的に本当に動かして確かめるべきだ、ということです。予備は「ある」ことではなく「動く」ことに意味があります。ですから、見るべきも「動くか」です。
そのためには、主を止めずに予備だけを通す道を用意しておくとよいと考えています。予備を試すたびに主を止めていては、確認そのものが負担になり、続きません。主はそのまま動かしておき、予備だけに別の入口から通せれば、元気なときでも予備の状態を見られます。
もうひとつ、予備に切り替わったこと自体を知らせるべきです。予備で無事に済んだ回は、失敗には見えません。利用者から見れば何も起きていないので、一見よい結果です。ところがそれは、主の不調まで覆い隠してしまいます。主が壊れかけているのに、予備がうまく受け止めたせいで、誰も気づかない。そういう状態が続きかねません。
予備がうまく働くほど、主の問題は見えにくくなります。この性質を知っていれば、「切り替わった」という事実は、成功の中に埋もれさせず、独立した知らせとして扱う理由が分かります。
今回の件で、私たちの見方は変わりました。予備は、置いたら終わりの保険ではありません。使われないあいだも、動くかどうかを確かめ続けるものです。静かな予備ほど疑ってかかるのが、結局は安全につながると考えています。