~ エンデベッドシステム開発経験を回顧する ~
後処理は果てしなく続くのである
旧モジュールでの安定稼働を見守る。
時刻は14時を過ぎていた。
「食事に行こう。」
2次請負企業のプロジェクト責任補佐に声を掛けられた。
システムは復旧した。
だが1年前の状態に戻しただけである。
これからもう1度、最新の状態にしなければ終わらない。
最新モジュールを再度リリースする。
この過程がどれほど大変か。。。
ビルを出て近くの牛丼屋に入る。
「すみませんでした。」
謝る俺に補佐はこう言った。
「起きてしまったものは仕方ないさ。今できることをやろう。」
急いで牛丼を掻き込み、足早にビルに戻る。
ビルに戻ると事象の原因について議論されていた。
今回の事象の発生原因が判明したのだ。
原因を要約すると以下となる。
システムは起動時にサーバーから制御情報を受け取っている。
切り替え当日以降、制御情報に新機能のサービスのON/OFFの指示が追加で設定されることになっていた。
そして、システムのメイン機能はその情報を使用しない。
使用しないのだがメモリへの格納を許容することにしたのだ。
これが問題だった。
実はその格納していた値を見ている機能がいたのだ。
それがメイン機能の一機能である媒体管理機能だった。
媒体管理機能は制御値ゼロを期待していたが、サービスONが設定された結果、期待値ではなくなり、制御不能となったのだ。
そもそもメモリの参照など機能改修時の最も考慮すべき点。
なぜ見落としていたのか?
それは問題となった媒体管理機能が変数参照ではなく、キャストによるメモリ参照をしており、設計担当者は参照されないことに気付かなかったのである。
(これはこの後もう少し掘り下げて書いていこうと思う。)
これで原因は特定された。
この後何をするのか。
目に見える影響はあった。それ以外に影響はないのか?
同じような間違いをしている箇所はないのか?
被害を受けたユーザーはどれほどいたのか?
どう改修するのか?
幾つも挙げられる課題に対し、チーム編成され、課題に取り掛かる。
時間が過ぎていった。
旧モジュールに切り替えて以降、問題は発生しなかった。
終電が近づく。
「君はもう帰りなさい。」
2次請負企業のプロジェクト責任補佐に声をかけられ、帰宅することとなった。
夜勤として出社してからの稼働時間は26時間になろうとしていた。
これは個人的体験談を元にした回顧録です。企業名、人名などは架空の名称です。
毎週日曜日更新。
随時、加筆、修正を行います。
投稿日 | 2022.03.27 | 更新日 | 0000.00.00 |