サービスレベル：設計と運用のプラクティス

概要

サービスレベルをいかに設計し、いかに運用するか。自分なりの考えの整理です。 尋常ではない長さになりました。随時アップデートします。たぶん。

ウェブオペレーション ―サイト運用管理の実践テクニック (THEORY/IN/PRACTICE)

もくじ

SLAとは何か

関係者が同じ目線を持つためのもの

例えば、システムエラーで真夜中にアラート通知が来たとする。そのエラーはどの程度のレベルなのか。 今すぐ対応しなければいけないレベルなのか。翌朝に出社してから対応すれば問題ないレベルなのか。

関係者全員が同じ目線を持てるようになると、運用が少しだけ楽になる。 過剰な期待に振り回されなくなる。未熟な対応に甘んじなくなる。

システムの保守運用だけに限った話ではない。「明日までにお願い」とか「大事だから緊急でやってくれ」とか。 そんな依頼を受けて違和感を覚えた経験があるなら、サービスレベルについて考えることで便益を得られるかもしれない。

火の一ヶ月間を経て……

私自身が体験したのはこんな事例¹ã ã€‚

1営業日あたり2件の障害が発生する日々が1ヶ月間続いた。 ふと気が付いたら朝の5時だったり、土日が丸々潰れたり、そんな日々だった。 そのせいでヒューマンエラーや二次災害も起きた。まさに火の一ヶ月間だった。

炎が沈静化してから、真っ先にサービスレベルを定義して、関係者の合意を取った。 すると、死に物狂いで対応した内容の約半分が、必ずしも障害とは言えないことが分かった。 最初から品質に関する共通指標があれば、無理をせず安定したトラブル対応ができただろう。

SLAは契約ではなく、目標の合意に過ぎない

「受注側が満たせなかったら、発注側に賠償金を支払う」といった契約条件としてSLAを盛り込むケースがあるらしい。 そうではない。SLAは、サービスとして目指したい品質を、関係者内で合意するためのものだ。

未達成だと損をするような枠組みでは、高い目標に挑戦できるわけがない。 OKRという目標管理手法では「実績が達成度70%くらいになる高い目標」を定めるのが良いと言われている。 目標を合意するというのはそういうことだ。

SLAと聞くと、国内大手SIerがお堅い契約をするイメージがあるが、それは誤った認識だ。 GoogleやFlickerでもSLA（もしくは類似する概念）にもとづいてシステムを運用しているらしい。 本格的にITサービスを開発・運用するなら、規模や形態を問わず適用できるのがSLAだ。

SLA：設計のプラクティス

いかにSLAを設計するか。

サービスのレベルを設計する

機能観点でのレベル分け

3〜4段階でレベルを分けることができる。

レベル	内容	例）音楽共有SNSを運営していた場合
1	セキュリティや法律を守れているか	演奏者の個人情報が本人以外から見えてしまうとレベル1の違反となる。
2	相対的に重要な機能が使える状態になっているか	ログインや音楽演奏（重要な機能）ができないとレベル2の違反となる。
3	相対的に重要でない機能が使える状態になっているか	楽曲再生数（おまけ機能）が正しくカウントされないとレベル3の違反となる。

※ちょっとした画面の表示崩れなどを「軽微な不具合」として4段階目に入れることもできる。

※機能観点とは言えないが、カスタマーリレーションを広義のサービス運用に含めると、 社会的配慮（LGBT・宗教・趣味・職種への言及）についても、セキュリティや法律と同レベルで扱う必要がある。

コア機能を定義する

機能の優先度をつけるのは難しい。関係者の中で合意を得るのはさらに難しい。 「8割の機能は使われない」「顧客は2割の機能にお金を払っている」という言葉を踏まえて、優先度を判定することになる。

例えば、Flickerでは 写真を閲覧する機能 > 写真を新たに投稿する機能 の優先順位となっているようだ。 『ウェブオペレーション - サイト運用管理の実践テクニック』にて、Paul Hammond（元Flickerグループリーダー）が述べている。

