少人数での障害対応について

弊社では少人数チームで、ある程度の規模のシステムを開発・運用代行しています。そのシステムが少しでも停止すると、ユーザーだけでなくお客様やお客様のクライアント様にも大きな損害が出てしまいます。そのため、障害をなるべく出さないように、様々なチェックを通してアップデートやリリースを行うようにしているのですが、どれだけ気を付けても障害ゼロにすることは困難です。そこで、障害を対応する際にルールを設けることにしました。ルールを設ける際に、WEB+DB PRESS vol.119号内の特集記事「インフラ 障害対応演習」を参考にしました。一部、記事から抜粋した文章が入ることをご了承いただければ幸いです。また、弊社で考えた内容は割と普通のことです。なんだこんなことか、となるかもしれません。しかし、改めてメンバー全員が障害対応についてどうあるべきかを認識しなおすことが重要だと考えます。

弊社の状況について

弊社では少人数で開発や運用をワンストップで行っております。そのため、記事のように実際に疑似的な障害を発生させて大々的な演習をするといった時間を作ることが難しく、また演習を実施しても少ない人にしか知見や経験がたまらないため、コストパフォーマンスを考えると演習を実施することは難しいと判断せざるを得ませんでした。そこで、障害に関する認識を改めたり、障害対応時のルールを決めることで、メンバー全員が知見や経験値をためられるようにできないかと考えました。

障害対応の２つの課題について

ルールについて話をする前に、どういった問題や課題があるのかを知ること、伝えることがとても重要です。

1．MTTR（Mean Time To Recovery）平均修復時間を短く保つ必要がある

発生した障害はいち早く収束させ、被害の範囲を小さくする必要があります。つまり、対応はビギナーエンジニアではなく、ベテランエンジニアが行うことが多くなります。

2．障害対応スキルが属人化してしまう

障害をいち早く収束させるために、ベテランエンジニアが投入されます。ビギナーエンジニアが対応に入ることは少なく、また教わりながら対応することもありません。つまり、ベテランエンジニアにのみ知見や経験がたまっていくことになります。

結果として、経験が豊富な人はより経験を多く積むことになり、経験の浅い人にはなかなか機会が巡ってくることがなくなるため、ベテランエンジニア頼みのチームになってしまいます。

障害発生時の対応について

そこで、以下を障害対応時のルールとすることにしました。

1．ログをとる

何をどう考え、どう対応したのか、どういったコマンドを実行したのか、ログを記録するようにします。

2．振り返り会の実施

時系列にログを追い、どういった対応がよかったのか、またどういった対応が次に活かせそうか話し合いを行います。

障害対応時のロールについて

障害の対応をしているエンジニアはログを取得するような余裕がないため、記録は別のメンバーに担当してもらうようにします。具体的には下記のロールを予め決め、障害の対応を行います。

・現場指揮官

・実施担当者

・書記

・コミュニケーション役

現場指揮官は、障害対応時の司令塔です。状況を俯瞰し、障害対応の全体を常に把握、各担当者の情報を集め、指揮します。

実施担当者は、現場指揮官からの指示を遂行します。原因を調査するためのログや監視システムをチェックしたり、ターミナルで復旧手順のコマンドを実行したりします。

書記は、実施担当者が行ったことを記録します。どのようなログを分析して何が判明したか、どのサーバに対してどのような操作をしたか。発生時間や解消時間、障害の内容、影響範囲、原因、さらには今後の作業予定などを記録します。振り返り会では、この記録された内容を時系列順に追って確認していきます。

コミュニケーション役は、お客様への報告や相談を行います。

まとめ

障害の対応方法について、改めて整理し対応方法に関して検討しました。ロールを決め対応時のログを記録することで、振り返り会で障害対応時はどこのどのようなログを見るのか、どういった項目をチェックするのか、といった知見・経験がメンバー全員にたまっていくと考えています。

障害をゼロにすることは困難ですが、影響範囲を限りなく小さくすることができれば良いなと思っています。