システム障害と僕達はいかにして戦えば良いのか、障害対応について考えた - Qiita
IT界隈でエンジニアしていると、よく出くわすのが障害対応です。できれば会いたくないという人が多いと思うんですが、僕はけっこう好きです。障害対応。どこに原因があるのか調査をして、バランス良くベターな対応をしたときの楽しさは、プログラミングとはまた違ったものがあります。探偵っぽい感じが面白いですよね。もちろん、障害が発生しない状況を作るのが一番です 弊社では数多くのWebサービス／アプリを運営しているので、過去様々な障害対応をしてきました。その際に、解決までどんな道筋を僕がたどるのかを振り返ってまとめてみました。これが大正解なんてことはなく、人や事象によって違うとは思いますが。 なお、障害検知手法とか、サーバのコマンドとか、コードのデバッグ手法とか、具体的なことは一切出てきません。手続きと思考プロセス的な話です。 障害対応フローチャート 一般的な感じだと思いますが、障害報告から対応完了までのフ
第8回 インフラエンジニアの「修羅場」事件簿 | gihyo.jp
今回は、前回予告した通り、筆者が経験したことのある修羅場について書いてみます。なかなか微妙な内容で、セミナーとかパネルディスカッションとか（飲みの席とか）では話したことはあるのですが、字にするのはたぶん初めてです。 普通修羅場というと、技術的なトラブルに関するものだと思うのですが、ある程度の経験値を積むと、対処できない技術的なトラブルというのはなくなるものです。もし対処できない技術的なトラブルがあるとすると、もうそれは誰にもどうにもできないので諦めるしかないとかになります。ここであえて「技術的な」と書いたのは、意味があります。筆者が経験した修羅場は技術的なものではなく、法的というか金銭的なものでした。 ［Case1］ネットワーク機器差し押さえでルータ13台→4台に まず1つめは、あるデータセンターの運用をサポートというか代行していたときのことです。そのデータセンターは実は購入しているネット
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
