Category
DevOps

PagerDutyオペレーションクラウドの新しいアップデートと機能強化を発表することに興奮しています。製品チームによる最近の開発およびアプリのアップデートには、PagerDuty®プロセスオートメーション、パートナー統合およびアプリエコシステム、コミュニティ＆アドボカシーイベントのアップデートが含まれています。私たちは、お客様がクラウド運用を最適化し、他のチームにエスカレーションされる問題の量を減らすために、あらゆる場所を自動化できるよう支援し続けています。今すぐ始めましょう。

最近リリースされたPagerDuty + Sumo Logic Job Step PluginとPagerDuty + AWS ECS Node Executor Pluginの詳細、およびPagerDuty® Process AutomationとRundeck Communityのアップグレード、バグ修正、パッケージ更新を最新の4.5.0 Releaseでキャッチアップすることができます。 PagerDuty App for Jira Cloudのサイドバーの更新、PagerDuty App for Jira Data Center Recertification、PagerDuty App for BMC Helix/Remedy を管理するKTSLへのサポート移行を含む、最新のパートナー統合とアプリエコシステムの更新をお楽しみ下さい。 イベントルールの廃止、イベントオーケストレーションへの移行、V1/V2 Webhooksの廃止など、製品廃止情報を常に把握してください。 今後のイベントに登録し、最近のポッドキャストやTwitchストリームを閲覧し、コミュニティチームや製品チームのメンバーと一緒に新製品やソフトウェア業界の最先端のプラクティスを学べます。

PagerDuty® Process Automation

PagerDuty® Process AutomationソフトウェアとPagerDuty® Runbook Automation 4.5.0

最新のPagerDuty® Process Automation Version 4.5.0には、以下の内容が含まれています。

Sumo Logic Job Step Pluginをリリースしました。Sumo Logicインスタンスと連携することで、インシデント診断のためのログ取得などの運用タスクを自動化できるようになりました。 AWS ECS Node Executor Puglin ユーザーは、単一のジョブステップまたはコマンドタブから、複数のECSコンテナにコマンドを実行できるようになりました。これにより、インシデント発生時にコンテナを再展開する前にタイムクリティカルな診断を取得するなどのタスクを容易に実行できるようになりました。

ハイライトをご覧いただき、プラグインなどの追加アップデートや修正についてご確認ください。

アップグレード、修正、パッケージの更新は、Rundeckオープンソース製品にもあります。それらの詳細や、GitHub で公開されているプルリクエストを見ることができます。

2022年8月10日のNessie Orchid Tower Release (4.5.0)についての詳細はこちら。

パートナーインテグレーションとアプリエコシステム

PagerDuty App for Jira Jira Data Center：マーケットプレイスアプリを１年間正式に再認定

既にPagerDutyをJira Data Centerと統合し、重要なサービスリクエストに取り組み、Jira Serverの課題とPagerDutyのインシデント間を双方向同期してインシデント解決を加速している方に朗報です。私たちはまた、Jira Data Center用のPagerDutyアプリを１年間正式に再認定し、AtlassianマーケットプレイスにおけるData Center Approved Statusを維持しました。

アプリの詳細はknowledge baseでご確認ください。

PagerDutyアプリ for Jira Cloud。Jira CloudのサイドバーにPagerDutyを表示する新オプションを今年９月に提供開始

Jira Cloudの新規顧客には、全Jira プロジェクトでPagerDutyがデフォルトでサイドバーに表示されません。 既存のJira Cloudプロジェクト管理者は、プロジェクトごとに Jiraサイドバー上の PagerDuty を非表示または表示する機能があります。

(上図：Jira CloudでPagerDutyのサイドバーがdisabledにされています)

(上図：PagerDutyのサイドバーをJira Cloudでenabledにできます)

ご不明な点がございましたら、PagerDutyアカウントチームまたはカスタマーサポート([email protected])までご連絡ください。

BMC Helix用PagerDutyアプリ／Remedy：パートナーKTSL社への所有権移管について

PagerDutyは、BMC HelixとRemedyのインテグレーションの所有権を、サービスマネジメントと統合の専門家であるBMC Eliteパートナー、KTSLに移管しました。今後、KTSLがこのインテグレーションをビルドし、サポートします。

製品廃止のお知らせ

今後予定されている製品の廃止について、チームにお知らせください。

Event Rulesの廃止とEvent Orchestrationへの移行

PagerDuty は、2023年1月31日にEvent RulesをEOL (End-of-Life)=停止することを決定しました。私たちは、お客様のために最も堅牢で信頼性の高いイベントドリブンのエンリッチメントとオートメーション体験の構築にリソースを捧げることを確実にするために、この決定を下しました。Event Orchestrationは、Event Rulesの次の進化形として年初にリリースされ、現在では、ユーザーがルールの量を圧縮し、ノイズ除去を改善し、よく理解されている手作業をより効果的に自動化するための最良の方法となっています。

このEOLをサポートするために、十分な移行経路を用意しています。さらに、EOLの日に、あなたが使っている残りのイベントルールをEvent Orchestrationに一対一で自動移行します。それ以降は、現在のイベントルールでできることは、全てEvent Orchestrationでできるようになります。Event OrchestrationはEvent Rulesと同じ機能を持ち、同じバックエンドアーキテクチャーを使用しているので、イベント処理には数十億イベント分のテストが既に実施済みだと確認できます。

(上図：PagerDuty Event Orchestration)

マイグレーションについて詳しくはknowledge baseをご覧ください Event Orchestrationの詳細 アカウントマネージャーへのお問い合わせ

V1/V2 Webhooks

現在、PagerDuty 環境で V1/V2 webhook 拡張を使用している場合、機能を維持するために V3 webhook サブスクリプションに移行する必要があります。

移行ガイドに従ってください。

重要な日程

V1 Webhooks** - V1 Webhook 拡張は、2021 年 11 月 13 日からサポート対象外（新機能やバグフィックスがない）となり、2022 年 10 月に機能停止となります。 V2 Webhooks** - V2 Webhook 拡張は、2022年10月にサポートが終了し、2023年3月に動作しなくなります。

必要なパーミッション

Admins* またはAccount Owners* は、アカウント全体を移行することができます。 Team Manager** は、割り当てられたチームのウェブフックのみを移行できます。

ウェブフックとは何ですか？ ウェブフック（webhook）を使うと、PagerDutyアカウントで重要なイベントが発生したとき、例えばインシデントがトリガー、エスカレート、または解決したときに、HTTPコールバックを受け取ることができます。イベントに関する詳細は、Slackや独自のカスタムPagerDuty ウェブフックプロセッサーなど、指定したURLに送信されます。

ご質問がある場合は、PagerDutyの担当者またはサポートチーム（[email protected]）にご連絡ください。

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

PagerDutyでインシデントを割り当てられたとき、最初にすべきことは何でしょうか？すぐに「受任！（Acknowledge）」と思った方は間違っていませんが、その後は、できるだけ早く、痛みを伴わずに問題を解決することが大切です。解決への第一歩は、最初にインシデントの原因を調査し、簡単に修正策を講じられるようにすることです。 PagerDutyのプラットフォームでは、Root Cause Analysis（根本原因分析）*は、レスポンダーであるあなたにできるだけ多くのコンテキストと実用的なインテリジェンスを提供することを目的とした一連の機能を指します。過去に発生したインシデントや関連するインシデント、インシデントの発生頻度に関する情報を表示することで、レスポンダーは根本原因を特定するために必要な状況認識を素早く得ることができ、迅速なトリアージと、そして最終的には早期解決につながるツールを手にすることができます。また、過去のデータに基づき、発生源と思われる場所がハイライト表示され、状況を把握しやすくなります。 ここでは、インシデントの詳細ページで、潜在的な根本原因を調査するのに役立つ5つの場所を紹介します。

1. Outlier Incident

