インフラチームの貢献範囲を広げるために何ができる？
「インフラチームの貢献範囲を広げていく」と宣言した村山氏だったが、まず最初にシステムの構成要素や動作を理解し、技術的にも情報的にも、受け身ではなく“主体的”に貢献できる土台づくりから始めた。
そこで村山氏は「1．構成の理解（静的な構造の可視化）」と「2．動作の理解（リアルタイムの挙動の可視化）」という2つのアプローチを取ることにした。
「1．構成の理解（静的な構造の可視化）」については、リバースエンジニアリング的な発想で、以下のような方法で既存リソースを可視化して理解を深めていった。
- 既存のAzureのリソースをTerraformのコードにインポートして構成を把握する。
- Azure Resource Graphでクエリを実行して、リソース情報を一覧で取得する。
- JSONで出力されたリソース構成情報を図示して、構成の全体像を可視化する。
「2．動作の理解（リアルタイムの挙動の可視化）」については、クラウドやサービスも含めたシステム全体を横断的に見られるフルスタックなオブザーバビリティツールがほしいと考え、「New Relic」の導入を決定。オブザーバビリティとは、「システムの全容をリアルタイムに把握して、改善できる状態にある能力」を指し、監視を進化させた考え方として昨今注目されている。
いくつかあるオブザーバビリティツールの中で、New Relicを採用した理由について、村山氏は次のように述べた。
「New Relicは必要な機能を必要なタイミングで段階的に追加していける柔軟性がある。New Relicの主な課金要素は『フル機能のユーザー数』と『投入するデータ量』の2つ。我々は当初システムの全容が見えていない状況だったので、最初から厳密に決めなくても始められる手軽さが魅力だった」。
New Relicを導入した当初は、教科書通りに外形監視から始めた。その後、ある程度モニターやアラートを定義したことで、サービスの異常にも気づけるようにはなったものの、不具合の解消に貢献できるようになるまでには、さまざまな試行錯誤があったという。その具体例として、村山氏は次の2点を挙げた。
-
障害時には自ら首を突っ込む
率先してTeamsで会議部屋を立ち上げ、関係者を巻き込む。会議ではNew Relicのデータをもとに、現状の可視化と事実共有を必ず行うようにした。「状況把握→対策検討→対策決定→実行」のプロセスを通じて、関係者の視点や意思決定基準を学んでいった。
-
復旧後はポストモーテム（障害後の振り返りレポート）を書く
不具合を学びの機会とするために、HRT（謙虚・尊敬・信頼）を意識しながら、ポストモーテムを書いた。チーム内で課題認識を共有できる上、インフラの領域外に関するデータの解釈があやしくても、プロダクトチーム内で共有すれば、自然にフィードバックをもらえて勉強になる。また、ポストモーテムは上層への報告時にも流用できるため、チームメンバーからも喜ばれた。
