誰も教えてくれなかったMySQLの障害解析方法 - QiitaDeleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
システム障害対応に対する考え方について
ヴィス @2vis 社内システムが普通に12月32日なって 「どーなってるんですか！」とユーザに言われて、 しらねーよ俺作ってねーよとは言えず呼び出されたことがｗ 2014-01-01 02:57:47 ヴィス @2vis 後、汎用機で1月1日になったら急に送受信が止まって呼び出されたときに… MMCFに「expire：20〷」って設定がされてた。 訳：期間満了って事 こんな地雷設定しこむんじゃねー！と叫びたくなったよｗ 2014-01-01 03:00:57
ファーストサーバの手順の問題点 - きしだのHatena
えらいことなってますが。 正規手順と今回の現象の説明などを含めた中間報告が出されています。 http://support.fsv.jp/info/nw20120625_01.html ここで、正規手順で、途中でオペレーションミスがあったときに復旧できない状態になってしまう可能性があることがわかります。 具体的には「原因3：メンテナンス仕様」のこの部分。 脆弱性対策のメンテナンスに関しては対象サーバー群とそのサーバー群のバックアップ領域に対して同時に更新プログラムを適用する この時点でこの更新プログラムに不具合があった場合には、リストアできなくなることになるわけです。そして今回はそれがおきたようです。 より安全な手順であれば、バックアップ側にパッチをあてている間は正常系がバックアップのバックアップということになるはず*1ですが、どこにもバックアップがない状態になってしまったわけです。 手順１
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
