• ブログ
  • 製品
    • PagerDutyの製品機能
      • アラートの集約と分類
      • サービスとチームの組織
      • システム&ユーザーレポート
      • プラットフォームの拡張性
      • モバイルでのインシデント管理
      • ライブコールルーティング
      • リアルタイムコラボレーション
      • 事後検証から学び改善する
      • 多様なアラート機能
      • 簡単なスケジューリング
      • 信頼性の高い環境
      • エンタープライズレベルのセキュリティ
    • 操作画面の特徴
    • 開発者の責任
    • 部門ごとのPagerDuty活用法
    • ITの運用
    • ビデオで学ぶPagerDuty
  • 事例
  • サポート
    • FAQ
    • インテグレーションガイド
    • 日本語サポートサイト
  • 価格

  • お問い合わせ
  • Why DSC?
  • 無料トライアル
  • ブログ
  • 製品
    • PagerDutyの製品機能
      • アラートの集約と分類
      • サービスとチームの組織
      • システム&ユーザーレポート
      • プラットフォームの拡張性
      • モバイルでのインシデント管理
      • ライブコールルーティング
      • リアルタイムコラボレーション
      • 事後検証から学び改善する
      • 多様なアラート機能
      • 簡単なスケジューリング
      • 信頼性の高い環境
      • エンタープライズレベルのセキュリティ
    • 操作画面の特徴
    • 開発者の責任
    • 部門ごとのPagerDuty活用法
    • ITの運用
    • ビデオで学ぶPagerDuty
  • 事例
  • サポート
    • FAQ
    • インテグレーションガイド
    • 日本語サポートサイト
  • 価格

  • お問い合わせ
  • Why DSC?
  • 無料トライアル

買うべきか作るべきか?

  • On 2017年12月28日
  • Blog

典型的な技術者はたった1つの質問ですべての課題に対峙します:「私は自分でこの ソリューションを構築できるだろうか?」と。そしてこの質問は重要な考察が得られるので十分考えるに値します。 では私たちは作るべきですか?買うべきですか? インシデント管理ソリューションの評価は今この問題を招いているようです。 しかし、今インシデント管理プラットフォームを作るべきか、あるいは購入するべきかは、どう分かるのでしょうか?

 

なぜビルドするの?

 

独自のソリューションを構築したいという願望が、商用ソリューションの調達権限があなたにないという単純な理由によることもあります。 例えばエンタープライズのITにはツールの予算があっても、DevOpsチームがそれを必要としていたりします。 オープンソースプロジェクトを基にソリューションを構築する方が、商用ソリューションを購入するのに必要な長い駆け引きをするより簡単に思えるかもしれません。 しかし、これは組織的な問題であって、技術的な問題ではありません。 そしてカスタムビルドのソリューションは短命になることがよくあります。

 

でも独自のソリューションを構築する理由は他にもあります。

 

  • 現実のまたは既に必要が見えている固有の要件がある
  • セキュリティとプライバシーに関する懸念がある
  • コスト

 

これらは、インシデント管理ソリューションの構築を検討する正当な理由ですが、どれも精査する必要があります。

 

あなたの要件は本当にユニークですか?これが当てはまるかどうかを特定する方法は、競合他社と彼らが使っているものを見て、さらに類似の組織と比較して要件を調査することです。同時に、独自の要件があっても、なぜそれがユニークであるのか疑問に思うかもしれません。それって本当に必要なの?と。

 

セキュリティに関しては、商業的なインシデント管理を使わないようにさせるようなセキュリティとプライバシー上の懸念は何ですか?データが暴露される可能性がありますか?ほとんどの場合、アプリケーションのデータはアラートの中に含める必要はありませんが、そうなっている場合は、検討する必要があります。一般的なセキュリティに懸念があるのなら、ベンダーは自らが常にセキュリティの脅威に敏感であろうと努めていることを知っておいてください。多くの場合彼らはあなたの社内の運用チームよりもセキュリティの面ではるかに優れた能力を持っています。

 

そして、コストの問題があります。独自のソリューションを構築する上で最もコストのかかる側面は簡単には数字にならないため、コストの計算は難しいのです。インシデント管理サービスの月額料金と、フルタイムの開発者による一回きりの開発のコストを計算するのは簡単です。しかし、継続的なメンテナンス、機能の変更、および大きな一回切りの開発のコストを予期することは困難です。このソリューションを構築していない場合に、開発者は何をしているんでしょうか?また、開発中に複数のプロジェクトやバックログを脇に置いてしまうコストはいくらですか?構築した人が退社した場合に別の問題が発生します。残されたコードベースを理解するためにまたコストがかかります。組織のインフラストラクチャのミッションクリティカルな部分に関連している場合、知識を持つ人が組織を離れることは望ましくありません。

 

