誰もがミステリースリラーを好みます。もしかすると、全員とは言えないかもしれませんが…、ハリウッドは間違いなくそうでしょう。ホームズものであれ、ポアロものであれ、観客は凶悪犯罪の犯人を追い詰めるページをめくるようなプロットを楽しむのです。私も含めて多くの人が、物語の最後に謎が「解ける」ミステリー・スリラーを好みます。後に続くような展開は想像力をかきたてますが（クリス・ノーラン監督の『インセプション』のラストを覚えていますか？）、探偵小説に関しては、私自身は「誰がやったのか」というハッキリとした答えを知る方が好きです。
探偵小説が完結するためには、犯罪の証拠が非常に明確で、真犯人が明らかになり、うまくいけば裁判にかけられるような詳細が提供されることが理想的です。
技術的な運用と重要なサービスのアップタイム維持の世界では、ハリウッドの探偵小説に似た明確な対立が生じます。重要なアプリケーションのパフォーマンス低下や、最悪の場合、完全な停止すると、エンジニアは問題をできるだけ早く修正できるように、事件の（明白な）原因を見つけようと急ぎます。チームは、自由に使えるツールを使って、オーバーロードした計算リソース、ハングしたクエリー、最大化したキューを追跡して切り分け、問題を修正するために迅速な行動を起こします。
しかし、これは探偵小説の始まりに過ぎません。この種の探偵ミステリーは、目撃者が犯人を、たまたま悪い時に悪い場所にいた人物だ、と認識するものです。しかし、証拠が増えるにつれ、やがて「真犯人」は遠くから壮大な計画を操っている悪の黒幕であることが明らかになります。しかし、「探偵」エンジニアにとっては残念なことですが、根本的な原因を解決したところで、その根本的な原因を示す証拠を「知らずに」消してしまう可能性が高く、サービスの再起動やポッドの再展開によって貴重なフォレンジックの証拠を消してしまうことになりかねません。
タイミング悪く雨に降られ、最も有力な手掛かりとなるはずの指紋が洗い流されたことに気付いた主任警部が、身の毛もよだつような思いをしているのは想像に難くありません。
最近では、開発者と運用エンジニアは、できるだけ早くサービスを復旧させながら、インシデントのコードレベルの根本原因を特定するのに役立つ重要な証拠を失わないようにするという、綱引きのような作業に取り組んでいます。
でも、モニタリング・ツールはそのためにあるのではないでしょうか？答えは、「時々当てはまる」です。問題によっては、高度な観測ツールを使って、設定やコードレベルのエラーを追跡できます。しかし開発者は、監視ツールで取得できない、より詳細なデータを必要とする場合があります。ヒープ、スレッド、TCPダンプ、リソースを大量に消費するデータベースクエリー、スタックトレースなどのデータは、「真犯人」を特定するために使用されますが、ほとんどの場合、サービスの復旧には必要ありません。そして、このようなデータの収集には時間がかかります。インシデント発生時には、サービスの可用性を回復することが何よりも優先されることは周知の通りです。
残念ながら、コンテナ化されたアプリケーションとコンテナオーケストレーションの採用・普及は、主に2つの理由から、この綱引きのような闘いを激化させるだけです。
- マイクロサービスアーキテクチャーでは、Pod の再展開など、安全に可用性を回復するための方法がより迅速に提供されます。
- このような環境では、開発者や運用エンジニアがコンテナ・イメージの表面積を最小限に抑えたいため、利用できるデバッグ・ユーティリティが少なくなります。
このような対立する勢力への対応には、「瞬時のスピード」で行動し、エビデンスを取得・保存し、その後すぐにサービスを再開できるソリューションが必要です。
このようなソリューションは、PagerDutyのOperations Cloudで提供されています。問題を検出すると即座にトリガーされるランブックを活用することで、デバッグレベルの証拠を取得し、S3などの永続的ストレージサービスに送信し、既知の修正を使ってサービスを復元できます。PagerDutyのユーザーは、オンプレミス環境とクラウド環境の両方に対応した統合済みの大規模なライブラリと、増え続けるランブックのテンプレートにより、MTTRと技術的負債チケット解決のためのバグ再現にかかる時間の両方を削減し、一見大胆に見えるこの目標を達成できます。PagerDutyの既存ユーザーは、次のリンクからRunbook Automationのトライアルをリクエストできます。
https://www.pagerduty.com/contact-us/runbook-automation/
新規ユーザーはここからPagerDuty Incident Responseを開始することができます。
また、Automated Diagnostics Solution Guideでは、これらのランブックの例をいくつか紹介していますので、ぜひご覧ください。
今回は複数回に渡るブログシリーズの1回目です。次回のブログでは、Kubernetes Ephemeral Containersを活用してKubernetesで動作するアプリケーションから証拠を取得するためのテンプレートジョブをご紹介します。
探偵の仲間たちよ、好奇心旺盛であれ。
この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。
カテゴリー ：インシデント＆アラート
