先日書いた【障害対応】インシデント管理プロセスについての記事で
おおよそ他のSREプロセスと同じく、このインシデント管理プロセスについても導入先の組織に合わせてよく改変されます[1]。
と書きましたが、私もSRE本で紹介されたインシデント管理プロセスを一部改変して運用することが多いです。
この記事ではそういった改変と、SRE本に書かれていないために自分で補完したこと、あとは障害対応の訓練中によく質問された点をFAQとしてまとめておきます。
改変
インシデント状況ドキュメントを更新する人: 指揮官 → コミュニケーション担当者
原文では次のようにインシデント状況ドキュメントの維持責任を指揮官としています。
The incident commander’s most important responsibility is to keep a living incident document.
指揮官の最も重要な責任は、インシデント状況ドキュメントを最新の状態に維持することです。
しかし、私はその責任をコミュニケーション担当者にしています。そうする理由の1つは、3つの役割のうち最も手が空きやすいのがコミュニケーション担当者であるためです。
指揮官は、特にそれに慣れていない人は、状況理解と判断で頭がいっぱいになり、ライブインシデント状況ドキュメントの更新が疎かになりがちです(議長と書紀を兼ねるような難しさ)。一方で比較的官僚化が進んでいないスタートアップに近い組織では、コミュニケーション先はそれほど多くなく、頻度も頻繁でなくて良い場合が多いです。そのため、バランスを考えてドキュメントの更新はコミュニケーション担当者の仕事にしています。
また、コミュニケーション担当者は外部とのやり取りの中でより広範囲な状況を把握していることが多く、ドキュメント内の時系列をより良く更新できることも一因です。
計画担当者: 一旦置かない
【障害対応】インシデント管理プロセスについてでも書きましたが、私は計画担当者を通常の障害で置きません。今まで10回以上障害が発生しましたが一度も起きませんでしたし、振り返りで置いたほうが良いと感じたこともありませんでした。
それは、計画担当者が必要なほど障害が長期化・複雑化することがなかったためです。
原文では計画の詳細について以下のように書かれています。
計画の役割は、バグの報告、夕食の注文、引き継ぎの調整、システムが標準からどのように逸脱したかを追跡してインシデントが解決したら元に戻せるようにするなど、長期的な問題に対処することで運用をサポートします。
しかし、多くのシステムでは、これに専任の人を割り当てる必要があるほど長期・複雑な障害はほとんど発生しません。また、もしそういった障害が起きた場合でも、多くの場合指揮官をやっているであろう、もっとも経験豊富なリーダーしか判断できない事が多いです。そのため、この役割に人を割り当てることには意味がありません。
インシデントを宣言するタイミング: 改変なし
ここは【障害対応】インシデント管理プロセスについてで説明を省きましたが、実は改変していません。原文と同じく、
- 問題対処に他チームの協力が必要か
- ユーザーに影響を与えているか
- 1時間対処を続けても問題が解決しないか
などを判断基準に使っており、また、迷ったら障害として扱うという方針にも従っています。
個人的にはこの2番目の「ユーザーに影響を与えているか」が最も重要だと思っています。普段はこれだけ覚えておいていいと考えています。
FAQ
インシデント管理プロセスとはつまるところ何であって何でないのか
私は、インシデント管理プロセスを
- フレームワーク
であって、
- ルール や
- ガイドライン
ではないと思っています。
ルールではないので、インシデント管理プロセスにはこの条件になったら責任者に連絡しよう、この障害が発生したらこう対処しよう、といった具体的な指針・アクションがほとんどありません。
作業や調査の内容はすべて作業責任者に任されており、コミュニケーションの手順・相手もすべてコミュニケーション担当者に任されています。つまり、Webフレームワークのように枠組みだけが提供されており、内部実装は作りたいもの・会社に合わせて変えられるようになっているわけです。フレームワークなので、それぞれの会社や組織に合わせてある程度のカスタマイズができます。
私はフレームワークであることの最大の利点を シンプルであること と捉えています。
障害対応の場では通常と違う現場であることから多くの人が通常時ほどパフォーマンスを発揮できません。
また、関わる人が広くなり、システムに精通していない人も対処チームに入ることがあるので、多くの人が実行できるシンプルなフレームワークであることが求められます。インシデント管理プロセスはそれを満たしています。
また、こういう事態が起きたらここに連絡、障害のレベルはこのように判断、といったより具体的なルールは維持に大きなコストがかかります。まず、初期の策定にコストがかかる点、日々変わっていく組織やシステムに合わせてアップデートすることにコストがかかる点、その変更のたびに関係者や再教育を行うコストがかかる点などです。その結果、ルールの更新がされなくなり、ルールが守られなくなったり、守るけども更新する人がいないので実際のシステム・組織と乖離したひどく非効率・無意味なルールを実行していたりします。そういった事態を避けるためにもインシデント管理プロセスのシンプルさは有用です。
障害が発生したとき、経験豊富なメンバーがおらず未熟なメンバー1人しかいません。この場合でも、この1人が指揮官ですか？
そうです。不安かもしれませんが、対応チームが1人でもいる限り、指揮官を定義しておいたほうがよいです。
ただし、後述の通り、あとから参加してきたメンバーへ指揮官を変わってもらい、自分は作業担当者やコミュニケーション担当者になるのはOKだと考えています。
後から入ってきた人に指揮官や作業担当のリーダーを変わってもらうのはOK?
これについてはSRE本には書いていません。ただ、私はOKだと思っています。
実際、前述のような、初期対応はジュニアメンバーが当たったが、すぐに解決せず後からリーダーが参加した場合などは変わってもらったほうが良いケースでしょう。
ただ、この際は以下に注意する必要があります:
- しっかり引き継ぎを行う (現在の状態およびそれまでの経過。これにはインシデント状況ドキュメントをきっちり書いていることも必要)
- 指揮官を渡したら、今まで指揮官をやっていたメンバーは障害対応から離脱するのではなく、作業担当者やコミュニケーション担当者になる
ただ、よく訓練された組織であれば、障害の規模によってはあえてジュニアメンバーにそのまま指揮官をやらせるケースもあります。障害対応の経験を積んでもらうことで長期的なチームの戦闘能力向上を行うためです。
Embedded SRE(または集約型のSREチーム = インフラチームのメンバー)が指揮官になるべきですか？
開発チームと十分な連携が取れている前提ならイエス、そうでなければノーだと思っています。
前提として、インシデント管理プロセスを実行するのは普段から積極的に障害対応に当たっているメンバー = チームです。つまり、今まで障害対応をSREチームが行っていたところへ、開発チームへインシデント管理プロセスを教えたから今後は障害対応は開発チームがよろしくね、と行ってもうまくいきません。インシデント管理プロセスは、あくまで今まで行ってきた障害対応にルールを決めることでより効率的な対応が取れるようになるだけのものです。ですので、逆のパターンでいうと、今まで障害対応にEmbedded SREやインフラチームが関わってこなかったのであれば、彼らが指揮官をやってもうまく行かないでしょう。あくまで、指揮官は今まで障害対応を行ってきたチームの誰かがやるべきです。
指揮官はチームリーダー(テックリード, 部長, EM, ...)のほうが良いですか？
基本的にはYesです。なぜなら、彼らは開発チームの誰よりも経験豊富で正しい判断を下せる場合が多いためです。指揮官には正しい現状把握と制度の高い意思決定が求められるため、適任と言えます。
ただし、一方でチームリーダーしか指揮官をできない開発チームは障害に対して脆弱です。
より強いチームは、リーダーがいなくてもそれと同等の障害対応ができます。多少意思決定の質・速度が落ちるとしても、すべてのメンバーが指揮官をいつでもできるのが理想でしょう。
そのためには可能なら訓練で指揮官をジュニアメンバーも行い、実際の障害でもある程度はチームリーダー以外へ指揮官を任せる戦略と勇気が必要です。
チームリーダーです。指揮官の役割をしているのですが、作業担当者をジュニアメンバーに任せられません。調査・解決作業も私がするのが一番早いです
エンジニアとして優れたリーダーが必ず一度は感じることだと思いますが、答えは「それでも任せる」です。
理由は、任せないといつまで経ってもできないためです。開発チームのリーダーであれば、チームがより高い戦闘力を持つようにすることも責務の一部ですが、そのためには今できないことでも任せて、できるようになって貰う必要があります。そのためにまずは訓練で優先的に経験をさせ、場合によっては実際の障害でもあえて経験の浅いメンバーに完全に任せます。それによって障害の時間が数秒や数分伸びるかもしれませんが、それよりも成長したメンバーが将来返してくれる利得のほうが多くの場合よほど大きくなります。
インシデント状態ドキュメントってどこで書くのがよいですか？
SRE本では、
- 誰でもアクセスしやすく
- 安定して利用できて
- 同時編集できる
ことをインシデント状態ドキュメントの要件としてあげて、Googleドキュメントを勧めています。
私もGoogleドキュメントで長い間インシデント状態ドキュメントを書いてきましたが、Googleドキュメントは記述体験はいいものの検索や社内wikiからのアクセシビリティ・アクセス管理などいくつかのストレスがありました。
ただ一方で kibela の同時編集機能は2023/12時点では信頼の置ける段階ではなく(時たまバグや誤操作で巻き戻る)、esa.ioの同時編集はkibelaよりは洗練されているもののそれでもたまに予想外の動きがあります(confluenceも同時編集ができるようですが使ったことはありません)。
個人的には、社内wikiサービスの同時編集の体験が十分に良ければそこで行うのが良いと思います(私はesaは実用可能なレベルだと感じています)。逆にそうでなければ、Googleドキュメントを使うのが無難でしょう。少なくともGoogle内の開発チームが使っているという実績があります。
インシデント状態ドキュメントのフォーマット、なんか微妙じゃないですか？ / もっといいやつありません？
公式な例として書かれているインシデント状態ドキュメントのフォーマットは、多くの人が微妙だと感じるようです。
# 障害のサマリ
# 指令所
# 障害対応メンバー
# 最新状況
# 解決の判断基準
# TODO
# 時系列
なぜ使いづらいのか考えると、おそらくこのフォーマットにはgoogle社内の固有事情や組織構造が反映されているからだと思います。とかく、みんなが使いにくいと思うためか、それぞれの会社で自分たちの使いやすいように定義しています。
私は以下のようにもっとシンプルなフォーマットを使っています。
# 障害の概要
# 最新状況
# 障害対応メンバー
# 時系列
# その他
この中で重要だと思っているのが時系列です。
他の3つは対応に参加するメンバーおよび障害対応チームの外向けの情報ですが、時系列だけは対応チームが障害を分析し、時系列から根本原因を探るための重要なヒントになります(多くの障害対応ではこれを記録しないため、これが有用であることを知らない)。
また、この時系列の記録はポストモーテムで改善点や問題点を洗い出すときにも非常に役に立ちます。
Discussion