ビジネス／開発／運用のサイロ化を防ぐ、イノベーションと信頼性を両立させる
SREとは？ Google Cloudがその基本を説明、JCBも導入／実践経験を紹介
信頼性の提供と顧客満足度の維持：詳細なポリシーを策定、あいまいさを排除
SREチームとしてももうひとつの取り組みが「適切な信頼性の提供と、サービスに対する顧客満足度の維持」だ。前述のように定めた信頼性（SLI/SLO）を日々どのように運用し、インシデントが発生した場合などにはどう対応しているのか。
笹野氏は、SREチームとしてまず取り組んだのは「ポリシーの策定」だったと説明する。グーグルの協力も得ながら、チームとしての使命やエンゲージメント内容をまとめた「チーム憲章」をはじめ、さまざまなインシデントの重要度や対応時のロール／フローをまとめた「インシデントポリシー」、インシデント対応完了後に根本原因や解決のためのアクションを記す「ポストモーテムポリシー」、そのほか「オンコールポリシー」「トイルポリシー」「エラーバジェットポリシー」などを一から策定したという。
「たとえばあるインシデントが発生したときに、その重要度はどのくらいで、誰がどんな役割を担うのか、どんな順番でどう動くのか――日々の運用の中で何かトラブルが起きても即時に動けるように、あいまいさをなくすためにポリシーを設けている。こうしたポリシーのフォーマットはグーグルのSRE本などにも書かれているが、実際に作ってみるとやはり自社特有の事情、たとえば開発メンバーの数に限りがあるとか、社員とパートナースタッフとで担える役割の範囲が違うといったことがあるので、それもきちんと組み込むことが大事だと感じている」（笹野氏）
グーグルのSREチームはさまざまな情報発信を行っている（グーグル山口氏スライドより）
こうしたポリシーに基づき、JCBのSREチームは2つの役割を担って活動している。アプリチームに対してインフラサービスの構築や改善を支援する「Platform SRE」と、アプリチームに参画してリリースエンジニアリングを主導する「Embedded SRE」という役割だ。なお、アーキテクチャの検討やレビューを行う「Consulting SRE」は別のチーム（アーキテクチャチーム）が担当している。
また発足当初は1チームだったSREチームも、現在はアプリチームと連携する「Diplomat（“外交官”）」と、全体のルール策定やプラットフォームの信頼性を高める「Sheriff（“保安官”）」の2チームに分かれている。これは、アプリチーム数の増加にともなってチームに対する支援業務が増え、全体の改善に取り組むリソースが足りなくなったため、あらためて役割を定めてそれぞれにリソースを割り当てた結果だという。
具体的には、Diplomatチームでは「モニタリングのためのダッシュボード構築」「SLI/SLOの管理／更新」「CI/CD設計／構築」を、Sheriffチームでは「リリース方式の策定／導入」「障害訓練の企画／遂行」「ワークロードの脆弱性検知」を担当する。またそのほかの「日常的なモニタリングと予兆監視」「オンコール対応」「トイル対応」といったものは、SREチーム全員で担当している。
このように現状では「チーム体制や運用のためのポリシー策定」「アプリチームに対する支援体制の構築」「定期的な障害訓練の実施」「トラブル対応のためのプレイブック（手順書）の充実」といったことは達成できている。一方で、今後に向けた課題としては「オンコール対応が可能なメンバーの拡充」「各チームへのSREの注入」「教育カリキュラムの拡充」を挙げた。
「『各チームへのSREの注入』というのは、SREチーム以外の各チームがSREの考え方をもって活動していく土台を作っていくというもの。先ほど説明したポリシーがアプリチームなどほかのチームでも独自で必要になるので、それを一緒に作っていく」（笹野氏）