アカウント名:
パスワード:
# ジャンルは違えど、ひとごとではない...
障害前は「障害が起こる前」だし障害後は「障害が起きた後」なんだから障害前後に障害が起きるというのは「もうとっくに障害が起きている」か「まだ障害が続いている」というだけなのではないでしょうか？:-D
っていうか単に「障害が起きる場合は連続し
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
※ただしPHPを除く -- あるAdmin
またFourelle Venturiか? (スコア:2, すばらしい洞察)
それにしても、19日といい、その前 [srad.jp]といい、Web圧縮サービスの開始や障害前後に障害が発生しているのはなぜなんでしょうか。
今回も「prinなら通る」みたいな不思議な現象が出てるし、前回は「HTTPだけダメ」だったし、特定プロトコル圧縮サービスと日取りが重なってるし。パケットの中身で判断する4層スイッチみたいな製品を使いこなせてないような予感がするな……
Re:またFourelle Venturiか? (スコア:1)
インターネットのバックボーンでのピーク負荷って、挙動不審？
それに平均負荷も容易なレベルじゃないだろうしなぁ。
# ジャンルは違えど、ひとごとではない...
=^..^=
Enjoy Computing, Skiing, as much as Horse Racing.
負荷とトラブル (スコア:3, 参考になる)
負荷によるサービス不能がそのサービスの系で閉じている限りは、系として負のフィードバックが解決してくれます。つまり、負荷が原因になって負荷が減って元に戻る、まだマシなんです。ある意味、ベストエフォートの正常動作ですから (客としては許せんが)。
負荷やトラブルが他の系に影響するようになると、その影響先が他に影響を与えて……と。互いに崩しあうドミノ倒し状態になったりします。この場合は横から手を入れないと回復しません。
ネットワークに限らず、このような正のフィードバックを作らないようにするのも、システム構築の芸です。今回に限らずAir H"の障害って、特にサービス追加にあたって、トラブルが起こった後のことを考えていなかったように見えます。
というのは技術屋の弁。それよりも「早めに、目立つように障害報告」「概要を説明の上、具体的な反省」「反省をきっちり守る」などなどをこなしてないあたりがまずいんでないかなぁ。Freedに期待という話も、このあたりの無反省雰囲気を汲み取ってのことと思う。
実際、23日の障害情報で19日の障害情報を上書きするあたり、無かったことにしたいのではないのかなと。
Re:負荷とトラブル (スコア:1)
5月あたりから、障害報告の書き方が、上書きから追記に変わってます。
とりあえず、納得しておきましょ。
Re:またFourelle Venturiか? (スコア:1)
この時間帯、RedHatNetWorkやAria [rednoah.com]でいろいろ落としていましたが、特に問題はなかったです。
Re:またFourelle Venturiか? (スコア:0)
障害前は「障害が起こる前」だし障害後は「障害が起きた後」なんだから障害前後に障害が起きるというのは「もうとっくに障害が起きている」か「まだ障害が続いている」というだけなのではないでしょうか？:-D
っていうか単に「障害が起きる場合は連続し