本番障害が起こってしまった話
少し前ですが、私が携わっているシステムで本番環境障害を起こりました。
正直に言うと重大な障害ではなく、さらに言うと本番環境が本格に稼働する前に発生した障害なのですが、私自身の責任もあるので色々書いていきたいと思います。
何が起きたか？
最初に書いた通り、障害の内容は非常に軽微でシステムが止まってしまうようなものではありません。画面に表示されている一部分に色がつかないというものです。
とはいえ、あるページでは画面の1/4ほどが色無しの状態であったのですぐに気づけるはずのもの。
何が原因か？
直接原因や根本原因に分けて書いていきます。
直接原因
直接的な原因はDBへのアップデートSQLの適用です。少し分かりにくいと思うのですが、DBのデータ種類と画面側の設定値（？）を紐づける作りになっており、アップデートSQLによりデータ種類を新しく追加した時に画面側の設定値が更新されていなかったことが原因です。
さらに、画面側で設定値を紐づける箇所はハードコードされており、データ種類が更新されたらモジュールを再リリースするしかないシステムとなってしまっています。
ちなみに、私はアップデータSQLを作成し、データの確認を行った張本人です。データ更新後の本番相当データでAPIエラーなどが起きないこと等は全て確認していたのですが、カラー定義のことを失念していました。
根本原因
根本原因に関してはいくつか原因があると思っています。
PJ全体でのシステムの構成への認識不足
上記の対応を行う際に、影響範囲を正しく理解できていなかったことがまず良くないことです。（私も含めてですが…）
そもそも、運用方針などでDBデータ更新による影響は元々まとめられていないいけない気もします。
アプリケーションの作りの問題
そもそもDBデータと紐づける値がハードコードされていたのが、一番悪いところだったと思っています。本来であれば設定値もDBやプロパティに持っておくべきだったのでしょうが、何故かこのような作りになってしまっていました。
今回の件でもしかしたら仕組みを修正することになるかもしれないので、その際は全力で取り組みたいと思います。
影響調査不足
お客さんから急に来た依頼だったというのもありますが、全体として調査がずさんになってしまっていました。しっかりした影響調査やデータ更新後の確認を入念に行えていればと思います…。
仕組みで防げる？
実は直近で導入している仕組みを使えば今回の事象は防ぐことができました。それは「画面側の自動リグレッションテスト」です。画面側の自動リグレッションテストはImageDiffを使用して、画面のキャプチャを改修やデータ更新前後で比較することでデグレを検知する仕組みです。（自動リグレッションテストの詳細は別の記事にて書こうと思います）
今回の事象はこれが完成していれば防ぐことができたものでしょう。私が画面の自動リグレッションテストを作成しているところなので、全力で完成させようと思いました。
最後に
この件で私は色々考えさせられました…。開発の仕組みや運用を考慮することや影響範囲調査の重要性などなど…、システム開発には難しいことはいっぱいですね。
これを踏まえると、この経験は私にとって良いものだったのではないかとも思えます。