はじめに

この記事は、株式会社asken (あすけん) Advent Calendar 2025の12/24の記事です。

こんにちは。askenのエンジニアリングマネージャーの西です。
askenのエンジニア組織ではDevOpsを推進しています。
(社内ではDevOpsやるぞとは明言していませんが)
つまり、エンジニアみんなでシステムを保守していくわけですが、
何もしないと一部のメンバーだけが保守をする体制になってしまう事が多々あると思います。
その原因は一部のメンバーが保守が好きなだけで、他のメンバーがそのタスクを避けるだけなのでしょうか？

原因はそれだけではありません。
基本的にはログ・メトリクスを見て、何かを判断・特定するということは非常に高度な技術力を伴います。
それを単純にできる人が担当しようとするとOpsが属人的になっていくのは自然なことです。

この問題を解消するための取り組みについて話したいと思います。
askenではオブザーバビリティのサービスとしてNewRelicを採用していますので、
NewRelicのDashboardsを活用して、みんなでメトリクスを見て保守できるようにするための考え方と活動について紹介します。

エンジニアみんなでアラート対応する (アラート対応の民主化)

askenにおけるエンジニアのレイヤーとしては大きく分けて、モバイル/バックエンド/インフラの3つの領域に分かれます。

みんなで保守をしていくためにはアラート・お問い合わせの発生時にレイヤーに関わらず、どのエンジニアでも調査へ着手できる必要があります。

原因が自分の専門外のレイヤーの場合もありますので、その場合でもアラートを受けた人がトリアージをして別のレイヤーのエンジニアへ調査タスクをお願いする必要があります。
そのためには結局、すべてのエンジニアがメトリクス・ログを見て原因の切り分けができる必要があります。

askenでは、誰かにアラート・お問い合わせ対応が偏らないようにできる限り順番で担当するようにしています。

順番に対応したぐらいでは属人性は解決しない

アラート・お問い合わせ対応を順番にしたぐらいでは、DevOpsなエンジニア組織ができると思ったら大間違いです。

アラート・お問い合わせを受けてから原因を調査することは非常に大変です。
askenではMAU(Monthly Active Users)が132万人(※2025年5月時点)に達しており、特にお昼の食事時はアクセスが集中する傾向があります。
単純に単一ユーザのエラーや、既知のアラートであれば調査・対応は簡単ですが、多くのアクセスを受けると、一筋縄では原因がわからない問題が多く発生します。

なぜ、エラー率が増えているのか？
なぜ、レスポンスが遅くなっているのか？

どこで何から調べるべきなのか途方に暮れる事があります。
そんな、問題を回避するための知の集約の場所がダッシュボード(Dashboards)です。

ダッシュボード(Dashboards)を作るだけでは問題は解消しない

NewRelicなどのオブザーバビリティのサービスを利用していてダッシュボード(Dashboards)の機能を使わないチームはほとんどいないと思います。
何をいまさら、そんな機能の紹介を・・・と。

色んなリソースのメトリクスを集めたダッシュボードを作ることでシステムの状態を確認できるようになるため一見、すぐに問題が解決できるようになると思いますが、実はどんなに見やすくメトリクスを集めても、そのダッシュボードを正しく読める人は、限定されています。

アラート・お問い合わせなど監視のために作成するダッシュボードは大きく分けると以下の2つの種類に分かれると思います。

システム全体の見える化 (SLI/SLOの監視)
- メトリクスを選ぶ際に、問題の現象・前提を限定しない
- 問題発生時は原因の場所を絞り込むために利用する
- 例) リクエスト量、エラー率、サーバー(CPU/メモリ)、DB(CPU/connection数) など
特定の現象の発生・機能を前提とした見える化 (特定領域の監視)
- メトリクスを選ぶ際に、問題の現象・機能を限定する
- 問題発生時に特定の対処をするために用いる
- 例) 新機能を開発した場合の正常性確認用、特定の障害(外部サービスの死活監視、デッドロックなど)

DevOpsな組織を作っていく上で、それぞれのダッシュボードで問題になるのは以下だと思います。

システム全体の見える化 (SLI/SLOの監視)
- 特定のメトリクスが悪化していても、そこから問題の解消へ辿り着けるエンジニアは限られる
- 結局、問題を解消できる一部の人しか情報を見に行ってくれない
特定の現象の発生を前提とした見える化
- システムのメトリクスの種類が多すぎて、何のメトリクスを監視するべきか選択が難しく一部の人しかダッシュボードの設計ができない

これら、メトリクスへの理解を深めてDevOpsな組織を育てるために、askenでは以下の取り組みを行いました。

メトリクスへの理解を深める活動

システム全体の見える化 (SLI/SLOの監視)への対処

システム全体を見える化しているダッシュボードをうまく活用できない主な原因はインフラに対する知識不足です。
各メトリクスがシステムのどういった挙動があった時に変化するのか知らないため、ダッシュボード見ても、何が起きているのか理解や仮説を立てる事ができません。
この問題を解消するために、インフラチームが隔週でモバイル・バックエンドエンジニアに向けて、メトリクスについて解説をする活動(Performance Working Group)を行いました。

PWG (Performance Working Group)とは

隔週30分で、その期間のシステムのメトリクスを見せながら、なぜこのメトリクスが動いたのかをインフラチームが解説する会。
- 会の目的
  - システムの傾向や直近起きた問題を参加者全員で把握
  - 集合知によるボトルネックの特定と改善アクションの策定
  - 問題に対する調査内容の共有
  - 問題の早期発見、既知の問題の対応状況の確認
  - アラート設定改善の機会提供
  - NewRelic や CloudWatch の使い方や見方の共有