インシデントを最初に開くとき、［Outlier Incident］分類ラベルを探します。このラベルはインシデント名の直下にあり、"Frequent", "Rare", "Anomaly "のいずれかの分類ラベルが表示されます。この分類ラベルに基づいて、このインシデントが以前に発生したことがあるかどうか、また過去の経験に基づいてどう対応すべきかをすぐに判断することができます。ラベルにカーソルを合わせると、それぞれの定義が表示されます。

2. Past Incidents

サービス上でインシデントが発生した頻度を決定したら、ページのさらに下にある［Past Incidents］タブに移動します。ヒートマップが表示され、このオープンインシデントのような過去のインシデントが過去６カ月間にいつ発生したかが示されます。色のパターンを探す（色が濃いほどインシデントが集中している）か、ヒートマップの色にカーソルを合わせると、関連するインシデントの詳細が表示されます。その下には、オープンインシデントのような過去のインシデント上位５件（もしあれば）の詳細と、それらがいつ発生したか、誰が最後にインシデントを変更したかについての情報が表示されます。注：その人は、インシデントに際して何をしたか尋ねたり、それに関するメモを見たい場合、素晴らしいリソースになります。過去のインシデントの詳細ページを開くには、ハイパーリンクされたタイトルをクリックします。

3. Related Incidents

もう一つの簡単な情報源は、［Related Incidents］タブです。ここでは、同じサービス上の類似のインシデントしか表示されない過去のインシデントとは異なり、全サービスからあなたの問題に関連する可能性のある進行中のインシデントがあるかどうかを確認できます。ビジネス全体のインシデントの範囲（これは孤立したものか、より大きな問題の一部か）を理解することは、影響を理解し、問題を解決するために協力する必要がある人を迅速に特定するのに役立ちます。

4. Probable Origins

インシデントの詳細ページにある［Probable Origins］ウィジェットを使用して、トリアージ作業を素早く始められます。このウィジェットは、インシデントが現在のオープンインシデントの類似イベントの直前に発生したか、または直後に発生したかなどの履歴データに基づいて、発生源の可能性のパーセンテージを計算します。

5. Change Correlation

最後に、インシデントの原因となった可能性のあるインフラやコードの変更に気付いている場合、解決を大幅に加速できます。インシデントの詳細ページの［Recent Changes］に表示される［Change Correlation］は、時刻、関連サービス、PagerDutyの機械学習に基づいて、インシデントに最も関連する最近の変更イベントを３つ表示します。最近の変更イベントには、プラットフォームがイベントを表面化させた理由が表示されるため、潜在的な原因を簡単に絞り込めます。

ナレッジチェック！ 正しいでしょうか、間違いでしょうか？： [Past Incident]タブには同じサービスのResolved Incidentsが表示され、[Related Incidents]には他のサービスのOpen Incidentsだけが表示されます（ページ下部の回答を参照）。

いかがでしたでしょうか？これら５つの、コンテキストをすばやく取得し、トリアージ作業を開始するために調べられる場所を忘れないでください。

インシデントを迅速に解決し、ダウンタイムをさらに短縮するには、この一連のRoot Cause Analysys機能をNoise ReductionとEvent Orchestrationの機能と組み合わせるとよいでしょう。再確認が必要な場合は、PagerDuty UniversityのEvent Intelligenceコースを受講し、Event Intelligence認定を取得して、ハードワークではなく、スマートな作業ができることを証明してください。

次のステップのためのリソース：

Event Intelligenceコースは、PagerDuty University eLearning Portalでご覧いただけます。

Noise Reduction Event Orchestration Root Cause Analysis

Event Intelligence Certification Exam（認定試験）の情報は、このページの "Specialty Product Certification" でご覧いただけます。この新シリーズの発売を記念して、30日間、試験への登録を無料にしますので、今すぐご登録ください。

*脚注：このカテゴリーの機能を「Root Cause Analysis」と呼んでいますが、PagerDutyは根本原因を予測したり特定したりするものではありません。むしろ、PagerDutyの機能は、インシデントに関連するコンテキストを作成し、より迅速な解決を促進するためのものです。また、業界では、真の「root cause」が１つであることを示すような用語ではなく、「probable」cause または「 proximate」causeという用語を採用する方向に変化していることも注目に値します。

ナレッジチェックの回答：誤りです。過去のインシデントは同じサービス上で解決された過去のインシデントのみを表示するという記述は正しいのですが、関連インシデントは全サービス（現在のインシデントが起きているサービスを含む）上で未解決の、または最近解決した他のアクティブなインシデントを調べ、現在のインシデントに関連しているインシデントがあるかどうかを確認します。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

毎年、Radarリポートには驚きに満ち溢れています。私たちと共に、多大な利益を得ている何千ものお客様にとっては驚きではないでしょうが、PagerDutyは2022年のGigaOm Radar for AIOps Solutionsでリーダーに選ばれたことを大変喜んでいます。

GigaOmは、Radarのベンダーを評価するために広範な基準を使用しています。リポートによると 「今年は、既存のツールを置き換える必要があるAIOpsソリューションと、大きな混乱なしにITツールボックスに追加できるソリューションを区別しています」とのこと。これは、PagerDutyがLeaderに位置付けられ、Tool DisplacementでOutstanding と評価された鍵の一つです。

Time to ValueとTCOは、かねてよりPagerdutyのビジネスバリューの特徴です。お客様はPagerDutyを信頼して、既存のシステムを取り替えることなく、迅速にその価値を最大化することができます。 私たちのSaaSプラットフォームは、シンプルなセットアップ、素早い統合、使いやすいイベントルーティングとエンリッチメントを提供し、これらは全て「導入の容易さ」の優れたスコアにとって重要な要素となっています。

650以上の統合機能を持つPagerDutyは、データ消費、システム統合、クラウド監視の分野で「Exceptional」と評価されました。このような幅広い機能により、実務担当者は事実上カスタマイズの必要なく、迅速な価値創造を実現することができます。UI、Terraform、APIプロバイダーにより、専門家はモニタリング、CI/CD、DevOps、セキュリティー、BizOpsなどの全てのデータソースを活用し、新しいチームメンバーでも迅速に問題を解決するために必要なåコンテキストを作成することができます。 当社のEvent Orchestrationは、シンプルかつ強力なルーティング、エンリッチメント、問題への自動応答を可能にします。膨大で複雑なルールベースからシンプルなノードベースのグラフルーティングに移行することで、SREとDevOpsチームは、コンテキストを作成し、診断を提供し、必要に応じて自動的に問題を解決するためにイベントを使用する方法を正確にコントロールすることができます。シンプルなグラフィカルインターフェイスは、簡単な実験的方法を提供し、基盤となる Terraformプロバイダーはセルフサービス機能を可能にし、中心チームから負担を取り除くことができます。この総合的なセルフサービス機能は、「Manageability」で「Outstanding」と評価されました。

GigaOm は、AIOps に対する自動化優先のアプローチの優位性を認識しました。Rundeck と Catalytic の買収により、当社のプラットフォームは、ビルトインのAutomation Actionsと柔軟なワークフローという形で、プラットフォーム全体に包括的な自動化の統合を提供することができるようになりました。人とマシンのワークロードのバランスをとることは、生産性を維持し、燃え尽き症候群を防ぐために重要です。インシデント解決の最初のレスポンダーとして自動化を活用することで、労力を軽減し、解決までの時間を短縮することができます。レスポンダーが必要ない場合、一般的な問題の兆候を特定し、自動修正により機械の速さで処理することができます。自動修復はごく一部のよく知られた修正に対応できますが、多くの場合、自動化はインシデント対応と調査の中心であるレスポンダーを補強する、第二の手の役割を果たします。 Radarはまだ1年目ですが、ここ数年のEvent Intelligenceの成功に基づき、お客様のために機能を拡張し、新たなビジネス成果を提供することに全力を注いでいます。今年は、お客様のために200億件以上のイベントを処理する予定です。SaaSプラットフォームとしての長年のデータを活用し、お客様がどのようにノイズを減らし、問題を解決しているかを理解することで、機械学習、自動化、分析を拡大し、チームは生産の維持とよりよいソリューションの提供に集中できるようになりました。

