BLOG
インシデント管理データで技術的負債を測る

投稿:2018年1月18日   |    更新:2022年3月10日

技術的負債(technical debt)が借金のようなものだったら、手作業でチェックインしない限り、それを追跡するのは難しいでしょう。 多くの人にとっては自分の当座預金口座に資金がなくなったことを知る唯一の方法は、口座の残高を確認することです。さらに悪くなると、小切手が返されたり、デビットカードが拒否されます。

しかし、技術的負債の測定はもっと自動化できます。 これは、お客様の銀行口座とは違って、ITインフラストラクチャの場合はそれを専用のツールで継続的に監視でき、重要なヘルスメトリックについて通知を受けることができるからです。 次に、監視データを使い技術的負債についての情報を得ることができます。 つまり、データセンターで問題が発生したときに手動で監査する必要はありません。 問題があることを知るのに、サーバーがダウンするまで待つ必要はありません。 インシデント管理ツールは、その情報を提供します。 エクステンションを使えば手作業で面倒なことを測定することなく、技術的負債を取り込む方法も提供しています。

インシデント管理は、技術的負債を追跡して修正するのに役立ちます。追加の投資は必要ありません。

技術的負債の定義

c0cde857356e4f87ca2097122ad7e386

まず、技術的負債の意味を説明しましょう。 技術的負債とは、長期的には非効率性やその他の問題を引き起こすような、ソフトウェアコードやアーキテクチャの不完全性を指します。 たとえ欠陥自体が小さいとしても、その効果が継続的に繰り返されるため、時間の経過とともに多くの利子が生じることがあります。

例えば、モジュラーアプローチを採用しておらず、同じ機能の複数のバージョンをコードに含むようなプログラムは、より優れたプログラムよりも実行に数ミリ秒余計にかかることがあります。 一度だけそれを実行するなら、大きな問題にはなりません。 しかし、それがサーバーの側で1日に数千回実行されるWebアプリケーションであれば、パフォーマンスが低下したり、CPU時間が浪費されたりするという負債があっという間に積み上がります。

技術的負債には多くの潜在的な原因(訳注:クリックすると英語版のWikiに飛びます)があります。 場合によっては、例えば何かを迅速に導入しなければならず、ベストプラクティスに従う時間がない場合は、負債がコストに見合う価値があると判断(少なくともその時点で)して、技術的負債を意図的に負うことがあります。管理者の中で最も優れた人でも将来の技術的負債を避けることは難しいです。 将来を見通せない限りは(例えば、あなたがアップグレードする余裕がないために今日も使用している10年前のスイッチが、最新のファイアウォールツールではうまく機能しないということは過去の時点では分からなかったはずです)。 その場合、技術的負債は、不完全な世界での生活で起きることまったく同じ経緯をたどります。

技術的負債を追跡する

技術的負債には多くの源がありますが、それをインシデント管理を使用して測定するというアプローチは、問題の原因を問わず問題の追跡を容易にします。繰り返しますが、時間のかかる手動のシステム監査で非効率性を検索する代わりに、インシデント管理データを技術的な負債の程度を評価し、それを評価するためのプロキシとして活用できます。

やり方を理解するために、PagerDutyが追跡するさまざまな種類のインシデント管理データの例と、それらのデータが技術的負債について明らかにできることをいくつか見てみましょう。

まず、ツールが生成するアラートの生の数を取得します。これは非常に基本的な指標であり、さまざまな要因によって影響を受ける可能性があります。しかし、インシデント管理の報告システムが適切に構成されており、インフラストラクチャに大きな変更を加えなくてよいと仮定すると、技術的負債の規模とツールが報告するインシデントの数との間に相関が見られる可能性があります。負債が増えるとパフォーマンスが低下し、応答時間やリソースレベルが特定のしきい値に達するとアラートがトリガーされるためです。したがってアラートの発生率が月ごとに減っていれば、コードがより効率的になったので技術的負債が減っている可能性があります。

平均解決時間(MTTR)は、技術的負債を見るためのインシデント管理の指標です。MTTRが悪い一般的な原因の1つは、コードがあまりにも複雑すぎることです。例えば、上の例を再利用するために、急いで書かれたコードには冗長な機能が含まれているため、管理者にはすぐに理解するのが難しいでしょう。これは、事件に対応するためにコードを読み込んで変更する必要がある場合に、解決時間が長くなることを意味します。

技術的負債の源を見つける

インシデント管理データは、技術的な負債に関する一般的な傾向を追跡するのに役立つだけでなく、問題の原因をゼロにするのにも便利です。

たとえば、特定のプログラムに関連するインシデントのMTTRが平均MTTRよりも高い場合、問題のプログラムが技術的な負債を生成している可能性があります。同様に、あるタイプのオペレーティングシステムを実行しているサーバーが不均衡なアラート数の大部分を占めている場合、おそらくコードまたは構成上の欠陥があります。それはあなたが対処できる技術的な負債です。

インシデント管理データを使って技術的負債を特定し、対処するのはとてもクールで、ほとんど追加作業を必要としません。あなたは既にPagerDutyのような操作と報告を集中化するハブ(うまく設定すればですが)を備えた監視システムを備えています。これらのリソースを活用して技術的負債を見つけて修正するには、追加のツールや投資を必要としません。既存のソフトウェアを使用して、コードや操作をより効率的にすることができます。