Blog
ブログ

2018年8月3日  (更新日:2022年3月10日)

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

Honeybadgerは、Ruby on Railsアプリケーションのエラー管理スイートです。 アプリケーションからエラーデータを収集し、ユーザーフレンドリーな形式で表示することで、問題をより迅速かつ容易に追跡し解決します。 HoneybadgerとPagerDutyを組み合わせることで、アラートによってこれらのエラーに関する情報をチームに配信し、記録的な速さで問題を修正できます。

詳しくはこちら

続きを読む
インテグレーション&ガイド
2017年12月15日  (更新日:2022年3月10日)

インシデント管理をスケールさせる方法

インシデント管理は、現代のITOpsチームの成功に最重要です。しかし、ビジネスを成長させるようにインシデント管理をスケールさせることは、成長の痛みを引き起こす可能性があります。監視が必要なデバイス、アプリケーション、システムの規模が拡大するにつれて、ノイズも増え、オンコールスタッフの管理の複雑さも増えます。チームのエンジニアの数が増えるにつれて、効率的で負荷が公平に分散されるような人員配置や、新しい通知方法の実装、時間外の運用計画を立てるのが困難になります。また、ITのハイブリッドモデルとバイモーダルなIT環境を志向する動きは、インシデント管理を複雑にする可能性があります。それにもかかわらず、いくつか実証された技術を試してみると、インシデント管理を計画的で組織的かつ効果的な方法で拡張することができます。

変化するITOps環境に被害を与えない

スケーリングが深刻な問題になる例を参考にまずこの問題の重要性を理解しよう

あなたは会社が新しい事業を買ったのを知りました。そこで、あなたは新たなインシデント管理プロセスを始めることになります。あなたのOpsチームは、すでに担当していることに加えて、新しいIT環境を引き継がなければなりません。まずあなたは、新しいスタックに同じツールと方法を適用することができる完璧なシナリオがないかを考えます。

しかし、現実は完璧ではありません。新しい会社は、以前と違う技術スタックと異なるインシデント管理の監視ツールと方法論を活用するかもしれません。このシナリオは非常に困難ですが、ITチームの成長や、よりアジャイルでバイモーダルなITOps構造の採用など、あらゆる成長シナリオと非常によく似ています。あなたがどんなスケールのシナリオに直面するにせよ、監視、インシデント管理、およびチームの拡大に取り組んでいる組織のためには下記が参考になります。

スケールの主な領域を特定する

新しいハードウェア、ソフトウェア、またはサービスを実装していますか? あなたの将来のITOps環境には新たな複雑さがありますか? あなたのエンジニアリングチームは育っていますか? コードエラーを報告する必要があるアプリケーションを継承しましたか? いずれの場合でも、ITOpsチームが業務を拡大することを余儀なくされている分野を特定する必要があります。

監視ツール

監視ツールが確実にスタック全体をカバーできるようにすることは、スケーリングの成功に最も重要です。この変更を採用するには、現在のスタックの外に複数の、または全く新しい監視システムを実装する必要があるかもしれません。これらのシステムの目的は、フルスタックの可視性を得ることであり、多くの場合、異種システムや新しいシステムを適切に監視するために、さまざまな監視ツールを実装する必要があります。しかし、組織化されたスケールを本当にサポートするには、このデータすべてを正規化し、重複を排除し、相関を取り、実行可能な洞察を得る方法が必要です。各監視ツールによって生成された全イベントを、単一のハブに集中させる必要があります。このハブからはイベントがトリアージされ、オンコールエンジニアにルーティングされるようにできます。

ノイズ減少

監視を実施するのは、効果的なインシデント解決のためにデータを理解することが目標です。監視ツール全体のルーティング動作を調整し、適切なしきい値を設定することは、新しいツールを実装した後にチームがアラート疲れを経験しないで済むようにするための次の大きなステップです。データを集約し、共通のインシデント管理システム内のページングからの対応不能なアラートを抑制またはフィルタリングすることは、ノイズを削減し、スタック全体のインシデントの可視性を高めるために重要です。

事故管理

包括的なインシデント管理プラットフォームは、すべてのツールのデータを統合し、スケールを拡大しながら成長するのに役立ちます。これは、すべての異種監視アラートを1つの共通システムに統合するだけでなく、リソース管理に関する混乱を防ぎ、エンジニアリングチームの成長をサポートします。さらに、より組織的なコラボレーションだけでなく、よりアカウンタビリティを促進するのに役立ちます。ボーナスとして、インシデント分析を活用して、上司にITOpsチームがどれだけうまく稼働停止を管理し解決するかを示すことができます。

スケールと複雑さは去っていません

ITOpsの世界は急速に進化していますが、1つの点は明らかです。ITチームは、業務拡大に全力を傾けるように指示されています。ITOps環境は、よりハイブリッドでアジャイルなアーキテクチャとフレームワークへと移行しています。ユーザーは、さまざまなデバイス間でデータへの高速で信頼性の高いアクセスを絶えず要求しています。その結果、ITOpsチームはスケーリングの計画を立てる必要があります。ダウンタイムの損害が大きくなるにつれて、インシデント管理が必要になっているのです。

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

HipChatサーバースラッシュコマンド統合ガイドを追加しました

HipChatは、デスクトップやモバイルデバイス向けの140 以上の統合とネイティブクライアントを持つ、チーム向けの永続的に使えるグループチャットです。 この統合により、HipChatからPagerDutyにインシデントをトリガーすることができます。 このガイドの情報は従来の、HipChat Server integrationとlegacy HipChat integrationを補完するものです。

詳しくはこちら

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

HipChatエクステンションガイドを追加しました。

※ HipChat Cloudとの統合はこちらを参照してください。

HipChat は、デスクトップやモバイルデバイス向けの140以上の統合とネイティブクライアントを持つ、チーム向けの永続的に使えるグループチャットです。HipChatからPagerDutyのインシデントをトリガーできるようになります。HipChat Serverとの統合には別の記事を用意しております。そちらをご覧ください。

HipChatエクステンションガイドについて詳しくはこちら

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

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

Graylogはオープンソースのログ収集、検索、管理ツールです。Graylogストリームがアラートをトリガーすると、あらゆる通知をPagerDutyで表示するように設定できます。PagerDutyをオンコールスケジューリングとチームへの通知のための集中化された場所として利用できます。

詳しくはこちら

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

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

Freshserviceは、クラウド上のプラグアンドプレイITILサービスデスクです。 インシデント、問題、変更、リリース、資産管理などのコア機能をクラウド上でカバーしています。

このインテグレーションには、 REST APIキーが必要です。このキーは 、管理ユーザーとアカウント所有者のみが生成できます。 また、REST APIを使用するには、 基本プラン以上が必要です 。 ナレッジベースで REST APIキーの生成について詳しく読むことができます。

詳しくはこちら

続きを読む
インテグレーション&ガイド
2017年12月8日  (更新日:2022年3月10日)    |    インシデント&アラート

ファーストデータ、ファーストモニタリング

ビッグデータはもう古い。 今日、データを効果的に活用するための鍵は、ファーストデータです。

大量の監視情報の収集と分析を伴う従来のインシデント管理ではもはや十分ではありません。 また、監視データの収集だけでなく それをリアルタイムで実行する「ファーストモニタリング」が必要とされています。

ここでは、ファーストモニタリングが意味することを検証し、インシデント管理チームがこのアプローチを実装して大きなメリットを実現する方法について説明します。

ファーストデータの定義

ファーストモニタリングの概念を理解するためには、ビッグデータの世界で最も新しいイノベーションの1つであるファーストデータを理解する必要があります。

非常に簡単に言えば、ファーストデータは高速にビッグデータを処理することです。 ビッグデータとは、伝統的に大量の情報を保存して後で分析することを意味しますが、ファーストデータとは、大量の情報をできるだけ速く、理想的にはリアルタイムでデータ分析を実行することを意味します。 その目標は、できるだけ実用的で関連性のあるデータを分析することです。

ソースから分析プラットフォームにデータをストリームするのは、ファーストデータを活用する上で重要な部分です。 これが、Apache Sparkのようなビッグデータツールが近年普及している理由です。 ストリームデータの収集とインメモリ処理をサポートすることにより、Sparkは非ストリーミングやハードディスクによるデータ解析プラットフォームよりもはるかに高速で大量の情報を取り込み、分析できます。

ファーストデータとインシデント管理

インシデント管理はデータ分析とは異なる分野ですが、インシデント管理者はファーストデータへの移行トレンドから多くのことを学ぶことができます。 インフラストラクチャの監視とインシデント管理の世界では、大量の監視とアラートのデータをリアルタイムで分析してレスポンスを向上させることが、これまで以上に重要になっています。

伝統的なインシデント管理から迅速なインシデント管理まで

ファーストデータとファーストモニタリングのつながりは偶然ではありません。多くの点で、インシデント管理の進化はデータ分析の進化を反映しています。

約10年前までは、インフラストラクチャのデータは比較的小さくて済んでいました。ほとんどの組織では、それほど多くのデータを生成しなかったため、ペタバイトクラスのデータを分析する必要はありませんでした。同様に多くの組織は、大規模で多様なインフラストラクチャをサポートできる監視ソリューションを必要としませんでした。代わりに、サーバやワークステーションからなる比較的小さくて複雑ではないネットワークをトラックするためのベーシックな監視システムで済んでいました。

そして、2000年代半ばには、データとインフラストラクチャの両方が大幅に拡大し始めました。すべてをデジタル化することで、組織は大量の情報収集を開始し、ビッグデータを生み出しました。その一方で、モバイルデバイスの普及、仮想化の台頭、さらにますます強くなるコンピューティングパワーの必要性は、インフラストラクチャをはるかに大きく複雑にしました。この新しい状況には大規模なモニタリングが必要でした。