リポートはこちらからご覧いただけます。また、PagerDutyのAIOps向けソリューションの詳細については、こちらをご覧ください。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

本日、Dedicated Incident Slack Channelの改良版のアーリーアクセスを開始することができました。この改良は以下の通りです。

全てのインシデントの詳細、履歴、およびアップデートを表示する 全てのインシデントアクションを実行する 全レスポンダーをチャンネルに追加する ズームコンファレンス専用ブリッジの掲載または作成

この機能を利用するためには、Slack on WebHooks V3にアップグレードし、PagerDutyサポートにアーリーアクセスをリクエストする必要があります。 正しいバージョンでアーリーアクセスができたら、専用のインシデントチャンネルを作成する方法が2つあります。

1. Slackにて

Slackのインシデント通知から、「View | Create Channel」を使用して、デフォルトのネーミングスキーマで新しいインシデント専用チャンネルを作成します。チャンネルがすでに存在する場合は、チャンネルのハッシュタグが付いたメッセージが投稿されます。

2. PagerDuty Web 経由

Incident Pageで、「Set the Channel」でチャンネルを設定する。アーリーアクセス中は、「BETA」タグが表示されます。

その後、ユーザーは既存のチャンネルを選択するか、新しいSlackチャンネルを作成することができます。

新しいチャネルを作成する場合、ユーザーはデフォルトの名前を受け入れるか、新しい名前を割り当てることができます。チャンネルは公開にも非公開にも設定できます。

注：PagerDutyアカウントに複数のSlackワークスペースが接続されている場合、ユーザーはチャンネル接続に必要なワークスペースを選択することができます。

作成すると、PagerDutyのウェブのUIとSlackではこのように表示されます。

この新機能を活用していただくことを期待するとともに、ご意見をお待ちしています。

次はどうする？

この機能は、Slack on Webhooks V3をご利用の全てのお客様に対して、来月には公開する予定です。

また、チャンネル作成の効率化・自動化により、この機能の充実を図っています。

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

2020年は、私たちの働き方に革命をもたらしました。多くの人が一夜にして、フルタイムのオフィスワークから100％リモートワークへと移行しました。そして今、再びオフィスでの仕事が視野に入ってきたため、企業はフレキシブルな働き方を継続する方法を考えています。しかし、これには課題が増え、この働き方に合ったツールが必要とされています。

PagerDutyのモバイルアプリケーションは、App StoreやGoogle Playで星4.8の評価を得ており、高い認知度を誇っています。私たちは、適切な人にすぐに連絡することがいかに重要かを理解しています。だからこそ、レスポンダーがいつでもどこでも重要な仕事を解決できるように、iOSとAndroidに多大な投資を行ってきました。

このブログ記事では、最も必要な情報を見つけるための新しいナビゲーションインターフェース、過去および現在のインシデントを通じたインシデントインテリジェンスの向上、自動診断の起動と修正アクションを実行するための自動化の活用など、最もエキサイティングな改善点をいくつかご紹介します。

必要な情報を簡単に見つけられる

レスポンダーは、自分がいつオンコールになるのか、どのようなサービスのためにオンコールになるのかを知る必要があります。万が一、呼び出しを受けた場合、自分が担当する技術サービスがどのように機能しているかを確認できることが極めて重要です。そして最も重要なことは、これらの情報をモバイルアプリから一目で確認できることです。複数の画面を参照したり、アプリの奥深くに埋もれた情報を探したりする必要はありません。

新しいPagerDutyモバイルホーム画面エクスペリエンスでは、レスポンダーが必要とする最も重要な情報が容易に利用可能です。このデザイン変更により、オープンインシデント、オンコールシフト、影響を受けるテクニカルサービスを中心に表示し、アプリ内のナビゲーションに必要なタップ数を減らすことができます。

デザイン変更されたホーム画面は、現在、早期アクセス可能です。試してみたい方は、この早期アクセスフォームに必要事項を記入し、「新しいモバイルホーム体験」の選択をすると、案内が送られてきます。

フレキシブルに働くということは、最も重要な瞬間に、クリティカルインシデントの状況を自由に把握できることを意味します。インシデントが発生したら、できるだけ早く対応し、影響を軽減するための最善の方法を決定する必要があります。

その方法の１つが、新しいモバイルインシデント詳細画面です。この画面では、視覚的に分かりやすく、最も重要な機能全てにアクセスできるため、インシデント対応に迅速に取り組むことができます。インシデントで作業している他のレスポンダーのメモ、変更イベント、過去のインシデント、最新のアラートなど、インシデントに関する最も重要な情報をすぐに利用することができます。

また、更新版のモバイルインシデント詳細画面にある新しいカルーセルでは、プレーの実行、優先度やメモの追加、ステータスアップデートの投稿などを行うことができます。

過去または現在におけるクリティカルインシデントのコンテキストを獲得する

インシデントが発生したとき、最大のハードルの１つは、「以前にもあったか」という質問に答えることです。もしあれば、以前に動作したプレーを実行したり、自動化シーケンスを実行することで簡単に解決できるかもしれません。しかし、そのような過去の状況を見つけることはしばしば困難であり、それは誰にも許されない無駄な時間です。

PagerDutyモバイルアプリのPast Incidents（過去のインシデント）機能では、現在アクティブなインシデントと同じサービス上で発生した、類似したメタデータを持つインシデントが表示されます。この追加コンテキストにより、正確なトリアージが容易になり、解決までの時間が短縮されます。例えば、自分やチームの誰かが過去に同様のインシデントに巻き込まれたことがあるかどうかを確認し、詳細を調べてどのような改善策が取られたかを知ることができます。 Change Events（変更イベント）。システム内の変更は、しばしばインシデントの影の犯人です。特に、多くの組織が１日に何十回、何百回も新しいコードを出荷している場合、どの変更がインシデントを引き起こしたかを正確に特定するのは難しいため、見過ごされがちです。しかし、「Gartner社の推定によると、全てのパフォーマンスインシデントの約85％は追跡可能」です。変更イベントにより、お客様の環境に影響を与える変更を確認し、潜在的な根本原因を特定することができます。変更イベントは、モバイルアプリの２つのエリア（新しいモバイルインシデントの詳細画面と、サービスの詳細画面）で簡単に確認できます。目的のインシデントをタップして変更イベントにスクロールするか、サービスディレクトリーに移動してサービスを選択し、最大２つの変更イベントを表示できます。表示されるイベントの詳細には、日時、概要、サービス、タイプ、リンク、ソースが含まれます。 インシデント対応におけるもう１つの重要な情報は、問題の影響範囲を理解することです。この情報を得るための１つの方法は、Service Dependencies（サービス依存関係）を理解することです。大規模で顧客向けのビジネスサービスが、技術的なサービスインシデントによって問題が発生している場合、問題の範囲をよりよく理解するために、より速く、より文脈的なインテリジェンスで対応する必要があります。モバイルアプリのサービス依存関係画面では、どのサービスが影響を受けるかを表示して、範囲をよりよく理解することができます。サービス依存関係は、サービスディレクトリーの各サービスのプロファイル内に表示されます。

自動化を活用した迅速な対応

テクノロジー環境がより複雑になるにつれ、人々の時間と認知資源を節約することがこれまで以上に重要になっています。これは、人間ではなく、機械が最初の防衛線として機能することを意味します。

反復的な手作業やよく理解されている事象を自動化することで、対応者の不必要な労力を軽減し、本業に集中できるようにし、最も必要とされている事象にのみ注意を向けるようにできます。これを実現する１つの方法が、指先のタップで実行できる自動化です。

