深夜にアラートが鳴り、当番の人が画面を開いても、何から確かめればよいか分からないことがあります。
そのシステムに詳しい人に電話がつながるまで、対応が止まってしまうのはよくある光景です。
この「詳しい人の頭の中にしかない手順」を、誰が読んでも同じ結果にたどり着ける文書に移したものがランブックです。
Google の SRE 本は、手順を前もって書き出しておくと、その場の思いつきで対応するより復旧までの時間がおよそ 3 分の 1 になると書いています。
この一節は、Introduction（Site Reliability Engineering 第1章） の緊急対応の節に出てくる一文です。
ランブックに何を書き、どう保てば属人化を防げるのかが分かると、オンコールの当番表を組む前に整えるべきものが見えてきます。
私も SRE を学んでいる途中なので、ここでは Google の SRE 本とワークブック、AWS の Well-Architected フレームワークを読み比べて整理した内容を書きます。
ランブックは次の人が同じ結果を出すための手順書
AWS の Well-Architected フレームワークは、ランブックを「特定の結果を得るための、文書化されたプロセス」と定義しています。
いちばん簡単な形は、作業を終えるためのチェックリストです。
定義の原文は OPS07-BP03 Use runbooks to perform procedures で読めます。
同じページは、ランブックが無いときに起きることを「よくあるアンチパターン」として並べています。
- 手順の一つひとつを記憶に頼って進めている
- チェックリストなしで、手作業で変更をデプロイしている
- 同じ作業なのに、人によって手順や結果が違う
- システムの変更や自動化に、ランブックが追いついていない
三つ目の「人によって結果が違う」状態が、まさに属人化です。
ランブックの価値は、誰が実行しても同じ結果になることにあります。
新しく入ったメンバーが早く作業を担えるようになる点も、AWS は効果として挙げています。
障害対応だけでなく、定期的なデプロイやデータベースの変更のような平時の作業も対象です。
ランブックとプレイブックの呼び方は組織で揺れる
調べ始めると、ランブックとプレイブックという二つの言葉が出てきて混乱します。
AWS はこの二つをはっきり分けています。
プレイブックは障害の原因を調べるための手順で、ランブックは原因が分かったあとに直すための手順です。
プレイブックの説明は OPS07-BP04 Use playbooks to investigate issues にまとまっています。
AWS の説明では、プレイブックで原因を特定したら、その原因を直すランブックへ案内するのがよい形とされています。
一方で Google の SRE 本とワークブックは、調べる手順と直す手順をまとめて「プレイブック」と呼んでいます。
ワークブックの定義では、プレイブックはアラートの深刻度と影響を説明し、調査の手がかりと、影響を抑えて解決するための対応を含む文書です。
この定義は On-Call（The Site Reliability Workbook 第8章） に書かれています。
どちらの呼び方を採るかは、チームの中で揃っていれば問題ありません。
大事なのは「調べる」と「直す」の両方が文書になっていることで、名前の違いで迷う必要はないでしょう。
以下では、両方を含めてランブックと呼びます。
書く中身は目的・権限・手順・失敗時の連絡先
AWS のページには、Markdown で書けるランブックのひな形が載っています。
項目を日本語に置き換えると、次のような形になります。
# ランブックの題名
## 基本情報
| ID | 目的と期待する結果 | 使うツール | 必要な権限 | 作成者 | 最終更新日 | エスカレーション先 |
|----|----|----|----|----|----|----|
| RUN001 | （何のための手順か） | （略） | （略） | （略） | （略） | （略） |
## 手順
1. 手順 1
2. 手順 2項目を見ると、手順そのものより前に、目的と権限と連絡先を書く欄があります。
当番の人が途中で止まる理由は、手順が分からないことだけではありません。
権限が足りずに作業できない、うまくいかなかったときに誰へ連絡すればよいか分からない、という止まり方もあります。
AWS も、ランブックにはエラー時の対処・ツール・権限・例外・エスカレーションの案内を入れるべきだと書いています。
所有者と最終更新日を書く欄があるのは、古くなった手順を見分けるためです。
置き場所は、文書の置き場がまだ無ければバージョン管理のリポジトリから始めるよう勧められています。
変更の履歴が残り、手順の修正をレビューに乗せられるからでしょう。
アラートとランブックを一対にする
Google のワークブックには、アラートを作るときはたいてい対応するプレイブックの項目も作る、という一文があります。
アラートが鳴った瞬間に開く文書が決まっていれば、当番の人は探す時間を使わずに済むでしょう。
そのためにワークブックは、呼び出しの通知に監視画面へのリンクを入れることを勧めています。
AWS も、特定のアラートに使うプレイブックは、アラートの中にその場所を示しておくよう書いています。
この一対の関係は、アラートの設計とも深く関わる話です。
ワークブックは、すべてのアラートはすぐに行動できるものであるべきだとしています。
鳴っても何もすることがないアラートには、書くべきランブックがありません。
逆に言えば、ランブックを書こうとして手が止まるアラートは、鳴らす必要があるのかを見直す合図になります。
障害が大きくなり、複数の人で対応する段階に入ったときの役割分担は、Tech Lead の連載のインシデントコマンダーの記事で扱いました。
古くなる手順と書きすぎる手順の落とし穴
ランブックで最も起きやすい失敗は、書いたあとに放置されて実際の環境とずれることです。
ワークブックは、プレイブックの細部は本番環境が変わるのと同じ速さで古くなると書いています。
古い手順は、無い手順より危険な場合があります。
書かれたとおりに実行した結果、今の構成では別のものを壊すことがあるからです。
AWS が、ランブックの更新を変更管理の一部にするよう求めているのはこのためです。
システムを変える作業の完了条件に、関係するランブックの更新を入れておけば、ずれが溜まりにくくなります。
もう一つの落とし穴は、どこまで細かく書くかです。
ワークブックによると、Google の SRE の中でも意見が分かれています。
ゆっくりとしか変わらないよう一般的な書き方にとどめる派と、人による差をなくして復旧を早めるため一つひとつの手順まで書く派がいるそうです。
ワークブックは、ほかに何も合意できなくても、最低限どんな情報を構造化して載せるかだけはチームで決めるよう勧めています。
書いたランブックは、自分以外のメンバーに実際に使ってもらって確かめる、というのが AWS の手順です。
書いた本人は前提を知っているので、抜けている手順に気づきにくいからです。
書き終えたランブックは自動化の設計図になる
手順が固まると、ランブックは次の段階に進めます。
ワークブックは、アラートが鳴るたびに同じコマンドを決まった順で打つだけのプレイブックなら、自動化するよう勧めています。
AWS も、短くて頻繁に使うランブックから自動化を始め、やがて大半を何らかの形で自動化するよう書いています。
人が毎回同じ手順をなぞる仕事は、SRE が減らす対象であるトイルそのものです。
トイルの測り方と減らし方は、SRE の連載の別の記事で整理しています。
ランブックを書いておくと、手順が文書としてそろっているので、どこを機械に任せられるかを判断しやすくなります。
手作業の手順を文書にすることは、自動化に回す仕事を見つける近道にもなります。
最後に
ランブックは、詳しい人の頭の中にある手順を、誰が読んでも同じ結果を出せる文書に移すためのものです。
目的・権限・連絡先まで書き、アラートと一対にし、システムを変えるたびに更新すると、当番が変わっても対応が止まりにくくなります。
手順が固まったランブックは、そのまま自動化の候補を示す設計図として使えます。
以上です。
コメントを残す