[アーカイブ] DevOps ~ Ops からの情報を如何に Dev で対応するか!今すぐ試せるハンズオンラボをやってみた


<オリジナル投稿 2013年2月13日 本ポストの情報はオリジナル投稿時点のものです。マイクロソフトの正式な見解や製品の仕様を保証するものではないことをご了承ください。>

Brian Keller のブログで、一連のシナリオを実施できる仮想マシン(VHD)とハンズオンラボ(Hands on Lab: HOL)のドキュメントが公開されています。

Team Foundation Server 2012 and System Center 2012 Operations Manager Integration Virtual Machine and Hands-on-Lab / Demo Script

今回は、このシナリオを可能な限り日本語化した環境で実施してみました。

試せる DevOps シナリオ

シナリオは、大きく分けて以下の3つに分類されています。

  1. System Center Operations Manager (SCOM) によるアプリケーションの監視
    ASP.NET MVC で作成された Web アプリケーションを監視します。
  2. 運用監視のアラートを TFS と同期
    SCOM と TFS の同期は、MTTR の改善にとって欠かすことができない重要なポイントとなります。他のソリューションでこれが行えるか考えてみてください。
  3. 運用監視から IntelliTrace の高度な診断情報を制御
    IntelliTrace はすでにデバッグのための便利機能という位置づけだけではなくなっています。本番稼動中のアプリの診断情報の収集から高度なデバッグへのシームレスな流れは、MTTR の改善を大いに推進します。

1. アプリの監視

image
これが、System Center Operations Manager (SCOM) の画面です(※元VHDにすでにSCOMがインストールされていたので、英語版になっていますが、当然日本語版が提供されています)。
監視対象として、MS関連だけでなく、Linux などもあることも注目してください。今回は、「.NET Application Performance Monitoring」です。クリックすると右側に監視対象が一覧表示されます。「Monitor FabrikamFiber website」とあるのがそれです。
このプロパティを開きます。
image
このように、パフォーマンスに影響を与えるときや、例外が発生したときにアラートが上がるように設定することができます。より詳細についても「Advanced Settings..」で設定できます。
image
たとえば、例外についても、これだけいろいろと選択ができます。各アプリごとに細かくアラートを上げるかどうかを設定できるのがわかります。今のが、サーバー側の監視設定です。
次にクライアント側の監視設定を見てみます。
image
監視するクライアントの IP アドレスを範囲指定することで監視を可能にしています。
次に、実際の監視画面を見てみましょう。
image
「Monitor FabrikamFiber website」を見てみると、今の状況がわかります。この画面だと、「健全」であることがわかります。
image
詳細ビューにすると各項目での健全度合いがわかります。今回は、Availability と Performance を見ていることもわかりますね。
どんなアラートが上がっているのかは、「Alert View」で見ることができます。
image
パフォーマンスの監視でのパフォーマンスカウンタの設定と監視は、「Performance View」で見ることができます。
image

2.Ops の運用監視のアラートを Dev の開発基盤と同期

SCOM には、 TFS とアラートの同期をとる機能が備わっています。
image
「TFS Work Item Synchronization」という項目です。ここで TFS の設定を行っておくわけです。詳細を見てみましょう。
image
image
TFS のプロジェクトコレクションの URL を登録し、チームプロジェクトを指定(区分も必要に応じて)たったこれだけで SCOM と TFS が同期します。楽な世の中になりましたね。それだけ MTTR の改善というビジネス要件に注力ができるということですね。
さぁ、ここからは、実際のアプリで例外を発生させる(要するにあらかじめ例外が発生されるように実装されている)ことでどのような動きをするのかを見ていきます。
image
はい。例外が発生しましたw
さっそく SCOM に戻って監視の状況を見てみます。
image
アプリケーション単位で(もちろんその上位の単位でも)監視状況をみることができます。詳細をみると NullReferenceExceptionが発生していたことがわかります。
このアラートをダブルクリックしてアラートのプロパティを開くと
image
状況がわかります。
ここで、TFS との同期の操作になります。
image
このアラートへの対応として、「Assigned to Engineering」を割り当てます。すると自動で TFS に「Operational Issue」作業項目を作成してくれます。これ、すなわち Ops から Dev への連絡が詳細情報含めて送信されたことになります。
さぁ、ここからは、Dev の対応です。Visual Studio を起動します(もちろん、TFS の Web I/F でも OK)。
image
「Operational Issue」についてのクエリがあれば、すぐに本番稼動中のアプリの状況を知ることができます。Visual Studio と TFS のエレガントな連携により、今仕掛中の開発作業があってもそれをクリック一回で「保留」にして、重要な本番環境での問題に対応することができます!
より詳細な、情報は、SCOM が提供する情報への URL をクリックすることで知ることができます。
状況を確認できたら、作業項目のステータスを「New」から「Accepted」に遷移させます。
image
TFS でこのステータスを変更すると今度は、TFS から SCOM に Dev 側は状況を確認したことを同期してくれます。先のアラートの状況をもう一度見てみましょう。
image
「Resolution Status」が、「Assigned to Engineering」から「Acknowledged」に遷移していることがわかります。
すなわち、不必要なコミュニケーションを削減して、ビジネス価値にまい進して、Ops も Dev も連携が仕組みを通じて円滑に行えていることがわかります。それぞれの作業を強引に中断する必要もありません。