PagerDuty Automation Actionsは、PagerDutyモバイルで一般的に利用できるようになり、いつでもどこからでも自動診断と修復アクションを実行できるようになりました。繰り返し行われる診断と修復のステップを自動化することで、手動で行っていた作業を代替し、生産性を向上させることができます。スクリプトを実行するだけでなく、過去に実行したスクリプトや出力レポートをモバイルアプリから直接表示することができます。これらはリアルタイムで更新されるため、見落としがありません。

PagerDutyモバイルアプリケーションに追加されたこれらの最新機能は、時間、品質、顧客体験を犠牲にすることなく、レスポンダーが思い通りに作業できるよう支援します。フレキシブルな働き方は今後も続きます。PagerDutyの強力なモバイルアプリケーションは、あなたがそれを最大限に活用できるよう支援することを約束します。PagerDutyのモバイルアプリケーションをまだお試しでない方は、今がチャンスです。QRコードを使って、どちらかをダウンロードしてください。

iOS

Android

重要：モバイル体験の安全性を確保するために

PagerDutyモバイルに多くの新しい素晴らしい機能が追加されました。モバイルアプリが革新的で安全であり続け、ユーザー体験を向上させるために、新しい最小システム要件を導入します。2022年6月27日より、PagerDutyモバイルアプリの将来のバージョンでは、Android 9.0かiOS 14.0以降が必要となります。モバイルアプリのアップデートを継続的に受信するために、お使いのデバイスが最新に保たれていることをご確認ください。

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

AIOpsは、機械学習と人を組み合わせ、IT運用で技術的成果を実現するものです。この能力への期待が新たな競合を市場に送り込み続けています。AIOpsは、あらゆる主要なイベント管理プレーヤーにとって、メッセージングの中核となるコンポーネントとなっています。多くの企業が自社製品のブランドを変更し、AIOpsの機能を特に強調するようになりました。新興のイベント管理プレーヤーも登場し、AIOps市場に場を確保しようと試みています。ほぼ全ての観測可能なAPMベンダーが同じことを行い、自分たちが今、AIOpsツールとして選ばれていると主張しています。

AIOpsとは何か？

しかし、一歩下がってほんの少し現実を見てみましょう。AIOpsはツールではなく、一連の機能です。したがって、製品セットとしてのAIOpsを定義することは困難です。これは、自分のツールがDevOpsのツールとして選ばれていると主張するのと同じようなものです。業界をリードするアナリストでさえ、AIOpsの中核となるアプローチは何か、AIOpsの特定のヒューリスティックは何かについて、同様に意見の相違があります。このような意見の相違はあるものの、私たち実務家は、大多数のAIOpsソリューションを２つの中核的な陣営に分類して考えることができます。

オプションその１：アプリケーション監視

アプリケーション監視ツールは、最初の陣営を所有しています。この監視中心のアプローチは、メトリクス、KPI、ログなどを活用し、機械学習と傾向分析を使用して予測を行い、より早くスマートなアラートを出せるようにすることを目的としています。良い点は、全てを監視することで、根本的な原因に近づける可能性があることです。一方、デメリットは、監視を複製することになるか、これらのツールセットを活用するために現在のツールセットの大部分を削除して交換しなければならないことです。さらに、ネットワーク、ストレージ、アプリケーション、パフォーマンスモニタリングなど、全てを１つのツールで監視することは、特に「十分な」監視ツールを置き換える場合、コストがかかる可能性があります。

オプションその２：イベント管理

2つ目のアプローチは、イベント管理です。このソリューションのグループは、異なるモニタリングを統合することでドメインにとらわれない視点を維持し、単一の管理画面の結果に焦点を当てた集中型NOCの能力タイプに行き着くことになります。このアプローチでは、全ての異種情報を一元化することで、理想的にはより良い意思決定を行うことができると期待されています。しかし、ルールを更新するために一元化された場所を持つ必要があるため、能力のボトルネックになってしまう可能性があります。さらに、多くのベンダーがピーク時の使用量、１日の平均使用量、ノード数、イベントソース数などのデータに基づいて異なる料金指標を設定しているため、ソリューションのサイズ設定が難しい場合があります。

どちらのアプローチも抜け落ちているのは、「完璧な」根本原因を突き止めることができても、「さあ、どうする？」がないことです。どのように問題を解決するのか？これらのソリューションを使用するチームは、実際の銃撃戦に役立つ重要な質問をまだ残していることになります。どのサービスが影響を受けているのか？そのサービスの所有者は誰か？誰がそのサービスのために待機しているのか？どのような診断が必要なのか？どのような自動化が可能か？

これらの答えが見つからないと、サービスを復旧させるのに苦労することになります。

より良いAIOpsソリューション

PagerDutyは、ほとんどのAIOpsソリューションが無視しているリアルタイムの作業の問題を解決するために、この課題に取り組んでいます。私たちは、ノイズを減らし、根本原因を特定するためのコンテキストを作成し、労力を削減しサービスを回復するための自動化を促進します。PagerDutyを利用することで、チームはフルサービスのオーナーシップアプローチを活用し、ビルダーやイノベーターが競合他社よりも早くソリューションを市場に投入し、顧客のために価値を繰り返し提供できるよう支援します。PagerDutyは、お客様が既にお持ちのツール、チーム、機能を活用し、デジタルトランスフォーメーションに向けた幅広い戦略的優位性の構築をサポートしながら、戦術的な運用を迅速に実現するお手伝いをします。

自動化ファーストアプローチ

私たちの自動化ファーストのアプローチは、私たちのランブックオーケストレーションプラットフォームであるRundeckを第一レスポンダーとして活用することで、あなたのチームの働き方を変えることができます。Rundeckを使うことで、チームを動員することなく問題を解決できることがたくさんあります。この自動解決はMTTRを大幅に改善しますが、それと同じくらい重要なのは、各分野の専門家が本業に集中できるようにすることです。自動化が問題を即座に解決できない場合は、自動診断により、影響を受けるサービスと顧客への影響とSLAへの影響を第一レスポンダーが理解できるようにコンテキストを作成できます。そうすることで、ログ、スクリプト、手順から情報を収集し、自動化対応を推進するための指針とすることができます。これにより、全体の監査証跡が作成され、事後検証やITSM問題管理を改善し、将来、同様な問題が発生するのを避けられます。

私たちのプラットフォームは、大規模な組織や複数のチームがセルフサービスで管理できるように、API設定機能を活用しています。そのため、ルールの更新や設定の管理を中央のチームに依存するのではなく、管理者はリポジトリーやTerraformなどのツールを活用し、チームが必要とする更新を迅速に入手できるようにすることができます。中央のチームの力だけに頼って渋滞を起こすことを避けられます。

自動化を優先したデータ駆動型のセルフサービスアプローチにより、チームと機械学習が一体となって問題を解決し、根本原因を見つけるだけでなく、AIOpsの真の約束を実現できると信じています。このドメインにとらわれないアプローチでは、適切なタイミングで適切な情報を適切な担当者に提供することに集中できます。アクションを実用的なインテリジェンスに置き換えることで、ノイズやアラート疲れを減らし、第一レスポンダーが問題を解決できるようにし、労力を削減し、ビルダーやイノベーターがインシデントを追いかけるだけでなく、新機能を提供できるように変えられるのです。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

本日は国際女性デーということで、オーストラリアの技術職の女性たちにスポットライトを当て、特にDevOpsのキャリアに焦点を当てる、待望の機会となっています。

昨年６月、LinkedInはDevOpsエンジニアを最も需要の高い職種第10位に挙げ、最近の求人レポートでは情報通信技術（ICT）分野の職種が業界で最も高給であることが判明しました。