インテグレートしてますか?

 

インシデント管理ソリューションの構築には、1つに大きな弱点があります。成功したインシデント管理プラットフォームには、ソース(アプリケーションとインフラストラクチャなど)とディストリビューション(コラボレーションツールなど)への統合に関する膨大なライブラリが用意されています。これらの統合を実現するためには開発者は新しいAPIに対して習得し、構築する必要があり、かなりの時間がかかります。独自のインシデント管理プラットフォームを構築する組織は、いろいろなユースケースをサポートする必要がなく、重要な統合を行うだけで済みます。

 

しかし、これらのシステムのAPIが変更されると、あなたは盲目になる可能性があります。新しい機能を使えず、プラットフォームを完全に壊す可能性があります。オープンソースプロジェクトは、統合の中での変化に、あるいは新しいものを作リ出すために素早く対応することはありません。何か不具合が生じた場合も、開発者はもう別の何かを抱えています。もちろん、インシデント管理システムと統合する必要のあるツールの選択は、チームの規模の拡大とそのニーズの変化に伴って変化する可能性があります。

 

ビルドする時期

 

オープンソースプロジェクトを基盤とするカスタムインシデント管理プラットフォームが有用なシナリオがあります。それは特定の目的のためのビルドが必要という、とてもニッチなシナリオです。一般的に、このようなソリューションが必要な組織は、グローバルでの商業的インシデント管理を行っており、ニッチなシナリオのためにインシデント管理プラットフォームのAPIに統合していることさえあります。

 

もう1つの目的は、アプリケーションまたはインフラストラクチャのサポートとは異なるコンテキストで使用されるアラートのためです。おそらくそのアラートはコラボレーションや製品管理に使用されています。このような場合は、自社で作った他のユースケース向けの責任の低いシステムと、商用およびミッションクリティカルなインシデント管理システムとそのユースケースを分けたほうが有用な場合があります。アプリケーションの使用方法から学ぶことについては同じことが、すでに多くのカスタマイズを行っているチームにも当てはまります。例えば、新しい機能がローンチされたときに、その機能が使用されたらアラートを受け取るということができます。また、新しいインフラストラクチャが配備されたときに、パフォーマンスを示す特定のKPIにヒットしたときにアラートを表示させるように設定することもできます。

 

もう1つの理由は、内外へのデータ漏えいの懸念がある場合です。例えば、是正措置が個人を識別できる情報を、内部のティア1のサポートに、その人たちには見る権限がないのに晒してしまうアラートです。これは問題であり、特に規制産業では問題となる可能性があります。 ほとんどの場合あなたはプラットフォームでの役割と見られる内容を変更できるため、これは問題にはなりません。一般的に言って、あなたはそれを常に試すようにするべきです。避けられない場合もまれにはあるでしょう。

 

あなたの輝く時間が来る

 

熟練した技術者は、自分の興味の範囲を超えて、いつビルドや購入をするのが適切かを判断し問題を解決できるようになります。このソリューションは早速作り始めるべきで、立ち止っていてはいけません。これはカスタムソリューションに伴う長期的なサポートであり、リスクです。ソリューションの作成だけでなく、実行する必要もあります。インシデント管理システムにインシデント管理システムをインストールしているんですか?他の何かの稼働時間を心配することはストレスであり、インシデント管理がダウンすると、何も見えなくなります。

 

コードベースとインフラストラクチャへのカスタムニッチの統合を理由に、独自のインシデント管理ソリューションを構築することが正当化されることがあります。あるいは、商用インシデント管理と連動する非ミッションクリティカルなユースケースがある場合は、独自のインシデント管理を構築する価値があります。しかし、一般的に商用ソリューションの総所有コスト(TCO)は低く、規模の拡大に合わせてニーズに対応し、特定の専門家が退職したときにツールやプロセスが破壊されないようにし、キュリティとプライバシーに関する懸念にもより良いカバレッジとソリューションを提供します。

 

ビルドや購入を決定するときは、機会費用に重点を置くことをお勧めします。これはあまり知られていない費用ですが、これを考えると普通はかなり早く答えがはっきりします。

 