そして、ここ数年の間に、もうひとつの変化が起こっています。情報が絶えず変化している時代には、ほんの数時間の分析の遅れでもデータの価値が損なわれます。同様に、最新ではない情報を監視することに基づいてインシデント管理を実行することにより、管理者はインシデントを迅速に処理して対応することができなくなります。

したがって、ファーストデータとファーストモニタリングには異なるツールセットが必要な場合がありますが、両方の動機と原則は同じです。インシデント管理チームがインフラストラクチャとアプリケーションをできるだけスムーズに稼動させようとファーストモニタリングに専念するのは、データアナリストの仕事とよく似ています。

ファーストモニタリングの促進

情報の収集と迅速な対応は簡単に聞こえるかもしれませんが、実際にはどのようにしてファーストモニタリングを行うことができるでしょうか。主なガイドラインは次のとおりです。

データ収集を一元化する:** 迅速に情報を監視するためには、すべての監視データを中央のインターフェイスに転送する必要があります。これにより、異なるダッシュボードや監視システムを切り替える必要がなくなり、時間と精神的なエネルギーを無駄にするだけでなく、根本原因を理解することが非常に困難になります。 利用可能なすべての情報を収集する:** 伝統的なインシデント管理は、マシンのデータとアラートの収集だけに集中する傾向があります。その情報は、迅速な監視を行うために必要なものの一部を提供しますが、可能な限り迅速にインシデントに対応するためには、可視性と洞察力を可能な限り広げるべきです。たとえば、チケットやサポートコールから人間が生成したデータを収集することを無視してはいけません。これは、PagerDutyのカスタムイベントトランスフォーマーなどの機能を活用して、従来はインシデント管理ワークフローの一部ではないソーシャルメディアチャネルなどのソースからデータを収集することも意味します。 ノイズを最小限に抑える:** 大量のアラートを受け取っても、アクションを必要とするのはそのうちの一部だけです。 したがって、警告の数が最小限になるようにノイズをカットし、対応不要なものを抑止することは絶対に重要です。重複するアラートは自動的に排除されるべきであり、解決が必要な単一の問題に関連する症状をグループ化するのは簡単なはずです。これにより、注意を必要とするアラートの瞬時識別が容易になり、リアルタイムで適切な応答ワークフローが開始されます。 データを解釈しやすくする:** 大量の監視データを収集し、中央の場所に格納することで、そのデータをすぐに価値に変えることができます。 しかし、ダッシュボード上の情報を分析する負荷を軽減するには、さまざまなソースからのデータを一貫した形式に正規化する必要があります。 そうすれば、さまざまなベンダーのすべてのスキーマを暗記する必要はありません。 これを実現するには、さまざまな形で情報を取得し、フィールドを普遍的なものに標準化し、即座に実行可能でわかりやすい洞察を与えるインシデント管理ソリューションが必要です。

これらのプラクティスはすべて、重大な事故の際にインシデント管理者が必要とする手動分析の量を最小限に抑えます。 また、アラート収集とアクションの間隔を最小限に抑え、インシデント管理スタッフがインシデントに素早く反応し、ファーストモニタリングをリアルタイムレスポンスに変えて正常稼働時間を向上させます。

2020年8月21日  (更新日:2022年3月10日)    |    インシデント&アラート

リモートインシデント対応でPagerDutyを常にオンに保つ

2020年7月初め、多くの地域で、サービスプロバイダーのルータの設定ミスによる大規模なインシデントが発生しました。これにより、サービスの障害が連鎖的に発生し、いくつかの有名なSaaSに広範囲の停止と混乱を引き起こしました。

障害が発生したとき、我々PagerDutyのチームはすぐにイベントやインシデントの世界的な急増に気付きました。いくつかの組織内でアラートやインシデントが増加することは珍しくありませんが、今回のケースでは、複数の地域で多数発生していました。これは懸念材料でした。

インシデントの量が異常に増加した場合には、問題に対処するために総力を挙げて対処できるように、予防措置としてメジャーインシデント対応を積極的に展開しています。対応者にタイムリーに通知を行うために、PagerDutyのモバイルアプリを使用して、必要な関係者がどこにいようとも、即座に連絡を取るようにしています。

この特定の問題は、私たち全員がリモートで仕事をしている時に起きたので、私たちはSlackとZoomを使って対応を調整しました。PagerDutyとSlackとのインテグレーションを利用して、インシデント責任者、エキスパート、利害関係者、記録係からなる完全にリモートのチームを編成し、サンフランシスコ、トロント、アトランタで協力して大規模なインシデント対応を3分以内に完了させました。

当社のインシデント責任者が対応を調整し、カスタマーサポートが内部と外部の情報更新を管理し、専門分野のエキスパートが取るべき必要な手順を議論し、記録係が対応の進捗状況とコミュニケーションを文書化しました。

幸いなことに、当社のシステムがインシデントトラフィックの急激な増加に対応できることを迅速に判断し、問題を沈静化することができました。

リモートインシデント対応の重要性

完全に遠隔地での作業環境でのこのような大規模なインシデントは、場所に関係なく、インシデントを迅速に受任し、チームとして対応することの重要性を浮き彫りにしました。PagerDutyでは、分散化した作業と対応の文化は、初日から私たちのプロセスに組み込まれています。実際、当社のインシデント対応ドキュメントを見てみると、対処中に対応者の物理的な接近を必要とするプロトコルは1つも見当たりません。PagerDutyプラットフォームを使えば、どこにいても、インシデントに瞬時に対応し、作業することができます。

また、SlackやZoomのようなコラボレーションツールを利用して、インシデント発生時にリアルタイムでコミュニケーションを取ることもできます。今回のケースでは、PagerDutyとSlackのインテグレーションが、インシデントの状況と関係者への情報更新のための中心的なハブとなりました。Slackで当社のチームメンバーは主要な利害関係者に通知し、役割を割り当て、仮想的な場所に集まり、インシデントに真正面から取り組むことができました。

さらに、インシデントが解決したあとにも、Slackは事後検証のプロセスに役立つため、将来の対応プロセスにも貢献します。記録係はSlackインテグレーションを使用して、対応中に発生したすべてのことを文書化して記録します。誰が対応したのか、誰が対応しなかったのか、なぜエスカレーションしたのかなど、起きたことをすべて見ることができるので便利です。これにより、インシデントの全体像を把握して理解することができ、将来インシデントが発生した場合でも、より迅速に対応して解決するためのプロセスを改善することができるようになります。

私たちの分散型エンジニアリングの文化は、PagerDutyが何があってもお客様のために常にオンになっていることを保証することを可能にしています。PagerDuty をコラボレーションツールや明確に定義されたプラクティスと共に真実の単一ソースとして使用することで、事実上どこからでもインシデントに効果的に対応することができます。多くの場合、オフィス内のオーケストレーションから仮想的な対応に移行することは困難だと思うでしょうが、PagerDuty を使用することで、ほとんどの場合、通常通りの業務を行うことができます。

チームがどのように PagerDuty を使ってリモートインシデントレスポンスを行うかについては、分散型コミュニケーションに関するこのブログを参照してください。

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

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

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

Errorceptionは、JavaScriptのエラーがユーザーのブラウザで発生しているのを見つけるために一番簡単な方法です。ページにスクリプトタグを挿入するだけで、リアルタイムで発生するエラーを記録することができます。Errorceptionのサービスフックを設定することにより、ErrorceptionからのJSエラー通知をPagerDutyインシデントとして受け取ることができます。

詳しくはこちら

2020年6月30日  (更新日:2022年3月10日)    |    インテグレーション&ガイド

Elixir at PagerDuty:ステートフルサービスによる処理の高速化

PagerDuty の核となる部分の1つは、ユーザーにインシデント通知を送信することです。しかし、ただの通知ではなく適切なタイミングでの適切な通知である必要があり、すでにインシデントに対処しようとしているときにスマホをスパムマシン化させないようにする必要があります。2018年にはElixirを使って、PagerDutyの通知をすべてスケジュールするサービスを書き換えました。

この記事では、通知がどのように機能するのか、また、書き換えを成功させるためにErlang VM(別名BEAM)とElixirをどのように活用したのかを見てみましょう。

古代の歴史

当初は、すべての通知はモノリシックなRailsアプリから直接送られていました。

2014年には、スケジューリング動作がScalaの新しいサービスに実装されました。Artemisです。当時のArtemisは斬新なもので、同期、マルチリージョン、永続的なキューを実現するために自作のCassandraでバックアップされたWorkQueueライブラリを使用していました(当時のKafkaはこれらのボックスをすべてチェックしていたわけではありません)。

この抽象概念の上にあるArtemisは事実上ステートレスでした。キューをポーリングし、作業アイテムをロックし、作業を行い、ロックを解除し、忘れます。このきめ細かいロックは効果的で、どこにいてもアイテムの作業ができ、関係のない作業アイテムを同時に実行することができます。

最近の歴史

私たちは、システムのブラックボックスの動作(すなわち、その入力と出力)を見直し、Artemisの複雑さとインフラコストと対比させました。何かをしなければなりませんでした。私たちは、マイナーな改善作業か、大規模な改修か、あるいは完全な書き換えを行うかを検討しました。

完全書き換えの危険性を慎重に検討した結果、リスクを上回るメリットがあると判断し、進めることにしました。これは通常、リスクの高い提案と考えられていますが、Scala、WorkQueue、Cassandraの使用を止めたかったので、この状況ではうまくいきました。当社のエンジニアは、これらの技術が組織内で人気を失っていくにつれて(また、オリジナルのコード作成者が去っていくにつれて)、これらの技術に馴染みが薄くなってきていました。

Cassandraの3つのアンチパターンは以下の通りです。

Cassandraをキューとして使用しない インターネットで同期レプリケーションはしない 非常に広い列は、Cassandraの水平方向のスケーリングをブロックする

