Blog
ブログ

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

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

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

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

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

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

設定についての警告

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

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

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

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

iPadレイアウトの改善

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

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

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

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

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

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

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

Amazon EventBridge

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

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

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

続きを読む
ニュース&告知
2018年3月5日  (更新日:2022年3月9日)

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

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

詳しくはこちら

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

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

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

詳しくはこちら

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

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

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

詳しくはこちら

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

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

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

詳しくはこちら

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

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

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

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

詳しくはこちら

続きを読む
インテグレーション&ガイド
2017年12月27日  (更新日:2022年3月9日)    |    ベストプラクティス

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

根本的な原因

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

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

対応

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

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

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

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

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

恥と思わず、金と思え

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

DevOpsを高速化するための6つのステップ

多くの組織がDevOpsの導入を検討しているのは、リリース速度の向上、開発速度の向上、開発者がイノベーションに集中できる時間を確保できることなどが期待されているからです。しかし、DevOpsの採用は万能薬ではありません。その代わり、DevOpsモデルが奨励するコミュニケーション、コラボレーション、批判しない前提での振り返りの考え方は、問題を解決するだけでなく、プロセスを改善してボトルネックを解決し、より無駄のないシステムを構築するのに役立ちます。

DevOpsを実装する組織にとって最大の課題の1つは、ワークフロー内の既存の問題を特定して削除し、より新しく、よりアジャイルな方法論に道を開くことです。ガートナー社は、システムが目標達成に近づくのを妨げる不便さ、挫折、その他の制限要因を意味する制約を取り除き、真の意味でDevOpsの速度を向上させるために組織が取ることができる6つのステップを以下にまとめました。

ステップ1:プロセスを定義する

プロセスを再構築する際には、DevOpsチームは、初期の構想から最終的な顧客価値に至るまでのワークフローをデザインし、プロセスを定義する必要があります。既存のプロセス内のすべてのステップを文書化することにより、プロセス全体に積極的に貢献していない可能性のある制約領域をより簡単に見つけ出し、改善できます。さらに、サイクルタイム、おおよその時間間隔、ハンドオフ、待機状態など、より価値の高い流れを明確に把握できます。これがすべて整理されたら、チームは最大のプロセス制約を簡単に特定し、プロセス全体を改善するための手順を開始し、プロセス文書化の効果を高めることができます。

ステップ2:最大の制約を特定する

典型的なDevOpsのワークフローでは、アイデアから価値へのプロセスを遅らせる段階が常に存在します。体系的な改善を推進するために、チームは進行を妨げている特定のフェーズを特定し、制約の原因を取り除く必要があります。

最大の制約を特定するには、「誰もが常に何を待っているのか」を問います。これを尋ねることで、チームは効率を高めるために特別な注意が必要なことを特定できます。責任追求をしない建設的な環境でこれを行うと、チームメンバーは発言しやすくなります。最大の制約を特定したら、プロジェクトの進行状況を監視して、ブロック要因が正しく特定されていることを確認します。

ステップ3:制約条件下での無駄を取り除く

制約が特定された場合、最も一般的な行動方針は、より多くのリソース(人、お金、新しいシステムなど)を投入することです。ただし、役に立たない可能性があるリソースを追加するのではなく、無駄な可能性のあるリソースを排除することがより効果的です。

ガートナーによると、クライアントが特定した上位3つの無駄の発生源は次のとおりです。

インシデント:** 新しい製品や機能の開発などの付加価値活動を犠牲にして、インシデント管理に貴重な時間が費やされています。このためのベストプラクティスは、チームメンバーを相互訓練してインシデント管理に習熟することです。将来のインシデントを防止する1つの方法は、責任追求をしない事後検証を実施して、インシデントの根本原因を解明し、将来それを防止することです。 待機:** 人、外部組織、その他のリソースを待つことは、常に課題です。これは、多様なスキルと知識を備えた従業員をトレーニングや雇用して、並行して作業できるようにすることで軽減できます。これにより、他の人の対応を待っている間に、プロジェクトの目標や他の割り当てられた仕事を達成することができるようになります。 人のポテンシャル:** データベースの更新であれ、インシデントのエスカレーションであれ、多くのIT専門家は多くの時間をかけて手動で作業しています。組織はできる限り自動化することでより多くの価値を実現し、人々はより価値の高いタスクに集中できるようになります。

ステップ4:制約を無視しない

