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が日本語に訳したものです。無断複製を禁じます。原文はこちらです。
ベストプラクティス
オペレーションの未熟さがコストを増大させる
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が和訳・追記したものです。無断複製を禁じます。原文はこちらにあります。
ベストプラクティス
リアル（タイム）になりつつある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が日本語に訳したものです。無断複製を禁じます。原文はこちらです。
インテグレーション＆ガイド
アラート対応疲れを減らすために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社のサイトで公開されているものを日本語訳したものです。原文はこちらです。
Summit 2018の事例紹介トラックに登場する顧客企業について
ソリューションと顧客マーケティング担当ディレクターである私の一番の仕事は、世界中の熱心なPagerDutyの顧客全員と会うことです。 PagerDutyがどのようにしてより俊敏で、より顧客中心の、より革新的なものになったのかなどに関する彼らの話は、本当に感動的です！
そのために、 Summit 2018では、顧客がユニークで創造的な方法で組織内でPagerDutyをどう使ったかを紹介する一般向けのトラックがあります。 Summit 2018は皆のために、あなたがスタートアップや大企業、ハイテク業界や他の業界で働いていても、何かが得られることを保証します！ 登場するお客様を紹介します。
American Eagle
あなたが町で見かけるキュートな服は、衣類やアクセサリーを専門とするアメリカのオムニコマース企業であるAmerican Eagle Outfitters（AEO）のものである可能性があります。 新学期からホリディシーズンまで、カレンダーのQ4はAEOの最も忙しい時間です。Matt Kundrat氏のチームは、販売チャネルをサポートするすべてのアプリケーションが週７日で24時間いつでも利用できるようにする責任があります。Mattが説明してくれるのは、AEOがワークライフバランスを維持しながらピークシーズンにどう対応しているか、ということで、そう、維持できるんです！
FanDuel
あなたがデイリーのファンタジースポーツが好きなら、FanDuelが向いています。 同社のサイトでゲームが進行中にログインすると、トーナメントに参加したり、他のコンテストに参加したりすることができます。ただし、それはWebサイトやアプリが稼働している場合だけです。 そうでないときは、FanDuelサポートチームがこれについて確実に把握します！ しかし、テクニカルチームが5つのタイムゾーンに離れている場合、サポートチームは各テクニカルチームに顧客対応の問題をどうに通知したらよいでしょうか？ Business Operations ManagerのLuke Kanter氏がその方法をシェアします。
Fitch Group
Fitch Groupは金融情報サービスの世界的リーダーであり、中でも著名な信用格付け機関であるFitch Ratingsはよく知られています。 そのため、迅速なイノベーションは同グループの競争上の差別化要因です。 しかし、同社は機密性の高いデータを扱うため、強力なセキュリティとのバランスを取る必要があります。 Director of IT Product Development and Head of DevOpsであるMir Ali氏は、Fitch GroupのDevSecOpsの流れについて、背景から主な学習とベストプラクティスまでを通して説明します。
Funding Circle
Funding Circleは、ピアツーピアレンディング（融資）のリーダーとして、投資家から50億ドル以上を調達して中小企業に融資しています。 これをできるだけ簡単にすることが同社の最優先事項であり、同社のエンジニアチームが革新を継続的に提供できるようにするのが、Paul Whyte氏の責務です。Funding CircleがPagerDutyを活用して、ソフトウェアの品質とパフォーマンス、ビジネスの重要な指標を真に理解しているその方法を、聞きましょう。
GE Digital
多くの人は、フィットネス-トラッカー、スマートサーモスタット、Alexaのおかげで、Internet of Things（IoT）に精通するようになりました。 しかし、産業用IoTの規模は、特に製造業や重工業にとって、さらに大きくなることが約束されています。 GE Digitalは、産業用インターネット向けのデジタルトランスフォーメーションに役立つエンジンです。Cloud Architecture and Automation LeaderのBen Hwang氏から同社のアプローチとPagerDutyが組織内でどうに使用されているかについての講演を聞きましょう。
Good Eggs
あなたが私のような人なら、スーパーマーケットに走るのと並んで待つのが嫌でしょう。Good Eggsのおかげで、これはもう不要です。 同社は、あなたの食べ物が適切な温度に保たれるように特別な冷蔵配送トラックを使用して、生鮮食料品を戸口まで届けます。 新鮮さはミッションクリティカルなので、Good Eggsはトラックの冷蔵庫が常に動作するようにする必要があります。PagerDutyはその監視を支援するために使われています。 センサー、トラック、PagerDutyの詳細については、Good EggsのAssistant Director of OperationsのTannia Hernandez氏と、Facility Manager であるJJ Mayoraの講演をお聞きください。
まさにすごいラインアップですね？ これはPagerDuty Summit 2018のトラックの１つです！ 今年のサミットでは3つのトラックで20回以上のセッションが行われ、いくつかの新しい思考を促す基調講演者も登壇します。 私はアジェンダや数日間のコースで共有される優れた学習方法やベストプラクティスについてとても楽しみにしています！ では、 あなたも席を予約するため今すぐ登録してください！
本記事は米国PagerDuty社のサイトで公開されているものを日本語訳したものです。原文はこちらです。
PagerDutyがお届けする今年夏の新機能
2018年はPagerDutyにとって極めて重要な一年でした。 過去6ヶ月間にわたり、私たちは多くのPagerDutyの新機能の開発を加速し、デジタルオペレーション管理プラットフォームとモバイルアプリケーションのさまざまなアップデートと拡張をリリースしました。
これらの機能により、各組織は、レスポンス体制の編成と継続的な開発と配信をさらに最適化できます。開発者、運用チーム、DevOpsの実践者、および管理者が、コンテキストの洞察とインタラクティブなアプリケーションを通じて、カスタマーエクスペリエンスのあらゆる側面を視覚化できるようになります。
(訳注：下記の新機能の機能名は英文が正式名称です。和文の名称はDigitalStackが仮に訳したもので、正式ではありません。)
新機能のリリース
イベントインテリジェンスのリリース
最新の製品であるイベントインテリジェンス（Event Intelligence）は、デジタルシグナルと人間の対応行動の両方を組み込み、機械と人間のテレメトリーを組み合わせて、デジタルオペレーションを最適化します。自動適応学習アルゴリズムは、ノイズを削減し、チームがイノベーションと生産性向上に容易に集中できるようにします。 統合されたイベントインテリジェンスとインシデント対応により、誰もが同じ情報に接し、問題をより迅速に解決するために必要なコンテキストが確保されます。 ルーティングとワークフローの自動化、インテリジェントなアラート相関分析、ノイズ抑制、類似インシデントの憑依、API、およびプログラマビリティが連携して、レスポンダーが必要とする正確なマシンと人間のコンテキスト情報を提供します。
イベントルール（Event Rules) 、PagerDutyのルーティングとワークフローの自動化機能は、200以上のツールから大量のイベントデータをプログラムで管理するのに役立ちます。 イベントデータ、問題の重大度、サポート時間などに基づいて、ルーティング、抑制、通知、およびその他の動作をインテリジェントに自動化できます。
インテリジェントアラートグルーピング（Intelligent Alert Grouping）により、重要なコンテキストを集中しながらノイズを削減し、適応的機械学習とルールベースのアプローチによって、複雑なシステムにわたる関連する着信アラートを自動的にグループ化して１つのインシデントすることで、トリアージをスピードアップします。
類似インシデント（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社のサイトで公開されているものを日本語訳したものです。原文はこちらです。
LGBTQ＋グループ向けのPagerDuty Summit参加プログラム
私たちは、PagerDutyのインクルーシブな企業文化を非常に誇りに思っています。 それは当初から私たちがビジネスのコアに置いている価値であり、多様なチームを持つことはより多くのイノベーションにつながることを実地で知っています。
今後のPagerDuty Summit 2018を含めて、私たちの活動がすべて同じインクルージョンの精神を背景としていることを確認したいと思います！ PagerDuty Summitは、ベストプラクティスを学び、実践的なトレーニングを受け、業界のリーダーからDevOpsの未来を聞く場所です。 私たちの目標はこのサミットを、すべての人種、民族、性別、年齢、能力、宗教、性的指向、軍関係、背景を問わず、最もインクルーシブなサミットにすることです。
私たちは、今年のサミットへ技術に触れる機会があまりない人たちのための無料パスを100枚予約しました。 そうです、この2日間の全カンファレンスで、私たちのセッションやイベントにすべて無料で入れます – 無料です！
応募するには、 このフォームに必要事項を記入して提出してください （注：英文です）。
Summit Details：
2018年9月11-12日
ウェスティン セントフランシス、サンフランシスコ
応募適格**：
女性、有色の人々、能力の異なる人々、LGBTQ +、退役軍人/軍隊の兵役、予備軍を含み、これに限定されない、技術産業や技術コンファレンスに参加した経験があまりないグループのメンバー
ご自身で旅行や宿泊施設を予約できること
18歳以上
私たちの行動規範に同意できること
抽選は、資格基準を満たすこと、完全な書式を提出することで、先着順に行われます。 選ばれた人は、完全なフォームを提出してから8営業日以内に電子メールで通知されます。 ご関心をお寄せいただきありがとうございます。お会いできますように！
*無料パスはサミットのみで、PagerDuty Universityは含まれていません。
本記事は米国PagerDuty社のサイトで公開されているものを日本語訳したものです。原文はこちらです。
フォースの覚醒：PagerDuty + DatadogでDevSecOps
セキュリティ専門家として長年過ごしてきた私は、Datadogのような企業が、変化するセキュリティ環境にどう対応しているかに常に関心を持っています。 昔はセキュリティ組織がセキュリティの責任を完全に負っていて、ビジネスの周縁（perimeter）を保護することに重点を置いていた、ということも思い出せます。しかし、クラウド、モバイル、Webアプリケーションの出現で、周縁は消えてしまいました。 それと並行して各企業は、セキュリティとは開発チームと運用チームの中で共に責任を担い 、統合されるべきだと認識するようになっています。
それに向き合いましょう：Webアプリケーションに対する攻撃はMenace(脅威。ファントム・メナースから)となっており、毎年急速にデータ侵害が増加しています。 Rogueアクターは、インフラ、ソフトウェア、およびプロセスの弱点を悪用しています。私たちはこれに対してどのようにしてStrikes Backしますか？ New Hopeをここに…DevSecOps！
お分かりでしょうが、私は子どものころからスターウォーズの熱狂的なファンです。いつもこの話題のシリーズの新作が発表されるたびにワクワクしています。最新版は私にこの、遠く遠く離れた銀河の（原文はa galaxy far, far away ）の教訓がDevSecOpsに関して私に教えてくれたことを思い出させました。
“覚えたことは全て忘れるのじゃ” – ヨーダ
賢明なJedi Masterが言ったこの言葉を言い換えると、あなたがずっと真実だと思っていた知識のいくつかは、いつか偽に変わることもある、と言っていたはずです。DevSecOpsについて言えば、それはトランスフォームの成功を邪魔することもあります。時代遅れのツールとプロセスを使うことで、セキュリティチームが物事を停滞させる可能性があるのです。セキュリティは、組織内のセキュリティのマインドセットを変える一部として調整が必要であり、より新しいツールやプロセスがどれだけ良きパートナーになるかを知っておく必要があります。クラウドアプリケーションの監視サービスであるDatadogは、ツールとプロセスを更新する必要があると認識した企業の1つです。 そのセキュリティチームは開発部隊から学び、PagerDutyをアラートとレスポンスに使用し始めました。 PagerDuty Securityチームの一員として私は、ビジネスに自前のサービスを生かすこと（Eat Your Own Dog Food）も 自分のプラットフォームをセキュリティ業務の一環として使うこともできます。 しかし、なぜでしょうか？
“こいつはケッセルまで12パーセクで飛べた船だ！”- ハン・ソロ
PagerDutyでは、私たちは即応性と応答性を備えたモデルを志向しています。 例えば、セキュリティイベントが発生していたりリソースが準拠していないことをどれぐらい早く発見できるでしょうか？あるいは起きた問題を収めるためにどうに迅速に対応できるでしょうか？ といったことです。DevSecOps一部は、セキュリティについてスピード面でスケールする自動化された決定をすることです。 ミレニアム・ファルコンが光速で飛ぶほどは速くないかもしれませんが、迅速に対応できることは、潜在的なコスト削減とリスクの削減につながります。 スピードが要（かなめ）なんです！
すべてのリリースが100％安全で、100％稼働率を達成していると言えればよいのですが、現実にはありえません。現実では問題が起こり、どのくらい迅速に対応できるかが収益に影響します。 2017 Ponemon Cost of Data Breach Study は、インシデントレスポンスチームを組織することで、レコードあたり最高19ドル分の損失を削減できることを示しました。 適切な人にアラートして迅速に関与させることが重要です。
PagerDutyでは、クラウド内でマルチテナントのSaaS（software-as-a-service）プラットフォームを運用し、さまざまなツールを使用してインフラストラクチャを監視および保護しています。 これらのツールは、私たちが採掘してフィルタリングできる多くのシグナルを生み、PagerDutyプラットフォームとのインテグレーションにより、関連するセキュリティイベントとアラートをまとめることができます。 これにより、イベントに即応して、 インシデント対応プロセスを開始し、迅速に対処と復旧ができるようになります。
これはセキュリティインシデントに限りません。 開発者がコードを所有している環境では、クラウドインフラ内のリソースがコンプライアンスから逸脱したり、セキュリティリスクが発生したりする事態を迅速に判断することもできます。 迅速に対応して開発者と協力して問題を修正し、最善のセキュリティプラクティスについての早急なフィードバックを提供し、以後のプロセスを改善することができます。
“やるか、やらないかじゃ。試しはない ” – ヨーダ
DevSecOpsのアプローチを実装するのは、難しい作業のように思えるかもしれません。また成功するためには、組織内のセキュリティの考え方を変えるなど、多くの課題があります。 それ自体は、ジェダイの精神的なトリックを使うべきだと思えるかもしれません。しかし、あなたはプロセスにコミットし、その後に自分の間違いから学び、また過去に同じことをした他の人から学ぶ必要があります。DevOpsと同様に、DevSecOpsは反復学習と改善のプロセスでなければなりません。 DevSecOpsは、迅速なフィードバックを提供するためにセキュリティプロセスを自動化するための適切なツールを選択することでもあります。PagerDutyを活用すれば、そのトランスフォーメーションを助けられると思います。
あなたの組織でDevSecOpsをうまく実装する方法の詳細を知りたいですか？ Datadogの導入事例をチェックしてください。
本記事は米国PagerDuty社のサイトで公開されているものを日本語訳したものです。原文はこちらです。
