JIRAクラウドエクステンションガイドを追加しました
JIRAソフトウェアは、組織内のチームコラボレーションを有効にするプロジェクト管理ツールです。 このガイドでは、PagerDutyインシデントからJIRAのイシューを作成できるように、JIRAエクステンションを設定するプロセスについて説明します。
詳しくはこちら
インテグレーション＆ガイド
ThousandEyesインテグレーションガイドを追加しました
ThousandEyesは、クラウド時代のIT性能管理を提供します。企業のネットワークの範囲を超えた詳細な可視性を提供し、クラウドアプリケーションの性能の根本的な原因を見つける助けになり、問題を分散したコラボレーションで迅速に解決できるようにします。このガイドでは、ThousandEyesとPagerDutyをインテグレートする方法について説明します。
詳しくはこちら
インテグレーション＆ガイド
DevOpsのメインストリーム化
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
HybridOpsとは？
CentralOpsとDevOpsの融合であるHybridOpsがエンタープライズの世界で盛り上がっています。昔から大企業には、 重大インシデント対応の中心的役割を果たすオペレーションセンター（サービスオペレーションセンター、テクニカルオペレーションセンター、ネットワークオペレーションセンター。略称SOC、TOC、 NOC ）がありました。
これは長年にわたり実行可能なアプローチでしたが、DevOpsにより従来のCentralOpsモードのオペレーションが、開発と運用の両方のスキルを持つ開発者の新しい波と相反し始めました。さらに、CentralOpsとDevOpsを融合する必要があることを認識する企業が増えてきており、デジタルトランスフォーメーションを成功させるための仕組みを整えることがますます重要になっています。
協調戦略の重要性
HybridOpsに移行する際の課題の1つは、IT運用における最も重要な資産＝人のインパクトを評価することです。
最近まで、IT Operations（ITOps）の監視対象は、常にサーバやアプリケーション、サービスに集中してきました。欠落していたのは、ITOpsのアラートが及ぼすオンコール担当者とその家族に対する影響を評価する能力でした。
たとえば、新しいサービスのデプロイや既存サービスのアップデートのために、オンコール担当者が夜間に何度も起こされた場合、担当者の欠員やバーンアウトのリスクが高くなります。現在、企業はデジタルトランスフォーメーション（HybridOpsへの移行など）を成功させるために必要とするリソースのわずか19％しか持っていないことを考慮すると、従業員の減少は大きな問題です。
さらに、うまく調整された移行戦略がなければ、サイロ化の可能性は非常に高まります。たとえば、NOC、SOC、TOCの集中管理に不満を感じているDevOpsチームは、 AWS EC2とDatadogを導入し、インフラストラクチャの管理と監視を独自にすることができます 。しかし、このアプローチの欠点は、いくつかの点で明らかです。
企業環境では、そのチームがサポートしているインフラストラクチャの問題が非常に目立つようになります。
大規模なインシデントが発生した場合、 経営幹部チームなどのビジネス関係者は、通常、復旧に関する最新情報をNOCに問い合わせます。上記のようなサイロ化した組織では、インフラストラクチャはNOCには見えず、NOCは関連するアップデートを提供できないため、解決までの時間が遅くなる可能性があります。
HybridOpsをうまく実装し、サイロ化を排除し、NOCチームとDevOpsチームの間で負荷を分担する合理的なシステムを採用する組織と比べてみましょう。このシナリオでは、NOCはアラートを適切なDevOpsチームにルーティングし、チームは得意とするインシデントの処理ができます。NOCは、インシデントが複数のチームにまたがってカスケード接続されているかどうかを把握し、ビジネス関係者への情報を更新し、DevOpsチームはインシデントの修復にエネルギーを集中することができます。 結果として、アラート、インシデント、インシデント解決の流れが劇的に改善されます。
オペレーションヘルスマネージメントサービス
いかなるITOpsオペレーションモデルも、それを選択して実装するのは、特に企業環境においては恐ろしく複雑なことです。問題の深さを理解し、必要な機能を開発したベンダーが提供するツールと監視ソリューションを利用しなければ、デジタルトランスフォーメーションのリスクははるかに大きくなります。
PagerDutyのオペレーションヘルスマネージメントサービスは、ITOpsの人々の健康と福利に関する監視を提供する業界初のサービスです。ビジネスリーダーとテクニカルリーダーは、人々の健康を重視した運用インフラストラクチャと改善のための具体的な推奨事項を深く理解しています。このサービスを使用して、これらの推奨事項を実装した企業は真のHybridOpsを達成することにより、従業員の幸福度、定着率が高まり、デジタルサービスのスムーズな提供が可能になります。
本記事は米国PagerDuty社のサイトで公開されているインテグレーションガイドをそのまま日本語に翻訳したものです。日本語環境での動作を保証するわけではありません。原文はこちらを参照してください。
DevOps
RunScopeインテグレーションガイドを追加しました
Runscopeは、APIのデバッグとテストのためのツールセットです。 開発者と運用チームは、Runscope RadarをPagerDutyを組み合わせて使うことで、自動インシデントトリガと解決によるスケジュールされたテストによってAPIを監視できるようになります。 PagerDutyをRunscopeとインテグレーションするためには、PagerDuty Connectを使用します。
詳しくはこちら
インテグレーション＆ガイド
LogicMonitorインテグレーションガイドを追加しました
LogicMonitorはSaaSベースのパフォーマンス監視ソリューションで、IT Opsチームがインフラストラクチャ、アプリケーション、およびサービスをうまく監視できるようにします。 LogicMonitorの監視機能とPagerDutyの高度なオンコールスケジューリング機能およびアラート機能を組み合わせることで、インフラストラクチャ内に問題が発生したらすぐに通知を受けることができるようになります。
詳しくはこちら
インテグレーション＆ガイド
「シフトレフト」：オペレーションがセキュリティを早くプロセスに組み込むために
クラウドセキュリティ会社の運用のプロとして、私はオペレーションとセキュリティを同時に実現できるかどうか―理想的な世界においてそうすべき―ということについて独自の視点を持っています。今日のハイテク業界で見られる共通の問題の1つは、開発プロセスにおいてセキュリティの実現がほとんどいつも遅れているということです。
セキュリティというのは完全に別個の規律なので、それをタイトなDevOpsフィードバックループに組み込むことは難しく思えるかもしれません。しかし、それは可能なだけでなく、思ったほど難しくないということをここで伝えたいと思います。そして、それを普通に行えれば、多くの問題を除去しながら全体的なセキュリティ方針に大きな違いをもたらします。
特に、「シフトレフト」というコンセプトは、チームが以前にデプロイプロセスの後半で行っていたセキュリティ導入プロセスを早期に組み込むことを可能にします。この記事では、これを行う方法について説明します。
「遅すぎる」とはどういう意味か
まず、今日DevOpsプロセスにセキュリティがどのようにもたらされているかを見てみましょう。実際は多くの場合そうなってはいません。これは、エンジニアが準備できたコードをデプロイするとき、セキュリティプロセスはまったく含まれていないことを示しています。もちろん、これを行う開発者は自分の仕事をしているだけです。彼らは製品チームから機能をリリースするという圧力を受けています。できるだけ早くコードを書き上げるために、自分がしなければならないことをやっているだけです。
他のケースでは、セキュリティチームが投入され、門番としてコードが外に出る前にセキュリティレビューを行うことがあります。セキュリティ要員が呼ばれて、欠陥があるかどうかを確認することは良いことです。しかし、最後の最後まで待つことは、継続的デリバリーのサイクルを妨げる可能性があり、今日のアジャイルな開発風土では選択肢とはなりえません。言うまでもなく、それはお互いを対立する立場に立たせることになり、チーム間の緊張につながる可能性があります。
いかにして「シフトレフト」するか
ここ数年、DevOpsチームをよりスピードアップし、継続的デリバリーで開発するよう最適化している組織がますます増えています。しかし、今はセキュリティを織り込む時です。それが「シフトレフト」です。
今までは、
Devチームが開発を行う → テスト → セキュリティチームがチェック（やらないこともしばしば） → デプロイ
というプロセスだったのを、
Devチームが開発を行う → セキュリティチームがチェック → テスト → デプロイ
というように、セキュリティを確保するプロセスを前段階に組み込むのです。それを実現するためのいくつかのヒントがあります。
同じツールを使用する
セキュリティチームがDevOpsチームが使用するのと同じ継続的インテグレーション／デリバリーのツールに精通していることが重要です。Opsのチームにコードの書き方を教えたり、Chefのような構成管理ツールの使い方をDevチームに教えたりと、DevとOpsのチームが協働するのです。今度はこれをセキュリティで行う番です。
Jenkinsは最適な例です。開発者が既にJenkinsを使用してコードのテストやデプロイをしている場合、セキュリティチームにも使うように教えたらどうでしょうか。彼らがセキュリティテストに同じツールを使用すれば、すぐにそれをプロセス化することができます。
もう1つの素晴らしいツールはGauntltです。「Rugged DevOps」という用語についてはいくつか言いたいことがありますが、Gauntltのアイデアは良いものです。Gauntltのサイトで、
「Gauntltは、さまざまなセキュリティツールを提供し、セキュリティ、Dev、Opsチームで連携させて、堅牢なソフトウェアを構築します。これは、グループ間のテストとコミュニケーションを容易にし、実行可能なテストを作成して、デプロイプロセスとテストプロセスに投入できるようにします」
運用と開発プロセスの途中でセキュリティを導入するというコンセプトは基本的に妥当なものです。この方法では、セキュリティがデプロイを遅らせることはなく、問題が発見されたときのフィードバックループを強化できます。セキュリティチームはGauntltを使用してコードを書き、テストして、継続的デリバリーを容易にします。
スタティック解析を試みる
別のオプションは、Veracodeのようなツールを使ってスタティック解析を試みることです。セキュリティチームは、デプロイの前にコードを解析し、潜在的な問題をキャッチしようとします。スタティック解析は、コードを実行することなくソフトウェアを分析します。セキュリティチームは、デリバリーサイクルを中断することなく、潜在的な脆弱性を自動的にチェックすることができます。
インセンティブを合わせる
歴史的に、DevOpsとセキュリティを連携させるための課題の1つは、相反するインセンティブがあることでした。DevOpsチームはコードを素早く書き上げることが勝利です。セキュリティチームは安全なコードができたときが勝ちです。
所有権を提供する
私たちが抱えている一般的な間違いの1つは、開発にアクセスすることさえできないセキュリティチームがあることです。セキュリティチームがコードに対して直接的な所有権を持たない場合、DevOpsサイクルに緊密に統合されない可能性があります。
一方で、セキュリティチームに所有権を与え、コード内の問題を自分で解決する方法を教えると、サイロ化を免れ、よく油の効いたマシンの一部になることができます。たとえば、 Threat Stackはセキュリティ上の問題についてチームに警告することができます。セキュリティチームに問題を解決する方法を教え、構成管理コードにアクセスできるようにすると、システムに直接アクセスして変更を加えることができるようになります。
同様に、Chef は監査とテストのフレームワークであるInSpecというツールをオープンソース化しています。InSpecを使用すると、セキュリティチームは監査サーバにコードを記述し、コンプライアンスを確保できるようになります。これにより、プロセスに対する直接的な所有権が大幅に強化されます。そして、セキュリティチームの開発スキルを向上させることができます。論より証拠です。
これにアプローチする別の方法（特に専用のセキュリティチームを持たない場合）は、セキュリティ上の脆弱性が発生した場合に、バックエンドのエンジニアにコードの修正を担当させることです。エンジニアがコードの健全性に直接の責任を負っている場合、最初からセキュリティに重点を置く可能性が高いです。Threat Stackでは、2人のOpsと10人のバックエンドのエンジニアがオンコールに従事しています。製品に問題が発生した場合、そのコードを書いたのは通常バックエンドのエンジニアリングチームです。このレベルのコード所有は、最初から正しいものを構築するようなインセンティブを彼らにもたらします。
前に進むことは横に行くこと
セキュリティをシフトレフトすると、ビジネス全体の健康状態が改善されます。セキュリティチームが問題をキャッチしチケットを開いたあと、開発者やOpsの担当者が物事を修正するのを待つのではなく、彼ら自身で解決するような力を与えます。これにより、時間と人員が節約できるだけでなく、コードが安全かつ継続的にリリースされることが保証されます。この方程式が他のチームの仕組みやワークフローにどのようにしっかりと統合されているかを、より積極的に理解できるかは皆さん次第です。
上記のヒントは、組織の現実を「セキュリティをシフトレフトする」ための出発点です。セキュリティの多くの側面と同様に、新しいツールを導入するだけでなく、 文化的な変化も必要であることを覚えておいてください。それにより、正しい考え方、インセンティブ、フィードバックループを適切に実行することができるのです。
本記事は米国PagerDuty社のサイトで公開されているブログをそのまま日本語に翻訳したものです。原文はこちらを参照してください。
Logentriesインテグレーションガイドを追加しました
Logentriesは、開発からデプロイ、そして継続的な管理とサポートまでのあらゆる段階で実用的なインサイトを提供するログ管理、分析プラットフォームです。API経由とeメール経由でPagerDutyにアラートを送ることができます。
詳しくはこちら
Kayako 5 インテグレーションガイドを追加しました
Kayakoは、お客様のビジネスに合わせてカスタマイズ可能なカスタマーサービスソフトウェアです。Kayakoでサポートチケットが作成・更新されるとPagerDutyで通知を受け取れます。また、オプションの電子メール解析ルールを設定すると、KayakoのチケットがクローズされたときにPagerDutyインシデントも解決できるようになります。このガイドはKayyakoバージョン5以降をお使いの方向けです。
詳しくはこちら
Kayako Classic インテグレーションガイドを追加しました
Kayakoは、お客様のビジネスに合わせてカスタマイズ可能なカスタマーサービスソフトウェアです。Kayakoでサポートチケットが作成・更新されるとPagerDutyで通知を受け取れます。また、オプションの電子メール解析ルールを設定すると、KayakoのチケットがクローズされたときにPagerDutyインシデントも解決できるようになります。このガイドはKayyakoバージョン4以前をお使いの方向けです。
詳しくはこちら
Circonus Integrationガイドを追加しました
Circonusはホスト、SaaSの双方を監視するシステムとして、種々のメトリック（システム、ネットワーク、アプリケーション、さらにはビジネスメトリックまで）を収集し、トレンド分析と障害検出を実行します。CirconusのアラートをPagerDutyに送信することで、PagerDutyのアラート機能をフルに活用できます。
詳しくはこちら
IBM Bluemix Integrationガイドを追加しました
IBM Bluemixクラウドプラットフォームは、アプリケーション、インフラストラクチャー、サービスなどで問題を解決しビジネスを推進します。Bluemixは複数のデータソースの統合、システムの拡張、コグニティブサービスの組み込みにより、ビジネス価値を迅速かつ安価に推進します。
詳しくはこちら
Graylogインテグレーションガイドを追加しました
Graylogはオープンソースのログ収集、検索、管理ツールです。Graylogストリームがアラートをトリガーすると、あらゆる通知をPagerDutyで表示するように設定できます。PagerDutyをオンコールスケジューリングとチームへの通知のための集中化された場所として利用できます。
詳しくはこちら
チームの健全性に関する驚くべき3つの発見
800人のITプロフェッショナルの調査結果から驚くべき発見
PagerDutyで、私たちは芳しくない業務の健全性につながる否定的な結果を認識しています。 今日の常時接続のデジタル世界では、絶え間なく高まる顧客の要求のために企業はプレッシャーにさらされていて、ITサービス担当者はデジタルサービスを健全かつ継続的に運営するために努力していますーしばしば個人の健康と生活が脅かされるほどに。仕事の呼び出しに応答するため、真夜中に携帯電話が鳴る音に起こされたり、人生の重要なマイルストーン（子供の初めての学校演劇のような）を逃したことなど想像してみてください。燃え尽きてすぐにワークライフバランスのいい仕事が欲しいと考えたことがあるでしょうか？
それでも、私たちは、米国、英国、オーストラリアの800人以上のITプロフェッショナルを対象に実施した最近の調査による３つの発見に驚いています それは、
家族生活はITマネージャーの想像以上に荒れている 認知度の欠如はITOpsの職業病となっている ビジネスにかかるコストは、労働力の喪失だけでなく苦労している従業員の生産性低下にも及ぶ
ということでした。
PagerDutyが依頼した調査レポートでは、常時接続のデジタルサービスを管理する責任が家庭生活に影響を与えているとの回答が94％となっています。さらに、半数以上（51.3％）が、デジタルサービスの中断や停電に対処するために、1週間に10回以上睡眠や個人的な生活の中断を経験したと指摘しています。
コンスタントに起こる呼び出しがオンコール担当者の健康や個人生活に悪影響を及ぼしているという統計にもかかわらず、調査回答者の約4分の3（72％）が、彼らのマネージャーはt担当者が厳しいオンコール時間を過ごしていることをを全然知っていないという結果になりました。それに対して、 調査のITマネージャーの58.9％は、彼らのチームが厳しいオンコール時間を過ごしていることをほとんど知らなかったと答えています。
悪い業務管理はデジタルトランスフォーメーションを妨げる可能性がある
IT管理者と企業全体は懸念すべきです。なぜか？
Forresterによると、多くの企業ではクリティカルな役割を担うタレントの不足がデジタルトランスフォーメーションを妨げることにつながっています。このようなタレントの欠如は、悪い業務管理と結びついた場合に、最終的に損益に悪影響を及ぼし、従業員の離職率や売上に直接悪影響を与えます。
健全なITエコシステムを維持するためにオンコール担当者はいつでも準備を整えていることを要求されます。その結果、燃え尽きたり、離職したりする不幸な従業員が生まれる可能性があります。しかし、ITOpsの始まり以来、運用上の管理は、人ではなくサーバやアプリケーションに集中しており、それはしばしばビジネスに損害を与えるものでした。
しかし、サーバやアプリだけでなく、人の面から業務の健全性を見ると、なぜIT管理者はオンコール担当者の健康状態をより詳細に把握する必要があるのかが分かるようになります。一部の回答者（23.1％）は、仕事と生活のバランスがとれない結果、新しい仕事に移る可能性が高いと答えています。さらに、組織が業務の健全性を改善するための対策を講じないと、残る人の生産性も低下する可能性が高くなります。 事実、94.5％の回答者は、継続的な中断が作業生産性にも影響を及ぼすと回答しました。
データの利用によりチームの健康を変える
いま指摘したように、良い人材を失うことは、組織がデジタルサービスをどれだけうまく提供できるかに悪影響を及ぼします。では、従業員の健康と幸福をどのように改善できるでしょうか。
それを知っているかどうかに関係なく、あなたはすでに現在の操作の健康状態を把握するためのデータを持っています。そのデータのロックを解除するだけで、改善すべき点を判断することができます。
PagerDutyは、この課題を認識してOperations Health Serviceを開発しました。これは機械学習、データサイエンス、専門サービス、1万を超える組織のピアベンチマークデータを組み合わせて、IT管理者が社員の健康状態を見て自社のデジタルオペレーションを評価できるようにするものです。
今日からPagerDutyがいかに組織のデジタルオペレーションをに人間的にすることができるかを学び、業務の健全性を向上させてください。
本記事は米国PagerDuty社のサイトで公開されているブログをそのまま日本語に翻訳したものです。原文はこちらです。
Logglyインテグレーションガイドを追加しました
Logglyは世界で最も一般的なクラウドベースのログ管理サービスです。インフラストラクチャ全体のログを集計し、検索し、問題の根本原因を特定し、全体傾向の監視を行う単一のインターフェイスを提供します。Logglyで発生したアラートをPagerDutyに送信すると、PagerDutyはSMS、電話、Eメール、またはプッシュ通信を介して適切な技術者にアラートします。
詳しくはこちら
Sumo Logic Email Integrationガイドを追加しました
Sumo Logicは膨大なログを分析・集約する機能を提供し、インフラや複雑なアプリの問題を迅速に修正するのに役立つサービスです。PagerDutyと連携させるとSMS、電話、Eメール、またはプッシュ通信を介して適切な技術者にアラートを送れます。メールを介したPagerDutyとの連携方法を紹介します。
詳しくはこちら
Sumo Logicインテグレーションガイドを追加しました
Sumo Logicは膨大なログを分析・集約する機能を提供し、インフラの障害や複雑なアプリの問題を迅速に修正するのに役立つサービスです。PagerDutyと連携させるとSMS、電話、Eメール、またはプッシュ通信を介して適切な技術者にアラートを送れます。その方法を紹介します。
詳しくはこちら
NS1インテグレーションガイドを追加しました
NS1はDNSとトラフィックの管理のためのプラットフォームです。リアルタイム性を要求されるネットワークで、名前解決と転送を高速化し、リアルタイムアプリケーションのUXを高めます。またDNSの構成管理をインテリジェント化します。PagerDutyとの連携法を紹介します。
詳しくはこちら
