株式会社ウェイブのSREシラトです！
みなさんは、システム監視のアラート通知が届いた際、すぐにアクションを開始できますか？
私は、
＿人人人人人人人人人人人＿
＞ なんのこっちゃわからん ＜
￣Y^Y^Y^Y^Y^Y^Y^Y^Y^￣
ってなることが多かったです。
ということで、今回は、Playbook / Runbook の概念を導入し、アラート通知改善をおこないましたので、ご紹介いたします！
課題
課題は大きく２つありました。
1. 何をすればいいかわからない
一番の課題は、この一言に尽きます。
アラート通知が届いてからのアクションは、主に３つのフェーズに分かれると思います。
- 原因調査
- 一時対応
- 解決確認
この各フェーズごとに、メンバーが同じアクションを取れるかというと、ばらつきが発生している状態でした。
アラート通知の原因調査を、自分しか行わないと感じたことはないでしょうか？
もしかすると、他のメンバーは何をすればいいかわからないかもしれません。
2. 手順書が管理されていない
正確な情報が記載されている手順書があれば、自走して問題解決することができますが、、、
- 手順書がどこにあるかわからない
- 手順書があっても必要情報が記載されていない
- そもそも、手順書があるかどうかさえもわからない（これはやばい）
手順書を探していたら、同じような手順書が合計３つ出てきた時は笑いました。
どれだけ優れた手順書があったとしても、探し出すことができなければ意味がないですよね。
どう改善するか？
タイトルにもある通り、Playbook / Runbook の導入が課題解決の糸口になりそうと感じました。
定義自体は、明確に決まっていないみたいでしたので、書籍や他社の導入事例を参考にして定義することから始めました。
他社事例 / 書籍
AWS Well-Architected フレームワーク
Playbook
翻訳
プレイブックで調査プロセスを文書化することにより、障害シナリオへの一貫した迅速な対応を可能にします。
知識を共有し、より多くのチームメンバーが同じ結果を達成できるようにすることで、主要な担当者の負担を軽減します。
Runbook
翻訳
Runbook は、特定の結果を達成するための事前定義された手順です。
Runbook には、手順を正常に実行するために必要な最小限の情報が含まれている必要があります。
知識を共有し、より多くのチームメンバーが同じ結果を達成できるようにすることで、主要な担当者の負担を軽減します。
入門 監視
Runbook
手順書（runbook）はアラートが来た時にすばやく自分の進むべき方向を示す素晴らしい字方法です。
環境が複雑になってくると、チームの誰もが各システムのことを知っているわけではなくなり、手順書が知識を広めるよい方法になります。
メルペイ
Playbook
メルペイのPlaybookはSLOに紐づきます。SLOに紐づくアラート(後半で説明します)が発生した場合に、エンジニアが何を行い、どのように考える必要があるかといった、SLOアラート対応時の一連の流れを示します。
Runbook
その中の対応作業の各手順のうち、オペレーション部分の再利用可能なものはRunbookとして切り出します。実際には既存の手順書のなかで再利用性の高いものをすでに切り出されているRunnbookと位置づけ、Playbookから辿れるようにしたりすることが考えられます。
transposit社ブログ
翻訳 + 要約
ベストプラクティス
- 特定の問題だけ解決する手順を記載する
- 探しやすくする
- 正しい情報を記載する
- 同じrunbookは一つだけ作成する
- 誰でも内容の更新を可能にする
Playbook / Runbook 導入
- 他社事例などを踏まえてウェイブでは、以下の定義にしました。
定義
Playbook
-
大きな包括したイベントの手順書- 例
- AWS Config コンプライアンス違反対処
- AWS コスト異常検出 の対応
- 社内Gitlabのメンテナンス実施
- etc
- 例
- 対インシデントやアラート関連だけではなく、顧客、従業員のどちらかに影響があるイベント系は、Playbookとして作成する方針にいたしました。
Runbook
達成したいこと１つの手順書
ルール
1. テンプレートを使用する
- ある程度強制力がないと、オリジナリティ溢れる手順書になってしまいます。
- 内容に過不足が発生しないようテンプレートを用意しました。
Playbook テンプレート
インシデント系に関しては、メルペイさんのテンプレートをそのまま参考にさせていただきました！
その他のケースに関しては、別途作成予定です🙇♂️
Runbook テンプレート
# 概要
# 手順
## 1.
## 2.
## 3.
# 参考
2. 管理を同一サービスに集約する
ウェイブでは、社内wikiツールとして、Growi を使用しております。
探しやすさを重視するため、すべての手順書を Growi に集約することにしました。
3. ディレクトリの階層を深くしない
- ネストが深くなってしまうことも、探しやすさに影響するかと思います。
- そこで、ディレクトリの階層は最大でも三階層までにする方針にしました。
- 例
- Runbook
- AWS
- 新規アカウントを作成する
- Config
- Organization 配下に適合パックをデプロイする
- 特定のアカウントに適合パックをデプロイする
- 違反しているリソースを特定する
- AWS
- Runbook
4. シンプルを意識する
- runbook限定のルールですが、内容の大小は問わず、単一目的・単一責務にする方針にしました。
- 特定の問題解決のことだけにフォーカスすることで、再利用性を高め、手順書の粒度を制限します。
結果
AWS Config のコンプライアンス違反のアラート通知を例に挙げると以下の通りです。
| Before（Chatbot経由） | After（自作Lambda経由） |
|---|---|
 |
 |
改善後の通知に含まれる、Playbookを読むことで、アクションすることができる状態を目指しました。
実際のPlaybookの中身は↓の通りです。
Playbookを展開する
# 重要度
* Warning：ユーザーに影響しない
# 影響範囲
### 顧客
* なし
### 従業員
* AWSの無駄なコスト上昇
* セキュリティリスク
# 何が発生したのか？
* 特定の AWS リソースが、会社のコンプライアンスに準拠していない
# なぜ発生したのか？
* AWS リソースの新規作成、更新を行なった
# 問い合わせ先
* SRE
# 原因調査
## 1. 対象アカウントにログインする
* runbook URL
## 2. 違反しているリソースを特定する
* runbook URL
## 3. 違反しているリソースの作成者を特定する
* runbook URL
# 対応
## 1. 対象アカウントにログインする
* runbook URL
## 2. コンプライアンス違反を解決する
* 違反ルールが"A"の場合
* runbook URL
* 違反ルールが"B"の場合
* runbook URL
* 違反ルールが"C"の場合
* runbook URL
# 解決確認
## 1. コンプライアンス違反が解決したか確認する
* runbook URL
「Playbook欲しい。。。」
そう思ったあなたは今日から仲間です🤝
おわりに
社員数やサービス規模が拡大するにつれて、属人化が加速していると感じたため、改善してみました！
本件はSRE内部で改善が始まったばかりですが、当たり前の文化にしていきたいです。
また、何でもかんでも手順書を作成することが正しいとは思っておらず、自動化、半自動自動化を目指すことが理想と考えております。
手順書を作成する前に、「あれ？これ自動化できそう！」と感じたら、すぐに自動化までできるといいですね！
宣伝
ウェイブでは、電子コミックやアニメ配信などのエンタメコンテンツを自社開発で運営しております。
一緒に働くメンバーを募集中ですので、興味ある方、是非、以下のリンクにアクセスをお願いいたします！
株式会社ウェイブのエンジニアによるテックブログです。 弊社では、電子コミック、アニメ配信などのエンタメコンテンツを自社開発で運営しております！ ve.jp/service/
Discussion