制約を無視して新たに発生した問題に集中すると、元の問題に対処できなかったため、作業が遅くなり、将来さらに問題が発生します。たとえば、鎖について考えてみましょう。鎖の中の最も弱い環が強化されていない場合、鎖はある時点でその場所で切れてしまいます。

制約を無視することで、チームは次のようなさまざまな課題を経験することになります。

ミスや欠陥の増加 チームの効率と生産性への悪影響 変化率の高い状況での費用のかかるやり直し

ステップ5:容量を追加する

上記の手順は、スループットを少なくとも30%向上させるのに役立ち、問題を評価する能力と時間を利害関係者に与えるので、迅速な解決策を選択するのではなく、最善の解決策を慎重に検討できます。チームは専門サービスの契約であろうと追加のスタッフの採用であろうと、キャパシティを増やすことができる他の方法を見つけるためにこの時間を取るべきです。

ステップ6:次の最大の制約を見つける

リリース速度を向上させることは簡単なことではなく、プロセスを継続的に改善する必要があります。例えば、あるチームが制約を取り除くことに成功したとしても、ワークフローの別の部分で別の制約が取って代わることがあります。時間が経つにつれて、チームは高い開発スピードを達成するために、プロセスとプラクティスを適応させる必要があります。最後に、顧客のニーズを確実に満たすためには、開発サイクルのデューデリジェンスを実施し、必要に応じて改善する必要があります。

ガートナーの完全なレポートをお読みになりたい方は、「制約を削除してDevOpsのリリース速度を向上させる6つのステップ」をご覧ください。

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

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

オンコールのシャドー中に驚いた5つのこと

シャドーイング( 訓練のためインシデント対応を見学すること )中のコールエンジニアは、医師の肩越しに開腹手術を見ているような感じがします。精密さとスピードが最優先事項であり、間違いは深刻な結果につながります。私はPagerDutyエンジニアリングチームのオンコールローテーションにシャドーオブザーバーとして1週間参加しました。

オンコール中、私は同じエスカレーションポリシーで、他のすべての人たちと同じように通知を受けました。エンジニアが緊急でセンシティブな状況に立ち向かうため、Slackで起こされると私も起こされます。私はストレスが人々を悪い状況に追い込むと予想しました。ところが、驚いたことにそれは完全に間違っていました。

コールは睡眠、食事、シンプルな文章は、何時間ものストレスを乗り切れるようにします。

思考、そしてほかの多くのものを中断するために鳴り響き、チャットチャンネルは一晩中炎上と対応を知らせるメッセージを流し続けました。オンコールの責任とストレスに押しつぶされそうなのに、エンジニアが見せる優しさ、助け合い、ユーモアに私は驚かされました。

励まし

シンプルな文章は、何時間ものストレスを乗り切れるようにします。

初日のシャドーイングの午後遅くに、私は最初の通知を受けました。私はSlackのチャンネルを見て、問題の調査が完了したのを知りました。チームは直ちに新しいマシンを停止し、再配置をしました。トリアージと診断の混乱の中で、そのオンコール担当者が私と同じく新人だと知りました。私たちはどちらもまだ1カ月足らずの新米でした。彼はこれまで一度も遭遇したことのない問題を修正していました。

夕方までに事態は回復しました。長い1日を終え、人々は家に帰って行きました。それでも、ベテランのエンジニアPがチームメイトKの応援に入っていました。

6:14 PM (P)すべて終わった?

6:15 PM (K)まだ、ホストを再起動してるところです。すべてがスムーズに進んでます

6:18 PM (P) その調子だ! 俺達はこいつのために半日つぶしたんだ

このような仲間の励ましは、プロジェクトに新しく加わった人、新人社員、新人エンジニアに自信をもたせます。シニアエンジニアからの励ましは経験の少ないエンジニアに質問する勇気を与えます。質問は新人がエキスパートになるための第一歩です。「その調子だ!」の一言は人々に力を与えます。

謙虚さと感謝

この初心者オンコールエンジニアは、その励ましにすぐ反応しました。彼は自分を助けてくれたシニアエンジニアに短い言葉で謙虚さと感謝を示しました。

6:21 PM (P)本当にあなたとMがいなければダメになるところでした。勉強になりました

Kが彼を助けた別のチームメイトの名前を挙げたのが嬉しかったです。DevOpsのエンジニアリングチームは、チームメイトを高く評価しています。彼らが今開発しているソフトウェアが明日、地獄のオンコール嵐を起こさないため、互いに頼り合っています。誰も常にすべてのことを知ることはできません。彼らは常に互いから学び、お互いに助け合わなければなりません。