私たちは3つすべてをやっていました。新しい技術スタックを使用し、基礎となるデータモデルを完全に変更しようとしていたので、完全な書き換えはより意味がありました。

当時、PagerDutyは新しいサービスのためにElixirを使い始めていました。ElixirはErlang VM(BEAM)上で動作するコンパイル言語で、ScalaがJVMにコンパイルするのとよく似ています。Elixir/Erlangランタイムは、独立した軽量なプロセスからなる全く異なるパラダイムをもたらします(1つのVMで10万個のプロセスは普通です)。Erlangは数値計算や共有メモリ計算にはあまり向いていませんが、非同期に行わなければならい多くのことがある場合には優れています。

通知スケジューリングの仕組み

PagerDuty では、カスタムのコンタクトメソッドと、それらのコンタクトメソッドをいつ使用するかを示す通知ルールを設定することができます。例えば、以下のようなものです。

携帯電話番号を追加する インシデントが割り当てられたときにすぐに電話をかける通知ルールを追加する インシデントがあなたに割り当てられてから5分後に電話をかける通知ルールを追加する(インシデントがまだ開いていて、あなたに割り当てられていて、それを受任していない場合)

同じ電話番号でも、連絡方法が異なる(例えば、「電話 555-555-0123」と「SMS 555-555-0123」は別)ため、それぞれの連絡方法は別々に扱われます。緊急度の低いインシデントと緊急度の高いインシデントが混在することもありません。情報通知(「私が担当しているインシデントがエスカレーション、受任、解決されたらすぐに教えてください」)はこれらのルールと相互作用しますが、この例では関係ありません。

例えば、インシデント#1があなたに割り当てられたとします。あなたに知らせるために電話をしてみますが、あなたは出ないかもしれません。数秒後、別のインシデント(#2)があなたに割り当てられたとします。私たちはあなたに電話をかけたばかりなので、すぐにはそれを通知しません。私たちはこの動作を「ペーシング」と呼んでいます。これは、あなたがインシデントを解決しようとしているときに邪魔をしないためです。

ペーシングの間隔が切れたら、インシデント#2と、あなたがまだインシデント#1に割り当てられているという事実をお伝えします。あなたがその時も電話に出なかったとしましょう(シャワーを浴びていたのかもしれません)。

5分後、次の通知ルールが適用されます。しかし今回は、インシデント#1については今すぐに、インシデント#2については数秒後に通知する必要があることに気づきました。今回は、あなたに一度だけ電話をして、積極的に両方のことを伝えることにします。この動作を「バンドル化」と呼んでいます。

もしインシデントのどちらかが誰かに受任されたか、または解決された場合、私たちはそれらについてあなたに伝え続けることはありません。

まとめ:ハンドリングされていないインシデントについて連絡する間隔を管理するルールがあります。私たちは、合理的な範囲でできるだけ少ない通知を送るようにしながら、その都度発生しているすべてのことをお知らせするようにしています。

通知スケジューリングサービス

Notification Scheduling Service(別名NSS)を入力してください。この問題の美しいところは、それ自体が並列化に適しているということです。PagerDuty の各ユーザーへの通知は、お互いに全く相互作用しません。各ユーザーは島です。各ユーザーの小さな島の中にあっても、個々の連絡方法(例えば、「緊急度の高いインシデントの場合は+1-555-555-0123に電話してください」と「緊急度の低いインシデントの場合はMarvinDroidにプッシュ通知してください」)は、「このインシデントに割り当てられたユーザー」を各ユーザーのルールに従った連絡方法にマッピングする場合を除いて、他のユーザーとは相互作用しません。

私たちは各ユーザーをErlangプロセスとしてモデル化し、関連するUserChannelsを管理しています(これもErlangプロセスとしてモデル化されています)。これにより、新しい情報を素早く取り込むことができます(各インシデントの時間ルールごとに未来の日付の通知トリガーをキューに積みます)が、各UserChannelは自分のペースで状態を進化させることができます。インシデント#1についてユーザーAに伝える必要があることを知ると、ユーザーAのユーザープロセスにメッセージを送信します。そのユーザープロセスはユーザーの通知ルールを参照し、関連するすべてのUserChannelに、このインシデントについていつユーザーに知らせるべきかを伝えるメッセージを送信します。

NotificationBundlesはNSSの第二段階でピックアップされ、あなたに送信する実際の通知内容を決定します。これには少し時間がかかりますが、これらのNotificationBundlesはすべて別々の連絡方法とユーザーに送信されるので、作業を並列化することができます。

PagerDutyは小さなシステムではありませんが、コンピュータ用語では、我々が扱うオープンインシデントの数は「ビッグデータ」ではありません。私たちは、この関連する状態のすべてをメモリに保存しているので、より速く行動できるようになっています。これは、状態のないArtemisのシステムとは正反対です。各ユーザーを Kafka パーティションに関連付け、与えられたパーティションを処理する NSS のインスタンスが最大でも1つ(通常は正確に1つ)あることを保証します。これにより、User と関連する UserChannels がシステム内でsingletonになるのは簡単です。粒度の粗いパーティションロックを使えば、プロセスが小さな作業をしようとするたびに同期をとる必要がなくなります。現在データを処理している部分を除いて、その特定のデータの変更を担当するシステムの部分はありません。ユーザーとUserChannelは、状態の変更とともにidempotency メタデータを維持し、クラッシュの回復や定期的なソフトウェアのデプロイを可能にします。

各ユーザーに独立したパーティションを与えるのは素晴らしいことですが、Kafka はパーティションの数に比較的制限があります(クラスタあたり約 50k)。その代わりに、Kafka駆動のアプリケーションでは通常のように、トラフィックをパーティションに分割します。異なるライフサイクルを持つ異なる種類のデータがあるため、「並列パーティション」を持つ複数のトピックを使用することになりました。これらのトピック間のメッセージは同期する必要はありませんが、特定のユーザーのすべてのトラフィックが同じパーティションセットに表示されるようにすることでメリットがあります。この例では、3 種類の受信メッセージがあります。

インシデントの割り当て、状態の更新 ユーザーの連絡方法と通知ルールの更新 下流システムからのフィードバック(例:「この電話は完了しました」など)

システム内のパーティションごとにパーティションオーナーを実行して、そのパーティションから3つのトピックを同時にconsumeする(例えばパーティション1のパーティションオーナーは、インシデント更新トピックのパーティション1、通知ルールトピックのパーティション1、制御メッセージのパーティション1のデータをconsumeして処理するように調整する)。

下の図では、ユーザーAとBのデータはすべてパーティション番号1のみで終了し、ユーザーCとDのデータはすべてパーティション番号2のみで終了します。

変更の成果

NSSが状態を維持することで、すべての実行中の作業を高速にアクセスできるメモリに保持することができます。ロックはパーティションレベルでのみ発生し、作業のピースごとに細かくロックするオーバーヘッドを回避します。独立した動作を管理するために軽量プロセスを使用することで、順序が重要なところでは一度に1つのことに集中し、順序が重要でないところではシステムが同時に多くのことを行うことができるようになります。この新しいインフラは、サイズは(計算とデータストレージの点で)10分の1、ラグタイムは半分、スループットは10倍です(追加の水平方向のスケーリングのための余地は十分にあります)。2019年1月以来、私たちは通知トラフィックの100%をそれを介して実行しています。

この記事は、私たちが何をしたのか、そしてElixirで何が可能なのかの表面をかいつまんだだけです。このような背景を踏まえて、第2弾をお届けしたいと思っています。

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

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

ブランドと評判を守るインシデント対応

顧客は、価値観 を共有していると 感じる企業に忠実です。予期せぬ出来事が企業を襲ったとき、結果として生じた激動がブランドを危険にさらします。航空会社の災難や、テクノロジーシステムを巻き込んだ性能に関するインシデントなど、これらの瞬間は、顧客にサービスする能力を低下させることで、顧客体験に影響を与えます。顧客にブランドへのアクセスを提供するデジタルチャネルが増えている状況で、今日の現実は、世界中がポリシーや行動を監視する中で企業は事業を展開しているということです。

このシフトの影響から、CEOのオフィスにブランドが置かれるようになり、インシデント対応の中で企業のコミュニケーションを重視させる一因になりました。しかし、このチャレンジは企業のコミュニケーションのように、テクノロジー、製品、セキュリティなどのインシデント対応の共通部分にフォーカスする傾向があります。しかし、実際に問題となるのは、全ての側面がインシデント・オペレーションに書記から統合されていた場合、予期しない事態が発生したら、それらがどうに連携して最も効果的な戦略になりうるかです。

最近のForbesの記事で私たちは、危機の最中、特にインシデントのニュアンスが見落とされたときに、組織がブランドを保護するために使える3つのコミュニケーションのヒントを紹介しました。このような状況でストーリーラインをコントロールすることは、企業のコミュニケーションの責任です。彼らの役割は、オペレーションと顧客との関わり方を変えられるコミュニケーション計画を準備し実行することです。企業のコミュニケーションがインシデント対応業務に合わせて準備されている場合、次の点に対応できるメリットがあります。

出血を遅らせる

重大インシデントでは、技術とセキュリティの関係者だけが含まれる古典的な対応チームが組織されることがよくあります。 専門家が問題を特定して解決する間に、企業のコミュニケーションチームは待機させられ、対応作業に遅れをとります。 その一方で、デジタルチャネルを横断して世論が醸成され、形成されています。 レポーターは複数のストーリーを公開し、コミュニティ、ユーザー、パートナーはソーシャルチャネルを通じて意見を共有しています。インシデントの進展に合わせて企業のコミュニケーションチームを早期に巻き込むことで、危機に瀕しているブランドの出血を遅らせる機会が得られます。

ブランドの再構築

