Category
DevOps

2022年8月9日  (更新日:2022年8月9日)

DevOps活動に女性の参加を呼びかける

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

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

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

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

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

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

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

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

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

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

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

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

続きを読む
DevOps
2022年8月4日  (更新日:2022年8月4日)

アクショナブルインテリジェンスに "アクション "を入れる

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

AIOpsとは何か?

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

オプション #1: アプリケーション監視

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

選択肢その2:イベントマネジメント

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

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

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

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

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

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

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

当社のプラットフォームは、大規模な組織や複数のチームがセルフサービスで管理できるように、API設定機能を活用しています。そのため、ルールの更新や設定の管理を中央のチームに依存するのではなく、管理者はリポジトリやTerraformなどのツールを活用し、中央のみの機能による閉塞感なしに、チームが必要とする更新を迅速に入手できるようにすることができます。

自動化を優先し、データ駆動型のセルフサービス・アプローチにより、チームと機械学習が一体となって問題を解決し、根本原因を見つけるだけでなく、AIOpsの真の約束を実現できると信じています。このドメインにとらわれないアプローチでは、適切なタイミングで適切な情報を適切な担当者に提供することに集中することができます。アクションを実用的なインテリジェンスに置き換えることで、ノイズやアラート疲労を減らし、初動対応者が問題を解決できるようにし、労力を削減し、構築者や革新者がインシデントを追いかけるだけでなく新しい機能を提供できるようにすることができるのです。

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

続きを読む
DevOps
Invalid date  (更新日:2022年7月27日)

What's New:イベント・インテリジェンス、オンコール管理、オートメーション、モバイルなどの最新情報

私たちは、PagerDutyプラットフォームの新しいアップデートと機能強化のセットを発表することに興奮しています。製品チームからの最近の更新は、オンコール管理、イベントインテリジェンス、およびモバイル製品、PagerDutyコミュニティ&アドボカシーイベントが含まれています。新しい機能により、ユーザーや顧客はインシデントの迅速な解決、以下のようなことを行うことができます。

強力なイベントインテリジェンスにより、システム全体のノイズを制御し、手動イベント処理の量を削減します。 Rundeckの最近のリリースでオートメーションのセキュリティが向上しました。 オンコール管理機能の向上により、応答者の燃え尽き症候群を軽減し、応答者が常に重要な事件に迅速かつ効果的に対処できるようにします。 PagerDutyのモバイルアプリの最新アップデートにより、重要なコンテキストの表示と重要なインシデントレスポンス機能へのアクセスが可能になりました。 PagerDuty App for ServiceNowの製品デモと、2021年からのイベントインテリジェンスの機能をWebinar & Eventsからご覧いただけます。 PagerDutyとRundeck、LaceworkをTwitch Stream上で連携させる方法について同業者から学ぶ

また、新機能のデザインパートナーとしての参加も歓迎します。また、ソリューションガイドのコレクションを通じて、組織内のさまざまなチームがPagerDutyオペレーションクラウドをどのように受け入れ、利益を得ることができるかを発見していただけることを願っています。

ソリューションガイド PagerDutyは、IT部門以外の部署でも利用できることをご存知でしょうか?その通りです!マーケティング、営業、財務、人事などのチームがPagerDutyを使用して重要なビジネス機能を処理するのに役立つ、私たちが共有したソリューションガイドをチェックしてみてください。

イベント・インテリジェンス イベントインテリジェンス(EI)は、企業がダウンタイムを削減し、顧客体験を実現するために役立つMLを活用したソリューションです。最新のEI機能は、ノイズを減らし、根本原因を突き止め、手動プロセスを自動化してインシデントの発生を減らし、迅速な解決を可能にする実用的なインサイトをチームに提供します。

イベントオーケストレーション イベントオーケストレーションにより、チームはノイズを減らし、手動によるイベント処理を削減し、業務効率の向上と労力の軽減を図ることができます。イベントオーケストレーションのディシジョンエンジンは、カスタムロジックを作成し、イベントの条件に基づいて、適切なチームへのイベントのルーティングを大規模に強化、変更、制御することを可能にします。

ネストされたイベントルールを機械学習とターゲット自動化と組み合わせて、診断および修復アクション(システムヘルス統計情報の取得、自己修復の実装、導入の自動ロールバックとサーバーの再起動を含む)をトリガーします。

Event Orchestrationのデモをご覧ください。

オンコール管理

チームの健康、幸福、そして全体的な幸福は、すべての組織の成功の鍵です。私たちのオンコール管理機能は、組織の最も貴重な資産である「人」を守るために役立っています。

ラウンドロビンスケジューリング ラウンドロビンスケジューリングは、複数のチームメンバー間でオンコールシフトの責任を公平に分配することができます。この機能は、チーム内の異なるユーザーに新しいインシデントを自動的に割り当てることで、チームが燃え尽きるリスクを抑えながら、可能な限り効率的にインシデントを解決できるようにするものです。

デモをご覧ください。 詳しくはナレッジベースで デモを見る ブログを読むラウンドロビンスケジューリングでオンコール責任を公平に分配し、インシデント対応を合理化する

オートメーション Rundeck 3.4.7, 3.4.8, 3.4.9, および 3.4.10 リリース Rundeck Enterprise と Rundeck Community の最新の Rundeck 機能と拡張をチェックしてください。

HashiCorp Vault Pluginは、より多くのログを記録し、パスワードが保存されている場所とは異なるネームスペースへの認証をサポートし、セキュリティを強化しています Spring Securityのバージョンを5.1.11から5.2へ変更し、セキュリティを強化。 Rundeck Enterprise と Rundeck Community の両方で log4j を 2.17.0 に更新し、最近の Log4J の脆弱性に対処しました。 Rundeck Enterprise のパスワードリセット機能は、アカウント上で直接パスワードをリセットする代わりに、リセットリンク付きのメールを送信することでローカルユーザーのパスワードをリセットできるようになりました。

これらのアップデート、およびその他のコア製品のアップデートとバグ修正の詳細については、3.4.7, 3.4.8, 3.4.9, 3.4.10 のリリースノートでご確認ください。

インシデントレスポンス モバイルインシデント詳細リフレッシュ 新しく改良されたモバイルのインシデント詳細画面では、インシデント対応プロセス中のお気に入りの機能すべてに、一箇所から簡単にアクセスできるようになりました。新しいカルーセルで、再生の実行、優先度やメモの追加、ステータスアップデートの投稿など、さまざまなことが可能です。

詳しくはナレッジベースで最新のモバイルリリースノートをご覧ください。

製品廃止のお知らせ 2022年3月31日** - Webhooks V2 は、現在一般公開されている Webhooks V3 に置き換わります。

ウェビナー&イベント 以下のウェビナーやイベントに参加し、PagerDutyの最近の製品アップデートと、それがどのようにお客様に利益をもたらすかについて、より詳しく学んでください。

PagerDutyでノイズを減らし、イベントルーティングを管理する方法** - PagerDutyのシニアプロダクトマネージャであるFrank Emeryが、PagerDuty Event Orchestrationで管理しきれないレベルのノイズと複雑さに対処する方法を説明します。オンデマンドでウェビナーを見る イベントインテリジェンスの最新情報 - 2021 Roundup** - Vivian Chan、Frank Emery、Vera Chanによる製品デモとQ&Aで、イベントインテリジェンスの最新のアップデートをオンデマンドで入手できます。オンデマンドでウェビナーを見る イベントインテリジェンス101 with PagerDuty University** - Hannah Lodiseが、イベントインテリジェンス機能がいかにチームのシステムノイズを減らし、問題のトラブルシューティングを迅速に行い、手作業を排除して迅速な解決を可能にするかを詳細に説明します。オンデマンドでウェビナーを見る ServiceNowとPagerDutyの統合によるメジャーインシデント管理のレスポンスタイム改善** - ServiceNow統合の製品デモとLaura ChassagneとVera ChanによるQ&Aで、CMDBデータの活用、可視性とコンテキストの向上、インシデントレスポンス、さらに自動診断と自己回復によるインシデント解決時間の短縮について詳しく学びましょう。オンデマンドでウェビナーを見る PagerDuty Pulse Q3** - 最新の製品デモをQ3 PagerDuty Pulseでプレイリストにまとめてオンデマンドでご覧いただけます。今すぐQ3 PagerDuty Pulseをご覧ください。