上の例では、謙虚さと自己嫌悪の間の細い境界線が見えました。エンジニアは「学ぶことがとても大事」と述べています。この態度は「こんなことは絶対自分ではやりません」や「私にはこんなこと全部分かるわけないでしょう」とは異なります。謙虚で感謝の気持ちがあれば、チームメート同士の信頼を築けます。自己嫌悪は迷いと不安を引き起こすでしょう。

軽薄さとたくさんのGIFファイル

オンコール待機中は(幸せなことに)退屈でもあります。オンコールに入る予定が分かっていることはストレスを軽減してくれますが、それでも常に不安があります。幸運なことに、インターネット上のGIFファイルは、ストレスに満ちたオンコールシフトをユーモアで支えてくれます。

PagerDutyはユーモアの文化とカスタムGIFに特別な情熱を持っています。3つのタイムゾーンと2つの異なる国に分かれているこの楽しくてちょっとおバカなチームを観察するのが私は大好きです。オンコールでない人々がいつも明るいことに気づきました。

どうすればオンコールをよりポジティブにすることができるか

あなたがオンコールでない場合でも、チームと共にあれ 応援しよう。特に新人を 挑戦やリスク、時間のかかることを肯定する 感謝をもってあなたに直接影響を与えてくれた人々に接する。チームが将来どのような強みを持つか理解するのに役立つ ひょうきんに振る舞う。皆笑うのが大好き

たくさんの問題解決と心労を経験しましたし、他人が週末や夜にもオンコール待機をするところも見ました。そのまっただ中で、チームメイトが示す小さなジェスチャーが、あなたが1人ではないことを思い出させてくれます。

空が落ちてくると思うような時は、互いに品性ある振る舞いをすることが助けてくれるでしょう。

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

メールでのアラートをやめたほうがいい5つの理由

メールアラートを改善したいですか? もう一度考えてみましょう

監視システムは、稼働中のシステムをより効果的に管理するのに役立ちます。しかし、早期に問題を特定するためにチェックとしきい値を設定するのに多くの時間を費やしたとしても、アラート自体にはインシデント対応プロセスと同じくらいの意味しかありません。 PagerDutyがお客様の声を聞いてきた中で発見した最大の課題の1つは、どのお客様もメールアラートに悩まされているということです。 受信トレイがぐちゃぐちゃになって大切なものを見逃してしまいがちだと気づいていながらもなお、多くの監視システムとIT運用チームはメールアラートに依存しています。 メールアラートを改善しようとしていますか? もう一度考えみてください。それでもまだこのまま使い続けようとお考えのあなたに、メールによるアラートをやめてしまった方がいい理由を5つお教えしましょう。

  1. メールアラートは見過ごされやすぎる

「ねえ、友達が私にメールで送った最新の猫のビデオを見ましたか?」

受信トレイを常に見ていても、重大なアラートが他のアラートや仕事関連のメールに紛れてしまうのは日常茶飯事です。 このため、優れたオペレーションチームは、通常、少なくとも2つの通知チャネルを使用します。ひとつは、電話またはSMSメッセージです。 音でアラートを知らせることは間違いなく気づくのに役立ちます。

  1. メールで誰かを確実にアサインすることはできません

「えーと、この件誰か対応してる?」

深刻なインシデントへの対応では時間が重要であり、チームの誰が対応に当たることになるのかで混乱している場合ではありません。アラートが複数の人にメールで送信されている場合、チームの誰が最初に応答するかを知る方法はありません。 他の誰かが既にそのメールを見て対応しているのか、自分はそのアラートに対応するのに最も相応しいのか、それとももっと経験豊富な人を待つべきだろうか。 優秀なオペレーションチームは、各インシデントが最適な担当者に自動的に割り当てられるようにします。 インシデント管理ツールとチケットシステムは、オンコールのエンジニアを自動的に割り当て、割り当てたエンジニアのステータスを追跡することにより、このワークフローを実行させます。

PagerDutyではオンコールのスケジュールに従い、すぐに対応に当たる人を決定してインシデントを割り当てます。

  1. メールを集約またはバンドルすることはできません。

「これ、止められないのか?」

アラートの嵐が吹き荒れる。スタッフが対応を誤ると、すべての監視システムが毎分何度もアラートを送信します。膨大なアラートは受信トレイをたちまちあふれさせて、事実上使用できなくなります。 PagerDutyでは単一インシデントのアラートは1つに集約し、複数インシデントのアラートは、それぞれの最初の通知の後にまとめて通知します。したがって担当者が受け取るアラートは一度だけです。また、ダッシュボードにより現在進行中のインシデントの数とその出所を簡単に把握することもできます。

  1. メールは状況を可視化してくれません

