Blog
ブログ

2018年3月9日  (更新日:2022年3月9日)

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

Catchpointを使用すると、オンラインアプリケーションのパフォーマンスを管理、監視、テストできます。 PagerDutyをCatchpointとインテグレーションすることにより効率的な監視サービスを実現します。

詳しくはこちら

続きを読む
インテグレーション&ガイド
2018年1月18日  (更新日:2022年3月9日)

スケーラブルな分散システムを構築する

予防は最高の薬です

分散システムを構築する最善の方法は、 分散を避けることです。その理由は簡単で、分散コンピューティングの欠陥を迂回することができます(一部の楽観主義者の考えとは異なり、分散コンピューティングの欠陥はまだ残っています)。

私の個人用のラップトップにはSignalFXのステッカーが はってあります。これは、さまざまなトランスポートメカニズムの速度のリストです。そもそもこのステッカーは、特にデータセンター間を移動するときに、複数のディスクやネットワークを使うのを避けるようにと言っています。それに従い、機械的な共感を抱くならば、単一ノード上で毎秒何百万件ものトランザクションを実行できる取引プラットフォームをサポートできる、LMAXのように市場を破壊するような素晴らしいものを構築することができます。メモリや単一のマシン上で処理させるようにするとさらに多くの処理ができます。おそらく15秒分の作業をやり直しても問題ない場合は、メモリ内ですべての作業を行い、1分に4回チェックポイントをディスクに書き出すだけです。そのようなシステムは非常に高速に動作し、完全にスケールアウトするという問題を回避できます。

自分自身をだますことはできません – 分散システムは常に複雑さを増し、生産性を低下させます。もし誰かが別のことを言うのなら、その連中はおそらくいんちきなものを売っているのでしょう。

なぜそうしているのかを調べ、前提をすべて問い直してください

「高可用性」と呼ばれる要件のせいで、すべてのコードを1つのノードに置くことが不可能になります。この要件は、しばしば、複数のシステムが引き込まれるまで非常に高価なステップを引き起こします。ここでは、2つの要件、チャレンジの仮定とチャレンジの要件があります。この特定のシステムには本当にファイブナイン(訳注:99.999%)の可用性が必要ですか、それとももっと 緩い可用性を与えるレイヤーに移行できますか?特にあなたのソフトウェアがそれ自体を証明する必要や、HA(高可用性)やその他の鐘や笛を鳴らす必要があるのならば、成熟度の低い最適化を施してしまう可能性があります。そうではなく、今すぐにスキップして、市場投入を早め、後で追加する戦略を立ててください。ビジネスのステークホルダーが「はい」と言うなら、「HA」にする必要がありますが、トレードオフと、時間とお金を使う実際には使えないものに時間とお金を費やすことになるかもしてないことを相手が知っていることを確認する必要があります(顧客がその製品や機能を気に入らないようになるという結果も考えられます。顧客が好きになることを知っている製品や機能だけを作ってればリスクはなく、あなたが始めたベンチャーは退屈な雲の上に止まってしまいますが)。

CAPの定理を説明すると利害関係者に、可用性や一貫性を持たせられるということは言えますが、両立は無理です(もう一度言っておくと、楽観主義者の中にはそれは問題ないという人がいますが、間違っていると思います)。 たとえば、通知を送るシステムを構築した場合、たいていは、一貫して通知を送るシステム(一貫性がありますが可用性の低い通知)とか、ほとんど常に通知を送理続けるシステム(可用性はある一貫性が低い)を作ることはできます。 通常、最終的に一貫性のある(AP)システムは、調整が少なくてすむため、構築が楽で、拡張と操作が簡単です。可用性の要件を取り除けるかどうかを検討してみてください。 普通は、APソリューションで問題解決を図ることを検討することは価値がありますので。

忘れないで – 何かを避けられないなら、少なくとも単純にする方向で交渉してください。 複雑な分散システムを実装しないことが、分散システムを構築する最善の方法です。

人生をシンプルにする

複雑さは我々の商売の敵なので、どんなコードを書いていても、どのようなシステムを設計していても、この「複雑さが膨れ上がったらハンマーで叩き潰す」というモグラ叩きゲームをプレーする必要があります。 複数のシステムにまたがるソフトウェアを書いたらすぐにこれはさらに大事になります。分散システムは本質的に複雑なので、偶発的に複雑さが増すことには我慢しないようにしてください。分散システムの中には、他のものより実装が簡単なものがいくつかあります。単純なものに固執し続けることです。

HA用に配布する

可用性を向上させるにはいくつかの方法があります。ノードのクラスタを作り、すべてを調整できます(作業状態を常に保存しておくと、どのノードでもなんでも拾えるようになります)が、それには多くの調整が必要です。 調整はシステムを壊れやすくするので、おそらく維持できないのではないでしょうか。 コーディネーションを避けるためのさまざまな選択肢があり、依然として優れた可用性を保てます。

同じ作業を複数のシステムで並行処理させ、1つのシステムの出力のみを使うこと。 すべてがセカンダリノードにレプリケートされるため、プライマリノードに障害が発生すると、レプリケーションによってバックアップノードが確実に「ホット」になり、瞬間的に引き継ぐことができます。調整が必要なのは最初にどのノードを実行し、どのノードを2次バックアップにするかを決めることだけです。 予備の待機系を持つこと。 プライマリノードは定期的に共有ストレージ上で作業を継続し、作業が停止すると、セカンダリがそれを読み込んで引き継ぎます。 ここでの調整は、通常、テイクオーバーが必要かどうかを知るために、常にセカンダリがプライマリを監視するようにしておくことです。

どちらの場合も、調整の単位は「トランザクションごと」から「構成ごと」に移行します。分散した作業トランザクションの扱いは難しいので、構成レベルの調整を取り除くことができれば、そうしてください。しばしば、これにはいくつかの作業が含まれます。「正確に1つ」の作業プロセスは、マシンが死ななければ「ほとんど正確に1つ」のプロセスになり、何も見逃さなかったことを確実にするためには最後の1分まで再生してみる必要があります。場合によっては、重複したオペレーションが表示されるのを避けることはできませんし、要件に関してステークホルダーとチャットする必要があります。正直なリスクアセスメント(1年に何回くらいそのマシン群は死ぬのか)と、正直なインパクトアセスメント(どのくらい各要素が重複する作業をしたのかと、ユーザーにどのくらい不便を感じさせたのか)と正直な難易度アセスメント(ぜい弱性を生じさせ、これにより可用性が低下するような余分な作業と複雑さがどれくらい増えたか)を実施しましょう。

場合によっては、データセンターに障害が発生した場合にも可用性が必要になることがあります。そのような場合には注意が必要です。システムが脆く、早くなりすぎるので、最小限の調整で済むようにしたいと考えるようになるでしょう。

パフォーマンスのために分散させる

一つのノードだけですべての作業を完了させることはできない場合もあります。まず、そんなポジションをとらないようにしてください。目をしっかり開いて、サイクルを無駄に使っているところを探してください。LMAXの人々は、1台のマシンで1秒あたり7桁のトランザクションを実行できることを示しました。より大きなインスタンスが必要ならAmazonを使うべきでしょう。私はまともなソフトウェアとは、より速いハードウェアを手に入れれば迅速に修正できるようなマルチコア対応のものだと、今のところは思っています。より多くのコアでより速く実行できるようにコードを書けない場合は、たぶんノードを追加しても高速化は期待できないのではないでしょうか? LMAXレベルのエンジニアリングがなくても、少なくとも1秒あたり5桁のビジネスオペレーションをソフトウェアが処理できると問題を解決するためにマシンを追加する必要がある場合(これは大きな問題です)、調整が最小限になるように計画してください。

