「バジェット（予算）」という言葉を誤解するなかれ

「サイト信頼性エンジニアリング」（SRE）における「エラー予算」とは何か

IT運用チームは、どの程度の数の問題発生を許容するのだろうか。「エラーバジェット（エラー予算）」という考え方の意味をおさらいしよう。これを誤解するとIT戦略を立てる際にリスクを読み違える恐れがある。

公開 2018年03月21日 05時00分

著者

Tom Nolle

[TechTarget]

印刷する

　ミスを全くしない人は「警戒し過ぎ」というそしりを受けるのだろうか。例えばバスケットボールの決勝戦、2点差の場面を考えてみよう。試合終了数秒前、リードしているチームの選手はファウル覚悟で敵のスリーポイントシュートを阻止しても良いだろうか。ほとんどの人は阻止すべきと答えるだろう。同じ疑問をITに当てはめてみよう。「エラーバジェット（エラー予算）」とは、IT部門の思考を限界まで高める方法だろうか。それともエラーバジェットというトレンドは、過激な考え方を正当化しているにすぎないのだろうか。

　エラーバジェットの考え方は、サイト信頼性エンジニアリング（SRE）によって広まった。これは、ある程度のリスクを見越し、IT運用を迅速に進めるために必要な予算という考え方だ。問題を起こさないチームは、恐らく、イノベーションを起こすこともなく、運用を改善しようともしないだろう。一方で、多くの問題を引き起こすチームは、イノベーションの名目で信頼性を犠牲にしているだろう。こうしたチームは、問題の数を減らさなければならない。エラーバジェットは、個人や企業が冒すリスクを測る方法になる。

　本稿では、テクノロジーにおける「攻めの戦略」は全面的に支持する。だが、エラーバジェットという考え方には大きな問題があると考える。エラーバジェットは、IT戦略を変えてしまい、リスクのために危険を冒すことを推奨するような、過剰かつ過激な計画になる恐れがある。ITプロジェクトの承認プロセスがリスクとメリットを最適なバランスに保っているかどうかという正当な疑問に対処する際に、エラーバジェットの要素があると対処方法を間違えることになる。

併せて読みたいお薦め記事

サイト信頼性エンジニアリング（SRE）とは

Googleがおススメするシステム運用管理手法「SRE」「SLO」のメリット

SLO／SLAとは何か

クラウドのSLAについて

IT部門のリスクの評価と管理の向上

　エラーバジェットが誇張されると、本来の目的に悪影響を及ぼす。エラーバジェット本来の目的は、特定のアプローチから生み出されたビジネス目標のリスクレベルを表すことだ。つまりプロジェクトで問題が発生した場合のエラーバジェットとは、予測からどの程度外れたらプロジェクトの投資対効果検討書が台無しになったといえるのか、の許容範囲を示すものだ。問題の発生はある程度までは許容可能だ。エラーバジェット本来の目的は、どの程度の問題発生のリスクなら予算として吸収し、プロジェクトを正当化できるかを測ることだ。

　最先端を行く一部のITプロフェッショナルは、SREにおけるエラーバジェットを「義務を負う境界線」だと感じている。恐らく、この予算を少し上回らなければならないと感じている。こうした意味の変化は、ある意味避けられないものだ。人は新しい基準を与えられると、いつもその基準で物事を測るようになる。例えばチャーリーはエラーバジェットを2回上回り、エイミーは1回もエラーバジェットを超えることはなかったとする。エイミーはリスクを取らなかったのかもしれない。チャーリーは目指すレベルが高すぎるのかもしれない。「虎穴に入らずんば虎児を得ず」と「君子危うきに近寄らず」は対立する表現だ。

　IT変更管理プロセスでよく交わされている、エラーバジェットに関する議論において、欠けているのは正確性だ。エラーバジェットでは、プロジェクトのトレードオフとリスクを数値化すべきだ。サービスの目標に対してリスクを生み出しているのは何か、境界線を押し上げることで得られるメリットは何かを正確に把握しなければならない。だが、ITプロフェッショナルは、エラーバジェットの裏付けになる数値をめったに提示しない。CIMI Corporationが2016年に実施した企業のITプロジェクト意思決定に関する調査では、回答者の90％がリスクを全く数値化しておらず、メリットのみを数値化していると答えた。

　このITプロジェクト管理プロセスには欠陥がある。例えば、ほとんどのアプリケーションにはアップタイムについての目標がある。アップタイムとは、アプリケーションが利用可能だと予想される時間の割合を指す。調査した企業の中で、アップタイム率が低いとどうなるかを考えていたのは2％にすぎなかった。つまり、このような変更の結果をほとんど数値化していない。アプリの可用性を上げることで生まれるメリットを見積もっている企業はさらに少ない。では、こうした企業はそもそもどのように目標を設定しているのだろうか。

　本稿は、数値化できないものを話題にしている。エラーバジェットとは、サービス目標の余裕として許容できるダウンタイムを予測する方法ではなく、世間話のテーマになってしまっている。前述の調査では、チームのメンバーが「このコードでいつも通りのエラーバジェットに近づいた」などと話していると報告している。さらには、管理者がチームに対してエラーバジェットぎりぎりで運用することを期待している場合があるとも報告している。リスクを客観的に測る数値がなければ、境界線にどれほど近づいているかを知る方法はない。

　エラーバジェットのこうした傾向には、管理の失敗が隠れている。本当に注意すべきこととして目標を定義できれば、目標による管理は素晴らしい考えになる。だが往々にして、測定する必要があるからではなく、測定できるという理由で目標を選んでいる。

予算の大幅な削減

　バジェット（予算）という言葉にも問題がある。結局のところ、管理者は予算をどの程度真剣に受け止めているのだろうか。ITプロジェクトを管理する達成度として、我々はプロジェクトの予算を持っている。ほぼ全ての管理者は、富の分け前を得るには、予算を少しだけ上回るのがこつだと知っている。これは昔からあるビジネスの知恵だ。数％ほど下回る形で予算内に収めると、次回のプロジェクト予算では最初からその率が削減されることになる。3～4年後には、予算もプロジェクトも消えうせる。

　エラーバジェットが境界線になるのなら、それを追求するのは自然なことだ。競争心の強いITプロフェッショナルにゴールテープを見せれば、それを通り抜けたくなるのは当然だろう。スターターピストルを見せれば、号砲と同時に走りだそうとするだろう。もしもエラーバジェットが「限界リスク」「報酬分析」などといった別の名前で呼ばれていれば、同じように管理行動に奇妙な変化が生じていただろうか。実際のところ、管理者はおとなしくなるだろう。試してみるといい。活気は生まれないだろう。

　活気は過剰な宣伝を生む傾向にある。人々の注目を集める派手な言葉は、物事をうまく宣伝できる。だが宣伝していることは、本来の意味とは違っていることが多い。いずれ正しい使い方によって、エラーバジェット編成の正しい概念を取り戻せるだろう。勝利するためにファウルするのではなく、勝利する確率を計算すべきだ。

印刷する