東証の障害の考察と、それによって学ぶべき事

今回のnoteも極めてマニアック！！興味のある人だけ読んでね！！しかもクソ長いよ！！誤字脱字はご勘弁を。
可能な限りかみ砕くけど、割と小難しいかもしれません。
情報のインプットは
https://pr.fujitsu.com/jp/news/2020/10/19-2.html
から。東証の障害について知らないあなたはGoogle先生にでも聞いてみて、どうぞ。

--------------
自分もIT業界と呼ばれる世界にいるけれど、このお仕事はだいたい以下の流れで仕事をしていく。(契約成立後から)

・デザイン(設計)
まず論理的や物理的なものを紙の上で検討していく。
基本設計と詳細設計の段階に別れていて、基本設計は主に「概念」や「大枠での動作」等の要望を定義(要件定義)した上で製品ベースでの実現方法を定義する。
例えるなら、「このお菓子は食べたときにサクサク食感と甘さと香ばしさを感じられる」という要望/要件に対して、「甘味成分を入れた焼き菓子で作ります」みたいな感じ。めっちゃおおざっぱ。
詳細設計では実際にその概念や動作を実現する上で必要な部品やその設定内容を数値やパラメータ単位で、基本設計に沿って定義していく。
これらの設計には故障やエラー発生した時の動作も含める。

・構築
設定に基づいて製品を組み立てたり、接続したり、設定したりする。
余談だが、この段階で起きるエラーはほぼほぼ100％がすっごい単純なヒューマンエラー。

・試験
お客さんの要望通りに製品が動くか？とかどこかが故障した時の動作は想定通りか？等、実際の製品やそれに準じたシミュレーターを使ってくまなく点検していく。
ここで点検するのは「設計や設定」と「製品そのもの」が対象。
設計や設定に見落としや間違いがあったり、製品そのものに欠陥や初期不良がある場合はここで発見する。

・リリース
そのまんま。試験も終わったし、製品を世の中に出す。

(大なり小なり違いはあれど)これらの過程でお仕事をしていくわけだ。が、時たま問題が起きる。
そしてその問題が起きる時というのは以下の流れで発生する。

・問題要因の発生
問題となる要因の発生した段階を指す。この段階で挙げられる要因自体は避けられる(発生そのものを抑制できる)話もあれば、避けられなかったり、そもそもそれ自体は別に悪くなかったりすることもある。
わかりやすいように一般化すると、お菓子作る過程で不良品ができちゃった。っていうのがこの段階。

・問題の混入
混入は、その問題要因が成果物の中に入り込むことを指す。
不良品のお菓子がほかの正常な製品と一緒に製造ラインに入り込む状態を指す。

・問題の流出
流出はその問題がここまでの過程でせき止められることなく流れ出る(リリースされる)こと。
不良品がそのままパッケージされて発売されちゃう状態がこの段階。
この段階まで来たからって発覚するとも限らない。(発売されても買われなければ発覚はしない。)

--------------
これらの考えや流れを理解した上で再度今回の流れを見てみよう。
(あくまで一般論に基づいた外部からの考察なので実際の所はわかりません。)

①設計段階において起きたと予想される要因や問題
・OSバージョンアップに伴うデフォルト動作(パラメータ)の変更
これ自体が問題だとは思わないが、根本原因の一つとされているし、確かに原因ではある。
問題と思わない理由として、OSバージョン変更に伴って既存のパラメーターが変更されることは往々にしてよくある。
お菓子の例で言うなら実質値上げする為に製品の数量や大きさを小さくしたりすることが該当か。
不満や不便はあるかもしれないが、目的があって変更されていることが多いのでこれ自体が問題になることは少ない。

・いずれかの段階におけるコミュニケーションミス
どちらかと言うと問題は「デフォルト動作やパラメータが変更されたにも関わらず、それが認識されていなかった」ことにある。
本来、こういった影響の甚大な変更は伝えられて然るべきところが、伝達されていなかった問題。

今回の問題ではOEM(original equipment manufacturer)が採用されている。OEMとは、今回で言えば富士通が富士通製品としてリリースしているものの、実際の開発は別の委託先が行っている状態。
お菓子で言うなら特定のブランドの名前で商品を発売してるけど、製品を製造してるのは別の会社、みたいな感じ。
この場合、実際の開発元→富士通→東証という形で伝達されるべき情報がどこかの段階で漏れたことになる。
富士通の発表を見る限りは開発元から富士通への伝達が漏れた可能性と、富士通内部での伝達が漏れた可能性が考えられる。
製造元がお菓子を小さくしたけど発売するブランドに言うのを忘れたか、発売ブランド内での内部伝達で漏れた、両方の可能性。