想定してよいと思います。 1ノードでは1秒間に数百個も処理できないのでスケールアウトしたい、というのなら、最初の設計をしたボードに戻ってください。おそらく、あなたのコードには対処が必要な別の問題があるのです。

問題を解決するためにマシンを追加する必要がある場合(これは大きな問題です)、調整が最小限になるように計画してください。

トランザクションの調整ではなく構成の調整をする。さらなる協調の必要なしに各ノードがそれ自身のチャンクをプロセスに実行させるための調整スキームをノードに使わせます。あるノードが使えなくなったときに各ノードが再配布できるようにすれば、HAを非常に簡単に追加できます。 どんな調整も全く必要としないように、並行できる作業を見つけること。 ステートレスなWebサーバーが良い例としてここに挙げられますが、調整されていないノードの束を投入できるのはそこだけに限りません。

ストレージは安いのだから活用しよう

コマンド/クエリ分離やイベントソーシングなどのアーキテクチャパターンは、データストレージを複数の特殊なステージにデカップリングし、複製することがよくあります。これらの特殊なステージは、分散設計をサポートするためにはうまくいきます。ローカルに保存するものと分散するものを選択できるため、調整を最小限に抑えるハイブリッドソリューションになるからです。たとえば、アップデートコマンドを分散Kafkaクラスタに書き込むことはできますが、そこからの下流のすべてはローカルで操作できます(たとえば、コンシューマがアップデートコマンドを処理し、クエリに使用されるElasticSearchノードを個別に更新します)。 「実際の」データは、利用可能性が高く、メッセージストリームで調整されます。システムは、検索、分析などの特殊な処理のためにそのデータのビューを使用します。このようなシステムは、中央のデータベースシステムがすべての操作のネクサスであり、必然的にボトルネックになる古典的な構成(データベースシステムがスケーラビリティのために構築されたものであろうとなかろうと)よりも簡単に維持できます。

データを冗長に保存し、複数の独立したシステムがそれぞれ独自の最適化された形式のデータを使用するようにしてください。そうすれば調整の必要性が低くなり、最終的にはストレージコストは比較的小さな増加で済むようになります。

NIH症候群を避ける-車輪はすでに他の場所で再発明されている

Googleのスケールでシステムを運用するのでない限り、分散型であなたが実装しようと取り組んでいるシステムは、一から自分で構築する必要があるほど特別なものではないはずです。あなたが投資をしているのはビジネス上の問題を解決するためであって、ツールやインフラストラクチャを構築するためではないでしょうから、2017年の今、自分のための特別な何かを探す理由はないのです。分散システムを正しく実装するのは難しいので、失敗する可能性が高いのです(パーシステンスと暗号化についても同じアドバイスができます)。独自の問題を抱えていて自分自身で何かを発明する必要があると思っている場合は、実はちゃんとじっくり世間を見ていないか、何百ものオープンソースプロジェクトのどれかが使える形に、自分の問題を定義し直す努力をしていない可能性があります。あなたは「ビジネス」を推進しており、分散ソリューションをずっと簡単に、したがって信頼性を高める形で要件の形を変えるのを助けています。あなたが抱えている問題の、ユニークではない部分を解決するための、正しいソフトウェアを見つけましょう。そうすればあなたは自分の会社を特別なものにすることに集中できるようになります。

そう、ツールを作ること(tool-smithing)は楽しい – 私も大好きで、一日中やっていても飽きません。そして、確かに、独特の雪のかけらみたいに見えるような形であなたの問題をフレーミングすることは、自尊心のためには良いことです。でもそれは辞めて、ビジネスを成功に導くために本当の問題を解決してください。

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

DevOpsカルチャーを構築するためのガイド

DevOpsを知った時期によって、DevOpsの実装方法に関する認識は変わります。DevOpsはまず文化のみの動きとして始まり、成熟するにつれてますます戦術的になりました。

文化がDevOps環境の中心にあります。 多くの場合、文化はDevOpsにとって最も難しい部分です。また、DevOpsの文化を構築するための万能薬はありませんが、私が以下で説明するように、働いている組織の種類に無関係に、健全な文化を定着させるのに役立ついくつかのテクニックがあります。

なぜ文化が大事?

文化という言葉はお嫌いかもしれませんし、大好きかもしれませんが、それは問題ではありません。文化に関してそういうことは環境に関係なく常にあるものだからです。 文化が意識されていない開発環境では、それ自体が有機的に作成されますが、これは通常、あまり望ましくないシナリオになります。 それは独裁国家(fiefdoms)の文化、あるいはすべてが壊れやすく、すべての新機能はそれが書かれる前でさえ失敗とみなされる、恐怖の文化かも知れません。。

だから、どんな場合でも文化があります。 DevOpsの原則が作ろうとしているのは、意図的に作られた文化です。組織は、その目的を最もよく支える文化を事前に決定し、その枠組みを確立し、向上させ、維持するために必要なことを行います。

DevOpsの文化が悪い印象を持たれているのは、それはしばしばヒップスターやスタートアップに関連する言葉だからです。 しかし、これは正確ではありません。その文化の要素のいくらかはスタートアップのロビーに属するように見えますが、DevOpsを意図的に文化として広げようとする触媒はボトルネックを避けられるかもという希望でした。あらゆる種類のプロセスとツールを採用してより速く開発を進められるはずですが、意思決定に加わっていないユーザーにより速度が制限されると、高品質でより頻繁で高速なリリースは実現できません。

文化の問題のもう一つの理由は、DevOpsは単なるプロセスやツールではないからです。 これは、DevOpsに対応しないスタティックな環境にデリバリーチェーンがならないようにすることを目的に、作られています。プロセスとツールだけで開発運用を「実装する」場合、2年後にはその環境はウォーターフォールのようなルック&フィールになり、現在の開発の標準に追いつけなくなります。

文化を快適にする

適切な文化を醸成することは、組織が、「より良いソフトウェアの品質とスピードを促進する文化をサポートし成長させる必要がある」と認めているほど簡単です。、いくつかの明確な目標を持ちどう行うべきかを意識し始めると、すべてのチームメンバーにとってその文化が最優先事項になります。 彼らは新しいツールを採用する際に、ツールがどのようにモジュール化でき、スクリプト化できるかを考えます。 あるいは、他のチームメンバーとのコミュニケーションについて考えるとき、彼らは簡潔に結果が得られることに重点を置くでしょう。チームがポジティブな文化を築くためにできることは、組織がより良いコードの文化に専念していることを明確にすることに加えて、他にもいくつかあります。

管理責任を持つこと(独裁ではなく)。 あなたが欲しい、または必要とする文化は、トップダウンでの導入を必要とします。でもそれは指示されるべきではありません。文化を支えるために、チームメンバー(リーダーシップとエグゼクティブの両方を含む)は、人々にどのように行動すべきかを伝えるのではなく、文化を積極的に実践してメリットを見せる必要があります。 あなたは誰かにチームプレーヤーであることを伝えることはできません。チームプレーヤーであるという利点を示す必要があります。 しかし、これは、誰かがその環境内に収まらない場合、彼らが歩き回っても良いようにするか、組織から去らせることで収拾する必要があることを意味します。 成功を分かち合うこと。 チームがそのメリットを理解するためには、リリース頻度の増加、欠陥の減少、人間の関与を必要としないタスクやリリースが増えるといった成功を共有する必要があります。チームの全員がより効率的な環境のメリットを享受できるわけではないので、そのメリット(革新的なビジネスの差別化要因の企画や繰り返しの少ないタスク、バーンアウトの削減などに専念する時間)を、常にチーム全体で話し合う必要があります。 チームを小さくする**。 強い文化を維持するには、より小さくて緊密なチームに保つことです。 これは階層の問題であり、リーダーシップは絶対に関与する必要があります。 アマゾンのようなハイテク企業の指針は、すべてのチームが「ピザ2枚で足りる」少人数のチームでなければならないということです。すべてのメンバーがチームへの貢献度を明確に把握し、作業の可視性を確認する必要があります。 これは、各チームが協力して文化を維持し、直接的な説明責任を持つようにするのに役立ちます。 目的をシェアする**。 組織がしばしば間違っている点は、競合する目標を設定することです。 チームメンバーが常にある測定方法で評価されながら作業するので、例えば開発者が発表した新機能の数で評価されているのに、運用チームは物事が中断しないことを基準に評価されている場合、これらの2つは直接衝突します。変化はOpsの心のリスクと等しいので、新しいものに対してサポートするのではなく、それをリリースをさせないように動機づけられるからです。経営陣は、同じ目標を達成するためには、全員を同じ基準で評価する必要があります。