エンジニアリングに限らず、さまざまな職務におけるDevOpsエキスパートの需要は、飛躍的に高まっています。プラットフォームやアプリケーションが記録的なスピードで出現し、進化していく中で、これらの職務は、女性が国内外で大きな成功を収めるのを目にすることができます。

テック業界は、自動化の進展に伴い、今後数年間で他のどの業界よりも急速に成長すると思われます。技術系、非技術系を問わず、金融サービス、小売、教育などの分野でキャリアの機会が増え続けており、COVID-19はこれをさらに加速させるものです。しかし悲しいことに、Australian Computer Societyの最近の統計によると、オーストラリアの技術系労働者に占める女性の割合はわずか29％に過ぎません。

オーストラリアでは、科学、技術、工学、数学（STEM）のあらゆる段階で、才能のある女性が失われています。また、調査によると、女子は６歳でSTEMから離れることが分かっています。これは主に、目に見える女性のロールモデルがいないことや、STEMの専門家が何をするのかが理解されていないことが一因となっています。

しかし、2022年現在では、イノベーションの機会が最前線にあり、キャリアパスについて女性の意識を高める余地が大いにあります。

これを受けて、PagerDuty APJは、技術分野の女性に焦点を当てた地域プログラムを立ち上げました。これはWomen in Technologyの地域支部から始まり、PagerDutyの広範なプログラムであるSisterDutyの一部を形成しています。さらに、四半期に一度、メンターと若いメンティーがペアを組み、知識やアドバイスを共有するメンターシップミートアップを開催しています。

外部からは、STEM分野の若い女性を支援するTech Girls Movement Foundationとパートナーシップを結び、毎年開催されるNext Tech Girl Superheroコンテストでメンターや審査員として協力することにしています。

女性だからといってチャンスは限られていませんし、むしろ増える一方だと思います。女性リーダーは異なるスタイルのマネジメントを組織にもたらしますが、私はこのカルチャー、共感、成功に焦点を当てたスタイルにチームがよく反応すると思います。

技術やDevOpsのキャリアを考える女性を鼓舞するために、私は３つのアドバイスをしています。

じっくりと正しい道を探ってください。テック業界は、女性にとって素晴らしい機会を与えてくれます。時間をかけて探索し、充実感と感動を与えてくれる道を探してください。 選択肢を研究してください。オーストラリア国内のテック業界は、多くのエキサイティングなスタートアップ企業で活況を呈しています。よく調べて、選択肢を検討しましょう。リスクをとることを恐れないでください。この業界に入れば、可能性は無限に広がります。 あなたの声を届けましょう。この業界に多様な視点を持ち込むことは、非常に歓迎されるでしょう。現状を打破し、新鮮なアイデアと思考をもたらすことを恐れないでください。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

クラウドや関連技術への支出が急増した２年間を経て、2022年は企業のITおよびデジタルリーダーにとって正念場となります。テクノロジーへの投資は、大規模なハイブリッド勤務への急速な移行を促進し、ニューノーマルのデジタルファーストモデルを採用するビジネスを支援しました。しかし、新しい働き方を支えるための単なる投資だけでなく、リーダーは組織が革新を続けることを保証する必要があります。

これは非常に重要なことです。マッキンゼーの調査によると、リーマンショック後でもイノベーションを重視する組織は、市場平均より30パーセント以上も業績を向上させたことが分かっています。デジタルサービスの競争環境では、立ち止まるという選択肢はないのです。では、どうすればデジタル革新を加速させ、2022年に成功することができるのでしょうか。

重要なのは、開発者の生産性を具体的に向上させ、複雑さを軽減するようなイノベーション関連の投資を選ぶことです。そして、そのためには、３つの明確な攻め手があります。先進的な企業は、開発者の支援に焦点を当て、インフラについて実用的であり、「複雑さ」について現実的です。これらの分野を探ってみましょう。

1. 開発者の生産性向上への投資 開発者は、デジタル革新の原動力となる存在です。しかし、手作業による設定や管理が必要な扱いにくいツールを使っていることがよくあります。大手企業は、開発者の生産性向上に投資することで、この問題に取り組んでおり、多くの場合、「開発者ツール」チームを新設しています。このチームの取り組みには、開発者をラップトップからGitLab/GitHubなどのクラウドベースのDevOpsやCI/CDプラットフォーム、GitHub ActionsやCodespacesなどの機能へと移行させることが含まれています。なぜでしょうか？それは、アプリケーションのアーキテクチャーが複雑化し、計算能力に対する要求が大きくなりすぎて、現在のやり方を続けることが難しくなったからです。

開発者にとってよくある問題は、「自分のラップトップでは動くが、本番では動かない」というものです。新しいクラウドベースの開発者環境は、この問題を解決します。本番環境と同じ規模の複雑なシステムをクラウド上で実現し、開発者の増強されたノートパソコンと同等かそれ以上のパフォーマンスとパワーを提供します。さらに、クラウドベースの環境は、継続的インテグレーションだけでなく、未だに悩ましい問題である継続的デリバリーへの道筋を容易にするのに役立ちます。

重要なことは、開発者の生産性に投資すれば、収益も向上するということです。調査によると、開発者の生産性が高い企業は、生産性の低い企業に比べて最大で５倍もの収益増加を達成しています。

2. 「インフラ」の過剰設計を避ける 調査によると、現在92%の企業がマルチクラウド戦略を取っていることが分かっています。しかし、多くの場合、これは競争上の優位性につながっておらず、より良いイノベーションに寄与していません。IDCによると、79％の企業がマルチクラウドのメリットを実現するのに苦労しており、作業負荷がサイロ内に留まっているといいます。

これは、企業がマルチクラウドに取り組む際に間違った理由に基づいてベンダーを選択する場合に起こります。「ロックイン」を回避しようとするあまり、最善の機能を選んでいません。将来はハイブリッドクラウドが主流になる、マルチクラウドではないと認識している企業こそが、2022年以降に成功を収めることができるのです。

ここで必要なのは、健全な実用性です。賢明なエンジニアリングリーダーは、「ベンダーロックイン」の心配に負けることなく、そこで利用可能な機能に基づいて、自分たちのコードに適したインフラ環境を選択することになるでしょう。このようにして、企業は社内で利用できる限られたスキルを最大限に活用し、クラウドプロバイダー間で複数の同一環境を複製するために貴重なエンジニアリング時間を費やすことなく、イノベーションに専念できるようになるのです。 3. 複雑さを極限まで減らす より革新的な顧客体験への要求は高まる一方です。しかし、その反面、複雑さが増大し続けることはありえません。現代の企業は既に何百万もの依存関係を持つ何千ものデジタルサービスを動かしており、マイクロサービス、コンテナ、サーバーレスアーキテクチャー、オーケストレーションプラットフォームが網の目のように張り巡らされています。

システムの複雑さには「ダンバー数」というものがあり、私たちはそれに急速に近づいています。いくつかのアプローチに対する反発の最初の兆候が現れています。例えば、Kubernetesは、ビジネス価値を提供するために多くの表面積を必要とします。また、CSPが提供するマネージドサービスを採用する企業も増えています。これらのサービスは、自社で設計することなく、最初から拡張性、信頼性、冗長性を提供します。

複雑さに対抗するためには、他に２つの重要な要素があります。１つ目に、リアルタイムの依存関係管理に投資して、エンジニアがデジタルシステムの関連性を明確に把握できるようにすることです。２つ目は、タスクを実行する必要がある人から「内側の複雑性を隠す」ために、自動化に投資することです。これにより、チームはデジタルインシデントをリアルタイムで監視、管理、是正することができます。PagerDutyの調査によると、技術系リーダーの73%が、複雑さとデジタルサービスに対する圧力の高まりに対処するため、自動化に投資している、または投資する予定であると回答しています。

イノベーションの強化 2022年にデジタル革新を成功裏に加速するために、組織は開発者の時間を解放し、単に「明かりを灯し続ける」のではなく、彼らがベストを尽くし、イノベーションを起こすことができるようにしなければなりません。リーダーを目指す企業にとって、この３つの領域は成功のための青写真となります。

