最近の仕事は「運用支援」をやっています。
「運用支援」というのは、システムはあるけれど、運用できていない or 上手くいっていないチームに対して、上手く運用できるように支援する仕事である。
支援する・・・といっても、私自身が運用のプロフェッショナルか？と聞かれれば、「No」と答える。
そもそも、私が過去にいた会社は「Web制作会社」であり、受託開発なので、Webサイトやシステムを構築したら納品して完了なのです。
そのため、運用は完全に・・・とまでは言わないけど、ほぼ対象外。
なので、私自身も「運用」に対して知識を深めつつ、支援というお仕事をしているわけです。
こんな状態でお仕事できるのかな？？なんて、思っていたのですが、やってみると意外とできるもので、不思議に感じています。人は経験が多いと色々と誤魔化すのも上手になるんですかね（笑）
さて、本題に入りましょう。
みなさん「運用ができている or 上手くいっている」とはどういう状態かご存知でしょうか？
なんとなく、必要な手順書が揃っている。とか、運用専門のチームがいる。とか、問い合わせフォームがある。とか、そんなイメージを持たれている方が多いのではないかと思います。私自身もそうでした。
まず、大前提として「運用ができている or 上手くいっている」というには、「〇〇ができているからOK」といえるものではありません。
システムに対して、色々な視点から見た上で「〇〇ができているからOK」となります。
今回は、その視点の一つである「信頼性」から見た「運用ができている or 上手くいっている」状態を書いていきたいと思います。
「信頼性」とはなんでしょうか？
私はこれが結構ややこしくて、苦手なのですが、私はシステムに対する「信頼性」という解釈をしています。
（お客さんが）「システムを信頼している」「システムを頼りにしている」状態という解釈です。
ちなみに「信頼性」は英語で「リライアビリティ」と言います。
「リライアビリティ」といったら、「サイトリライアビリティエンジニアリング（SRE）」じゃないですか？？
SREのお仕事は、システムのダウンタイムを減らして、サービスの可用性を高めたり、開発や運用の担当者間の連携を強化したり、改善や新機能の追加を継続的に行うチームのことです。
なんとなく、SREチームも（お客さんに対して）「システムを信頼している」「システムを頼りにしている」状態にもっていくことが仕事という感じがしませんか？？
話を戻します。
「信頼性」から見た「運用ができている or 上手くいっている」状態とは？
つまり、（お客さんが）「システムを信頼している」「システムを頼りにしている」状態だからこそ、「運用ができている or 上手くいっている」と言えるということです。
では、（お客さんが）「システムを信頼している」「システムを頼りにしている」状態はどのようにして、わかるのでしょうか？
ここで出てくる単語が「SLO」と「SLI」です。
- SLO（Service Level Objective）
サービスレベル目標とも言います。（お客さんが）「システムを信頼している」「システムを頼りにしている」状態になるような箇所に、目標を設定して、サービス品質の維持、改善を行います。
- SLI（Service Level Indicator）
サービスレベル指標とも言います。SLOに対して数値化した指標です。SLOが達成しているのかを判定する値になります。
私も「SLO」と「SLI」という単語をちゃんと理解し始めたのは、この仕事をはじめてからです。
ちなみに、良く耳にする単語は「SLA」ですね。
- SLA（Service Level Agreement）
サービスレベルの（お客さんとの）合意ですね。
これは、提供しているサービスが一定レベルを下回った場合に返金に応じるという約束事が書いてあることが多いです。
「SLA」は、お客さんとの合意のため、お客さんへの報告義務がありますが、「SLO」と「SLI」はお客さんへの報告義務がないというのも大きな違いです。
「SLO」と「SLI」の話に戻ります。
「SLO」の説明で、（お客さんが）「システムを信頼している」「システムを頼りにしている」状態になるような箇所に、目標を設定する。とありました。
どこに設定するのでしょうか？
とりあえず「えいやっ」はダメです。
レスポンス速度を計測する人も多いのですが、toC向けで重い処理やページで無い限り計測する必要は無いと私は思っています。toB向けであれば、なおさらです。
ここでも新しい単語が出てきます。「ユーザージャーニー」です。
お客さんがシステムを操作する一連の流れや体験を表したもの。トランザクションのようなものだと言えば伝わるでしょうか？
お客さんがシステムを操作する一連の流れ、つまり、ワークフローがあると思います。
そのワークフローをすべて可視化して、最も重複する場所を特定し、そこに対して「SLO」を設定します。
ワークフローは、画面遷移図からわかることもあれば、システム構成図からわかることもあるかと思います。
他にも、インセプションデッキのトレードオフスライダーで最も優先してきた機能を目標に設定するのも良いかもしれません。
そうすれば、システムのどこが重要な機能であり、お客さんがそのシステムに対して信頼する場所なのかが、特定できるのではないでしょうか？
「SLO」の設定ができてしまえば、あとは、その「SLO」を計測するために必要となる指標。「SLI」を決めていくだけです。「SLI」を決めた箇所には監視をいれましょう！
ここで、注意したい点としては、「SLO」を多く設定しすぎないことです。
理由は以下の通りです。
- データから意思決定する難しさが増える。
- サービスの信頼性の状態を他の人に報告するのがより困難になる（「信頼性をわかいりやすく伝える」というメリットがなくなる）
- 計測が多すぎると統計上の問題がでる。（多重検定問題）同じシステムで異なる計測をしてしまう。
そのため、3 〜 5個程度にすると良いと言われています。
「SLO」と「SLI」について、理解頂けたでしょうか？
「SLI」は、計測が必要なので監視が必要になり、「SLO」を超える様であれば、アラートによる通知が必要になります。
ここからさらに考えなければならないのが、「SLI」以外の監視についてです。
システムが構築したばかりであれば、「SLI」以外でも多く監視し、必要であればアラートを鳴らす必要があると思います。
しかし、システムを構築し終えて安定期に入った時は、はたしてそんなに多くのアラートが必要なのでしょうか？
もう「SLI」だけ監視していれば良いのか？
「運用支援」を始めたばかりの私にはわからない課題、まだまだ「信頼性」という視点から見た運用は奥が深い。。。
