こんにちは、中上(@_knakagami_)です。Observability Conference Tokyo 2025では企画・設計チームの一人として活動しています。開催まで残り1か月を切って、準備も佳境を迎えています。ぜひ多くの方に会場にお越しいただいて、楽しんでいただければと思います。
『オブザーバビリティとわたし』シリーズは、実行委員がオブザーバビリティに出会ったきっかけや、参加の思いを紹介する連載です。きっと共感してくれる方も、逆に新しい視点と感じる方もいらっしゃるはずです。これをきっかけに、このカンファレンスにも興味を持っていただければ幸いです。
きっかけ - SIerインフラエンジニアとしての経験
新卒でSIerのインフラエンジニアとして働き始めたのが、もう10年以上前です（早いものです）。担当顧客に対して提案から設計・構築、運用を一手に担うチームで、深夜のアラートエスカレーションに対応したり、週末の変更作業後に翌朝業務開始時刻まで待機したりすることもありました。顧客接点だからこその働き方、経験をしたように思います。
障害やパフォーマンス問題、サービスリリースや更新に際して、インフラリソースやエラーの確認などを求められます。ただ、「アプリケーションのパフォーマンスがよくない」という相談に対し、インフラリソースの確認では異常が見つからないということも珍しくありませんでした。メトリクスの推移に何らかの傾向を見つけたとしても、原因がインフラにあるのか、何らかの別の要因でリソースを有効に活用できていないのか判断がつかないということもあったように記憶しています。そしてトラブル時には大量のログをかき集めて、catして、grepして、lessかmoreして、目で追いかけるわけです。まあ大変でした。
よく覚えているのは、基幹系のシステムにおいてパフォーマンスの大幅な低下が発生して業務影響が生じた時のことです。事象発生の数日前にインフラのメンテナンス対応が行われていたことから、これがパフォーマンス低下の原因ではないかと疑われ、暫定対応と調査を連日連夜行う羽目になりました。暫定対応で問題を抑えるまでに結局1週間程度、原因を特定して対処が完了するまでには数か月かかりました。
しばらく続いた調査の結果、蓋を開けてみると、インフラ側の不具合や仕様が影響を及ぼしていたのは事実だったものの、実はアプリケーションサイドでも軽微な修正が行われており、不要だが非効率な処理が大量に発生し、結果的にパフォーマンス全体が低下していたことが分かりました（もちろん「なんでアプリ開発サイドでの変更を誰も調査していなかったんだ…」とは思いましたよ？ そりゃあ思いましたとも）。
この時に強く感じたのは、「インフラ視点だけでの調査には限界があるし、アプリケーションの観点から問題やパフォーマンスを追いかける術はないの？」「もっと簡単に問題を調査できるようにする仕組みを作れないの？」 といったことでした。
当時の私はオブザーバビリティという言葉にまだ出会っていませんでした。「オブザーバビリティ」という単語が当時の会社で聞こえるようになったのは5年ほど後のことです。ただ、こういった経験が「オブザーバビリティがないとダメだよね」という思いにつながっていったんだろうなと思います。
オブザーバビリティとの出会い
その後、ロールの変更なども経験しつつ、Kubernetes環境をオンプレ上で構築する仕事をしたり（当時はエンタープライズ企業での採用がまだまだ限定的でした）、IaCの仕組みを整備する仕事をしたりしていくと、自然と従来的な監視だけでは色々と大変だなあと感じることが増えていきました。
そんな折に、オブザーバビリティソリューションの導入支援のプロジェクトを担当することが決まり、初めて本格的にオブザーバビリティソリューションに触れることになりました。
検証対象のシステムに各種エージェントを導入し、どんなデータが取得され、何が分かるのかを確認していきました。APMエージェントの導入やトレースデータの解釈には手こずりつつ、ダッシュボードが自動で表示され、すぐに状態が分かるようになることには便利さを感じました。他方で「でも可視化だけなら別に他のツールでも十分だよなあ」などと冷めた見方もしていました。従来の監視と同じような設定を再現したいという顧客の声を聞きながら、「新しいソリューションを採用したのに、同じ監視を実装する必要があるのか…？」と議論したりしました。他チームへの横展開に際しては「なぜ今あるものを変えなきゃいけないの？」と困惑気味の反応をされることもしばしばでした。
当時の私は「何が便利になるのか」「なぜオブザーバビリティに取り組んでいった方がよいのか」「どう取り組むべきなのか」といったことをまだ上手に伝えられなかった、まだまだ知識も経験も足りなかったな、と反省させられます。
ただ少なくとも、試行錯誤が許されるこういった貴重な機会を通じて、上述した 「インフラだけではない、アプリケーションやユーザ体験の観点から状態を理解し、アクションを考えられるようになる」ソリューション・取り組みは改めて魅力的に映りましたし、こういった概念がより広まっていけばいいなと思ったのも確かです。徐々に、オブザーバビリティという概念や取り組みをより広めていくような活動ができればいいなという思いが強くなっていきました。
オブザーバビリティと出会ったその後
縁あって、オブザーバビリティソリューションの導入支援をミッションとするポジションを紹介いただき、今ではオブザーバビリティに関するお仕事をしています。オブザーバビリティに興味を持つお客様に対して、その現状をヒアリングしつつ、どこからどう始めるのがよさそうか、解決したい課題にどうアプローチするとよさそうか、といった点を議論しながらご提案やサポートをさせていただいています。
仕事の延長上で、例えば OpenTelemetry Meetupなどの運営をお手伝いしたり、コミュニティイベントにも参加させていただいています。コミュニティを通じて、よりオブザーバビリティに関する取り組みや概念が定着していけばよいと思い、今回の Observability Conference Tokyo 2025 の実行委員にも参加させていただきました。
仕事でもコミュニティでも、すこしずつですが、オブザーバビリティというものが広まりつつあること、他方、まだまだナレッジや実践がシェアされる機会が限られていることを感じます。今回のカンファレンスは、そういった状況を一歩先に進める良い機会になるのではないかと思います。
よいカンファレンスを作るには、多くの方に参加いただき、参加者の皆さんが何かをシェアし、何かを持って帰っていただくことが重要だと思います。ぜひ、同僚の方などもお誘いいただきながら、会場に足を運んで楽しんでいただければと思います！