DevOpsのサポートからクラウド戦略、自動化まで、PagerDutyがどのようにデジタルイノベーションの加速を支援できるかを知るには、https://www.pagerduty.com/ をご覧ください。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

PagerDutyでは、お客様を最優先にすることを約束します - これは会社のコアバリューです。私たちの製品は素晴らしい価値を提供し、優れたサービスを提供し、そして私たちとビジネスをすることをシンプルにする必要があります。

2022年冬のG2 Grid for AIOps Platforms Relationship Indexは、これらの価値を紹介し、PagerDutyをAIOps分野のリーディングプレーヤーとして取り上げています。

AIOpsの展望が進化し続ける中、PagerDutyは、よりインテリジェントで自動化されたオペレーションを実現するために、お客様の成功を促進することに力を入れています。ドメインにとらわれないアプローチで、戦略的な投資に基づいて構築することで、「壊して取り替える」という考え方ではなく、組織が観察可能性やその他の監視ツールで成し遂げてきた成功をさらに後押ししています。PagerDutyは、組織内に既にある戦略遂行能力を基に構築することに重点を置いており、ワークフローと連携して大きな価値を提供するために、再調整やわずかな改善点を探すことはしません。

私たちの顧客は、数秒という短い時間で適切な情報を適切な人に届けるためのサービスとしてPagerDutyを信頼しています。AIOps機能の加速は、この約束の実現を加速させ続けてきました。

昨年のレポート以降、AIOpsの領域で導入した新機能は以下のとおりです。

自動化とオーケストレーションのためのRundeckの機能を追加し、チームが安全にセルフサービスオペレーションを実行可能に コンテキストと状況認識のため、数少ないシステムからの変更イベントを、事実上あらゆる構成または展開ツールに統合 過去のインシデントと変更イベントのビューを統合し、モバイル機能を拡張 イベントのスループットを40倍に向上 イベントオーケストレーションの導入により、ルール管理を簡素化し、複雑なネスト化されたロジックを比較的容易に作成可能に イベントやインシデントがサービスに与える影響を理解しやすくするため、グラフィカルなサービスマッピングを開始 考えられる原因（Probable Cause）を示唆し、問題解決の出発点としてチームを特定のサービスに誘導し、MTTRを短縮

PagerDutyは、AIOpsの約束を実現するために、Actionable Intelligenceの推進に注力しています。PagerDutyのAIOpsソリューションにより、チームは数年にわたる実装を待つ必要はなく、PagerDutyは今すぐペインポイントの解決を応援することができます。

私たちのソリューションは、データサイエンティストを必要とせず、簡単に始められ、価値創造までの時間が短いため、チームがより良い、データ主導の意思決定を行えるよう支援します。** サービス、レスポンダー、インシデント、監視などに関する深い洞察を提供することで、チームはプラットフォームの専門家でなくても、より良い運用上の意思決定ができるようになります。私たちが独自のデータセットを使って開発したMLとデータサイエンスのアルゴリズムは、ノイズの低減、根本原因の迅速な分析、自動化を可能にし、チームはすぐにでもその恩恵を受けることができます。 プラットフォームを誰でも使いやすくし、分散チームやハイブリッド運用モデルに合わせた分散構成で、セルフサービスオペレーションを実現します。** PagerDutyのAIOpsは、中央のITチームには診断と自動修復を実行するための簡単なボタンを、開発チームには根本原因のトラブルシューティングを行うための合理的な方法を提供し、600以上のインテグレーションパートナーによってあらゆる技術スタックにシームレスに適合します。 インシデント対応のライフサイクルを通じて、自動化された次善の策を提案します。** イベントオーケストレーションでは、より少ないルールでよりスマートにネストされたルールを提供することで手動処理を削減し、インシデントの詳細と同時に考えられる原因や関連する変更を表示し、Rundeckを活用してエスカレーションの回数を減らし、インシデント解決を自動化します。

AIOpsソリューションの詳細については、こちらをご覧ください。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

PagerDutyで、私たちはDevOpsコミュニティとITプロフェッショナルが成功するために、どのように支えることができるかを考えて多くの時間を費やしています。私たちは、DevOpsの実践の進化のやり方と理由、実務家に価値を提供する方法、PagerDutyに高い信頼を寄せているコミュニティにどのように役立つのかについて、特に興味を持っています。

このことを念頭に、私たちは最近業界リーダーを対象としたWebセミナーを開催し、最新の実践とDevOpsの将来に関する予測を共有するよう求めました。 APMだけでなく、アプリケーションやセキュリティ監視の世界の視点を取り入れ、デジタル運用管理についての洞察を得ました。このグループには次の人たちが参加しています。

Ilad Rabinovich氏、Datadogの技術コミュニティ担当ディレクター Chris Gervais氏、Threat StackのエンジニアリングVP John Rakowski氏、AppDynamicsのプロダクトマーケティングディレクター Arager Chakrabarti氏、PagerDutyのエンジニアリングディレクター

私たちは、「DevOpsがやがて主流になるか？」とか、「エンタープライズ企業がDevOpsのプラクティスを採用することはできますか？」など、DevOpsの将来に関する多数の質問を検討しました。パネリストは多くのことをシェアしてくれたので、その中から、私たちは以下のハイライトを得られました。

DevOpsはやがてメインストリーム化するのか？

各スピーカーは、DevOpsがやがてメインストリーム化するのかということに関して考えを述べました。

DatadogのIlan Rabinovich氏は、ツールの普及、関連カンファレンス、マーケティング活動の環境全体を上げて、この産業はDevOps用語でいう「ピーク使用量」を達成したとコメントしました。 彼はさらに、誰もが同じ方法でDevOpsの言葉を使用しているわけではなく、真のDevOpsは “CAMS” definition:に定義されれいるような、文化、自動化、定量化、共有などによって証明されると指摘しました。

Threat StackのChris Gervais氏は、普及が遅れたとしてもDevOpsという言葉は確実に主流になると認めました。彼は、多くの組織や特定の種類の企業にとって、DevOpsはその活動のファブリックに組み込まれていることを提示しました。特に、SaaS製品を作っていスタートアップとファームには、DevOpsを一種の基盤となる固有の機能として活用しており、DevOpsのアプローチはまったく新しいものではなく、そうした企業の創業物語の一部になっています。 infrastructure as codeの考えに沿い、素早く進歩したい企業はコミュニティと同じくDevOpsツールの有用性を取り入れています。最近のTechCrunch の記事ではDevOpsは廃れたと宣言されたが、今やメインストリーム化しているはずだ、という冗談も口にしました。

AppDynamicsのJohn Rakowski氏は、DevOpsのメインストリーム化を「はいといいえ」という提案の一種とみなしています。同氏は、他のパネリストと意見を交わすことなく、DevOpsについて聞き取ること無しでは何処へも行けないと同意し、2016年までにDevOpsが主流戦略になるという2015年のGartnerの予測について言及しました。現実はあまり緊密に連携していなくても、Rakowski氏はメインストリーム化できると信じていましたが、 DevOpsの定義に関する継続的な闘争と議論は、特にさまざまな業界や組織にわたって残っています。彼は、エンタープライズ企業のDevOpsとスタートアップ企業のDevOps、DevOpsのメリットを得るために別々のチームを作成している企業などの有意義な違いを見分けました。

Arup Chakrabarti氏は、DevOpsは中小企業にとって「まさにそのままの存在です」と述べています。既存の企業にとって、DevOpsは標準ではありませんが、多くの企業は進化してあります。彼は、遅くて煩わしいことで知られている銀行や通信事業者の中には、DevOpsをポケットに入れて素晴らしい仕事をしていると指摘しました。しかし、彼は、DevOpsコミュニティが企業内でメインストリーム化できるためにはもっと多くの作業を行う必要があることを示唆しています。

