Blog
ブログ

2019年9月28日  (更新日:2022年5月19日)

AIと機械学習を利用してHarnessとPagerDutyでの継続的デリバリーを強化する

一見すると、機械学習を継続的デリバリー(Continuous Delivery)に適用するのは、ハンマーでピーナッツを割るように聞こえるかもしれません。 つまり、デプロイメントの自動化は実際どれだけ難しいのでしょうか?

調べた結果、それは私たちが考えるよりも複雑です。

新しいデプロイメントをプロダクションに移すと、通常2つの結果になります。

サービスは起動し、すべてがOKだと思う。 サービスは起動せず、何もかもが壊れてる。

現実には、上の2つの点は、組織の95%がデプロイメントの成功を測る方法(上=良い、下=悪い)を表しています。 幸せなPagerDutyのお客様は、2番目のシナリオ(携帯電話にアラートとインシデントの嵐が届く状況)はよくご存じです。 しかし、シナリオ1は、誤解を招く可能性があります。サービスが動いているからといって自動的に健全性、性能、品質がOKだという証拠ではないからです。

手動でデプロイメントのヘルスチェックをする短所

Harness(訳注:Continuous Delivery-as-a-Service プラットフォームのサービス提供会社)で最初の25人の顧客から私たちが学んだ1つは、大部分の組織では一般的に3〜5人のエンジニアがいて、手動で実稼働展開を確認す​​るのに1時間以上かかるということです。例えば当社の顧客のBuild.comは5-6人のチームリーダーがNew RelicとSumo Logicのデータを手動で分析するのに1時間かかっていました。これは通常、複数のコンソール/ブラウザウィンドウを開き、bashスクリプト、アプリケーションパフォーマンス監視、ログ分析ツール間でコンテキストを切り替えることを意味します。

人間の脳は短期記憶を使う際は8-10​​項目しか集中できず、様々なシステムからのすべてのデータが集中していることを考えると、2018年の人間は非常に簡単にミスをします。数十万回の時系列メトリックと、展開後に数百万回のログエントリーがあることを考えれば、 手作業による分析とヘルスチェックは難しい問題です。

AIと機械学習がヘルスチェックを支援するようにする

Harnessでは、ソフトウェアアーチファクトのプロダクションへのデプロイメントを自動化するだけではありません。 AIや機械学習を使ってヘルスチェックを自動化します。 私たちはこのContinuous Verification(継続的検証)と呼んでいます。

主に隠れマルコフモデル、記号集約表現(訳注:Symbolic Aggregate Representation。いわゆるSAX)、k-平均法クラスタリング、およびいくつかのニューラルネットなどの教師なし機械学習アルゴリズムを使用して、APM(アプリケーション性能指標値)とログデータから異常や性能低下の検出を自動化します。

Harnessは、新しいソフトウェアアーチファクトを数秒で展開して、任意のAPMツールまたはLogツールに接続し、パフォーマンス(応答時間/スループット)と品質パースペクティブ(エラー/例外/イベント)から、アプリケーションの動作モデルを自動的に生成できます。

Harnessはこれらのモデルを以前のデプロイメントと比較し、新しい異常や性能低下を即座に示します。 人間が処理や分析をするのに要する時間に比べ、機械学習アルゴリズムでは数秒しかかかりません。

たとえば、以下のスクリーンショットはAppDynamicsのAPMデータをHarnessで検証した結果です。

上記の画像では、Harnessが展開後に2つのビジネストランザクションがパフォーマンス低下を示していることが分かりました。 以下の図では、「Request Login」という1つのトランザクションで、応答時間が31msから165msに増加したことを示しています。 この分析はすべてAI と機械学習で自動化されています。

SplunkからのアプリケーションログについてHarnessが検出したエラー/例外の異常の別の例を次に示します。

赤い点は、デプロイ後からアプリケーションログに入るようになった新しいエラーを示します。 灰色と青色の点は、すべてのデプロイで通常観察されるベースラインのイベントまたはエラー/例外を表します。

ハーネスは、k-平均法クラスタリングといくつかのJacardおよびコサイン距離演算(訳注:ふつう、集合の類似度を示す)を使用して、これらのビジュアルを生成します。 任意の点をクリックすると、イベントのスタックトレースと根本的な原因も表示されます。

AI / 機械学習インテリジェンスによるロールバックの自動化

Harnessは、Continuous Verificationのインテリジェンスを使用して、デプロイメントのロールバックを自動化することもできます。 Harnessは、Dev / DevOpsチームがより速く展開できるようにしながら、新しい異常や性能低下に遭遇するたびにロールバックできるようにするセーフティネットと考えてください。

今後のPagerDutyのHarnessサポートにより、各組織はPagerDutyを通知チャンネルとして、また検証ソースとして使用することができます。 たとえば、Harnessはデプロイの前にPagerDutyに対して、運用中に発生しているアクティブなインシデントがあるかどうかを確認するクエリを送信できます。Dev / DevOpsチームが最後に望むのは、本番環境に展開することです。

まとめると、Harnessは、 継続デリバリー・サービス( Continuous Delivery as-a-Service )を提供することで、各組織が本番環境でエンドユーザーへのソフトウェアの展開と配信を自動化することを支援します。私たちは、顧客が何かを壊すことなく迅速に動けるよう支援します。

Steve BurtonはHarness.ioのCI / CD DevOps Evangelistです。 Harnessに入る前は、AppDynamics、Moogsoft、GlassdoorでGeekをやっていました。 彼は2004年にSapientでJava開発者としてキャリアをスタートしました。 テクノロジーで遊んでいないときは、通常はF1を見たり、インターネットで車を研究したりしています。

本記事は米国PagerDuty社のサイトで公開されているものを日本語訳したものです。原文はこちらです。

続きを読む
インテグレーション&ガイド
2018年5月28日  (更新日:2022年5月19日)

DNSmetrics:複数のDNSプロバイダから統一したメトリックを集める

マネージドDNSプロバイダーからメトリックを収集して変換するためのツールをオープンソース化して皆様とシェアできたことを喜びに思います。私たちは現在DNSmetricsを使用して、SREチームの監視、警告システムに標準形式のデータ提供を行なっておりますが、この方式が皆さんのお役にも立てると信じております。

DNSの主な役割

PagerDutyでは、サービスの信頼性と可用性を重視しております。可用性は私たちの内部インフラの設計に重要であるだけでなく、私たちが所有していないインフラにも同じ要件を適用する必要があります。 PagerDutyは外部のプロバイダーをいくつかの不可欠なインフラコンポーネントに活用しています。本日はこれらの1つについて説明します。

ドメインネームシステムは、pagerduty.comのようなドメイン名を、APIやWebアプリケーションが要求する数字のネットワークアドレスに翻訳します。アドレスは変わる可能性があるため、ほとんどのシステム(とほとんどの人)は数字ではなく名前を使用します。そのため、私たちのドメインの DNSが利用できない場合、多数のお客様は私たちのサービスに到達できなくなるので、DNSを使用可能にして正しく構成することが重要です。

DNSプロバイダはこれを理解し、高可用性システムのグローバルネットワークを維持しています。しかし、DNSの性質上、大規模なシステムは間違いなくDoS攻撃の影響を受けやすくなります。実際、有名なマネージドDNSプロバイダの大部分は、過去数年間に少なくとも1つの大きなサービスの混乱を経験しています(例:1、2、3、4)。PagerDutyは過去に単一のプロバイダを使用していましたが、我々はもはや十分に頑強であるとは言えません。現在ではアクティブ―アクティブ構成(各プロバイダーが運用トラフィックの半分ずつを担当する)で、DNSニーズに対して2つのプロバイダーを使用しています。

