• ブログ
  • 製品
    • PagerDutyの製品機能
      • アラートの集約と分類
      • サービスとチームの組織
      • システム&ユーザーレポート
      • プラットフォームの拡張性
      • モバイルでのインシデント管理
      • ライブコールルーティング
      • リアルタイムコラボレーション
      • 事後検証から学び改善する
      • 多様なアラート機能
      • 簡単なスケジューリング
      • 信頼性の高い環境
      • エンタープライズレベルのセキュリティ
    • 操作画面の特徴
    • 開発者の責任
    • 部門ごとのPagerDuty活用法
    • ITの運用
    • ビデオで学ぶPagerDuty
  • 事例
  • サポート
    • FAQ
    • インテグレーションガイド
    • 日本語サポートサイト
  • 価格

  • お問い合わせ
  • Why DSC?
  • 無料トライアル
  • ブログ
  • 製品
    • PagerDutyの製品機能
      • アラートの集約と分類
      • サービスとチームの組織
      • システム&ユーザーレポート
      • プラットフォームの拡張性
      • モバイルでのインシデント管理
      • ライブコールルーティング
      • リアルタイムコラボレーション
      • 事後検証から学び改善する
      • 多様なアラート機能
      • 簡単なスケジューリング
      • 信頼性の高い環境
      • エンタープライズレベルのセキュリティ
    • 操作画面の特徴
    • 開発者の責任
    • 部門ごとのPagerDuty活用法
    • ITの運用
    • ビデオで学ぶPagerDuty
  • 事例
  • サポート
    • FAQ
    • インテグレーションガイド
    • 日本語サポートサイト
  • 価格

  • お問い合わせ
  • Why DSC?
  • 無料トライアル

PagerDuty On-Call Responder Training

  • On 2018年5月15日