サイトを提供する上でコアとなる機能を真剣に考えるとよいだろう。それがなくてもサイトを継続できる機能は何だろうか。

例えば、Flickerの場合は、写真を閲覧する機能がそのままであれば、アップロード機能がなくても構わない。

（この書き方をどこまで解釈できるかは怪しいが）少なくとも、コア機能については考えた方が良い。

まずは、自分のサービスがどんな機能を提供しているのか一覧化すると会話しやすくなる。 そのリストをもとに「コアとなる機能・サブとなる機能を振り分けましょう」と言って議論を始められる。

「全部重要」は「全部重要ではない」と同じ意味になってしまうことに注意したい。 チームのキャパシティを超える事態に陥った時には、1つ1つ優先順位を付けて行動せざるを得ないからだ。 やるべきこと・やりたいことは、大抵の場合、チームのキャパシティを超えている。

そのサービスにとって、何が本当に重要なのか。何が提供価値なのか。定義することが重要。

非機能観点でのレベル分け

システムとしての信頼性と性能がメインの対象となる。

信頼性

観点	内容
サーバサイド	サイト停止の頻度・時間
クライアントサイド	モバイルアプリやフロント画面でのクラッシュ
プラットフォーãƒ	規約違反でAppStoreからBANされないか、自己証明書を使ってFirefoxからアクセス不可になっていないか

性能

観点	内容
レスポンス状況	最終指標：応答時間
キャパシティ	中間指標：CPU、メモリ、ディスク容量

後述する「目標設定」が重要になる。パフォーマンス目標として、どの程度の水準を目指すのか。 同じく後述する「定期的な振り返り」も重要だ。キャパシティ利用の推移を把握して、問題が起きる前にストレージを追加できると安心だ。

オペレーションのレベルを設計する

対応速度のレベル分け

サービス品質が脅かされた際のオペレーションは、以下のようにレベル分けできる。

レベル	概要	詳細
1	即時対応	夜中や休日であってもベストエフォートで対応する。
2	優先対応	営業日・営業時間内に対応。その間は機能追加の開発をストップする。
3	通常対応	開発要望リストに起票して、優先順位を判断する。次以降のタイムボックスに申し送る。

サービスレベルと組み合わせて考える。 どのレベルの問題だったら、どのレベルの対応速度なのか。

3つのフェーズ：調査→暫定対応→恒久対応

トラブル発生時、「調査」と「課題解決」で要求されるスピードは異なる。 アラートメッセージだけでは何が起きているのか分からない。そんな状況だと、サービスレベルを判定しようがない。 最悪の場合を考えて、まずは即時で事象の解明に当たる。そして問題が明らかになった段階で、再度レベルを判定する。

「課題解決」は、「暫定的な解決」と「恒久的な解決」に分けることができる。 ITILではインシデント管理と問題管理と呼び、これらは時にトレードオフの関係になる。 調査するためには現状を残した方が良いが、現状を残していてはユーザーに迷惑が掛かる、といった具合だ。

原則的にはインシデント対応を優先するのが望ましいとされている。 カスタマーケアの担当者は、利用者の不満を解消することに注力しなければいけない。 WebAPIサーバが落ちてスマホアプリが使えなくなったら、迷惑を掛けてしまったことを謝った上で、WEBサイトの利用を案内する。 その間にシステム担当はサーバ復旧に全力を尽くす。サーバが落ちた真因追求と予防策を考えるのは、落ち着いた後だ。

※大量・同時に問題が発生したときは、サービスレベルをもとに対応の優先順位を決めることになる。 Flickerの例を再掲すると、写真投稿と写真閲覧が両方できなくなったら、まずは写真を閲覧できるようにするのだ。

※恒久対応については、機能追加と同じようにプロダクトバックログ（あるいは変更要求一覧）で管理するのが望ましい。 プロダクトオーナーはサービスレベル目標をもとに、他案件との優先順位を決めることになる。

ベストエフォート

ベストエフォートへの過剰な期待

金曜の夜中にサーバが落ちたまま、月曜の朝までアクセスできなかったとしたら「ありえない」と思うだろう。 ベストエフォートで対応することになる。