階層やKPIのようなものは、常にあなたが制御できるとは限りません。もちろん開発者でもボトムアップで、共通の文化の価値を表現することができます。ある時点では、組織と管理者はその光を見る必要があります。 良いことは、すべての企業がある程度の能力を備えたハイテク企業になるにつれて、以前より高い品質なアプリケーションリリースを頻繁にサポートすることを支援する必要性は収益に影響します。 経営陣は数字以外を聞くことはありません。

文化をOKにする

文化はとても主観的なので、効率の環境を維持する原則とは対照的に、DevOpsの戦術にフォーカスするほうが簡単です。 文化エンジンを地面から降ろすのは難しいですが、良いニュースは、いったんそれが始まると非常に自立しているということです。 文化の鐘を鳴らすことは難しいです。これは、あなたがそれを作成することを熟考したとしても当てはまります。

上記のフレームワークとともに、ボールを投げて、結果が出るまで耐える自信を持つことが、成功への鍵です。 DevOps文化を受け入れる組織は、ソフトウェア配信をよりシームレスにして、最先端の開発の実践をより成功させるでしょう。

続きを読む
ベストプラクティス
2017年12月8日  (更新日:2022年3月9日)

サイロを壊す:ベンダー間のデータを関連付ける

DevOpsのへの移行で、一連のサイロからなる ソフトウェアデリバリーチェーンがなぜ悪いのか理解されるようになりました。 サイロは異なるチーム間のコミュニケーションを複雑にし、デリバリー遅延や手戻り、バグにつながります。

インシデント管理においては、あるベンダー製品の管理データと別のベンダー製品の管理データを分けるというサイロがあります。このサイロは、複数ソースからの監視データの収集と分析を困難にするため、インシデント解決を妨げます。

インシデント管理業務を効率的に流していくために、サイロをどのように分析していますか?

サイロを特定する

インシデント管理での作業の最初のステップは、サイロが最初に存在する理由を理解することです。

理由は簡単です。現代のインフラストラクチャは、多様なハードウェアとソフトウェアで構成されています。ほとんどのコンポーネントには特別な監視が必要です。特定のリズムに従って情報を特定の形式で出力し、特定の方法でデータを収集する必要があります。したがって、インフラストラクチャの各部分に関連する監視情報は、インフラストラクチャの他の部分からのデータと容易に比較できないため、サイロの中に入ってしまいます。

基本的な例として、Windowsを実行する10個のベアメタルサーバと、Linuxを実行する10個のベアメタルサーバで構成されるデータセンターを考えてみましょう。このシナリオでは、Windows用とLinux用の異なる監視ツールを必要とします。ホストが落ちていないかどうかなど、各タイプのオペレーティングシステムに関する監視情報の一部は同じですが、他のデータには違いもあります。そのため、各OS専用のツールでデータを収集する必要があります。したがって、Windows、Linuxそれぞれが専用ツールでデータを監視するエコシステムを備えた明確なサイロになります。

これは単なる例です。モニタリングする2種類のベアメタルサーバだけでなく、各種のハイパーバイザ上で実行される仮想サーバ、各種デスクトップOSを実行するワークステーション、いろいろなモバイル機器やモバイルOS、バージョンなど実際の現場ではさらに複雑になります。

サイロを壊す

シームレスで全体的な監視の可視性を得るために、インフラストラクチャ内の各監視コンテキストを分離するサイロをどのように排除するか。このソリューションには2つの部分があります。

ステップ1:データ収集の集中化

最初のステップは、さまざまなタイプの環境から情報を収集し、その情報を中央の場所に転送できるインシデント管理ソリューションを実装することです。 こうすればエンジニアはインフラストラクチャ全体を1点で監視することができます。 インフラストラクチャのさまざまな部分を監視するために個々のサイロを調べる必要はありません。

集中型のデータ収集には、複数のソースからの監視情報を集約するのに十分な機能を持つインシデント管理ソリューションが必要です。 これは簡単な作業ではありません。 幅広い環境とエンドポイントをサポートするためには、さまざまなタイプの監視システムと統合する必要があります。

ステップ2:データを翻訳する

2番目のステップは見落としやすい点です。インシデント管理チームは、多くの監視ツールのデータを集約し一元管理することに加えて、すべてのデータを一貫したフォーマットに変換する必要があります。

すべてのエンジニアがあらゆるソースからのアラートを解釈して対応できることを保証する唯一の方法は、データ変換だけです。データが共通のフォーマットに翻訳されない場合、エンジニアは特定のタイプの監視システムに必要な特別の知識を持たなければならないか、または特定ベンダーのスキーマを知ってそのシステムから発生したデータを理解する必要があります。このように、中央の場所ですべてのデータを利用できるようにするだけでは、複数のシステムを隔てる大きな障壁が依然として存在するため、サイロを分解することはできないでしょう。

たとえば、ZabbixとNagiosで「エイリアス」という用語の使われ方を見てみましょう。以前の監視システムでは、エイリアスは基本的に各種コンフィギュレーションの略語として機能します。対照的に、Nagiosでは、エイリアスはホストの名前です。この違いを理解しないまま、ZabbixシステムとNagiosシステムの両方のデータが集中ダッシュボードに集約されていたら混乱するでしょう。

効果的なインシデント管理のためには、ベンダーやプラットフォーム固有の用語を単一の言葉に置き換えるソリューションが必要です。 PagerDuty Common Event Formatで有効になっているようなイベントの正規化だけで、レスポンダは複数のソースからのデータを簡単かつ正確に解釈できます。

現代のインフラの複雑さは、サイロを避けることを困難にしています。しかしそれは、監視情報がサイロの中になければならないということを意味するものではありません。さまざまなソースからの監視情報を集約し、オンコールチームの誰でも理解できる言語に変換することで、インシデント管理チームはインフラストラクチャ内に存在するサイロを分解することができます。彼らは、シームレスなコミュニケーションと、機敏なインシデント対応が可能になります。

続きを読む
インシデント&アラート
2018年6月20日  (更新日:2022年3月9日)

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

BMC TrueSight Pulseは、DevOpsチームにリアルタイムのサーバーとアプリケーションの監視機能を提供してクラウド、VM、または物理サーバーを監視できるようにし、さらに問題を早期に見つけて修正するための、1秒ごとのメトリックを提供します。TrueSight Pulse側にはPagerDutyと連携するためのメニューが用意されており、簡単に統合することができます。

詳しくはこちら

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

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

BigPandaのデータサイエンスプラットフォームは、自動的にすべてのITアラートを相関させるため、ITの問題を迅速に検出、理解、解決、防止することができます。 BigPandaからPagerDutyインシデントを作成するには、BigPandaのインシデントをPagerDutyと共有するときに通知を送信するようにインテグレーションを設定します。

詳しくはこちら

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