PagerDuty Community Twitch Stream 私たちのTwitchチャンネル、PagerDuty Twitch StreamとPagerDuty Community Twitch Streamに参加して、私たちのデベロッパーアドボケートが率いる最新のストリームをキャッチアップしてください。

登録すると、ライブのお知らせや過去の録音を見ることができます。 私たちの放送を見逃しましたか?最近のTwitch配信やYouTube動画をご覧ください。 2022年1月14日 スコット・マカリスター&マンディ・ウォールズと - PD Garage (Custom Change Transformer for Change Events) 2021年11月16日 マンディ・ウォールズ&ロブ・ヤーン(Dynatrace)と共に - パートナーインテグレーション - PagerDuty、RundeckとDynatraceの連携 2021年11月11日 マンディ・ウォールズ&ジェフ・フライ(Lacework)と共に - PagerDutyとLaceworkを統合する。

もし、あなたのチームがこれらの機能拡張を利用できるのであれば、ぜひアカウントマネージャーに連絡して、14日間の無料トライアルに申し込んでください。

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

続きを読む
DevOps
2022年7月15日  (更新日:2022年7月15日)

2022年に向けて、組織のデジタル革新を加速させたいですか?そのための3つの方法をご紹介します。

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

これは非常に重要なことです。マッキンゼーの調査によると、危機的な状況下でもイノベーションを重視する組織は、危機後の数年間で30%も市場パフォーマンスを向上させることが分かっています。デジタルサービスの競争環境では、立ち止まるという選択肢はないのです。では、どうすればデジタル・イノベーションを加速させ、2022年に成功することができるのでしょうか。

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

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

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

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

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

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

ここで必要なのは、健全なプラグマティズムです。賢明なエンジニアリングリーダーは、「ベンダーロックイン」の心配に負けることなく、そこで利用可能な機能に基づいて、自分たちのコードに適したインフラ環境を選択することになるでしょう。このようにして、企業は社内で利用できる限られたスキルを最大限に活用し、クラウドプロバイダー間で複数の同一環境を複製するために貴重なエンジニアリング時間を費やすことなく、イノベーションに専念できるようになるのです。

  1. 複雑さを極限まで減らす より革新的なカスタマーエクスペリエンスへの要求は高まる一方です。しかし、その反面、複雑さが増大し続けることはありえません。現代の企業はすでに、マイクロサービス、コンテナ、サーバーレスアーキテクチャ、オーケストレーションプラットフォームの網の目のように、何百万もの依存関係を持つ何千ものデジタルサービスを動かしているのです。

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

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

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

DevOpsのサポートからクラウド戦略、自動化まで、PagerDutyがどのようにデジタルイノベーションの加速を支援できるかを知るには、https://www.pagerduty.com/ をご覧ください。

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

続きを読む
DevOps
2022年7月14日  (更新日:2022年7月14日)

PagerDutyが最新のG2 Grid for AIOps PlatformsでLeaderに選出される

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が日本語に訳したものです。無断複製を禁じます。原文はこちらです。

続きを読む
DevOps
2018年4月25日  (更新日:2022年6月10日)

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
2019年8月26日  (更新日:2022年5月19日)     |    DevOps

DevOpsは買えません

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が日本語に訳したものです。無断複製を禁じます。原文はこちらです。

2017年12月26日  (更新日:2022年5月19日)     |    DevOps

現代のインフラストラクチャに真のフルスタック可視性を

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

ツールのベンダーが「フルスタックの可視性を提供します」と宣伝していることがありますが、これが何を意味しているか分かるでしょうか。ツールが違えばどう可視化するかも違います。理由は、可視性が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カ所で管理できます。

2018年2月5日  (更新日:2022年3月11日)     |    DevOps

OK、Google。次のオンコールはいつだっけ?

VoiceOpsは次に進む準備が出来ている?

想像してみよう : PagerDutyからコールがあり、静かな声であなたに、注意すべき問題があるよと伝えてくれる。あなたの心中はきっと乱れ、心の声が次のように聞こえるだろう。

“げげ!これは直さなくっちゃ!”

“どうすればいい?”

“これは他人の問題かも”

…あるいはここには書けないような汚い言葉かも。

DevOpsの動きが立ち上がるということは実は、担当者は9時から5時まで個室に詰めて問題を解決するだけでは済まなくなるってことだ。 スマートフォン、ラップトップ、高速な家庭用Wi-Fiが使えるようになって、人々は自宅で仕事をすることも求められるようになった。 何かが起きれば、いつどこにいても、多数のプラットフォームを通じて通知を受け、対応できる。

でも今のテクノロジー・フォワード・ソーシャルや数多くのコミュニケーション・オプションがあるにもかかわらず、ラップトップや信頼できるWi-Fiにアクセスしないとか出来ないといったこともある。例えば通勤中や、コーヒーを飲んで会議をしているときとか、歯科医のオフィスで根管治療を受けているときとか。 こういうケースでは、声で反応するほうがより自然に感じる(根管治療中は除くけど)。

“エスカレーションしてよ。今私は答えられない。 “

“ああ分かった。確認。”

“うーん。担当者を増やすようリクエストして。データベースチームのEllenを探してくれるかい。 “

このシナリオを念頭に、われわれPagerDutyの中では、人々が実際にPagerDutyとどう話したがるかを研究し始めた。 まずPagerDutyと最も関連性の高い2つの状況を考えた。

戦闘中:多くの人々が大規模なインシデントに対応している状況で、複数のチームが絡んでいて、会議ブリッジで通信している可能性が最も高い。

小競り合い:1人の担当者が、マイナーなインシデントを確認して処理をしており、ダッシュボード、メトリック、およびランブックを参照して、一人で頑張っている。

しかしもう一つのシナリオがある:平時だ。これは、各チームが比較的静かな時間を最大限に活用してスケジュールを編集したり、分析結果を チェックしたり、サービスを設定したり、オーバーライドを管理する時間だ。 自宅の音声対応デバイスがあったら、みんなどう信頼を得るかを考えてみよう。 相互作用のほとんどは、比較的「平和」なものだ。消費者は、比較すれば緊急でないコマンドを試すことで、家庭の音声対応デバイスを信頼し始めている。

“今日は傘がいる?

“冗談を言ってみてよ”

“チーターってどのくらい速く走れるの?”

システムの状態をチェックすることは、天気をチェックするのと同じくらい自然でなければいけない。 平時のVoiceOpsは、人々がデジタルオペレーションを管理する方法を変えるはずだ。UXデザイナーのCorinna Sherman氏や、ソフトウェア技術者のZayna Shahzad氏は、平時のVoiceOpsの可能性を見出し、次にGoogle Assistant、Google Homeデバイス、そして PagerDuty APIを使ってプロトタイプを作った。

われわれはActions on Google開発者コミュニティとチームを組んで、先月共同でハックイベントを開催し、そのプロトタイプをPagerDutyコミュニティやHackbright AcademyとCode2040の出席者と共有した。

このイベントで我々は、Actions on Google AssistantとPagerDuty APIを使ってデモを作るためのブレーンストーミングを全員で実施しアイデアをひねり出した。優勝者はGoogle Homeデバイスを授与されたので、イベント後も引き続きプロジェクトに取り組める。さらに、Actions on GoogleのDevエバンジェリストであるIdo Greenが、参加者が音声を使った設計の原則を理解し、いくつかのコードラボをわたり歩き、Dialogflowでさまざまな自然言語技術を使って時間をかけて改善する方法を共有するのを支援した。

