デスマーチを振り払う理の枝を持つ技術

TOCfE Advent Calendar 2015

　この記事は「TOCfE Advent Calendar 2015」の22日目です。昨日の記事はKANDA Yuriaさんの「子育てあるあるブランチ（字が読めない子も思考する）」でした。読みました？日常の出来事に根ざしたとても分かりやすい記事ですね。オレの書く内容はIT業界という特殊な世界に閉じた内容ですが、参考にしていただければ幸いです。

はじめに

　さて、みなさま、12月も残り10日を切りましたが、いかがお過ごしでしょうか？きっと忘年会などで激動の2015年の総決算をされていたのではないかと思います。しあわせですかぁ？義務ですよ？

　ちなみに私は今月ほぼ毎日出勤してました。朝から晩まで仕事して、それでも終わらなくて土日も仕事して、通勤の時間も寝る時間も削って仕事して。ええそうです、IT業界にありふれた「炎上案件」ってやつです。ちなみにこういう案件があると「デスマーチだああああああ！！！！！」とか気が狂ったように叫ぶ輩がおりますが、デスマーチとは終わらないから「死の行軍」などと揶揄されるわけでして。オレの案件のようにまかりなりにも一ヶ月未満で収束を迎えた案件はデスマーチとは呼ばんのですよ。巷で言うデスマなんて仮初のファッションです、偉い人にはそれがわからんのですよ。甘ったれんな、目ぇくいしばれ！！！！

　というわけで、オレの体験したデスマーチにもなれない無残な失敗プロジェクトは、今日、形だけでも収束を迎えました。これからお客様へのお詫びとか色々ありますし、きっとこれからも障害は出続けるでしょう。今もって地獄への道はアスファルトで綺麗に舗装されてオレの目の前にまっすぐ伸びたままです。それでも一応収束は収束です。
　炎上案件になってしまった原因は勿論オレ自身にも多分にあります。ではなぜ案件が炎上してしまったかを、振り返って分析してみたいと思います。TOCfEには「ブランチ」という物事の因果関係を分析する為のツールが存在します。この記事では、今回オレが体験した「炎上案件」の要因のひとつを、ブランチで書いてみようと思います。

　ちなみに、オレが過去に書いた、デスマーチに関係しそうな記事は以下になります。すっげー暇だったら読んでくれるとうれしいです。読んでためになるかどうかは知らんけど。

事例

　今回、オレが担当した案件は、機器の使用期限切れを起因とした「サーバ移設」でした。要は新しいサーバに現行システムを乗っけ直すことです。なんも知らん人には超楽ちんな仕事に見えますが、同業者ならどれほどシンドイ作業かはなんとなく理解してもらえるはず。
　今回徹底したルールは「既存ソースコードには一切改修を加えないこと」、つまり問題があるとしたら、環境だけに絞り込めるようにしました。

……まあそれでも死ぬほど障害が出たわけですが。

　今回の障害のひとつに、「更新通知」がありました。移設対象のシステムは、コンテンツ情報を集約管理する、いわば基幹システムです。このシステムで情報を更新したとき、他システムに通知するのがこの機能。下流の他システムはこの更新通知の受信をトリガーにして、移設対象のシステムに情報取得にアクセスしてきます。
　この機能がまともに動かない、というのが今回の障害の中では一番デカイ問題でした。基幹システムとしてまるで役に立たなくなってしまったわけですから。

　結論から言うと、今回の機能がまともに使えなかった原因は、「画像ディレクトリが無い」ことでした。コンテンツ情報には文章や画像などがあるのですが、更新通知の処理の中では画像の存在チェックも行っています。このシステムで扱うコンテンツ情報は数万件におよぶため、画像だけでも数十万点存在し、全画像ファイルのサイズは数TBにも及びます。一方、新環境の回線速度は非常に遅く、この画像ディレクトリのコピーに数日かかってしまいました。当然、画像コピー作業は数日前から実施していましたが、当日までにコピー完了すること叶わず。新サーバ稼働時にはまだ殆ど画像コピーができていない状態となってしまいました。結果、画像ディレクトリ内の特定画像を参照できずにエラーになっていたのが、更新通知が飛ばなかった理由でした。

　ロジックをひも解くと、上記のようになります。この機能を担保するには、文章情報を取得する為のDBアクセスと、画像情報を取得する為の画像格納ディレクトリへのアクセス(パーミッションを適正に設定することも大事)の両方を担保する必要があります。

　では経緯から探ってみましょう。今回は直前で画像ディレクトリを旧環境からコピーし直さなくてはならなかったため、コピー作業が移管当日に間に合いませんでした。

　では何故、直前で画像コピーを実施する必要があったのか？
　実は事情がありました。作業当初に作成したユーザーの作成が間違っており、ユーザーのuidが旧環境のそれを踏襲していませんでした。これは作業者……つまりオレですが、Linuxのユーザー管理に関する知識が無く、「Linuxでユーザーを作る時、それ以前のユーザー情報を使うなら、uidを指定しなくてはならない」という「常識」を把握してなかったが為です。結果、画像ディレクトリのパーミッションがグシャグシャになってしまい、システムのプログラムから、移設前のようにアクセスできなくなってしまっていました。画像ディレクトリは前述のように数十万点のファイルデータがあり、これを手作業で修正するのはとても困難だったのです。そのせいで画像コピーをやり直さざるを得なかった。

　大障害に発展したその起因は「ユーザー作成ミス」という非常に些細なものだったことが、こうやって分析してみると分かります。

　防ぐ手だてを考えてみると、たとえ作業者当人に知識が無くても、作成ユーザーの仕様や、各ディレクトリのパーミッションをきちんと設定するための資料が事前に用意されていれば、もしくは、Linuxサーバに精通した開発者が作業を担当してれば、このような間抜けな自体は防げたわけです。
　プロジェクトで仕事を行う事を考えれば、資料を用意する方が進め方としては正しいと言えるでしょう。

まとめ

　プロジェクト守秘義務もあるためここではこれ以上書きませんが、今回オレが体験した案件では、このようなダメブランチがいくつもできあがりました。

　残念ながら、オレが今回関わった「炎上案件」は、もう取り返しようもありません。ですが、システムはこれからも稼働し続けますし、オレ自身もシステムエンジニアとして仕事を続けていかなくてはならない。その時、今回の教訓を深く分析し、教訓として自戒として深く心に刻むことができれば、以後似た様なことに出会っても、今回ほどヒドイ目に遭わずに済むかもしれない。

　ブランチは過去を振り返るのには向いているツールだと思います。過去は変えることができませんが、未来は変えることができる。災厄の元となる「不幸の種」を予め探り当てることができるようになれれば、もしかしたら災厄を避け、未来を変えることができるかもしれない。

　自らがシステムエンジニアとしてお客様に安心して仕事を任せてもらえるように、今後「ブランチ」を活用して「不幸の種」をいち早く見つけられる能力を身に着けたいと、今回は強く感じました。勉強代としてはずいぶん高くついたものですが、なんとかして元を取らないといけませんね。