InstanaにおけるPipeline Feedbackを用いたシステムの開発・運用効率化を考える（理論編）

## 本記事の趣旨

はじめまして。私は普段、APMであるInstanaを用いてシステム開発・運用に関わることを試行錯誤しています。
今回は、数あるInstanaの機能の中でも、**Pipeline Feedback** をピックアップして、この機能の使ったユースケースをご紹介します。
[Instanaのユーザーコミュニティ](https://instanautsjp.connpass.com/)で、とある方がご紹介されていたことをきっかけに、いろいろ調べたり、妄想を膨らませていたりしているうちに、だんだん楽しくなってきたためアドベントカレンダーへ投稿することにしました。
なお、別の記事で「[実践編](https://qiita.com/mumumu_666/items/706fbbb9cb47d79290c3)」を題して、Pipeline FeedbackのAPI Tokenの取得や設定方法などをご紹介予定です。

## Pipeline Feedbackとは

[公式ドキュメント](https://www.ibm.com/docs/en/instana-observability/current?topic=capabilities-pipeline-feedback)通りですが、自分なりに噛み砕いて平たく言いますと、Pipeline Feedbackを使うと **マーカーを打つこと** ができます。
InstanaのAPIを用いることで、任意の時間に、任意のメトリクスに対して、ロケットマークを打つことができます。

![image-1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/359643/57b75cdc-6411-58fa-3b19-fe75233ba272.png)


「なんだこれだけかよ！」と思った方も多いのではないでしょうか。
私がこの機能を知った時、「単純に見えるこのマーカー、実は様々なシーンで使えるのでは？」と脳裏をよぎりました。

## Pipeline Feedbackのユースケース

### 想定するペルソナ

下記の3つの役割を持つ人を想定します。

- **開発チーム**
    - アプリケーションを開発・リリースする
    - インフラの構築・設定をする
- **運用チーム**
    - アプリケーション・インフラを監視する
    - 問題発生時にトラブルシュートする
- **システム管理者・プロジェクトマネージャー**
    - 基本的には手を動かして開発・運用はしない
    - プロジェクトを円滑に進める
    - 問題発生時にお客様へご報告する

### ユースケース1: パフォーマンステスト

アプリケーションテストをする時、テスト開始のタイミングでPipeline Feedbackを用いることで、InstanaのGUI上で、パフォマンステスト状況と共に、開始タイミングも確認することができます。
このようなシンプルな方法でも、**開発チームは、<font color="#1e90ff">テスト開始時刻を手元でメモすることや、後からログを漁って確認する必要がなくなるため、確認稼働を削減できます。**</font>

また、**システム管理者・プロジェクトマネージャーは**、問題なくパフォーマンステストが行われているかを、わざわざ開発チームに問い合わせることもなく、InstanaのGUI上で確認できるため、<font color="#1e90ff">**テスト状況把握・問い合わせをする手間も削減できます。**</font>

![image-2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/359643/e1274209-eb6e-4b1a-581a-6fc24d895102.png)


### ユースケース2: アプリケーションのリリース・計画作業後の正常性確認

アプリケーションの新規リリース時や計画的な作業を実施するタイミングで、Pipeline Feedbackを用いることで、作業後の正常性確認をInstanaで行うことができます。システムの規模が大きくなればなるほど、新規機能追加、バグ修正のためのアプリケーションのリリース回数や計画作業が多くなりがちです。それらの作業を1つずつ管理することは容易ではありません。1日単位や1週間単位でまとめて作業を管理・運用しているプロジェクトもあるのではないでしょうか。
このような状況の時、Pipeline Feedbackを使うとそれぞれの役割にとってどのようなメリットがあるかを考えてみます。

**開発チームは**、アプリケーションのリリース・計画作業後の正常性確認、つまり本番稼働中のシステムに対して影響していなかったかどうかを、対象のテクノロジーにおけるメトリクスにPipeline Feedbackのマークされた時間を確認することで、問題の有無を判断することができます。その結果、<font color="#1e90ff">**作業後に何らかの問題が発生した場合でも、それは自分の作業が影響したものなのか、他のチームの作業なのかを判別しやすくなります。**</font>

**運用チームは**、開発チームの作業後にしばらくして問題が発生した場合でも、どの作業に問題があったのかを正確に把握することができ、それにより<font color="#1e90ff">**どのサービスに影響があり、何を切り戻せば良いのかの判断がしやすくなります。**</font>

**システム管理者・プロジェクトマネージャーは**、より細かい粒度の時間単位でも、どのようなアプリケーションのリリース・計画作業をしているかをそれぞれ管理できるようになります。作業終了時にもマーカーをつける運用にすれば、まだ作業完了していないチームに気づくことができ、<font color="#1e90ff">**不足の事態が発生していないか、その作業手順に問題はなかったのか、など早期に問題を認識しやすくなります。**</font> また、問題発生時は直接機器にログインせずとも問題となった作業を把握できることはもちろん、お客様や社内へ問題報告する際も、<font color="#1e90ff">**時系列や影響サービスをInstanaで把握することができるため、確認稼働や報告書作成の手間を削減することにもつながります。**</font>

![image-3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/359643/dd218128-7fe3-49ca-a628-d8370226ab98.png)


## Pipeline Feedbackの可能性

ご紹介したユースケースは序章にすぎません。
例えば、既存の CI/CD ツールとの連携によりさらなるユースケースが見込めます。

たかがマーカー、されどマーカー

みなさんもPipeline Feedbackの可能性を探ってみてはいかがでしょうか。

## 参考資料

- [Instana 公式ドキュメント](https://www.ibm.com/docs/en/instana-observability/current?topic=capabilities-pipeline-feedback)
- [Instana API リファレンス](https://instana.github.io/openapi/)
- [IBM コミュニティブログ](https://community.ibm.com/community/user/wasdevops/blogs/randy-langehennig1/2021/05/23/how-to-integrate-ibm-urbancode-deploy-with-instana)