ポストモーティム(事後検証)のフェーズでは、重大インシデントに巻き込まれたビジネス全体の関係者が集まり、何が起こったのか、どのように対応業務が実行されたのか、何が改善できるのかを議論します。事態が終息すると、企業のコミュニケーションチームは、顧客やコミュニティの信頼を回復するために組織の舞台裏で働きます。彼らは企業側のメッセージを次にどこへ届けるかを決定し、PRの機会として何をすべきか、あるいは何をしないべきかを決定するために良い判断を下します。危機後に各ブランドは顧客の評判を素早く回復するためにどれだけのケアと行動を取ったかを顧客に迅速に伝えます。時には、整合性が取れない行動に直面したり、次の関連イベントが発生したりして、バックファイアを食らうことがあります。

デジタル時代には、企業の運営方法やコミュニケーションの役割に対する期待が急速に高まっています。新しい技術が登場し、デジタルチャネルが増加する現在、重大インシデントへ対応するための運用の初期段階でコミュニケーションを統合しておくことが、お客様のブランドが世間から否定されず称賛されるという差を生み出します。

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

PagerDutyがお届けする今年夏の新機能

2018年はPagerDutyにとって極めて重要な一年でした。 過去6ヶ月間にわたり、私たちは多くのPagerDutyの新機能の開発を加速し、デジタルオペレーション管理プラットフォームとモバイルアプリケーションのさまざまなアップデートと拡張をリリースしました。

これらの機能により、各組織は、レスポンス体制の編成と継続的な開発と配信をさらに最適化できます。開発者、運用チーム、DevOpsの実践者、および管理者が、コンテキストの洞察とインタラクティブなアプリケーションを通じて、カスタマーエクスペリエンスのあらゆる側面を視覚化できるようになります。

(訳注:下記の新機能の機能名は英文が正式名称です。和文の名称はDigitalStackが仮に訳したもので、正式ではありません。)

新機能のリリース

イベントインテリジェンスのリリース

最新の製品であるイベントインテリジェンス(Event Intelligence)は、デジタルシグナルと人間の対応行動の両方を組み込み、機械と人間のテレメトリーを組み合わせて、デジタルオペレーションを最適化します。自動適応学習アルゴリズムは、ノイズを削減し、チームがイノベーションと生産性向上に容易に集中できるようにします。 統合されたイベントインテリジェンスとインシデント対応により、誰もが同じ情報に接し、問題をより迅速に解決するために必要なコンテキストが確保されます。 ルーティングとワークフローの自動化、インテリジェントなアラート相関分析、ノイズ抑制、類似インシデントの憑依、API、およびプログラマビリティが連携して、レスポンダーが必要とする正確なマシンと人間のコンテキスト情報を提供します。

イベントルール(Event Rules) 、PagerDutyのルーティングとワークフローの自動化機能は、200以上のツールから大量のイベントデータをプログラムで管理するのに役立ちます。 イベントデータ、問題の重大度、サポート時間などに基づいて、ルーティング、抑制、通知、およびその他の動作をインテリジェントに自動化できます。

インテリジェントアラートグルーピング(Intelligent Alert Grouping)により、重要なコンテキストを集中しながらノイズを削減し、適応的機械学習とルールベースのアプローチによって、複雑なシステムにわたる関連する着信アラートを自動的にグループ化して1つのインシデントすることで、トリアージをスピードアップします。

類似インシデント(Similar Incidents)は 、トリアージを改善するのに役立つように、インシデント内に過去の関連のある問題を自動的に埋め込んで表示します。過去に類似の問題を処理していたエキスパートや過去のその問題の発生頻度を把握したり、過去のインシデントから得たより迅速に問題を解決するのに役立つ修復手順を含めて、状況に応じた洞察を得ることができます。

継続的な強化

今年の年初に、モダンインシデントレスポンス(Modern Incident Response)機能をリリースしました。私たちは、顧客からのフィードバックを取り入れながら、この製品を引き続き改良し続けています。

モダンインシデントレスポンス(Modern Incident Response)機能 の更新

既にPagerDutyのレスポンスプレイ機能を使用し、複数のチームのレスポンスをモバイル化し、ワンクリックでインシデントに関するアップデートを送れるようステークホルダーを登録している方もいらっしゃると思います。今夏からはさらに レスポンスブリッジ(Response Bridge)をレスポンスプレイにつなぎ合わせて、レスポンダーがシームレスにコラボレーションできるようになりました。この機能によって問題の最下部までレスポンダーが下りていけるようになり、ビジネスの重要なサービスをすばやく元に戻せるようになります。

ライブコールルーティングの機能拡張(Live Call Routing enhancements)。 電話番号をダイヤルしてオンコール通話相手にすぐにアクセスできるほか、重要なアプリやサービスに関連付けられたオンコールスケジュールとエスカレーションポリシーでオンコールをルーティングすることができます。

あるコールが次のレスポンダーにエスカレートする前に鳴動時間をカスタマイズする

自動受付の文言をカスタマイズする

コール内容を文章に転記する

この柔軟性は、さまざまなチームの対応プロセスに対応し、チーム全体および組織全体の学習を促進します。

レスポンスのモバイル化中の全エスカレーションのインシデントタイムライン項目化。 インシデントレスポンスに携わっているのが誰かを知ることは、インシデントレスポンスを加速するうえで重要であり、適切な人材を重要な問題の解決に専念させ、他者が開発に戻れるようにします。 PagerDutyのインシデントのタイムラインは、レスポンスプレイ、カスタムインシデントアクション、チャットの会話など、豊富なインシデント関連アクティビティをキャプチャします。 現在では、レスポンスのモバイル化中に発生するすべてのエスカレーション関連アクティビティもインシデントのタイムラインに記載されており、定期的な問題や新たな問題に直面した場合に貴チームが信頼する貴重な事後検証(ポストモーティム)にその内容を簡単に含めることができます。

クリティカルインシデント関連の活動をどのようにあなたの事後検証に含めることができるかについて詳しくはここでご覧ください。

インテグレーションとAPI

PagerDuty開発プラットフォームは柔軟なAPIと拡張性ツールを提供しており、どんなチームもPagerDutyと簡単に統合して拡張することができます。 私たちはすでに280以上のビルトインのインテグレーションとエクステンションをカバーしており、さらに追加しています!

最新の PagerDuty とServiceNowの公認インテグレーションは、ITチームが重要なサービス管理およびセキュリティインシデントの問題にリアルタイムで対処するのに役立ちます。 チームは脅威を緩和し、根本原因の特定とサービス修復を加速する力を得られます。 この統合により、チームは解決までの平均時間を短縮し、デジタルでの障害がビジネスへ及ぼす影響を軽減できます。

サービス群とチームの同期

ServiceNowプラットフォーム全体にわたるリアルタイム応答

自動化されたエンタープライズワイドなモバイル化

セキュリティインシデントレスポンスの迅速化

PagerDuty + Microsoft AzureとVisual Studio Team Services(VSTS)は、もうひとつの新しいインテグレーションです。ソフトウェア開発のライフサイクル全体を通して、チームに運用上の健全性の洞察とイベントインテリジェンスを提供することに私たちも大きく期待しています。各チームは、PagerDutyとMicrosoftを使用して、アプリケーションのコーディング、所有、および管理を効率的に行うことができるため、顧客に影響を与える問題を先取りしてより高品質なアプリケーションやサービスを迅速に提供できます。 その他の利点は次のとおりです。

PagerDutyインシデントとMicrosoft Azure Metric AlertsとMicrosoft Visual Studio Team Services Work Itemsとの自動同期

新しいMicrosoft Azure Metric Alertsフォーマットのサポート

インシデントレスポンスとサービス提供の迅速化

改善されたコンテキストによる開発サイクル時間の短縮

各サービスとAzureインフラストラクチャ全体の可視性の向上

V2 webhooks。 インシデントベースのWebフックを使用すると、インシデントが発生したときに外のWebhook URLにWebhookメッセージを送信できます。 Webhook受信者は、ID、イベント、作成日時、インシデント、ウェブフック、およびログエントリなどの複数のメッセージ要素を含む、メッセージ配列のペイロードを受信できます。

あるアカウントに拡張機能を追加するためのAPI 。 APIを介してサービスに拡張機能(webhookなど)を追加できます。

モバイル

アップデート: iOSのUniversal Linksのサポート (訳注:Universal LinksはiOS 9以降で導入されています)。レスポンダーが時間を節約できれば収益とカスタマーエクスペリエンスにポジティブなインパクトを与えられるため、調和のとれたモバイルエクスペリエンスが、レスポンダーにとってとても重要です。そのため、私たちはiOSのUniversal Linksのサポートを実装しました。 iOS Safari、Mail、Messagesからタップされた、インシデント、エスカレーションポリシー、ユーザーへのリンクは、PagerDuty Appでシームレスに開けます。

モバイルアプリについて多くのご意見をいただきました。人々はどこにいてもモバイルデバイスからアクセスできて、エスカレートできるようにすることが大好きなので、次の機能を追加することでアプリをさらに便利にすることに決めました。

iOS 1Passwordインテグレーション 。

インシデントの中の詳細、メモ、電話番号とURLをクリック可能に。

インシデント優先度(Incident Priority)のサポート (詳細、インシデントリスト、ソートなどを含みます)。

インシデントタイムラインのレスポンダリクエストとメモのiOSの電話番号とURLをタップ可能に。

PagerDutyモバイルアプリでのライブアップデート対応。この詳細については、 エンジニアリングのブログをご覧ください。

これらは2018年のこれまでに用意した全アップデートです! しかし、今年はまだ終わっていませんし、後半に発表する予定も増えています。製品や機能の最新かつ最大限の情報を知るためにチューニングはそのままにブログをチェックしてください。

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

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

アジャイルとスクラムに関する問題