「現在のステータスはどうなってるんだ?」

メールでは、誰がインシデントに対処しているのか、経過時間、最新の状況の把握などは難しいです。この情報はチームだけでなく、経営幹部やその他のビジネス関係者にも重要です。あなたが対応している最中に、状況を知りたい人々に絶えず質問されるのも迷惑です。インシデントをPagerDutyのようなシステムに取り込むことで、管理者だけでなくチーム全員がアクセスできる単一のダッシュボードですべての情報を取得できます。 CEOやCTOがこれで問い合わせを控えてくれるとは限りませんが、少なくとも自分で情報を入手できる方法を伝えることはできます。

  1. メールアラートでメトリクスを作成することはできません

「僕ら、うまくやれてる?」

優れたオペレーションチームは、パフォーマンスを継続的に測定、評価、改善するためにメトリクストラッキングを採用しています。全てのメトリクスをメールからトラッキングすることは非常に困難です。インシデントが発生した時刻、最初の人が気付いて応答するまでの時間、チームが解決するまでの時間などをトラッキングすることは、完了予想時刻を管理する上で大切になってきます。このデータを使用して作成したチームのパフォーマンスを示すダッシュボードと週ごとのレポートで、チームや企業内のコミュニケーションを容易にすることができます。

メールアラートの問題は、今まさにあなたが直面している課題かもしれませんが、それはあなただけの問題ではありません。

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

アラート管理プロセスの最適化

シンプルな 世界では、すべてのアラートは等しく発行され、インフラストラクチャは 完全に機能しているか、完全に壊れているかのどちらかで、その中間はありません。

しかし、実際には、世界はそれほど単純ではありません。インフラストラクチャがこれまで以上に多様で複雑な今日は特にそうです。

その複雑さに対処するには、監視とアラート管理に異なるアプローチが必要です。やって来るアラートに順番に応答するプロセスとして、またはすべてのアラートがアクションを必要とすると仮定して処理するよりもはるかに多くのことを要求されます。

この記事では、アラート管理に対する柔軟で微妙なアプローチが不可欠である理由と、その実装方法について説明します。

複雑化した現代のインフラ

柔軟なアラート管理プロセスが不可欠な理由を理解するために、現代のインフラストラクチャを複雑にする要因を検討してみましょう。次の点を考えてください。

階層化され相互依存しているインフラストラクチャ

以前はベアメタルのサーバとワークステーションがたくさんありました。今日、すべてがソフトウェアで定義される時代に、インフラストラクチャは物理マシンと仮想マシン、ソフトウェア定義のネットワーク、シンクライアント、断続的に接続されたセンサーなどからなる複雑なスタックであり、相互に絡み合っています。その結果、Docke化アプリケーションなどの1つのソースから発せられるアラートは、実際にはインフラの他の部分に根をもつ可能性があります(Dockerホストサーバが接続されているストレージアレイなど)。

いくつかの問題はより深刻

これは、インシデント管理の経験がある人にとっては自明のことです。それでも、今日の問題の範囲がどれくらい広がっているのか、アラートの重大度をすばやく解釈することがどれほど難しいのかを強調しておきましょう。たとえば、ストレージサーバが応答を停止したことを知らせるアラートは、一見すると非常に深刻に思えるかもしれません。ただし、サーバが自動フェイルオーバーを備えたスケールアウトされたストレージクラスタの一部である場合、ダウンタイムは実際には最優先事項ではありません。データが失われる可能性は低く、チームがすぐに問題に対応しなくともビジネス継続性は中断されません。さらに、一部のアラートは警告としては機能しますが、すぐに対処可能ではありません。その情報は、インフラストラクチャ全体のレベルでの異常検出のために保持する必要がありますが、アラートの嵐に疲れてしまわないために、人間の反応のトリガーにならないよう抑止する必要があります。

リアルタイム応答の重要性

今日の常時稼働の世界では、ユーザーはサービスの失敗をリアルタイムで知ることができます。したがって、アラート管理プロセスはリアルタイムでも発生する必要があります。あなたの会社に連絡する前に、SNSのような公開の場所に書き込む傾向があるという事実は、リアルタイム解決をより緊急事項にします。反応的ではなく積極的に行動する、顧客が怒りのツイートをするまでアラート対処を待つことは望ましくありません。