VUI Design from Ido GreenからのVUIデザイン (訳注:スライドが開きます)

学んだことは?

VoiceOpsは、 小競り合いの際のシナリオで、担当者が予定外のマイナーなインシデントの解決に独自に取り組んでいるときに、その役に立つ。

VoiceOpsは平時のマネージャーに約束しており、通常は毎日自分のチームのPagerDutyアプリケーションをチェックしない人にも答えを提供する。

VoiceOpsはまだ戦闘時に対しては準備が整っていない。Corinna氏が指摘しているように 、アクセントの認識の問題があったり、音響に問題がある部屋では、音声認識はかなりひどくなる。

音声認識と対話がうまくいけば、人々はVoiceOpsを使ってうまく働けるだろう。音声対話が設計どおりに動作しない場合、人々は不満を感じ、信頼しなくなる。

もっと学びたい?それなら プロトタイプをチェックし、コミュニティフォーラムでディスカッションに参加してください。 あなたはオンコール中に何を尋ねる?オンコール中でないときは? 私たちはそれを聞きたい。 また、PagerDutyコミュニティに参加してイベントなどの最新情報を忘れずに入手してください。

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

2018年1月17日  (更新日:2022年3月11日)     |    DevOps

DevOpsの失敗から学ぶ方法

DevOpsの失敗は微妙な話題です。それが一般的にはDevOpsは障害を回避する方法として認識されているからです。その結果、DevOpsの実践に失敗した場合、状況はほとんど絶望的に見えます。しかし、フェイルファーストのビジネスアプローチや、「失敗して早く修正する」アジャイルの手法がしばしば証明するように、DevOpsの失敗は実は正しい方向への一歩なのです。失敗から学び、DevOpsの実践を、後まわしではなく早く、より大きな成功に導く道に向かわせるための第一歩です。

DevOpsはアジャイルに発するものです。頻繁なフィードバックループで開発サイクルを短くすると、顧客のニーズに一層合致した製品の提供に集中できます。フィードバックループの活用ポイントは、顧客からのフィードバックを通じて行動から学び、何が正しいのか、何が改善できるのかを測定することです。

フィードバックループは、頻繁な変更と失敗からリスクを実際に減らすよう学べる機会を提供するため、効果的です。DevOpsの実践に打撃を与える失敗はいろいろなので、それにどう対応するかが重要です。ではいくつかを細かく見てみましょう。

インシデント対応の失敗

ソフトウェア関連の問題が発生した場合(ソフトの展開に関連することであろうとバグであろうと)、それが起きたという事実よりも、どう反応したかがたいていは重要になります。 ここでの失敗は、以下を含む複数の形で発生する可能性があります。

過剰反応**:障害からの回復や、失敗の繰り返しを避けるために、過度の時間を費やしたり、過度に多くのリソースを費やしたりすることです。

誤った反応**:情報の欠如による問題の誤診や、問題の見積もりを誤ること。

無反応**:問題を早急に修正したり、効果的に修正したりするのを忘れ、直後に問題が再発すること。

インシデント管理とKPIによる成功を評価することは、DevOpsの成功の要件である測定の重要な部分です。関連する情報を浮上させ、他のチームメンバーを募集し、個々のコンポーネント(およびそれらの背後にある人)を原因として示すのではなく、全体としてシステムを見て、インシデントを迅速に評価して解決します。

ここでの取り組みには、インシデント対応、知識の伝播、将来の問題を回避するための過去のインシデントからの学習、問題解決の自動化による迅速な対応といったことが含まれます。

プロセスの作り過ぎ

DevOpsは単なるプロセスまたはツールであると考えて、厳格で正式な一連の手順を設定することをに走る人もいます。しかし、あまりにも多くのプロセスを作ったり、プロセスについて厳格すぎたり、特定のツールセットを強制すると、組織の柔軟性が失われる可能性があります。 そうではなく、DevOpsには、組織の敏捷さを向上させるツールと手順が含まれている必要があります。

例えば、ソフトウェア開発と展開の効率の全体を測定するツールは、その効率を向上させるためのフィードバックを提供するのに役立ちます。 どうやって? 変更が必要な箇所と削除する必要のあるボトルネックを指摘するのです。厳格になりすぎると、変化するユーザーベースまたは市場のニーズを改善または満たすために迅速に変えられなくなる場合があります。

DevOpsの範囲を制限する

DevOpsの実践の仕事は、組織内の一人の人間やチームだけには任せられません。 私は、既存のソフトウェア展開とメンテナンスの問題をすべて修正するためにある人が”DevOps Person”として特別に雇われ、”DevOps stuff”を魔法のように行う状況を目撃しました。しかし、そこには足りない点がありました、「そのアプローチが失敗する」と考えなかったことです。

同様に、顧客サービスおよびサポート担当者が、事前に知らされていなかった、週末にインストールされた新機能に関してコールを受けた状況も見てきました。 主なサポート担当者がお客様からソフトウェアの変更を知らされるような場合は、DevOpsの失敗が起きます。

DevOpsは、アジャイル開発から学んだことを取り入れ、ソフトウェアの展開全体を通じてエンドツーエンドで適用する、構成的な実践方法です。 これはビジネス全体の他の機能にも拡張する必要があります。 つまり、開発作業は各プロジェクトではなく顧客への価値に沿って行われ、製品チームはITスタッフとだけではなく、コールに対応する人や、技術文書を作成する人、アプリケーションを宣伝して販売する人、ビジネススポンサーとして働く人たちとも共に働かなくてはなりません。その中には将来計画を立案するエグゼクティブも含まれます。 フィードバックループを拡大して組織の全員を構成するには、誰もが覚えておくべきことがあります。

ここでは、フィードバックループ、コミュニケーション、および主要な測定活動を組織のすべての部分に拡大することを含みます。 また、サードパーティベンダー、サプライヤー、コンポーネントを除外しないでください。 外部コンポーネントの検証、監査、および監視も含めてください。

不毛な責任追及と競争を回避する

アジャイルは、組織のソフトウェア配信パイプラインでのボトルネックを明らかにすることが多く、物事を遅らせていると思われる人や活動を指摘するのは簡単です。これが起きると、DevOpsは意図していたのとは正反対に、チーム間をばらばらに引き裂くくさびを打ち込むことになってしまいます。

そうではなく、サイロ(真空中で仕事をしようとするチームや人)を取り除き、ボトルネックや改善を特定するよりも先にチーム間の壁を壊してください。 全員が最初に協力して責任を共有することで、チーム同士が競争する結果ではなく、1つにまとまるという改善ができます。

サイロを徹底的に排除する

組織内で例外を作っていることは珍しいことではありません。 たとえAgileやDevOpsで実際に成功を収めている組織でもあることです。おそらく、それはレガシーなアプリケーションや、過去に実績があるチーム、またはベテランの従業員です。 しかし、DevOpsの実践から個人やチームを除外するのは面倒な作業です。

サイロは、組織のソフトウェア展開の実践を複雑化して毒になる可能性があります。 そのサイロに共同創業者が含まれていたとしても、組織のDevOpsが奨励するプロセスとコラボレーションから免除されるべきではありません。 一言で言えば、DevOpsはサイロとボトルネックを取り除くことを意味します。例外なしに。

開発環境を無視する DevOpsは、本番環境と展開するもの以外にも適用されます。 アジャイル開発のスプリントが成功し、本番環境の導入が自動化され、テストが継続的に行われている場合でも、開発環境にこれらの実践を拡張しないと、独自の問題が発生します。たとえば、開発環境とテスト環境が同じツール、アプローチを使っておらず、その運用環境を管理する担当者によって管理されてもいない場合、ソフトウェアが想定外のユニークな構成に初めて遭遇したときに生産上の問題が発生します。

