前回に引き続き、内科診療について話ます。前回は、内科的診療は使わない事と述べました。なんて安易な、という思う方もいるかもしれません。ただ、障害の８割、９割は変更を加えたことにより、発生しているのも事実です。最近ではDevOps、Nonops と開発と運用の自動化、見直しという観点がでてきておりますが、この発想も、変更による障害を意識しての事です。
【変更による不具合はなぜ発生するのか】
前回も記載したように、ITでは情報の概念が全てです。では、この概念は確定的な存在かというと同じ会社が、世の中に存在しないように、概念も同じものはありません。個人、組織、トップが日々努力をして、業務改善や利益の確保を目指しているのです。また、資本主義社会という負荷価値主義ともいえる現代において、昨日は同じでも、今日も同じで良いかというと、そうではありません。設計時は確定していた概念も、社内的な要因や、社外的な法律、景気の変動により、変わっていきます。そして、当初、確定した概念もいつ変わるかわからないという前提で定義されています。
要件定義の打ち合わせの時に、「とりあえず」とか、「現時点では、これで」という言葉が、良く行きかいます。言葉では曖昧でも、設計書に起こす時は、明快な言葉になります。これを矛盾といいます。もともと矛盾のある概念を、ある断面を境に決めるのです。無理な事をしているのですが、それは人間には矛盾がありますが、システムには矛盾がない為、致し方のない事です。狭間に挟まれた設計者は、矛盾を受け入れると先に進めないので、明確なyes,noで組み立てていきます。概要の時にも述べましたが、システムは伝言ゲームという側面をもっています。曖昧さは分岐処理を1から100へと増やしていくものですが、確定されるものは、100の分岐から1へと減っていくものです。増やしすぎて、動かないか、減らしすぎておかしな事になるか、どちらを選びますか？
【治療には、どのようなものがあるか】
内科診療は、できる事なら自然治癒能力があるといいのですが、システムにはない為、悪化させない事が目的とする治療になります。そして、薬に良く似ていますが、ある分岐処理で問題があると判明した場合、今度は、その分岐処理から入力元を探します。〇〇画面の備考欄には、文字を入力するなとか、変更時の使用フラグは、常にONにするという対応です。外部インタフェースの場合、入力データの自動取り込をいったん止めて、中の値をいじってから再開させるという対応になります。ハードディスク障害であれば、ディスクを物理的に抜いたり、ネットワークケーブルを外し、サーバ毎切り離してしまうという対応です。このハードディスクの障害は結構、ありました。ハードディスクは冗長化していたのですが、コントローラとディスクの相性が悪く、ハードディスクは壊れていると判断しているのに、コントローラはまだ、大丈夫と認識してしまい、書き込みリトライが大量に発生し、サーバ自体がダウンしてしまうという現象です。
そういう意味では、プログラムでも、もともと障害時の対策がとれているのであれば、わざとエラーにして、リカバリ機能にまかせるという対応もあります。ただし、どちらも、通常行われているリカバリ機能である事が前提です。今まで、使っていなかったけど、そういう思想で作ったのだから大丈夫。この認識で、何度も失敗しました。
性能的な問題があれば、今、入力するのはやめよう。あるいは、同時接続、１００人の設定を５０人に制限しよう。残り５０人に対しては問題ではありますが、１００人全ての人が使えなくなる、あるいは、１００人使わせる事により、一時の障害が１週間、１ヶ月と復旧にかかってしまう事を考えれば、正確な状態で５０人に使ってもらうべきでしょう。障害の対策には２面性の対策を進めます。運用面で回避する事を考えるのが、顧客側で、システムに改造を加えて改善するのが、開発ベンダーでしょう。原因がわからなければ、回避ができない場合もありますので、開発ベンダーは発生箇所の特定と対策への模索を並行に進める必要はあります。
【たらればになってしまいますが】
開発段階での打ち合わせの席で、なんとなく障害箇所がわかります。そして、障害が起きたとき、やっぱりと思ったり、そういえば、あの時と思い出す事があります。曖昧さや、無理がたたる。というのは、慢性疾患に似ているのかなと思います。概念が崩れていくにつれて、どんどん危うくなり、気が付くと手のうちようがなくなる状態です。可能であれば、その時、問題がおきた時の対策が考えられていたらと、ついつい考えてしまいます。