ペアーズで実践している、オーナー不在のサービスを引き受ける際の心得

著者：ogady（@_ogady_）
目次

はじめに

こんにちは。恋活・婚活マッチングアプリ「Pairs（ペアーズ）」 を運営する株式会社エウレカ SRE/Data Platformチームの@ogadyです。 主に、インフラやソフトウェアを運用・チューニングして、パフォーマンスや信頼性を改善しています。さらに、開発効率を支えるプラットフォームの構築や、AI・分析チーム向けのデータ基盤の運用も担当し、サービスの稼働と開発を支える重要な役割を担っています。 最近はボルダリングにハマっています。

みなさんは突然オーナー不在のサービスを引き受けるときになったら、どうするでしょうか？

誰もが使っている重要なシステムであっても、担当者が不在のまま放置されているケースは意外に多いものです。気づいた時には誰も管理していないオーナー不在のサービスの責任が急に、あなたに降りかかることがあります。 また、一人のメンバーに属人化していたサービスの担当者が、退職などで引き継ぎが急遽発生した場合、チーム全体で対応する準備が整っていないと、サービス運用に大きな支障をきたす可能性があります。

「自分はそんな事態にはならないだろう」と思うかもしれませんが、現実は違います。突如として引き継がれたサービスのトラブル対応に直面することは、SREなら一度は経験すると思います。（私は経験があります。）

本記事では、オーナー不在のサービスを引き受けた時に、私たちがどのように対応しているかをご紹介します。

1. 新しいオーナーの決定

オーナー不在のサービスを引き受ける際、最初に行うべき重要なステップは、新しいオーナーを決めることです。オーナー選定は、新たな属人化を避けるためにも、特定のチームをオーナーにアサインするのが適切です。サービスの技術スタックや立ち位置によって適切なチームは異なると思います。

新しいオーナーが決まったら、必要なアクセス権限や管理者権限を速やかに付与し、環境を整えます。

2. サービスの現状把握

オーナーが決まったら次はサービスの現状をドキュメントにまとめます。 エウレカでは基本的にSREチームがインフラリソースを管理しており、知見があるので、この段階でオーナーチームと共に情報収集を行います。

主に下記の観点で情報をまとめていきます。元々ドキュメントがある場合はリンクを貼るだけで済みますが、ない場合は新規で作成します。

システム構成

アーキテクチャ図やそれに準じるものです。 以下の情報が含まれていることがこの項目の期待値です。

  • システムを構成するコンポーネント（AWS例 SQS,VPC,Subnet,RDS,etc..）が網羅されていること
  • ネットワーク構成を理解できること
  • 提携外部サービスがある場合、提携サービスが列挙されていること
  • システムの依存が表現されていること
  • 各種アプリケーションログの保存先がわかること

データ設計

各種データベース（RDBMS、KVSなど）のデータ構造のドキュメントです。 以下の情報が含まれていることがこの項目の期待値です。

  • システムが保持するデータの論理設計が把握できること

開発方法・リリースサイクルについて

開発方法・リリースサイクルについて記載します。RepositoryのREADMEなどが充実している場合はそのリンクなどでも問題ないと思います。 以下の情報が含まれていることがこの項目の期待値です。

  • 開発を開始するのに必要な一連の手順が記載されていて、新規開発者がスムーズに開発を開始することができること
  • 実際のリリースまでに必要なテスト・検証フェーズやデプロイ方法について記載されていること
  • リリース時に必要なオペレーション（情報連携、ドキュメンテーション更新作業など）がわかること

機能仕様

サービスに実装されている機能について記載します。APIのドキュメント（OpenAPIドキュメントなど）や、シーケンス図など、できるだけ詳細な仕様がわかるのが望ましいです。 以下の情報が記載されます。

  • API Document/List
  • 代表的なシーケンス
  • 認証/認可
  • 想定クライアント（iOS/Android/Web Browserなど）

社内ステークホルダー

サービスの運用・開発に関わる社内のステークホルダーを記載します。 以下の情報が含まれていることがこの項目の期待値です。

  • プロダクトオーナー、リリース時の共有先、障害時のエスカレーション先などがわかること

連携サービス関連の契約窓口やアカウント/アクセス許可

サービスが、SaaSやその他サードパーティベンダーと連携している場合はその連絡先やSaaSアカウントなどを把握している必要があります。 以下の情報を記載します。

  • 外部と契約をしている場合、契約の本通やコミュニケーション先/担当者メールその他
  • 提携外部サービスのアカウント管理画面アクセス権限、APIアクセスのID/PW/Tokenなどの管理場所一覧
  • 先方にIPアドレスなどの許可を行っているかなどの情報

プライバシー

法律や社内規定に基づくアクセスコントロールルールに該当するデータが保持されている場合、記載します。 また、社内の分析基盤と連携するデータパイプラインなどがある場合も同じく記載します。

特殊な法準拠や外部向けSLA

PCI-DSS, JSOXなど、特殊な要件を有している場合、対応内容や資料を記載します。 また、外部向けに約束しているSLAなどがある場合もこの項目に記載します。

外部要因で発生するタスクや、定期イベントタスク