チームからのアクセスをむやみに増やさない DevOpsの結果としてチームワークが強化されるのは良いことです。またソフトウェアの開発過程で、新しい手順やコンポーネントにさらされるにつれ、チームメンバーが成長する能力も向上します。 しかし、これに伴う責任の追加分担を忘れると、重大な失敗につながる可能性があります。 たとえば、DevOpsはUI開発者がアプリケーションのデータベースに慣れるのに役立つかもしれませんが、UI開発者がDBの変更を自分で公開する権限を持つようになると、誤って本番データベースを変更するといった事態も起こるかもしれません。 ボトルネックは除去すするにしても、大災害を避けるためにコントロールも必要です。

重要なプロダクションシステムへの予期しないアクセスを監視して報告し、意図しない変更をロールバックする(またはロールフォワードする)手順を導入するべきです。

結論:つまりは人の問題です

ゴールはDevOps自体の成功ではありません。プロセスでも活動でもありません。ゴールはソフトウェアとカスタマーエクスペリエンスと組織を改善するためにDevOpsの使命をまっとうすることです。 これらのいずれかが欠落している場合は、DevOpsで成功していると思っても生きるのは難しくなるかもしれません。

これまで説明したことすべてに現実の人々を巻き込むよう肝に命じること、それが重要です。 DevOpsがどう役立つかに関係なく、失敗から学び、絶えず改善を続ける文化を吹き込み、顧客を幸せにし、楽しい時を過すことが本当に大切です。 あなた自身のゴールを達成するために働く毎日の中で、本当に大事なことを忘れないでください。

2018年2月8日  (更新日:2022年3月10日)     |    DevOps

デジタルオペレーションを人間的に

午前3時、あなたは暖かく居心地良い布団の中で、枕に垂らしたよだれに気づかぬまま、深い夢の中で癒されています。

ところが突然、あなたは目が覚め、心臓が高鳴ります。電話が最大音量で鳴っています。隣で寝ていたパートナーは目を開けて寝返りを打ち枕を頭にぶつけ、眠りに戻る前にあなたを睨みつけます。あなたは電話を黙らすために手を伸ばし、アラートの発生を知ります――夜間のバッチジョブがまたトラブったようです。 あなたは一言怨嗟の声を上げ、ノートパソコンの前に座って2時間の仕事に就きます。気が付けば夜明け。あなたは睡眠不足で疲れていますが、数時間後にはオフィスにいなければなりません。

いつものことですか?

微妙なワークライフバランス

今日の常時稼働の世界では、これがオンコール担当者の日常です。健全なITエコシステムを維持するのは、昼夜を問わず準備ができていることを要求する厳しい仕事です。最近のPagerDutyの報告書「グローバルITワークライフバランスの現状」によれば、ITエンジニア800人を調査したところ、51.3%は週に10回以上、仕事や生活が中断されたと答えています。 IT運用は担当者の健康を犠牲にしながらインフラとアプリケーションの健全性に重点を置いてきました。オンコール対応者は勤務時間中と時間外に関わらず、週末にもアラートを受信し、疲れ、欲求不満が高まり、睡眠不足に陥っています。担当者だけがストレスを感じているわけではありません。その家族も同様に影響を受けています。

これは広範な問題です。調査の回答者の94%が、アラートが家庭生活に影響を与えると答えました。ほぼ同数の回答者(94.5%)は、アラートによる中断が仕事の生産性に悪影響を及ぼしていると回答し、72%は彼らの上司は担当者が抱えている問題をほとんど知らないと答えています。

これは憂慮すべき数字です。これらのストレス要因がタイムリーに対処されない場合、従業員は燃え尽き、仕事と生活のバランスを求めて退社してしまうでしょう。私たちの調査によると、回答者の23.1%が現在の会社のワークライフバランスが悪い場合、新しい仕事を探すだろうということが分かりました。熟練した担当者を新たに雇うためのコストは30万ドル以上にのぼるため、スキルの高い従業員を維持することは会社の利益のために重要です。

チームを健全に保つための洞察を得る

PagerDutyはオンコール担当者が直面する課題を認識し、企業がIT運用とオンコール担当者の健康を全体的に改善するのを支援するため、データ分析とアドバイザリー・コンサルティングを組み合わせたPagerDutyオペレーションヘルスマネジメント(OHM)サービスを開始しました。 OHMサービスは、PagerDutyの幅広い分析機能のポートフォリオの一環として、企業に最も価値のある資産、つまり人材について、実践的な洞察と助言を提供します。私たちはIT運用を人間的にし、その背後にいる人々の生活の改善に導きます。

各企業はオペレーションヘルススコアと呼ばれるスコアを使い、我々が特許出願中のアルゴリズムと機械学習、ドメインの専門知識とピアベンチマークデータを活用し、業務の健全性を定量化することができます。OHMサービスを通じて、企業は組織やプロセスの改善点を把握し、オンコール担当者とチーム、サービスの健全性を損なう問題を特定して修正することができるようになります。

チームの健康、生産性、そして幸せを向上させたいとお望みならば、今すぐ無料のオペレーション健康度アセスメントをご覧ください。

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

2018年4月25日  (更新日:2022年3月10日)     |    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社のサイトで公開されているインテグレーションガイドをそのまま日本語に翻訳したものです。日本語環境での動作を保証するわけではありません。原文はこちらを参照してください。

2017年12月27日  (更新日:2022年3月10日)     |    DevOps

デジタルオペレーションの人間的側面

2017年2月28日の朝のこと、インターネットが広大な範囲で利用できなくなりました。 Slack 、Quora 、GitHub、Trelloなど、数千人が頼りにしている個々のサイトからサービスに至るまでたくさんのものが利用できなくなりました。たぶん、人為的ミスがインターネットの大部分をダウンさせたこの日を覚えているでしょう。AWSの幅広いコンポーネントが機能しなくなりました。一つの停止でインターネットが無秩序になったのは今回が初めてではありませんが、AWSの規模を考えれば、その影響はいつでもありうると感じられます。

多くの場合、危機の最中に重大な事件に対処する人間の側面を忘れることがあります。例えば人々に連絡する難しさや、個人的な連絡先情報を見つけること、複数のタイムゾーンに主要なスタッフが分散していること、会議から人を引き離すことなど、予期しない出来事のため計画していた作業を中断することなどです。

PagerDutyは、こういう時代に存在する最先端のデジタル運用管理プラットフォームです。私たちは、チームや組織が事態が悪化したときにPagerDutyを使いインシデントを先取りして管理することを支援し、チームがやりたい仕事に集中できるようにします。当社の製品は、予期せぬ事態が発生した場合の行動のプラットフォームとして機能します。私たちは主にエンジニアリングとITチームにフォーカスしてきましたが、チームや人をサポートする他のビジネス分野にとってPagerDutyがどんな意味を持っているかも考えていました。

過去には、エンタープライズシステムや人事部門こそが、AWS停止などの事態が発生したときに必要となる重要な人員の詳細を把握するシステムの責任者でした。人事チームはまた、大事な顧客への影響が発生したときに情報を提供する必要があります。私たちの情報の世界の大部分はクラウドにあり、クラウドベースのサービスが利用できない場合に、私たちが仕事をするために必要な重要な情報もそこにあります。私たちが日常的に利用している人気のあるサービス、社内のメッセージングとVoIPサービスは、すべて利用できなくなる可能性が隠れています。これらのクラウドサービスの大規模な停止またはダウンタイムの間、顧客と従業員に情報を提供し、行動と対応を調整することは困難です。

「 私たちの情報の世界の大部分はクラウドにあり、クラウドベースのサービスが利用できない場合、私たちが仕事をするために必要な重要な情報もそこにあります。」