「アジャイル」はソフトウェア開発でよく使われるバズワードで、一部の組織やチームはアジャイルを装っていますが、実際には全く違うことをしています。私はアジャイルコーチとしてのキャリアの中でそれを何度も見てきました。あるリーダーは、アジャイルの価値観を受け入れていると主張していましたが、エンジニアリングチームを細かくマネジメントし、開発者を操って長時間労働させるための方法としてアジャイルを利用していました。その結果、私たちの業界のエンジニアの中には、アジャイルソフトウェア開発を嫌っている人がいます。それは、エンジニアリング以外の人が彼らを操り、ソフトウェア開発をゲーム化するためにアジャイルソフトウェア開発を利用していると感じているからです。

この記事では、エンジニアがアジャイルやスクラムで経験する3つの「問題点」をお話しします。そして、悪質なアクターや誤解が蔓延している「アジャイルのBS」を切り取って、なぜこれらが全く問題ではないのか、その理由をお話しします。

始める前に、「アジャイルBS」を定義しましょう。

アジャイルBS:アジャイルの原則と価値観に沿っていないチーム、プロジェクト、または組織を指すときに「アジャイル」という用語を使うこと。例えば、アジャイルを装ったウォーターフォールや、実際には機能不全のプロセスを「アジャイル」という言葉で呼ぶこと。

この定義を念頭に置くために、チームまたは組織がアジャイルでないことを示す「アジャイルBS」フラグの例をいくつか示します。

エンジニアリングチームのメンバーがソフトウェアのユーザーと話したり、観察したりしていない

ユーザーからエンジニアリングチームへの継続的なフィードバックが行われていない

実用最小限の製品をできるだけ早く出荷して早期のフィードバックを得るよりも、完全なプロジェクト要件を満たすことを優先する

「アジャイルBS」の詳細については、国防総省のアジャイルBS検出ガイドをご覧ください。アジャイルの原則と価値観は、人々がアジャイルについて時々表現する問題、特にこの記事で指摘されている問題を解決するために作成されたのです。

問題1:アジャイルは、マネージャーが悪意を持って使用するための多数のプロセスとツールを提供するが、エンジニアが前向きの影響力を発揮するためのものはほとんどない

マネージャーがデイリースタンドアップを使用してチームメンバーを細かく管理できるのは事実です。また、マネージャーはスクラムチームのスプリントへの取り組みを「保証」と混同し、エンジニアにスプリントの目標を達成するために長時間労働を強要することがあります(問題2を参照)。しかし、これらはアジャイルソフトウェア開発の問題ではなく、マネージメントの問題です。そして、アジャイルソフトウェア開発では悪いマネージメントを克服することはできません。これは、アジャイルの原則と価値観が達成しようとしていることに対して、間違った期待をかけていることになります。

それでは、組織が適切な管理を実施しているとしましょう。どうすればアジャイルを受け入れることができるでしょうか。組織は、あらゆるレベルでアジャイルの原則と価値観を実践する必要があります。これには、リーダーシップによるアジリティへの取り組みが必要であり、アジャイルコーチのサポートを受けながらアジャイル変革の取り組みを通じて達成できます。PagerDutyの場合は、組織の効率を継続的に改善し、チームの可能性を最大限に引き出すシステム、プロセス、文化を構築、拡張するための専用のアジャイルリーダーシップチームがあります。

この「問題」と密接に結びついているのが、アジャイルはプロセスやツールよりも個人や相互作用を大切にしているということです。それは実際には何を意味するのでしょうか。

プロセスよりも人を大切にする。ソフトウェア開発を管理するのは人であってプロセスやツールではない

プロセスとツールに対する万能型のアプローチを求めるのは、ソフトウェア開発にはうまく機能しない

多様性を許さないプロセスや相互作用を妨げるツールに注意する。ガイダンスとガバナンスを考える

プロセスとツールについて考えるとき、アジャイルではないことを示す「アジャイルBS」フラグは次の通りです。

Doneの定義のようなプロセスの考慮事項が、エンジニアリングチームのトップダウンで定義されている

チームがプロセスソリューションを所有していない(例:スクラム対カンバンの選択)

マネージャーは、エンジニアを細かく管理する方法として、デイリースタンドアップとスプリントゴールを使用している

問題2:アジャイルは意図的に「見積もり」と「コミットメント」を混同し、エンジニアを操って時間外労働をさせる

この問題を2つに分けて考えてみます。

アジャイルは意図的に「見積もり」と「コミットメント」を混同している

チームの取り組みについて話し合う場合、言語は特に重要です。「スプリントへの取り組み」というスクラムの概念を説明するために、スクラムアライアンスとアジャイルアライアンスの共同創設者であるマイク・コーン氏からのアドバイスを紹介します。

「チームのコミットメントが保証と見なされないことが重要です。チームのコミットメントは最善を尽くすことです。私はコミットメントに、おおむね80%の時間を費やしてほしいと思っています。それは彼らが真剣に取り組み、時間の大半を占めるものでなければなりません。これは、チームが提供できるという内容をビジネス側が信頼するために必要なことなのです」。

ここで重要なのは、チームのコミットメントが保証と見なされないことです。チームは最善を尽くし、各イテレーションの終わりに達成したものと目標を比較し、それに応じてプロセスを適応させます。

エンジニアを操って長時間労働をさせる

時間外労働はアジャイルであることとは関係がなく、企業文化と関係があります。とはいえ、アジャイルマニフェストの原則は、アジャイルプロセスは持続可能な開発を促進するということです。これは、エンジニアが時間外労働を一切しなくてもいいということでしょうか? もちろんそんなことはありません。

エンジニアリングリーダーは、チームとともに適切な労働時間を設定することが重要です。たとえば、エンジニアリングマネージャーは期待を次のように伝えます。

私は誰もが週に40〜50時間働くことを期待します。これは通常、1日8時間の稼働で、月に1週間はオンコールであるということです。年に2回、私はチームに時間外労働をお願いするかもしれません。ただし、どうしても必要な場合を除いて、これをすることはありません。

マネージャーはチームに定期的に時間外労働を要求しているわけではありません。しかし、彼らはこれが毎年数回起こる可能性があるということを理解します。

持続可能な開発に関連して、チームや組織がアジャイルではないことを示す「アジャイルBS」のフラグは以下の通りです。

エンジニアリングチームがスプリントに取り組む場合、これは保証と同義である

スクラムチームは常にスプリントのコミットメントを守る

エンジニアリングチームは、スプリントのコミットメントを守るために、定期的に時間外労働をする

問題3:「コミットメント」というスクラムの概念は、2週間ごとに特定の量の完成した作業を実行することを意味する。これは、ソフトウェア開発について長期的な意思決定を望むエンジニアにとっては過度に敵対的である

スクラムチームが次のスプリントの計画を開始すると、彼らは顧客にとって最高の優先度を持つと決定された項目を引き出します。チームの長期的な決定は、チームの製品ロードマップで事前に計画されています。しかし、製品のロードマップは双方向です。プロダクトオーナーは、チームが解決すべき次に重要な問題を定義します。エンジニアがロードマップにフィードバックを提供し、チームが取り組むべきより価値のあるものがあると感じた場合は、それをプッシュバックするかどうかはチームのエンジニアにかかっています。

エンジニアが製品ロードマップにフィードバック(またはプッシュバック)するのはなぜでしょうか。

オンコールローテーションを行っているチームの場合、最近オンコールが特に騒がしくて苦痛を伴う場合、次のスプリントで最も価値のある作業は、インフラの改善を優先することです

チームが大量の技術的負債を蓄積している場合、問題が大きくなる前に、ロードマップを調整してそれに焦点を合わせる必要がある場合があります

チームがユーザーや利害関係者からフィードバックを受け取り、それによって提供している価値を向上させることができた場合、ロードマップを適応させてこのフィードバックに優先的に対応することが、最も価値のある仕事になるかもしれません

長期的な決定について考えるとき、チームまたは組織がアジャイルではないことを示す「アジャイルBS」のフラグをは次の通りです。

エンジニアリングチームには、プロダクトオーナーから解決すべき問題ではなく解決策が与えられる

エンジニアリングチームが製品ロードマップにフィードバックを提供する仕組みがない

成功とはなにか

組織が真のアジリティを受け入れれば、

エンジニアは、メトリクス(製品エンゲージメント、収益への影響、予測可能性など)、チームヘルスチェック、チームの回顧などのメカニズムを使用して、組織に前向きの影響を与えることができます。

形式の整ったスクラムとカンバンチームは、持続可能なペースで作業しながら、予測可能な価値を顧客に提供するとの信頼を得ます

エンジニアはフィードバックを提供し、製品ロードマップを調整して、常に最も価値のあるものに取り組むことができます。さらに、HackWeekを定期的に開催することで、組織にとって最も重要だと思うことに取り組むことができるようになります

学びを共有する

組織やチームが「アジャイル」を装っているのに、実際には全く違うことをしていることに気がついたことはありますか? PagerDutyコミュニティでは皆様からのご意見をお待ちしています。

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

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

クラウドへの旅、インシデント管理の改善

多くのIT組織は、クラウドインフラストラクチャ の活用はやむを得ずやることではなく、IT組織がビジネスニーズに即応するための最も効果的な方法だと悟りました。

しかし、クラウドには、ダウンタイムの最小化、運用コストの削減、社員の燃え尽き症候群防止など、新たな課題があります。企業がプロセスと手順を新しい現実であるクラウドベースのインフラストラクチャに移行するのに合わせて、これらの課題を解決するためにインシデント管理ソリューションを採用する必要があります。これはハイブリッド環境で運用する大企業の場合、つまり従来型のインフラストラクチャとクラウドベースのインフラストラクチャを混在させて、インシデント管理にもハイブリッドなアプローチが必要な場合に特に当てはまります。クラウドに移行するには時間がかかりますが、それは1回で済むものではありません。