アプリケーションパフォーマンスの問題

アプリケーションが実行されていることを単に確認するだけでは不十分です。ユーザーはパフォーマンスの低下に対してほとんど忍耐力を持たないため、パフォーマンスを最善にする必要があります。たとえば、Webサイトの速度が遅い場合、顧客は10秒待たずに別のサイトに移動します。アラートの観点からこれが意味することは、アプリケーションが完全に応答を停止したときに通知されるだけでは不十分だということです。稼働の監視は重要ですが、パフォーマンスの低下に関するアラートも受け取る必要があります。さらに、無応答アラートと区別できる必要があります。

アラートを微妙に調整

最新のアラート管理の課題は以上のようなものですが、ではどのように解決できるでしょうか。 答えはアラート管理プロセスを非常に柔軟に、より機敏にすることです。次のような戦略を採用します。

優先順位の高いアラートを目立つようにする

最も重大なアラートに迅速に対応するには、それが簡単に見分けられる必要があります。優先度の高いアラートと優先度の低いアラートがダッシュボード上で混在していると、双方を見分けるのは困難です。監視ソフトが優先度の高いアラートをマークすればはるかに簡単になります。

役に立たない警告を抑止する

役に立たないアラートを排除することで、ダッシュボードの視認性を向上させることができます。新しいユーザーアカウントの作成など、優先度の低いイベントのアラートを抑制することなどです。このようなアラートを完全に無効にするのではなく抑止する利点は、緊急の時は紛らわされず、かつ必要に応じて表示させることができるからです。

微妙なアラートの報告と抑制

抑制は必ずしも命題ではありません。特定の状況では特定の種類のアラートをいくつか抑制できますが、他の状況では抑制しないことを選択できます。

たとえば、就業時間内にスタッフがアカウントを作成しているときにはアカウント作成に関連するアラートを抑制し、時間外に行った場合はアラートを表示する、ということができます。または、再起動が一定時間内に3回以上行われない限り、サーバの再起動に関する警告を抑制したい場合もあります。

また、重複した対策やコミュニケーションを防ぐため、関連するアラート間の関連付けを作成することも重要です。

重要なイベントを見逃さずにアラートノイズを最小限に抑えるには、抑止、関連アラートのグループ化、通知閾値のカスタマイズなどを実行し、アラートの重要度をより洗練された方法で判定する必要があります。

アラートによって送信先を変える

すべてのアラートをチームの全員に送るのは非効率的です。異なるタイプのアラートは、各人のスキルとスケジュールに応じて異なるメンバーに送る必要があります。対応する者が異なるということは、アラートの柔軟な割り当てが重要だということです。次の1時間インシデント管理にあたるエキスパートは、その後は非番になるかもしれません。

最初から適切な人にアラートを送信するようにしておくことで、問題を判定してスタッフに割り当てるために必要な手作業の多くを省くことができます。

システムダウンだけではない監視

前述のように、アラート管理の成功は今日、障害だけでなくパフォーマンスの低下を検出することを意味します。このため、システムが容量の限界に近づいたとき(ネットワーク負荷が80%を超える場合や、アプリケーションのCPUタイムが閾値に達したが、まだそれを超えていない場合)にアラートを生成するように監視ソフトウェアを設定することが重要です。

もちろん、これらのアラートに重大な障害と同じ優先順位を付ける必要はありません。障害インシデントは、直ちに知り直ちに処理することがより重要になります。しかし、何かが完全に壊れるまで待ちたいとも思いません。代わりに、アラート処理を最適化して、パフォーマンスの問題がシステムダウンに発展する前に処理できるようにします。

DevOps時代には、インフラストラクチャはアジャイルです。アラート管理プロセスもそうあるべきです。すべてのアラートが同等の重要性を有すると仮定したり、すべてのアラートを報告したりレビューしたりする必要があるとした時代は終わりました。圧倒されることなく現在の複雑で変化の激しいインフラストラクチャを監視するには、アラートに対する最適化されたアプローチが必要です。アラートを重要度に応じて識別し解釈するIT組織の能力が試されます。

2021年8月23日  (更新日:2022年3月8日)    |    DevOps

DevOpsのROIを測定する方法