現代の企業には、通常、人の情報をすべて記録したシステムがいくつもありますが、その詳細を最新の状態に保つインセンティブを人々に持たせていることはめったにありません。 PagerDutyのようなインシデントや危機対応の鍵を握るシステムでは、従業員全員が緊密な接触を維持する気にさせる深いインセンティブと日常のビジネスニーズがあります。そのプラットホームを活用して正確な人の情報を得、応答を調整すればスムースになります。

これは、ビジネス全体で高度に採用されているプラ​​ットフォームをHRチームが使用する絶好の機会であり、私たちを行動の心臓部につなぎとめ、妨げにならないように支援します。私たちが最も避けたいことは、素早い返事と行動を求められている最中に、社内で不要な騒音や官僚的な行動を作り出すことです。

従業員に対する環境的、物理的、またはデジタル的な脅威など、人事部門が責任を持つべき危機のことを考えてください。私たちに必要なのは、状況を管理し、重要な情報にアクセスし、サイロになったりワークフローにまぎれずに、あるいは、チケットによって遅くならずに応対できるようにすることです。いつもそうとは見えないかもしれませんが、HR部門は、さまざまな状況になると、しばしば第一級の対応ができる部門です。ベストプラクティスとアジャイルワークフローを使い重大な事態に対処するには、法律、設備、ベンダー、サイバーセキュリティチームと連絡する必要があります。

当社の顧客の多くは、物理的な在庫やサプライチェーンを持たないビジネスモデルを採用しています。デジタルインフラストラクチャがビジネスの主体であり、顧客の経験に大きな影響を与えます。エンジニアリングから法律およびマーケティングに至るまで、インフラストラクチャと顧客体験の成功に投資しています。リアルタイムの顧客への影響がある場合、そのインフラストラクチャ全体を調整できるプラットフォームを使う方が優れた対応ができます。

“ これらのチームが人々と意思決定とシステムの間に持っているスピード、オーケストレーション、相互運用性からはみんなが恩恵を受けられます。”

テクノロジーに焦点を絞ったビジネスでは、エンジニアリングチームや開発チームが使用するプラットフォームやプロセスから学ぶ必要があります。これらのチームが人々と意思決定とシステムの間に持っているスピード、オーケストレーション、相互運用性からはみんなが恩恵を受けられます。各チームが醸成した文化、つまり最前線に至るまでのカスタマーエクスペリエンスの説明責任を果たせること、チームが対策を組織できると信頼すること、非常に高い協調性から学んだこと、そしてDevOpsチーム、ITチーム、顧客が習熟してきたインシデント対応へのアプローチから、恩恵を受けることができます。ビジネス全体がこれから学ぶことができます。

“ HRの専門家としての私たちの責務は、組織の人々のデータおよびオーケストレーションのインフラストラクチャが、インシデント対応の技術インフラストラクチャおよびオーケストレーションと同じくらい効果的だと保証することです。”

さまざまな機能が共有プラットフォーム上で共同して働ける新しい方法を見つけ出すことは私をワクワクさせます。例えばデータを集めることと機械学習を活用して、あるパターンが出現する前にそれを見つけたり、過去の反省から対策を覚えたり改善したりすることができます。 HRの専門家としての私たちの責務は、組織の人々のデータおよびオーケストレーションのインフラストラクチャが、インシデント対応の技術インフラストラクチャおよびオーケストレーションと同じくらい効果的だと保証することです。私たちは社員が顧客のために構築した経験を彼らから借用していますし、オンコールエンジニアの人生をより良くしていくことで、デジタルビジネスに関わる全員の人生をより良くすることができるはずです。

2020年9月16日  (更新日:2022年3月10日)     |    DevOps

DevOpsトランスフォーメーションに血を通わせる

チェスをしたことがある人なら誰でも、望む結果に到達する方法が1つではないことを知っています。1手目の後には400の違った指し手があり、2手目の後には19万7742の、3手目の後には1億2000万の可能性があり、これらはすべて望む同じな結果に向かって進んでいます。

「これがDevOpsと何の関係があるの?」。真っ当な質問です。チェスの試合にアプローチする方法が1つではないのと同じように、DevOpsの変革に取り組む方法も1つではありません。

では、どのようにしてビジネス、既存のプロセス、従業員に大きな影響を与えることなく、より速いデプロイメント、安定性の向上、コラボレーションの向上を約束する変革を行うのでしょうか?

PagerDutyでこれに成功した企業は、5つの重要な戦術に従っていることがわかりました。

避けられない変化を認識する

今日の企業は、顧客の期待の高まりに応えるためにデジタルサービスを変革していかなければなりません。変化はしばしば不快なものであり、多くの組織は変革の取り組みに関してチームからの反発を経験し、場合によってはメンバーの離職を経験することもあります。多くの場合、DevOpsの「自分で構築して自分がオーナーになる」というモットーは、現実には一歩踏み込みすぎていることがあります。

しかし、それでいいのです。私たちは、多くの組織で抵抗や従業員の離職が起こるのを見てきました。しかし、このシナリオでは、短期的な苦痛は長期的な利益に値します。

あなたと一緒に変革の旅に出たいと思っている人には、この変革を視覚化するのを手伝ってあげてください。既存のプロセスを解体して置き換えるのではなく、小規模なプロジェクトから始めることで、新しいアイデアをテストし、リスクを評価し、すぐに成果を得て、将来の「新しい標準」の感覚を得ることができます。目標は、オンコールを変化の障壁にするのではなく、学び、成長する機会にするために、考え方を変えることです。成功の種を蒔き、早期に小さな成功を得ることで、たとえ変化が避けられないとしても、少なくともそれがより身近なものになるようにしましょう。

DevOpsはゼロサムゲームではありません。加算的です。その意図は、チームのアウトプットとスキルの質を継続的に向上させることです。

ビジョンへの賛同を得る

トップの賛同なしでは、開発者チームがより多くのオーナーシップを持つようになれないということを強調することが重要です。経営陣と開発チームの両方が、将来の状態と潜在的な利益について相互に理解していることが重要です。

小さく始めて、隠れたところでいくつかの勝利を得ることは、2つの目的に役立ちます。

アジャイルアプローチが達成可能であり、開発者とOpsチームにとっても同様にうまく機能していることを示します。周囲の期待を得ると、この成功を紹介して新しいプロセスを実現する開発者のサポートを得られるため、経営陣へのアピールが容易になります。 この成功の成果が、開発側が得たデプロイ頻度の向上やコード品質の向上なのか、運用側が得た重大インシデントの減少やインフラの回復力の向上なのかに関わらず、それが経営陣の賛同を得るための要素であり、目に見えるものであることが重要です。結果を定量化することで、組織が新しいプロセスを完全に実装した場合に、経営陣はこれらの新しいプロセスがもたらすプラスの影響をよりよく理解することができます。

開発チームの賛同を得ることは、乗り越えなければならない大きな障害のように思えるかもしれませんが、最終的には彼らのサポートが最も貴重な資産となります。ビジョンに取り組むことで、役割と責任を調整し、DevOps への全体的なアプローチを作成することができます。

インセンティブの変化を理解する

PagerDutyを使用することで開発文化がシフトし、より多くの説明責任を果たすことができるということを、私たちは顧客からよく聞かされます。では、これは正確には何を意味しているのでしょうか?

従来のOpsモデルでは、開発者とOpsチームのインセンティブは一般的にずれています。開発者は迅速なコード出荷を望んでいますが、コードが本番になってからの信頼性の可視性は低くなっています。一方、Opsチームは、たとえ出荷が遅くなったとしても、信頼性と完璧に動くコードを望んでいます。

DevOps のアプローチでは、インセンティブが変わります。開発者は出荷するコードのオーナーなので、夜中に本番環境で起きた問題で起こされるのを避けるために、品質に焦点を当てようとする意欲が高まります。多くの開発者は、このような理由からオンコールを恐れています。しかし、私たちが発見したのは、アジャイル DevOps アーキテクチャではコードの品質が大幅に改善されているため、実際に電話が掛かってくることは予想よりもずっと少ないということです。