DNSメトリックを何のため構築し、どのように役立つのでしょうか

両方のDNSプロバイダに監視と警告を設定するのは難しいことでした。各プロバイダは、管理インタフェースでオーバービューとレポートを提供していますが、公開されているメトリックの選択、異なるインタフェース内の同じデータの場所、平均とレポートに使用される時間間隔など、レポートはプロバイダによって異なります。プロバイダやゾーン全体でDNSの状態のスナップショットを得るために多くの努力とさまざまな表示画面が必要で、我々はアラート機能のために自らのツールを使用したいと考えました(いずれのプロバイダーも当社の総トラフィックの一定割合以上を取得していないことを追跡します)。

私たちにはもっと良い解決策が必要でしたが、利用可能なものはなかったので、構築することにしました。これは、APIを使用して両方のDNSプロバイダに接続し、関心のある指標を引き出すサービスです。これらのメトリックは、同じ名前空間とユニットに正規化され、標準的な統計形式で発行され、任意の時系列モニタリングシステムに取り込まれます。

2つの異なる管理インターフェイスとそれぞれの複数の画面ではなく、すべてのプロバイダとゾーンを集約したDNSの正常性の概要を示す単一のダッシュボードが作成されました。

さらに、時系列のメトリックを1か所に配置したので、時系列クエリ(我々の場合はDataDogモニタ)の豊かな表現力を適用して、すべてのプロバイダでDNSの柔軟なアラートをプロバイダごと、ゾーンごとに設定できます。

マネージドDNSプロバイダを監視することは、PagerDutyのSREチームだけの問題ではありません。そのため、オープンソースのDNSメトリクスを採用することにしました。現時点では、使用しているプロバイダのみをサポートしていますが、他のプロバイダにカバレッジを拡張するには、一般的に使用されているメトリックを公開するREST APIがあれば簡単です。 DNSメトリックを試してみるのは、Dockerコンテナを実行するのと同じくらい簡単です。スピンを加えて環境内の場所を探すこともできるかもしれません。

本記事は米国PagerDuty社のサイトで公開されているブログをそのまま日本語に翻訳したものです。原文はこちらを参照してください。

続きを読む
ベストプラクティス
2018年4月3日  (更新日:2022年5月19日)

チームの健全性に関する驚くべき3つの発見

800人のITプロフェッショナルの調査結果から驚くべき発見

PagerDutyで、私たちは芳しくない業務の健全性につながる否定的な結果を認識しています。 今日の常時接続のデジタル世界では、絶え間なく高まる顧客の要求のために企業はプレッシャーにさらされていて、ITサービス担当者はデジタルサービスを健全かつ継続的に運営するために努力していますーしばしば個人の健康と生活が脅かされるほどに。仕事の呼び出しに応答するため、真夜中に携帯電話が鳴る音に起こされたり、人生の重要なマイルストーン(子供の初めての学校演劇のような)を逃したことなど想像してみてください。燃え尽きてすぐにワークライフバランスのいい仕事が欲しいと考えたことがあるでしょうか?

それでも、私たちは、米国、英国、オーストラリアの800人以上のITプロフェッショナルを対象に実施した最近の調査による3つの発見に驚いています それは、

家族生活はITマネージャーの想像以上に荒れている 認知度の欠如はITOpsの職業病となっている ビジネスにかかるコストは、労働力の喪失だけでなく苦労している従業員の生産性低下にも及ぶ

ということでした。

PagerDutyが依頼した調査レポートでは、常時接続のデジタルサービスを管理する責任が家庭生活に影響を与えているとの回答が94%となっています。さらに、半数以上(51.3%)が、デジタルサービスの中断や停電に対処するために、1週間に10回以上睡眠や個人的な生活の中断を経験したと指摘しています。

コンスタントに起こる呼び出しがオンコール担当者の健康や個人生活に悪影響を及ぼしているという統計にもかかわらず、調査回答者の約4分の3(72%)が、彼らのマネージャーはt担当者が厳しいオンコール時間を過ごしていることをを全然知っていないという結果になりました。それに対して、 調査のITマネージャーの58.9%は、彼らのチームが厳しいオンコール時間を過ごしていることをほとんど知らなかったと答えています。

悪い業務管理はデジタルトランスフォーメーションを妨げる可能性がある

IT管​​理者と企業全体は懸念すべきです。なぜか?

Forresterによると、多くの企業ではクリティカルな役割を担うタレントの不足がデジタルトランスフォーメーションを妨げることにつながっています。このようなタレントの欠如は、悪い業務管理と結びついた場合に、最終的に損益に悪影響を及ぼし、従業員の離職率や売上に直接悪影響を与えます。

健全なITエコシステムを維持するためにオンコール担当者はいつでも準備を整えていることを要求されます。その結果、燃え尽きたり、離職したりする不幸な従業員が生まれる可能性があります。しかし、ITOpsの始まり以来、運用上の管理は、人ではなくサーバやアプリケーションに集中しており、それはしばしばビジネスに損害を与えるものでした。

しかし、サーバやアプリだけでなく、人の面から業務の健全性を見ると、なぜIT管理者はオンコール担当者の健康状態をより詳細に把握する必要があるのかが分かるようになります。一部の回答者(23.1%)は、仕事と生活のバランスがとれない結果、新しい仕事に移る可能性が高いと答えています。さらに、組織が業務の健全性を改善するための対策を講じないと、残る人の生産性も低下する可能性が高くなります。 事実、94.5%の回答者は、継続的な中断が作業生産性にも影響を及ぼすと回答しました。

データの利用によりチームの健康を変える

いま指摘したように、良い人材を失うことは、組織がデジタルサービスをどれだけうまく提供できるかに悪影響を及ぼします。では、従業員の健康と幸福をどのように改善できるでしょうか。

それを知っているかどうかに関係なく、あなたはすでに現在の操作の健康状態を把握するためのデータを持っています。そのデータのロックを解除するだけで、改善すべき点を判断することができます。

PagerDutyは、この課題を認識してOperations Health Serviceを開発しました。これは機械学習、データサイエンス、専門サービス、1万を超える組織のピアベンチマークデータを組み合わせて、IT管理者が社員の健康状態を見て自社のデジタルオペレーションを評価できるようにするものです。

今日からPagerDutyがいかに組織のデジタルオペレーションをに人間的にすることができるかを学び、業務の健全性を向上させてください。

本記事は米国PagerDuty社のサイトで公開されているブログをそのまま日本語に翻訳したものです。原文はこちらです。

続きを読む
ベストプラクティス
2018年1月15日  (更新日:2022年5月19日)

アラート管理:インシデントの優先順位をどう決めるか

アラート 。それはいとも簡単に積み上がります 。一瞬で目にするアラートはほんの一握り。でも数時間、場合によっては数分後に、積みあがった山を見ることになります。 どのようにそれらを管理すれば、担当者がお手上げにならないようになるんでしょうか?

これらは非常に重要な質問です。 アラート管理システムにノイズが溢れていて、対応チームが慢性の疲労状態にある場合は、初動に対応するITアラート管理システムを持っていないも同然です。 過剰なノイズとアラート疲れは、アラート管理システムの有効性を完全に低下させます。

フィルタリングの適用:インシデントにアラートをまとめる

多くの点で、アラート管理システムの合理化の鍵は、関連するアラートをインシデントに統合し、インシデントの優先順位を決定するための迅速かつ正確な方法にあります。緊急度別にインシデントを並べ替えることで、ほとんどのノイズを自動でフィルタすることができ、すぐに注意が必要なものとしばらく様子を見ることができるものを、合理的に推量することができます。すべてのアラートがインシデント化や対応を必要とするわけではありません。対応不要なアラートを抑制すると、ノイズがさらに削減され、重要なことに集中できます。