DevOpsは、ソフトウェアの提供とインフラストラクチャの変更のプロセスを自動化および加速しながら、ソフトウェア開発者とIT運用の専門家の間のコラボレーションとコミュニケーションを強調する文化、ムーブメント、実践手法です。 DevOpsプラクティスを実装するには、人、教育、ツール、組織の調整など、いくつかの種類の投資が必要です。しかし、これらの投資から組織が受け取るリターンを判断するのは難しい場合があります。効果測定では何を重視しますか? どうやって投資を価値あるものにしますか?

DevOpsがROIに与える影響

DevOpsのない世界では、ソフトウェアリリースの頻度は低く、以前のリリース以降に開発チームによって構築されたすべての新機能、更新、および変更が含まれています。ビルドされたが次のリリースまで出荷されないコードは、ビジネスには何の価値も生み出しません。コードのユーザーへの配信を加速するということは、ジャストインタイムの製造のようなものであり、完了後すぐに価値を生み出します。そして、今日の継続的なデジタルトランスフォーメーションの世界では、新しい機能をデプロイし、競合他社よりも早く問題を解決する能力が、市場での優位性につながるのです。 DevOpsの主な目標の1つは、ソフトウェアリリースを頻繁に、定期的に、自動化することです。1日に複数回リリースする能力がある場合、個々の本番環境へのプッシュはたいしたことではありません。リリース頻度の低い「ビッグバン」スタイルの体制、つまり全員が臨戦態勢で、土壇場でのトラブルシューティングに追われ、やり遂げるまで深夜も週末も作業する運用チームを必要とするような体制と比較してください。デプロイの失敗によるダウンタイムを解決するために髪を振り乱すのではなく、より幸せで休息の取れた運用チームが次の問題を積極的に解決することの方が、組織にとって明らかにはるかに大きな価値があります。

あなたのチームはあなたの最大の資産です

DevOpsを実装する最良の方法は、解決が必要な問題に権限と責任の両方を集中させることです。最前線のチームは、時間が無駄になっているところ、隠れた非効率性がどこにあるのか、どこに最適化の機会があるのかを知る最適な立場にあります。プロセスに自動化を導入することについての最大の誤解のひとつは、それが必然的にチームから仕事を奪うということです。むしろ、面倒な手作業を自動化に置き換えることで、チームはより価値の高い活動に集中できるようになるのです。 結局のところ、あなたのビジネスをあなたのチームよりよく知っている人たちはいません。人件費にどれだけ投資したかを考えてください。チームの生産性を最大化することは、DevOpsを実装することによるROIの大きな改善点です。重要な問題の解決に時間を費やしてもらうことで、ビジネス全体の成果の量と質が向上し、面倒なエラーが発生しやすいタスクがToDoリストから削除されるため、リスクが排除されます。

ROIをビジネスの目標に結び付ける

では、DevOpsプラクティスを採用するためのビジネスケースを検証するために、ROIの適切な指標をどう選択すればいいでしょうか? これはビジネスにとって大変重要なことです。デジタルトランスフォーメーションが広がるにつれ、新しいビジネスモデルと顧客との新しい対話方法が、あらゆる業界で生み出される価値を根本的に変えています。成功を測定するための鍵は、ユーザーに提供する独自の価値を理解し、それを達成するために指標を結び付けることです。顧客が目標を達成するために費やす時間を最小限に抑える、ユーザーあたりの収益を最大化するなど、DevOpsへの投資を主要なビジネス指標の改善に直接関連付けることができるはずです。

			時は金なり
			鍵は効率化
			柔軟に最適化を
		
	
	
		
			チームがより価値の高い問題に時間を費やすことができれば、あなたのビジネスにより多くの価値をもたらすでしょう。
			ボトルネックを防ぐために、問題に近い現場に権限と責任を持たせましょう。	
			どんなケースでも即通用するというものではありません。ビジネスにとって何が重要かを把握し、そのために最適化を図ってください。

そして忘れてはいけないのは、何かを測定できるからといって、そうする必要があるとは限らないということです。我々は時にビジネスの目標に関係ない指標に気を取られてしまいがちです。開発者の生産性を測定するためには非常に多くのツールが利用可能であるため、記述されたコードの行数や修正されたバグの数など、実際には重要ではないあらゆる種類のデータを追跡できます。計算や最適化は簡単かもしれませんが、ユーザーのために生み出そうとしている価値とは実際には関係のないことです。

「数えれられることすべてが大事なわけではないし、大事なことすべてが数えられるわけではない。」(ウィリアム・ブルース・キャメロン)

ビジネスへの教訓