組織がこの新しいパラダイムを受け入れてクラウドに移行する理由と、シームレスなクラウド移行のためにインシデント管理をどのように処理しているのかを見てみましょう。

なぜクラウドに移行するのか

組織がクラウドに移行するには多くの経路があります。クラウドネイティブアプリを担当する開発チームを、プライベートクラウドとパブリッククラウドの様々な組み合わせを担当するインフラストラクチャチームへと移行させ、2つのクラウドを相互接続するためのハイブリッドインフラストラクチャを構築する方法など、クラウドに移行するメリットのいくつかを見てみましょう。

インフラストラクチャ管理の削減**:クラウドサービスを活用することで、従業員は、下位レイヤーのコンポーネントをパッチして維持する必要がなくなり、ビジネス価値を提供することに集中することができます。 アジリティ(俊敏性)の向上**:クラウドインフラストラクチャ上でサービスを更新、追加、削除する機能は、企業が新しい機会に対応するスピードを大幅に加速します。 クラウドネイティブアプリ**:アジャイル開発のプラクティスと継続的インテグレーション、継続的デリバリー、マイクロサービスを組み合わせることで、チームはビジネス機能をスピードとスケールをもって提供することができます。 ディザスタリカバリとビジネス継続性**:クラウドインフラストラクチャのビルトインデータレプリケーション機能を活用することで、迅速なリカバリを目的としたセカンダリサイトの構築が可能になります。時間が経つと、これは複数のゾーンや地域に配置した冗長システムに変わります。 常時稼働**:クラウドサービスは、一般的に24時間365日稼働しており、サービスへの移行以外の余分な労力や人員を必要としません。 設備投資の無償**:クラウドサービスはサブスクリプションベースで機能するため、大きな設備投資が不要で、償却費や減価償却費を払う必要はなく、コストを運用予算に移行できます。クラウドサービスプロバイダは、資本投資を必要とする物理的環境を維持します。 市場投入までの時間短縮**:購買手続きが全くなくてもチームは新しいアイデアのテストを数日間で開始することができます。数週間または数カ月のリードタイムを必要とする従来のモデルとは異なる点です。

クラウドへの移行は、企業がより機敏に対応できる利点があるため、規模を問わず多くの組織にとって合理的です。クラウドへの移行は、やるかやらないかではなく、いつやるかという問題になっているのです。結果として、ITチームはこの新しいパラダイム内でアプリケーションを構築、運用、サポートする方法を学ばなければなりません。

クラウド環境でリアルタイムの可視性を得る

クラウドへの移行の前後にインシデント管理プロセスを導入していないと、問題が発生したときに盲点になり、インシデント対応が遅れることがあります。これらの問題は、ビジネスへのリスク、顧客への影響、および移行プロセスの遅延につながる可能性があります。また、ハイブリッドインフラストラクチャを使用したり、パブリッククラウドインフラストラクチャに完全に移行したりする場合に、これらの弱点を未解決のままにしておくと、実際のインシデント対応に支障をきたすようになります。効果的なインシデント対応でハイブリッドクラウド環境を管理することは非常に重要です。そうすればクラウドベースのアプリケーションで動作しているものをリアルタイムに把握し、移行中または移行後に問題が発生した場合に対処できます。

クラウド移行中のインシデント管理の課題

前述したように、クラウドに移行する際には、次のような新たな課題を克服する必要があります。

クラウドインフラストラクチャプロバイダとの統合と監視

クラウドネイティブアプリケーションを組織のアプリケーションポートフォリオに導入することで、複数のクラウドプロバイダー間でインスタンスを動的に追加または削除する場合でも、すべてのインスタンスを表示、レポートできることが不可欠です。現代のクラウドベースのツールからシグナルを引き出すことが重要ですが、従来のツールからシグナルを引き出せることも同様に重要です。組織がハイブリッド環境に存在する可能性が高いからです。すべてのアプリケーションが同時に移行されるわけではないため、これは移行中に大きなリスクになりますが、既存のサービスやアプリケーションを提供するには、オンプレミスとクラウドの両方のコンポーネントが必要です。

解決策:最新と従来のアプリケーションパフォーマンス管理スイートと、すべてのクラウドインフラストラクチャで使用可能なネイティブツールを理解し、統合できるインシデント管理プラットフォームを用意します。

常時オンは常時サポートが必要だという意味です

顧客は常時オンの経験に慣れてくると、自社のサービスは24時間いつでも利用できると期待しますから、問題を報告するために月曜日の朝まで待たずに声を掛けることを躊躇しません。

解決策:24時間365日のサポートを処理するために構築されたインシデント管理プラットフォームに投資し、監視ソリューションが事前に障害を検出したとき、またはクライアントがインシデントを報告したときに、どのチームに通知するかを知ることができます。その後、インシデント対応のライフサイクルを通してそのチームをサポートします。

クラウドの可視性

クラウドベースのプロバイダーから提供されるサービスが増えましたが、アプリケーション、ミドルウェア、インフラストラクチャからのイベントやアラートに必要な可視性を、顧客が影響を受けたり、あなたのプロジェクトが遅れる前に実現できるようにするにはどうしたらよいでしょうか。

解決策:複数の情報源からの情報を受け取れるソリューションに投資し、問題の影響を調査するチームの能力をサポートします。対応者が適切な情報を持って行動し、ビジネスチームやプロジェクトチームのリスクを最小限に抑えることが重要です。これにより、クラウドの移行ライフサイクルが迅速に回り、高品質なアプリケーションの変更が本番環境に導入されるようになります。

分散した労働力

クラウドにはモバイルフレンドリーなプラットフォームがあり、地理的に分散した複数のオフィスを持つ組織がますます増えていますから、単一の統一されたコミュニケーションチャネルを持つことが重要です。

解決策:従来の電話会議を使っているのか、それともSlackやHipChatなどの最新のコラボレーションソリューションを使っているのかどうかは関係ありません。目標は、あなたが話す必要がある人々を見つけられる場所を1つにすることです。SlackやHipChatのようなツールの利点は、会話を離れずにチャットに情報とアクションを持ち込めるようにインシデント管理と監視ソリューションにフックできる点です。

クラウドの移行の一環として、開発チームやビジネスユニットのニーズに合わせて、同じティアでチームをサポートする必要性を検討することが重要です。サポートチームが、開発者が展開しているものの背後にあって必要なすべてのプロセスとツールを持っていない場合、追加されたすべての複雑なレイヤは、信頼性の高い方法で使えないため、ビジネスにとっては無駄になります。

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

オーバーライド:PAGERDUTYの最も人間的な機能を紹介

オーバー…何?

あなたがオンコールをしたことがあるなら、あなたが風邪をひいていてもインシデントは止まらないことをご存知ですね。 あなたのお子さんの高校の卒業式に出席しているときとか、私が直接気づいたように、自分の結婚式に参加しているときでさえ、待ってくれません。孔子曰く、「オンコール中に決して大きな出来事が起こったことがないなら、あなたは今まで生きてきたとは言えない」と(まあ、これ完全に私の創作ですが。)

冗談はさて置き、人生があります。 スケジュールのオーバーライド(Schedule Override) 、または単に「オーバーライド」と呼ぶ機能を使えば、PagerDutyスケジュールの設定で、オンコールのシフトの一部または全部を他の人に引き継ぐように依頼することができます。 予定の休暇、予定外の病気、またはその他の生活上のイベントが発生した場合にオンコールの順番やスケジュール全体を変更せずにオンコール担当者(レスポンダー)を変更できるため、便利です。

素晴らしくないですか? 私が最初に気づいたように、自分の犬の誕生パーティーにラップトップを持って行ったりする代わりに、あなたのチームメイトに、月2回の獣医の健診の最後を祝う数時間の間だけオンコールを代わってくれないかと依頼できるわけです。

デベロッパー – 誰?

私たちの多くの顧客はDevOpsの文化をすでに持っていたり、DevOpsの体制に移行中です。 DevOpsの文化では 、エンジニアはコードを作成し、出荷し、オーナーシップを持つことが奨励されています。つまり、チームのコードに不具合があることが分かれば、そのコードを修正する責任があります。 この文化は、より良いコードの作成、より良いテストの作成、より安定した展開、そして事前のロールバック計画を立てることなど、数多くのことをチームに促します。 真夜中に起きるインシデントのためにチームが起きなければならない場合、コードに関係する可能性は低いでしょう。 エンジニアは今やレスポンダーでもあるので、私たちは古典的な「壁を越える」ジレンマを排除します。

私たちは、各エンジニア/レスポンダーが自分のコードに加えて、自分のオンコールライフを管理できるようにするためにPagerDutyを構築しました。 PagerDutyでは、各ユーザー自身が、自分が何のサービスに責任を持つか、オンコールローテーションをどうするかを、オーバーライドをスケジュールするタイミングを含めて、決めます。

HealthOps-どちらが優先?

オーバーライド機能は、PagerDutyで最も人間的な機能です。 以前のOperations Healthに関するブログの投稿から学んだように、オンコールの負担の大部分を課せられた従業員は燃え尽きて(バーンアウトして)しまいます。バーンアウトした従業員は、仕事でもうまくやれず間違いを犯す可能性があり、最終的には会社にとっての時間とリソースを費やします。 それだけではありませんが、激しい疲労や仕事に関連したコールによって自分の人生が絶え間なく中断されることに嫌気がさして退職する可能性もあります。つまり、 1人あたり最大300,000ドルのコストをかけて育成した熟練したレスポンダーを失ってしまいます。

