こんにちは。Topotal の 宮里 miya_wata1017 です。
約1年間、SRE NEXTをはじめとする、さまざまなカンファレンスに協賛し、Waroom のブースを出展してきました。
Waroom のブースにお立ち寄りいただくエンジニアの皆さんからよく聞こえてくるお悩み、それがインシデント対応の属人化です。
※属人化以外にも、様々なお悩みや課題はあると思いますが本記事は「属人化」にフォーカスしてます。
特定のエンジニアにしかわからない、その人が休んでいると対応が止まる、初めての人が入ると何をすればいいかわからなくて混乱する。こういった声は、組織の規模にかかわらずあるかと思います。
この記事では、インシデント対応における属人化がなぜ起きるのか、そして Waroom がどのようにその問題を解消するのかについて解説したいと思います。
インシデント対応はなぜ属人化しやすいのか❓
インシデント対応における、属人化が起きやすい理由は、大きく3つあると考えています。
- 手順が頭の中にしかない
- 熟練したエンジニアは長年の経験から培われた直感的な判断で、このアラートが出たらここを確認する、こういう状況のときはこのコマンドを打つ、という判断を半自動的にこなしています。しかし、そのプロセスがドキュメント化されていないと、当人がいなければ初動すら踏み出しにくい状況にあります。
- 今を乗り越えることを優先してしまう
- 障害対応中は復旧を最優先に動くため、後で手順書を書こう、振り返りをやろうという意図があっても、業務に戻ると優先度が下がってしまいます。こうして記録すべき知見が蓄積されないまま時間が経過していきます。
- ツールや情報が散在している
- Slack のスレッドに対応ログが断片的に残り、手順は別のツールに書かれており、振り返りはさらに別のツール、という状況では、次に同じインシデントが起きたときに前回の対応を参照するだけでも一苦労です。
属人化が組織にもたらすリスク⚠️
全ての組織の属人化 = リスク ではないと考えておりますが、組織・サービスの規模拡大等、ステージによって、属人化は単なる不便さではなく、事業継続のリスクに直結する可能性を秘めています。
たとえば、インシデント対応をするエンジニアが、オンコール当番のたびに大きな負担を感じ疲弊してしまうケースや、組織拡大にともなって新しいメンバーがインシデント対応に加わるときに、何をすればいいかわからないという状態が続けば、初動の遅れがサービス停止時間(ダウンタイム)の長期化につながります。
Waroom をご利用中のお客様でも、Waroom 導入前はインシデントの情報共有に課題を感じていました。特定の Slack チャンネルのスレッドを使って対応を行っていたため、関係者への通知漏れや情報のサイロ化が発生しており、経営層と現場の間で課題認識のギャップが生じていたといいます。
Waroom が属人化を解消するための2つのアプローチ 👉
Waroom では、属人化の根本原因に対して、対応を標準化する仕組みと情報を自動で残す仕組みの2方向からアプローチしています。
① Runbook (対応手順書) で、対応を標準化する
Waroom の Runbook 機能は、インシデント対応の手順をあらかじめ定義し、インシデント発生時に Slack 上へ自動で表示する機能です。
Runbook は Overview（状況説明）・Dashboard（参照すべき監視ツール URL）・Precheck（確認すべきポイント）・Resolution（復旧手順）の4セクションで構成されており、対応者が迷わずに初動から復旧までを進められるよう設計されています。
※インシデント対応の手順がない場合でも、デフォルトの Runbook をご用意しているので、すぐにご利用いただけます。
## Overview アプリサーバー上で動作しているnginxが停止している。 ## Dashboard - [Grafana ダッシュボード](https://sample.grafana.net/d/hoge) ## Precheck ### systemctl status 以下のコマンドを実行してステータスを確認してください systemctl status nginx.service 以下のコマンドを実行して何か手がかりとなるメッセージが出力されないか確認してください journalctl -xe -u nginx.service ## Resolution ### systemctl restart nginx の再起動を実行してください systemctl restart nginx.service ### systemctl status 正しく起動したかを確認してください systemctl status nginx.service
さらに Runbook Rules を設定することで、サービスのインシデント内容ごとに、どの Runbook を適用するかというルールベースの自動紐付けができます。アラートの内容に応じて適切な手順書が、Slack 上に自動で提示されるため、対応者がどの手順書を使えばいいかを調べる手間もはぶけます。
Waroom をご利用中のお客様の事例では、Runbook 機能を活用することで、エンジニアがより高度な対応に集中できるよう、一次対応をカスタマーサポートチームへ移譲することに成功しています。Runbook で手順がドキュメント化され、Slack 上に自動表示されることで、インシデント対応に不慣れなメンバーでも安心して動けるようになったとのことです。
② 専用チャンネルの自動作成と関係者の自動招待で、情報を集約する
Waroom では、インシデントが起票されると対応専用の Slack チャンネルが自動で作成されます。さらに、サービスに応じてあらかじめ設定したメンバーを自動で招待する機能もあります。
これにより、誰に連絡すればいいか、どこで情報を共有するかを判断する必要がなくなり、インシデント対応に集中することができます。
組織が拡大しても回るインシデント対応基盤を作る👷
属人化の解消はいまのお困りごとを直すだけではなく、組織が成長しても崩れない仕組みを作るという観点でも非常に重要なのではないでしょうか。
チームが10人から30人、30人から100人へと拡大していく中で、インシデント対応を属人的な運用のまま拡張しようとすると、熟練したエンジニアの皆さんの大きな負担となります。
Runbook と自動化された対応フローがあれば、熟練エンジニアの皆さんのこれまでのノウハウを新しいメンバーが加わるたびに口伝えで教える必要がなくなり、チーム・組織のスケールに対応できます。
終わりに
先ほども書きましたが、インシデント対応における属人化のリスクは、組織規模のステージによって異なります。サービス規模や組織拡大のタイミングによって、属人化が大きな課題となり、組織の負担となる可能性もあります。
Waroom の Runbook 機能とチャンネル自動作成・自動招待の仕組みを組み合わせることで、誰でも迷わず動ける標準化されたインシデント対応フローを実現できます。
現状のインシデント対応フローが、次のステージに耐えられるか、一度立ち止まって考えるきっかけになれば嬉しいです。
インシデント対応のお悩みや、デモンストレーションをご希望の方は、こちらからお申し込みください👇