ただし、あくまでもベストエフォートは、努力に過ぎない。約束ではない。 月曜の朝までアクセスできない状態が普通だ。そこに努力を上乗せするのだ。 深夜・休日の対応が続くと、そのオペレーションレベルが当たり前になり、チームは疲弊し、いずれ瓦解する。

試算すると、24時間365日で対応できるシフトを組むには、毎月1500万円ほど追加費用が発生することになる。

• 前提1:アプリ（iOS・Android・WEB）、インフラ（OS・MW）、ディレクションごとに各担当がいること。
• 前提2:トラック係数を保つために＆連続勤務にならないように各担当それぞれ3人以上であること。
• 前提3:1人あたり人件費は月100万円。平日昼間勤務より合計稼働時間は減るが、夜間休日シフトで時間当たり金額は割高になる。

仮に全部のシステムモジュールを扱えるエンジニアを集めたとしても、雇用人数は減るが1人当たり単価は上がるだろう。 どのみち上記を満たす人材を探すのは困難だ。障害対応のためだけのシフト勤務というのは、身体的にも精神的にも好ましくない。

言いたかったのは「稼働率100%に近づけるためには、それくらいのコストが掛かる」ということ。

明示的に人件費として負担するのか。ベストエフォートの名の下で労働者に負担を移転するのか。 本来はコストとして積まれるべきものだ。 医療従事者には、宿直制度があり、オンコール体制を巡って何度も裁判が起きている。それと同じ。

ベストエフォートへの期待を満たす

とはいえ、月曜の夜中にサーバが落ちたまま、月曜の朝までアクセスできなかったとしたら、ステークホルダーの大多数は「ありえない」と思うだろう。 少なくとも、顧客はそう思うはずだ。顧客志向な従業員もそう思うはずだ。

いかにダメージを最小化するか。以下のような方針が考えられる。

1. シフト制を導入してトラブルに対応する。宿直とまではいかなくても、オンコール体制にして、待機時間手当を支払う形でコストを積む。
2. 人材や働き方の多様性を確保する。従業員全員が世界中でリモートワークをしていれば、誰かが夜に眠っている最中でも、地球の裏側の誰かが昼間にトラブル対応できる。

これらは理想の話だ。将来的にはそうありたい。ただ、すぐに理想の運用を開始するのは難しい。 大多数の組織において、結局はシステム担当者のガッツに委ねられることになるだろう。

確実にできることがあるとすれば予防活動だ。 対処のコストが大きい＝予防が大事、という共通認識を醸成したい。 予防活動を仕組み化することはできる。予防の取り組みについては後述する。

影響範囲

アクセスの多い時間帯と少ない時間帯

夜間・休日の対応はベストエフォートであって約束ではないと述べた。

では夜間や休日にアクセスが集中するようなサービスのSLA・OLAはどうなるだろうか。 相対的には平日の昼間よりも重要なはずだ。 同じように、テレビCMを打ち始めたサービスであれば、CMの放送時間帯にアクセスできることが重要となる。

特定時間帯にオペレーションのレベルが高くなる場合、シフト制の導入を本格的に検討せざるを得ない。 ベストエフォート対応は安定しない。サービス特性とビジネス価値を守るために、払うべきコストは支払うしかない。

一方で、深夜・休日のシフト出勤をトップダウンで決めるのは危険かもしれない。 「従業員第一主義」（サウスウェスト航空）という言葉がある。 まずは従業員が安心とゆとりを持って働けるような環境を作る。 するとメンバー1人1人が工夫してサービスの信頼性を高めるようになり、深夜や休日でもユーザーが快適に利用できるようになる。 結果として利益に繋がり、株主が喜ぶ。あくまでも起点は従業員となる。 生活リズムを崩すような仕組みを明示的に導入するのとは正反対のロジックだ。

誰に何を約束するのか。どんなコストを掛けて、どんな価値を守るのか。 ユーザーとサービスだけでなく、ステークホルダーや業務についても、守るべき品質を定義できると素晴らしい。

