DevOpsは買えません
DevOpsへの移行は、どこから始めればよいのかわからない多くの組織にとって、大変な作業になる可能性があります。私は最近、どんなソリューションが市場に出回っているかを知るために、いくつかのDevOpsの評価を読んでみました。それはDevOpsを完全に採用している組織から、まだ始めたばかりの組織までありました。評価の中には真の価値をもたらし、文化や方法論に関する記事にリンクしているものもあれば、DevOpsのすべての夢を実現するためのツールを提供してくれるというものもありました。
DevOpsの過程では、ユーザーがサービスを継続的にデリバリーし、自動化し、サービスを監視することを可能にするソフトウェアとしてのツールは不可欠です。ただし、DevOpsは製品ではなく、ツールだけではDevOpsの価値を十分に理解するために必要なプロセスを得ることができません。DevOpsでは人が最も重要です。人がいなければ、DevOpsを完全に実現するために必要な考え方や文化を構築することはできません。
DevOpsで勝つのではなく、チャンピオンになる
私は最近PagerDutyのCEOであるジェニファー・テハーダと勝者とチャンピオンの違いについて話をしました。彼女は勝利の素晴らしさを語りました。トロフィーやタイトル、もしそれが宝くじなら数百万ドルが手に入ると。しかし、大きな絵で見ると、勝利は短期的なゴールに過ぎません。対照的に、チャンピオンになるには、長期的な成功や成果に焦点を当てることが必要です。この会話で、DevOpsを採用している組織に同じ原則をどのように適用できるかについて考えさせられました。
DevOpsツール関連の私のお気に入りの1つは、XebiaLabs社のDevOpsツール周期表です。
表に示されているように、DevOpsカテゴリーには多数のツールがあります。しかし、ツールを購入することによって組織が「DevOpsに変貌する」という話を見たり聞いたりすることが多すぎます。先に述べたように、ツールはDevOpsへの過程の重要な部分ですが、ツールだけではDevOps環境は構築されません。DevOpsチームを適切に機能させるためのすべての要素（コラボレーション、自動化、オーナーシップ、サイロの解体、プロセスの定義、継続的改善、継続的デリバリー）を考慮する必要があります。
ツールの購入を決断することは正しい方向への大きな一歩ですが、もっとも重要なのは、決定の背後にある「なぜ」、つまり最終目標を定義することです。そのために、もう一度チャンピオンの考え方を検討しましょう。
たとえば、オリンピックの水泳金メダリスト、マイケル・フェルプス選手を見てください。フェルプスは史上最も称賛されたオリンピック選手であり、彼は39の世界記録を保持しています。フェルプスは1、2勝するどころか、20勝でも止まりませんでした。彼はチャンピオンになることを目指しました。これはすべて、コミットメント、実践、そして目的とする最終状態に集中することによって成されました。
DevOpsの定義
DevOpsには何百もの定義がありますが、ほとんどの人はDevOpsレポートで概説されている次の基本原則に同意することができます。
「DevOpsは、チームがより効率的に作業し、優れたソフトウェアをより迅速に提供できるように、文化とプロセスを構築することを目的とした一連の原則です」。
文化やプロセスはクレジットカードで変更することはできません。ツールを使用すると、組織はより優れたコラボレーション、自動化、継続的デリバリーを実現できます。しかし、正しい考え方と選択がなければ、ツールの全機能が達成されない可能性があります。
例としてSlackを取り上げましょう。新しい会社に転職した私の元同僚は会議に出席していました。彼は、Slackのチャンネルを作ってコラボレーションすることが、チームをDevOpsに変えるために素晴らしいと言うのを聞きました。Slackが彼らのすべてのコミュニケーション問題を解決するだろうと彼のマネージャーは確信しました。しかし、Slackを採用してから6か月後でも、マネージャを含めチームの大半がまだSkypeを使用していました。Slackは、製品をより早く市場に投入するために使用されるツールというよりは、ビールの醸造について話すための場所になったのです。問題はSlackではありませんでした。それはチームと組織の参加の不在、そして製品の全機能に関する知識の欠如でした。
ツールとベストプラクティスをチームと短期、長期の目標の達成にいかに機能させるかが、DevOpsチャンピオンとしての我々が話すべきことです。たとえば、チームや組織の全体の目標は何ですか？ 目標が特定されたら、主要なステークホルダーからどのようにして賛同を得るのでしょうか。合意が成された後、どのようにしてソリューションを実装しますか？
組織変更
変化は多くの組織や個人にとって困難であり、意味のある変化は一晩では起こりません。人と組織がどのように変化を成し遂げるかを理解することは重要です。
Kotter 8-Step Process for Leading Changeが提唱するのは、最初のステップで変化の必要性を明確にし、すぐに行うべき理由を考え、小さなことから始め、勝とうとする前に内部にいるチャンピオンを見つけて育てるということです（この場合の変化はツールの購入）。
組織内の人々が問題を認識していない、またはより良い運営方法が存在することを認識していない場合、チームメンバーの賛同と新しいアイデアを採用し行動を起こすように動機付けることは困難です。もしかすると現在のプロセスが十分であるため、人々は現在の状態に完全に満足しているかもしれません。または、少なくとも現在の状態が既知である可能性があります。しかしながら、チーム全体がうまく機能し、より早く、より機敏な方法で彼らの共通の目標を達成するためには、最初に新しいメカニズムを導入しなければなりません。
DevOpsチャンピオンになる方法
DevOpsの世界でチャンピオンになることは、勝利を超えて進むことを意味します。それは、チームと組織構造と文化を深く掘り下げて、ツールの範囲を超えた問題を特定し、他の人と協力して、明確な結果につながる必要な変化を受け入れることを意味します。つまり、最初に戻って最終の目標を定義する必要があります。以下はあなたが始めるように頼むことができる簡単な質問です。
あなたのコアバリューは何ですか？ なぜあなたはもっとアジャイルな会社やチームになろうとしているのですか？ あなたのチームや組織はどんな障害に直面していますか？ ツールやプロセスは何を達成するのでしょうか？ 人々はどのようにしてコミュニケーションやコラボレーションをしていますか？ サイロはありますか？ それはなぜですか？ あなたはどのように顧客を擁護していますか？ 従業員は権限を与えられていますか？
最終状態を定義したら、志を同じくする他の人をチャンピオンチームの一員にし、達成しようとしていることを見失なわないようにしましょう。1つのチームやテスト環境から始めるなど、変化を始めるときはスモールスタートを忘れずに。小さく始めて勝利を築くことによって、内部のチャンピオンは彼ら自身をクリエイトし始めるでしょう。
覚えておいてください。企業は熱心にDevOpsを売ろうとしています。しかし、結局のところ、DevOpsは製品ではありません。それは、自動化、コラボレーション、人、そしてプロセスの方法論と考え方なのです。
*この記事のオリジナル版は、opensource.comで以前に公開されたものです。
本記事は米国PagerDuty社のサイトで公開されているものをDigitalStacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。
DevOps
2019年6月リリース新機能の概要：いつでもどこでも、リアルタイムで作業
6月の新機能リリースでは、チームがどこにいてもリアルタイムで作業できるように設計された新しい一連の機能強化を発表いたしました。移動しながらモバイルデバイスを使っていても、いつものようにデスクにいても、使いやすさを犠牲にすることなく業務の革新を続けていきます。
あなたのやり方で
PagerDutyを使用すると、チームはデスクトップから、もしくはチャットやモバイルを介して、どこからでもリアルタイムの作業を管理できます。
モバイルチームとエスカレーションポリシー
iOSモバイルデバイス用のPagerDutyモバイルチームとエスカレーションポリシーが更新されました（Androidは近日公開予定）。これで、iOSモバイルデバイスで次のすべてを直感的に実行できるようになりました。
チームメンバーとオンコール担当者がすぐ分かる 問題の現状把握と解決を容易にするため、適切な対応者とその連絡先を特定する チームのエスカレーションポリシーの明示
再設計されたモバイルオンコールシフトとスケジュール
モバイルオンコールのシフトとスケジュールの全体を確認し、タップしてスケジュールやエスカレーションポリシーの詳細を表示し、簡単に変更できます。
モバイルビューとインシデント対応者の追加
誰がインシデントに対処しているのかを確認し、アプリから対応者（ユーザーまたはエスカレーションポリシー）を追加して、問題を迅速に解決するために必要な支援を受けることができます。
モバイルビューインシデントステータスの更新
その他の新たな機能は、企業全体のコミュニケーションを自動化して、チームが重要なインシデントについて組織全体で認識を共有するのに役立ちます。iOS向けの最近のリリースに続いて、Androidデバイスを使用する利害関係者も、インシデント購読者を管理し、インシデントのステータスの更新を表示して、関連する解決活動について常に情報を得てデジタルビジネスの健全性を把握できます。
モバイルスワイプジェスチャー
インシデントに対するモバイルスワイプジェスチャーの改善により、Androidでは設定メニューから、iOSではスワイプから表示、タップと確認で、左スワイプや右スワイプのアクションを設定できるようになりました。
モバイル複数選択ワークフロー
Mobile multi-select workflowsで、一度に複数のインシデントをトリアージ、スヌーズ、マージ、受任することができます。これにより、ノイズを削減し、PagerDutyイベントインテリジェンスにフィードバックを提供して、トリアージとスマートな応答を迅速に行えます。
新インテグレーションーCloudability、Demisto、Salesforce（coming soon）
私達はFinOpsやSecOpsなど、さまざまな利用法をツールチェーンで接続する際に、より高い可視性と柔軟性を持つことができるように、新たなインテグレーションへの投資も続けています。さらに、Salesforceとのインテグレーションも間もなく開始されます。そのほか、新しく強化されたインテグレーションには、CloudabilityとDemistoがあります。
PagerDutyとCloudabilityのインテグレーション により、クラウド関連の意思決定と予測、計画、および購買能力の適切でタイムリーな最適化アクションを実行できます。このインテグレーションにより、クラウド使用料請求に異常が検出されたときに、リアルタイムで使用量を最適化することができます。
PagerDutyとCloudabilityのインテグレーションにより、次のことが可能になります。
豊富なクラウド請求イベントデータをCloudabilityからPagerDutyにリアルタイムで送信する Cloudabilityインスタンス内の異常を検出する 対応するPagerDutyサービスで新しいインシデントをトリガーする アラートを単一のインシデントに自動的にグループ化する Cloudabilityで検出された異常に対処するようオンコールの担当者に通知する
PagerDutyとDemistoのインテグレーション により、自動化されたデジタル運用管理とセキュリティとITチームにわたる集中的なインシデント監視が可能になります。また、DevSecOpsツールスタック内で機動的なセキュリティ対策を実施するのに役立ちます。
PagerDutyイベントの取り込みと作成、解決を自動化 Demistoインスタンス内のPagerDutyからオンコールスケジュール、連絡方法、通知の詳細にアクセスする 何百ものDemisto製品統合を活用して、部門を超えて対応を調整する ChatOpsを介して対話的に数千のコマンドを実行する 実行スクリプトを作成する。コントロールルームでコマンドを実行したり、スクリプトをプレイブックに関連付けたりする
PagerDutyとSalesforce Salesforce Service Cloudとのインテグレーションはまもなく登場します。内部プロセスがあなたの顧客経験に影響を与えないようにしてください。PagerDutyはSalesforce Service Cloudとのまったく新しいインテグレーションを開始し、カスタマーサービスチームがリアルタイムのサポートを受けられるようにします。双方向のインテグレーションにより、PagerDutyとSalesforceケースの同期が維持され、エージェントは必要に応じて適切なリソースを毎回適切な時期に活用できます。
インシデント対応
より大きなコンテキスト
コンテキスト検索
Contextual Searchでは、チーム、エスカレーションポリシー、ユーザーなどの簡単なタグ付けメタデータをPagerDutyオブジェクトに追加して、対応者とマネージャーが目的のオブジェクトをナビゲートして整理しやすくするとともに、インシデントをすばやく簡単に再アサインできます。タグ付けはコンテキスト検索と連動しているため、インシデントに対応者を追加するときにエスカレーションポリシーをフィルタリングできます。次のスクリーンショットは、PagerDutyオブジェクトのタグ付けの概要を示しています。
Contextual Search APIは現在、特に関心のある利用者への早期アクセス提供となっており、2019年夏に一般利用可能になる予定です。
チームタグの作成と追加
エスカレーションポリシーのタグ
ユーザータグ
タグでオブジェクトを絞り込む
タグを使用してインシデントを再アサイン
モバイルでのエスカレーションポリシーのコンテキストサーチ
Mobile Contextual Searchを使用して、アラートを受信すればいつでもどこでも、タグでエスカレーションポリシーをフィルタリングしたり、検索を使用してインシデントを適切な担当者にすばやく再アサインできるようになりました。
セルフサービスの拡張性
ユーザセッション管理API
User Session Management APIエンドポイントにアクセスしてユーザーセッションを取得、削除できます。これらのエンドポイントは、組織外のユーザーをそのユーザーに関連付けられているすべてのPagerDutyセッションから安全に削除する、ユーザーオフボーディングワークフローの活用に不可欠です。
リアルタイムの可視性
可視化コンソールのパフォーマンスとカスタマイズ
可視化コンソールのパフォーマンスが新たに強化されたことで、エンジニアとビジネス担当者の間で、テクニカルインシデントがデジタルエクスペリエンスにどのような影響を与えるかをリアルタイムで共有することができます。可視化コンソールのすべてのモジュールがライブアップデートされるようになったため、手動でのリロードや自動更新は不要になりました。さらに、コンソールレイアウトの変更は自動的に維持されるようになり、レイアウトの変更を手動で保存する必要がなくなりました。
6月リリースの新機能を使い始めるには、あなたのアカウント担当者に連絡を取り、詳細についてはKnowledge Baseをチェックしてください。
最後に、私たちは定期的に、四半期ごとのPagerDuty Pulse Webinarで、製品、インテグレーション、その他新機能のすべてを紹介しています。今すぐregister todayで登録しましょう。
本記事は米国PagerDuty社のサイトで公開されているものをDigitalStacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。
ニュース＆告知
2019年春リリースの概要：The Intelligent Enterprise
今日のデジタルワールドでは、企業のビジネス関係者や障害対応にあたる技術者は、中断が発生したときにすぐに対応できるように、常にデジタルサービスの健全性を意識する必要があります。それでも過去3年間で、1人のレスポンダーあたりの業務の複雑さは平均3倍に増えているため、チームがデータを理解し、意味のある洞察を得て、デジタルオペレーションを改善することはますます難しくなっています。
そこで今日私たちは、インテリジェントな企業向けに設計した新しい一連の製品の機能を発表します。これらの機能強化によって、各チームが重要な瞬間にデータ、インテリジェンス、そして大規模な自動化を使って、効果的に成果を上げることができます。Spring 2019リリースでは、プラットフォーム全体で新しい改善が行われており、エンタープライズクラスのものでありながらユーザーを念頭に置いて設計されたエクスペリエンスを提供します。
新製品のアップデート
この1年で、私たちは、マシン、チーム、サービスの所有権、そして人間の応答データにわたる、独自のテレメトリの流れに基づいて構築された、いくつかの新しいモジュラー製品をコアプラットフォームの上にリリースしました。 以下に詳述するこれらの新製品は、すでに何千ものチームがよりインテリジェントで効率的な方法でリアルタイム作業を処理するのを助けています。
PagerDuty Event Intelligence
ますます複雑化する運用上の複雑さを管理し、ノイズから信号を抽出し、機械学習主導のコンテキストでトリアージを加速することで、チームの拡張を支援します。
PagerDuty Modern Incident Response
自動対応の動員と利害関係者のコミュニケーションにより、チームは重要なインシデントをより迅速に解決できます。
PagerDuty Visibility
レスポンダーと事業主の両方がデジタルの混乱への共通の状況を受け取ることができます。
PagerDuty Analytics
運用上の投資と成熟度を向上させるための最新の洞察をデジタルビジネスのリーダーに提供します。
Human-Context Enriched Intelligenceの提供へ
Springリリースの一部として、 いくつかの新しい機能でPagerDuty Event Intelligenceを強化しました。 機械学習を使用してノイズを低減するPagerDuty独自のIntelligent Alert Groupingアルゴリズムは、これをさらに効率的に実行するように改善されているため、少ないトレーニングデータでより早く作業を開始できます。 新しいアラートグループ化プレビューにより、サービスのオーナーはインテリジェントアラートグループ化をアクティブにする前に、潜在的なノイズ低減とグループ化動作を理解することができます。
インシデント＆アラート
Dutonianのような影：シャドーイングでオンコール学習
by Max Timchenko
オンコールシャドーイングをする理由
PagerDutyでは、オンコール中のシャドーイングは欠かせません。 新しいエンジニアにとって、シャドーイング期間は問題診断と解決のストレスや責任を一切伴わずに、より親切でスムーズなオンコール開始の準備として役立ちます。
PagerDutyでシャドーイングを設定するとき、「シャドーユーザー」の行動が実際にオンコール中の主任エンジニアに影響を与えないようにしながら、オンコールのプロセスとアクションをできるだけ正確にシミュレートすることが目標です。これにより、シャドーユーザーは安心し、気楽にしていることができ、主オンコール対応者も邪魔されずに行動することができます。
シャドーイングの使い方
最初のステップは、シャドーイング専用のPagerDutyアカウントを設定することです。 このシャドーアカウントに、シャドーイングをしているチーム用のサービスとeメールインテグレーションを追加します。チームが一度に1人のシャドーイングをしているだけであれば、チームごとに1つのサービスで十分です。同じチームに複数の人がシャドーイングしている場合、それでは済まない可能性があります。
このインテグレーションで使うメールアドレスは、プライマリー（メイン）のPagerDutyアカウントにシャドーユーザーへの通知方法として設定します。これは、チームをシャドーイングするためのプライマリーアカウントのオンコールエスカレーションポリシーに追加されます。
この設定の結果、インシデントが発生したときに、通知が主任オンコールユーザーとプライマリーアカウントのシャドーユーザーに送信されます。これにより、シャドーアカウントに同じ情報を持つ別のインシデントが作成されます。シャドーアカウントはシャドーユーザーに通知します。これは別のインシデントになったため、主任オンコールユーザーが対応しているという実際のインシデントのステータスを変更することなく、必要なこと（受任、スヌーズ、コメントの追加など）を実行できます。
この設定の副次的な利点は、一度設定するとプライマリーアカウントの設定をそのままに、シャドーアカウントを使ってシャドーする人の追加や削除、設定が完全にできることです。もう1つの利点は、週末やオンコールの引き継ぎ日などを除外するようにシャドーイングスケジュールを変更できることです。営業時間中にのみシャドーイングを設定することもできます（シャドーユーザーを本物のオンコールのローテーションに追加しないでください）。
「Dutonian」はStar Wars「The Old Republic」に登場するキャラクター。 「シャドーイング」とは初心者が技術習得のために教師役の行いをそっくり真似すること。
シャドーイングを設定する方法
ステップを詳細に見ていきましょう。手順のいずれかが不明な場合は、以下で使用されている設定手順の多くを順を追って解説する設定と対応者トレーニングのウェビナーをご覧ください。
シャドーアカウントを作成する
PagerDutyアカウントをまだお持ちでない場合は、無料トライアルをお申込みいただければこれを含めた設定が試せます。
プレースホルダーにユーザーを作成する
誰もシャドーイングしていない場合、このユーザーはシャドーアカウントのすべてのシャドースケジュールで使用されます。そして誰も呼び出しません。シャドーイングしている人がいると、対応するスケジュールでテキストボックスのユーザーを上書きします。
スケジュールを作成する
次の3つのエンティティ（スケジュール、エスカレーションポリシー、サービス）がチームごとと、同時に行われているシャドーごとに作成されます。これにより、すべてが整理され分離されます。単一のチームに単一のシャドーを設定している場合は、必要なのは1セットだけです。
この例では、架空の 「Labs」チームを使用しています。 テクストボックスのユーザーをスケジュールに追加し、自分のチームに最適なオンコールスケジュールの作成をします。
エスカレーションポリシーを作成する
新しく作成したスケジュールをエスカレーションポリシーに割り当てます。
サービスを作成する
プライマリーアカウントでシャドーユーザーを作成する
プライマリーアカウントに切り替えて、シャドーアカウントのイベントを生成するシャドーユーザーを作成します。シャドーアカウントに複数のシャドーサービスがある場合でも、チームごとに1人のシャドーユーザーしか設定できません。連絡方法に対応するすべてのシャドーサービスにすぐにメールを生成するように通知ルールを設定します。複数のEメールアドレスを設定することで、1人のユーザーがすべてのシャドーサービスに通知できます。対応するすべてのシャドーサービスにすぐにメールを生成するように通知ルールを設定します。
シャドーユーザーをプライマリーアカウントのエスカレーションポリシーに追加する
プライマリーのPagerDutyアカウントで、「Labs」チームのオンコールエスカレーションポリシーをスケジュールしている可能性があります。 誰がオンコール中かに関係なくシャドーユーザーに通知されるように、そのスケジュールと一緒にシャドーユーザーをエスカレーションポリシーに追加します。
重要：Shadow Userをエスカレーションポリシーに直接追加しないでください。追加すると、この人物の行動が実際のインシデント処理を妨げる可能性があります。
設定のテスト
これで設定は完了です。 実際に動作するかをテストできます。プライマリアカウントでチームが使用しているサービスを選択し、手動でインシデントをトリガーします。
インシデントはプライマリーアカウントに表示されます。
インシデントはシャドーアカウントにも表示され、プレースホルダユーザーが呼び出されます。
シャドーインシデントを受任して解決しても、プライマリーアカウントのインシデントには変更が加えられていないことに注意してください。 これで完璧です。
シャドーイング用のユーザーの設定
シャドーしたい人がいるときは、シャドーアカウントに招待してください。通知方法やその他のユーザー情報を通常どおりに設定するようにユーザーに依頼してから、それをシャドースケジュールに上書き設定します。シャドー期間が終了したら、ユーザーを削除します。
スケジュールメモ
PagerDutyでは、シャドーイングのためのサービスとスケジュールを別々に持つことで、シャドーイング時間を変更できます。週に7日、1日24時間などというプライマリーのスケジュールに従うのではなく、週末を除外したり営業時間のみにしたりすることで、シャドーイングの負担を軽減することができます。
「オンコールシフト時間を制限する」には特定の日を除外するのが最も簡単な方法です。営業時間のみのシャドーイングを設定するのはシャドーサービスで簡単にできます（例：「対応者に通知する方法」および「定義されたサポート時間を使用する」）。
注意：シャドーイングプラクティスを設定する際に、シャドーがオンコールローテーションに追加されると、それはプライマリーのオンコールになります。そしてシャドーがエスカレーションポリシーに追加されると、そのアクションはインシデント処理に影響します。
どのようにしてシャドーを私たちの文化に吹き込むか
PagerDutyのシャドーイングプラクティスは誰でも見ることが出来ます。これは、会社の全員にPagerDutyの機能を知ってもらいたいがためです。社内での立場に関係なく、PagerDutyを使用してエンジニアリングチームのシャドーイングに1週間かけて機能と使用方法を理解させることをお勧めします。週単位のオンコールローテーションを実施しているチームの中には、週末と次の担当者に引き継ぐ日を除いた時間をデフォルトのシャドーイングスケジュールとしているところもあります。これですと、週4日、1日24時間の「シャドーイングシフト」が成立します。
チームのほとんどは、シャドーイングを開始したい時期と、オンコールローテーションに参加する準備ができた時期を新しいエンジニアに決定させます。チームの期待するところは、シャドーイングは最初の3カ月のうちに始まり、責任と失敗を非難しないことを共有する文化は、シャドーイングから本番のオンコールへの移行の垣根を低くします。
PagerDutyのシャドーイングの設定方法が理解できたら、この重要なプラクティスを利用してオンコールの経験を改善し、エンジニアの円滑な参加を促進してください。
本記事は米国PagerDuty社のサイトで公開されているものをDigitalStacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。
ベストプラクティス
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が日本語に訳したものです。無断複製を禁じます。原文はこちらです。
ベストプラクティス
Postmortem（事後検証） パート2：学習する文化を取り入れる方法
事後検証（ポストモーテム）シリーズのパート2では、リーダーシップを発揮することから文化面での変化を起こすことまで、継続的な学習の文化を確立する方法を掘り下げます。*
文化は私たちが物事を一つにする方法です。それは一貫した形で目標を満たす幸せで健康的なチームを作るための秘密のソースです。組織の中で定義し、育て、変革するのは最も難しいことです。真の文化的変化には、ポリシーを作って伝えること以上のことが必要です。コラボレーション、永続性、そして実験が必要です。
PagerDutyの私たちはアジャイルの方法論とDevOpsプラクティスの大ファンです。私たちは、ソフトウェア開発から文化の変化まで、継続的な改善の原則を適用しました。反復的な評価とコラボレーションを通じて、文化を正しい方向にシフトさせることができます。
これは別のコアなDevOpsプラクティスである事後検証に思い至らせます。事後検証の成功は単なるプロセスにかかっているのではなく、誠実さ、学び、説明責任の文化に基づいています。企業文化の変革には経営陣の参加が必要ですが、自分の役割に関係なく文化の変革を先導することができます。
身近なところから始めよう
あなたの会社のプロセスの全面的な見直しに着手する前に、どこから始めるのかを把握することは重要です。インシデント後の報告には事後検証プロセスを使用していますか？ あなたが従うステップは何ですか？ 誰が関与していますか？ 失敗についての会話は通常どのように行われますか？ あなたのチームがこれらの議論をすれば、関係者の責任を問わない事後検証を実施する文化への移行を始められると思います。
多くの企業は、重大インシデントの後に、何が起こったのかを検討する会議を開くでしょう。これらの議論の過程で少数の個人がインシデントに対する責任を負わされるのを見ることになるかもしれません。一般的に、全員がもう少し詳しく知る前に、将来問題を避けるための計画を立ててしまいます。さらに重要なことに、少数の人々があなたが避けたいと思う、かなり不愉快な気分で立ち去ります。
あなたのチームに迅速な監査ができるように事後検証の実施のためのステップバイステップガイドを見てください。現在していることや、現在何をしているけれど微調整する必要があるかもしれないこと、そしてしていないことは何でしょう？
責任を問わないことをリーダーに求める
事後検証を組織にまったく新しいやり方として紹介するにせよ、既存のプロセスを改善するために動いているにせよ、文化の変革は難しいものです。伝統的には変革より管理が優先されると思います、しかしボトムアップでの変革は通常もっと成功をもたらすものです。 あなたの役割が何であれ、新しいプロセスを導入するための最初のステップは、経営陣からの承認を得ることです。
変革について思慮深い推論を用いリーダーに近づくことが、その変革が持つはずの重要性と影響を強化するのを助けます。 そのための対話で重要な点は次のとおりです。
責任追及がどれほど有害であるかを明確にし、定量化し、そして責任追及のビジネス上の価値を説明する。
問題を「引き起こした」ことを理由に個人を罰する慣習は、問題が発生したときに人々が責任追及されることを恐れて発言しなくなるように仕向けます。結果としてインシデントを認識して解決するまでの平均時間が長くなり、最終的にはインシデントの影響が大きくなり、深刻な影響を受ける可能性があります。問題が発生したらできるだけ早く解決できるように、リーダーは人々に発言を求めてください。
組織は責任追及される恐れを排除し、共同学習および反復的な設計の改善を促すことによって、システムの回復力を急速に向上させ、イノベーションのスピードを上げることができます。
さらに、バカみたいに聞こえるかもしれませんが、新しい事後検証プロセスを売りこむときに、管理側のせいにしないことを忘れないでください。リーダーがチームに加わっていることを確認してください。インシデント後に誤って責任追及を示唆した場合には、彼らがそのフィードバックを受け取るのを納得するというリーダーシップの確約を得ることが重要です。
ゴールは、継続的改善の文化を作るためにリーダーに確実に参加してもらうことです。
Pro tip___：責任追及をしないという概念を会社の価値にマップできるかどうかを確認してください。例えばPagerDutyの文化的価値観の1つは、特に中断と継続的な改善を受け入れ、常に学習に集中することです。このような責任を問わない事後検証の概念は、これらの価値を支えることに直接対応できます。
チームを指導する
これでリーダーシップが完成しました。組織で大きな文化の変革を遂げることができました。次のステップはあなたのチームの個々のコントリビューターの参加を確保することです。彼らがまだ、インシデントの責任を追及されることを恐れているかもしれないことに留意してください。その恐れは、ポリシーだけでは消えないでしょう。インシデント対応後にどんな方法でも誰も罰せられることはない、という経営陣からのコミットメントを得ていることを必ず共有してください。責任をもっと意識して、責任が認められたらお互いに声をかけて協力することで、同僚との信頼関係を築きましょう。
（グループ内での心理的安全性の重要性について読んでください。）
変革を繰り返す
文化の変革は一晩では起こりません。実験を成功させた結果を新しいプラクティスと共有し、次にそれらのプラクティスをチーム間でゆっくりと拡張するなど、小規模から始めて新しいプラクティスを組織に繰り返し導入します。
始め方：
チームを1人選び、完璧な事後検証の実験を始めましょう。** 始めるには、「事後検証記録の書き方」ガイドを使用してヒントを共有してください。スキルを磨き、他の人に教えます。
小さなインシデントから始めましょう。** 小さなインシデントのビジネスへの影響は小さいため、インシデントの原因として個人をスケープゴートにする圧力は少なくなります。
責任追及する人を批判しないでください**。上記で推奨されているように、個人に責任を負わせがちな人を探してください。必ず声をかけて、チームがこのインシデントに対して新しい、責任追及のないアプローチを使用することを決定したことを伝えてください。
覚えておいてください：責任追及のない事後検証へのグループの信頼を築くために最初は単純なものから始めてください。チームにとって最適なものを試し、次のラウンドで繰り返します。
共有することはケアすること
組織のためでも、単一のチームのためであっても、文化的シフトを促すには大きなエネルギーを必要とします。試みられ、テストされ、そして最終的に採用される前に、それが「難しい」という単なる認識のために、変革は時に強く非難されることがあります。
インシデントレポートを共有することは、最初は直感に反するように思われるかもしれません。成功というより失敗のストーリーを共有するように思えますからね。でもそれとは全く反対に、チームは失敗から学んでシステムを改善し、失敗の発生率を減らせます。
インシデントを個人的な失敗としてではなく、具体的な改善をもたらす学習機会として再考することです。それは士気を高め、ひいては従業員の定着率と生産性を高めます。
批判しないことがアカウンタビリティを育てる
自由に情報を共有し、透明性を促すことで、説明責任を養う環境を支えられます。事後検証のあとに起きることは、システムの健全性にとって重要です。事後検証の行動項目が網羅されたと思われた時点でSLAを設定することは、チームがタスクを迅速に割り当て、優先順位を付けるのに役立ちます。また、許可を待たずにチームが行動に移れるようにします。
Pro-tip*：このSLAをすべてのエンジニアリング部門に伝達し、将来の参考にするために必ず文書化してください。
PagerDutyでは、Sev-1インシデントの再発防止に必要な優先順位の高いアクションアイテム（行動項目）は、インシデントから15日以内に完了することを期待しています。Sev-2インシデントから得たアクションアイテムは30日以内に対処されるべきです。
カルチャーのチャンピオンになる
あなたの会社の文化を良い方向に変えることは、実現が最も難しい仕事のひとつです。信じられないほど微妙で、高レベルの共感を必要とし、そして感情的に疲れることです。継続的に学習する、責任を問わない文化を促進することは、より幸せなチームとより良いソフトウェアにつながるので、組織にとって最も重要でやりがいのある作業でもあります。
評価、コラボレーション、コミュニケーション、そして実証という具体的なステップを適用すれば組織を正しい方向に変えることができます。
現在の事後検証プロセスの状況を知ることから始めましょう
リーダーとチームの了承を得て、責任を問わない事後検証を試しましょう
1チームまたは小規模なインシデントで試してみてください
実証結果を共有して、変化を広めてください
責任を問わない事後検証を採用する方法の詳細については、包括的な「Postmortem Guide」をご覧ください。あなたがどのようにして文化の変化にアプローチし、誠実さを広めているかをお聞きしたいです。当社のフォーラムにアクセスしてコミュニティと情報共有してください
本記事は米国PagerDuty社のサイトで公開されているものをDigitalStacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。
ベストプラクティス
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が日本語に訳したものです。無断複製を禁じます。原文はこちらです。
リアル（タイム）になりつつあるSecOps
AWS Security HubとPagerDutyがリアルタイムオペレーションを強化
クラウドに移行する企業は、強力なセキュリティ体制を維持し、コンプライアンス要件を満たすことができるようにする必要があります。コンプライアンスを確実にすることに加えて、企業はまた、異なるインターフェースおよびプラットフォームにわたって大量のイベントデータを生成する複数のセキュリティツールを結びつけるという課題に直面しています。この課題に対処するために、AWS re：Invent 2018で AWS Security Hubに新しいセキュリティサービスが発表されました。
AWS Security Hubとは？
Security Hubは、 Amazon GuardDuty 、Amazon Macie、Amazon InspectorなどのAWSセキュリティサービスからのイベントデータを1画面に表示します。さらに、Security Hubを使うと、AWSは多数のサードパーティ製セキュリティツールをプラグインして、好みのファイアウォールまたはエンドポイントソリューションを引き続き使用し、AWSネイティブサービスと一緒に表示するために、Security Hubにイベントデータを送信できるようにします。
AWSセキュリティハブ+PagerDuty
また、Security Hubはコンプライアンスチェックを実行し、潜在的な問題を防ぐためチームが迅速に行動できるようにカスタムアクションを作成するのに役立ちます。Security Hub内での対応および修復プロセスの一環としてPagerDutyとのインテグレーションを使用すると、各組織はCloudWatchイベントを介したGuardDuty検索ルールをPagerDutyに送信するカスタムアクションをすばやく設定できます。
Security Hub設定内でカスタムアクションを設定するのは非常に簡単です。これにより、チームはAWSまたはサードパーティのセキュリティツールから特定されたセキュリティ問題を選択し、すぐにPagerDuty内にインシデントを作成して適切な開発チームとセキュリティチームに通知し、彼らは共同で調査と対応に当たれます。
Security Hubとの新しいインテグレーションに伴い、当社もre：Invent 2018でいくつかの新しい AWS Integrationsを発表しました。
もっと知りたいですか？ 14日間の無料トライアルを提供しています。組織にPagerDutyを採用する準備はできましたか？ それならば AWSマーケットプレースでも購入できます。（訳注：Digital StacksでPagerDutyを契約するメリットについてもご覧ください）
本記事は米国PagerDuty社のサイトで公開されているものをDigitalStacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。
オペレーションの未熟さがコストを増大させる
Aditya Patil
January 3, 2019
デジタル運用の成熟度とは？
デジタル運用の成熟度は、リアルタイムの作業での組織の有効性と、その組織がインシデントへの対応に熟達するにつれて改善するパフォーマンス指標にフォーカスする能力として、定義されます。
PagerDutyは、複数の業界に渡る600名以上の回答者を対象にした調査を含む、広範囲な調査と9年間の業界のデータに基づいて、次の4つの運用成熟度レベルを特定するモデルを開発しました。
リアクティブな組織は、ほとんどの問題を顧客が報告したときに見つけることが多く、これらの問題に対処するためのプロセスを持っていません。第1線にいるレスポンダーが、サービスの問題を解決するためのスキル、知識、または権限を持っていないこともよくあります。 レスポンシブな組織は、顧客に影響が出る前にいくつかの問題に直面します。第一線のレスポンダーはスキルを持っていて問題を防ぐための権限を得始めています。しかし、その人々はまだ自分たちの仕事をするのに必要な情報を欠いています。 プロアクティブな組織は、顧客が影響を受けたり気付いたりする前に、ほとんどの問題をあぶり出して解決します。過去の問題から学んだことは自動的に文書化され、レスポンダーは現在の問題を解決し将来の問題を防ぐための知識と権限を与えられています。 プリベンティーティブな組織は、顧客に影響が及ぶ前に、ほとんどすべての問題をあぶり出して解決します。このレベルを達成するのは非常に困難であり、このレベルで活動している組織の特徴は継続的に学習する文化を持っていることです。この組織のレスポンダーは、現在の問題を解決し将来の問題を防ぐための知識と権限を十分に与えられています。これらの組織は、リアルタイムの対応プロセス全体にわたって自動化の仕組みを多用しています。
PagerDutyは、以下の図に示すように、組織の運用上の成熟度を決定する上で重要な5つの重点分野を特定しました。
5つの重点分野がビジネスの改善にどのように役立つかについて、さらに詳しく説明しましょう。
1.カスタマーエクスペリエンスを改善する
ビジネスを常に「顧客第一」と考えるように位置付けることは、今日の市場では重要です。これは、顧客にシームレスで中断のない経験を提供するために可能な限りのことを行うことを意味します。次のシナリオを検討してください。
あなたはサンフランシスコのサウス・オブ・マーケット地区にあるお気に入りのPhilz Coffeeに来て、ブリトーを欲しがっています。あなたは自分のスマホでライドシェア用のアプリAを開きますが、それがロードされません。それであなたは数秒待ちます。いや、まだロードされません。ついにあなたはあきらめてアプリを閉じて、競合他社のアプリBを開きます。これでは、Aの売り上げを失ったことになりますね。それだけじゃありません。
次回乗車が必要になったときには、前回のライドシェア会社Aでの体験を覚えている可能性があるので、まずB社のアプリを開きます。つまりそうした1つのちょっとした体験がA社の評判を損ない、将来的に売り上げをフイにさせる可能性があります。実際、Gartnerは、平均的な企業のダウンタイムコストは1分あたり5,600ドル、または1時間あたり約300,000ドルであると見積もっています。
潜在的なお金を失う可能性は大きいのです。顧客と収益を維持するために、企業は自社のデジタルビジネスがほぼ100％常に稼働している状態を確保する必要があります。しかし、当社の調査によると、回答者の50％以上が自社の組織がレスポンシブまたはリアクティブであり、顧客に損失を与え顧客との関係を壊すことにつながるダウンタイムを防止または削減するための適切な対策を講じていないことを示しています。
- 従業員の健康と会社の文化を改善する
最も単純に言えば、企業は共通の目標に向かって努力する人間の集団に他なりません。 （そしてPagerDutyには最高の人間がいます。一緒にやりましょう！）
従業員は会社の最も貴重な資産でもあるので、燃え尽きを防ぐための対策を講じることはその人たちの幸せと生産性を維持するために不可欠で、結果的に離職率も低くなります。
なぜ組織が離職率を気にする必要があるのでしょう？貴重な蓄積された組織知を失うことは置いておいて、IT専門家に関するPagerDutyの最新の調査では、1人の経験を積んだレスポンダーを別の人に変えるには最大30万ドルものコストがかかることが分かりました。こうした種類の数字を検討すると、次のような質問をすることによって個人と全社の健康状態を追跡することが会社にとって最も重要です。
勤務時間後に従業員が呼ばれる頻度はどのくらいですか？ あなたのチームのIT担当者の年間離職率はどのくらいですか？
これらの指標にアクセスできることは有益で、対処不可能なアラートや繰り返し発生する対処不可能な量のインシデントが、仕事から離れた従業員をイライラさせることにつながることを理解できるようになります。また、アラートの数を減らすことによる影響はすぐには表に出ないものの、時間の経過とともに大きな違いが生じることも当社のデータから明らかになっています。
現実に、アラートを減らすための対策を講じた成熟した組織では、成熟していない同業者と比較して、オンコールする担当者（レスポンダー）の離職率が21％低くなっています。 50人のレスポンダーがいて、10％の離職率である会社の場合は、21％の削減は年間31万5000ドルの節約になります。
- MTTRを削減するために各プロセスを最適化する
プロセスの最適化は組織がスケールするにつれて重要になります。しかし、それは単にベストプラクティスを見つけてそれに従えばよいというわけではありません。つまり、各企業は改善のための領域を特定するために既存のプロセスを評価する必要もあるのです。 例えば、インシデント対応中の利害関係者への通知は、ほとんどの組織で改善できるプロセスです。以前のブログで説明したように、中核の対応チームの外にいる人々に最新情報を提供するためのコミュニケーション戦略を構築することで、オンコールレスポンダーはインシデントの解決にもっと時間を費やすことができます。
さらに、インシデント対応プロセスは、インシデントが解決されたというだけでは完了しません。成熟した企業におけるデジタルオペレーションの要素には、チームが根本原因の分析を実行できるようにする、ブレームレスつまり個人の責任を問わない事後分析（ポストモーティム）プロセスが含まれます。これはパターンを解析し、類似のインシデントが再発するのを防ぐのに役立つ洞察を提供します。
-
知識共有の実践を育てる
-
正しい技術とツールを使う重要性
現代では組織がビジネスプロセスを最適化するのを支援するために豊富な技術とツールが利用できます。そして健全で成熟したデジタル運用のプラクティスを構築する場合でも同じです。オンコール中の従業員は、大量の通知や対処できない警告に溺れてはいけません。以下の表は、組織の成熟度に3つの重要な指標がどう対応しているかということに関するいくつかの重要な発見をまとめたものです。
注目すべき点は：
最も成熟した回答者は25％のアラートしか 対応不能（unactionable）なものはないと回答していますが、最も成熟していない回答者は28％のアラートがunactionableだったと回答しています。 最も成熟した回答者のインシデント対アラート比（incident-to-alert ratio。実際にインシデントになったアラートと全アラートの比 ）は約1：3でしたが、最も成熟していない回答者は約1：1でした。 最も成熟した回答者は自動化で問題の57％を解決しました**が、最も成熟していない回答者は自動化で問題の16％しか解決できませんでした。
成熟した組織によくある最も一般的な特徴は、過去のインシデントから学んで、それによって、顧客が影響を受けるようになる前にインシデントを解決する、またはアラートのノイズを減らす、どちらかのテクノロジーを利用していることです。 従業員が対応不能なアラートの確認と自動化で解決される可能性のあるインシデントの手動での解決に注力している場合は、て本来は業務の革新や他の問題解決にかけるべき数えられないほどの人・時が失われます。重要なのは、組織のデジタル 運用をReactiveからPreventativeに成長させ、そしてカスタマーエクスペリエンスを向上させるための革新の推進に集中するために、チームに適したツールを見つけることです。
組織の運用上の成熟度を向上させる方法についてもっと知りたい場合は、弊社までぜひお問い合わせください。
GET STARTED
この記事は、PagerDutyサイトに掲載されたブログをDigitalStacksが和訳・追記したものです。無断複製を禁じます。原文はこちらにあります。
アラート対応疲れを減らすためにSignalFxとPagerDutyでソーシャルシグナルを監視する
チームにこう伝えました。「SignalFxで重要なイベントが進行中の場合は通知してほしい」。しかし、システム監視の会社のCTOであるにもかかわらず、進行中のインシデントや潜在的な問題を常に把握するために、適切なアラートを作成することは思ったよりも困難でした。
どうして？
クラウドとオープンソースの登場により、ソフトウェアをより迅速に構築できるようになりましたが、今日の環境は次のようなさまざまな理由から、監視と管理が非常に複雑になっています。
監視するインスタンス数の爆発（ホスト、コンテナ、関数） サービスはまれに「正常動作」というメトリックを発したり、常に変化したりする マイクロサービス構成のため、個別に監視する必要があるサービスの量が増えている
私たちの経験による結論は、誤検知や繰り返される警告の嵐です。アラート疲れはチームがリアルタイムで問題を見つけて解決する能力を妨げるだけでなく、長時間対処されないとチームの士気を破壊し、本来予防可能なシステムダウンをもたらします。
アラート疲れを軽減するための戦略
アラート疲れを軽減することは、自らの焦点を広げることから始まります。きめ細かなメトリックの測定は、トラブルシューティングやフォレンジック分析には非常に役立ちますが、最も効果的なアラートは、アプリケーションの健全性に関する高レベルのインジケーターを構成するシグナルの組み合わせに依存します。特に、次の点を考慮する必要があります。
個々のインスタンスではなく、全体を監視
環境内の個々のコンポーネントのステータスを警告するのではなく、サービスごとまたはグループごとの健全性インジケーターを定義してモニターします。たとえば、サービスインスタンス間のAPI呼び出しの99％が要している遅延時間、ノードの特定クラスタの平均CPU使用率、コンテナのグループのAPIエラーの合計などを追跡します。
1436台のホストのシステムメトリックを集約
固定の閾値よりもパターンと傾向に関する警告
変化する環境に適応できるアルゴリズムで生成された閾値を使用する。分散システムはしばしばミステリアスな方法で動作するため、アラートが発生する前に正しいCPU使用率やAPIエラーの数を判断することは非常に困難です。
単純セッション数と週をまたいだ変化
定期的なパターン（たとえば平日の高トラフィック）や予測的なアラート（次のN日以内にクラスタがディスク領域を使い切るのを警告する）によって、システムの通常の動作と対応を必要とするものを区別できます。
グラフが示す容量のメトリックの傾向
アプリケーションのパフォーマンスの全体的な尺度の定義
さまざまなマイクロサービスのメトリックを組み合わせて、より高いレベルのシグナルとアラートを導き出す。たとえば、ログインユーザーあたりのページ読み込みの数と、API呼び出しの合計に対するAPIエラーの割合です。あるお客様は、すべてのマイクロサービスのメトリックを組み合わせて、デプロイしたバージョンのパフォーマンスが全体的に改善されたかどうかを示すヘルススコアを作成しています。
ソーシャルシグナルの測定
SignalFxでこれらのテクニックをすべて使用していたにもかかわらず、まだ誤検知のアラートが多すぎました。次の点に注意しました。
私はエンジニアリングリーダーなので、サービスオーナーやオンコールエンジニアのように細かいアラートを必要としません。アラートのサブセットをフォローするのは、警告なしにリストがすぐに古くなるため実用的ではありません 私たちはPagerDutyを使用していますが、私が常にオンコールのエスカレーションパスにいるとは限りません 私はSignalFxのステータスページのようなソースを見ることでマイナーな問題をフィルターすることができますが、その代りにインシデント対応に積極的に関わりたくても、アラートが届くのが遅すぎて気付くのが問題が大きくなった後だったということになりかねない
では、他にどのようなシグナルを検出できるでしょうか？ 我々SignalFxは#outageという名前のインシデントについてのSlackのチャンネルを作っていました。また、このチャネルは、PagerDutyから重要なアラート通知を受け取って、議論の内容を保存します。運用してみると、重大な問題には多くのユーザーがSlackでコラボレーションし、PagerDutyを介してエスカレーションしているという事実を知ったので、私は#outageで人間の活動に関するメトリクスを収集することにしました。結果は次のようになりました。
私はAWS Lambdaセットを使ってメッセージを照会し分類し（例えば人間かボットか）、それをSignalFxに公開しました。次に、3人以上の人が#outageで5分以上タイピングしていると私に通知する検出システムを作りました。アラートはPagerDuty経由で私の電話に送信され、Slackに直接メッセージが送信されます。
進行中の潜在的な機能停止を警告する
これは驚くほどうまくいきました。誤検知が全くなくはありませんが、その数はほぼゼロになり、関心の高いインシデントは全て通知されました。興味深いことに、いくつかの潜在的なインシデントについてアクティブなアラートとしてではなく通知を受けましたが、エンジニアはいつものサービス観察の中でそれを発見していました。
ハードウェアとソフトウェアの監視は停止しない
最初は、アプリケーションとインフラのメトリクスだけを使用して「完全な」アラートが作成できないことに失望しましたが、これは素朴な期待だったかもしれません。正確なアラートを作成するにはシステム環境を理解するだけでなく、組織がどのようにインシデントに対応するかを知ることも必要です。
私の問題の解決には人間の行動を測定することで十分でしたが、今日のツールの多くが相互運用性とデータ非依存を志向していることを考えると、モニタリングに組み込む可能性のあるシグナルはたくさんあります。
インシデント管理と問題検出を統合する
リアルタイムのビジネスはリアルタイムの運用インテリジェンスを必要とし、今日のテクノロジーは従来の監視ツールで処理できる量よりもはるかに多くのデータを送信します。SignalFxは環境内の各コンポーネントからのストリーミングメトリックを収集し、数秒で分析とアラートを提供するため、問題が顧客に影響を及ぼす前にそれを見つけて解決することができます。
SignalFxとPagerDutyを使用すると、SignalFxでアラートがトリガーされたときにPagerDutyでインシデントを自動的に開くことができます。アラートに応じて異なるエスカレーションポリシーにマップし、正常に戻ったときに解決されたインシデントを自動的にマークします。
SignalFxは、組織が重要なシグナルをリアルタイムにあらゆる規模で監視するのを助け、かつてないほど迅速に革新することができるとの自信を持っています。
Arijit MukherjiはSignalFxのCTOで、システムの監視に情熱を傾けています。Facebookのメトリクスソリューション（ODS）のオリジナル開発者の一人であり、その後もFacebookのネットワーキングツール、データビジュアライゼーション、その他のインフラ監視ソフトウェアの開発を管理しました。10年以上にわたり監視の領域に重点を置いていましたが、20年以上にわたる彼の多様なキャリアは、IPテレフォニー、VoIP会議、ネットワーク仮想化にも及んでいます。
GET STARTED
本記事は米国PagerDuty社のサイトで公開されているものを日本語訳したものです。原文はこちらです。
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が日本語に訳したものです。無断複製を禁じます。原文はこちらです。
エラーを迅速に解決するための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が日本語に訳したものです。無断複製を禁じます。原文はこちらです。
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はどこに? １週間を通じて出展する場所は
ブース＃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と一緒に開催しています。PagerDutyチーム、イベントスポンサー、業界のAWSエキスパートとのカクテルやネットワーキングのためにAquaKnoxにおいでください。
現地でミーティングをしたい方に
PagerDutyがあなたの組織にできることを知るために会議を予約したり、技術的な質問をしたり、製品のデモを見ることができます。PagerDutyがリアルタイムのデジタルオペレーションを通じてより良いビジネスパフォーマンスを後押しする方法を学べます。
Twitterの@pagerdutyをフォローして、我々のニュースとAWS re：Inventからの更新情報を追ってください。ラスベガスでお会いましょう！
（注：残念ながらDigital StacksはAWS re:Inventには出展しません。）
GET STARTED
本記事は米国PagerDuty社のサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。
Business Insiderの記事でPagerDutyが取り上げられています
Business Insiderの記事「 2018年、ユニコーンになった米テック企業35社 」でPagerDutyが取り上げられています。こちらをご覧ください。
“2018年、ユニコーンになった米テック企業35社” (November 14, 2018)
オーバーライド：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が日本語に訳したものです。無断複製を禁じます。原文はこちらです。
2018のPagerDuty Summit Awardsの受賞者を発表
毎年開催されるSummitカンファレンスの最終日に、共同設立者でCTO Alex Solomonが2018 PagerDuty Summit Awardsの受賞者を発表しました。 これらの賞は、最高の顧客とパートナーをいくつかのカテゴリーに分けて表彰し、PagerDutyプラットフォームを活用した独自のユースケース、緊密なコラボレーション、およびビジネスへのインパクトを認めるものです。
今年の受賞者は次の方々です。
Community Champion Award winner： Simon Fiddaman 氏 Simon Fiddaman氏はeBayのeCG NOCのSiteOpsマネージャーで、 PagerDutyコミュニティのアクティブメンバーです。Simonはコミュニティを充実させ、メンターを募集し、他のメンバーとの交流を深める新しい投稿とコンテンツを生み出しています。 International Customer of the Year Award winner： Xero （代表者はサイト信頼性エンジニアAbdullah Siddiqui氏） この賞はPagerDutyのグローバル展開に不可欠な役割を果たした国際的な顧客を表彰するものです。Xeroは会計士や簿記担当者向けのニュージーランドベースのクラウド会計ソフトウェアプラットフォームです。 同社はPagerDutyを使用してインシデント対応プロセスを改善し、APIを活用してChatOpsツールMultivacを構築しています。 Impact Award winner： SightLife （代表者はドナー・オペレーションディレクターのAustin Nagasako氏） この賞は、PagerDutyを使用して、社会的または環境的に重大な課題に効率的かつ効果的に対処するための非営利団体を表彰するものです。SightLifeは、2040年までに世界中の角膜の病気による失明をなくすために取り組んでいる非営利団体です。PagerDutyを使用して、SightLifeは寄付された角膜を回収するための回復プロセスを加速し、世界中で利用可能な角膜の数を増やしました。 Customer Experience Award winner： ING Australia この賞はPagerDutyの能力を使用して、記憶に残る世界でも一流のカスタマーエクスペリエンスを提供している顧客に与えられます。 Nielsen Consumer and Media Viewのオーストラリア版で最も推奨された銀行であるING Australiaは、監視プロセスを自動化し、顧客の影響を受ける前にインシデントを効率的に解決するため機械学習を活用しています。 Innovation Partner of the Year Award winner： SignalFx （代表者はCTOのArijit Mukherji 氏） SignalFXは、クラウドの監視および分析プラットフォームです。 この賞は、PagerDutyとの共通の顧客の成功を実現した有望な革新者を称えるものであり、SignalFxソリューションは PagerDutyプラットフォームの機能を拡張し、共通の顧客に大きな価値を提供しています。 Alliance Partner of the Year Award winner： AWS （代表者はパートナーエコシステムのグローバルヘッドのAina Khimani氏） この賞は、PagerDutyとの共通の顧客との優れたコラボレーションと成功を実現し、パートナーシップの成長と強化を続けているパートナーを表彰するものです。 現在までに、2600社を超えるお客様がAWS CloudWatchでPagerDutyを使用しています。 さらに、7月中旬にPagerDutyがAWS Marketplaceで発売されたため、既にMarketplaceを通じてPagerDutyに加入している顧客もいます。
Summit Award受賞者全員にもう一度、おめでとうございます！ PagerDutyは、お客様やパートナーのサポートなしには何の意味もありません。私たちは、あなたがたが当社の製品やあらゆることにしてくださった貢献に感謝しています。 私たちと働き、革新し、成長してくれてありがとう！
本記事は米国PagerDuty社のサイトで公開されているものを日本語訳したものです。原文はこちらです。
PagerDuty、Atlassianユーザーのためのデジタルオペレーションを推進
IT Operations、DevOps、およびDeveloperチームは、PagerDutyの300以上の統合を利用して、どのツールスタックを使用していても、エンドツーエンドのリアルタイムデジタル操作を強化します。 PagerDutyの顧客はすべての規模、業界、およびデジタルでの成熟に対応しているため、通信、APM、ITサービス管理（ITSM）などのニーズにどのツールを使用しているかについて常にお客様にお聞きしています。
今年の初めに、PagerDutyはITSMソリューションとしてServiceNowを活用しているチームのための新しい統合を開始しました。 Atlassian Suiteとの包括的な統合を開始することができ、AtlassianユーザーはPagerDutyのリアルタイムデジタルオペレーションの機能を日常業務に追加することができます。
今月（2018年9月）のバルセロナでのAtlassianサミットでは、PagerDutyチームは共通のお客様のうち3000人を超える方々と交流する機会を得ました。 Atlassian Suiteの最新のプラットフォームとのインテグレーションは、お客様からのフィードバックを共有した結果として構築されたものです。Atlassian Summitは、これらを発表するのに理想的な場所でした。 PagerDutyとAtlassianは、Jira Software、Jira Service Desk、Jira Ops、およびBitbucketの双方向インテグレーションの新しいセットを組み込むように、 パートナーシップを拡大して深めました。これによりチームはリアルタイムでアクションとコラボレーションを行うことができます。 さらに、PagerDutyのイベントインテリジェンス機能は、デジタル信号と人間の反応行動の両方を組み合わせて、Jiraにさらに深いコンテキストを提供し、Atlassianユーザーの生産性を向上させます。
Atlassianユーザーは、すでにJira SoftwareやJira Service Deskなどのようなシンプルな製品を使うのが大好きです。これらの新しいインテグレーションにより、よりスマートで効率的に作業することがさらに容易になりました。 PagerDutyは、Atlassianユーザーが本物のリアルタイムオペレーションを自分たちのデジタルでの仕事に活用できるようにし、さらにAtlassian Suiteだけでは本来は利用できない機能を追加できるようにします。
リアルタイム運用センターでできること
PagerDutyを使うと、Jira SoftwareとJira Service DeskでPagerDutyとの双方向同期で問題や重要なサービス要求を処理し、インシデント解決を加速できます。 こうした柔軟性は、お客様との会話で常に出てくるテーマでした。私たちは、この新しいレベルの機能性をお客様と共有できることを嬉しく思います。 全体として、PagerDutyのAtlassianとのインテグレーションにより、PagerDutyを使うチームは、デジタルオペレーションプロセス全体で問題の検知、対応、通信、改善をより効果的に行うことができます。 AtlassianユーザーのためのリアルタイムIT運用のハブと記録システムとしての役割を果たすことで、PagerDutyを使うチームは、Atlassian Suiteの中で好きな方法で作業することができます。クラス最高のModern Incident Response、Event Intelligence、 Analytics 、 Visibilityといった製品に対応しています。
すべての信号、より少ないノイズ
Atlassianユーザーは、PagerDutyプラットフォームが提供する300以上の監視、コラボレーション、開発、セキュリティ、およびその他のツールとのインテグレーションに期待することができます。 PagerDutyのイベントインテリジェンス製品は、Atlassianユーザーのためのゲームチェンジャーですあり、チームの効率性をさらに高めます。機械学習を利用して信号からノイズをカットし、チームの時間を節約し、あなたの組織にとって本当に大事なことに集中できるようにします。 また、Jiraとの同期を維持することで、チームの生産性が向上します。 この豊富なコンテキスト情報をAtlassian Suiteに追加することで、ユーザーはデジタルオペレーションのライフサイクル全体にわたって効率を上げることができます。
自動化されたリアルタイムOpsが可能に
データは、適切な人の手元にある場合にのみ役立ちます。 これを念頭に置いてPagerDutyプラットフォームは構築されました。新しいAtlassianのインテグレーションも例外ではありません。 PagerDuty + Atlassianを使うと、リアルタイムで、適切なコンテキストで、適切な人と交流できます。 インシデントに関するバックグラウンド情報を検索する必要はありません。それは自動で用意されます。ユーザーはPagerDutyとJiraの間で、豊かで実用的なインシデントを自動または手動で同期できます。 このような柔軟性により、チームはAtlassianのツールスタックとSlackのようなChatOpsツール全体でワークフローの統合を調整できます。
無料で試してみてください。簡単に始められます
PagerDutyとAtlassianの両方のユーザーは、それぞれのソリューションをどのように簡単に（そして素早く）始めることができるかをすでに知っています。では、私たちの統合ソリューションは他と何が違うのでしょうか？ PagerDuty + Atlassianは簡単に設定でき、製品間で同期し、ビジネスに合わせて拡張できます。チームがどこでどう働いていても適応するインテグレーションを提供することで、共通のお客様がJiraとAtlassian Suiteを合理的に利用できるようにしました。 Atlassianを試用するチームは、PagerDutyプラットフォームとの統合により、イベントインテリジェンス、300以上の監視ツールとの統合、オンコールのローテーションとスケジューリング 、冗長性のある通知の配信など、スAtlassian Suiteだけでは使えない機能を活用できます。
新しいAtlassian Suiteとのインテグレーション Jira Service Desk
Jira Service Deskの統合により、エージェントは重要な要求に対してオンコールのレスポンダーに従事し、通知することができます カスタマーサービスエージェントのビジネスコンテキストとサービスの健全性の可視化 PagerDutyのサービス要求状態、優先度、および注意事項の双方向同期 Jira Service Desk UIに表示されるサービス要求のエスカレーションに関する詳細情報
Jira Software
Jira Software（ Cloud / Server ）はPagerDuty Event Intelligence Awareなもので、デジタル信号と人間の対応行動の両方を見て、より上流のコンテキストを提供します PagerDutyからJiraにフィールドをマップする機能を含む、PagerDutyで識別された問題とインシデントの詳細をさらに詳しく提供 問題のステータス、優先順位、および注意事項に関するPagerDutyとの双方向同期 問題をエスカレートし、Jira Software内からのをオンコール中のレスポンダーを呼び出せます PagerDutyのインシデントをJiraに自動または手動で同期できます
Bitbucket
ビルドやテストの失敗に素早く対処して、パイプラインをグリーンに保つ コミットによって障害が発生した場合は、すぐにエンジニアに知らせて対応させる PagerDutyと Bitbucketとの統合の詳細
Jira Ops
自動的に、またはボタンを押すことでJiraインシデントを開く 課題（Issue）のステータスのPagerDutyとの双方向同期 問題をエスカレートし、Jira内からオンコールのレスポンダーを呼び出せる PagerDutyがJira Incidentタイムラインと統合されます PagerDutyと JiraOpsとの統合の詳細
本記事は米国PagerDuty社のサイトで公開されているものを日本語訳したものです。原文はこちらです。
PagerDuty Summitで新製品のイノベーションをチェック！
今年のPagerDuty Summitは私にとっては3度目ですが、最高のものになることを願っています！ このカンファレンスは、サンフランシスコのユニオンスクエアにあるシンボル、ウェスティンセントフランシスホテルで開催され、2日間にわたり業界のリーダーやあなたのような人々の現実のストーリーやベストプラクティスなどを紹介します。参加する人々は、デジタルトランスフォーメーションとよりスマートなリアルタイムオペレーションを推進するために、日々各組織の担当をリードしています。
テクニカル、ビジネスバリュー、製品という3つのトラックにまたがる24セッションでは、誰にとっても有益な情報があります。特に製品トラックのいくつかには素晴らしい情報があります。PagerDutyを最大限に活用する方法を学ぶことができます。 さらに重要なのはこれらの製品を構築する際にパートナーとなった実際の顧客から直接聞くことでしょう。優れたサービスとチームの幸福の両方を提供する能力の上ですでに達成した、数字の裏付けのある利点を共有してくれるからです。
ここでは、製品トラックの中を覗いてみましょう
オペレーションのリアルタイム・ビジネスへの影響
VodafoneのデジタルIT担当責任者、Ben Connolly氏は、 PagerDutyはDevOpsや文化の変革を推進する重要なパートナーです。サミットで発表する新製品のおかげで、Benと彼のチームは、技術的な問題がデジタルサービスやビジネスパフォーマンスに及ぼす定量的な影響を直接リアルタイムで把握できるようになりました。
ビジネスの成熟度の定義と測定
今日のデジタルビジネスとITのリーダーは、人やプロセス、テクノロジーへの投資を優先させるために、業務と業績のつながりを理解する必要があります。 しかし、現実に理解している人はまれで、何を測定すべきかも分からないことがよくあります。 Castlight Healthのレジリエンスエンジニアリング担当ディレクターのCad Oakley氏は、PagerDutyの最新製品の1つが、チームが運用の成熟度を測定し、加速するための規範的な方法をどのように提供しているかを共有します。
最新のインシデント対応によるベストプラクティスの自動化
デジタルビジネスはこれまで以上にビジネスの変化に適応しており、効果的なインシデント対応はあらゆる組織にとって重要な機能となっています。 できるだけ早く問題を解決するためには、技術チームは適切な人材を即座に動員しなければなりませんが、たいていは言うほど簡単ではありません。William Hillの ITオペレーション担当ディレクターであるAlan Alderson氏は、PagerDutyがインシデント・ライフサイクルの各段階でベスト・プラクティスと自動化を適用してシグナル・アクション間の悩みを解消する方法を共有します。
HumanOps：ピークパフォーマンスの達成
ITオペレーションテレメトリーは、常にサーバー、アプリケーション、および技術サービスの健全性に重点を置いてきましたが、これらのすべての品質を実際に支えているのは、その背後にいる人々です。 当社のDigital Insightsチームは、PagerDutyのオペレーション・ヘルス・マネジメント・サービスがITオペレーションに対して、かつてない人的要因の視覚化機能をどう提供しているかを紹介します。
開発者向けPagerDuty
柔軟なAPIと開発ツールを使用してPagerDutyプラットフォームをユニークで興味深い方法で拡張していることがわかった時、私たちは非常に興奮しています。 このセッションでは、 Xeroのサイト信頼性エンジニア、Abdullah Siddiqui氏のような人々がPagerDutyの上に構築した最もクールなサードパーティツールを紹介します。 また、プラットフォームチームのプロダクトマネージャーやエンジニアと直接連絡して詳細を学ぶ機会もあります。
デベロッパーズ・トランスフォーメーション：PagerDuty Journey
信頼性は、PagerDutyで行っているすべての心臓部にあります。 しかし、継続的なアベイラビリティを提供し、迅速なイノベーションで顧客のニーズにマニアックな焦点を当て、指数関数的に拡大するスケールをサポートするために、私たちは製品の開発と運用の方法に多大な投資と変更を加えなければなりませんでした。 このセッションでは、PagerDutyのエンジニアリングヘッド、Tim Armandpourから、開発チームのベストプラクティスと洞察を分かち合うことができます。
製品に関するAMA（Ask Me Anything）
PagerDutyでは、顧客からのフィードバックを得ることが大好きです。 私たちと共有するのを待てない機能がありますか？ 将来の拡張について聞いてみたいですか？ 当社のHead of Rachel Obstlerと製品チームのさまざまなメンバーとのライブトークに参加してください。
これは3つのトラックの1つです！ 今年はSummitで学ぶべきことがたくさんあります。そして、この素晴らしいコンテンツといっしょを逃さないでください。 席を確保するために今すぐ登録してください！
本記事は米国PagerDuty社のサイトで公開されているものを日本語訳したものです。原文はこちらです。
