[0][2] = "カレンダーコンポーネント異常終了事件{3}"
あれから数日。彼がオフィスにいることは光熱費と酸素の無駄使いでしかないことは確定した。この会社で陰惨な殺人事件でも起こらない限り彼が役に立つことはないだろう。いや、今の人間関係を見る限り殺人事件が起こるとしたら犯人は私で被害者は御園になる可能性が最も高いわけだから、彼の自慢の推理能力は発揮されることなく回収されない伏線として忘れさられるだけだ。
いずれにしても。
私は再び部長に言いに行かなければいけなかった。
社長は絶対ではない。
社長だって間違えることはある。
社長が間違っているのなら、私達はそれを正さなければならない。
立ち上がれ。プロダクトと正義のために。
「部長！」
「ああ、小林君、ちょうどよかった」
「え？」
部長は電話を置いて私の方をじっと見て腕を組んだ。
ああ、この仕草は。
「仕事の依頼が来た」
やっぱり。
「どこですか？」
「銀座三丁目だ。場所はいま転送した」
その言葉と同時に私のデバイスのスクリーンに地図とルートが表示された。
「詳しくは向こうで聞いてもらいたいんだけど、システムダウンの原因を調べて欲しいということだ」
「
「わからない。とにかく突然すべてのサーバーが落ちた原因を探って欲しい。そういう依頼だ。人為的なミスも含めて調査してもらいたい」
「わかりました。出動します！」
私は重量感のあるデバイスパックを背負って、ひとり社用車に駆け込んだ。
依頼主はセルビ銀行システム株式会社。
大手金融機関のシステムを保守運用している中堅企業だった。
受付で社名を告げるとすぐにスーツ姿の男性が出てきた。彼は私の姿を見て意外だったのか少し驚いた様子だったが、身分を確認すると執務室の中へと案内してくれた。
それから少ししてエンジニア達が集まってくる。いずれもスーツ姿だった。
エンジニアの間に混乱している様子は見られなかった。緊急性はないのかもしれない。
「弊社の『バグ解消サービス』にご契約いただきありがとうございます。担当エンジニアの小林望です」
私達の会社では通常の業務の他に、難解なバグの原因調査を広く請け負っている。一向に復旧できないサーバー、仕様がわからず無限にバグを産みだし続けるコード。そういったものを安くはない値段で請け負って解消まで持っていく。それが私達の会社のサービスだった。
「デバイスに書類をお送りしましたので必要事項の記入とタップをお願いします。その間に現象をお伺いします」
若手エンジニアのリーダーらしき男が窓際の席を指差した。
「それでは向こうに座席が空いてますのであちらで……」
「床でも良いですか？」
「え？ 床ですか？ はあ……まあ……」
「失礼します」
私はいつもの通り床に座り込むとデバイスパックから六枚のモニターと筐体を取り出しケーブルの接続を進めていく。最近は無線で接続できる機種がほとんどだが、信頼性の面ではまだまだ有線に分がある。
「電源もらえますか？」
「あ、これです」
「発生当時のログを見れるアカウントとアプリケーション全体のソースコードを用意してください。すぐに調査しますので」
「わ、わかりました」
そう言うと、男は周りに手早く指示していく。
「それでは具体的な内容を聞かせてもらえますか」
「は、はい。問題が起こったのは今月の一日の朝です」
「一日だけ？ それからは起こっていないんですか？」
「はい。その通りです。――それで再現に手間取っているというところで……」
七月一日の朝、か。愛用の紙製のノートにペンで現象を書き留めていく。
「それでなにが起こったんですか？」
「銀行の開始に合わせて入出金の怪しい動きをチェックする監視処理があるんですが、朝九時頃、稼働している五インスタンスがすべて一つ残らず落ちてしまったんです。その――お恥ずかしい話ですがそれほど安定しているシステムではないので、一つ程度はたまに落ちることはあるんですが……。さすがにすべて同時に落ちるというのは」
「ログは当然出していますよね？」
「もちろん問題があったらログを出すようにしているんですが、この事象に限っては参考になるログは全然出ていなくて……」
「ログはどういうものですか？」
「現象が起こった時分秒と、ログレベル、スタックトレースなどが出る一般的なものです。出したかった情報があったので、一部独自実装になってますが」
「それ以前にこの問題が起こったことはありますか？」
「いえ……」
そう言いながら男は周りの顔を見回したが、誰も彼も首を横に振るだけだった。
「記憶の限りではありません。少なくともここ数年は」
「監視プロセス以外にその日だけ動いているバッチとかなかったんですか？ 例えばデータを補正するバッチとか半期に一度だけ動く処理とか……」
「ありません」
その後、私はプロセスが使用しているアカウントの状況やディスク容量などを確認したが、どれも可能性としては低いと言うことだった。
（たぶん、これは簡単な問題だ）
私は心の中でそう思った。
「め、メモしてきました！」
リーダーの指示を受けたエンジニア達が戻ってきた。メモに従ってソースコードを転送しつつ、その日のログ出力を確認していく。時刻はすべて日本時間で記録されているようだった。
07/01 08:59:50 [Info] 監視シーケンス開始
07/01 08:59:59 [Info] 監視開始
07/01 09:27:12 [Info] システム起動
「この七月一日の九時半ごろのログは？」
「顧客からシステムが起動してないのではないかという問い合わせがあって、あわてて起動したんです……」
「普段と違う時刻に起動して大丈夫だったんですか？」
「いえ……大丈夫じゃなかったんですが、それは」
「すみません。本件には関係ありませんね」
彼の青ざめた顔を見ると、監視処理の障害と復旧時に起こした問題、この二つによって顧客からの激しいクレームに繋がり、下手をすると取引を切られる間際まで来ているのかもしれない。この状態でまた同じ問題が発生したら損害賠償にまで発展する、だからこそ私達に頼るしかなかったんだろう。
それはともかく、ログを見る限りでは七月一日の日本時間九時を超えようとした瞬間にシステムが落ちたということは推測できた。
「このコードの場所を教えてもらえますか？」
私はログの一行を指差した。
「あ、監視開始後の処理ですね？ 確かにそこでサーバーが落ちてますから、私達も念入りに調べました。この後は入出金のデータを受け取って、一定の条件に引っかかるかどうかをチェックしているのですが、そのコードは」
「いえ、ログ出力そのものの処理です」
そう言うと彼は目をぱちくりさせてそして
「ログを出力しているのはこの関数ですが……。大したことはしてないですよ。ログ種別と時刻とログ用のテキストを受け取ってバリデーションして出力しているだけです」
「関数の内部でシステムから現在時刻を取るのではなく、時刻を引数で……しかも文字列で受け取ってますね。この理由は？」
「それを作った当時はいなかったので私も詳しくないんですけど……恐らく外から時刻を与えたいケースがあったんだと思います。でもちゃんと時刻もバリデーションして変な時刻が入らないようにはなっているので大丈夫だと思います」
見てみると、時刻をパースして、時の部分に0～23、分の部分に0～59、秒の場合に0～59が入らない場合、例外を生起するようになっていた。
「昔、引数の順番を間違えて時刻とエラーメッセージが逆に出ているケースがあったので、開発時に気づけるように例外を出すようにしているみたいです」
「なるほど。だいたいわかりました」
「よろしくお願いします」
私は彼の目を見て言った。
「いえ、原因がわかりました」
新規登録で充実の読書を
- マイページ
- 読書の状況から作品を自動で分類して簡単に管理できる
- 小説の未読話数がひと目でわかり前回の続きから読める
- フォローしたユーザーの活動を追える
- 通知
- 小説の更新や作者の新作の情報を受け取れる
- 閲覧履歴
- 以前読んだ小説が一覧で見つけやすい
アカウントをお持ちの方はログイン
ビューワー設定
文字サイズ
背景色
フォント
組み方向
機能をオンにすると、画面の下部をタップする度に自動的にスクロールして読み進められます。
応援すると応援コメントも書けます