影響範囲の閾値を決める

時間帯の話は、大きな括りでは「影響範囲」と呼ぶことができる。 ユーザー全体の1%だけが影響を受ける時間帯と、70%以上が影響を受ける時間帯だと、サービスレベルは変わるだろう。 同じように、ユーザー全員がログインできない障害と、1人だけがログインできない障害だと、前者の方が重く捉えられる。

誤解がないように補足すると、1人がログインできない障害についても、軽視すべきではない。全力で対応すべきだ。 ただ、1人分のデータにパッチを当てたり、新アカウントを手動で用意する、といった回避策を実施しやすい。 サポートスタッフの1人が、その1人のユーザーにつきっきりで対応することもできる。 10,000人がログインできない場合に比べると代替案や選択肢は多い。サービスレベルは相対的に低くなる。

影響範囲を考慮すると「全アクティブユーザー数の5%を超えるかどうかでレベルを上下させる」といったOLA設計ができる。 例えば、1人がログインできない場合（重要機能） = 全員のアクセスカウンターが誤表示する場合（おまけ機能） で同じくらいのレベルになるだろう。

例示に違和感があるようなら、以下のようなレベル設定はどうだろうか。

レベル	要約	内容
1	超ヤバい	全員がログインできないときのレベル
2	結構ヤバい	1人がログインできないときのレベル
3	少しヤバい	全員がおまけ機能を使えないときのレベル
4	まぁまぁ	1人がおまけ機能を使えないときのレベル

このSLA設計をするチームは、重要機能の軸がベースにあり、そこに影響範囲の軸を加えて判断していることになる。 それも1つの決め方だ。正解は1つではない。大事なのはレベル感について関係者が同じ認識を持つことだ。

サポート対象：OS・端末・ブラウザ・アプリバージョン

影響範囲の延長上にあるのが、サポート環境の話だ。 どのOS・端末・ブラウザ・アプリバージョンまでサポートするかを決める必要がある。

サポートの具体的なレベルとしては、3つに分けることができる。

レベル	顧客対応	テスト	内容
1	しない	しない	「このブラウザで閲覧できないのですが」と問い合わせが来たら、別のブラウザでの利用を案内する。
2	する	しない	マイナーなブラウザの細かい挙動まではテストせず、「画面が崩れます」と問い合わせを受けたら直す。
3	する	する	常にテストまで実施する。

「該当ブラウザを利用するUU数 / 全体のアクティブUU数」といった形でシェア率を測定する。 5%以上のシェアであれば対応する、10%以上のシェアであればテストする、といった設定ができる。

重要機能かつサポート対象であれば、品質を担保し続けることになる。 リリースごとに手動で回帰テストを実施するのも辛いので、E2Eテストを自動化する話に繋がる。

SLA：運用のプラクティス

設計したSLAをいかに運用するか。

各項目について目標を設定する

機能観点

機能観点のサービスレベルは以下のような目標設定ができる。

レベル	内容	目標値の例
1	セキュリティや法律を守れているか	ベストエフォート。そのサービスの歴史上で障害0件を目指す。
2	相対的に重要な機能が使える状態になっているか	重要機能が使えなくなる障害は月に1件以内に抑える。
3	相対的に重要でない機能が使える状態になっているか	月に10件まで許容する。

相対的に重要ではない機能は、品質目標を定めないという選択肢もありうる。 小さなバグで問い合わせが多発すれば（Dev/Opsが一体となっている前提のもとで）機能追加の開発にも影響が出る。 ベロシティが不安定になったり、リードタイムが伸びるといった形で可視化されるはずだ。

非機能観点

非機能観点のサービスレベルは以下のような目標設定ができる。

信頼性

観点	内容	目標値の例・補足
サーバサイド	サイト停止の頻度・時間	月に2回まで。1回あたり3時間以内。
クライアントサイド	モバイルアプリやフロント画面でのクラッシュ	UU数やPVに対するクラッシュが3%以下。他アプリがメモリを食う、といったクライアント都合も影響するので、0件にはならない。
プラットフォーãƒ	規約違反でAppStoreからBANされないか etc…	ベストエフォート。そのサービスの歴史上で0件を目指す。

