2021年6月に開催されたPagerDuty Summit 2021から、注目セッションのご紹介のパート２です。
パート2では2つのセッションを取り上げます。最初のセッション「The power of PagerDuty in alert noise suppression」（アラートノイズ抑制におけるPagerDutyの力）は、Hudson’s Bay Company社のPlatform Visibility and Command Center Monitoring部門のディレクターであるMarcelo LaRosa氏が登壇しました。このセッションで彼は、測定対象を管理することで生産性と従業員の満足度がどう向上したかを共有しました。 ノイズ抑制に関しては日本の皆さんも興味のあるところだと思います。
さらにご紹介する2番目のセッションは「How PagerDuty & Rundeck Drives Operation Maturity」（PagerDuty＆Rundeckが運用の成熟度を高める方法）です。こちらはTrimbleのCloud Engineering and Infrastructure部門のディレクターであるAndrea Valenti氏と、TrimbleのシニアリードDevOpsエンジニアであるAli Soheili氏の講演です。
The power of PagerDuty in alert noise suppression：
(アラートノイズ抑制におけるPagerDutyの力)
Hudson’s Bay Company社のMarcelo LaRosa氏 ©PagerDuty
「The power of PagerDuty in alert noise suppression」（アラートノイズ抑制におけるPagerDutyの力）の講演は、Hudson’s Bay Company社のPlatform Visibility and Command Center Monitoring部門ののディレクターであるMarcelo LaRosa氏によって行われました。
最初にLaRosa氏は、「誰もノイズなんか聞きたくない、特にモニタリングでは」と述べました。 彼は、受信する必要のないアラートを処理するためにアクションを実行する必要があり、アクション可能なアラートのみを受け取るようにする必要があると述べました。
最初に行う必要があるのは、PagerDutyでデータを収集することです。分析内で、レポートを選択し、月次データを取得する必要があります。彼は、「少なくとも1年分のデータを取得し、通常の月よりもアラートが多い可能性がある場所を確認すること」を提案しました。次に、その月次データを取得したら、特定のサービスごとに月次統計を分析する必要があります。彼は、高い頻度でアラートを出す上位3つのサービスを確認し、各サービスのCSVレポートをプルダウンして、ピボットテーブルビューを作成することを強く勧めました。
アラートノイズの問題を改善するための手順 ©PagerDuty
そのデータを入手した後に、彼はトップ3のアラートサービスのオーナーとの個別の会議を設定すべきだと強調しました。「サービスオーナーの知識に応じて、アラートをP1 / P2またはP3などとして優先し、警告を設定し、アラートをグループ化するなど、分類法を改善する必要があります」。そして彼が最後に提案したのは「メンテナンス」です。 彼は、改善のための、PagerDutyを使った反復的なモニタリングを確立することを提案しました。彼のチームでは、毎日、毎週、毎月のリズムを確立し、定期的にアラートをチェックしています。そして、ある時点で何かがトップ10に入っているのを見ると、すぐにそのデータの再分析を開始します。
最後に、彼は「継続的改善はまさにそれ自体、継続的に改善すべきである」と私たちに思い出させました。 彼は、こうした説明したプロセスを継続することを強く推奨しました。 「最初の数カ月は大変かもしれませんが、大量のアラートと戦ったあとは簡単になります。こうしたたくさんのレポートを取得する方法はおそらく自動化できます。 自然と会議ができるようになり、意見が出てきます。 その意見が広まり、人々が私たちを求め始めると、何か大きなことをやったんだと感じるようになります」。
How PagerDuty & Rundeck drives operational maturity：
(PagerDuty＆Rundeckで運用の習熟度を上げる)
このセッションでは、建設をはじめ複数の業種にサービス提供している国際企業で、大規模なDXを遂げているTrimble社のシニアリードDevOpsエンジニアであるAli Soheili氏と、同社のクラウドエンジニアリングおよびインフラストラクチャのディレクターであるAndrea Valenti氏が講演しました。彼らのプラットフォーム 「Trimble Project and Program Management」（Trimble PPM。同社の「Connected constructions Portfolio」の一部）は、PagerDutyとRundeckを使いインシデント対応プロセスを自動化しています。彼らがどうやってインシデント解決までの時間を短縮し、エスカレーションを削減したかを学ぶことができます。
まず、Andrea Valenti氏は同社の重要な目標のひとつとして、CEOのRob Painterの言葉を引用し「私たちがサービスを提供する業界のライフサイクルをつなぐこと」と述べました。PPMは、そのTrimbleにおけるSREの変革の最前線です。彼はPagerDutyとRundeckの導入の経緯を説明しました。特定の部門内だけでなくTrimble全体で、PagerDutyとRundeckの両方を長い間使用してきた経験があります。
TrimbleでのPagerDutyとRundeckの導入と自動化の歴史 ©PagerDuty
また、特に同社の「e-Builder」SaaSアプリケーション群で、すでに数年間PagerDutyを使用していると述べました。Rundeckについてはヨーロッパグループの輸送部門で最初のプロジェクトを開始したときかに使い始めたそうです。PPMでは、エンタープライズレベルでのセキュリティと統合を進めることが彼らにとって最重要なポイントであるため、彼らはさらに2つの製品を活用することを決めました。
Trimbleは、2018年以降、複数のアプリケーションの統合ポートフォリオの運用を開始しました©PagerDuty
2018年からは複数のアプリケーション、e-Builder、ProjectSight、Prolog、Prolianceの統合ポートフォリオの運用を開始しました。その運用は、全グループが独自の方法、独自のツール、独自の解釈とアイデンティティを持っているため、非常に困難でした。そこでSREグループはまず複数のグループでプロビジョニングとデプロイメントについて一貫性のある命名法を決めました。これはまだ継続中ですが、ほぼ確立しています。同時にインシデント管理についても命名法を決めました。以前はイベントがなぜ起きたかをチームごとに別々の見方で調べていました。そのためインシデントの状況を特定すること困難でした。そこで彼らは、イベント管理や各グループがもたらす多様性を消してしまうのではなく、決断をするようになりました。インシデントの概念にフォーカスして、全イベントをPagerDutyに集約することを決めたそうです。
次に、Ali Soheili氏は、SREチームを単一のクラウドチームに変えるべき3つの理由を共有しました。
Rundeckを使いビジネスオペレーションを自動化したことで得られた効果 ©PagerDuty
次に、インシデント管理がどう設定されているかを説明しました。同社ではNew Relicをはじめ複数の監視ソリューションがさまざまな部門で使われていました。Rundeckの利用目的の1つはそのオペレーションの自動化でした。彼らはそれらをセルフサービスとしてRundeckで自動化しました。結果として複数のチームがこれらのセルフサービスジョブを利用できるようになり、時間を大幅に節約できます。例えばあるケースでは、開発チームのオペレーションには5日間のサイクルタイムがありましたが、数分に短縮されました。コスト削減も大事な目的であり、このセルフサービスを使用するメリットの１つです。
次の図はPagerDutyとRundeckを使用して実行した自己修復の例です。
PagerDutyとRundeckを使用して実行した自己修復の2つの例 ©PagerDuty
最後に、Andrea Valenti氏は、RundeckとPagerDutyの利用について学んだことを共有しました。
- 自動的に修復をする実用的なフレームワークを用意してください。小さくて簡単なものでも、インシデントの優先順位付けで最上位に当たるP1をダウングレードする際に再利用できます。
- SME（Subject Matter Experts）のセカンドラインが待機していることを確認してください。
- PagerDutyを使用すると、複数の監視ツールからの情報を集約でき、インスタンスを表示する方法を1つに絞ることができます。
すべての画像の著作権はPagerDutyにあります。
PagerDuty Summit 2021のサイトでは詳しい資料と動画を公開していますので、こちらをご覧ください。
カテゴリー ：ニュース＆告知