PagerDuty、AWS CloudWatch、GuardDutyなどとのインテグレーション4種を発表

”PagerDuty Launches New AWS Integrations for CloudWatch, GuardDuty, CloudTrail, and Personal Health Dashboard”

by Andrew Marshall

Amazonの元従業員によって設立された会社だから当然と思われるかもしれませんが、PagerDutyはAWSユーザーが何らかのシグナルから自動的に正しい洞察と行動を導くのを何年も助けてきました。 当社のAmazon CloudWatchとのインテグレーションを使えば、各チームは顧客に影響を与える問題を積極的に軽減し、自信を持って組織がAWSとハイブリッド環境の両方を更新し、拡張していくことができます。

今年初め、 AWS Marketplace のEnterprise Contracts for AWS Marketplace を通じて、PagerDutyのサブスクリプションがAWSのお客様にご利用いただけるようになりました。 今週のAWS re:InventでPagerDutyは、AWS CloudWatch Events、GuardDuty、CloudTrail、Personal Health Dashboardのための全く新しいAWSインテグレーションをローンチしたことをラスベガスで発表しました。

Amazon CloudWatch(Events, Alarms):AWSサービスへのゲートウェイ

AWSユーザーは全AWSエコシステムの一部として展開したAWSサービスのステータスを監視するために使うパフォーマンスデータを、Amazon CloudWatchを利用して得られます。パブリッククラウドリソースを活用しても、ユーザーがサーバーの基盤となるサーバーの状態やパフォーマンスを無視することはできません。 実際には、使用するさまざまなツールを監視することは、企業が重要なアプリケーションをAWSに移行するにつれて、ますます重要になっています。

CloudWatch AlarmsとのPagerDutyのインテグレーション(AWSと当社に共通するユーザーがしばらく使用していたもの)は、ユーザーがリソースの使用状況(メモリの最適化など)をカスタマイズした細かなアラームしきい値を設定することで監視できました。 これらのアラームがトリガーされると、PagerDutyを介して必要な解決の自動処理を始められます。 これは非常に強力な組み合わせです。PagerDutyが提供する中で一番の人気のあるインテグレーションではないにしても、それが人気のあるインテグレーションの1つである理由は驚くことではありません。

非常に便利なツールですが、CloudWatch Alarmsは指定期間に1つのメトリックしか監視せず、全期間で同じしきい値を基準にして、あるメトリックの値がそれを超えた場合に1つまたは複数の指定されたアクションを実行します。 言い換えれば、特定の時点で一度だけアラームが発生します。 今週のAWSでは、当社のAmazon CloudWatch Alarmsインテグレーションを補完する新しいAWSインテグレーションであるCloudWatch Eventsの提供を開始しました。

CloudWatch Eventsは、AW Sリソースの変更を記述するシステムイベントのストリームであり、CloudWatchが収集するメトリックを強化するものです。 「イベント」は、AWS環境を支えるサービスと同様に、AWS環境に起きる変化のことだと考えてください。

現代のITOpsチームとDevOpsチームにとって、変化を監視することは、エコシステムの継続性とパフォーマンスの維持のために不可欠です。 たとえば、各チームはEC2インスタンスが状態を「pending」(保留中)から「running」(実行中)に変えたかどうかを知る必要があります。また、「スケール」が実際に「オートスケール」でどのくらいの頻度で行われているかを知る必要があります。さらに、AWS CloudWatchとCloudTrailとを併用すると、API呼び出しのようなことも確認できます。

弾力性と迅速なスケーラビリティは、AWS、Google Cloud、Microsoft Azureなどのパブリッククラウドプロバイダーにとって重要な価値を提案するものです。 「pay for what you use」(あなたが使っている分の対価を払う)サービスとして、AWSの請求書を見ることは、ほとんどのチームにとっても非常に重要です。 CloudWatchインテグレーションにより、PagerDutyはAWSからの請求が一定のしきい値を超えた場合にあなたに警告するので、無計画なスケーリングを避けることができます。

CloudWatch Alarmsの上にCloudWatch Eventsインテグレーションの機能を追加することで、PagerDutyは、よりしっかりしたAWSのデータの集合に基づいてチームのデジタルオペレーションを自動化することができます。PagerDutyのお客様は、以下のような多くのAWSサービスのデータを活用することもできるようになります。

Amazon EC2インスタンス AWS Lambdaファンクション Amazon Kinesis Data Streamsのストリーム Amazon Kinesis Data Firehoseの配信ストリーム Amazon ECSのタスク Systems Manager Run Command Systems Manager Automation AWS Batch ジョブ Step Functionsステートマシン AWS CodePipelineのパイプライン AWS CodeBuildプロジェクト Amazon Inspector Assessment Templates Amazon SNSのトピック Amazon SQSのキュー

オンデマンドサーバー、AWS、Azure、Google Cloud、またはハイブリッドインフラストラクチャなどあらゆる組み合わせを使用している場合でも、PagerDutyはインフラストラクチャから重要な信号を収集し、リアルタイムオペレーションを強化します。

Amazon GuardDuty

最近では、AWSの shared responsibility モデルとうまく一致する「security is everyone’s responsibility」(セキュリティは誰でも責任がある)という言葉を普通によく耳にします。セキュリティはみんなの仕事でもあり、 PagerDutyのAmazon GuardDutyとのインテグレーションにより、レスポンスワークフローを自動化するだけでなく、セキュリティ専門家にエスカレートするという面倒を軽減することで、セキュリティの管理権限を開発者にもたすことができます。 Amazon GuardDutyを使用すると、組織のAWSエコシステムやその上に構築されたアプリケーションに悪影響を及ぼす可能性のある、悪意のある行為や不正行為を継続的に監視できます。 たとえば、予期しないAPI呼び出しや侵害されたインスタンスを心配する必要はないでしょうが、その情報を収集してより深い分析が行えるようにする方がよいでしょう。

そこが、PagerDutyとDevSecOpsが入るポイントです。CloudWatchでマシン指向の出力を収集することは、最初のステップに過ぎません。脅威の性質、全体的な影響、および正しい対処方法を判断するためのワークフローが必要です。 Amazon GuardDutyによって脅威が検出されると、PagerDutyはレスポンス・ルールに基づき、その重要なセキュリティ問題に適切な人物に、自動的に通知します。 さらに、 PagerDuty Event Intelligenceを使用して脅威を他の問題とグループ化し、同様のアラートに埋もれさせるのではなく、問題に対処する正しいコンテキストを提供することで、チームは騒音を削減できます。 これらのすべては、さまざまな記録システム(Jira、ServiceNow、Remedy、Cherwellなど)とのシームレスなインテグレーションによって実行できます。

Amazon Personal Health Dashboard

AWSにはたくさんサービスがあります。 そして、彼らはおそらく、今週さらにいくつか新サービスを立ち上げる予定です。 これらの新しいサービスは、AWSユーザーに新しいソフトウェアを構築しサポートするための優れた柔軟性とパワーを提供しますが、AWSサービス、地域、およびゾーンの現在の状態を、組織がはるかに容易に知ることができます。例えばした下の図は北米向けのAmazon Personal Health Dashboardのスクロール表示です。

AWSは、このAWS Personal Health Dashboardの中の問題点を理解しています。Service Health Dashboardは全体としてはAWSサービスの一般的な状態を示してくれますが、Personal Health Dashboardは、あなたのチームが毎日気にしているAWSサービス群に関するこれらのアラートは役に立ちますが、その知識であなたは何かをする必要があります。

新しいPagerDuty AWS Personal Health Dashboardインテグレーションによって、このデータを取り込んで、どうやって、いつ、そしてだれと一緒に対応するかといった、あなたが問題解決のために取る必要があるステップを自動化できます。各チームは、問題の原因となっているAWSサービスでのサポートプレイとチケットを追加し、組織内の全員にAWSサービスの中断に迅速に対処するために必要な情報を提供できます。