②-1 試験段階においての問題点
・試験観点の不足？(網羅性の問題)
OSアップグレードとかのプロジェクトにおいては、だいたい以下の観点での試験を実施する。

- リグレッション試験
回帰性試験や既存機能動作確認試験。
OSが変わったところで変わってない/変わるべきでない部分が、今まで同じ動作や品質を保たれているかを確認する観点での試験。
基本的に導入時の試験を全て行うことが望ましいが、工期や予算の都合で「変更されたり新機能が追加されたものが影響しそうな箇所」を絞り込んで実施することもある。

- 新機能、変更点確認試験
新しい機能や、バージョンアップに伴って設定を変更した箇所が想定通りの動作を行うかを点検する。

- 結合試験(E2E試験)
コレはシステムや導入するものによるけれど、例えばシステムを構成してる3つの製品のうち一つの製品を入れ替えたりバージョンアップしたりした時、システム全体が正常に稼働するかを確認する試験。
リグレッション観点と新機能観点両方を含むことが多い。(これに対した呼称として更新される製品のみで行うリグレッションや新機能試験を単体試験と言ったりする。)

今回の場合、OSバージョンアップされたとしても今まで通り動くことを期待された部分が動かなかったので、リグレッション試験が疑わしくなる。
予想される問題は
「リグレッション試験項目を作る時に今回のような障害時の動作に関するリグレッション観点が欠落/不足していた」という試験設計に端を発する問題である可能性と
「試験自体は行っていたが、試験手法に問題があり、ただしく障害時の状況、もしくはそれに準ずる状況を再現できていなかった」という試験実施時の問題である可能性がある。

・試験を誰がやったか？
OEMを使うことが少ないのでちょっと不透明なのだけど、今回の場合は試験実施するチャンスが3つある。
・製品開発元が試験する
・富士通が試験する
・東証が試験する
望ましいのは3つ全てがそれぞれ試験観点や試験項目を整理して、独自に試験をやること。なんだけどなかなかその時間が取れない場合、2もしくは1段階の試験だけで済まされる可能性がある。
望ましい試験段階(3段階)で実施されていた場合、OEM、富士通、東証らが雁首そろえて考慮漏れもしくは試験漏れ、ないしその両方を起こしていたことになる。
(ちなみに1/2段階だからって富士通や東証に責任がないとするのは大きな間違い。両者の受け入れ部隊には限度はあれども品質をそれぞれ担保する責任がある。)

③問題発生後の問題点
・復旧までの時間
復旧までに極めて長い時間がかかったのが印象的なこの問題。
今回のデフォルトパラメータ変更がなかった場合、メモリーが故障してもすぐにバックアップシステムに移行される想定だったはず(ちなみにこういう障害に伴うバックアップ系統への移行をフェイルオーバーという)。
バックアップ系統のシステムは存在していたにも関わらず復旧に相当な時間を要した。
さすがに同時に該当メモリーが故障することは考えづらいので、何らかの設計的もしくは製品的な欠陥、または制限があった可能性がある。
また、運用的な手順においても、手動でのフェイルオーバーが検討されていなかったか、手動でのフェイルオーバーができなかった可能性もある。

ただまぁこの考察は本当に一般的なシステムにおける考察であって、これだけの大規模なシステムになると一般論が通用しない可能性もある。
(例えば今回の障害により主系と副系の同期にも一部で問題が起きていて、主系と副系の間のDBに齟齬が発生して、それ関係のアラームもボカスカ出てた、とか。)

④全体的に言えそうな問題点
・レビューの問題点
レビューに何かしらの問題があったのはほぼほぼ確定。
レビューとは見直しのことで、今回の場合で言えば「設計や試験に問題なかったかな？」というのを再度確認することを言う。
このレビュー手法ってのはまぁ難しい問題で、改善しても改善しても何かしらの問題を孕むことが多い。
今回起きてそう、起きてる可能性がある問題としては
- 単純な見落とし
解説するまでもないんだけど、単純にレビューした人間が大事な所を見落とした可能性。
- レビュー観点の問題
「どういう目線でレビューするか？」という話で
1. お客さんの要件をちゃんと満たしてる？
2. そもそもこの設計って実現可能？正しい？
3. パラメータや数値は正しい？
ざっくりと言えばこれらの観点で実施すべき。
何らかの観点が欠落していた可能性がある。