ソート(優先度順に並べ替える)プロセスの一部を自動化する(例えば、ソースとキーワードで並べ替える)ことはおそらく可能ですが、一部の(多分相当な量の)ソートプロセスでは、ディスパッチャの役割を果たしているレスポンスチームの誰かが介在する必要があります。ただし、どのような方法を使用しても、基本となる基準は変わりません。

優先順付けのスキームのほとんどは、ITILが定めているインシデントの優先順位付けガイドラインなどに準拠しています。インシデントの優先順位は、インパクトと緊急性という2つの密接に関連する要因に基づいて付けられます。この記事では、これらの要因とその相互作用について詳しく見ていきます。

インシデントのインパクトを判断する

インパクトは、インシデントの影響範囲(部門、ユーザー、または主要サービスがどれだけ影響を受けるか)に基づきます。 影響判定プロセスの少なくともいくつかの要素を自動化するのは比較的簡単です。 たとえば、ほぼ同時に特定のサービスが利用できないことを示す多数のレポートが出てくれば、影響の大きいインシデントになる可能性があります。一方、単一のユーザーからの問題のレポートは、類似のレポートが他になければ、 影響の少ないインシデントだということを示します。 多くのIT部門にとって、インシデントの影響を判断するためのガイドラインは、次のようになります。

高インパクト

重要なシステムがダウンしている。 1つ以上の部門が影響を受ける。 相当数のスタッフがその機能を実行できない。 そのインシデントが多数の顧客に影響を与える。 そのインシデントが、財務上の大きな損失や組織の評判への損害になる可能性がある。 組織の機能と影響を受ける他のシステムに応じて変わるその他の基準もあります。例えば公衆の安全上の脅威、人命の喪失、または重大な財産の被害などが含まれる可能性があります。

中程度のインパクト

一部のスタッフまたは顧客は影響を受ける。 失われたサービスはどれも重要ではない。 財務上の損失や組織の評判への損害は起きる可能性があるが、範囲は限られている。 人命、公共安全、身体的財産への脅威がない。

低インパクト

少数のユーザーしか影響を受けない。 重要なサービスは関与しておらず、財務上の損失や評判の低下の可能性はほとんどない。

インシデントの緊急度

インシデントのインパクトとその緊急性を厳密に区別することは必ずしも容易ではありませんが、ほとんどの場合、このコンテキストで言う「緊急性」とは、「問題がシステムにどれだけ早く影響を及ぼし始めるか」ということだと定義できます。 給与計算システムの故障は、例えば、影響が大きい可能性がありますが、給与の支払い周期の始めに発生した場合は、毎日使う顧客関係データベースの損失よりも緊急性が低い可能性があります。

緊急度高

日々の操作に不可欠なサービスが利用できない。 インシデントのインパクトの範囲が急速に拡大しているか、または迅速なアクションによってその範囲を制限できる可能性がある。 時間に敏感な仕事や顧客の行動に影響がある。 そのインシデントが、高位の個人または組織(上級管理職または主要なクライアント)に影響を与える。

緊急度低

影響を受けるサービスはオプションであり、まれにしか使用されない。 インシデントの影響は拡大しないように見える。 重要な作業や時間に敏感な作業は影響を受けない。

注意してほしいのは、インパクトと緊急度の両方について、一般的には各カテゴリの1つの基準に当てはまればそのカテゴリになると思ってよいということです(基準のすべてまたは大多数を満たす必要はありません)。インシデントは、それが条件を満たす最も高いカテゴリに配置する必要があります。

優先度=インパクト+緊急度

以上のように考えれば、優先順位をインパクトと緊急性の両方の合算で評価すべきだと分かりやすくなったはずです。アラート管理とインシデントのディスパッチプロセスには関係なく、優先順位を決定するための基準に従ってルーティングする必要があり、結果としてアラートノイズを大幅に減らすことができ、低インパクト、低緊急度のイベントは自然に優先順位リストの下端に並ぶと思います。これにより、インシデント対応チームは、非常に注意を払う必要がある、高インパクトで高優先度のインシデントに集中することができます。

本記事は米国PagerDuty社のサイトで公開されているブログをそのまま日本語に翻訳したものです。原文はこちらを参照してください。

続きを読む
インシデント&アラート
2017年12月22日  (更新日:2022年5月13日)

Firefightに必要なインシデント管理ツール

火事が発生する前に適切なツール を用意することが重要です。適切なツール がないと、大規模な停止を認識し、整理し、解決することがはるかに難しくなります。事前にベストプラクティスが確立されていれば、困難なインシデントをよりスムーズに処理できます。

以下は、障害発生に備えたプランを網羅したリストではありませんが、問題の調整と準備のための組織の能力を大幅に向上させます。

  1. 内部コミュニケーション

内部のコミュニケーションは通常電子メールで行われます。これは、いくつかの理由で問題があります。電子メールは1対1のメディアです。つまり、送信者と受信者だけが読み取り可能であり、迅速なステータス情報が必要な場合は解析が困難です。SlackやHipChatなどのコラボレーション環境は、情報を伝達するために外部ホストを利用します。これらは、全員への公開チャンネル、登録者のみに公開されるチャンネル、あるトピックについてのチャンネルなどを提供します。クリティカルレベルでは、ステータスの更新(または問題が既に分かっており、作業中であることを伝えるメッセージ)を、主要なスタッフ(サポート、リーダー)にほぼリアルタイムで提供することができます。

  1. アプリケーションのパフォーマンスとインフラストラクチャの監視

本来、チームは顧客より先にアプリケーションに問題があることを知るべきです。アプリケーションやインフラストラクチャの監視技術は、修正や更新が必要なときに役立つかどうかの情報を提供します(New RelicやAWS CloudWatchなどがこれにあたる)。また、PagerDutyなどのソリューションを使い、アプリケーションのパフォーマンスとインフラストラクチャのパフォーマンスを監視することも重要です。問題が発生した場合は、全サービスの正常度データを単一のビューに統合し、緊急行動が必要な場合はオンコール担当者に通知します。アプリケーションとインフラストラクチャの両方が可視化されていれば、問題解決ははるかに簡単です。

  1. ステータスの更新

パフォーマンス上の問題が発生した場合、サポートチームに更新要求が殺到します。この流入を緩和するための主な方法は、Twitter、ステータスページなどを利用すること、またはPagerDutyのような製品を使うことです。これらは、主要インフラストラクチャとは別のインフラ上で稼働し、サイト全体が停止しても動き続けることが必要です。Twitter上では、ユーザーがピントゥイートと最近の返信を簡単に探すことができます。ユーザーはstatusapp.comで「黄色」または「赤」のステータスを確認することもできます。statuspage.ioのような読みやすいステータスページは、ダウンタイム中に情報を顧客に伝えるための重要なコンポーネントです。ユーザーはトラブルの際の情報が正確で更新が適切に行われている場合、そのページに信頼を置きます。そうすれば、彼らはあなたのビジネスにもっと信頼を寄せるでしょう。また、トラブル対応の最中にも情報の更新と各主要サブコンポーネントのステータスを知らせる必要があります。これらの更新は、完全な可視性を担保するために数分ごとに行われるべきです。最後に、PagerDutyのステークホルダーエンゲージメントのような機能により、インシデント担当者は、任意の優先通知チャネル(電話、SMS、電子メール、またはプッシュ通知)を介して、事前定義されたビジネス関係者のグループに到達するステータス更新を簡単に送信できます。ステークホルダーは、インシデント状況の更新を購読して、顧客に影響を与える問題についてリアルタイムの情報を得ることもできます。

  1. チケットソリューション