DevOpsの変革とは、ITの流れを加速することを目的としたプロセスの変更がすべてです。つまり、ROIを測定する際の最大の課題は、DevOpsが提供するさまざまな種類のメリットを理解し、それらのメリットをビジネス目標に結び付けることができるかどうか、ということなのです。 配信されないソフトウェア在庫の山の削減から、手作業による障害リスクの削減、生産性と従業員の満足度の向上まで、DevOpsプラクティスを実装することの価値はすぐに得られます。今日のデジタル環境で競争力を維持しようとしている企業にとって、DevOpsに移行する余裕があるかどうかという問題は、「DevOpsに移行せず現状のままで安泰なのか?」という問いになってきています。

ROIの決定に使用できるDevOps指標

これらをあなたのビジネス目標に当てはめてください

			指標
			詳細とメリット
		
	
	
		
			1日/週/月あたりの本番環境へのプッシュ数
			本番環境への展開の頻度を増やすことで、ユーザーにビジネス価値を提供する速度を上げ、「倉庫の在庫」コードを減らすことができます。
		
		
			1か月/年あたりのダウンタイムの分数	
			自動化が進むと、アプリケーションのダウンタイムが削減されます。これは、ユーザーの満足度と収益に直接関係します
		
		
			自動テストカバレッジ	
			自動化を広範に使用すればするほど、手動エラーの可能性が少なくなり、移動が速くなります。
		
		
			新入社員がコードを本番環境にデプロイするのに必要な時間	
			新入社員が迅速に対応できるようにするためのフレームワークとプロセスを構築することで、新入社員の生産性が向上し、既存のチームの生産性も向上します。
		
		
			新しいイニシアチブと既存のプロセスの実行に費やされた従業員の時間	
			手動プロセスを自動化することで、チームは既存の問題に対処するのではなく、ボールを前進させることに時間を費やすことができます。
		
		
			従業員の幸せ	
			作業に忙殺されるのではなく貴重な問題に時間を費やしている幸せな労働者は、生産性が高く、長期間にわたって戦力となってくれます。これは、NPS(Net Promoter Score)を介して直接測定することも、トラブルシューティングに追われる夜と週末の数を介して間接的に測定することもできます。
2020年7月8日  (更新日:2022年3月8日)    |    ベストプラクティス

インシデント対応から得た分散型コミュニケーションの教訓

新型コロナウイルス(COVID-19)の報告例が世界中で増加し続けていることから、多くの企業では、従業員の感染を最小限に抑える方法として、リモートワークへのシフトが進んでいます。しかし、多くの企業は現在、業務を完全なリモートワークに移行するためにはどうすればよいのか、悩んでいるのが現状です。

企業が急速に分散型組織への移行を考えようとしている中、インシデント対応のパターンを見ることで、数多くの教訓を得ることができます。

リモートワークへの移行

企業がますますリモートワークを採用するようになってきている中で、ITとエンジニアリング職はこの変化の先頭に立ってきました。

20年前は、エンジニアリングチームが物理的に同じ場所にいて、オンプレミスのサーバルームで本番アプリケーションを実行し、プライベートなイントラネットですべての作業を行うのが一般的でした。IT チームとエンジニアリングチームは現場にいて、運用チームがサーバールームにクラッシュカートを走らせるころ、開発チームとマネージャーは、インシデント対応のための作戦室である会議室に集まり始めていました。重大なインシデントが発生した場合、マネージャーがネクステル社の携帯電話を使って、その日外出していたエンジニアに無線で連絡を取り、トラブルシューティングを支援できるようにVPN接続を指示することもありました。

この10年間で、クラウド環境とアプリケーションを使用するようになったことで、世界中のどこからでも本番用アプリケーションにアクセスできるようになりました。今日では、これらのチームが分散して活動することが一般的になっています。その結果、ITとエンジニアリングチームは、リモートで作業する際の効果的な方法を開発する最前線に立っています。

オンサイトサーバ、イントラネット、物理的なインシデント対策室の時代は、多くの組織では一般的に、より近代的なソリューションに取って代わられてきています。これらのソリューションとワークフローがどのように組み合わされているかを検証することは、分散型ワークへのシフトをどのように行うべきか悩んでいる組織に役立つでしょう。

10年間のリアルタイム運用管理の教訓