もしre:Inventに出席し、Personal Health DashboardとPagerDutyのインテグレーションについてもっと知りたい場合は、AWSが提供する以下のセッションをチェックしてください。

日時: 11月26日(月曜日)午後4時

場所: Bellagio、レベル1、グランドボールルーム6

セッション:Optimize Performance and Reduce Risk Using AWS Support Tools (ENT316-R1)

日時: 11月27日(火)午前11時30分:

場所:Mirage、Mirage Event Center C3

Amazon CloudTrail

AWSとエンドユーザの間のもう1つの共通の責務は、コンプライアンス、ガバナンス、および運用監査です。 サーバーがデータセンターにないからといって、それらのワークストリームを放置することはできません。 AWS CloudTrailは、AWSエコシステムのガバナンス、コンプライアンス、運用監査、リスク監査を可能にします。

チームがAWSエコシステムで発生するさまざまなイベントのログを保存できるようにすることで、Amazonは、AWS Management Console、AWS SDK、コマンドラインツール、およびその他のAWSサービスを通じて行われるアクションを含む、コンプライアンスを管理するための強力なツールを提供します。 あなたが容易に想像できるように、こういったことは、戦いの半分です。

PagerDutyの新しいAWS CloudTrailインテグレーションにより、チームはDevSecOpsのプレイに使用するAWSのイベント履歴全体を収集し、必要に応じてアクションを自動化し、JiraやSNOWのような記録システムとシームレスに統合することができます。 PagerDutyは、DevOpsとDevSecOpsのチームに対して、オペレーション上のノイズをカットして必要なコンテキストだけを与えることで、他の進行中の問題との相関関係やグループ分けを可能にします。 チームは、例えば、Amazon S3で隠れたデータの逆流が発生していないかどうかを特定したり、Amazon Virtual Private Cloudでセキュリティグループルールが変更されたときに瞬時に警告を発することができます。どちらの例でもPagerDutyを使用して、正しいレスポンスを即座に自動化できます。

re:Inventでお会いしましょう DevOpsのコンピテンシーを持つAWSパートナーネットワークの先進的パートナーとして、PagerDutyは re:InventでAWSと共同でこれらのエキサイティングな新しいインテグレーションを共通の顧客に共有できることを喜ばしく思います。 今週ラスベガスにいる場合は、ブース1023にご来訪ください。PagerDutyは無料の14日間のトライアルを提供していますが、それはAWS Marketplaceを通じて調達することができます。 また、 AWSのこれらの統合の詳細についてはこちらをご覧ください 。

次のAWSインテグレーションを使ってください:

https://support.pagerduty.com/docs/aws-cloudwatch-integration-guide

https://support.pagerduty.com/docs/aws-guardduty-integration-guide

https://support.pagerduty.com/docs/aws-cloudtrail-integration-guide

https://support.pagerduty.com/docs/aws-personal-health-dashboard

GET STARTED

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

2018年11月21日  (更新日:2022年3月9日)    |    ニュース&告知

AWS re:Invent 2018へのカウントダウン

もう1年になるのかと思うと信じられませんが、もうすぐAWS re:Inventがやってきます。いつものように、PagerDutyはグローバルなAWSコミュニティに参加して、デジタルオペレーション、ネットワークセキュリティ、アプリケーションパフォーマンスを改善するためのアイデアを共有できることにワクワクしています。

AWS re:Inventは、あなたがたが私たちのチームと出会い、交流し、社交を深め、PagerDutyがどのように組織のリアルタイムデジタルオペレーションの変革を支援するのかを学べる絶好の機会です。今年のハイライトは、PagerDutyがAWSとハイブリッドクラウド環境全体でどのようにデジタルオペレーションを可能にするのかです。PagerDutyがDevOpsとITOpsチームに、顧客と収益に影響を与えるインシデントを積極的に減らし、組織が革新性、生産性、成長を発揮できるようにする方法を紹介します。

さらにあなたは、実用的な情報をリアルタイムで提供する2つの新製品をチェックして、ビジネスチームとテクニカルチームが最高の顧客体験を提供することもできます。PagerDuty Visibilityは、ITとビジネスのギャップを埋め、AWSのインシデントが顧客にリアルタイムで与える影響を示し、チームが積極的に対応できるようにします。PagerDuty Analyticsは、専門知識と一緒に、機械と人間のレスポンスデータを組み合わせ、より良いビジネス上の成果につながるオペレーション方法に関する洞察を提供します。

PagerDutyはどこに? 1週間を通じて出展する場所は

ブース#1023です。ここでPagerDutyチームに会い、クールなお土産を手に入れ、毎日行われる500ドルのAirbnbギフトカードの抽選にエントリーできます。

11月26日 (月)

スピーカーセッション:リアルタイムオペレーションでチームの生産性を引き出す(Unleash Team Productivity With Real-Time Operations)に登場します

時刻:午後1時〜午後2時

場所:Venetianホテルの4階、Delfino 4005

PagerDutyの新しい事例であるDave CliffeとIntuitのDevSecOpsリーダーShannon Lietzが、以前に存在しなかったスケールでリアルタイムオペレーションを処理し、優先順位を付ける必要がある理由について議論する予定です。

セッションでは、 最新のインシデント管理のベストプラクティスと組み合わされた機械学習、自動化、分析の革新が、運用パフォーマンスとチームの生産性を向上させ、より良いビジネス成果をもたらす方法を探ります。

11月27日(火)

イベント:パブクロール – セキュリティゾーン

時刻:午後6時〜午後8時

場所:VenetianホテルのAquaKnox

一緒に飲みましょう! 当社はパブクロールの「セキュリティゾーン」をDatadogとMongoDBと一緒に開催しています。Pag​​erDutyチーム、イベントスポンサー、業界のAWSエキスパートとのカクテルやネットワーキングのためにAquaKnoxにおいでください。

現地でミーティングをしたい方に

PagerDutyがあなたの組織にできることを知るために会議を予約したり、技術的な質問をしたり、製品のデモを見ることができます。PagerDutyがリアルタイムのデジタルオペレーションを通じてより良いビジネスパフォーマンスを後押しする方法を学べます。

Twitterの@pagerdutyをフォローして、我々のニュースとAWS re:Inventからの更新情報を追ってください。ラスベガスでお会いましょう!

(注:残念ながらDigital StacksはAWS re:Inventには出展しません。)

GET STARTED

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

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

AWS CloudWatch統合ガイドを追加しました

Amazon Web Services CloudWatch は、AWSリソースとユーザーアプリケーションの監視を提供します。 AWSは、データを収集し、洞察を得て、ユーザーにアプリケーションの問題を解決するよう警告します。 AWS CloudWatchを使用すると、システム全体でリソースの使用状況を把握でき、任意のメトリックが指定した閾値を超えた場合の通知を設定できます。これらのアラームは、PagerDutyに自動的に送信され、PagerDutyは正しい連絡方法でオンコール担当者に確実に警告します。

詳しくはこちら

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

インシデント対応のボトルネックを回避する

インシデント 対応のボトルネック―今お使いのインシデント 対応システムでは少ないかも知れませんが、確かに存在することをご存知でしょう。オンコールのチームやお客様のためにボトルネックは最小限に抑える必要があります。最も重大なボトルネックのいくつか、およびそれらを回避する方法を見てみましょう。

あなたの目標は何ですか?

まず、プロセスのボトルネックを理解する前に、そのプロセスの目標が何かを理解する必要があります。インシデント対応の目標は何でしょうか。

ほとんどのインシデント対応チームにとって目標はおそらく次のようになります。