性能

観点	内容	目標値の例・補足
レスポンス状況	最終指標：応答時間	ピークタイムの中央値が0.5秒以下。危機を検知するために、負荷が大きい時間を見る。コネクションエラーなどで外れ値が出るので、中央値を見る。
キャパシティ	中間指標：CPU、メモリ、ディスク容量	40%以下。跳ね具合を確認したいので、ピークタイムの最大値を見る。

目標と実績

目標を満たせなかったときはどうするか。

例えば、GoogleのSREではErrorBudgetの概念が出てくる。 ある程度までは障害を許容するが、閾値を超えるようであれば、機能追加の開発を停止せよ、という内容だ。 実際にはまだ開発停止になったことはないようだが、目標を意識することで動き方が変わったらしい。

定期的に目標と実績を比べながら、振り返りを実施していくのが良いだろう。

月次で振り返りを実施する

会のアジェンダ

アジェンダ1：結果の振り返り

その月に発生した障害や対応が、どのサービスレベル・オペレーションレベルに該当するのかを記録していく。 その上で、各目標値を満たせたかのか確認する。これを毎月繰り返すことで関係者の目線が徐々に揃うようになる。

アジェンダ2：原因・対策の振り返り

その月に発生した障害や対応について、問題があったならば真因分析と改善施策を打つ。 例えば、証明書の期限が切れてブラウザからアクセスできない障害が起きたとしよう。 同じようなミスがないように、証明書の期限切れをリマインドする仕組みを作るのがTryになる。

アジェンダ3：傾向・予防の振り返り

その月の実績を見て、これから問題が起きそうだったら事前に手を打つ。 例えば、徐々にパフォーマンスが劣化し始めているとしよう。 クエリや設定をチューニングしたり、サーバを増築するのがTryになる。

アジェンダ4：SLA自体の見直し

ソースコードをリファクタリングするように、SLAの設計自体を少しずつ進化させる。

例1：その時のシェア率を見てサポートブラウザを更新する。 「IEが減ってChromeが増えた！」のであれば「Chromeだけテストしよう！」という判断に繋がる。

例2：シェアの5%以上だったら問い合わせに対応するルールだった。 だけど「潜在的なユーザーを取り逃がしすぎているように感じる」とカスタマーサポートチーム。 「基準値を3％に下げて、この端末のトラブル対応にコストを割けないだろうか」という提案に繋がる。

振り返りの位置付け

定期的な会話を通して、品質に対するチームの共通認識を得ることが目的だ。

ロールによって認識が違うなら、その違いをぶつけ合って、最適なサービスレベルに軌道修正しよう。 機械的に振り返り会を実施するだけでは意味がない。対話が生まれて初めて意味がある。

ちなみにトラブル対応と振り返りは別なので注意したい。 キャパシティが急激に悪化するようだったら、すぐさまプロセスを再起動するといった対応が必要だ。 わざわざ振り返り会を待つ必要はない。

プロアクティブに予防する

トラブル対応や振り返りといった受け身の動きだけでなく、いかに予防するかも大切だ。

技術的負債を予防する仕組み作り

以下のエントリーにまとめた。

yuzutas0.hatenablog.com

SREの例：稼働の50%以上を信頼性向上のために使う

予防策の1つは、GoogleのSREを参考にして、稼働ポートフォリオを組む方法だ。 運用担当は業務時間の50%以上を割いてシステム品質を向上させる。 トラブル対応や定常作業に使う時間 < 予防活動に使う時間 を目指す。

リアクティブな活動の時間（＝問題が入ってくる量）よりも、 プロアクティブな活動の時間（＝問題が出て行く量）が多ければ、品質は継続的に向上できる。 逆だと品質は悪化し続け、地雷を踏む日が来るのを待つだけの辛い運用になる。

理想はDev/Opsの両方を1つのチームが担うこと