私たちは、サーバーの健全性、アプリケーションの安定性、Webページの応答性を測定するためのツールがたくさんある業界で働いています。 不健全なサーバー、不安定なアプリケーション、そして応答の遅いWebページを通知するのに役立つこれらのツールのほかにも、別のツールがあるのです! バグを修正するため昼夜を問わず働いたり、展開時の問題を解決するため3年生の初のシアターデビューを逃したりしているレスポンダーの健康を犠牲にして、お客様の幸せとビジネスの生産性を維持しているのです。 私たちはデジタルシステムが稼働していることを保証する一方で、週末や夕方、時には睡眠時間を削って仕事をしているこうしたリアルな人々の健康のことを考えないようにしているのです。

ここにオーバーライドが役に立ちます。 今年は、 PagerDuty Universityの Summitでのイベントの際に、私はオーバーライドをスケジューリングすることに独自のアイデアを持っていたある紳士と話をしました。彼、Vacasa(訳注:バケーションレンタルサイト)の Dan Wade氏によると、彼のチームは週7日24時間のローテーションを組んでおり、各レスポンダは一回に7日間オンコールしています。 彼は、チームメイトの1人のオンコールローテーションが特に激しかったことに気付きました。オンコール中に重大度1のインシデントがいくつか起きていたのです。そしてそれらの重大度1のインシデントは、解決されるまでに数日かかりました。 彼女が数日間眠らなかったことを知って、残りの彼女のコール・シフトを彼が引き継いだので、彼女は必要な休息を十分に取ることができました。 このような状況で、Danが彼女の状況に共感を見せたために、Danのチームメートはよりハッピーで生産的な従業員になりました。

Danは彼のチームのヒーローであるだけではなく、私たちが学ぶべきロールモデルでした。 現代の技術者として、オンコールすることは、Opsの男女とは隔離されてはいませんが、デジタルシグナルを扱っている人にとっても同じです。 デジタルシグナルは、時刻、特別な機会、生活イベント、または疲労と無差別に起きます。 それはチームの一人であるあなたに降りかかり、あなたが使えるリソースの一部、例えば時間、エネルギー、あるいは愛といったものをシェアするよう迫ります。

覚えておいてください:次回オンコールするときに、「Boulevard of Broken Dreams」や「Wake Me Up When September Ends」(注)になりたいですか?

注:Boulevard of Broken DreamsとWake Me Up When September EndsはアメリカのロックバンドGreen Dayが発表した曲。2004年の「american idiot」に収録。

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

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

積極的なインシデント対応で障害を未然に防ぐ

もし各種業務とその依存関係を俯瞰的に把握し、インシデントや障害が起こりそうな指標を見極める能力を持っていたら、あなたの日常生活にどのような影響を与えるでしょうか。想定外の事態に対応するのではなく、混乱に先手を打つために数分、数時間の猶予が与えられたら、ビジネスにとってどのような意味があるのでしょうか。企業にとって、プロアクティブ(積極的)なインシデント対応を可能にすることは、費用の節約、ブランドの評判の保護、対応チームの燃え尽きを減らすことに直結します。

プロアクティブであるということは、技術スタッフとビジネススタッフの両方に、デジタルサービスの方向性を示すのに必要なツールを提供することを意味し、問題が発生した場合に、無知の状態からスタートしないようにします。一刻を争うデジタルの世界では、オンコール対応者は、インフラや対応手順をその場で学ぶことはできません。だからこそ、デジタル対応の心構え、準備が非常に重要なのです。

そして、それは遠い夢のように思われていたかもしれませんが、プロアクティブなインシデント管理はもはや単なるおとぎ話ではありません。2020年春発表のPagerDutyの最新の機能強化では、すべてのチームにまたがるデジタルサービス、依存関係、ハイパーケアを提供し、問題が収益に影響を与える前に対処するのに必要な運用上の指標を得ることができます。PagerDutyがどのようにそれを可能にするか見てみましょう。

イノベーションを掘り下げる

ダイナミックサービスディレクトリ内のサービスプロファイル

昨年秋、当社はすべてのサービスを1カ所で追跡して管理する方法として、Dynamic Service Directoryを導入しました。このディレクトリを構築したのは、IT技術スタックの複雑さと変化の速さが増しているため、従来の作業方法、つまりコンポーネントを追跡するための集中化された手動のアプローチでは、クラウドネイティブの世界では拡張性がないからです。

別のチームによる発見とマッピングを含む、時間のかかる手動のアプローチの代わりに、PagerDutyのDynamic Service Directoryは、プラットフォームの定期的な使用を通じて収集されたサービス情報を提示します。ディレクトリは自動化を可能にする豊富なAPIを持っているだけでなく、中央集権ではなくチームベースでもあります。

回答者が利用できる情報量を増やすために、Service Profileと呼ばれるDynamic Service Directoryの新しい機能強化をリリースしました。Service Profileは、各サービスの周りに情報アーキテクチャを作成することで、サービスに意味とコンテキストをもたらします。これにより、エンジニアリングマネージャーとオンコール対応者は、チームの所有権、オンコール対応者、過去のアラートやインシデント、依存するサービス、ランブック、優先する通信チャネルなどの各サービスの情報を確認することができます。

サービス依存関係

組織の規模が大きくなるにつれて、複雑で横断的な大規模インシデントを解明したり、インフラがどのように接続されているかを理解することが難しくなり、潜在的な脆弱性につながる可能性があります。また、チームが最善の努力をしても、手動で管理されたWikiや静的なCMDB(構成管理データベース)では、依存関係の状態についての視点が限られています(時代遅れとまではいかないまでも)。

だからこそ、PagerDuty に Service Dependencies(サービスの依存関係)を導入しました。Service Dependencies は、問題の特定、トリアージ、修正を迅速に行うために、サービス間の関係を理解することを可能にします。ユーザーは直感的なユーザーインターフェイスを介して複数のサービスと依存関係のレベルをナビゲートし、誰がいつサービスを変更したかなどの重要な情報を公開することができます。Service Dependencies は対処の自動化を推進し、脆弱性に関する貴重な洞察を平時に提供し、組織が独自のインフラについて持っているメンタルモデルと一致させることができます。

サービスダッシュボード

従来型のIT組織では、エンジニアリングチームがインシデントがサービスにどのような影響を与えるかを認識していなかったり、不確かであったりすることは珍しくありません。このような理解がなければ、ビジネス関係者の期待に先手を打ったり、チームを改善に集中させることができません。

エンジニアリングチームがこの問題を克服するために、新たに提供されたサービスダッシュボードでは、運用上のメトリクスと KPI を可視化して、部門間の連携とビジネス成果の向上を実現します。この一元化された表示により、サービスの構築者と運用者は、製品の可用性、リソース配分をより効果的に管理し、チームとサービスの継続的な改善を推進するために協力し合うことができます。

新しいビジビリティコンソール

現在、多くのお客様がワークフローを物理的な目に見えるネットワークオペレーションセンター(NOC)から仮想環境に移行し、NOCオペレーターが自宅で作業する必要性を感じています。しかし、これらのオペレーターは、サービスパフォーマンスの統合されたビューをまだ必要としています。

PagerDutyのVisibility Consoleは、アーリーアクセスとしてユーザーにデジタルオペレーションのリアルタイムビューを提供します。改訂され適応されたエクスペリエンスには、高度なフィルタリングとカスタマイズ可能なレイアウトも含まれています。この強力なコンソールは、運用の準備を促進するだけでなく、ハイブリッド運用組織のNOCとアプリケーションチーム間のギャップを埋めるのにも役立ちます。最も重要なことは、このツールにより、チームはインシデント対応に積極的なアプローチを取ることができ、ハイパーケアの瞬間に顧客のニーズを満たすために必要なコンテキストを提供することができるようになります。

プロアクティブなインシデント対応を行うためには、インシデントが発生したときに対応できるように、チームが管理しているワークフロー、自動化、サービスに関する情報を持っている必要があります。現在の経済環境では、コスト削減、顧客との関係の維持、企業の回復力の確保という点で、このアプローチがもたらす影響を過小評価すべきではありません。

これらの新機能は、プロアクティブなインシデント対応を実現するために PagerDuty を使用する多くの方法のほんの一例です。もしあなたの企業にとってこれらのツールのどれかが有効だと思われたなら、無料トライアルを試してみるか、当社までご連絡ください。

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

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

オンコールエンジニアのための準備

オンコールエンジニア は インシデント 管理 で重要な役割を果たします。 彼らは、インシデントをクリティカルな状態から管理された状態に変える役割を果たし、迅速に解決します。

スタートアップには誰がコールを受けるべきかについてあまり多くの選択肢がないかもしれませんが、組織が成長し、インシデント管理がより複雑になり、関係者が増えるにつれて、構造化されたプロセスを用意しておくことがオンコールエンジニアにとって重要になります。スタートアップ企業であれ大企業であれ、オンコールエンジニアを成功させるための明確なプロセスを用意しておくことで大きな利益を得られます。 ここにいくつかのガイドラインを示します。

最初の対応が重要

インシデント発生の最初の数分間で、オンコールエンジニアはインシデントの重大度とサービスへの影響を把握する必要があります。それに基づいて、影響を受ける下流のサービスと、誰がそのインシデントを解決する必要があるのか​​、そしてその人たちを迅速に実戦に投入する方法を判断する必要があります。これには、何かが壊れたときに根本原因を特定し、作業の優先順位を決定できるように、システムがどのように機能しているかを実践的に知っておく必要があります。オンコールエンジニアのローテーションは自動的にスケジュールされます。こうすれば負荷が分散され、チームは公平性と説明責任のために最適化され、誰もがインシデントを処理でき、接触を失うことはありません。大規模なチームでは、最初の対応を開始できる専門のインシデント管理者がいることがあります。いずれの場合も、オンコールエンジニアの主な目標は、インシデントのトラブルシューティングや解決ができない場合でも、インシデントを解決するために必要なリソースを取り込むことです。

2次オンコールエンジニアを用意しておく

