炎上プロジェクトの火消しに「障害対応フロー」を応用する
まだ炎上してる。つらい。
そんなときタイムリーな記事が。
システム障害と僕達はいかにして戦えば良いのか、障害対応について考えた - Qiita
何か原因不明の問題が起きている共通点がある。
障害対応か、問題解決か。
記事を参考に応用方法を考えてみたい。
まず、すぐ近くにいるエンジニアやチームメンバーに報告をします。どのように報告をすれば良いのかというと 結論ファースト です。
まずは今起きてることを発信する。
多分、周り緊急度に気づいてない。いや、「伝わっていない」。
まず声出してみる。
出してるつもりだったけど、「伝わるまで」出してみよう。
いったい何が問題なのかを把握するのが重要です。
問題を把握する。どうやるか。切り分けをするのは大事。
怪しいA、B、Cという事柄があれば、一つ一つ潰していく。
障害が発生するということは、何か変化があった可能性が高いです。そこが分かれば対応もスムーズにできます。
問題が「起きる前」と「起きた後」の「差分」を取るのはいい方法。
たとえば、前回の案件と今回の案件で、フィックスパックを当てた、とかね。
監視アラートもバグレポートもオープンな環境で共有できるようにしましょう。
ほんとこれ。無駄な責任感・罪悪感というものは蔓延しやすい。
「自分でここまではせめてなんとかしよう」とか言ってるうちに
状況はどんどん悪くなる。スピード感大事。
かといって個人が悪いのかというとそうじゃなく
大体組織の「文化」や「雰囲気」だ。
組織全体で自分を見つめなおす必要があるだろう。
とにかく 見なくても良い物 を増やしていくことが重要です。
すごくわかる。
問題が1個に見えるものは、実は100個の要素の集合だったりする。
100からまず50に、50を25に、と関係ない要素は潰していくといいと思う。
そのためには例えば、Redmineで100の確認チケットを作って潰すとか、アリだと思う。
- 1人で勝手にやらない
- 必ず（コード｜設計）レビューを通す
- 小さなことでも気になった所をメンバーに共有する
耳が痛いところ。
特に小さなことでも気になったところを共有する、ってとこ。
「なんかおかしい気がするなぁ・・・」「なんとなく変な感じがする」
みたいなものは、チケット化や情報共有まで持っていくのが怠りがちだと思う。
「小さな違和感」や「心のひっかかり」は放っておかないマインドと仕組みが必要だなぁ。
