自らが担当した炎上プロジェクトを、自らの手で鎮火するために
ITの開発案件の数多くは、基本的に余力がない。
品質は当然のこと、競合他社に勝つためには安く作り、早く提供しなければならない。
もちろん技術発展の目覚ましい業界なので、過去のやり方やツール、モジュールなどに依存せず、新しいものをいち早く取り入れ、既存のものは改良しなければならない。
また、時には、見知らぬ誰かが作り上げたものを、改訂しなければならないときもあるし、そもそもいつ何時だって短納期が当たり前。
そう、自分の担当するプロジェクトは、いつだって炎上したっておかしくない。
炎上してからでは遅い。
炎上してもいいように事前に防火の知識を蓄えておくことも必要だし、
炎上した時に鎮火する術も身に付けておく必要もある。
自らの担当するプロジェクトでも炎上経験はあるが、それはあまり思い出したくない。
別の機会に書くとしよう。
今回は、炎上プロジェクトを体験する機会よりは、リリース後の障害発生のほうが数多く体験する機会が多いため、まずリリース後に発生した障害やトラブル、異常、エラーなどが発生した時に、自分がどう対処してきたのか、簡単にやり方をご紹介する。
原因について。
障害の原因には2種類ある。
直接的な原因と根本的な原因だ。
直接的な原因は、
- プログラムがバグっている
- リリース手順を誤った
- 通信障害やサーバダウンが発生した
- ジョブが停止していた
などが良くある直接原因だろう。
原因を早急に特定し、顧客に一方入れ、サービス復旧させるまでの第一歩は非常に大事だ。
対策について。
筆者の会社では、何らかのインシデントが発生した時点で、即、その報告を上司と顧客にエスカレーションする。
暫定的でもいいのでサービスを継続できるよう緊急の対応を取る。
複雑な障害や対策が数種類考えられるものなどは、有識者や関連者集まり、インシデントの共有と、改修案を検討する。
正直、この1次対応を誤ると、2次災害を産み、より悲惨な状況となるため、こういった対策会議はポジティブに開催すべきだ。
参加者は担当者本人、有識者（助っ人）、第3者目線（俯瞰した視点）で物事を判断できる担当者か上司、が最低限参画したほうがいい。
ここで重要なことは、
障害やミスなどの報告をエスカレーションをしやすい環境づくりと、
対策会議を即開催できるようにしておく環境づくり。
障害や異常・エラーなどに対して、臭いものにふたをするような風潮や、事もあろうか他人にミスをなすりつける人間関係だと、まったくもって意味をなさない。
会社の信頼を失うだけだ。
改修について。
直接的なエラーについての改修内容やポイントが分かって、「さぁ直そう」と取り掛かる前にちょっと待つ。
2次災害を生まないためには、
- デグレしていないかの点検
- 障害が発生したポイント以外に、同様のバグが潜んでいる箇所がないかの点検
- 暫定的な対応なのか、根本的な対応なのか
の3点を改修前に行うことがポイントだろう。
もちろんシステム視点だけでなくビジネス視点も考え、今、障害が発生しているシステムが担うビジネスのコアを理解し、優先度を付けて取り掛かるのが非常に重要だ。
例えば、わかりやすい例だと、Eコマース系の機能だと商品の販売・発走はプライオリティ度合いはHighとなるが、画面の表示崩れなどは火を見るより明らかにLowプライオリティだ。
それと、障害に慌てず、緊急度・優先度付けして対応に当たることも重要だ。
これら2点のことは当たり前のことなのだが、問題を引き起こした当事者の立場では、これを頭の片隅に置いて立ち回ることはなかなかできない。
そのための対策会議だ。
第三者視点で状況理解、対応の優先度の判断が冷静にできる味方を近くに着けておくことと、改修の優先度・方針が誤っていないのか、という方針決めを対策会議で行っておくと、慌てずに済む。
味方が多いと慌てず冷静に対処できる。
その状況をもたらすことが対策会議の骨頂だ。
もちろん改修後は原因の究明を行う必要がありますが、ここはまた別の機会に。
小さなプロジェクト・案件での小さな障害・問題でも、上記のようなサイクルで対処する癖をつけ、部門や社内に障害対応のプロセスを浸透させておけば、少々の障害・問題にはビクともしなくなるだろう。
また、小さな障害・問題でもきちっと対応することで顧客の信頼も上がることが、経験上、副次的に得られる効果ということがわかった。
トピック「最近おもしろかった本」について
