こんにちは。@nari_exです。
創業直後からSREのことをより多くの人に知ってもらおう！という目的でもう一度読むSREというSRE本精読系(?)Podcastをやっています。先週の収録で31章に到達しました。いよいよ完走間近です。
本記事では、SRE本の30章を読む過程でみつけたプラクティスについて紹介します。このプラクティスは、Topotal SRE（SRE as a Service）の実績としても複数みられるものなので、もしかしたらすでに行っている方も多くいらっしゃるかもしれません。
SRE本の30章のあらすじ
Postvitamというワードが出てくるのは章の末尾の方なので、先に30章 Embedding an SRE to Recover from Operational Overloadの概要をおさらいします。
本章では、過負荷に陥ったチームに対して一時的にSREを埋め込む（Embedding）することで、健全な運用体制へ導いた事例が紹介されています。 embedded SREとして業務に取り組んでいる方や運用業務に追われて戦略的な改善ができていない方におすすめの章です。
プラクティスは3つのフェーズに分けて整理されています。
- フェーズ1: 状況を把握する
- 重要課題を特定（ストレスの最大の原因を特定）
- フェーズ2: コンテキストの共有
- Postmortem（単に障害対応するだけでなく、運用構造を見直す視点）の推進と改善の方向性の提示
- フェーズ3: 変革の推進
- 改善を行いながらSRE基本原則を定着させる
そして、最後にまとめ（Conclusion）があります。今回紹介するPostvitam（ポストヴィタム、ポストビタム）は数行程度のまとめ部分に記載されています。
Postvitamとは
Postvitamとは、なんらかの活動がうまくいった場合に、その成功要因を分析するプラクティスです。
この取り組みにより、良好な状態を維持したり再現することができたり、失敗しないための工夫を学ぶことができます。Postvitamレポートは、成功要因を分析した結果をまとめた文書を指します。
得てしてふりかえりというものは、なにか失敗したり損失があったときに求められることが多いわけですが、成功した場合もその要因を冷静に分析することでチームのサステナビリティを高めたり、問題の兆候を把握して予防することに役立ちます。
具体的には以下のような視点で振り返ることを想定しています。
- なぜ成功したのか/失敗しなかったのか
- 意図した結果の範囲と運によってもたらされた範囲はそれぞれどこか
- 次に同じことが起きても成功するか
SRE本を元にしたPostvitamの解説
以降ではSRE本の30章の本文を引用しながら、私の解釈も含めてPostvitamという表現がなされた背景を説明をします。
Your final task is to write an after-action report. This report should reiterate your perspective, examples, and explanation. It should also provide some action items for the team to ensure they exercise what you've taught them. You can organize the report as a postvitam, explaining the critical decisions at each step that led to success.
最終タスクは、事後報告書を作成することです。この報告書では、あなたの視点、具体例、説明を再確認する必要があります。また、チームが学んだ内容を実践するために、具体的な行動項目を提示する必要があります。報告書はポストヴィタム形式で作成し、各ステップで成功に導いた重要な意思決定を説明してください。
上記の文は、SREが変革を終えて一時的に携わったチームを離れるときになにをすべきかを示したものです。具体的には、SREの視点・例・説明を再掲したり、教えたことを確実に実行できるようにアクションアイテムを提示することが期待されています。そして、最終的にチームが自律的に改善し続ける状態に到達するように指南すべきであると書かれています。
この章を読んだらわかる通り、SREの基本原則をチームに根付かせる重要性が何度も強調されています。そのため、本書が理想とするEmbedded SREの本懐は（課題解決の代行者ではなく）チームが自己調整（self-regulate）するために必要なSREの原則を教えることだと解釈しています。
もし上記の解釈が正しいのであれば、「〇〇が起きていたので〇〇をしました」というイベント情報をレポートに書くのではなく、なぜそうしたのか（どのような意図だったのか）を積極的に伝える必要があるでしょう。
このようにSREの考え方を伝承するためには、Postmortemのようにインシデントをトリガーにしたふりかえりも重要ですが、それに加えてさまざまな成功事例に対して適用しやすいPostvitamというプラクティスを実践することも重要そうです。
PostmortemとPostvitamの比較
「post-mortem（死後）」に対して「post-vitam（生後）」というラテン語的な造語だとすると、「死んだ後（停止後）」ではなく、“生きている状態での振り返り” を比喩的に指した表現といえます。SRE本ではPostmortemとの対比をするためにあえて用いた表現だと思います。
SRE本の30章の例では、「過負荷のチームを正常化するプロジェクトがうまくいったあとで行うふりかえり」を行うシーンで Postvitam が例示されましたが、ほかにも利用ケースはありそうです。
たとえば、Postmortem は「システム停止後に行われるふりかえり」ですが、これとは対照的に「システムが正常に動作している状況で行われるふりかえり」として Postvitam を行う価値はありそうです。
Postmortemに少なからず障害の根本原因分析（Root Cause Analysis = RCA）の文脈があるように、Postvitamには成功の根本原因分析の文脈があると思います。結果をもたらしたメカニズムを明らかにすることは、エンジニアリングを行う上で重要なプラクティスです。
SRE as a Service の例
Topotalは創業以降、企業向けのEmbedded SREとしてSRE as a Serviceを提供し続けています。
SRE as a Serviceの目的の一つは、お客さまがビジネスを遂行する上で必要不可欠な仕組みづくりを支援することです。逆にいえば、仕組みが整い内製化の道筋ができた先ではTopotal SREの役目を終えたことになり、相互が納得したかたちで解約に至ります。
解約時はお客さまに対して引き継ぎを行うのですが、その際には「どのような考え方で取り組んでいたのか」や「〇〇が起きた時はどのように対処するとよいか」などを伝える必要があります。この引き継ぎ作業時に発生するドキュメントは、まさに今回紹介した Postvitam レポートに近いものでした。
レポートを書こうとするとわかるのですが、あとからすべてを思い出そうするのは非常に困難です。そのため、プロジェクトを遂行しながら定期的にドキュメントにまとめたり、IssueやPull RequestのdescriptionにWhy, Whatを明確に書き記しておくことをおすすめします。Postvitamレポートを作成する観点においても、要所でADR（Architectural Decision Records）やDesign Docを書くことはやはり重要だと思います。
まとめ
インターネット上を調べた限りではSREの文脈でPostvitamを取り上げている記事が見つかりませんでした。そういった意味では、PostvitamはSREの正式な用語として厳密には存在していないかもしれません。
今回の記事を客観的にみると、シンプルにふりかえりを行うことの重要性を説いているようにもみえます。本質的には、PostmortemやPostvitamなどのプラクティスにこだわらず、再発防止や成功の継続性獲得のために事後分析を行い、積極的に学びを得ようとする姿勢が重要なのだと思います。
最後に
TopotalはSREを軸にしたスタートアップです。
SRE as a Serviceをともに提供するSite Reliability EngineerやWaroomを開発するバックエンドエンジニア（Ruby on Rails）を募集しています。SREのプラクティスを用いて世の中の開発・運用の現場を一緒に変革していきましょう。
もし気になる方はカジュアル面談のお申し込みをお願いします！