開発と運用を同じ人が担当する。この体制は品質担保のためのベストプラクティスと言える。

課題を可視化する＝品質を担保する

運用観点を嫌でも意識できるようになるからだ。 企画・開発の際に運用観点を考慮するようになり、品質を維持しやすくなる。

また、計画外の運用作業が増えると、その分だけ機能追加に割けるパワーが減る。 結果として全体のボトルネックが可視化されるようになる。 可視化されることで、課題の解消・予防アクションに自然と繋がるようになる。

ウェブサイトの開発と運用は、別々のチームに分かれている。

この配置は一般的なのかもしれない。しかし、サイトの安定性を確保し、新しい機能を届けるには、おそらく最悪の方法である。

成功したインターネット企業（Amazon・Facebook・Google・Flickerなど）の多くは、チームを分割せずに違ったやり方を試みている。

チームを分ける狙いは、開発の邪魔になるものを排除し、機能の実装が遅れないようにするためだが、ここから24時間稼働し続けるコードが生まれることはない。

日曜の午前3時にポケベルを鳴らされるくらいなら、システムを壊れにくくしたり、もし壊れてもツールで自動的に回復できるようにしたりするはずだ。

（『ウェブオペレーション - サイト運用管理の実践テクニック』から引用）

開発・運用を一体化する → 課題が可視化される → 品質が担保される → 開発デリバリーに好ましい影響を与える、ということだ。

品質を担保する＝デリバリーを加速する

よく言われる「QCDはトレードオフの関係」という考え方は無視しよう。

品質が悪ければ、スピードは落ちる。調査・改修・テストに余計な時間が掛かるからだ。 トレードオフが発生するのは、作るだけ作って1回リリースした後は放り投げるプロジェクトの場合だけだ。

継続的なデリバリーを実施する場合、クオリティとアジリティは同時に改善される。² 品質を下げてスピードを優先するという選択肢は存在しない。

3つの変数とは速度、品質、価格である。

品質を下げても、作業がなくなるわけではない。自分の責任だと分からないように、作業を後回しにしているだけだ。

多くの欠陥のコストは、それを防止するコストを上回る。

欠陥を発見するのが早ければ、それだけ修正するコストは安くなるのである。たとえば、欠陥の発見が開発の10年後だとしたら、（中略）解明するために、膨大な歴史や文脈を再構築する必要がある。同じ欠陥であっても、作成直後に補足すれば、その修正コストは最小限になる。

（『エクストリームプログラミング』から引用）

障害対応はマッチポンプ

OLAの項目でベストエフォートについて述べた。夜間・休日の対応についてだ。

貴重な時間を費やしてトラブルを解決したメンバーには、好意を抱きやすくなる（シグナリング効果）。 しかし、予防の観点からすると、夜間・休日に対応した個人を評価してはいけない。アンチパターンだ。³

火を消して最高の報酬を得るよい機会だと考えるようではいけないのだ。そうなると、プロジェクトはほぼ間違いなく危機駆動になる。

もし組織がプロダクトを作り出すことを仕事にしているなら、プロダクトのデリバリーをサポートしたことに対して報酬を出すべきだ。

（『組織パターン』から引用）

DevとOpsが一体化されているチームの場合、自分でバグを作って自分でバグを直すことになる。 マッチで起こした火をポンプで火を消すようなものだ。

深夜・休日の対応はネガティブなものだ。担当者は評価もされずに、嫌な思いをする。 そんな思いをしたくないから、品質を前工程で作り込む。 品質の安定に伴って、デリバリーが安定・加速する。

結果としてプロダクトの価値をムダ・ムラ・ムリなく顧客に届けられるようになる。

サービス保守運用の枠を超えて

ユーザーへの約束

利用規約やプライバシーポリシーを考える

法務担当以外は関心を持ちにくいかもしれないが、大切なドキュメントだ。 この文書を通してサービス提供者と利用者は約束を交わしている。

当然ながらサービスレベルにも連動する。約款の内容が守られていないと法令違反、最悪の場合は営業停止となる。 そうでなくとも社会的な信頼を損なう。同意なしに個人情報を販売するようなサイトを使いたいだろうか。