エンタープライズ組織はDevOpsプラクティスを採用できますか？

エンタープライズ企業でDevOpsを採用するという問題で、Rabinovich氏は、採用とは技術よりも文化や組織の整合性のことだと感じています。 エンタープライズ企業では、ビジネスユニットやプロジェクトに割り当てられた別個のITチームが行動目標や営業目的などの共有によって内紛調整を対処できるサイロを作成することができます。

Rabinovich氏は「DevOpsの成功した組織は、まず文化と共有に取り組んだ後、ツールやメトリックを使って旅を加速しました。」とコメントしました。彼は市場にはテクノロジー製品を攻撃するために、ツールや、イベントや他のソリューションを販売していますが、文化と共有はメインストリームをもっと集中すべきエリアだと感じています。 DevOpsツールを購入することも一つのことですが、チームが共同の文化を構築していないと、データを共有できても進歩がほとんどなしで、学習も難しくなるとIlanは示唆しています。彼の見解では、CAMSモデルを活用し、共通の目標を特定するために共同作業をすることは、組織の成功への鍵となる道筋です。これは、アライメントと効率性を高め、追加リソースの確保につながる成功を追跡して共有する方法を生み出すからです。

Threat StackのGervaisは、エンタープライズの採用の聴衆からの、DevOpsは上から下、それとも下から上へ押し上げられているのか　という質問に対応しました。.Gervaisは、これはただのCIOが DevOpsで “ready set go” というようなケースではなく、その代わりにmiddel outプロセスだと言えます。つまり、DevOpsはITチームの一部だけではなく、何人かの同好の一人一人がビジネス上の問題に集中するときに成長します。ビジネス上の問題に取り組まれる時、チームはDevOpsモデルの実験やテストを行い、従来のエンタープライズプロジェクト計画から外れる可能性のあるメトリクスを確立することでメリットを得られます。 Gervaisは、DevOpsが伝統的なIT組織やPMO組織に由来する場合、本質的に開始能力に制限があることを示唆しています。

Rakowskiの観点から見ると、エンタープライズ企業全体でDevOpsを実装することは、　　

「DevOpsの採用はエンタープライズ企業全体でどのように進んでいますか？」などの質問を見て究極の問題とみなされています。ソフトウェアは顧客インタラクションと従業員の生産性を高めルための中心部であり、アプリケーションはビジネス成果を上げるようにします。そのように、技術がビジネスパフォーマンスの第一ドライバーとなっているため、より速いリリースが必須であるという現実があります。 DevOpsを実装しているRakowski州は、エンタープライズにとっての選択肢ではなく、ユーザーにサービスを提供し、ビジネスに価値をもたらすためにITが果たさなければならないことである。

PagerDutyのChakrabartiは、DevOpsの採用は、彼が考えるエンタープライズ企業が直面する最大の課題の3つ：文化、共有、アライメントによって推進されていることを示しています。 Opsチームは安定性に集中し、開発チームはイノベーションと変化に焦点を当てているため、根本的に不安定であり、異種のグループが組織内でサイロを作成します。結果として、彼は、サイトの信頼性と革新のバランスをとるビジネスの成功に焦点を当てた共通の目標を通じて、整合性を確立する強い必要性を認識しています。

マーケット上の雑音を除いて、パネリストはDevOpsがメインストリームかし、2017年以降にエンタープライズに移行していることに同意しているようです。 共有や文化の変革など、採用を推進する重要な要素は、DevOpsイニシアチブの基本要素であり、アライメントは成功と同じ傾向にあります。

このブログシリーズの次回の記事では、「中央オペレーションチームがアプリケーションコードベースに近づくのか」、「セキュリティがDevOpsの運用モデルの一部になるのか」など、さらに重要な質問について検討します。

その間、BrightStudioのデベロッパーズウェブセミナーの2017年の予測と傾向全体をチェックしてください！

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

DevOpsへの移行は、どこから始めればよいのかわからない多くの組織にとって、大変な作業になる可能性があります。私は最近、どんなソリューションが市場に出回っているかを知るために、いくつかのDevOpsの評価を読んでみました。それはDevOpsを完全に採用している組織から、まだ始めたばかりの組織までありました。評価の中には真の価値をもたらし、文化や方法論に関する記事にリンクしているものもあれば、DevOpsのすべての夢を実現するためのツールを提供してくれるというものもありました。

DevOpsの過程では、ユーザーがサービスを継続的にデリバリーし、自動化し、サービスを監視することを可能にするソフトウェアとしてのツールは不可欠です。ただし、DevOpsは製品ではなく、ツールだけではDevOpsの価値を十分に理解するために必要なプロセスを得ることができません。DevOpsでは人が最も重要です。人がいなければ、DevOpsを完全に実現するために必要な考え方や文化を構築することはできません。

DevOpsで勝つのではなく、チャンピオンになる

私は最近PagerDutyのCEOであるジェニファー・テハーダと勝者とチャンピオンの違いについて話をしました。彼女は勝利の素晴らしさを語りました。トロフィーやタイトル、もしそれが宝くじなら数百万ドルが手に入ると。しかし、大きな絵で見ると、勝利は短期的なゴールに過ぎません。対照的に、チャンピオンになるには、長期的な成功や成果に焦点を当てることが必要です。この会話で、DevOpsを採用している組織に同じ原則をどのように適用できるかについて考えさせられました。

DevOpsツール関連の私のお気に入りの1つは、XebiaLabs社のDevOpsツール周期表です。

表に示されているように、DevOpsカテゴリーには多数のツールがあります。しかし、ツールを購入することによって組織が「DevOpsに変貌する」という話を見たり聞いたりすることが多すぎます。先に述べたように、ツールはDevOpsへの過程の重要な部分ですが、ツールだけではDevOps環境は構築されません。DevOpsチームを適切に機能させるためのすべての要素（コラボレーション、自動化、オーナーシップ、サイロの解体、プロセスの定義、継続的改善、継続的デリバリー）を考慮する必要があります。

ツールの購入を決断することは正しい方向への大きな一歩ですが、もっとも重要なのは、決定の背後にある「なぜ」、つまり最終目標を定義することです。そのために、もう一度チャンピオンの考え方を検討しましょう。

たとえば、オリンピックの水泳金メダリスト、マイケル・フェルプス選手を見てください。フェルプスは史上最も称賛されたオリンピック選手であり、彼は39の世界記録を保持しています。フェルプスは1、2勝するどころか、20勝でも止まりませんでした。彼はチャンピオンになることを目指しました。これはすべて、コミットメント、実践、そして目的とする最終状態に集中することによって成されました。

DevOpsの定義

DevOpsには何百もの定義がありますが、ほとんどの人はDevOpsレポートで概説されている次の基本原則に同意することができます。

「DevOpsは、チームがより効率的に作業し、優れたソフトウェアをより迅速に提供できるように、文化とプロセスを構築することを目的とした一連の原則です」。

文化やプロセスはクレジットカードで変更することはできません。ツールを使用すると、組織はより優れたコラボレーション、自動化、継続的デリバリーを実現できます。しかし、正しい考え方と選択がなければ、ツールの全機能が達成されない可能性があります。

例としてSlackを取り上げましょう。新しい会社に転職した私の元同僚は会議に出席していました。彼は、Slackのチャンネルを作ってコラボレーションすることが、チームをDevOpsに変えるために素晴らしいと言うのを聞きました。Slackが彼らのすべてのコミュニケーション問題を解決するだろうと彼のマネージャーは確信しました。しかし、Slackを採用してから6か月後でも、マネージャを含めチームの大半がまだSkypeを使用していました。Slackは、製品をより早く市場に投入するために使用されるツールというよりは、ビールの醸造について話すための場所になったのです。問題はSlackではありませんでした。それはチームと組織の参加の不在、そして製品の全機能に関する知識の欠如でした。