オンコールであることは、オーナーシップを促進し、インセンティブを調整する戦術であり、リアルタイムの学習を促し、品質の向上とより迅速なイノベーションを促進します。

DevOpsを自分のものにする

チームがDevOpsトランスフォーメーションをナビゲートするのに役立つ情報は、そこら中に豊富にあります。しかし、最終的には、DevOpsの実装方法はチームや組織に固有のものであり、ツールやプロセスだけでは実現できません。

DevOpsの原則は単なるフレームワークですが、そのフレームワークをどのようにチームに適合させるかによって、DevOpsは組織独自のものとなります。チームを変革プロセスに参加させ続けることが、最終的な成功への最も重要なステップです。例えば、新しいプロセスについてチームからのフィードバックを収集し、組織全体からの提案や新しいアイデアを求めてフォーラムを開いておくことは、チームの一体感を構築し、チームが新しい変化を積極的に受け入れようとするモチベーションを高めるのに役立ちます。

このようにして、より多くの成功を収めることで、より多くの支持と採用を得ることができ、文化的な変化は有機的に起こるようになります。多くの先行投資が必要ですが、早い段階での投資は、将来的に配当金として戻ってきます。

指標を理解する

DevOpsの利点について説得力のある議論をするには、証明が必要です。既存のプロセスを測定して定量化し、以下のような質問をして、比較のためのベースラインを作成することを確認してください。

新しいコードを本番環境にデプロイするのにどのくらいの時間がかかるか? デプロイの頻度は? バグのトラブルシューティングにはどのくらいの時間がかかるか? 四半期ごとのダウンタイムはどのくらいか?

これらは単なる測定基準のサンプルであり、あなたの組織で測定するものは全く異なる可能性があります。重要なのは、DevOps モデルの「後」の状態のパフォーマンスを評価できるように、「前」の状態の指標を十分に把握しておくことです。

理想的には、DevOpsアプローチにより指標がより良い結果を示すことが望ましいです。例えば、アップタイムの向上やデプロイ頻度の向上などです。通常、問題を確認する平均時間(MTTA)と解決する平均時間(MTTR)に注目しますが、重要な指標はこれだけではありません。

これらの測定基準を取得することで、改善すべき領域をより明確に把握することができます。経営の第一人者であるピーター・ドラッカーがかつて言ったように、「測定できないものを改善することはできない」のです。 DevOpsには幅広い解釈があり、あなたの組織にとって意味するものは、別の組織にとっては全く異なる意味を持つことがあります。DevOpsへの移行は、リスク、忍耐、コミットメントを伴う重大な変化であり、それが早すぎたり、組織全体の賛同を得ずに行われた場合には、不安な気持ちになることもあります。しかし、思慮深いアプローチでは、開発者がオンコールしている状態でDevOpsの世界に移行する際に生じる懸念や成長の痛みの多くを軽減することができます。

2017年12月26日  (更新日:2022年3月9日)     |    DevOps

オムニチャネルで成功しているリテーラーのDevOpsを学ぶ

ウォルマートのようなリテーラー( 小売業者)の増加に伴い、eコマースとリテーラーの間の戦いが収束しつつあり、Amazonのようなeコマース企業の多くはオフラインでのプレゼンスを確立しています。この2方向の展開をサポートするため、リテーラーとeコマース企業は、優れたオムニチャネルカスタマーエクスペリエンスを提供することを目指しています。

リテールの世界のオムニチャネル

顧客は、店舗内、Webサイト内、モバイルアプリ内、またはソーシャルメディア内の全チャンネルでシームレスな体験ができると期待しています。世界最先端のリテールブランドはトレンドに乗っており、たくさん成功事例があります。以下は、オムニチャネルのリテール体験を提供しているブランドの好例です:

ディズニー:ディズニーランドでの休暇を計画するのは大変です。しかし、ディズニーのWebサイトやモバイルアプリのおかげで、レストランや観光スポットなど、休暇全体をオンラインで計画することができます。また、各アトラクションの待ち時間を知ることもできます。

スターバックス:スターバックスの特典カードを使えば、コーヒー代でキャッシュを使い切ることはありません。モバイルデバイスから簡単に特典カードを取り出して、いつでもカウンターで使えます。

ノードストローム:ノードストロームは、顧客がiPhoneアプリで行う注文を店内のスタッフが補助することで、優れたカスタマーエクスペリエンスを提供しています。各スタッフはアイテムの在庫を確認でき、特定のアイテムが在庫切れの場合、すぐにiPhoneで予約して顧客の家に届けることができます。顧客はオンラインで商品を購入して店頭で持ち帰ることもでき、返品も簡単です。

これらのチャネルでのエクスペリエンスをサポートするためには、深くよく統合されたバックエンドと、一貫したフロントエンドインタフェースが必要です。しかし、これは以前よりもずっと簡単になりました。従来のインフラストラクチャ、ツール利用、そして開発プロセスを放棄して、リテールアプリケーションを構築するための最新のDevOpsアプローチに移行すればよいのです。顧客は絶えず新しい機能や体験を求めており、そのために頻繁になる更新は、安定性を損なうことなくアジャイルさと正確さを最大化する方法で展開する必要があります。これは、デジタルチャネルと物理チャネルをシームレスに統合したエクスペリエンスを構築するために不可欠です。何千もの日常的なやりとりは破綻を生じやすく、また、人気ブランドはサイバー攻撃の目標とされやすいです。何百万人ものユーザーをサポートするためには堅牢なシステムが必要です。システムの可用性とセキュリティを確保する必要があります。これは簡単な仕事ではありません。

いかにしてDevOpsチームがオムニチャンネルリテーラーをサポートするか

インフラストラクチャ層から始めて、アプリケーションスタックまで移動し、オムニチャネルのリテールアプリケーションを構築する際に、DevOpsチームが留意べきことを理解しましょう。

クラウドに移行する

モバイルは、オムニチャンネルのリテールを考える際に最も重要なメディアです。これは、顧客にアプローチする最も個人的かつ強力なチャネルです。どこにいても、お客はあなたの会社とやりとりして、都合のいいときに買うことができます。しかし、ほとんどのリテールアプリは、過去に使われていたクライアントサーバモデルをベースにしていて、現代の最先端の消費者をサポートすることはできません。複数のデバイスやモバイルオペレーティングシステム用のアプリケーションを構築するには、クラウドテクノロジーを活用する必要があります。しかし、いくつかのクラウドツールをあなたのレガシーなスタックに投入するだけでは足りません。AWS EC2などのクラウドサーバでアプリケーションを実行したり、AWS S3などのブロックストレージにデータを格納したり、Sauce Labsなどのクラウドベースのテストプラットフォームを使ったり、Prometheusなどのクラウドネイティブな監視ツールを使ったりする場合は、全システムをクラウドで稼働させるか、少なくともそこへの移行を開始しなければなりません。

マイクロサービスモデルにゆっくりと移行する

マイクロサービスは、単一のモノリシックなアプリケーションを、小規模なクロスファンクショナルチームによって開発・管理される小さなサービスに分解するアプローチです。このタイプの複合型のシステムにより、新しい機能をより早くリリースできます。さらに、あるサービスに障害が発生しても、システム全体をダウンさせることはありません。しかし、マイクロサービスへの移行は、一度に1ステップで行う必要があります。最初のバッチが安定した後に、いくつかの機能を切り分けてください。マイクロサービスアプリは、従来のツールセットを使用する場合に限り、管理が難しくなります。幸いにも、DockerやKubernetesのようなコンテナ技術は、マイクロサービスの管理を容易にしています。

VMからコンテナへの切り替え