ZenDeskのようなチケットソリューションは、停電を管理するために絶対に重要です。重大な停止は破壊的であり、信用を失うことにつながります。チケット管理システムは、アプリケーションモニターが見逃した間欠的に起こる問題を特定するのに役立ちます。また、サポート要求に対して情報を公開します。問題のエスカレーションのワークフローは、特に大きなサポートチームにおいて、個々の判断に頼るよりも迅速な問題解決を導きます。あらかじめ用意されたメッセージは、システム停止中にメッセージの一貫性と正確性を維持するのに役立ちます。また、「related to」タグを使うと、問題が解決された後で簡単に報告することができます。

  1. プロシージャのトラッキング

適切な手順を講じることで、組織はアプリケーションから発生する可能性のある問題を予測できます。これらのシナリオは、事前に文書化する必要があります。トラブル対応、障害緩和、修復に関する情報は、チームのために文書化されるべきです。この文書には、誰が何をすべきかという職務チェックリスト、緊急連絡先電話番号とオンコール担当者の名前も入れておきましょう。もし可能ならば、模擬停電の訓練が、実際の停電が発生した際の対応に役立ちます。その後、訓練終了後、事後検証チームと一緒に検討し手順を改善してください。別のトラブルが発生した際、プロセスに追加できる情報があれば追加します。上記の他の項目と同様に、ローカルのインフラが利用できなくなる可能性があるため、これらのプロシージャを外部にホストされたリポジトリに格納するか、PagerDutyなどのソリューションで自動化することをお勧めします。

これらは一連のリストの最初のいくつかに過ぎません。トラブル時に有効だったことを記録しておくのは、事前に理解して準備するために費やされた時間と同じくらい貴重です。社内外のステークホルダーとのコミュニケーションはIT業界だけでなく、あらゆる業界にとって重要です。

続きを読む
インシデント&アラート
2017年12月30日  (更新日:2022年5月13日)

システムダウンを回避するための7つの方法

7つのステップでアプリケーションの高可用性を確保する

2016年8月、デルタ航空はコンピュータシステムの大々的な停止を経験しました。これにより1億5000万ドル以上の損害を被り、全社の利益率が3%低下しました。2300便がキャンセルされ、顧客は空港に何時間も足止めされました。デルタ航空は移動できなくなった人のために、何千件ものホテル代と旅行クーポンを支払う必要がありました。

数百万ドルするアプリケーションやサービスでも、いつダウンするか分かりません。大きな問題が1つでも発生すると、数億ドルの損失が発生する可能性があります。しかし、次のような対策をとれば、これを大幅に回避することができます。

1.マイクロサービスアーキテクチャを採用する

伝統的に、アプリケーションはモノリシックなスタイルで、つまりアプリ全体が1つのプログラムとして開発されていましたが、今ではマイクロサービスアーキテクチャが大いに普及しつつあります。その開発、テスト、デプロイには、相互に依存しない小さなアプリケーション群を配置します。こうすると、アプリケーションのコンポーネントが互いに分離されているため、保守が非常に簡単になります。したがって、特定のコンポーネントの1つに障害が発生した場合、他のコンポーネントに影響を及ぼすことなくフィックスすることができます。モノリシックアプリケーションでは、障害が起こるとアプリケーション全体がダウンするため、問題を特定するのが困難です。マイクロサービスのアプローチは、アプリケーションのダウンに対する耐性を高め、高可用性を実現するための第一歩です。ただし、マイクロサービスアーキテクチャでは、生成されるモニタリングデータの量がはるかに多く複雑になるため、関連するアラートを相関させ、対処不可能なアラートを抑制して全体的なノイズを削減することが重要です。

2.リリースはより速く、より頻繁に

マイクロサービスアーキテクチャの最大のメリットは、Webアプリの場合は1日に複数回、モバイルアプリの場合は2週間に1回などの高速リリースを可能にすることです。以前は四半期ごとのメジャーリリースだったため、すべてのリリースでダウンが避けられませんでした。現代的なアプローチではリリースは断片化しています。デプロイメントは、いつでもバックグラウンドでアプリケーションの一部でのみ行われ、プラットフォームは常に稼働したままになります。これにより、ダウンするリスクが軽減されるだけでなく、リリース速度を上げて最先端の機能と価値を提供することができます。

3.品質保証チームの関与

品質と可用性が同時に高まります。多くの企業ではQA(品質保証)の重要性を理解することができず、最終段階までそれを無視しがちです。バギーなソフトウェアを防ぐために、QAチームは、可能な限り早期に開発プロセスに関与し、リリースのライフサイクルに密接に関わっている必要があります。QAチームは自動化とテスト戦略に力を注ぐべきです。テスト自動化フレームワークは、手動アプローチと比較してコストを大幅に削減し、時間を節約しながらエラーを最小限に抑えるのに役立ちます。さらに、テスターはバグを探すだけではありません。彼らは開発を適切な方向へ向けるために、要件定義にも積極的に関与しなければなりません。開発チームが最初から正しい方法を構築することによって、後々の憂いをなくすことができます。QAは継続的な改善なのです。

4.ディザスタリカバリー計画を立てる

アプリの中核サービスに障害が起きたときのために、優れたディザスタリカバリー計画が必要です。パブリッククラウドとプライベートクラウドによるハイブリッドアーキテクチャを採用している企業では、サーバに冗長性を持たせ、各クラウド間でバックアップを取ることが重要です。仮想化は、既存の物理サーバのイメージバックアップを作成するのに便利です。また、コンテナ化することはさらに有用です。これは、イメージバックアップが軽量でスペースをとらないためです。これらの戦略は、障害時でもデータを確実に利用できるようにします。さらに、adminがおらず権限がない場合でもバックアップを取れるよう、バックアップを自動化しておきましょう。自動化により、DevOpsチームはディザスタリカバリーをテストして、障害への準備を整えることができます。

5.ITSM変更管理を採用する

ITILのような標準化されたフレームワークがITSM(ITサービスマネジメント)変更管理に使用されていることを確認してください。変更はそれがなければ進歩がないほどITサービスにとって有益ですが、変更は常に文書化されなければなりません。変化の成功率を測定し結果を公表して、どのチームが成功率が低いかを調べます。ServiceNowのようなITSMツールは、変更管理の可視性と制御性に優れています。ITサービスの混乱を最小限に抑えながら、迅速かつ効率的に変更を加えることができます。

6.インシデント管理ツールを使用する

避けられないシステムダウンが発生した場合、チーム内の適切な人にリアルタイムで通知することが重要です。しかし、多くの場合、チームはあまりにも多くのアラートを受け取るため、MTTR(解決までにかかる平均時間)に影響する重要なイベントを見逃す可能性があります。PagerDutyのようなインシデント管理プラットフォームは、さまざまな監視システムからのアラートを管理しグループ化するのに役立ちます。それは、簡単に定義されたルールに基づいて対処不可能なアラートを抑止し、関連する対処可能なアラートをインシデントにグループ化し、優先度の高いインシデントだけを適切な人物に通知するようにします。さらに、PagerDutyは既存のすべての監視、チケットシステム、ChatOps、コラボレーションツールなどとの統合により、チームがインシデントの解決を迅速に行います。

7.障害訓練を行う

計画的に障害を起こすことによって、システムダウンに対する準備をします。Netflixはこのアプローチをとっていることで有名です。彼らは常にバックグラウンドで実行されていて、ランダムにサーバインスタンスをシャットダウンするChaos Monkeyというスクリプトを使用しています。これにより、本物のサーバダウンが発生した場合でも、常にチームは準備ができており、スムーズに顧客にサービスを提供できます。PagerDutyでも毎週「Failure Friday」を実施し、意図的にシステムに障害を発生させ、対応を継続的に改善しています。

