負荷は負荷をよぶ。
経験上そうであるし、人間の心理学的にもそれが言えるのではないでしょうか。
何か重い、おかしいと感じるとそれが何なのかを確かめたいが為に、サイトにアクセスするでしょうしそこからくるストレスから、繰り返しアクセスを試みようとする心理は働きやすいものだと思います。
「現在トラブル中です」
「あっ。そうですか・・・。またきます・・・」
等といって素直に立ち去ってくれる人は少ないでしょう。
それを理解していても、「もうそろそろ直ったかな・・・？」といっては5分も経たない内に再度アクセスしてみたり。
利用者が多ければ多いほど、その間隔に押し寄せるアクセス数も爆発的に増加する事になります。
平時であれば、サイトを開いておくだけとか何かを読んでいたり、書いていたりで長時間一つのページに滞在する時間が多いでしょうが、皮肉な事に利用できない事が何時も以上の負荷を招く事態に陥らせる事があるものです。
負荷と言うのはシステムにはつきもですが、それに対する対策と言うのは難しいものがあります。
いわば無限の可能性に対してどこまで予め予防線をはっておくのかという点。
負荷の原因は千差万別、インターネットの特性上、アクセス数も無限大。
平時からのリソース状況から、システムのスケールを変えていくと言う方法を取るしかないので、想定している負荷を超えると即アウトと言う事態にもなってしまいます。
負荷が高騰した場合に、どのように復旧を行うかその手段を決めておくのは障害管理の運用の中で重要になりますが、これは負荷によって障害が出た場合の対処であって、起こりうる負荷に対しての対処にはなりません。
しかし、このスタッフBlogを読むと現時点では原因は分かりませんとしているので、システムの復旧を最優先に行ったと言う事が受け取れ、評価できる対処かもしれませんね。
負荷を減らすために、利用者の機能を制限したのも正解だと思いますし。
一番痛いのは、「利用者に迷惑かけてはいけない」とシステムを稼動したまま、システムを復旧させようとするんだけども、その負荷で作業が遅々として進まない、復旧も遅れるという自体。
ITILでも問題解決と、インシデント管理（サービスの回復）は分けて定義されていますので、この対応については間違いではないと思います。