ミドルウェアなどのバージョンアップ、サードパーティベンダーのメンテナンス時に必要な項目や、リソースの棚卸し/定期メンテナンスなどを定期的に実行する要件がある場合に記載します。

RunBook/Playbook

運用に必要なRunbookなどがすでにある場合はここに記載します。ない場合は、引き継いだ後の運用の中で頻出する運用作業について、運用ルールを新たに定め、ドキュメント化します。 以下の情報が含まれていることを期待します。

  • 頻度が高い問い合わせパターンの対応マニュアル

Critical RunBook/Playbook

システム障害時の対応手順やその際のエスカレーション先などを記載します。

以下の情報を含む格納先のリンク

  • システム停止時の影響範囲
  • メンテナンスなどでシステムを停止するために必要なコミュニケーションと停止手順
  • データが破壊されて復旧する必要がある場合の復旧手順

3. モニタリングダッシュボードとアラートの再設定

オーナー不在のサービスは、特定のイベントや問題が放置されがちです。そのため、監視とアラートの設定を再確認し、重要なシグナルに対するアラートが適切に設定されているかを確認します。

  • モニタリング用のダッシュボードの見直し、作成: ダッシュボードを作成し、定期的なパフォーマンスモニタリングやインシデント調査が可能な状態にします。
  • アラート閾値の見直し: システムの負荷状況やトラフィックに基づき、アラートの閾値を適切に調整します。
  • 監視の追加: 不足している監視項目があれば、新たにメトリクスを追加し、潜在的な問題を早期に検知できるようにします。

私たちは基本的にダッシュボード、アラートをDatadogに集約してTerraformで管理しているため、SREがサポートに入りながら構築していきます。 Datadogにそもそもメトリクスが取り込まれていないケースや、適切なモニタリング項目が設定されていない場合には、まずそのデータを取得するための設定を行います。これには、アプリケーションやインフラのメトリクスを収集するためのインテグレーションの設定や、外部サービスからのログ・メトリクスの取り込みを行う必要があります。

具体的には下記のような手順で進めます。

重要メトリクスの定義

サービスの正常性やパフォーマンスを確認するために重要なメトリクスを定義します。

一般的なゴールデンシグナル（レイテンシー、トラフィック、エラー、サチュレーション）に加えて、サービスの特性や利用しているクラウドサービスに応じた特定のメトリクスも重要になります。

例えば、バッチ処理がメインのサービスであれば、「正しく処理は完了したのか」、「処理は期待する時間内に完了したのか」、「リソース不足は起きているのか？リソースが過多すぎないか？」などをメトリクスとして収集できるようにし、モニタリング可能な状態にします。詳細は、ペアーズのバッチ実行基盤の品質を定義して改善を続けている話をぜひご覧ください。

アラートの設定と調整

各メトリクスに基づき、適切なアラートを設定します。アラートが多すぎるとノイズが増え、重要な問題が見逃される可能性があるため、常にアクショナブルなアラートとなるように心がけます。

アラートにはRunbook/Playbookのリンクを付与するなど、トリアージの負荷を軽減するようなアラート設計を行います。

モニタリングダッシュボードの作成

モニタリングダッシュボードは、チームがリアルタイムでサービスの状態を把握し、異常を検知できるようにするために重要です。Datadogを使い、視覚的に理解しやすいダッシュボードを作成します。

ダッシュボードは定期的なパフォーマンスモニタリングによるパフォーマンストレンドの把握やボトルネックの発見、インシデントの原因調査のために活用します。

オーナー不在時の対応プロセスの標準化

エウレカでは、このようなフォーマットのドキュメント作成を最初に共同で行う事で、引き継ぎを受ける側・する側の負荷軽減をしています、オーナー不在のサービスを引き継ぐプロセスを標準化しておくと、急な担当者不在や引き継ぎ時における混乱を最小限に抑え、チーム全体で一貫した対応ができるようになります。一方で、このドキュメント自体は抽象度が高いもののため、実際にはコードリーディングなどによる挙動の理解はもちろん必要になってきます。

また、このドキュメントの内容はそのままサービスのドキュメントとして運用可能です。そもそも、サービスを新規構築する時にこのドキュメントに準じたものが作られていることが理想です。そうすれば、オーナー不在のサービスでもある程度の品質で運用をスタートさせることができます。エウレカでも基本的にこのようなドキュメントを開発時に作成することを受け入れ条件にするようにしています。こちらについては、プロダクション運用に必要な項目の定義とドキュメント化の実践に詳しく記載しております。

まとめ

本記事を通して、オーナー不在のサービスを引き受けた際の対応について、具体的なステップや心得を説明しました。サービスの現状把握から新しいオーナーの決定、監視とアラートの再設定、そして対応プロセスの標準化に至るまで、スムーズに引き継ぎを行い、安定した運用を実現するための方法を紹介しました。

しかし、これらの対策を講じたとしても、長期的な課題は依然として残ります。例えば、サービスが成長するに従い、ドキュメントや運用プロセスの見直しが必要になる可能性もあります。サービスや仕様・体制の変化とともに常に継続的にメンテされることが重要です。

この記事が、オーナー不在のサービスを引き継ぐ際の一助となり、より強固で持続可能な運用体制の構築に役立てばと思います。