3.本番稼動環境での IntelliTrace 活用

実は、SCOM 側で、本番稼動環境での IntelliTrace 診断データを収集しておき、アラートに組み込んでおいてくれています。SCOM から送られてきた Operational Issue の添付情報にしっかりと IntelliTrace のデータファイルが自動添付されています。
image
また、アラートからの情報として、顧客の優先順位や、プロダクトのナレッジ情報も自動で同期されています。
image
Dev 側にとっては、本番稼動中、ビジネスにどのような影響を与える問題が起きているのかを正しくリアルに知ることはとても大切です。「開発環境では再現しませ~ん」とすましていませんか?
そんなことはもう通用しませんよ。
IntelliTrace ファイルをクリックすれば、即時デバッグを開始できますゆえ。
image
ここで落ちていたわけですね。
ここで、さらなる情報の提供を依頼します。Operational Issue のステータスを遷移させます。「Awaiting evidence」です。
image image
ノートに、より詳細な診断データの含まれる IntelliTrace ログを要求してみます。
さて、SCOM に戻ってみると、アラートのステータスが、「Pending IntelliTrace」に変わっています。
image
アラートのプロパティで履歴を見ると
image
「より詳細なIntelliTraceログを頼む」と Dev 側からの要請がきていることも正確に把握できます。
これは、TFS からの要請としてすべてを見ることもできます。
image
このように、ステータス単位で、Dev 側から Ops 側に何か要請されていないか、Dev 側での対応がどこまで進捗しているのかを Issue 横断的に見ることができます。
ここからが、SCOM と TFS の連携の真骨頂です。SCOM側から IntelliTrace の診断を開始することができます。アラートを選択しておいて、
image image
これで診断を開始できました。便利ですね。さて、もう一度操作してみます。一連の操作を行い再現したら、「Collect IntelliTrace Snapshot」でデータを収集します。その後は、用が済んだので IntelliTrace も止めておきましょう。
データが取れたので、Dev に教えてあげます。アラートのステータスを「Assigned to Engineering」に戻します。
image
Visual Studio でみると新しいデータが届いていることがわかります。
image
さてさて、デバッグです。
image
image
先ほどよりも、圧倒的に情報量が多いことがわかります。
IntelliTrace デバッグの真骨頂!巻き戻せるデバッグです!
image
デバッグし、問題を改修できたら、Operational Issue のステータスを遷移させます。
image
これで Dev の対応はおしまいです。この問題については対応が終わりましたということがわかります(なお、本来は、CIを行い、ここは問題がなければ自動遷移としたいところですね。もちろんできます)。
あとは、Ops 側です。SCOM に戻り、アラートのステータスを確認します。
image
「Resolved」になってます。あとは、Closed に遷移させるだけですね。
image
Ops から Dev への MTTR の改善に寄与するソリューションを見てきました。ここでは詳しく触れていませんが、TFS があらゆる開発リソースを一元管理できているからこそここまでのスムーズな流れで対応が行えることに注目をしてください。これがいろいろなリポジトリが存在している Dev 環境では、こうはいきません。一つの障害に対処するだけなら根性でできますが、同時多発したり、過去の履歴、ナレッジをとなると複雑なシステムでは、情報も複雑化の一途です。
非常に簡単な操作ですので、手順書は英語ですが、苦になりませんので、ぜひ動かして体感してみてください。

Comments (0)

Skip to main content