愛と幻想のアジャイル

道産子ソフトウェアエンジニアの技術メモ

炎上プロジェクトの火消しに「障害対応フロー」を応用する

どうも。
一介のソフトウェアエンジニア、竹田剣介です。
IT業界にて日々奮闘中!
 

まだ炎上してる。つらい。

そんなときタイムリーな記事が。

システム障害と僕達はいかにして戦えば良いのか、障害対応について考えた - Qiita

 

 

何か原因不明の問題が起きている共通点がある。

障害対応か、問題解決か。

記事を参考に応用方法を考えてみたい。

まず、すぐ近くにいるエンジニアやチームメンバーに報告をします。どのように報告をすれば良いのかというと 結論ファースト です。

まずは今起きてることを発信する。

多分、周り緊急度に気づいてない。いや、「伝わっていない」。

まず声出してみる。

出してるつもりだったけど、「伝わるまで」出してみよう。

いったい何が問題なのかを把握するのが重要です。

問題を把握する。どうやるか。切り分けをするのは大事。

怪しいA、B、Cという事柄があれば、一つ一つ潰していく。

障害が発生するということは、何か変化があった可能性が高いです。そこが分かれば対応もスムーズにできます。

問題が「起きる前」と「起きた後」の「差分」を取るのはいい方法。

たとえば、前回の案件と今回の案件で、フィックスパックを当てた、とかね。

監視アラートもバグレポートもオープンな環境で共有できるようにしましょう。

ほんとこれ。無駄な責任感・罪悪感というものは蔓延しやすい。

「自分でここまではせめてなんとかしよう」とか言ってるうちに

状況はどんどん悪くなる。スピード感大事。

かといって個人が悪いのかというとそうじゃなく

大体組織の「文化」や「雰囲気」だ。

組織全体で自分を見つめなおす必要があるだろう。

とにかく 見なくても良い物 を増やしていくことが重要です。

すごくわかる。

問題が1個に見えるものは、実は100個の要素の集合だったりする。

100からまず50に、50を25に、と関係ない要素は潰していくといいと思う。

そのためには例えば、Redmineで100の確認チケットを作って潰すとか、アリだと思う。 

  • 1人で勝手にやらない
  • 必ず(コード|設計)レビューを通す
  • 小さなことでも気になった所をメンバーに共有する

耳が痛いところ。

特に小さなことでも気になったところを共有する、ってとこ。

「なんかおかしい気がするなぁ・・・」「なんとなく変な感じがする」

みたいなものは、チケット化や情報共有まで持っていくのが怠りがちだと思う。

「小さな違和感」や「心のひっかかり」は放っておかないマインドと仕組みが必要だなぁ。 


問題解決の極意

問題解決の極意