全2回　スピードと安定性を両立～新たなシステム運用プロセス「SRE」とは？ 《連載:第2回》 事例で知る「強いSREチーム」の作り方

前半記事ではSREの概要を紹介しました。今回はSREの最初のステップとして重要な取り組みである“チーム作り”に関するポイントを、実際の企業事例を用いて紹介します。

国内企業のSREチーム作り事例

SREはGoogle以外にもAmazonやNetflixなどの海外ビッグテックが導入していることで知られていますが、日本でも2016年頃から株式会社メルカリのようなデジタル先進企業を中心に導入企業が増えているようです。今回はSREにおいて重要な“チーム作り”の参考になる、株式会社ジェイシービー(JCB)のSRE取り組み事例を紹介します。　

大手クレジットカード会社である同社は、ビジネスを迅速に市場提供することを目的に、ITプラットフォームとしてGoogle　Cloud上にクラウドネイティブな最新ソリューションからなるプラットフォームを構築。そこでアジリティと品質を両立したシステム（アプリ）開発を実現するべくSREチームを設立しました。ただし、チームと言っても一枚岩ではなく、下記のように役割別に2チームに分かれています。

・各アプリチームへSRE業務の支援・注入をおこなうチーム

モニタリングのためのダッシュボード構築や、SLI/SLOの管理・更新、CI/CD設計・構築などを担当

・全体の信頼性向上のためにルール作成・運用を規定するチーム

リリース方式策定・導入や、障害訓練の企画・遂行、ワークロードの脆弱性検知などを担当

このような2チーム体制は最初からではなく、アプリチームの増加に伴い支援業務が増え、全体的な改善などに割けるリソースが足りなくなったからとのこと。ちなみに、上記以外の「日常的なモニタリングと予兆監視」「オンコール対応」「トイル対応」といったベーシックな業務についてはSREチーム全員で担当しています。

もう一つ、同社のSREチーム作りのポイントとして挙げられるのが、チーム全体や個々の業務について次のような“ポリシー（方針、規定）”を策定していることです。

• チーム憲章…SREチームの使命や成功の定義を記載
• インシデントポリシー…インシデント発生時の役割や対応フローを定義
• ポストモーテムポリシー…ポストモーテムの作成基準や手順を記載
• オンコールポリシー…主にオンコール負荷の軽減方法を定義
• トイルポリシー…主にトイルの定義や計測方法を記載
• エラーバジェットポリシー…エラーバジェットを使い切ってしまった場合の対応などを定義

ポリシー策定のメリットは、突発的なトラブルが発生した場合もメンバー一人ひとりが即座に迷わず動けること。また、こうしたポリシーというのは往々にして形だけのものになってしまいがちですが、同社ではしっかりと定着させるために定期的な訓練・実践と見直しを繰り返しているということです。

※参考：SREチーム体制について｜株式会社ジェイシービー
※参考：クレジットカード会社における SRE 実践への取り組み｜Google Cloud（YouTube）

SREならではのカルチャー

SREはチーム作りにおいてもルールや正解はなく、企業規模やシステム構成、課題などによって最適な形は異なります。株式会社ジェイシービーが策定したポリシーも、Googleのベストプラクティスをベースにしつつ、自社に合わせてアレンジを加えているそうです。

また、SREチームのプロジェクトへの関わり方（エンゲージメント）にも、プロジェクトチームに組み込まれて開発・運用をおこなう「Embedded SRE」、開発には関わらず複数システムをサポートする基盤を提供する「Platform SRE」、各プロジェクトの開発チームへSREの浸透・サポートをおこなう「Enabling SRE」など、いくつかの種類があります。

しかし、形やアプローチは違っても重要なことがあります。それはSREチームに、従来の運用とは異なる“SREならでは”のカルチャーを根付かせることです。SREならではのカルチャーの要素としては、例えば次のようなものが挙げられます。

・データドリブン

GoogleのSREプラクティスを促進させるための4つのステップというWebページにも、「SREでは、可能な限りデータドリブン型を目指すため、組織に測定カルチャーを作ることがきわめて重要です」と述べられています。
そもそもデータが不十分であればSLI/SLOを定義できませんし、質の高いSLIを設定するためには様々なデータの収集が欠かせません。プロジェクトスタート後も、指標と実際のデータを基にスピードと安定性を担保する適切なアプローチを実践していくことが求められます。

・障害は仕組みの問題と捉える

ポストモーテムによる“振り返り”もSREにおける重要なカルチャーですが、その際に注意すべきなのが「個人を非難するのはNG」ということです。Googleも「非難をともなわない障害報告を記録するカルチャーがあること」をSREの原則として挙げています。
個人攻撃が習慣化するとインシデントの隠蔽につながる恐れがありますし、何より根本的な解決になりません。原因及び解決策は“仕組み”で考え、ヒューマンエラーを導かないプロセスやシステムに改善するほうが建設的です。

・他チームとのスムーズな協働

SREチームは他チームとの協働が不可欠です。開発チームはもちろんのこと、“信頼性”＝ユーザーにとって価値あるサービスを実現するためには、ビジネスサイドとの密なコミュニケーションも欠かせません。
特に開発チームとの協働をスムーズに進めていくために重要なのが、役割分担の明確化です。理由は、SREチームが便利なだけの“何でも屋”になってしまうのを防ぐため。開発チームの協働マインドを醸成するためには、オンコールやチケット対応などの運用業務を担当してもらうのも一策です。もちろん反対に、SREチームがシステムやサービスについての情報を開発チームと共有する機会を多く設けることも大切です。

以上、やや駆け足になってしまいましたが、SREの基礎知識を紹介してきました。当然ながら、一朝一夕に実現できるような簡単な取り組みではありません。しかし、システム／サービスにおけるスピードと安定性の両立は多くの企業にとって共通の課題。今後日本でもSREが広まっていくのは恐らく間違いないでしょう。