このトレーニングは、インシデントの通知を受けたり対応する責任があるオンコールユーザー向けに作られています。 自分のプロフィールや通知ルールをどう設定するかをデモし、インシデントが割り当てられたらどう対応するのかをお見せし、PagerDutyのスケジューリングオーバーライドのやり方を説明します。ご質問があれば遠慮なくsupport@pagerduty.comにお送りいただくか、PagerDuty Community(https://community.pagerduty.com)で質問してみてください。(この動画はPagerDutyの日本正規代理店であるDigitalStacksが日本語のキャプションを付けたものです。オリジナルは、 https://www.youtube.com/watch?v=fLre5s2P7NQ です。)



00:01
こんにちは、PagerDutyのレスポンダー・トレーニングにようこそ

00:07
私はPagerDutyのカスタマーサクセスマネージャーのヘイリーです。

00:10
早速始めましょう!

00:14
これが今日トレーニングするトピックのリストです。

00:18
これからWebアプリをどう使うかをデモします。

00:20
まずウォークスルーとして、

00:23
あなたにインシデントがアサインされたときの対応方法と

00:25
あなたのユーザー・プロファイルを調べる方法と

00:28
通知ルールを設定する方法を紹介します。

00:31
それからスケジュールをオーバーライドする方法を紹介し、

00:33
スケジュールとレイヤーがどう働くかについても触れます。

00:35
ライトやBasicプランをお使いの場合

00:38
このトレーニングの中で説明した機能の一部は見られません。

00:43
私たちPagerDutyの担当マネージャーか

00:45
または、support@pagerduty.comまで

00:47
連絡してください。

00:49
ではPagerDutyとは何か説明します。

00:53
PagerDutyはインシデント管理のプラットフォームで

00:55
複数の監視ツールと総合することによって

00:58
オペレーション上の信頼性や即応性を向上させます。

01:00
具体的にはこれらを自動的エスカレーション、

01:03
オンコールスケジュール

01:06
他の機能や特徴で実現し、

01:09
適切にチームに通知が届くようにし、

01:11
素早く問題解決ができるように支援します。

01:16
さらにアラートやワークフローの最適化も支援し

01:19
問題が再発するのを防ぐために

01:22
知見を提供する高度な分析機能などの

01:24
機能も備えています。

01:28
それではPagerDutyはどう働くのでしょうか?

01:31
監視ツールから送信されるハイレベルなイベントが

01:33
PagerDutyのサービスに届くとインシデントを生成します。

01:36
ひとたびインシデントがトリガーされると

01:39
サービスに紐づけられたエスカレーションポリシーが

0:01:42
どのユーザーがオンコール中かを見て

01:45
インシデントを適切にアサインします。

01:49
インシデントがアサインされたら、

01:50
PagerDutyはユーザー通知のルールを参照して

01:55
そのユーザーにどんな方法で通知をするかを決めます。

01:58
さらにエスカレーションポリシーは、

02:00
一定期間、インシデントがAckされない場合には

02:03
どうエスカレートするかを判定します。

02:08
ここからはWebアプリの使い方を説明します。

02:11
ではまず私のPagerDutyデモ用アカウントに移動して、

02:13
ダッシュボードの概要を説明します。

02:19
PagerDutyにログインしたとき最初に表示されるページは

02:23
インシデントのダッシュボードです。

02:25
ここにはアカウントごとのインシデントと過去7日間の活動記録が表示されます。

02:30
上の方のメニューバーは

02:33
このWebアプリの別のセクションに案内します。

02:35
Incidentsをクリックするとインシデントダッシュボードに戻れます。

02:40
Alertをクリックするとアラートタブが表示され、監視システムからPDに入ってくるイベントが見られます。

02:51
Configurationsのドロップダウンメニューでは、Scheduled services、Escalation policies、Usersといったメニューに移動できます。ここでアカウントレベルの全てのことが設定できます。

03:05
Analyticsはあなたのアカウントのレポートのところへ移動させます。

03:11
Analyticsセクションにはサードパーティのツールから情報を埋め込めるAdd-onsも追加できます。

03:16
Command Consoleでは、インフラの健全性と

03:20
ビジネス全体の状況を調べられます。

03:22
これは追加オプションの機能です。

03:25
一番右側に行くと

03:27
My Profileがあります。

03:30
ここには連絡方法と通知のルールを設定できます。

03:34
ここからログアウトすることもできます。

03:37
そのすぐとなりにはTeamというドロップダウンメニューがあります。

03:41
Teamメニューには組織向けの機能があり、

03:43
例えば特定のチームに関するものだけに絞り込んで

03:45
コンテンツを表示させることができます。

03:48
自分のチームだけに絞り込めば

03:50
自チーム関連のインシデント、スケジュール、サービスや

03:53
他の条件だけが見られるようになります。

03:58
そのとなりのクエスチョンマークはヘルプをリクエストしたり

04:02
フィードバックを送ったりできます。

04:05
そしてリリースした最新機能の情報が見られるWhat’s Newページもあります。

04:10
続いて、この左側には

04:13
クイックインフォメーションウィジェットがあり、次のオンコールはいつか、常時オンコールの対象は何か、

04:21
今オンコール中なのは誰か、といったことと、その時にオンコールしているユーザーのエスカレーションポリシーを表示します。

04:29
一番下にはリソースボックスがあります。

04:34
これは我々のナレッジベースの関連記事とつながっています。

04:37
このウィジェットはほぼ全ページに表示されます。

04:39
何を表示させているかによって関連するトピックにつながるようにリンクが変化します。

04:46
また、Chat with supportというリンクがあり、

04:50
何か質問がある場合、私たちのサポートエンジニアと直接チャットできます。

04:56
インシデントダッシュボード全体を紹介しました。

05:01
次は、インシデントがあなたに割り当てられた場合に、どう対応するかをお話します。

05:07
いくつかの大事な用語とあなたは実行できるアクションを見てみましょう。

05:12
最初のステップは、作業対象になっているインシデントを確認(Ack)することです。

05:18
Ackするということは、あなたがインシデントのオーナーになり、以後はエスカレートしないと全員に宣言することです。

05:25
サービスレベルに確認期間の対応期限が設定されている場合もあります。あるサービスでインシデントがその期限を超えても確認状態のままの場合、トリガー状態に戻されます。

05:38
対応にもっと時間がかかりそうだと分かっていれば、一定時間インシデントをスヌーズするオプションもあります。

05:45
他の支援が必要だったり別のチームに所属している人に頼りたいときは、他の担当者を再割り当てまたは追加するエスカレートのオプションも用意されています。

05:56
そうして最後に問題が解決されれば、PagerDuty内では解決になります。

06:01
ではWebアプリの中で実際にどうやって以上のアクションを実行するかをお見せします。

06:07
まず、私のデモアカウントに戻って手動でインシデントを引き起こします。

06:12
一般的、インテグレーションによってインシデントが自動的にトリガされることがよくありますが、

06:18
手動でトリガすることはできません。

06:22
この右上の隅から、+New Incidentをクリックして、

06:27
サービスを選択します。

06:29
DevOps Seviceを選ぶと、

06:31
それはエスカレーションポリシーを自動的に関連付けます。

06:33
私は次に、サーバーが火を噴いてる、とタイトルに記入して

06:41
詳細に、Please Help ASAP(すぐ助けて)、と記入します。

06:45
Incidentをクリックすると、

06:48
インシデントの詳細ページが開きます。

06:51
ここでは、もっと詳しい情報が見られるので

06:53
何が起きているのかについて、もう少しコンテキストを取得できます。

06:56
インシデントは現在トリガー状態になっています。

06:59
つまりインシデントはアサインされたのですが

07:01
まだ確認しているユーザーがいないこと、

07:04
または、誰もオーナーになっていないという意味です。

07:06
今はTrishがアサインされていると分かります。

07:08
なぜなら、彼女はエスカレーションポリシーのためオンコールになっているからです。

07:14
このサービスの設定ではインシデントの緊急度は高く設定されています。

07:20
高緊急度設定されたサービスは、クリティカルなインシデントのためのものなので

07:25
すぐに手当てすることが必要です。

07:28
担当の一人として、高緊急度の通知ルールに従ってあなたに通知されます。

07:34
サービスの緊急度は低にも設定できます。

07:37
それによって別の通知ルールが適用されます。

07:39
計画に合わせて時間によって緊急度を変更することもできます。

07:51
保留のまま30分以内にインシデントがAckされない場合にはエスカレートされます。

07:53
これがエスカレーションタイムアウト時間で、

07:55
管理者がエスカレーションポリシーに設定します。

08:00
ではインシデントをAckしてみましょう。

08:03
例えば私がオーナーになるとします。

08:07
つまりそのインシデントがさらにエスカレートされないようにAckするということです。

08:12
そのため、Acknowledgeボタンをクリックしたら、

08:15
Snoozeが表示されます。

08:19
ユーザーのPending Actionのところに、

08:21
Returns to triggered stateという表示と

08:24
re-notifies in 30 minutesという表示が見えます。

08:27
それがAckタイムアウト期間で、

08:30
サービスレベルで設定変更できます。

08:33
もっと時間が必要だと分かっているなら、

08:35
ここでスヌーズを設定し、

08:37
1時間、4時間、8時間、24時間といった単位で延長したり

08:42
otherをクリックして好きな時間の単位や

08:46
翌日の好きな時間に設定できます。

08:50
この下のタブにはDetailがあり、

08:54
そこではタイトルやデスクリプションなどのより詳しい情報が見られます。

08:59
Reponseタブをクリックすると、

09:01
Reassignオプションがあります。

09:04
インシデントのオーナーシップを誰かに割り当てたいときは

09:09
クリックしてほかのレベルまたは同じエスカレーションポリシーに再割り当てできます。
09:18
誰がオーナーになるべきか分かっている場合は、そのユーザーに割り当てることもできます。

09:26
ここではキャンセルをして先に進みます。

09:29
自分がオーナーを引き続いて、追加の援助だけが必要な場合、レスポンダーを追加できます

09:35
選べるのはエスカレーションポリシーか、誰がインシデントに対応しているかをあなたが知っているそのユーザーです。

09:44
次に私はエスカレーションポリシーにCore Teamを選び、

09:48
ユーザーにAndrewを選択します。

09:51
そして、Add responderをクリックします。

09:55
もし、必要だったら、コンファレンスブリッジも追加できます。

09:59
今はCore TeamやAndrewだけを追加して、Add respondersをクリックします。

10:05
さて、スクロールダウンして見ると、相変わらずインシデントは私にアサインされていますが

10:09
レスポンダーTrishが Core Teamとオンコールになっていることが見えます。

10:14
そして、Andrewには先ほど支援を直接要求しました。

10:20
それぞれの隣に、クエスチョンマークがあり、Pendingという言葉が見えます。

10:23
誰かがレスポンダーとして追加された時、通知がもらえ、

10:28
受け付けまたは拒否できます。

10:31
誰かが対応していればここに反映されます。

10:35
彼らの反応によって、小さいチェックマークまたはXマークが表示されます。

10:42
このページから、ノートを追加することもできます。これは後、タイムラインにもポップアップされます。

10:48
Subscriberタブでは、閲覧者を追加できます。

10:52
それは、一般的にビジネスの利害関係者やマネジャーのような

10:57
インシデントに関する仕事は担当しないが、成長のために最新情報を常に知りたいというユーザーが多いです

11:05
ここで、ユーザーやチームを追加できます。

11:10
私からのヒントですが、このTeamの下に私はManagerというチームを作っています。

11:16
そして、私のマネージャー全員をそのチームに入れてます。

11:19
マネージャーのグループを作っておきたいときはマネージャーをクリックすればよいのです

11:26
私のマネージャーチームには6人いて

11:31
全員閲覧者として追加しています。

11:33
私はここにステータスを書いて彼らに私が今何をしているかを知らせられます。

11:38
あなたが特定の行動をしている時には、彼らはここに掲示されている状態更新通知を受け取れるようになります。

11:48
最後に見えるタブは、Timelineです。

11:50
これはどのような行動が取られ、何が起こっているのかをよく知りたい場合には最適な場所です。

11:57
ここには最初にトリガーされた時から、最近実行されたアクションまで表示されています。

12:04
つまり、Webアプリケーション経由でインシデントに対応するためのものです。

12:09
インシデントは、設定する方法に応じて、統合によって解決される可能性がありますし、

12:18
解決する前に自動的に解決することもできます。

12:21
このResolveをクリックすると、ステータスがResolveに変化しするのが見えます。

12:29
それから、インシデントが解決されたら、それはもう二度と開けないことに注意してください。

12:35
続いて、SMSテキストメッセージによる電話とモバイルアプリからの応答についてお話したいと思います。

12:49
SMSテキスト通知を設定すると、インシデントに応答コードで応答することができます。

12:55
この例では、確認は4、エスカレートするには8、解決するために6に返信します。

13:04
レスポンスコードは変わるので、毎回正しい番号を入力していることを確認してください。

13:12
電話で通知された場合は、応答コードで応答することもできます。応答コードは自動音声で読み上げられます。

13:20
コールに一度応答すると、サービス名とサービスの説明がトリガされたインシデントの数が音声録音されます。

13:30
コールの応答コードは変更されません。

13:34
そのため、解決するために6、エスカレートするには8のままです。

13:40
よく使われる対応手段はモバイルアプリです。

13:46
アプリはiOSとAndroidの両方でダウンロードできます。

13:50
プッシュ通知が設定されている場合は、

13:54
インシデントがアサインされたときに、デバイスのロック画面で通知を受け取ります。

14:00
そこから、モバイルアプリで閲覧するためにViewをクリックすることができます。

14:04
すると確認、リアサイン、レスポンダーの追加、ノートの追加といった全操作をモバイルアプリから操作できます。

14:12
ここまでは、通知にどのように対応するかについて話しました。

14:17
これからは、実際にこれらの通知を受信できるようにあなたのプロファイルを正しく設定する方法を確認します

14:23
つまりユーザープロフィールの管理についてさらにお話します。

14:26
ではPagerDutyのデモ用アカウントに戻って、どう設定しているいるかをお見せします。

14:34
右上隅の、My Profileをクリックします。

14:43
My Profileの最初のタブはContact Informationです

14:48
これは、プッシュ通知用の電話番号とSMSテキスト番号、電子メールとデバイスの情報を設定する場所です。

14:56
プッシュ通知の場合、モバイルアプリをダウンロードしてログインしたら、デバイスがRegistered(登録済み)と表示されます。

15:04
これがデバイスに表示させる方法です。

15:09
それ以外にWebアプリには、電話番号のテキストやメールを追加できます。

15:16
連絡方法は合計10件まで持てます。

15:19
ですから、電話番号が3つ、テキストメッセージ番号が3つ、電子メール3つがある場合、あと1つのデバイスしか持てないことになります。

15:30
Tipですが、以前に通知を受け取ったことがない場合は、番号または電子メールを追加して小さなテストボタンをクリックしてください。

15:39
実際に電話やテキストメッセージを送ることができ、実際のインシデントの通知の受信を始めるとどうなるかを見せてくれます。

15:50
このページでは過去14日間のあなたの活動も見ることができます。
My on call scheduel や My Teamのような個人向けのウィジェットがいくつかあります。

16:05
次のタブはNotification ruleです。

16:11
ここではさまざまなシナリオでどのように連絡を取るかを管理できます。

16:16
例えば、when someone adds me as a responder(誰かがあなたをレスポンダとして追加した時)

16:20
when a high urgency incident is assigned to me(緊急性が高いインシデントがあなたにアサインされた時)

16:23
when one of my high-urgency incident change(あなたの緊急性の高いインシデントの一つが変わった時)

16:26
and then when a low urgency incident is assigned to me(緊急性の低いインシデントがあなたにアサインされた時)

16:29
そして、最後は Before I go on or off call (オンコール前や対応後)などです。

16:32
ここにはさまざまな設定を入れられます。

16:37
その中で、最も重要なのは緊急性の高いインシデントの設定です。

16:40
なぜなら、それはクリティカルで、即応する必要があるからです。

16:45
ベストプラクティスとしてこれらの通知はうるさいほど目立つようにし、昼夜問わず注意を喚起するようにすべきです。

16:54
このため、複数のルールに少なくとも1つは電話を設定することをお勧めします。

17:00
そして誰も確認していない場合は繰り返し通知されるようにしておきます。

17:05
この例では、私はすぐにメールと電話、そしてSMSテキストメッセージでプッシュ通知を受け取っていることがわかります。

17:16
もし私が1分後に確認応答をしなかった場合は、2分後にもう一度電話をかけ、再びSMSテキストメッセージを送信します。

17:26
そして3分後にまだ確認にならなければ、私は別のプッシュ通知を受け取るようになります。

17:31
注意を引くのが必要なときにはいつでも起こすようにするとか、あなたにとって意味のあるルールを何でも、必要だと思う分だけ、追加できます。

17:39
他との兼ね合いを見て削除したり編集したりすることができます。

17:47
もう一つは、緊急性の低いインシデントがあなたにアサインされた時です。

17:52
こういうインシデントは必ずしも深夜にあなたをたたき起こす必要はありません。

17:56
Low-urgencyとは、朝まで待って対処すればよい、という意味です。

17:59
だから、このためには電子メールを設定するだけでいいでしょう。

18:03
次に、before I go on or off callですが、これは自分のシフトを忘れないようにするために大変役立ちます。

18:10
例えばコンピューターを持っていくことを忘れないように、オンコールの4時間前にプッシュ通知を送るという設定もできます。

18:18
あるいは、オンコールが終わる1時間前に自分にそれを知らせるようにし、もうすぐシフトが終わるんだ、といい気分になれるよう設定することもできます。

18:25
これは電子メール、プッシュまたはSMSのどれでも設定できますので、設定することをお勧めします。

18:31
では、User settingsについて説明したいと思います。

18:36
ここは、あなたの電子メールパスワードを更新できる場所です。

18:40
オンコールスケジュールのカレンダーを個人カレンダーにエクスポートすることもできます。

18:45
2つのオプションがありますが、Web Cal feedがお勧めです。

18:50
即座にカレンダーを更新できますし、iCalendarも使えるからです。

18:55
一方これは1度で丸ごとインポートするので、エクスポートした後のスケジュールの変更は、自動的には反映されません

19:04
以上プロファイルについて話しました。

19:10
今から、スケジュールのオバーライドについて説明します。

19:13
誰かの病気や休暇中に何かが起きて、そのシフトをカバーする必要がある場合にするのがスケジューリングオーバーライドです。

19:20
私のPagerDutyカウントで実演してみます。

19:24
Configuration scheduleを選んで、スケジュールに移動することもできますが

19:28
My Profileにいるので、オンコールスケジュールウィジェットで移動してみましょう。

19:33
そして、Relevant Schedule(関連スケジュール)をクリックします。

19:37
さて、今スケジュールが見えました。

19:42
例えば、私の月曜日のシフトを誰かにカバーして欲しいとします。

19:51
そこで、私の名前をクリックして、Schedule overrideをクリックします。

19:56
Alexにカバーを頼んであって彼が私のシフトを受け取ることに同意していたら

20:03
彼の名前を追加して、私のシフトをクリックし

20:08
時刻のデフォルトをフルシフトのリンクにセットして、アップデートしなくて済むようにします。

20:14
その後、Create overrideをクリックします。

20:18
すると、先のAlexのオバーライドレイヤーが私のシフトをカバーしたことが見えます。

20:22
常に最新スケジュールを見て、あなたがもうオンコールになっていないことを確認し、新しいユーザーがその最新スケジュールでオンコールになっていることを確認することが重要です。

20:34
さらに、誰かのために自分をオーバーライドにすることもできます。

20:40
私がAndrewのシフトをオバーライドするとしたら、私の名前がAndrewのシフトをカバーすることになります。

20:48
それらをクリックして、既存のものを修正したり、オーバーライドがもう要らない場合キャンセルしたりすることができます。

20:57
Schedule overrideボタンをクリックして現在のシフトのスタートとエンドの時刻をデフォルトにすることもできます。

21:04
ただし、その時刻を更新する必要があるかもしれません。

21:09
これでスケジュールオーバーライドの説明を終わります。

21:14
次に話したいのはスケジュールやレイヤーのことです。

21:19
PagerDutyのスケジュール設定では、レイヤーをさまざまなシフトとして考える、レイヤーの概念があります。

21:27
最新のスケジュールを組むために複数のレイヤーがまとめられ、スケジュール内のある時刻の一点では、誰か1人だけがオンコールになれます。

21:37
注意すべき大事な点は、一番下のレイヤーが常に優先されるということです。

21:42
この例では、誰かをオンコールにしてあり、レイヤー1と2と3が日曜日の同じ点にしてあります。

21:52
この場合は、レイヤー3が一番下にあり、各レイヤーのどれかがオーバーラップした場合は、一番下のレイヤーが優先されるわけです。

22:01
先ほど、常に最新のスケジュールを確認することが大事だと私は言いました。その理由はここにあります。

22:06
よく見ると、ユーザーとレイヤー3にGuntherという名前があって、1日中オンコールになっています。

22:12
つまりユーザーとレイヤー1、2は関係なく一番下のレイヤー3のユーザーだけが重要なのです。

22:20
繰り返しますが、オーバーラップしている場合は最下層のレイヤーが優先されるのです。

22:26
トレーニングはここまでです。それではご自分でやってみてください。

22:36
まだログインしていない場合は、まずログインしてユーザープロファイルを設定することをお勧めします。その後に、あなたの連絡方法がリストされていることを確認し、通知ルールを設定してください。

22:47
ダウンロード可能なvCardをご用意していますので、PagerDutyの連絡先番号を控えていただくよう強く推奨します。

22:54
あなたが私たちからの通知を受け取ると、それがPagerDutyの通知だと分かります。

23:00
support@pagerduty.comのサポートセンターでこのvCardを見つけられます。

23:06
そうすれば、今日レビューした通りに、通知を受け取ってインシデント対応できるようになります。

23:14
ご質問がありましたら、遠慮なくお問い合わせください。

23:20
support@pagerduty.comまでお問い合わせください。ご連絡を心よりお待ちしております。

23:26
ご質問があれば、喜んでお答えします。

23:30
ご視聴ありがとうございました。素晴らしい日になりますように

0 Comments

Recent Posts
  • Japan IT Week 春 出展報告 2022年4月19日
  • PagerDutyをJapan IT Week 春に出展します 2022年3月21日
  • インシデントフローと対応の省力化を実現するPagerDuty&Rundeckを出展~Japan IT Week 秋 2021年11月10日
  • システム運用を強力に支援するPagerDutyとRundeckをJapan IT Week秋に出展 2021年10月25日
  • DevOpsのROIを測定する方法 2021年8月23日
  • 8/25 CEDEC 2021でCI/CDツールHarnessとインシデント管理ツールPagerDutyの活用例を紹介 2021年8月20日
  • PagerDuty Summit 2021の概要 Part 2 2021年7月12日
  • PagerDuty Summit 2021の概要 Part1 2021年7月2日
  • 6月23日-25日 PagerDuty Summit 2021 バーチャル開催のご案内 2021年5月20日
  • DevOpsを高速化するための6つのステップ 2020年10月15日
Product Tags
AWS Blog DevOps News Post Mortem SecOps signalfx Slack SRE インシデント インテグレーション オンコール・スケジュール オンコール管理 スケジューリング ステークホルダー ビジネス関係者 モニタリング モバイル リリース 事後検証 導入事例Video 更新 製品アップデート

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

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

Scroll
会社情報

株式会社Digital Stacks

〒141-0001

東京都品川区北品川5-5-15

大崎ブライトコア 4F SHIP 414


  • Home
  • 製品情報
    • PagerDutyの製品機能
    • 操作画面の特徴
    • 開発者の責任
    • 部門ごとのPagerDuty活用法
    • ITの運用
    • ビデオで学ぶPagerDuty
  • サポート
    • FAQ
    • インテグレーションガイド
    • 日本語サポートサイト
  • DSCが選ばれるポイント
  • 価格
  • お知らせ
    • お知らせ一覧
      • 更新情報
      • メディア掲載情報
      • 受賞情報
  • 更新情報
  • PagerDutyの製品機能
    • アラートの集約と分類
    • サービスとチームの組織
    • システム&ユーザーレポート
    • プラットフォームの拡張性
    • モバイルでのインシデント管理
    • ライブコールルーティング
    • リアルタイムコラボレーション
    • 事後検証から学び改善する
    • 信頼性の高い環境
    • 多様なアラート機能
    • 簡単なスケジューリング
    • エンタープライズレベルのセキュリティ
  • PagerDuty導入事例
    • 導入事例インタビュー:株式会社ミクシィ
    • 導入事例インタビュー:イーサポートリンク株式会社 
    • 導入事例インタビュー:株式会社いい生活
    • 導入事例インタビュー:株式会社Jストリーム
    • 導入事例インタビュー:SmartNews 尾形暢俊氏
    • 導入事例:IBM Cloud
    • 導入事例:IBM Smarter Workforce
    • 導入事例:GREE
    • 導入事例:Panasonic
    • 導入事例:Evernote
    • 導入事例:Backcountry
    • 導入事例:Groupon
    • 導入事例:SendGrid
    • 導入事例:Brightcove
    • 導入事例:Code.org
    • 導入事例:インディアナ大学
    • 導入事例:Signal Sciences
更新情報
  • Japan IT Week 春 出展報告 2022年4月19日
  • PagerDutyをJapan IT Week 春に出展します 2022年3月21日
  • インシデントフローと対応の省力化を実現するPagerDuty&Rundeckを出展~Japan IT Week 秋 2021年11月10日
  • システム運用を強力に支援するPagerDutyとRundeckをJapan IT Week秋に出展 2021年10月25日
  • DevOpsのROIを測定する方法 2021年8月23日
  • 8/25 CEDEC 2021でCI/CDツールHarnessとインシデント管理ツールPagerDutyの活用例を紹介 2021年8月20日
  • PagerDuty Summit 2021の概要 Part 2 2021年7月12日
  • PagerDuty Summit 2021の概要 Part1 2021年7月2日
  • 6月23日-25日 PagerDuty Summit 2021 バーチャル開催のご案内 2021年5月20日
  • DevOpsを高速化するための6つのステップ 2020年10月15日
Copyright © Digital Stacks Corporation. All Rights Reserved.
  • 無料トライアルを申し込む
  • お問い合わせ
  • 販売会社情報
  • 個人情報保護方針
  • サイト利用規約