インシデントの発生を防ぐ**。 インシデントの予防は、問題解決を主な目的とするインシデント管理の手には余る可能性がありますが、予防は計画外の作業を削減するために重要です。 損害を最小限の範囲にとどめる**。実際には、インシデント管理における予防的取り組みの大部分はこの点に焦点に当てられています。インシデントが発生しないようにすることができない場合でも、インシデントが広がらないようにすることができます。 インシデントを迅速に解決する**。全てのインシデントを解決できるわけではなく、全ての修正が根本的な問題を解決するわけではありませんが、迅速なインシデント解決は一番重要です。

各ボトルネックを監視する

上記がインシデント対応の基本的な目標である場合、ボトルネックはそれらの目標を達成することを困難にします。これらの中で最も重要なものは次のとおりです。

優先順位を適切に設定できない

優先順位付けは、インシデント解決とインシデントの影響の封じ込めに利用できる最も重要な手段です。深刻な影響の可能性に基づいて、最も注意が必要なインシデントに焦点を当てることができます。インパクトが比較的少ないインシデントは脇に置いておくこともできますが、それでも多大なチームの時間と注意が取られます。適切な優先順位を設定しなかった場合、重要なインシデントの一部が速やかに処理されない、あるいはまったく処理されないことがあります。

過負荷とアラート疲れ

対応チームがアラートの量に圧倒された場合、どの問題を優先すべきか判断する時間がないため、または真のインシデントをノイズのアラートから見分けることができず、麻痺して全てに対応することができなくなります。これは慢性的なアラート疲れにつながる可能性があります。チームメンバーが無意識にほとんどのアラートを無視する精神状態に陥るため、僅かなインシデントにしか集中できなくなります。

アラートのノイズをフィルタリングするための(典型的には自動化された)システムが絶対必要です。対応不可能なアラートを抑制し、関連するアラートを1つのインシデントにグループ化する必要があります。理想的には、これはルールを介して自動的に行われるべきです。さらに、アラート疲れや報告忘れが致命傷になる可能性があるため、チームメンバー全員にアラートするのではなく、適切なチームやチームメンバーだけにアラートを送るシステムを導入することが重要です。

不十分な準備、訓練、経験

理想的には、全てのインシデント対応チームは、問題を迅速に診断でき、各インシデントを修正するためにどのツールとテクニックを使用すべきかを理解している、高度に熟練した技術者で構成する必要があります。

このような問題を最小限に抑える最良の方法は、インシデント対応者のための正式なトレーニングシステムを用意すること、新しいチームメンバーは可能な限り経験豊富なチームに配属すること、チームに適切なドキュメントを用意することです。一貫性と再現性の高いベストプラクティスを実現するためのドキュメントには、基本的な手順のマニュアルや、索引付きで簡単に検索できる相互参照の効くデータベース(過去のインシデントなど)が含まれている必要があります。

メジャーな新製品のロールアウトに対する不十分な準備

メジャーなアプリケーションのリリースの際―それは全く新しいアプリケーションやサービスかもしれませんがー開発者がいくつかの重大なバグを見逃して大量のアラートが押し寄せる事態に対応チームは備えておくべきでしょうか。結局のところマーフィーの法則はいつでも有効です。それが起こるのは広く使われているプログラムのアップデートや、1つ2つのバグが絡みあったトレースしにくいエラーを発生させる場合です。対応チームが準備できていない場合、時間とリソースの全てが優先順位の高いアラートの暴風に巻き込まれ、関連性のないその他のインシデントを処理するための余裕はほとんどありません。

もちろん、リリース前にA/Bテストやカナリアテストなどでアップデートが適切にテストされていることが理想的です。応答チームが配備作業に加わっていれば、問題がはるかに小さなうちに対処できる機会があります。しかし、限定的な導入から始めるという決定をインシデント対応チームが下すのは不可能であり、十分にテストされていないリリースに対処しなければならない可能性があります。

このような状況では、全ての対応者をオンコール待機にするか、アップデートで起こる全ての問題を処理する特別なチームを指定する必要があります。どのアプローチが最も効果的かは、少なくとも更新の範囲と利用可能な対応チームのリソースによって決まります。しかし、計画はいつでも何度でも必要に応じて変更できますし、計画を立てておけば準備ができていない場合とは大違いになります。

ボトルネックの解消

他にも、時代遅れの障害が発生しやすいインフラや過負荷のインフラから生じるインシデントや、インシデントとは無関係のタスクで対応チームの時間が取られるなど、多くのボトルネックがあります。しかし、私たちが列挙したボトルネックは、インシデント対応チームが時間を消費した理由の多くを占めており、ここで提案した修復アプローチは、それらの大半をなくすのに役立ちます。

2019年9月9日  (更新日:2022年3月9日)    |    ニュース&告知

【2019年8月リリースの概要】 新しいモバイル機能、強化されたセキュリティと分析、Amazon EventBridgeとのインテグレーション

PagerDutyは2019年8月、新しいリリースを発表いたしました。このリリースでは、いつでもどこからでもリアルタイムで安全に作業できるように、新しい製品機能と拡張機能のセットが提供されます。

このリリースでは、デジタルオペレーションを最適に管理するためのより良いプラットフォームを構築するというお客様のニーズに引き続き応えています。機能強化には、モバイルアプリの新しいイノベーションと、メールドメインの制限を追加することによるプラットフォームセキュリティの強化が含まれます。また、分析スコアカード機能をより柔軟にし、Amazon EventBridgeとの新しいパートナーエコシステムのインテグレーションを追加しました。

モバイルプラットフォーム

すべてのインシデントが24時間以内に解決できるわけではないため、ユーザーが24時間以上アラートをスヌーズするオプションを追加し、営業時間外のアラートをより柔軟に管理できるようにしました。長時間スヌーズは現在iOSアプリで利用可能ですが、Androidでも近日中に提供される予定です。

設定についての警告

ユーザーは設定メニューで PagerDutyインスタンスのセットアップを最適化する方法を見つけることができます。警告をタップして、連絡方法と通知ルールを更新します。たとえば、ユーザーがSMSやメールなどの連絡方法を追加するのを忘れた場合、連絡方法の追加を推奨する警告がポップアップ表示されます。

ビジネスサービスのステータス更新

ビジネスレスポンス用PagerDutyソリューションをローンチしました。これは、アドオンのModern Incident Response上に構築されています。この新しいソリューションには、ビジネス関係者に明確で簡潔な情報を提供する新しいステータスダッシュボードが含まれているため、チームはインシデント発生時のリアルタイムのビジネスおよび技術的対応をより適切に連携、調整できます。

ユーザーはインシデントに優先度レベルを割り当て、モバイルアプリから直接ビジネスサービスに関連付けることができます。この新機能により、技術担当者はビジネス系サブスクライバーに通知でき、ステータスダッシュボードの適切な場所に情報が表示されるようになります。

iPadレイアウトの改善

新しいiPad用のレイアウトにより、より大きな画面をより有効に活用し、インシデントをタップして詳細を表示できます。また、分割画面のサポートもあり、PagerDutyアプリをカレンダー、Slackなどの他のアプリと一緒に使用できます。

eメールドメイン制限付きの強化されたプラットフォームセキュリティ

メールドメインが制限されているお客様用に、セキュリティレイヤーを追加しました。これにより、承認されたメールドメインを持つユーザーのみがPagerDutyセッションにアクセスできるようになります。管理者とアカウント所有者は、ユーザーがログイン情報を作成または変更したり、メールアドレスに連絡したりするときに、メールドメイン許可リストにあるドメインのみを使用するように制限することができます。

新しい分析スコアカード検索と購読、購読解除機能

