デジタル トランスフォーメーションを成功に導く、JCB による SRE の活用方法

JCB では、2020 年からアジャイルな環境で価値の高いサービスを開発するプロジェクトを立ち上げました。既存のシステムを使わずにゼロから出島戦略としてスモールスタートする方針を打ち出し、チーム構成、リスク管理、アプリケーションとプラットフォームの開発プロセスなど、さまざまな側面の改善に注力しました。

この変革は、Google Cloud の Professional Services Organization (PSO) による直接的な支援及び、Google Kubernetes Engine (GKE)、Cloud Spanner、Anthos Service Mesh などの Google Cloud サービスによって実現し、ドメイン駆動設計とマイクロサービス アーキテクチャを適用しました。これらを用いたプラットフォームを「JCB Digital Enablement Platform (JDEP)」と名付け、現在多くのビジネス クリティカルなプロダクション サービスを支えています。

GKE の主な利点は、チームが簡単にリソースを追加し、完了したらリリースできることです。これにより、忙しい時期やオフシーズンに柔軟に対応できるようになります。一方、Anthos Service Mesh は、複雑な環境を簡単に管理するのに役立ちます。コンテナ化とマネージド サービスにより、保守が容易になり、バージョン アップグレードのサポートが提供されるため、より多くのサービスが生み出される将来に備えることができます。同時に、Cloud Spanner により、常に 99.99% の可用性が維持されます。

SRE プラクティス導入当初の目的は、ビジネス、開発、および運用の間の垣根を壊すことにあり、現在私たちは SRE プラクティスによってその信頼性を確保し、顧客満足度を維持することに重点を置いています。

私たちが実装した SRE プラクティスの価値を高めるために、いくつかのカテゴリを明確にする必要がありました。その中には、組織の文化と慣習を定義することや、作成された新しいモデルに適用されるポリシーが現場レベルでの実装に十分実用的であることの確認などが含まれます。これにより、サービスの信頼性をさらに高める体制を保つことが実現できました。

測定の文化を浸透させる

ここでは、「適切な信頼性」が鍵となります。従来の JCB の考え方は、「サービス障害があってはならない」「 SLA はできるだけ高く維持する」というものでした。お客様が本当に必要としている「適切な信頼性」とは何かを議論することから始めましたが、アプリケーションごとにユーザーが満足する信頼性のレベルが異なるため、思ったほど簡単ではありませんでした。

最終的に、ビジネス、開発、運用の各チームが特定の SLI と SLO を一緒に策定しました。これは、各チームが別々に議論していたら実現し得なかったことです。以前は信頼性基準が高すぎて、ビジネスでは低いサービス レベルについては妥協する必要があったためです。ユーザーのインタラクションにおいてシステムがどのように機能するかを理解するには、開発チームと運用チームのコラボレーションが必要です。

Google Cloud PSO のサポートのもと、すべてのチームが参加する一連のワークショップを 実施した後、組織内に変化が見られました。ビジネスチームはビジネス部門の他のメンバーに SRE の価値を伝えるようになり、開発チームと運用チームは自律的に協力し始めました。 短時間で多くのことを成し遂げ、Google のようなスピードで作業しているように感じました。

SRE を会社全体として理解することは、今後も前に進むためには必要なことだと考えています。現在、SRE の概念を社内に広めるための定期的に新規参画メンバーにはカリキュラム作成の上、研修を実施しています。

あいまいさの排除

Google Cloud PSO の協力を得て、チームのミッション、バリュー、エンゲージメント モデルを定義するチームチャーター（チーム憲章）を作成しました。また、インシデントレスポンスポリシー、事後分析ポリシー、オンコール ポリシー、トイル ポリシー、エラー バジェット ポリシーを含むポリシー ドキュメントを作成し、日常業務におけるあいまいさを排除しました。

たとえば、インシデントが発生した場合、我々はその重要度や各人に割り当てられた役割、従うべき順序を正確に特定できます。事後分析はいつ行うべきか、誰が担当するのか? エラー バジェットが使い果たされた場合はどうすればよいか? 問題が発生した場合、他のチームはどのように SRE に連絡すべきか? 文書化されたポリシー文書は、効率を劇的に改善し、チームが失敗から学ぶ文化を導入するように動機付けます。

このようなポリシーのフォーマットは Google の SRE book に書かれていますが、それを採用する際には、当社固有の事情を考慮する必要があります。単に既存のポリシーをコピーするだけでは機能しません。そのため、各チームの状況に合ったポリシーを策定することが重要です。

チームの再編成

これらのポリシーに基づいて、JCB の SRE チームには 2 つのサブチームがあります。 1 つは Sheriff と呼ばれ、プラットフォーム SRE として機能し、アプリケーション チームにインフラストラクチャ サービスを提供します。もう 1 つは Diplomat と呼ばれ、アプリケーション チームに近い立場で SRE のエッセンスを注入します。SRE チームとは別に、アーキテクトと呼ばれるチームもあり、各サービスのアーキテクチャ検討や新規サービスの導入検討を主導します。

SRE チームは、発足当初は 1 つの役割でしたが、現在は 2 つのサブチームとなっています。これは、アプリケーション チームの数が増えると、チームのサポート タスクの数も増加し、全体的な改善に取り組むためのリソースが不足する可能性があるためです。日常のサポート業務を邪魔されない人員を確保し、本業に専念することで効率が向上します。

両方のサブチームがオンコールの義務を分担していますが、契約上全てのメンバーが夜間対応出来る訳ではないため、オンコール業務に参加できない人のために、トイル シフトと呼ばれる仕組みを作成しました。これにより、日中帯のインシデント対応はトイラーが実施し、公平なチーム内の業務ローテーションを実現しています。

今後もビジネスの成長に合わせてSRE の仕組みを日々改善させていくことで、更なる信頼性の向上を実現していきます。

-株式会社ジェーシービー、デジタル ソリューション開発部 SRE チームリード兼プロダクト オーナー 笹野真平氏

-株式会社ジェーシービー、デジタル ソリューション開発部 部長 片岡亮介氏