完全な対策を達成することは不可能ですが、DevOpsチームを構成する人、プロセス、ツールに焦点を当てることで、それに近づくことができます。すべてのシステムダウンを解決する銀の弾丸はありませんが、これらの手順に従ってより信頼性の高いアプリケーションを構築し、顧客の信頼と忠誠を獲得し維持しましょう。

続きを読む
インテグレーション&ガイド
2018年11月23日  (更新日:2022年5月10日)    |    インテグレーション&ガイド

エラーを迅速に解決するための5つのベストプラクティス

私はソフトウェアを書くことが大好きですが、バグを扱うことは嫌いです。それは、あなたがしたいことからあなたを奪い、バグフィックスというウサギの穴にあなたを導きます。完全なアプリケーションロジック、深いコンテキスト、リアルタイムでのスタック全体の可視性を提供するオープンソースのエラー追跡プラットフォームであるSentryを使って、時間をかけてエラーを苦労なしで(少なくとも小さな苦労で)解決するためのいくつかヒントをお伝えしましょう。PagerDutyとのインテグレーションの解説もあります。

以下にベストプラクティスのリストがあります。私たちはあなたが午前3時に起こされたときに、「ウサギの穴」に素早く移動できることを願っています。

問題の影響を特定する

あなたは午前3時の深い眠りの霧の中でコンピュータにつまずき、あなたが今受信したPagerDutyの警告のことをクリアな頭で考えようとします。最初にやりたいことは、問題の影響を知ることです。

この問題はInternet Explorerにのみ影響するのか? 特定のデータセンターの顧客のみか? あなたは聞くべき最も良い質問を知っています。そして今はそれをする時です。

Sentryは、問題に割り当てられたタグ(さまざまなキーと値のペア)というシステムを実装し、問題ごとに要約します。タグでバグのホットスポットを発見し、ブラウザ情報について顧客との間で行き来することを避けることで、時間とストレスを低減できます。

問題を再現するためにユーザーの手順をトレースする

問題の原因が明白でない場合、ユーザーがどのように操作したかを理解することが役立ちます。Sentryは、ユーザーがブレッドクラムとして取得したパスを自動的に追跡します。もちろん、ログを検索して手動でつなぎ合わせることもできますが、楽とは言えない作業でしょう。

スタックトレースからコンテキストを取得する

この時点で、あなたはウサギの穴を見つけ、1、2歩中に入りました。もう少し進みましょう。そしてもう一歩。

理論的にはすでにバグを再現しているので、コードを掘り下げて、何が間違っていたのか、なぜそうなのかを知ることができます。これらの質問に答える鍵はコンテキストです。あなたがこの穴から抜け出る道を見つけるために必要なのは。

そのコンテキストを取得する1つの方法は、スタックトレースを調べることです。おそらく例外が起きた場所を知ることができます。スタックトレースは、バグの原因となる一連のイベントや、バグのコード行を見つけるための洞察を与えてくれて、とても助けになります。

もっとたくさんのコンテキストが必要ですか? Sentryはスタックトレースを見せてくれるだけでなく、未展開のソースコードやローカルスタックをなど、すべてのスタックトレースを強化します。

必要に応じてオリジナルの開発者を追加

バグを突き止めて何が原因であるのかが分かれば、あなたはそれを修正するまでいじることができます。さもなくば、正しい人にバグを処理させることによって、前にしていたこと(食べたり、寝たり、人生を楽しむなど)に戻ることができます。バグフィクスを任せることは楽しくないかもしれませんが、エラー解決プロセスを簡素化し、迅速化することが最終的に必要です。

PagerDutyのお客様は、デベロッパーをステークホルダーまたはレスポンダーとして追加することができます。

Sentryは、ソースコード管理プラットフォームとの深い統合を提供し、エラーを引き起こした可能性のあるコミット-suspect commits(疑いのあるコミット)-を明らかにします。

Sentryは、問題を最もうまく解決できる開発者も示します。

アラートの優先順位付け

正直に言えば、すべてのエラーに眠りから起こす価値があるわけではありません。もし対応不可能な通知ならば、何とかしましょう。有効なツールを利用してください。

あなたの管理下にないgoofyプラグインに起因する警告やJavaScriptエラーを除外したいですか? PagerDutyのイベント管理を使用するか、 Delete&Discardを使用してSentryから直接削除してください。

これらのベストプラクティスはSentryとPagerDutyでなくともできますが、なぜ最善のもの以外に煩わされるのでしょうか? 結局のところ、何万人もの顧客が間違うわけにはいきません。

そして、おそらくあなたが推測したように、SentryとPagerDutyは共同で素晴らしい仕事をします。実際に、PagerDutyとの公式のインテグレーションがあります。私たちのインテグレーションは、あなたが定義したインシデント対応やインテリジェンスワークフローに従い、PagerDutyを介してアラートを送信します。開発チームと運用チームにエスカレーションポリシーや通知の緊急性、アプリ内のあらゆる場所からの対応などにより、エラーやアラートを表示します。

Neil ManvarはSentryのソリューションエンジニアマネージャーです。長年のソフトウェア開発経験の後、NeilはDevOpsのソリューションエンジニアリングに移りました。常にオンコールで、Cinnabon(訳注:米国の菓子パンチェーン)の前ではいつも立ち止まります。_**

GET STARTED

本記事は米国PagerDuty社のサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

2019年4月18日  (更新日:2022年4月29日)    |    ベストプラクティス

Postmortem(事後検証) パート3:事後検証ミーティングを最大限に活用する

「Postmortem Guide」を発表したとき、私は責任を問わない事後検証を行うことの価値と、継続的改善の文化を確立する方法について書きました。このシリーズの最後である事後検証の本記事では、効果的な事後検証ミーティングを開催する方法について説明します。*

私が参加した最後の事後検証ミーティングでは、システムで何が起きたのか、どのように対応したのか、問題が二度と起こらないようにするためにどのような改善を加えるべきかを話し合いました。PagerDutyには責任を問わないという文化があるので、誰かを名指しで非難したり、感情を傷つけたりはしませんでした。しかし、継続的な改善をという点において、この会議時間を最も効果的に活用しているのかどうか疑問に思いました。

インシデントを最適に分析する方法については、多くの記事が書かれています。「事後分析をする」というと、とかく分析のプロセスと結果として得られるドキュメントの形式に焦点が当たる傾向があります。多くの場合、このプロセスは、分析の結果について話し合うための事後検証ミーティングで終わります。私たちは最近、なぜ事後検証が重要なのか、そしてどのように実践するべきかについての詳細な情報をコミュニティに提供するため、総合的なPostmortem Guideを始めました。しかし、このガイドのために研究を行っているとき、私は事後検証ミーティングそのものについてはほとんど書かれていないことに気づきました。

分析を実行し、事後検証のドキュメントを完成させることは、インシデントから学ぶための重要な最初のステップです。結果を議論するために会議をフォローアップすることで、チームは分析からさらに多くの価値を引き出すことができます。事後検証ミーティングの目的は、インシデントの原因に対する理解を深め、実際に行動を起こせるようにアクション項目に賛同を得ることです。

一緒に、そしてクールに

何が起こったのかについてのライブ会話をするために(物理的またはバーチャルに)部屋に集まると、分析は新しい方向に進み、すべての人にとって学習ポイントが深まります。 最も重要なのは、議論することで、同じ問題が再発するのを防ぐのに必要なアクションの優先順位にチームの賛同を得ることです。