新しい分析スコアカード検索により、ユーザーはチーム名またはカスタムスコアカード名を検索することにより、利用可能なスコアカードのリストから特定のスコアカードをすばやく見つけることができるようになりました。以前は、ユーザーはスコアカードのリストを目で見て必要なものを見つける必要がありました。特に、多くのチーム、多くのスコアカードを購読しているリーダーや大規模な組織のユーザーにとっては、時間がかかるイライラする作業でした。

また、ユーザーはスコアカードのサブスクライブを設定、解除できるようになりました。これにより、チームに所属していない場合でも、チームの運用指標を確認できます。サブスクライブ/サブスクライブ解除機能を追加することにより、ユーザーはUIに表示するスコアカードの中から見たいものだけを表示できるため、カスタマイズされ、すっきりしたユーザーエクスペリエンスを体験できます。たとえば、マネージャーやエグゼクティブのマネージャーは、さまざまなチームグループに参加することなく、関心のあるデータを表示するためにサブスクライブできます。

パートナーエコシステムインテグレーション

Amazon EventBridge

PagerDutyとAmazon EventBridgeとのインテグレーションにより、チームはネイティブAWSサービスをPagerDutyに接続するイベント駆動型のワークフローを簡単に作成できます。Amazon EventBridgeを使用すると、PagerDutyのお客様は、AWSがサポートする幅広いインテグレーションと機能を活用できます。

この8月リリースの新機能にご興味がある場合は、詳細についてのサポート技術情報をご覧ください。

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

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

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

Aruba ClearPass Policy Managerプラットフォームは、ロールベースとデバイスベースのネットワークアクセス制御を、有線、無線、VPNインフラを介して、従業員、請負業者、ゲストに提供します。ClearPass Policy ManagerはPagerDutyにプロアクティブなアラートを提供し、ネットワーク上で発生したイベントをリアルタイムで確実に適切なスタッフに通知します。

詳しくはこちら

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

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

Apteligent(旧Crittercism)は、モバイルアプリの性能の最適化を助けます。性能に関係するあらゆる側面を監視して、アプリの診断結果を表示します。PagerDutyとの統合により、ApteligentでトリガーされたアラートがPagerDutyのインシデントを自動的にトリガーし、PagerDutyのスケジュール管理、アラート、およびインシデント追跡システムを利用できるようになります。

詳しくはこちら

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

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

AppOpticsは、クリティカルなITシステムのメトリクスを収集して可視化できる強力なサービスです。PagerDutyとのインテグレーションにより、PagerDutyインシデントを自動的にトリガーし、システムの潜在的な問題について直ちに通知できるようになります。

詳しくはこちら

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

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

AppDynamicsはアプリケーションやデータベースのパフォーマンスをモニターし、分析し、管理するためのツールです。PagerDutyは自由に設定したAppDynamicsのパフォーマンス閾値に従って通知します。

詳しくはこちら

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

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

ApicaはWebサイトが利用可能で、期待通りに応答しているかをモニターする強力な監視ツールです。

Apicaは簡単な設定でPagerDutyと直に統合できます。

詳しくはこちら

2017年12月27日  (更新日:2022年3月9日)    |    ベストプラクティス

インシデントの経験を事後検証で最大活用

インシデントを経験した後 のポストモーティム(事後検証。post-mortem またはpostmortem と表記される)に 何をします? 簡単な質問のように見えるかもしれません。 結局のところ、インシデントの処理の最後のステップとして事後検証を考えるのは簡単です。

しかし、そうではありません。 多くの点でインシデントのポストモーティムで何を検証するかは、ポストモーティムをすることと同じくらい大事なんです。以下、理由を説明し、事後検証が終わったあとに何をするべきか、そのヒントを提供します。

なぜポストモーティムするの?

しかし、この質問の意味を考える前に、より根本的な質問、つまりポストモーティムの機能とは何か、そしてそれには何を含めるべきかを検討する必要があります。

ポストモーティムは基本的に以下の役割を果たします:

インシデントとその原因および関連する兆候、解決策、将来の参考になる影響の記録を提供する。技術的問題を将来理解するためと、事件から生じる法的または行政上の懸念の解決の両方にとって重要になり得る。 事件を引き起こした基本的な技術的問題を分析し解決するための基礎として役立ちます。 インシデント対応プロセスを理解し改善するためのフレームワークを提供します 。

これらの基本的な役割をサポートするために、ポストモーティムにはインシデント、対応、解決の記録が含まれていなければなりません。 また、インシデントの根本原因の分析 、インシデントの範囲とその影響の説明、根本的な問題の解決、対応プロセスの改善、および/または将来のインシデントの影響の最小化のために適切な推奨事項も含める必要があります。

理解したあとに、責めないこと

大事な注意点ですが、ポストモーティムを責任追及の手段にしてはいけませんし、企業や組織のポリシーに点を付ける手段にならないように注意してください。必要ならば、事後検証から責任追及を分離するためにインシデント関連の問題を議論するために別のプロセス(すなわち、部門内での非公式で司会を立てた議論)を設定してください。

一方ポストモーティムでは、インシデントを起こす背景になった可能性のある、または対応中に明らかになった、技術的または組織的問題についての正直な議論が含まれるべきです。 技術や反応プロセスの改善に重点を置くべきであり、個人やチーム、あるいはその仕事の欠陥に置くべきではありません。

ポストモーティムはいつ必要?

すべてのインシデントでポストモーティムをする必要はありません。 軽度の運用上の問題や、よく原因が分かっており簡単な解決策があるインシデント、そしてダウンタイムやデータの消失が起きなかったインシデントには、ポストモーティムが必要ない場合があります。

ポストモーティムが必要な状況の例をいくつか示します。

データや生産性の低下、または顧客のアクセスにつながるインシデント シャットダウン、再ルーティング、以前のソフトウェアバージョンへのロールバック、および/または解決のための長期のアクションが必要だったインシデント 適切な監視やアラートシステムがあったのにうまく検出または処理されなかったインシデント 根本原因が不明、あるいは予想を超えていた、または今後も発生が疑われるインシデント システムの動作に広範囲の影響を及ぼす可能性のある、アプリケーションアーキテクチャや技術の根本を含むように見えるインシデント 回答や解決プロセスに深刻な問題や不備があったインシデント

ポストモーティムは学習を容易にする

ポストモーティムを価値あるものにするにはその書き方を、長期的な問題の分析、解決、防止を担当する人々が読みやすくかつ理解しやすくする必要があります。

これは、例えば、問題やその解決を抱えているチームや部署は、ポストモーティムの記録を読むことを読み、さらに結果として適切な次のステップを決定するために、できるだけ早く議論に参加することを要求されているからです。 どうポストモーティムの資料を流通させて、それらを読んだあとの行動にどう導くかという実際のプロセスは、もちろん、あなたの組織の構造と経営理念に依存します。

ポストモーティムの基本要素

ポストモーティムを書いたり読んだりするときには、次の3つの重要な分野があります。

根本的な原因

ポストモーティムは必ず根本原因の説明を含むべきです。根本的な理由が既に分かっていても、ささいなことであっても。ささいな原因ではない場合は、問題の実際の根本原因を正確に特定し、それを修正する必要があるかどうかを、原因の分析に含める必要があります。 根本原因を正確に特定できない場合は、将来の特定につながる可能性のある情報を含める必要があります。

例えば、インシデントの解決の過程で、その問題が多量のレガシーコードを含むモジュールで生じたことが明らかになったけれども、そのモジュールよりも下の部分にある根本原因を特定できなかったという場合でも、その事実を根本原因の分析に含めることが重要です。インシデントと関連してレガシーコードを特定したという事実の記録は、インシデントの解決だけでなく、後の調査で置き換える必要のあるコードを特定することにおいても価値があります。

