記載した背景

初投稿です。

子供の頃から20年以上auユーザですが、システムのサービス提供をする業務に携わっている身として、
障害対応をされている方を思うと辛い部分もありました。
独学で学んだ「サービスマネジメント」についてと、auの通信障害を例に計算練習と考え方をメモします。
なお、自分の理解度をあげるため、個人的解釈を含んで記載しております（「●個人的な解釈」や「→」で表現して記載）。
用語ごとの直下の１文は基本的に参考文献からの引用となります。

品質保証とサービスマネジメントについて

理解をするために必要そうな用語をメモします。

品質（quality）とは

品質とは、「コンポーネント、システム、プロセスが、特定の要件、ユーザー、顧客のニーズ、期待を満たす度合い」をさします。

●個人的な解釈
「最近、システム品質安定しているね」は、
「最近、システムの不具合もなく、顧客からのニーズにマッチしているので、品質安定してサービス提供できているね」
と言い換えることができるというもとになります。

品質保証（quality assurance）とは

品質マネジメントの一部。「品質要件を満たしていることの確信度合い」に焦点を当てている状態をさします。品質が当初設定したレベルに確実に到達するよう、適切なプロセスを遵守するための活動です。

●個人的な解釈
「きちんと要件定義したとおり動くよね？」
「リリース後問題なく、不具合発生せずに動いているよね？」
「止まってもすぐに復旧できるフローになっているよね？」
というものを、きちんと準備やルール作りできている状態かが大事ということと解釈しました。

サービスマネジメントとは

システムを安定的かつ効率的に運用するための取り組み・仕組みを指します。

完璧を目指すと、かえって費用や時間がかかるため「目標保証型」と「努力目標型」に区分けし、
どこまで許容するか等、求めるレベルを事前に決めておきます。
→「●時間以上継続して稼働できることを目標とします」や、
　　「事前告知を伴う定期メンテナンスは、この条件から除きます」など

SLA（Service Level Agreement）とは

サービスの提供者と利用者（顧客）との間で結ばれる合意文書です。

　→利用規約や約款に記載があります。

稼働率って？

システムが運用開始してから現在までの間、正常に稼働していた時間の割合です。

稼働率を求めるためには、MTBF（稼働時間）とMTTR（平均修理期間）の値を使い計算します。

●MTBF（稼働時間）

      MTBF　=　稼働時間の合計　÷　故障の回数

→「MTBF」は長いほうがいいということとなります。

●MTTR（平均修理期間）

      MTTR = 故障時間の合計 ÷ 故障の回数

→「MTTR」は短いほうがいいということになります。

●稼働率

      １台の稼働率 = {MTBF ÷ （MTBF ＋ MTTR）} ×100(％)

→100％に近いほうが「安定した稼働率」と言えます。

auの通信障害について

auの稼働率を計算してみる

今回通信障害が発生していたのが、 2022年7月2日AM1:35 から 2022年7月4日15:00 までの1回とし、７月の稼働率を計算してみます。

# ７月は31日までありますので
31day × 24hours × 60min = 44,640 min

# MTBF
44,640min ÷ 1回 = 44,640 

#MTTR 2022年7月2日AM1:35 から 2022年7月4日15:00は、３,６８5minですので
MTTR = 3,685 ÷ 1回 = 3,685

# 稼働率
7月7日0:00現在における７月の稼働率 = {44,640 ÷ (44,640 + 3,685)} × 100 = 92.37%

このまま何事も起きなければ、92.37%となります。

今回のSLAと稼働率

auの通信サービス契約約款をみると、以下の記載がありました。（抜粋＆個人的解釈）

「通信サービスを全く利用することができない状態が24時間以上その状態が継続したとき」
 
「認知した時刻以後の利用できなかった時間24時間ごとに日数を計算し、
その日数に対応するその通信サービスに係る基本使用料等」

サービスマネジメントとしては「目標保証型」で、
SLAは、「24時間以上継続したら日数換算で基本使用料を補填するよ」という内容と受け取れます。
今回の場合は、48時間は通信障害が発生していたので、2日分は対象となりうる可能性があるということになります。
「時間で換算ではない」ということも受け取れます。

感想

作業者の方、フロントに立たれている方、暑い中おつかれさまです。

サービス提供は、利用者がいてこそ成り立つものではありますが、
どんなに大変でも、サービスを提供する際にはサービスマネジメントとSLAの記載をきちんと規約等に載せておくことで、提供している側の身を守ることにもつながるということを学びました。

今回、障害が起きてしまったことは残念ですが、この「事象」から得ることができたものはいろいろな人にとってそれぞれあると思いましたので、私も次に活かせるようにしたいと思います。

参考文献

ソフトウェアテスト教科書 JSTQB Foundation第４版翔泳社

情報処理教科書出るとこだけ！　情報セキュリティマネジメント翔泳社
ａｕ（５Ｇ）通信サービス契約約款
 https://www.kddi.com/extlib/files/corporate/kddi/kokai/keiyaku_yakkan/pdf/honbun_kddi_5G.pdf

au 障害情報
 https://news.kddi.com/important/news/important_202207051022.html