ツールとベストプラクティスをチームと短期、長期の目標の達成にいかに機能させるかが、DevOpsチャンピオンとしての我々が話すべきことです。たとえば、チームや組織の全体の目標は何ですか？ 目標が特定されたら、主要なステークホルダーからどのようにして賛同を得るのでしょうか。合意が成された後、どのようにしてソリューションを実装しますか？

組織変更

変化は多くの組織や個人にとって困難であり、意味のある変化は一晩では起こりません。人と組織がどのように変化を成し遂げるかを理解することは重要です。

Kotter 8-Step Process for Leading Changeが提唱するのは、最初のステップで変化の必要性を明確にし、すぐに行うべき理由を考え、小さなことから始め、勝とうとする前に内部にいるチャンピオンを見つけて育てるということです（この場合の変化はツールの購入）。

組織内の人々が問題を認識していない、またはより良い運営方法が存在することを認識していない場合、チームメンバーの賛同と新しいアイデアを採用し行動を起こすように動機付けることは困難です。もしかすると現在のプロセスが十分であるため、人々は現在の状態に完全に満足しているかもしれません。または、少なくとも現在の状態が既知である可能性があります。しかしながら、チーム全体がうまく機能し、より早く、より機敏な方法で彼らの共通の目標を達成するためには、最初に新しいメカニズムを導入しなければなりません。

DevOpsチャンピオンになる方法

DevOpsの世界でチャンピオンになることは、勝利を超えて進むことを意味します。それは、チームと組織構造と文化を深く掘り下げて、ツールの範囲を超えた問題を特定し、他の人と協力して、明確な結果につながる必要な変化を受け入れることを意味します。つまり、最初に戻って最終の目標を定義する必要があります。以下はあなたが始めるように頼むことができる簡単な質問です。

あなたのコアバリューは何ですか？ なぜあなたはもっとアジャイルな会社やチームになろうとしているのですか？ あなたのチームや組織はどんな障害に直面していますか？ ツールやプロセスは何を達成するのでしょうか？ 人々はどのようにしてコミュニケーションやコラボレーションをしていますか？ サイロはありますか？ それはなぜですか？ あなたはどのように顧客を擁護していますか？ 従業員は権限を与えられていますか？

最終状態を定義したら、志を同じくする他の人をチャンピオンチームの一員にし、達成しようとしていることを見失なわないようにしましょう。1つのチームやテスト環境から始めるなど、変化を始めるときはスモールスタートを忘れずに。小さく始めて勝利を築くことによって、内部のチャンピオンは彼ら自身をクリエイトし​​始めるでしょう。

覚えておいてください。企業は熱心にDevOpsを売ろうとしています。しかし、結局のところ、DevOpsは製品ではありません。それは、自動化、コラボレーション、人、そしてプロセスの方法論と考え方なのです。

*この記事のオリジナル版は、opensource.comで以前に公開されたものです。

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

「フルスタックの可視性」とは？

ツールのベンダーが「フルスタックの可視性を提供します」と宣伝していることがありますが、これが何を意味しているか分かるでしょうか。ツールが違えばどう可視化するかも違います。理由は、可視性がITインフラストラクチャの構成方法に依存するだけでなく、あなたが何が見たいかにもよるためです。極論すればフルスタックの可視性は、ツール、アプリケーション、システム、サービス、および全体的なインフラストラクチャの状態を一覧できるようにすることです。

近代的なインフラ

まず、現代のアプリケーションとサービスをホストするフルスタックインフラストラクチャのタイプを特定してみましょう。以下は、現代のインフラストラクチャに見られる最も一般的なコンポーネント要素です。これらは、仮想デバイスと物理デバイスのミックスとしてオンプレミス、クラウド、またはハイブリッド環境でホストされる場合があります。

現代のインフラストラクチャコンポーネント

アプリケーションとツール オペレーティングシステム ミドルウェア ネットワーク データベース ストレージ Webサーバ 演算装置

これらのインフラストラクチャコンポーネントはすべて、膨大な量の構造化データと非構造化データの両方を生成します。この指数関数的に急増するデータの量と多様性はITOps、DevOps、開発チームに挑戦を突き付けます。つまりシステム、アプリケーション、サービスの可用性を高く維持し、最適なパフォーマンスを発揮させるためにカギとなる情報を収拾し解釈し、実用的な洞察を抽出することを要求します。

以下は、今日の組織がインフラストラクチャとアプリケーションのパフォーマンスを自動化するために採用しているツールの例です。これらのツールのそれぞれは、インフラストラクチャ、アプリケーション、サービス、コードの展開、ビルドなどのステータス、健全性、脆弱性を知らせるデータを生成することができます。

インフラストラクチャ、アプリケーション、自動化ツール

オートメーション／継続的インテグレーション ソースコード管理

構成管理とプロビジョニング リポジトリ管理

ソースコードとリポジトリ管理 プロビジョニング

デプロイ リリース管理

データベース テスト

モニタリング セキュリティ

ビルド クラウドIaaS

マイクロサービスと仮想化

どんな風に可視化できるか

アプリケーションとサービス、システムは、データテーブル、ステータスダッシュボード、パフォーマンスグラフとチャート、ヒートマップ、トレース、システムヘルスメトリック、分析、レポートなど、さまざまな形で可視化できます。フルスタックの可視性は、複数のツールを組み合わせて構成することができます。

監視ツールカテゴリ 人気ベンダー

アプリケーションパフォーマンス監視 New Relic、AppDynamics、Dynatrace

インフラ／クラウド監視 AWS CloudWatch、Microsoft Azure、Google Stackdriver

メトリック Datadog、Librato、Keen IO

ログの監視と分析 Splunk、Elastic、Sumo Logic

既に複数の組織が、上記のさまざまなソリューションを使ってITツールのポートフォリオを構築し、インフラストラクチャ全体で何が起こっているのかを深く調べられるようにしています。

PagerDutyのようなソリューションは、ITポートフォリオ内の全ツールから生成された全イベントとアラートを集中管理して集計し、インシデントへのより適切な対応をリアルタイムで選び出します。

何が起きているのかを示せるツールは世の中にたくさんあって、ほとんどのチームは複数の監視とチケット発行ソリューションに投資しています。ここでもっと重要になるのは、大規模なインシデントがビジネスに影響を及ぼすことを防ぐ、あるいはサービスを復旧するため、専門家に対してよりよく事態を理解するために必要なリソースを提供するソリューションです。

さらにその先へ

PagerDutyでは、真のフルスタック可視性は、インフラストラクチャ、アプリケーション、およびサービスの健全性に関するビューだけではありません。インシデント管理、レスポンスオーケストレーション、システムと運用の両方の効率性の視覚化など、他の重要な部分も含まれているため、チームはSLAを継続的に改善できます。ソフトウェアがビジネスと顧客の経験の中心になるにつれて、ITOps、DevOps、開発者、ITリーダー、エグゼクティブ、ビジネス関係者は、インフラストラクチャ全体で何が起こっているかをよりよく把握する必要があります。

インフラストラクチャの真の健全性を評価する際には、人の役割の重要性を忘れることはできません。ツールは常に仕事をしますが、インシデントはそれらのツールのデータを理解できる人々が解決するのです。PagerDutyのオペレーションコマンドコンソールとインテリジェンスアプリケーションは、多数のベンダーの製品から得た状況の推移を単一のビューにまとめ、どんな重大なインシデントが際立っているか、担当者が取り組んでいるインシデントはどれか、どんなイベントが関連性があるかを包括的に把握できるようにします。そしてインシデントへの技術的、ビジネス的対応の両方を調整します。

PagerDutyを使うと、アプリケーション、サービス、インフラストラクチャの健全性を簡単に視覚化し、インシデント対応ワークフローを1カ所で管理できます。