8月だというのに涼しい日が続きますね。 kintone.comのDevOpsをしている@ueokandeです。 もうすぐAWS版kintoneのローンチからから2年が経過しようとしています。 この2年間、DevOpsチームではkintone.comのサービス安定化やスケーラビリティに注力してきました。 時には本番環境の障害で休日や深夜に障害対応することもあります。
kintone.comの障害の一次対応は、我々DevOpsメンバーが実施しています。 サービスローンチ直後は、メンバーの多くがオンコールに不慣れで、慌てて障害対応したりうまく進められないことが何度もありました。 そこでメンバー全員が効率的・効果的な障害対応を目指すべく、チームでPagerDuty社のIncident Response（非公式日本語訳版）を読むことにしました。 この記事ではAWS版kintoneで実際に体験した障害対応のアンチパターンと、PagerDuty社のIncident Responseから得られた教訓について紹介します。
アンチパターンその1: 障害時に全員集合
AWS版kintoneローンチ直後は、どんな障害が起こるか予測できず、オンコールの体制も整えられていませんでした。 そこでローンチ直後はオンコールメンバー全員が障害の通知を受け取るようにしていました。 kintone.comで異常が検知されるとメンバー全員が招集され、集まった人から順に障害対応を始めます。
この体制はすぐに問題が顕著となりました。
- 大人数で集まると何もしない人がいたり、意思決定・作業の速度が低下した。
- 夜間に全員が招集されると、日中のオンコールや作業が手薄になった。
対応策
PagerDuty Incident Responseには、オンコールに全員参加するのはアンチパターンだと紹介されています。 kintone.comでもオンコールは全員ではなく、限られたメンバーのみを呼び出すようにしました。 これによってオンコールの人数が多すぎるという問題と、日中が手薄になるという問題を解決しました。 PagerDutyのエスカレーション機能によって、1次オンコールメンバーが対応できない場合は残りのメンバーにも通知するように設定してあります。
アンチパターンその2: 意思決定者が不在
オンコール開始当初は、障害対応メンバー全員が手を動かし、皆が率先して問題を解決すればよいと考えていました。 しかし障害対応を重ねるにつれ、その体制ではよくないということがだんだんわかってきます。
障害対応で「どこを調査すべきか」「次に何をすべきか」など、障害を俯瞰的に見て整理できる人がいないと、意思決定や次のアクションに時間がかかってしまいます。 大きな障害ではそういった役割が不可欠です。 軽微な障害であっても「追加調査をすべきか」「翌日にじっくり調査をするか」を決める人がいないと、夜間にだらだら障害対応を続けてしまうこともありました。
対応策
PagerDutyのIncident Responseでは、障害対応時にインシデントコマンダー（Incident Commander）という役割が必要とあります。 インシデントコマンダーの目的はインシデントを解決に導くことで、実際のアクションや障害調査はしません。
kintone.comのDevOpsチームでは「最初にアラートに反応した人」というルールで、機械的にインシデントコマンダーを決めています。 インシデントコマンダーに深い専門知識は求められません。他のメンバーから意見を仰いで意思決定できます。 重要なのは意思決定をする人がその場にいるということです。 この役割を明示的に決めることで、障害対応時のアクションがスムーズに決まります。 緊急でない夜間の障害は、詳細の調査を打ち切って日を改めて実施するという決定もできるようになりました。
アンチパターンその3: 告知をためらう
kintone.comのステータスは、status.kintone.comで社外に告知しています。 事前に予想できる障害（エラー率やレスポンスタイムの上昇）などは、自動化してステータスページに告知しています。 しかしアラートが鳴らない怪しい振る舞いをしているとき、告知をためらって出せないことが何度かありました。
対応策
社外への告知は常に最悪の事態を想定して、ユーザー影響を確認できたら直ちに告知を出すようにしています。 障害の誤報をすることは、本当の障害を告知しなかったり事後報告するよりもずっとましです。 また日本メンバーでも素早く告知を出せるように、告知文のテンプレートを用意して、誰でも告知を出せるようにしています。
アンチパターンその4: 「誰かお願い」は誰もやらない
障害対応で作業を依頼するときに「誰かやって」とお願いするのはよくありません。 メンバー全員が互いに誰か手を挙げるだろうと対応するだろうと期待して、誰も手を挙げません（これを傍観者効果と呼ぶそうです）。 障害対応時には誰かが手が挙がるのを待つ時間はありません。
対応策
障害対応時に作業を依頼するときは「誰かやって」ではなく、名前を指名して作業を依頼するようにしました。 もちろん依頼する側の経験年数や、名前で指名する心理的ハードルがあります。 しかし障害対応はユーザーへの影響を抑えるのが第一であって、開発メンバーの社交の場ではありません。 そのことはメンバー全員がわかっているので、作業を依頼された側も快く引き受けてくれます。
アンチパターンその5: オンコールメンバーだけが知っている
障害対応が終わってやれやれと安心しきってしまうと、他のメンバーが障害について知る機会を得られなかったりします。 もし障害の原因が人によるミスやプロセスの問題にある場合は、また同じ失敗を繰り返してしまいます。 振り返りがおざなりになると、再発防止策を講じることができなかったり、そもそも障害の原因を知る機会を失います。
対応策
kintone.comのDevOpsチームでは、発生した障害をkintoneアプリに記録しています。 スクラムイベントで毎日顔を合わせる機会があるので、障害の内容や原因を共有して、再発防止策をチーム全体で考えていきます。 再発防止策はプロセスの改善の場合もありますし、アーキテクチャの問題の場合はチームのタスクとして取り組む場合もあります。 影響が大きいインシデントではポストモーテムを書いて、ステークホルダー（kintone PMやUSのセールスチーム）と障害のふりかえり・再発防止策を講じます。
まとめ
この記事ではkintone.comの障害対応で得られた知見や教訓を紹介しました。 国内向けのcybozu.comのSREの知見を取り入れつつ、kintone.comでも改善を重ねています。 また社内の告知チームやUSのセールスチームとも協力して、お客様により素早く正確な情報を提供できる仕組みづくりも続けていきます。
kintone.comではDevOpsエンジニアを募集しています！
この記事の内容や、kintone.comのDevOpsエンジニアの職種が気になるという人は@ueokandeまでお気軽にDMをどうぞ！