これは、「言うは易く行うは難し」です。 事後分析をみんなで読むだけでは、この会議から最大の価値を引き出すことができません。感情が高まり会議の進行が困難になることもあります。チームが責任を問わない事後検証を実行するために最善を尽くしたとしても、彼らが犯したした失敗について議論するとき、人々はどうしても防御的になるでしょう。

私は元スクラムマスターとして、事後検証ミーティングと振り返り(retrospective)の類似点に気づきました。振り返りミーティングでは、チームは最後の反復がどのように行われたか、またどのように改善したいかを検討します。同様に、事後検証は過去のインシデントの考察とそこから学びを得るために行われます。チームが奮闘していると、ふりかえりミーティングは個人間の摩擦と感情的な反応を引き起こします。事後検証も恐れや怒りといった感情を伴うことがあります。

進行役を担う

PagerDutyでの事後検証ミーティングとふりかえりの運営方法には大きな違いが1つあります。ふりかえりはチームのアジャイルコーチによって進行されますが、事後検証ミーティングは通常Incident CommanderまたはPostmortem Ownerが主導します。

これら2つの会議の類似点を考慮すると、事後検証ミーティングも熟練した進行役の参加が重要であることに気付きました。会議における進行役の役割は、他の参加者とは異なります。彼らは彼ら自身の考えを表明するのではなく、議論を軌道に乗せ続け、メンバーに発言するよう促します。対応者が会議の進行役をやると、グループ全体の一体感を保ちながら彼らの経験やアイデアを共有することは困難であると学びました。

指名された進行役は、グループが会議の2つの主たる目標に集中するのを手助けします。

インシデントにつながった原因についての理解を深めること 事後検証で明らかになったアクション項目への同意を得ること

チームが議論をしている間、進行役は全員が快適で誰か1人がミーティングを支配しないよう、グループダイナミクスに注意します。進行役がこれをどの程度きちんと実行しているか注目しましょう。

インシデントの原因を探る

進行役が直面する議論を妨げる2つの大きな課題があります。

システム障害の責任を個人に負わせてしまう傾向がある 分析が深く掘り下げられていない

進行役は非難が起こりそうな時に会話の方向を変えることで、チームが責めを避けるようにすることができます。事後検証の目標は、どのような体系的要因がインシデントを引き起こしたのかを理解し、この種の失敗が再発するのを防ぐ方法を見つけることです。誰がミスを犯したのかではなく、ミスがどのように起きたかに焦点を絞るようにします。

進行役は、分析を妨げ、責任追及を暗示する「誰」や「なぜ」という質問を避け、代わりに「何」や「どのように」という言葉を使って「あなたは何が起こっていたと思いましたか」や「必要な支援をどうのように受けましたか」というような質問をしてください。

特定の対応者を抽象化した人間に置き換えることにより、ある行動についての責任追求を避けます。誰でも同じミスを犯した可能性があることをチームに思い出させてください。「何がその行動をとらせたのか」と尋ねることにより、誰か1人を責めるのではなく、グループ内の誰もがシステム障害の原因についての率直な意見を述べることができるようになります。

たとえあなたが責任追及を極力避けるという文化を持っていたとしても、インシデントにつながった多くの条件を深く理解するのは難しかったりします。進行役の役目は、グループに考えさせるために適切な質問をすることです。単純に「はい」または「いいえ」で答えることができる質問ではなく、常に自由回答形式の質問をしてください。会話の初心者は事後検証ガイドの分析用の質問を参照してください。

メンバーの賛同を得る

製品管理者や技術管理者など作業の優先度を決定するチームリーダーに、事後検証ミーティングへの参加を奨励するために、カスタマーエクスペリエンスに対する脅威と技術投資へのニーズについての見識が上がることを説明します。事後検証ミーティングは、行われるか、あるいは行われない作業に関する困難な決定と、それらの選択の予想される影響について話し合う機会です。

下手なチームダイナミクスは全員の積極的参加を妨げる可能性があります。進行役はこれらのパターンに注目してグループを導きます。1人が会議を支配している場合は、その人が言っていることを繰り返し(例:「◯◯ですね。それは分かりました」)、続けて「別の観点があれば聞きたいのですが」と他の人が話すのを促します。

誰かが人の発言を遮っていたら「初めの人の言ったことが聞こえませんでした」または「ちょっと待って。マリーさんの意見を最後まで聞かせて 」と言いましょう。

反対に、意見を話す人がいないときには「他に何か検討することがあるでしょうか?」と尋ねれば参加を促せます。

これらの会話のトリックにより、進行役は全員を参加させることができます。そして最も重要なのは、アクションプランへの合意に向かって会話を進めることです。たとえ最善の行動方針について意見の相違があったとしても、みんなが聞いたことがあると思えば、グループをアクションプランに参加させることができます。

成功のために進行役を配する

チームの議論をフォローして、あなたの事後検証分析を最大限に活用してください。ライブで会話をすることは、全員の学習を深め、新たな洞察につながる可能性があります。ただし、単にその会議をスケジュールして文書を一緒に読むだけでは不十分です。事後検証ミーティングを成功させるためには、熟練した進行役の助けを借りてください。

その他の円滑化のヒントと効果的な事後検証の実行方法については、「 Postmortem Guide」を参照してください。PagerDutyのフォーラムでは事後検証ミーティングからどのようにして最大の価値を得るかについてご意見を募集しています。

本記事は米国PagerDuty社のサイトで公開されているものをDigitalStacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

2018年6月19日  (更新日:2022年3月14日)    |    インテグレーション&ガイド

Pepperdata インテグレーションガイドを追加しました

PepperdataソフトウェアのAdaptive Performance Coreは、CPU、RAM、ネットワーク、ディスクの使用状況をユーザの介入なしに観察し、再編成して、時間通りにジョブを完了させます。 Pepperdataは、マルチテナント、マルチワークロードクラスタのボトルネックを動的に防ぎ、多くのユーザとジョブを単一のクラスタ上で最大の性能で確実に実行できるようにします。 不十分なデータを使用し、変化する条件に対応できないクラスタ管理ツールやチューニングとは異なり、Pepperdataはパフォーマンスの問題をスケールの点で自動的に解決するために全プロセスの完全なメトリックをキャプチャします。

詳しくはこちら

2018年2月5日  (更新日:2022年3月11日)    |    DevOps

OK、Google。次のオンコールはいつだっけ?

VoiceOpsは次に進む準備が出来ている?

想像してみよう : PagerDutyからコールがあり、静かな声であなたに、注意すべき問題があるよと伝えてくれる。あなたの心中はきっと乱れ、心の声が次のように聞こえるだろう。

“げげ!これは直さなくっちゃ!”

“どうすればいい?”

“これは他人の問題かも”

…あるいはここには書けないような汚い言葉かも。

DevOpsの動きが立ち上がるということは実は、担当者は9時から5時まで個室に詰めて問題を解決するだけでは済まなくなるってことだ。 スマートフォン、ラップトップ、高速な家庭用Wi-Fiが使えるようになって、人々は自宅で仕事をすることも求められるようになった。 何かが起きれば、いつどこにいても、多数のプラットフォームを通じて通知を受け、対応できる。

でも今のテクノロジー・フォワード・ソーシャルや数多くのコミュニケーション・オプションがあるにもかかわらず、ラップトップや信頼できるWi-Fiにアクセスしないとか出来ないといったこともある。例えば通勤中や、コーヒーを飲んで会議をしているときとか、歯科医のオフィスで根管治療を受けているときとか。 こういうケースでは、声で反応するほうがより自然に感じる(根管治療中は除くけど)。

