ゼロから始めるシステム障害対応フロー - Qiita
初めに 本記事 『ゼロから始めるシステム障害対応フロー』 の内容について タイトルの「ゼロから始める」には二つの意味があります。プロダクトのリリースを間近に迎える中、チーム内での障害対応体制の枠組みがなかったこと。そして体制づくりを担当することとなった私の知識・知見が（ほぼ）ゼロだったこと。この二つです。 この状態から、リリース前〜リリース後の約2月間でなんとか形にすることができました。本記事ではその過程でぶつかった問題とそれに対する課題、それらにどう対応したのか、何を学んだのか、の紹介。 そして、障害対応体制の策定・構築や改善の流れの中で私が起こした失敗から、人としてリーダーとして何を心がけなければいけなかったのかの反省を共有させてもらいたいと思います。 本記事は以下の構成です。 0. 始まり ※ スクラムチームでの話。スクラムチームの登場人物は以下の三つ PO：プロダクトオーナー（Pd
障害対応で大切だと感じていることのまとめ - Qiita
私個人の障害対応の経験と 一昨日参加したIncident Response Meetup vol.1での学びから 障害対応において大切だと感じていることをまとめる。 障害とは リリース後のシステムにおいてシステムの不具合やユーザーの操作ミスによってユーザー業務に影響が出ているもしくは出る恐れがあるもの。 障害対応の目的 システムを直すことではなく、ユーザー影響の回避・低減・早期回復をすること。 障害対応に対する心構え システムの信頼性の要である 障害への対応の仕方でユーザー影響が大きく変わる いつ発生するかわからないため特定の人が常に障害対応をするということは不可能である 素早く適切に行動するための備えが重要である 役割分担 障害対応では復旧対応、原因調査、ユーザーへの説明、社内調整などたくさんのことをやる必要がある。 またそれぞれの作業の難易度が高いことも多い。 一人の人間にできることは
障害対応は寝て、食べるが大事 - Qiita
「 障害対応 」 エンジニアができるだけ見たくない単語ですね。 でも人間が作っているシステムである以上おそらく避けては通れない道... 実は直近で障害対応を経験し、正直すごくしんどい思いをしました。 今回はその教訓を記事に起こしたいと思います。 障害&起こったこと 2月某日クライアントから障害報告が来ました。 幸い既に障害原因箇所が今後は動かないコードの部分だったのでシステム自体の改修はありませんでした。 ですが、障害報告として対象データの洗い出しを行う必要がありました。 結構対象データの件数もあったのですが、粛々と対象しないといけないです。 一通り調査し、報告したところ トラブル発生 ... 調査結果に不備が見つかってしまいました。。。。 障害が起きている時点でクライアントは結構噴火寸前。 もちろん厳しいお言葉をいただきました。。。。 その後も続く調査&報告....そして厳しいお言葉の数
20年前の「障害の再発防止策の考え方」は今でも通用する説 - Qiita
障害の再発防止策は、 1. メカニズム 2. ツール 3. ルール 4. チェックリスト の順番に検討せよ。 上記は、私が20年前に所属していたパッケージソフト開発会社の標語です。 ※転職したので現在の所属会社ではありません。 当時はまだインターネットが今ほど普及しておらず、修正パッチはCD-Rで配布していました。 特に、データ破損系の障害の場合は、 お客様にファックスで障害内容を報告し、 緊急ホットラインを開設し、 データ異常が見られる場合はバックアップを預かって修正後に返却し、 上記と同時並行でバグの原因調査と修正を行い、 パッチをCD-Rに焼いて配布する。 という障害対応を行っていました。 各パッケージの利用社数は数万〜10数万社に上りますので、大変な騒ぎでした。 そして事後に、障害の再発防止策を検討し報告する義務が課されるわけです。 メカニズム 仕組みとして、障害原因を封じ込める対
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
