僕が障害復旧対応時に考えていることを言語化してみる - Qiita
これまで数多くのシステム障害を復旧してきました。 障害は無いに越したことは無いですし、起こらないように最善を尽くすのが我々エンジニアの使命です。 しかし、どれだけ最善を尽くしても起こる時には起こります。 今回は、これまで数多くの障害を復旧させてきたエンジニアが、復旧作業時に何を考えているのかを改めて言語化してみたいと思います。 こういう情報ってそれぞれのエンジニアの頭の中にあってあまり共有されないので、意外に参考になるかなと思います。 障害復旧対応の醍醐味 表現が適切かは分かりませんが、僕はシステム障害を復旧させるのが大好きです。目の前に起こっている事象からヒントを集め、地道に原因を切り分けてクリティカルヒットを見つけたときは名探偵になった爽快感があります。 加えて、動いているものを常に動かし続ける日頃の保守運用とは異なり、動いてないマイナスの状況を0まで戻すということで、復旧成功した際に
東証、障害の原因を特定 「自動切り替えできない設定値になっていた」
東京証券取引所は10月5日、株式売買システム「arrowhead」（アローヘッド）で1日に発生した障害の原因を特定し、4日中に修正したと発表した。 障害は、ストレージ内でメモリ故障が起き、サブ機にも切り替わらなかったことが原因。メモリ故障による障害が起きた際、自動切り替えできない設定値になっていたという。 arrowheadのユーザー情報などを格納するストレージ「共有ディスク装置」の1号機に搭載されたメモリが故障したことに起因。1号機が障害を検知すると、切り替え用設定値に従って自動で2号機に切り替わるはずが、切り替わらなかった。 調査したところ、メモリ故障が原因の障害パターンが発生した際、自動切り替えできない設定値になっていたという。設定値を変更すれば、自動切り替えできることが判明。4日にシステムに適用し、自動切り替えが動作することを確認したという。 稼働前のテストでは、1号機と2号機相互
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