会の中では主要メトリクスを見ながら以下のような解説をインフラチームから行ってもらいました。
- 例)
  - CloudFront/ALBでリクエスト数が跳ねてますが、このタイミングでテレビでの紹介があったためアクセス数が増えています。サーバーのCPUはあまり変わっておらず、DBの負荷(CPU)は問題ないけど、Commit Latency が高くなっているので、多少、レスポンスタイムが遅くなってますね。アクセスが集中した時にCommit Latencyが高くならないようにcommitの頻度を下げられる点がないか見直してほしい。
    - メトリクスの変化がなぜ起きたのか説明
      - テレビで紹介されたから
    - リクエストが増えた場合に連動して見たほうがよいメトリクスを解説
      - サーバー(CPU) ※問題なかった
      - DB (CPU) ※問題なかった
      - DB (Commit Latency) ※増えてた
    - 結果として、レスポンスタイムが遅くなった
    - 改善の方針の提案をする ※提案までは難しい場合は多いです。
このようにメトリクスを見ながら解説をしてもらうことで、何かの事象(リクエスト増加)が起きた時に、どこのメトリクスが連動して動いて、ユーザから見た結果(レスポンスの悪化)へ影響を与えたのかを理解してもらう事ができます。この活動を継続していく事で、みんなが事象とメトリクスの紐付きが分かりダッシュボードを見た時にシステム全体で何が起きているのか分かるエンジニアが増えてきます。
約2年間、この活動を継続したことで、みんなの理解が進んできたので、最近では対面での解説はせずに隔週でインフラチームからメトリクスに関するレポーティングを出して、エンジニアが気になる点があればフィードバックするようになりました。

特定の現象の発生を前提とした見える化

特定の現象だけを見える化するためのダッシュボードで発生する主な原因は技術力の不足です。

そんなことを言ったら、元も子もないのですが、この原因に向き合わないと課題は解消しません。

そのために行った活動としては以下のようにDashboardsの共有を通して、特定の領域の現象とその対処方法を伝えて、みんなの技術力を底上げしていくという活動です。

技術力の向上のためにダッシュボード(Dashboards)の共有が必要な理由

特定の現象を観測するために作成するダッシュボードの場合は、特にその領域に関する技術力が必要になります。

例えば、最近、asken内で作成・共有されたDashboardsとして、HikariCPのBusyCountとThreads Awaiting Countを見るためDashboardsがあります。
まれにレスポンスの遅延が起きる場合があり、原因としてサーバーで確保しているDBのコネクションプーリングが不足していたため、プールするコネクション数の見直しと事象の発生を検知するためにDashboardsを作成しました。

この説明は、バックエンドエンジニアでDBのコネクションプーリングに詳しい人なら、監視していなかったですか！とお叱りを受ける内容だとは思いますが、それ以外のエンジニアからすると何を言っているのかまるで分からんってなる内容だと思います。
この知識の差が、この領域における技術力の差で図の左側で記載している、「現象・事象」と「システム・技術の知識」の両方を兼ね備えて、かつ、どのメトリクスを観測することで監視ができると仮説を立てられるエンジニアです。
しかし、このレベルの知識を全てのエンジニアが押さえておくべきであるというのは少し無理があります。

そのために、最初の一歩はその領域が得意なエンジニアに突破してもらい、その結果として作成したメトリクスを共有。普通のエンジニアは、そのメトリクスを見て対処を通して理解を深めます。
次に同じような監視が必要になった際には、技術力の高いエンジニア側へ回るというサイクルができると理想的です。

これからの取り組みについて

これらみんなでOpsへ対応するという取り組みを通して、組織としてはOpsに関する意識が数年前とは比べ物にならないぐらい高くなりました。
デイリースクラム(朝会)で、ダッシュボード(Dashboards)、Errors(errors inbox)を確認して、新しい問題が起きている場合はその日のうちに解決に向けて動き出せるようになりました。

ただ、問題が発生してから対処をしている事も多くあり、いくら解決までの時間が短くしても実際にユーザさんに不便をかけてしまっているという事実は変わりません。
なので、今後のDevOpsの目標としては「ユーザさんより先にエンジニアが問題に気づく」という状態を目指しています。
リソースが不足する前に予兆の時点で検知して、問題が発生する前に対応をする。監視として、今より一つ高いレベルでメトリクス・閾値の設計を行い気づける仕組みが必要になります。

一部のエンジニアだけがアラート・お問い合わせをしていた頃では、この目標を設定したとしても現場のレベルに合っておらず、目標としては受け入れてもらえなかっと思います。
今のaskenのエンジニアではあれば、この目標を目指せるところまで成長できたと実感をしています。

まとめ

askenではDevOpsなエンジニア組織となるために、アラート・お問い合わせ対応を全てのエンジニアができる状態(アラート対応の民主化)を目指してますが、理想的な状態には一朝一夕では到達できません。
お互いに、ダッシュボードなど各種メトリクスを共有することでエンジニア同士がお互いの成長を支え合う事ができます。
結果として、誰か一人に依存することのないDevOpsなエンジニア組織へ少しずつ成長していけると思いますので、この記事が少しでもどこかの現場で活かされたら幸いです。