クラウドへ移行することが最初にやるべきことです。クラウド内にもう移行していても、アプリをコンテナで実行することが重要です。マイクロサービスモデルに移行すると、サーバインスタンスごとにハードウェアハイパーバイザとOSのオーバーヘッドがアプリのパフォーマンスを低下させます。マイクロサービスアプリケーションを拡張するには、コンテナにコードをパッケージ化する必要があります。コンテナ化すると全く新しいツールセットを使うことになります。たとえば、Kubernetesのようなオーケストレータを活用して、数千のコンテナを管理する必要があります。幸いなことに、コンテナ周辺のツール事情は昨今急速に成熟しました。今日、多くの世界クラスのアプリは、コンテナを使用して確実かつ安全に稼動しています。業界は、クラウドネイティブコンピューティングファウンデーション(CNCF)が認めた標準規格を整理統合しているところです。

分散データストア

インシデント管理でシステムを保護する

現代のマイクロサービスベースのコンテナ駆動型システムでは、多くのパーツがあり、これらのパーツはしばしばフェイルします。DevOpsの呪文の「早く進んで前向きに失敗する」とは、これらの失敗にすばやく反応し対処できる必要があることを意味します。パフォーマンスとセキュリティの両方が、オムチャンネルのリテールアプリの最大の課題です。サイバー犯罪者は多数のユーザーを持つアプリに引き寄せられますが、リテールアプリは名前、住所、クレジットカード情報などの価値のある重要なユーザーデータを数十億単位で持つことが知られています。システム障害やサイバー攻撃から守るには、データポイントを集中管理し、問題に応じて適切な対応者をリアルタイムで把握するインシデント管理システムが必要です。

大規模なDevOpsチームでは、重要な通知が失われる可能性があるため、適切なメッセージが適切な人に届くようにルーティングシステムが必要です。インフラストラクチャの複雑さが増し、大量のデータを処理する必要があるため、機械学習を活用してデータを理解し、重要なポイントに人々が集中できるようにするソリューションが必要です。オムニチャネルリテール向けのインシデント管理ツールは、システム全体にわたる監視、チケット発行およびその他のデータソースを相互に関連付け、集中化することができます。最先端のインシデント管理プラットフォームにより、疑わしいパターンを特定し、インシデントがエスカーレートする前に適切な人材を確保できます。

オムニチャネルのリテールは単純ではないので、完璧なシステムを構築するためには数年以上の時間が必要です。ただし、ここに記載されている方法とツールは、DevOpsチームにオムニチャネル体験を提供するための手がかりを与えることになります。クラウドへの移行、マイクロサービスの活用、コンテナの採用、データストアの分散化、またはインシデントの予見的な管理など、次世代のコンピューティングテクノロジーが今や利用可能です。リテールビジネスに必要なのは、計画を立て直す準備を整えた開発チームだけです。

2017年12月15日  (更新日:2022年3月9日)     |    DevOps

DevOps監視は複数のツールの組み合わせで

監視ツールはDevOps チームの人生を楽にします。正しいDevOps 監視ツールを選択することで、効率的なワークフローとエンドユーザーの幸せを手に入れることができます。

多様なDevOps監視ツール

ほとんどの開発チームのための通常の監視ツールキットには、次のものが含まれます(ただしこれに限定されません)。

インフラ監視ツール アプリケーション・パフォーマンス・モニタリング(APM)ツール ログ解析ツール

各レイヤーに目を通し、あなたのDevOps監視プロセスにどこにフィットするか見てみましょう。

インフラストラクチャとネットワークの監視

これらのツールは、サーバ、ルータ、スイッチなどのインフラストラクチャとネットワーク全体を監視できます。インフラストラクチャ監視ツールは、重要なビジネスプロセスに影響を与える前に、ITインフラストラクチャの問題を特定し解決するのに役立ちます。また、古いシステムで障害が発生する前に、アップグレードの計画を立てるのに役立ちます。インフラストラクチャとネットワークの監視ツールは、メンテナンスの停止がユーザーに与える影響を最小限に抑えます。

インフラストラクチャの健全性を監視することで、インフラストラクチャ上で実行されているアプリケーションの正常性を把握できます。ただし、これらのツールはアプリケーションを完全な一連のサービスとして監視しません。その意味で、今日のクラウドアプリケーションには適していない従来の監視方法を採用しています。

例:Nagios、Zabbix

アプリケーションパフォーマンスの監視

アプリケーション・パフォーマンス・モニタリングツールは、その名前が示すように、アプリケーションのパフォーマンスを監視します。アプリケーションの動作を可視化し、ユーザーに影響を与える問題を検出し、それらの問題を迅速に解決するのに役立ちます。エンドツーエンドのアプリケーションフローを監視し、コードレベルの詳細を含むトレースを提供します。APMツールの診断には深い洞察が含まれており、パフォーマンスの低下や障害の原因となる可能性のある正確なコード行を見つけられます。

APMツールはパフォーマンスの向上、処理速度低下とダウンタイムの防止に役立ちますが、APMだけでは解決できない、さらに深いトラブルシューティングが必要な問題もあります。これらの問題には、ログファイルのインデックス付けと検索が必要です。残念ながら、APMツールはログファイルを分析せず、セキュリティ攻撃を検出できません。この種の分析には、ログ解析ツールが必要です。

例:AppDynamics、New Relic、

ログ解析

ログ解析ツールは、ログファイルを格納しインデックス付けするスケーラブルで信頼性の高い方法を提供します。ファイルをすばやく検索し、ログデータに基づいて詳細な分析を作成し、セキュリティ違反やサイバー攻撃を監視することができます。ただし、エンドツーエンドのアプリケーションパフォーマンス監視は提供されず、コードレベルのトレースを明らかにすることもできません 例:Splunk、Elastic Stack

これらのツールは、エンドツーエンドの監視のためのものではありません。インシデントが発生したときにこれらのツールのいずれか1つだけを使うと、解決の鍵となる部分が欠けることがあります。

監視ツールにはさらにその監視が必要

監視のためにこれらのツールを全て採用したとしても、インシデントが発生したときに混乱を招く可能性があります。これらツール全てからの警告は、重複するデータをたくさん提供します。これにより、あなたはツール間を行き来してあちこち見回することになり、チームだけでなく顧客にも多くの不満を引き起こす原因になります。ツールセット全体からのデータのオーバーロードに直面するので、MTTRは長くなります。インシデント管理での監視を簡素化が必要なのです。

監視ツールを集約する単一のインシデント管理プラットフォームが必要

ITチームやDevOpsチームは、互いに深く統合されたベスト・オブ・ブリード(複数ベンダーの組み合わせ)のツールを使用した監視を長年受け入れてきました。これらの全ての監視ツールを使用すると、矛盾する情報と膨大なアラートが表示されることがあります。その全てを管理し、問題の概要を把握するためのセンターハブが必要です。PagerDutyのようなインシデント管理プラットフォームは、インシデントが発生した際の混乱から秩序を回復するために不可欠です。

インシデント管理ツールは、優先度の低いアラートを抑制し、適切な人に適切なタイミングで優先度の高いアラートを表示することで、ノイズからシグナルを引き出します。インシデント管理ツールは、その他の監視システムと深く統合されているため、あらゆるDevOpsチームが必要とする真のエンドツーエンドの監視が可能です。十分に錬られた通知オプションを使用すると、PagerDutyなどのインシデント管理ソリューションはチームに自分たちへの通知方法を選択させることができます。さらに、これらのプロセスを自動化することで、解決までのの時間を大幅に節約し、全体的なMTTRを削減できます。

全ての監視ツールにはそれぞれ独自の機能が用意されていますが、全体を管理していないと混乱が生じます。1つで全てをカバーできるDevOps監視ツールはありませんが、1カ所から全ての監視ツールを管理して、送られてくるデータをフィルタできるPagerDutyのようなソリューションを使えば、完璧に一歩近づくことができるでしょう。

2018年1月18日  (更新日:2022年3月9日)     |    DevOps

