障害対応で大切だと感じていることのまとめ - Qiita

私個人の障害対応の経験と 一昨日参加したIncident Response Meetup vol.1での学びから 障害対応において大切だと感じていることをまとめる。 障害とは リリース後のシステムにおいてシステムの不具合やユーザーの操作ミスによってユーザー業務に影響が出ているもしくは出る恐れがあるもの。 障害対応の目的 システムを直すことではなく、ユーザー影響の回避・低減・早期回復をすること。 障害対応に対する心構え システムの信頼性の要である 障害への対応の仕方でユーザー影響が大きく変わる いつ発生するかわからないため特定の人が常に障害対応をするということは不可能である 素早く適切に行動するための備えが重要である 役割分担 障害対応では復旧対応、原因調査、ユーザーへの説明、社内調整などたくさんのことをやる必要がある。 またそれぞれの作業の難易度が高いことも多い。 一人の人間にできることは

[syu-m-5151]

障害対応で大切だと思うことは睡眠中に起こされても睡眠不足や精神を病まない健やかな心と身体、オンコールを持っていて夜中に鳴っても許してくれるパートナーです。

[oshishosan]

原因を報告すると担当にさせられるので発見しても黙っておくこと

[venus902]

部長クラスが現場に乗り込んできて「早く解決しろ」と「状況を説明しろ」の両方を要求してくるのには参った。応援と称して他部署からも何人も集められてきたが、キーとなる人物が会議室に拉致されてしまい何もできず

[sds-page]

後ろで急かされると焦って効率落ちるんだよねぇ

[iww]

矢継ぎ早にやって来ては障害報告を求める役員たちを遠ざける仕事とか、復旧作業と同時に再発防止プランを求める役員たちを黙らせる仕事とか、そういう名もなき仕事が書いてない。 書かずに済む職場なのか

[ryo_ryoo_ryooo]

推測否定しすぎ。ユーザーの発言聞いて、推測して、ログを見て、推測して、って流れじゃないの？

[ichiken7]

“システムを直すことではなく、ユーザー影響の回避・低減・早期回復をすること”←原因を解明せず、対処療法を施すことで、問題がより深刻化、長期化する可能性がある

[rogertroutman]

インシデントコマンダーは直接作業を行ってはいけない...「パルプ・フィクション」のハーヴェイ・カイテルみたいな感じですね。

[kazukan]

ログを見て推測と直感で次のログを見る。それが早く解ける鍵

[nemoba]

たぶん言いたいのはインシデント管理のことでITILとか読むとええ

[r-west]

ログから演繹推論はするけど、推測はダメ、絶対。

[futonchan]

必ず原因究明した後に対処療法をすること

[jojo800]

ひとりでやらないことと、障害出した人に対応を集中させないことかな

[natu3kan]

障害時に誰がとう担当するかの分担が決まってて公平ってシステムも重要か。正確な状況把握や原因分析にも試行錯誤と時間かかるし、イチ早い復旧したいけど、すぐコケて根治しないほうが損害大きくなるし。

[pwatermark]

誰が困ってるのか、何が出来なくなってるのか、それで不利益を被るステークホルダーは誰か、ステークホルダーと会話できるのは誰か、障害担当を監督できる管理者は誰か、辺りを整理する まず段取り

[jacoby]

ログで裏付けができない推測を過信しなければいいよ。むしろ推測しないと絞り込めないでしょ。そもそもログで裏付けなくて、ログ強化版作って再現させろ地獄もある（なかなか再現しない地獄）

[hiroomi]

故障と言ってる団体さん有り。サービスが利用できない状態。とか。なんか、星ついてるのは、ご愁傷さまだな。ナンマイダー。

[NOV1975]

「障害の」再定義しないようお願いします。

[IGA-OS]

事実と推測をちゃんと分類して判断するのは大事

[shikiarai]

・仲間を呼ぶ

[name-25137412]

目新しいわけではないがメモ