0 Comments

Recent Posts
  • Japan IT Week 春 出展報告 2022年4月19日
  • PagerDutyをJapan IT Week 春に出展します 2022年3月21日
  • インシデントフローと対応の省力化を実現するPagerDuty&Rundeckを出展~Japan IT Week 秋 2021年11月10日
  • システム運用を強力に支援するPagerDutyとRundeckをJapan IT Week秋に出展 2021年10月25日
  • DevOpsのROIを測定する方法 2021年8月23日
  • 8/25 CEDEC 2021でCI/CDツールHarnessとインシデント管理ツールPagerDutyの活用例を紹介 2021年8月20日
  • PagerDuty Summit 2021の概要 Part 2 2021年7月12日
  • PagerDuty Summit 2021の概要 Part1 2021年7月2日
  • 6月23日-25日 PagerDuty Summit 2021 バーチャル開催のご案内 2021年5月20日
  • DevOpsを高速化するための6つのステップ 2020年10月15日
Product Tags
AWS Blog DevOps News Post Mortem SecOps signalfx Slack SRE インシデント インテグレーション オンコール・スケジュール オンコール管理 スケジューリング ステークホルダー ビジネス関係者 モニタリング モバイル リリース 事後検証 導入事例Video 更新 製品アップデート

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

Twitterはコールセンターをなくす

Scroll
会社情報

株式会社Digital Stacks

〒141-0001

東京都品川区北品川5-5-15

大崎ブライトコア 4F SHIP 414


  • Home
  • 製品情報
    • PagerDutyの製品機能
    • 操作画面の特徴
    • 開発者の責任
    • 部門ごとのPagerDuty活用法
    • ITの運用
    • ビデオで学ぶPagerDuty
  • サポート
    • FAQ
    • インテグレーションガイド
    • 日本語サポートサイト
  • DSCが選ばれるポイント
  • 価格
  • お知らせ
    • お知らせ一覧
      • 更新情報
      • メディア掲載情報
      • 受賞情報
  • 更新情報
  • PagerDutyの製品機能
    • アラートの集約と分類
    • サービスとチームの組織
    • システム&ユーザーレポート
    • プラットフォームの拡張性
    • モバイルでのインシデント管理
    • ライブコールルーティング
    • リアルタイムコラボレーション
    • 事後検証から学び改善する
    • 信頼性の高い環境
    • 多様なアラート機能
    • 簡単なスケジューリング
    • エンタープライズレベルのセキュリティ
  • PagerDuty導入事例
    • 導入事例インタビュー:株式会社ミクシィ
    • 導入事例インタビュー:イーサポートリンク株式会社 
    • 導入事例インタビュー:株式会社いい生活
    • 導入事例インタビュー:株式会社Jストリーム
    • 導入事例インタビュー:SmartNews 尾形暢俊氏
    • 導入事例:IBM Cloud
    • 導入事例:IBM Smarter Workforce
    • 導入事例:GREE
    • 導入事例:Panasonic
    • 導入事例:Evernote
    • 導入事例:Backcountry
    • 導入事例:Groupon
    • 導入事例:SendGrid
    • 導入事例:Brightcove
    • 導入事例:Code.org
    • 導入事例:インディアナ大学
    • 導入事例:Signal Sciences
更新情報
  • Japan IT Week 春 出展報告 2022年4月19日
  • PagerDutyをJapan IT Week 春に出展します 2022年3月21日
  • インシデントフローと対応の省力化を実現するPagerDuty&Rundeckを出展~Japan IT Week 秋 2021年11月10日
  • システム運用を強力に支援するPagerDutyとRundeckをJapan IT Week秋に出展 2021年10月25日
  • DevOpsのROIを測定する方法 2021年8月23日
  • 8/25 CEDEC 2021でCI/CDツールHarnessとインシデント管理ツールPagerDutyの活用例を紹介 2021年8月20日
  • PagerDuty Summit 2021の概要 Part 2 2021年7月12日
  • PagerDuty Summit 2021の概要 Part1 2021年7月2日
  • 6月23日-25日 PagerDuty Summit 2021 バーチャル開催のご案内 2021年5月20日
  • DevOpsを高速化するための6つのステップ 2020年10月15日
Copyright © Digital Stacks Corporation. All Rights Reserved.
  • 無料トライアルを申し込む
  • お問い合わせ
  • 販売会社情報
  • 個人情報保護方針
  • サイト利用規約