DevOps:開発者の視点から

「オペレーションルームに歩いて行く – もうこれ以上何もする必要はないと思う」

開発者のための最新の機能のリリース(訳注:英語サイトに飛びます)で、PagerDutyのシニアエンジニアDavid Yang氏と私は、私たちの内部アーキテクチャが単一のモノリシックなコードベースから数十のマイクロサービスの組み合わせにまで進化していくのを見てきました。

彼は、8000人以上のPagerDutyの全顧客にアラート通知を送信するサービスを所管するIncident Management – Peopleチームのテクニカルリーダーです。私たちは座って、彼らのサービスの運用について彼のチームがオーナーになるよう切り替えた後の生活について話しました。 私たちが見た利点と欠点に関するいくつかの観察を紹介します。

今はチームがサービスのオーナーになっています

開発者がサービスのオーナーになるモデルに移行して以来、開発者の独立性はますます高まっています。副作用は、インフラストラクチャのプロビジョニングと管理の難しさを最小限に抑えられたことです。現在、チームは邪魔と障害を最小化するように最適化したいと考えています。 インフラをサポートするチームは、人間の介入の必要性を最小限に抑えるために優れたセルフサービスツールを提供することに重点を置いています。

開発者がコードのオーナーになると、サイクルタイム、つまり「これは問題だ」というメッセージがどこかで表示されてから実際に問題を解決するまでの時間が短縮されます。これは非常に価値があります。

文化面での変化は

人々がより多くのコードのオーナーになり、自分たちが運営するシステムのために一般的にはより多くの責任を負うようになると、道を邪魔するものを排除することを重視する文化が広がります。各チームは、 「自分が今まで、あるいは将来ブロックされていないことを確認するにはどうするか」という考え方に向かって最適化されます。ブロックされるともっとはっきり分かります。以前は、ホストをプロビジョニングするたびに私は毎回運用チームに問い合わせなければなりませんでした。 私のチームは他のチームの障害物で隠されていないため、自分たちの障害物をよりはっきり見ることができます。

私たちには、エンドツーエンドの顧客価値を提供するプロセスのすべてを所有することに重点を置いたチームがあります。これは非常に貴重です。

インシデント対応プロセスではどうに役立つ?

サービスのオーナーシップの境界が明確になっています。運用の問題が発生した場合に、影響を受けるチームを簡単に特定できます。そして、自分が従うべき正しい手順、例えばそれは「これがそのチェックリストです」という客観的な手順ですが、それを知っているということが大事です。 これによって問題の解決に100%集中し、インシデント前後のコミュニケーションに集中することができます。

それほどうまくいかなかったことも

サービスのオーナーになっていても、そのサービスに問題が発生しないとは限りません。当社のサービスの運用維持に専念するためには、そのためだけに使う時間が必要です。 これが結局はチームの時間の多くを占めます。特に知識のギャップがあるレガシーサービスで問題になります。 当初は、私たちのスプリントでの作業性を守るために十分なガードレールを設置していませんでした。 これは客観的な意思決定を可能にするためにKPI(特定のスケーリング目標や運用負荷レベルなど)を活用することで改善されています。

将来は?

[業務関連のワークロードと機能開発ワークのバランスをとるため]各チームは、メトリックによって客観的な意思決定を推進するために、次のように問い続けています。「私はこうした道具を日常的にどう活用していますか? どのようにして客観的な意思決定を行うのですか?」と。

組織内の業務の中で変更を実行しようとすると、多くのコラボレーションが必要になります。 適切なメトリックが何であるかを把握し、それらのメトリックについて議論することも必要です。

2017年12月19日  (更新日:2022年3月9日)     |    DevOps

DevOpsへのよりディープな監視の導入

継続的インテグレーションのポイント は、ビルドとテスト を自動化し、効率と品質を開発パイプラインにもたらすことです。しかし、継続的インテグレーションプロセスに伴って頻繁な更新が行われると、状況が悪化してしまうことがあります。

重大なインシデントや何か悪いことが起こるとパニックになります。それがインシデント管理のよくある風景です。しかし、何かが起きた後に常にそうなるでしょうか。初めからインシデント管理を継続的インテグレーションプロセスに組み込むことで、アカウンタビリティ、可視性、透明性を全く新しいレベルに引き上げることができます。

ここでは、いかにしてDevOpsへの深い監視を行い、それがアプリケーション開発方法を変革するかについて説明します。

コードの品質に対する責任は 継続的インテグレーションフェーズから始まります

DevOpsの目標は、開発チームと運用チームの協力を促進し、お互いのニーズを理解し、状況が悪化したときでも相手の責任を追求するのではなく共に解決することです。稼働時間の向上は必ずしもOpsチームだけの役割ではありません。DevOpsでは、新たに加わった開発者でさえ稼働時間に責任を感じ、ダウン時には協働することができるはずです。

継続的インテグレーションを実装する大きなメリットのひとつは、開発チームと品質管理チームの両方が出荷品質のコードに対して責任を負うことです。新しいビルドがコミットされるたびに、一連の自動ユニットテストによってコードが検証されます。インシデント管理がこのレベルで実装されていれば、何か不具合が発生した場合には適切なデータが手元に残るため問題を効果的に解決できます。こうして、誰も責めずに、パニックに陥ることもなく迅速にトラブルシューティングを行うことができます。インシデント管理を導入すれば高い品質を求める文化が醸成され、開発チームと品質管理チームは互いに可用性に責任を負うようになります。

緊急医療チームと同じように、責任者が現場に到着する前に最初に働く初心者のエンジニア、つまりオンコールエンジニアを待機させることも良いでしょう。この責任の文化を醸成するには、監視データをチーム間で見えるようにするモニタリングとオンコール管理システムが必要であり、公平なシフトに基づいて計画外の作業を分担する必要があります。

開発チームと運用チーム間の可視性

チーム全体の取り組みと進行状況を把握することで、誰もが自分の仕事に集中できるようになります。多くの企業は、悪い事が起こったときやインシデントが発生したときにのみ、Opsチームに新しいコードの実装を任せます。結果として、Opsチームは不信のために変更を控えていると非難され、更新が遅くなります。

Devチームが計画段階から変更点についてOpsチームに情報公開を行っている場合、それがビジネス全体にどのように役立つかを理解することができます。Opsチームに開発フェーズから新しいアイデア、今後の機能、考えられるリスクを認識してもらうことは、チーム全体の意識を高めます。Opsチームは何かあってもいいようにいつも準備ができているため、安心していられます。

早い段階でインシデント管理を実装することで、アプリケーションの健全性と問題が発生したときに何をすべきかを誰もが理解できるようになります。誰もが大きな図式を知っており、より迅速にトラブルシューティングを行うことができます。

透明性には統一された指標が必要

チーム全体が、危機の間お互いの責任を認識しているほど、彼らはより効果的に動き、より速く正常に戻すことができます。

複数のソースからデータを収集し、相関させ、分析することにより、DevとOpsは継続的な洞察を得ることができます。しかし、そのデータは実用的になった場合にのみ価値があります。インシデント管理ソリューションを使用すると、適切な人に問題の全体像を提供し、最終的にはアプリを壊してしまう可能性のある問題をゼロにすることさえできます。

最後に、インシデント管理ツールが問題が起きている時にリアルタイム通知を提供することで、実際に役立つことを確認してください。さまざまな重大度の問題の経路を決めるプロセスを定義することは非常に重要です。データを捨てようとは思いませんが、手元の問題を解決することに貢献しない無意味なメトリックを通知されることは望みません。

DevOpsへのトランスフォーメーションに成功するためには、継続的インテグレーションとインシデント管理が不可欠です。チーム全体にとってたのもしいリリーフとなり、ダウンタイムに対するより迅速な対応が可能になります。インシデント管理によってDevOpsエンジンは故障することなくスムーズに回転するようになります。

<  12  >