2次(そしておそらく3次も)のオンコールエンジニアをバックアップとして持つべきです。 そうして、第1レベルの対応者が寝過ごして午前3時の電話連絡に気づかなくても、何も谷間に落ちないようにします。これはまた、チーム内の役割のローテーションのスケジュールが必要だということです。1次担当のエンジニアからの応答がない場合、インシデント通知がバックアップエンジニアにエスカレートされるように、自動化されたルールを設定します。

オンコールエンジニアが必要なトレーニングを

受けていることを確認する

インシデント発生時には多くの問題が発生するため、オンコールのエンジニアはプロトコルを遵守し事態の推移に遅れず考えることができる必要があります。 彼または彼女は、さまざまな部門間のステークホルダー(顧客サポート、マーケティング、PRなど)が連絡を取り合う適切な方法も理解しておく必要もあります。そうすれば修復状況を外部に伝達できます。インシデントが発生した場合に従うべきチェックリストまたはフローチャートをオンコールエンジニアに渡しておくと便利です。

ダウンタイムの1分ごとに何千ドルもの損失が発生する可能性があるため、オンコールエンジニアができるだけ早くインシデント対応をする必要があります。そのための手順は次のとおりです。

インシデントの特定とログ作成

まず、インシデントを特定または検出してログを作成します。ロギングは、問題の根本的な原因を迅速に突き止めるのに役立ち、解決後のインシデントの包括的な事後検証の進め方を示してくれます。インシデントに迅速に対応することが重要なので、特定とロギングは迅速かつ体系的に行ってさっさと次のステップに進む必要があります。

カテゴリを分けて優先順位を付ける

チームが遭遇する可能性がある問題はその種類が膨大なため、混乱を避けるためにインシデントを分類することが重要です。影響を受けるユーザーの数、影響を受けるサービスに関する問題の「爆発の半径」、潜在的な収益への影響などに注意してください。インシデントの優先順位を設定することで、オンコールエンジニアは、インシデントが残りのチームの時間とリソースを必要としているかどうかを連絡することができます。可能であれば、チーム全体の時間を節約するために、あまり複雑ではないマイナーなインシデントにはエンジニアだけで対応できるようにしておくとよいでしょう。オンコールエンジニアが重要なことに集中できるようにするため、行動不可能なアラートは抑制する必要があります。

正しい人に通知する

PagerDutyのようなプラットフォームやそれに内蔵されたChatOpsやコラボレーションは、関係する人材を採用し、その人たちを適切なタイミングで適切な場所に集めるためのベストプラクティスです。特に、特定のChatOpsチャンネル/会議室、ビデオ通話と会議での共有、コンテキスト内の問題の修正機能を使うと、解決のスピードとビジネスの影響レベルに大きな違いが生じます。チームメンバーとコミュニケーションしている間は、自分と他の人の時間を節約するために、事件の説明を簡潔かつ理解しやすくすることも重要です。チームはアラートが多すぎて注意をそらすことがあるので、PagerDutyのようなソリューションでノイズを抑え、大事なシグナルを浮き立たせることが不可欠です。

トラブルシューティング

トラブルシューティングは、チーム全体に通知して提示する場合以外でも実行する必要があります。応答を待つ間も、オンコールエンジニアのような最初の対応者はトラブルシューティングを行うことが不可欠です。最初の数分が非常に重要な現実の救急サービスと同様に、迅速な対応が救命者になれます。

オンコールリソースの管理と装備は、開発チームや運用チームが成功するための重要な作業です。十分なバックアップと十分に検討されたプロセスと計画を立てておくことで、状況が悪化した場合でも効率を確保できます。オンコールのエンジニアが上記の基本的な手順に従えば、チームは作成とイノベーションに費やす時間を増やすことができ、修復時間を短縮できます。

2019年2月22日  (更新日:2022年3月9日)    |    ベストプラクティス

PagerDuty Postmortem(事後検証)ガイドのご紹介

「チームは重大インシデントと既に何時間も闘っており、あなたの調査は徐々に煮詰まっていきます。でもついにあなたは問題を特定することに成功し、グラフは改善し始めます。すべてのシステムが正常に戻ったとき、誰もがほっと息をついて、レスポンスコールを止め、そして再びこのインシデントについて考えることはありませんでした」。

…あるいはそう考えただけかもしれませんが。

先に進む前に、チームがやらなければならないことがもう1つあります。事後検証です。

なぜか?

事後検証は継続的に改善を進める文化を根付かせるのに役立つので、重要なのです。

事後検証なしでは、あなたとあなたのチームは自分たちがしていた正しい行いや、改善できる点、そして最も重要なこととして、何度も何度も何度も同じ間違いをしない方法を学ぶ機会を逃します。うまく設計された、責任を問わない事後検証は、あなたのチームがインフラとインシデントレスポンスのプロセスを改善するのを助けます。

ここで当社が効果的な事後検証(Postmortems)の実施方法に関する包括的なガイドを発表したことをお知らせしたいと思います。

このガイドのように、文化の変化のニュアンス、徹底した分析の実行方法の詳細、および失敗についての冷静で深い会話を促進するために必要な独自のスキルを網羅した資料は、他にありません。これらの概念がなぜ重要であるかを説明し、それらを実行することに関連する課題を説明し、そして責任を問わない事後検証を行うための実行可能な手順を提供します。

まだ事後検証をしたことがない人には、このガイドは、ご自分の組織に新しいプロセスを導入するのに必要とされる知識と戦略を提供します。事後検証の経験を持つ方には、自然任せでは陥りがちな非難の応酬に対処する方法、より深いインシデント分析のための新しい問い合わせの指針、事後検証の会議をより良く活用する方法、そして既存のプロセスを改善するための方法をたくさん学べるでしょう。

インシデントに対応している間は、チームは100%サービスの復旧に集中しています。 彼らは何かを最適な形で行う方法を考えたり、インシデントの原因を深く掘り下げることに時間と精神力を浪費することはできませんし、またそうすべきではありません。それが、事後検証の問題が不可欠である理由です。問題がユーザーに影響を及ぼさなくなったときに、事後検証の問題を反映するための平和的な機会を提供します。事後検証のプロセスでは、集中力を高め、学習の文化を浸透させ、そうでなければ失われる可能性のある改善の機会を特定します。

ちょっと待って、インシデントの事後検証って何ですか?

インシデントの事後検証(Incident postmortem)は色々な別名を付けて紹介されています。次のどれかならご存知かもしれません。

ラーニングレビュー

アクション後のレビュー

インシデントレビュー

インシデントレポート

ポストインシデントレビュー

根本原因分析(またはRCA:Root Cause Analysis)

事後検証とは、その根幹をなすもので、インシデントにつながった状況要因、インシデントに対応するために取られたステップ、そしてインシデントが2度と起こらないようにするために計画された作業を詳細に説明する文書です。事後検証プロセスには、検証結果について話し合い、それらの学習結果をより幅広い組織や顧客と共有するための会議も含まれます。

大きなインシデントを解決した後、その経験がまだみんなの心に新鮮な間に事後検証をすることを考え始めるべきです。PagerDutyでは、重大な問題が発生してから5日以内に事後検証の処理を済ませています。インシデントの解決がその発生時に最優先事項になるのと同様に、事後検証の完了は計画された作業よりも優先されます。事後検証の延期は、インシデントの再発を防ぐはずの重要な学習の開始を遅らせます。

責任を問わない事後検証

ITの専門家として、私たちは障害が複雑なシステムで起こることを理解しています。それは避けられません。そして、それが起こったときの失敗への対応は重要です。インシデントを引き起こしたとして個人を非難し罰したいという衝動は、将来のインシデントを防ぐために必要な知識の共有を阻むという意図しない効果をもたらします。エンジニアは、インシデントが発生したときには、非難を恐れて発言を躊躇します。この沈黙は、Ackまでの平均時間と解決までの平均時間を増大させ、インシデントの影響を拡大させます。

事後検証プロセスがシステムの改善と学習をもたらすためには、人的エラーを、体系的な問題が起こした症状として扱い、原因そのものだとは考えないようにする必要があります。ソフトウェア開発の複雑なシステムでは、様々な条件が相互作用して失敗を起こします。事後検証の目標は、どのような体系的要因がインシデントを引き起こしたのかを理解し、この種の失敗が再発するのを防げる行動を見つけ出すことです。

誰がミスを犯したかではなく、どのようにミスが犯されたかという点をブレずに検討し続けるべきです。これはエンジニアが罰を受ける恐れを排除することにより、起こったことについての客観的な説明を与え、事後検証の作業を正しく進めるために、Etsy(責任を問わない事後検証の先駆者です)のような多くの先行する組織に活用されている重要な点です。

継続的な改善の文化を望むことに賛成するのは簡単ですが、学ぶために必要となる、責任を問わない検証を実施することは困難です。失敗の本質の驚くべき性質は、それを素直に理解しない方向に人間を反応させます。情報を処理するとき、人間の心は無意識のうちに正確さよりタイムリーに対応しようと近道を取ってしまい、時々誤った結論を導きます。このガイドでは、事後検証分析を妨げる多くのCognitive biasesとそれらを克服するための戦略について詳しく説明しています。

あなたが次に重大なインシデントに遭遇したとき、あなたの対応は事後検証作業が済むまでは終わらないということを忘れないでください。大規模なインシデント対応は時々苦痛ですが、それはまたあなたのシステムとプロセスを学びそして持続的な改善をする素晴らしい機会になります。

私達の新しいガイドを見て事後検証プロセス(Postmortem process)に含まれるステップについての詳細を知ってください。また私たちは、Communityフォーラム(訳注:PagerDutyのサイトに飛びます)で、責任を問わない事後検証を実践するためにあなたが考えるテクニックについてお聞きしたいと思っています。

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

<  123456789101112  >