- レビュー手法の問題
レビュー手法としてよく問題になるのが、「人の目に頼ったレビュー」や「本人の脳みそに頼り切ったレビュー」である。
人の目という者はいくらでも誤魔化される。例えば15桁の数値が200個記載された資料と、その数値の元になる資料とを比較し、正しい値が記載されているかを確認するとして。
それを目で見て確認する。ってなった時に一個も見落とさずに確認できる人はどのくらいいるだろうか？
これは単純な見落としではあるが、単純な問題は単純であるが故に防ぎがたい。
可能な限り機械的な比較を導入することで防ぐべきである。

また、そういった細かな話ではなく基本設計の部分におけるレビューでも、レビュー者の頭の中にある情報と比較することは好ましくなく、必ずその設計の元となった資料(要件定義書や要件書)とを比較することが重要となる。

また、それらのレビュー手法に関するルールが整備されていたか？それらのルールに従ってレビューが行われていたか？という最終確認はされていたのだろうか。

- 人的な問題
例えば設計で言えば、設計のレビュー者は設計に関わっておらず、かつ設計者と同等以上の知識や技術を有し、更に正しい情報を持った人間が実施すべきである。
設計者が設計をレビューする場合だと、作った脳みそと点検する脳みそが同じってことになるので、仮にその設計者が持つ知識や情報、観点に不足や間違いがあった場合、その不足や間違いはそのまま見過ごされてしまう。
また、設計者より知識や技術水準が低い者がレビューしても、その設計者が気付けなかった抜け漏れを気付けない可能性が高くなる。
そしてこの二つを満たしていても、レビュー対象をレビューする上で大元となる資料等の情報を正しく与えないと、正しいレビューはできない。
これらのいずれかの問題が起きていた可能性がある。

・期間や費用
既存のプロセスでプロジェクトを進行させる場合、費用や工期などのいわゆる「コスト」と「品質」は、必ずしもではないにせよトレードオフ(片方を犠牲にしないともう片方を手に出来ない状態)になる。
工期は十分に余裕を持った見積もりがなされていなかったり、費用面でも同様の見積もり不十分であった可能性がある。

○まとめると
・開示可能な情報の範囲では、どこに本当の問題があったかは断定しづらい。
・富士通が全面的に矢面に立つ文面を発表しているが、東証に責任がないともいいづらく、OEMベンダーにももちろん責任があると思われる。
・というかここから学ぶべきことはたくさんあるので、「誰が悪い」って責任の所在を追うのは少なくとも第三者がやるべきことじゃない。当事者は最終的な落とし所としての責任の所在確認は必要なれど、それは対外的にやるべきことなだけであって、防ぐ手だてはそれぞれが考えるべきである。

○学ぶべきことって？
①人間は絶対ミスをすると思った方が良い
完璧な人間は存在しない。完璧に近い人間であれどその日のコンディションというものもある。
ミスや問題の発生そのものを抑制することもとても大事だが、ミスや問題は必ず起きるものである。という意識のもと、そのミスや問題の混入や流出を防ぐ仕組みを作ることも重要である。

②見えることだけが全てじゃない
ある程度大規模なシステム設計・構築の経験もやらかしの経験もある自分だが
やはり当事者ではないので見切れない部分がある。
見切れない部分を補う為に知識やら経験を総動員したこの考察ではあるが、これもおそらく見当違いや抜け漏れがあると思う。
見えることで判断することは結構なことだが、見えない部分があること、そこには少なからず主観が介在していることを認識すべき。

③大事なのは初動とリカバリー
①と似通うのだが、ミスや問題はどうしたって起きるし、流出する。
大事なのは「ミスを起こしてしまったこと」でも「自責の念」でもなく、その初動と正しく迅速なリカバリー行動である。
これはミスを起こした本人にも周りにも言えること。
ミスをした人がヘラヘラ笑ってるだけであっても、自責の念で落ち込んでるだけであっても、「なにもしてない」点に於いては同じ。
確かに感情面では落ち込んでる場合の方が、ミスによって仕事を増やされた周りの人からすると溜飲は下がりやすいが、仕事が減るわけじゃない。
だからミスをした人が落ち込んでたりミスを気に病んでる様が見えないからといって責めるのは何の建設性もない。
また、本人にしても冷静に起きたミスと向き合って自身なり全体なりの対策を考えてアウトプットに至るまでの過程を改善しない限りミスは減らない。
迷惑かけたことを気に病んじゃう気持ちはわかるんだけど、気に病むのはあなた個人の感情であって、他人には関係がないことを自覚すべき。