“エスカレーションしてよ。今私は答えられない。 “

“ああ分かった。確認。”

“うーん。担当者を増やすようリクエストして。データベースチームのEllenを探してくれるかい。 “

このシナリオを念頭に、われわれPagerDutyの中では、人々が実際にPagerDutyとどう話したがるかを研究し始めた。 まずPagerDutyと最も関連性の高い2つの状況を考えた。

戦闘中:多くの人々が大規模なインシデントに対応している状況で、複数のチームが絡んでいて、会議ブリッジで通信している可能性が最も高い。

小競り合い:1人の担当者が、マイナーなインシデントを確認して処理をしており、ダッシュボード、メトリック、およびランブックを参照して、一人で頑張っている。

しかしもう一つのシナリオがある:平時だ。これは、各チームが比較的静かな時間を最大限に活用してスケジュールを編集したり、分析結果を チェックしたり、サービスを設定したり、オーバーライドを管理する時間だ。 自宅の音声対応デバイスがあったら、みんなどう信頼を得るかを考えてみよう。 相互作用のほとんどは、比較的「平和」なものだ。消費者は、比較すれば緊急でないコマンドを試すことで、家庭の音声対応デバイスを信頼し始めている。

“今日は傘がいる?

“冗談を言ってみてよ”

“チーターってどのくらい速く走れるの?”

システムの状態をチェックすることは、天気をチェックするのと同じくらい自然でなければいけない。 平時のVoiceOpsは、人々がデジタルオペレーションを管理する方法を変えるはずだ。UXデザイナーのCorinna Sherman氏や、ソフトウェア技術者のZayna Shahzad氏は、平時のVoiceOpsの可能性を見出し、次にGoogle Assistant、Google Homeデバイス、そして PagerDuty APIを使ってプロトタイプを作った。

われわれはActions on Google開発者コミュニティとチームを組んで、先月共同でハックイベントを開催し、そのプロトタイプをPagerDutyコミュニティやHackbright AcademyとCode2040の出席者と共有した。

このイベントで我々は、Actions on Google AssistantとPagerDuty APIを使ってデモを作るためのブレーンストーミングを全員で実施しアイデアをひねり出した。優勝者はGoogle Homeデバイスを授与されたので、イベント後も引き続きプロジェクトに取り組める。さらに、Actions on GoogleのDevエバンジェリストであるIdo Greenが、参加者が音声を使った設計の原則を理解し、いくつかのコードラボをわたり歩き、Dialogflowでさまざまな自然言語技術を使って時間をかけて改善する方法を共有するのを支援した。

VUI Design from Ido GreenからのVUIデザイン (訳注:スライドが開きます)

学んだことは?

VoiceOpsは、 小競り合いの際のシナリオで、担当者が予定外のマイナーなインシデントの解決に独自に取り組んでいるときに、その役に立つ。

VoiceOpsは平時のマネージャーに約束しており、通常は毎日自分のチームのPagerDutyアプリケーションをチェックしない人にも答えを提供する。

VoiceOpsはまだ戦闘時に対しては準備が整っていない。Corinna氏が指摘しているように 、アクセントの認識の問題があったり、音響に問題がある部屋では、音声認識はかなりひどくなる。

音声認識と対話がうまくいけば、人々はVoiceOpsを使ってうまく働けるだろう。音声対話が設計どおりに動作しない場合、人々は不満を感じ、信頼しなくなる。

もっと学びたい?それなら プロトタイプをチェックし、コミュニティフォーラムでディスカッションに参加してください。 あなたはオンコール中に何を尋ねる?オンコール中でないときは? 私たちはそれを聞きたい。 また、PagerDutyコミュニティに参加してイベントなどの最新情報を忘れずに入手してください。

本記事は米国PagerDuty社のサイトで公開されているブログをそのまま日本語に翻訳したものです。原文はこちらを参照してください。

2018年4月26日  (更新日:2022年3月11日)    |    インテグレーション&ガイド

ThousandEyesインテグレーションガイドを追加しました

ThousandEyesは、クラウド時代のIT性能管理を提供します。企業のネットワークの範囲を超えた詳細な可視性を提供し、クラウドアプリケーションの性能の根本的な原因を見つける助けになり、問題を分散したコラボレーションで迅速に解決できるようにします。このガイドでは、ThousandEyesとPagerDutyをインテグレートする方法について説明します。

詳しくはこちら

2018年6月13日  (更新日:2022年3月11日)    |    インテグレーション&ガイド

Zenoss 5インテグレーションガイドを追加しました

Zenossは、普及しているオープンソースネットワーク、サーバーおよびアプリケーション監視システムです。あらゆるオープンソース監視システムで利用可能な最高のイベント管理システムの1つを提供します。Zenossのプラグインアーキテクチャにより、誰でも簡単に利用できるようになりました。PagerDutyは、PagerDuty APIを使用してオンコールスケジュール、アラート、インシデント追跡を提供することで、Zenossの機能を拡張します。 このガイドでは、Zenoss 4のインストールをPagerDuty ZenPackにインテグレートする方法について説明します。

詳しくはこちら

2018年3月17日  (更新日:2022年3月11日)    |    インテグレーション&ガイド

Uptimeインテグレーションガイドを追加しました

UptimeはあなたのWebサイトとWebアプリケーションの稼働とパフォーマンスを監視する(訳注:いわゆる外形監視)サービスの中でもトップクラスのサービスです。Uptimeは5大陸の異なる30カ所から1分間隔であなたのWebサイトをチェックします。PagerDutyとの連携法を紹介します。

詳しくはこちら

2018年6月22日  (更新日:2022年3月11日)    |    インテグレーション&ガイド

Watcherインテグレーションガイドを追加しました

Watcherは、Elasticsearchのアラートと通知用の製品で、データの変更に基づいてアクションを実行できます。これは基本的に、Elasticsearchで何かをクエリーできたら、そのことをアラートするように設計されています。 クエリー、条件、スケジュール、および実行するアクションを定義するだけで、Watcherが残りの作業を行います。PagerDutyと連携させることで、その作業をメンバーに効率よく周知できます。

詳しくはこちら

2018年1月22日  (更新日:2022年3月11日)    |    インテグレーション&ガイド

Zabbixのインストレーションガイドを追加しました

Zabbix は、ネットワークサービス、サーバ、およびその他のハードウェアのステータス を監視するために設計された、非常に強力なオープンソースのエンタープライズクラスのネットワーク管理システムです。多くの組織のITインフラストラクチャを監視する上で重要な役割を果たしています。 このガイドでは、インストール済みのZabbix 1.xまたはZabbix 2.x環境を、PagerDutyにPythonスクリプトを使って統合する方法について説明します。

このガイドでは、Zabbixの中でスクリプト、メディアタイプ、ユーザ、アクションを設定する方法を説明します。LinuxディストリビューションのバージョンとZabbixの設定によってはそれに合わせて、下記の手順を少し変える必要があるかもしれません。

詳しくはこちら

2018年1月13日  (更新日:2022年3月11日)    |    インテグレーション&ガイド

Zabbix 3.xのインストレーションガイドを追加しました

Zabbix は、ネットワークサービス、サーバ、およびその他のハードウェア のステータスを監視するために設計された、非常に強力なオープンソースのネットワーク管理システムです。多くの組織のITインフラストラクチャを監視する上で重要な役割を果たしています。

PagerDutyはZabbixの機能を、PagerDuty APIを経由したオンコール・スケジューリング、アラートやインシデントトラッキングで拡張します。PagerDutyはZabbixの最もクリティカルなイベントを通知し、あなたが即座に対応できるようにします。

詳しくはこちら

