救急車で患者がきたら、状況を救急士や患者から聞き、外と内の２面から症状を見ていきます。システム障害も、同様の事が言えます。今回は、状況と原因特定について話ます。
救急なので、あまり細かく書けないので、以下の３種類にします。
- 機能、構成がかわった
- 止まる、反応しない
- 遅い
- 不安定
【１．機能、構成が変わった】
事前に情報が提供されないと使用者からはわかりづらいものですが、システムの障害は、これが原因になる事が８割とも９割とも言われています。何も手を加えていない場合を想定するのは、２．３．４．になりますので、前日や直前に何らかの手を加えているのであれば、まず、変更部分に原因があると考えるべきでしょう。稀に、直前に手を加えておきながら、変更以外の場所で障害が発生する事があり、この場合は発見に時間がかかってしまいます。
この変更箇所も、変更部分が多ければ多いほど、調査に時間がかかります。だいたい見出す箇所は、やはり人間的なものになります。
- あまり使わないけど、重要な機能
- めったに変更しなかった箇所への変更
- 運用、エンジニアともに理解が乏しい箇所への変更
障害箇所を特定した後にいつも、思うのは、設計時や構築時に気になったり、悩んだところで発生しています。プロジェクトでは課題管理をして、リリース時に課題を潰すという工程が必ずあります。問題は、課題に書かないという人間的要素にあります。一方で書きすぎて誰も消せず工程が進まないという現象もあります。概要でも書きましたが、伝言に正解はありません。わからないからエラーにしたというのは見方を変えれば、正解です。
上記に上げた３つは、何れもやりたくないと感じるものです。あまり使わないという事は理解している人が、少ないあるいは、今はいないという事に陥ります。よく使う箇所はどうしても改造が増えます。改造が増えるという事は、よく障害が起きる事につながります。障害多発箇所は皮肉な事にドキュメントや障害管理が充足しており、障害が起きたとしても対応が早くなります。そして一番危険な事はあまり使わない機能に対して、知らず知らずに影響を与える変更を行っていた場合です。発見も遅れ、リカバリも困難なものになります。
顧客担当として何ができるか？ 顧客審査の時、『影響分析は万全か』という、チェック項目で終わってしまう事が多々あります。確かに中身の話を理解するのは厳しいものがあります。ましてや、いじる予定のなかったものなら、なおさらです。事前にできる事は検証環境の充実化でし、事が起きた後はレビューになります。検証環境は疑似である部分が少なからずでてきます。特に他のシステムの連携部分などシステム内にとどまらない箇所です。全ての検証環境を用意して、データやデータパターンを用意して連携させるには、コストがかかります。コストにかけられない場合は、最低限、検証環境と本番環境の違いとその違いに対するリスクを把握しておかなくてはなりません。リスクに対するアクションは、範囲と時間です。コスト削減で連携システムを一発で入れ替え、それが企業信用の根幹に関わるという計画はありえません。部分的に移行し、改善しながら完遂すべきでしょう。構築コストはかかってしまいますが、抱えるリスクに対し、コストを考える、時には経営層を説得する行為が必要です。後ろ向きな発言を経営層はよく思いませんので、前向きに発言するのが難しいところです。私は、改造の時、いつもしかめづらをしています。『無理です』と第一声でいってしまうと、耳を閉ざしてしまいそうなので、あまりにも不安な顔をみて、説いてくるまで、やるともやらないとも言いません。『厳しいかな？』と聞かれて、いろいろリスクの述べた上で、『やります』というように心がけています。あとで言い訳する為ではなく、ほんとにまずいと思った時に説得する為です。
事後のレビューとは、どのようなものか。基本は、理解している、または指示を出した者が、作業者から上がってきたドキュメントに対し評価、確認する行為です。ただ、最近のコスト削減で理解している者が指示を出しているかという部分が危うくなっていると感じています。最近では、作業者に気づかせる行為になってきているように思います。自信のある場所はとてもよく話ますが、自信のないところは、声が小さくなったり、読み飛ばそうとしたり、とても人間らしい行為です。当たり前の事ですが、ここが、まさに障害箇所になります。なのでレビューでは、中身より言い方を気にしています。『ちょっとまって、それってどういう事』と聞いて、すらすら答えてきたら通過しますが、『ええと』などと口ごもったら、ヒットです。なんでも、かんでも聞くことはありません、リスクの度合いによって、変わります。顧客レベルのレビュー同様で、窓口担当の自信のないところをつついて、技術者レベルまで引きづり出します。技術者をレビューの席に呼んだ時に気を付けないといけない事は、技術者が矛盾をいいだすと止まらなくなる事があります。全てを消化できない量がでてくるとお手上げになってしまいます。矛盾はあるのが当たり前と理解し、リスクや影響を見ながら、飛ばすところは飛ばす必要があります。１点、技術者が説明している中で、以前、不安だった事を思い出す事があります。この発言は重要なので、一緒に飛ばしてはいけないものです。障害は人間コミュニケーションにより埋め込まれたものです。開発当時、誰にも言えなかったという環境によるものですが、チェック項目に『コミュニケーションは十分か』と追加して終わらせるのはやめましょう、その行為自体が大きな問題です。派遣や２次、３次開発ベンダーの社員のスキルが問われるという社会的な要因が内在しています。個人の問題は理解した上で如何に解決結び付けるのかが重要です。
【２．止まる、反応しない】
１．の原因を除く事を前提としています。この事象は、ハード、ソフト、ミドルと原因の個所が広範囲になります。システム構成を概要に書いた３分類（端末、ネットワーク、サーバ）とした場合、調査は端末側から追っていく調査を行います。また、同時にサーバに対し、正常動作しているかを調査します。
端末の調査は、そのアプリの種類により異なりますが、とりあえずどの端末で起きているかを確認します。特定の端末なのか、フロア特定なのか、全社なのか。アプリの種類はたくさんありますが、代表的的なものとしては、以下になります。
- インストール型 （.exeや.cabなどからインストールするもの）
- ブラウザ型 （IEやFirefox、chromeなどを使用するもの）
インストール型は最近減ってきましたが、共有部分であるデータベース、ファイルのアップロードなどが、ネットワークを介して接続しています。なんの変更も加えていないのであれば（実際は、プログラムの自動配布がついていたりして、配布した設定ファイルやプログラムに問題ある事が一番多い）、ネットワークや、データベースなどのサーバの問題になります。また、データベースで管理している設定値が影響している場合もあります。これはログインパスワードの有効期限が過ぎていたといったものです。ネットワークの問題は、技術者が少ない為、対応に時間がかかりがちですが、まず、どこにつながるかを判断するといいです。大きく社内と社外のインターネットで分けられます。ping コマンドで確認するのが他の影響を受けなくていいでしょう。ネットワーク構成がわかっていれば、絞りやすいです。単純なところではデータベースにpingが通れば、ネットワークの問題はないと言えますが、時間がかかるとか、繋がったり切れたりする場合はネットワーク機器の可能性があります。シングル構成の場合は、OKかNGとなりやすいのでわかりやすいでしょう。冗長構成の場合は、壊れ方により切れたり繋がったりする現象が起きるなど、症状もいくつか増えてわかりづらくなります。ネットワーク機器は、トラフィック量、エラーパケット数などの監視（snmpプロトコルによるMRTGなど)を入れておくと状況を判断しやすくなります。
ブラウザ型は、javaなど端末にライブラリというプログラムを入れて使っている場合があり、まれではありますがライブラリのバージョンが変わってしまう可能性があります。また、ここも同じくネットワークの問題があります。ブラウザはとくにインストール型にくらべ、トラフィック量が大きいので、ネットワーク機器の故障以外に性能が限界に達する場合があります。大量のメールを流してしまったなど、まったくシステムに関係ないところが原因になる場合もあります。これは、インストール型でもある現象ですが、違いはエラーです。インストール型は手作りしているので、比較的わかりやすいメッセージを出すようにしていますが、ブラウザ型はブラウザで決められたメッセージ表示されます。英文でたり、業界用語に近かったりするので、わかりづらいかもしれません。また、使用しているブラウザごとに違ったりします。
サーバの調査は、まず正常性になるので、リソース(CPU,メモリ,ディスク)状況を調べます。サーバにログインすらできない場合は、ネットワークが原因か、このリソースが枯渇しているかの何れかです。リソースの枯渇は以外に多く、CPUの枯渇はログインできまないか異常に時間がかかります。メモリ枯渇も同様です。いずれも、システムが暴走している可能性があり、運よく暴走しているプログラムが停止すると解放されてログインできる場合もありますが、私の経験上、ほとんどないです。ここでのログインは端末からネットワーク越しに行うのではなくサーバのコンソールから実施する事をお勧めします。というのはリソースが枯渇するとハードが壊れる事はありませんが、中のデータが壊れている可能性があります。そして対応方法は電源断しかありません。（業界では「電プチ」とか言ったりします。私のまわりだけかもしれませんけど） 正常に動作しているサーバで電源断をするとデータを壊す可能性がありますので、念には念を入れてコンソールからのログインをお勧めします。ログインを入力し、パスワードを入力して固まるのも、メモリが枯渇している可能性が高いです。ログインするにも、少なからずメモリが必要なので、それすら確保できない状況です。これも、電プチで対応します。データが壊れる原因を簡単に説明すると、データベースなどがファイルにアクセスするとファイルの中身がメモリに展開しメモリ上で更新や削除が行われます。そしてあるタイミングでファイルを更新するのですが、ここでメモリが枯渇するとメモリの内容とファイルの内容が異なる事になります。特に複数のファイルで整合性が必要な場合はあるファイルは更新されているが、あるファイルは更新されないとエラーになります。メモリが枯渇するとファイルに更新する事すらできない為、手のうちようがありません。電プチで壊れたのではなく、すでに壊れていると理解ください。ただ、データベースでも、各ファイル内に番号を持たせ、ある番号までは生かし、それ以外は破棄するなど整合性を保つ仕組みをもっていたりします。ただ、破棄していいかという問題もあります。ディスクの枯渇はログインできないわけではないので、ログインして不要なものを削除する事になります。
【２．遅い】
この現象は、まずリソースの枯渇を疑います。リソースの枯渇には徐々に足りなくなる場合と、突然足りなくなる場合があります。徐々に足りなくなる場合は、足りなくなったと同時に止まる現象に近くなります。止まるのも、リソースを使わない機能は普通通りで、使う機能が遅い、何度も繰り返すといった限定的な現象もあります。突然足りなくなるのは、特定の操作、特定の処理で全てを使い尽くし、動いている間、機能に関わらず全体的におかしい現象になります。現象は様々なのですが、どのリソースが足りないかは把握し、対処していく事になります。徐々に足りなくなってきた場合は、ハードウェアとして現状の使用量に耐えられないという事になります。使用端末が増えてトラフィック量が超えてしまった。同時使用する利用者が増えてCPUが１００％になってしまった。機能を乗せすぎてメモリの使用量が１００％になってしまった。データ量が増えて空がなくなった。機器の増設、グレードアップはシステムによりますが、短くても数か月はかかりますので、半年前には計画したいところです。起きてしまった以上は、利用数を制限する、あまり使わないデータを削除するといった暫定処置を行い時間を稼ぐ事になります。突然足りなくなる場合の原因は、システムの改造が原因である事が多いので、元に戻すという対応があります。他にある一定の使用までは問題ないが、その線を越えた場合に暴走するような現象があります。データベースの最適化する機能では１テーブルのデータサイズにより突然、遅くなる事があります。ブラウザ型のアプリでも、ネットワーク関連はタイムアウト５分といった設定がわりと使用されているので、５分以上かかるようになると一斉にリトライを開始し始めて、トラフィック量やサーバのCPU使用率をリトライ分使う事になります。ブラウザ型では、よくボタンを何回も押さないでと明示している場合があります。これはブラウザ型特有の問題で、端末側の状況をサーバが理解できない作りになっている事が起因しています。PCでアプリが暴走すると「×」ボタンを押して止めようとすると思います。この時、止められないと「強制的にとめますか」といったポップアップがでます。何度か繰り返しやっと止まるのですが、ブラウザ型のアプリの実態は、サーバで動いています。ブラウザとは、そもそもドキュメント表示ソフトの為、サーバで動いている機能を止めてという指示ができません。PCでブラウザは閉じるので、あたかも止められたように感じるのですが、実際は、サーバで頑張って動いています。やっと、情報取得や計算が終わり、終わった結果を返そうとしたら、PCのブラウザが終了していて返せない事がわかり、終了します。ブラウザのもう一つの特性として画面に全部表示されていなくても次の操作ができたり、戻ってみたりとサーバ側の事情を考慮しないという特性があります。インターネットサーフィンする場合は、便利なのですが、逆のサーバ側の立場としてはたまってものではないという状況に陥ります。繰り返し操作はアプリでなんとか食い止めようと工夫はされていますが、完全には払拭できていません。ソーリーページを出して、機能の一部、または全部を使えないようにして、被害を広げないといった暫定処置を行った後、リソースを食い散らかす機能を特定する事になります。一時的な枯渇は、いつだれが枯渇させているのか発生箇所を特定するのに時間がかかる場合があります。また、止まったと連絡を受けて調べる時には解消されていたという事がよくあります。特定できない場合の正常性判断では、どの正常性を確認していいかわからず、関係ないところを確認し、後に大問題に発展するケースがあります。原因を特定するまで、何もしないという苦渋の判断が時には必要です。
【３．不安定】
２．のリソース枯渇であるケースも多いですが、ここでは明らかにどこかが異常になっている場合です。異常個所をシステムが自動的に補う事により、２次災害が発生します。例えば冗長構成しているネットワーク機器が壊れ、もう一台に切り替わっている場合です。冗長構成はペアとなる２台がまったく同じ設定であるという事が大前提ですが、よく設定が異なっている場合があります。設定変更を１台目だけにしていた場合です。設定が足りず、人事マスタDBサーバは大丈夫だが、人事勤怠サーバは接続できないなどといった場合です。達が悪いのはさらに人事マスタと人事勤怠はペアで使用される作りになっているが、人事勤怠のデータは使っておらず、内部ではエラーになっているが、正常に動作している。ただ、毎回人事勤怠サーバに接続しようと試みる分、遅くなる。こういった複合的な要因が不安定な状況になります。この例ではまず、１台が壊れているという事象を把握できていたかどうか。以前、分散したDBサーバの事を理解しているか。そもそも、この機能でなんで勤怠サーバに接続しにいくのか。何もかもが、おかしいと思うかもしれませんが、人は正常時はは強いのですが、異常時は弱いものです。『中澤さん、これおかしいよね』と何度も言われ続け鍛えられました。冗長構成はシステム利用に影響を与えない正常性を保つ事を目的としています。ここでは正常に切り替わったのです。まさか、設定が異なっているという前提ではありません。Ciscoというネットワーク機器のカスケード接続では１台ごとに設定する事はなく、１つの設定を複数台で管理している機能があります。ただ、これも正常性を担保する仕組みで異常はないかというと、存在します。話は戻って正常性を補おうとする分、事象の把握に時間がかかってしまう厄介な問題です。ここでも人的要素があり、概要でも述べましたが正常性はわからないという事象につながります。
開発におけるテスト仕様書のレビューで必ず引っかかるのが、異常系のテストケースがない、あるいは少ないというものです。思いつかないのは論外ですが、実際に壊さないとテストできず、時にはコードをいじってまで異常テストをする場合があります。正常系はInputデータを用意すればいいのですが、異常系は手間がかかるのと、範囲を広げすぎるとテストケース無限大になってしまう。障害試験ではポリシーが重要になります。どのレベルの障害をどこまでリカバリーするか。これはある意味正しいのですが、逆をいうとそれ以外の事は考えないというものです。この部分を理解するという事は、曖昧さを認める事になります。意味のない曖昧な部分は、どう対応してよいかわりませんが、それを考慮するにはコストが２倍必要だ、１０倍必要だと枠組みが決められれば、対応方針の路線をかえるきっかけになり、それは迅速な対応につながります。それはビジネスに関係してきますから、経営層に理解できるところまで説明できるといいのですが、難しいところです。
セキュリティという事に若干ふれます。セキュリティとは何か、システムが如何に人に左右されるかという事は、セキュリティホールがないものを作る事は現実、無理でしょう。最大のセキュリティは誰もしらないもので作る事です。windowsという主流のソフトを使うという事は、もっとも危険な事と理解すべきです。専用OSを作れば、そのOSを解析する気にはなりません。ソフトウェアの評価にパッチは適用され続けるか？というものがあります。不具合があるのはよくないので、直して欲しいのですが、ことセキュリティパッチに関しては別です。うちの製品はシェアが少ないので、パッチが提供される事はないです。実は、より安全なのかもしれません。もちろん専用OSを扱う技術者を抱えるのは高くつくことになりますので、簡単に判断できないのですが、開発コストの重視という事は、セキュリティに関係してきます。