【障害記録】No.2：多重明細の一つだけが不正表示

自分が体験したシステム障害を紹介してトラウマを抉り返す自虐コーナー
※特定避けるため一部脚色・変更しているが、大体ほぼ実体験。

障害No障害分類No
（自分用）発生分類
アプリ/データ/ミドル/ハード案件名個人的ヤバイ度
（５段階評価）

アプリ

多重明細の一つだけが不正表示

★☆☆☆☆

発生日時

2014年7月頃

解決日時

発生と同月中

発見者

お客さん

対応者

俺

原因者

俺ではない！（笑）

障害の詳細内容

固定で10件の明細を表示する画面がある。（10件未満ならそこまで）
この一覧に表示する各明細には、さらにそれにぶら下がる子供の明細が存在していて、
いわゆる「多重明細」構成になっている。
「親」をクリックすると、そいつにぶらさがる「子」の明細を展開して表示させるような画面だった。
すごい簡単にイメージでいうと↓みたいな感じか。
（「親１」とか「親２」とか、色のついた部分を押すと「子」の部分が消えたり出たりする）

親１

子１－１
子１－２
子１－３

親２

子２－１
子２－２

…

いわゆる「一般的な検索画面」にいく前に「おすすめ検索条件」みたいなやつを
事前に準備して提供してあげるような、平たく言うとそんな感じの画面機能だった。
「10個のお題目の中から一つを選んで、その中からさらに一つ詳細を選ぶ」
というような流れで検索条件を「選んで」、選んだ内容で検索を走らせるのである。
親の「10件」というのは内部的な制限（DBのカラムが横に10個までしかない）によるものだが、
子のほうはシステム上の共通明細上限数以外では明示的な（仕様上の）上限数は設けていなかった。
要するに、親は10件で打ち止めだが、親に紐づく子の数は親毎に違う。
といいつ、運用上、各親に紐づく子の明細数は大体5～10件程度で、多くても大体30件程度。
定常的に、1つの親にそこまで多くの子が紐づくような状態は発生しなかった。

ただあるとき、
上から７番目の「親」（便宜上これを「上７親」と呼ぶことにする）に紐づく「子」だけが10件までしか表示されていない
という問い合わせを受けた。

この問い合わせを最初に受けたとき、特に「上７親”だけ”」ってところが気になって、
一律「全ての親に紐づく子が10件までしか表示されない」ならまだしも、
「上７親”だけ”」がそうなるってことは普通に考えてありえないだろ～って思って
「んなバカなｗｗｗ単純に上７親の配下に10件までしか登録してないんだろｗｗｗｗ」
とナメたことを考えていた。
しかし調べてみると上７親には40件程の子明細が紐づいていて血の気が引く。
しかも上６親には20件・上５親には30件の子明細が紐づいていてそっちはちゃんと全件子明細が表示されている。
( ゜Д゜)

対応内容・経緯等

上の方でちらっと書いたが、
「子」のほうは”システム上の共通明細上限数で”検索結果を制限している箇所があった。
すごく簡単にいうと、
明細別に「検索結果上限数」を設定できるシステム共通部品があって、
その設定値が外だしの設定ファイルになっている。
（上限を超えたとき、内部的にException投げてエラーにするか、上限で打ち切ってアプリに返却するか、等の細かい設定もできる）
で、上７親に紐づく子明細の設定値だけが、なぜか「10」と設定されていた（他の親の設定は「100」になってた）。
このため上７親に紐づく子明細だけが10件で打ち切られていた、
というのが事の真相であった。

他の親に紐づく子は10件以上表示されていたので、これが障害であることは明白で、
言い逃れできないため修正に着手。
対応としても、共通部品の外だし設定を直せばいいだけなので、
日中直して反映させることが可能であった。
ただ「他の親は本当に全部大丈夫なんでしょうね？？」という疑いの目をかけられたのは当然であり
その辺を全てテストしてからリリース、という段階を踏んだため
若干リリースまでに日数は要してしまった。

上で書いた通り、様々な切り口で「検索」するための入り口を提供する画面機能なので、
直接的でないにせよ、ユーザの利便性を損なってしまっている。
システム上、売上に直結するような特性を持ってはいなかったので
そこまで大事にはならなかったが、
いかんせん残念な障害であった。

反省点・あとがき

正直、これの理由や背景は全くわからない。
設定の初期値は「100」であり、意図的に変えない限り「100」のままである。
仕様の取り決めも特になかったので（それもよくないのだが）、
変更する契機がプロジェクト中発生したわけでもない。
誰かが上７親の設定値だけを「100」から「10」に変えて
しかもそれを正式アプリ資産として登録して以後ずーっとそのままだったのである。
一応構成管理ツールの資産更新記録も追ったが、
初期に資産登録された段階から既に「10」であり、以後更新が入った記録がなかった。
なので、登録する人間がテキストエディタで中身を開いて確かめたときに、
タイプミスかなんかで「100」の後ろの「0」を削っちまったんだろう、
というのが内部的な調査結果の見解だった。
（そう考えるとおっかないですな～）

まあ、そうだとすると、
上７親を除く他の親の子明細数が「100」だったのは、
逆に言うと「初期値から変えてない」ことを意味しており、
明示的に「子明細数は上限100でいいですよね？」って設計時に決めた経緯もない。
そう考えるとそもそも他の親も含めて100で本当ににいいのか？って疑問はあるわけだが、
その辺質問するといろいろ面倒なことになりそうな予感があったので、聞くのをやめた。
上で話した通り、実質100あれば十分事足りるみたいなので、
この件で100にしてから問題は起きたとは聞いていない
（その後ちょっとしてこの現場を離れてしまったのでよくは知らないが…）

「外だしの設定ファイル」みたいのにアプリの仕様の主要な部分を任せて汎用化するのは
保守するうえではわかりやすくていいっちゃいいんだが、
裏を返すと簡単に変えられるため、ちょっとしたミスで全てが台無しになる可能性がある。
デリケートな部分なので普通は変更がないと考え、チェックも疎かになりがちだ。
こうした経験を経て、実装の手間はあれど、あまり汎用化に頼るのもいかがなものかと感じたのである。