対応

ポストモーティムには、対応プロセスの完全な技術的説明が含まれていなければなりません。 また、そのプロセスの相対的に見た成功または失敗の説明と分析も含める必要があります。 これは誰の責任も問うことなく実施されなければなりませんが、対応プロセスまたはそのプロセスの実施中の明らかな失敗や弱点を明確に示すべきです。 これには、対応チームメンバー間の責任分担、対応チーム内の連絡、または対応チームと他のステークホルダーとの間のやり取り、特定の対応プロセスの問題が含まれます。

対応プロセスの失敗は、技術的または組織的なものに及ぶ可能性があります。インシデントの解決中にシステムやアプリケーションが利用できないことを、その影響を受ける部門やユーザーに伝えられなかったというような、簡単なことが含まれます。 2つのチームのメンバーが協調せずに同じタスクを実行してしまったり、誰も必要なタスクを実行しなかったために、結果として解決に時間がかかりすぎた場合は、ポストモーティムの中にはチーム構成やコミュニケーションの潜在的な問題を示す注記を入れておく必要があります。

被害の影響範囲の確認と制御

ポストモーティムには、データの損失、生産性の低下、ユーザーアクセスの中断など、インシデントによって引き起こされた損害の程度を明確かつ正確に記述する必要があります。 この被害を限定あるいは緩和するために取られた措置についての説明と分析を含めることも同様に重要です。 ダメージコントロールは、技術的なインシデント解決とは別のプロセスとして考慮する必要があります。 インシデントの種類、被害の種類、および組織の構造によっては、カスタマーサービスの責任である場合や、ビジネス内の他の部門のアクションアイテムが必要な場合があります。

ダメージコントロールは、似たようなインシデントを将来どう処理すべきかに直接または間接に影響する可能性があるため、ポストモーティムの一部に入れておく必要があります。 例えば停電により航空会社のフライト予約システムが停止した場合、そのダウンタイム中に予約を処理するための代替システムを導入することを優先する必要があるかもしれません。

恥と思わず、金と思え

ポストモーティムを最大限に活用するための鍵は、これがアプリケーション、インフラストラクチャ、および対応プロセスの改善のためのロードマップであることを理解することにあります。 各ポストモーティムは、システムの動作方法とインシデントの処理方法を改善する可能性があります。 ポストモーティムを恥とか何らかの失敗の徴候として扱うのではなく、これは将来の金になる貴重な機会だと考えるべきです。

PageDutyは、業界のベストプラクティスを共有し、ポストモーティムのテンプレートを含む完全に無料のポストモーティムハンドブックを提供します。 あなたのチームが問題にできるだけ簡単に対応できるように、自分のポストモーティムプロセスを正式化するのに役立ちます。 PureDutyプラットフォームの一部であるポストモーティムは、自動化されたタイムライン構築、コラボレーティブな編集、実用的な洞察など、 14日間の無償体験版にサインアップし、ポストモーティムのプロセス全体を合理化します。

2018年3月14日  (更新日:2022年3月9日)    |    インシデント&アラート

インシデント管理がアプリケーションのサポートにもたらす7つの利点

インシデント管理は、アプリケーションをサポートする大事な要素です。アプリケーションの仕事をするとき、私たちはプロダクション(本番バージョン)のリリースに大部分の時間を費やします。これには、ロードマップについての打ち合わせ、ニーズと要望の特定、私たちのストーリーと機能の構築が含まれます。その後、多くのサイクルが開発、テスト、QA(品質検証)に費やされます。エンジニアリングチームは環境を準備しながら作業します。その後、アプリがローンチを迎え、チームは次のアプリに移ります。アプリを本格的に提供するのは運営チームの責任です。これがアプリとのやりとりの終わりである場合、開発チームは、改善に関する貴重なフィードバックを多く未解決または未発見のまま残しています。 そこで、インシデント管理プロセスが、アプリケーションを改善し、最終的にお客様にとってより良いエクスペリエンスを提供する鍵を握ることになるのです。

  1. 必要に応じて迅速にエスカレーションし、解決までの時間を短縮する

明確かつ十分に利用されるインシデント管理プロセスがあると、アプリケーションサポートは組織文化の自然な一部となります。インシデントは、ベストプラクティスを反映した方法に沿ってより迅速に、より一貫して解決されます。明文化されていなかったり不規則だったりするインシデント管理は、解決と絶え間ない消火作業で試行を繰り返すことにつながる可能性があります。

  1. クロストレーニングを奨励する

「夜中に誰かを起こしてそれを修正させる」という原則に従って、インシデント管理プロセスは、開発チーム内とチーム間の両方でクロストレーニングを奨励します。 これには、コードの可読性の重要性を強調し、コメントすることで、運用文書と構成管理を最新の状態に保つことを奨励するという副次的な利点があります。

  1. 信頼と透明性の文化を築く

開発チームのすべての人は、バックアップとプライマリの両方でエスカレーションのローテーションに参加する必要があります。これはコミュニケーションとチームの友情を深めます。また、透明性を奨励することで、オンコールに出る開発者はすでにアプリケーションの一般的な感覚を持っているはずであるため、解決までの時間が短縮されます。 チームがマイクロサービスのパラダイムに従っており、各アプリケーションに1つのサービスを含む場合、これはさらに強化されます。

  1. ジュニアスタッフの成長の道を提供する

私たちは、私たちが前進するために急いで来た場所を振り返ることをしばしば忘れています。 チームはまた、思考や意見の多様性から恩恵を受けます。インシデント管理プロセスでは、エスカレーションパスのすべてのレベルをアプリケーションに公開することで、これを促進できます。インシデントを解決することは、ジュニアメンバーにより多くのチームのことを理解させるのに役立ちます。特定のインシデント解決について貴重な知識を得る一方で、アプリケーショントポロジの包括的な設計にも触れる機会が持てます。才能ある人を募集し維持することは、組織にとって重要です。第1層のインシデント対応から開発およびエンジニアリングチームまでの可視的なパスを提供することは、貴重な採用ツールになります。

  1. より良い全体プロセスを作成する

継続的なインテグレーションと継続的な配信技術を組み合わせることで、以前の月次または四半期の導入よりも迅速に展開されます。 これはインシデントを促進し、量と頻度を減らします。 これの成果は、はるかに短い時間枠でバグを修正でき、繰り返しの一時的な修正の必要性を大幅に削減できることです。 これにより、エンジニアリングチームとオペレーションチームの技術的負債の蓄積も少なくなり、実践的に役立つ修正の道が開かれます。

  1. 定量的フィードバックを生成する

追跡される各インシデントは、多くのもののカプセル化です。 これには、修理のための複数の人の時間、解決を記した文書、おそらくバグレポートの提出が含まれます。また、アプリケーションを操作する際に苦労する点の評価も明らかにするに違いありません。これにより、アプリケーションのロードマップを知らせることができ、実装可能な高価値、低エフォートな機能拡張に関する会話を促進することができます。

  1. 内部ツールを開発する

チームが一定のサイズに達すると、職務の差別化が行われます。 これは組織の自然な進歩であり、規模を拡大する方法です。 以前はうまく機能していたアプリケーションを操作するツールは、組織の成長を維持するために不可欠になっています。 インシデント管理プロセスは、このニーズだけでなく、これらのツールを作成するときに開始する場所を明示することもできます。

アプリケーションのインシデント管理は、多くの場合、顧客サポートと成功にとっては重視されないものですが、顧客はアプリケーションの一部のみを見ています。 彼らが経験するのは、アプリケーションのレイヤーを通る狭いパスだけです。 もっと目に見えるくらいアプリケーションの復元力が高く、インシデントが迅速に解決されるほど、すばやくアプリケーションを使用することができます。

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