ユーザーに約束している機能は何か

同様に、サービス内で約束している機能はサービスレベルが高くなる。 お金を払ったのに漫画アプリで漫画が読めなかったら大問題だ。

どの画面でユーザーにどんな約束をしているのか、チーム全員が把握できるように一覧表をまとめよう。 開発・運用の担当者が青ざめるような約束があるかもしれない。

「24時間365日いつでもどこでもオンラインで映画を視聴できます！」というトップ画面があったらどうか。 稼働率100%だ。トラブルが起きたときには、24時間365日いつでもどこでも対応しなければいけない！

※かといって「週5日9:00-17:00でのみ映画を視聴できます！」というサイトに登録するだろうか。 ユーザーとしては難しいところだ。できれば終業後や休日にお酒を飲みながら映画を見たい。 そのため、障害発生時には割引クーポンを配布するといった工夫が必要になる。 何を約束し、どのレベルで約束を破ったら、どのレベルの補償をするか、SLA設計が必要になる。

約束と実態を合わせる

守ることができない内容を約束していたら、利用者も経営者も技術者も、全員が不幸になる。

過剰すぎない表現に変える工夫が必要だ。 ユーザーが気付かないような小さな注意書きを添えるだけではダメだ。 問い合わせやトラブルの削減には繋がりにくい。

もしきは、ユーザーへの約束に合わせて、サービスレベルの実態を上げる。 そのためのコストはきちんと支払うのが筋だろう。 サーバの増築だったり、機能追加を止めてバグシューティングに専念することだったり。

財務計画との連動

サービスレベルを財務観点で可視化する

財務計画とサービスレベルが連動すると、お金の流れを通して事業運営の実態を把握できるようになる。

ここで言いたいのは「経営をしよう」ということだ。 サービス運営のリスクは財務諸表（もしくは財務に連なるKPIツリー）に織り込もう。

稼働率100%・障害0件を前提にした計画は破綻する

営業活動を例に上げよう。訪問数と受注数は一致しない。 20社訪問して1社成約（5%）といった仮説を置くことになる。 そこから売上予想を立てていく。システムも同じだ。

稼働が100%ではないことを前提にして、（文字通り）Error BudgetをP/Lに反映するのが良いだろう。 「障害は月1件まで」のサービスレベルで目標設定するなら、障害が月1件起きる想定でコストを積もう。 少なくともKPIツリーのどこかで計測できるようにはしよう。

ネガティブサプライズを織り込む

システムは生き物のようなものだ。 障害は必ず起きる。障害が起きれば、利益を毀損する。

サイトを訪問するはずだった、広告を見るはずだった、課金をするはずだったユーザーを失うことになるかもしれない。 にも関わらず計測指標に組み込まれていないと、ある日突然、計画外のコストが乗ることになる。

ネガティブサプライズが起きると分かっているのに、財務計画に反映されていないのでは、健全なサービス経営はできない。

おわりに

サービスレベルを考えるということは「コストを払ってでも守るべき品質は何か」を考えるということです。

サービスにとって何が大切なのかを考えることです。 カスタマーに対して何を約束できるのかを考えることです。 ビジネスに対して何を約束できるのかを考えることです。

守れない約束のために疲弊するのはやめましょう。 守るべき約束を全力で守れるようになりましょう。

騙し騙しの企画や開発を続けていると、ある日突然、下らないことで足元を掬われることになるでしょう。 あらゆるチームがその罠に陥ってしまう可能性を持っています。100点のサービスは存在しないからです。

それでも健全な運用を目指し続けた先に、安定的な価値の提供があるのだと思っています。

強い会社はこうして作られる! ITIL実践の鉄則

---

1. ちょっぴり盛ったけど、気にしないでほしい。↩

2. ちなみにコストは人件費・サーバ費用が大きくなりやすいが、安易に増減できる変数とは言えない。↩

3. 既にレガシーなシステムで、10年前に埋められた地雷が爆発したときには、英雄を褒め称えたい。↩