2017年12月28日  (更新日:2022年3月11日)    |    インシデント&アラート

買うべきか作るべきか?

典型的な技術者はたった1つの質問ですべての課題に対峙します:「私は自分でこの ソリューションを構築できるだろうか?」と。そしてこの質問は重要な考察が得られるので十分考えるに値します。 では私たちは作るべきですか?買うべきですか? インシデント管理ソリューションの評価は今この問題を招いているようです。 しかし、今インシデント管理プラットフォームを作るべきか、あるいは購入するべきかは、どう分かるのでしょうか?

なぜビルドするの?

独自のソリューションを構築したいという願望が、商用ソリューションの調達権限があなたにないという単純な理由によることもあります。 例えばエンタープライズのITにはツールの予算があっても、DevOpsチームがそれを必要としていたりします。 オープンソースプロジェクトを基にソリューションを構築する方が、商用ソリューションを購入するのに必要な長い駆け引きをするより簡単に思えるかもしれません。 しかし、これは組織的な問題であって、技術的な問題ではありません。 そしてカスタムビルドのソリューションは短命になることがよくあります。

でも独自のソリューションを構築する理由は他にもあります。

現実のまたは既に必要が見えている固有の要件がある

セキュリティとプライバシーに関する懸念がある

コスト

これらは、インシデント管理ソリューションの構築を検討する正当な理由ですが、どれも精査する必要があります。

あなたの要件は本当にユニークですか? これが当てはまるかどうかを特定する方法は、競合他社と彼らが使っているものを見て、さらに類似の組織と比較して要件を調査することです。同時に、独自の要件があっても、なぜそれがユニークであるのか疑問に思うかもしれません。それって本当に必要なの?と。

セキュリティに関しては、商業的なインシデント管理を使わないようにさせるようなセキュリティとプライバシー上の懸念は何ですか?データが暴露される可能性がありますか?ほとんどの場合、アプリケーションのデータはアラートの中に含める必要はありませんが、そうなっている場合は、検討する必要があります。一般的なセキュリティに懸念があるのなら、ベンダーは自らが常にセキュリティの脅威に敏感であろうと努めていることを知っておいてください。多くの場合彼らはあなたの社内の運用チームよりもセキュリティの面ではるかに優れた能力を持っています。

そして、コストの問題があります。 独自のソリューションを構築する上で最もコストのかかる側面は簡単には数字にならないため、コストの計算は難しいのです。インシデント管理サービスの月額料金と、フルタイムの開発者による一回きりの開発のコストを計算するのは簡単です。しかし、継続的なメンテナンス、機能の変更、および大きな一回切りの開発のコストを予期することは困難です。このソリューションを構築していない場合に、開発者は何をしているんでしょうか?また、開発中に複数のプロジェクトやバックログを脇に置いてしまうコストはいくらですか?構築した人が退社した場合に別の問題が発生します。残されたコードベースを理解するためにまたコストがかかります。組織のインフラストラクチャのミッションクリティカルな部分に関連している場合、知識を持つ人が組織を離れることは望ましくありません。

インテグレー?

インシデント管理ソリューションの構築には、1つに大きな弱点があります。成功したインシデント管理プラットフォームには、ソース(アプリケーションとインフラストラクチャなど)とディストリビューション(コラボレーションツールなど)への統合に関する膨大なライブラリが用意されています。これらの統合を実現するためには開発者は新しいAPIに対して習得し、構築する必要があり、かなりの時間がかかります。独自のインシデント管理プラットフォームを構築する組織は、いろいろなユースケースをサポートする必要がなく、重要な統合を行うだけで済みます。

しかし、これらのシステムのAPIが変更されると、あなたは盲目になる可能性があります。新しい機能を使えず、プラットフォームを完全に壊す可能性があります。オープンソースプロジェクトは、統合の中での変化に、あるいは新しいものを作リ出すために素早く対応することはありません。何か不具合が生じた場合も、開発者はもう別の何かを抱えています。もちろん、インシデント管理システムと統合する必要のあるツールの選択は、チームの規模の拡大とそのニーズの変化に伴って変化する可能性があります。

ビルドする時期

オープンソースプロジェクトを基盤とするカスタムインシデント管理プラットフォームが有用なシナリオがあります。それは特定の目的のためのビルドが必要という、とてもニッチなシナリオです。一般的に、このようなソリューションが必要な組織は、グローバルでの商業的インシデント管理を行っており、ニッチなシナリオのためにインシデント管理プラットフォームのAPIに統合していることさえあります。

もう1つの目的は、アプリケーションまたはインフラストラクチャのサポートとは異なるコンテキストで使用されるアラートのためです。おそらくそのアラートはコラボレーションや製品管理に使用されています。このような場合は、自社で作った他のユースケース向けの責任の低いシステムと、商用およびミッションクリティカルなインシデント管理システムとそのユースケースを分けたほうが有用な場合があります。アプリケーションの使用方法から学ぶことについては同じことが、すでに多くのカスタマイズを行っているチームにも当てはまります。例えば、新しい機能がローンチされたときに、その機能が使用されたらアラートを受け取るということができます。また、新しいインフラストラクチャが配備されたときに、パフォーマンスを示す特定のKPIにヒットしたときにアラートを表示させるように設定することもできます。

もう1つの理由は、内外へのデータ漏えいの懸念がある場合です。例えば、是正措置が個人を識別できる情報を、内部のティア1のサポートに、その人たちには見る権限がないのに晒してしまうアラートです。これは問題であり、特に規制産業では問題となる可能性があります。 ほとんどの場合あなたはプラットフォームでの役割と見られる内容を変更できるため、これは問題にはなりません。一般的に言って、あなたはそれを常に試すようにするべきです。避けられない場合もまれにはあるでしょう。

あなたの輝く時間が来る

熟練した技術者は、自分の興味の範囲を超えて、いつビルドや購入をするのが適切かを判断し問題を解決できるようになります。このソリューションは早速作り始めるべきで、立ち止っていてはいけません。これはカスタムソリューションに伴う長期的なサポートであり、リスクです。ソリューションの作成だけでなく、実行する必要もあります。インシデント管理システムにインシデント管理システムをインストールしているんですか?他の何かの稼働時間を心配することはストレスであり、インシデント管理がダウンすると、何も見えなくなります。

コードベースとインフラストラクチャへのカスタムニッチの統合を理由に、独自のインシデント管理ソリューションを構築することが正当化されることがあります。あるいは、商用インシデント管理と連動する非ミッションクリティカルなユースケースがある場合は、独自のインシデント管理を構築する価値があります。しかし、一般的に商用ソリューションの総所有コスト(TCO)は低く、規模の拡大に合わせてニーズに対応し、特定の専門家が退職したときにツールやプロセスが破壊されないようにし、キュリティとプライバシーに関する懸念にもより良いカバレッジとソリューションを提供します。

ビルドや購入を決定するときは、機会費用に重点を置くことをお勧めします。これはあまり知られていない費用ですが、これを考えると普通はかなり早く答えがはっきりします。

2018年5月17日  (更新日:2022年3月11日)    |    インテグレーション&ガイド

Threat Stackインテグレーションガイドを追加しました

Threat Stackは、クラウドインフラの監視ツールです。PagerDutyとThreat Stackのインテグレーションによって、お客様はThreat Stackポリシーで生成されたアラートをPagerDutyに簡単に送信して、通知をよりうまく管理し、運用ワークフローに組み込めます。Threat Stack内のアラートを解消すると、PagerDutyのインシデントも自動的に解決されます。私たちはお客様が可能な限り簡単に稼動できるようにPagerDuty Connectを提供しています。

詳しくはこちら