PagerDutyは10年以上にわたり、何千もの組織がリアルタイムのオペレーションを管理するのを支援してきました。私たちの生活は、デジタルファーストの体験にますます接続されるようになり、世界は常にオンになっていることを意味します。顧客は完璧さを求めており、問題が発生したときの解決までの時間は、数時間ではなく、ほんの数秒しかありません。リアルタイムオペレーションを効果的に管理することは、1秒1秒が重要な時に、適切な人員が適切なタイミングで対応し、コミュニケーションを調整することです。これは、世界中のどこにいようとも、すべてのチームやチームメンバー、部門、リーダーがリアルタイムで起こっているアクションに関与し、情報を得て、連携することを確実にすることを意味します。

PagerDutyは、インシデント対応のリーダーとして広く認識されています。そこで私たちは、リモートチームのための効果的なコミュニケーションを管理する方法について、私たちが教えることができる教訓を見てみることから始めるのが当然のことだと考えました。PagerDutyでは、私たちのチームがどこにいても、リアルタイムの仕事を効果的に管理するために、私たち自身のプラットフォームだけでなく、他のいくつかのリモート生産性ツール(PagerDutyではSlackとZoomを使用しています)を利用して、発生したインシデントに対応しています。

大規模なインシデントが発生した場合、当社の社員はPagerDutyのプラットフォームを使用して、解決に向けて作業を進める際に必要に応じて、様々なチームにまたがって適切なその分野の専門家に連絡を取ることができるようにしています。物理的な作戦室は、ビデオ会議ブリッジ(必要に応じて、バックアップの電話回線があります)と、すべての重要なコミュニケーションをキャプチャする専用のチャットルームの組み合わせに置き換えられました。

リモートで仕事をする際には、いくつかのコミュニケーション方法が鍵となります。

インフォーマルなコミュニケーションチャネルは、フォーマルなコミュニケーションチャネルに置き換えるべきです 口頭での説明に頼るのではなく、知識を書き留めて記録すべきです 必要に応じて情報を制限するのではなく、内部で情報を共有しましょう

インシデントが発生した際には、その場しのぎの通信チャネルを持つのではなく、私たちのチームは、よく知られた明文化された通信チャネルを使用します。インシデントが発生し彼らの参加が要求されたとき、彼らはすでにどの通信チャネルに参加すべきかを知っているはずです。しかし、万が一に備えて、PagerDutyプラットフォームは、ワンクリックでそれらのチャネルに参加するためのリンクが埋め込まれた通知を送信します。

インシデントの管理は、速いペースで行われるストレスの多い仕事です。その作業を調整するために必要なコミュニケーションの多くは、ビデオ会議で口頭で行われます。しかし、知識を確実に書き留めて記録するために、すべてのインシデントコールには、重要な事実と取られたアクションを記録し、対処すべきフォローアップ項目を追跡することで、インシデント中の重要なイベントのタイムラインを作成する記録係が割り当てられています。当社のビデオ会議ソリューションでは、通話の自動テープ起こしを作成することができます。しかし、記録係によって作成されたメモは、発生した出来事を迅速に把握したい場合の参考資料として活用することができます。

記録係は、専用のチャットチャネルでタイムラインを記録します。そうすることで、他の対応者は(対応者として、またはオブザーバーとして)参加したときに、タイムラインを参照して見逃したことをすぐにキャッチアップすることができます。オブザーバーは、状況をよりよく理解したい場合は、専用のチャットチャネルやビデオ通話(聴取専用モード)に参加することをお勧めします。

インシデントが発生している間、当社のチームは通常、社内外の利害関係者に更新情報を送信し、最新のイベントを知らせます。内部の利害関係者には経営幹部、ビジネスオーナー、顧客対応チームなどが含まれ、外部の利害関係者には顧客が含まれます。これらの通知はPagerDutyプラットフォームによって管理されています。しかし、その通知を送信するまでの意思決定は、何を伝えるかの合意を含めて、記録係のタイムラインの一部として記録され、専用のチャットチャネルにも記録されます。

このように口頭でのコミュニケーションと記録されたコミュニケーションのバランスが取れているため、分散したチームが迅速に作業し、より広い組織に効果的にコミュニケーションを取ることができます。記録係のタイムラインを専用のチャットチャネルに記録することで、既存のPagerDutyとのインテグレーション機能を使用して、インシデント後のレビューに自動的に組み込むことができるようになります。

ここでは、インシデントの解決に至るまでの出来事を要約し、原因となった要因を特定し、将来的にこの種のインシデントを軽減するのに役立つであろう 合意された行動項目を文書化しています。これらの事後検証は社内で共有され、物理的な場所に関係なく、どのチームでもイベントをよりよく理解できるようになります。

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

<  123456789101112  >