SRE がOsushi 事件を見てサイト信頼性について考えたこと

一昨日、Osushi というサービスがリリースされ、即クローズされた。事の顛末は、以下のtogetter に詳しい。

https://togetter.com/li/1195320

私はSRE（Site Reliability Engineer ） という仕事をしている。知らない方のためにかんたんに書くと、SRE はサーバ・ネットワークの構築や運用、さらには構築したシステムのパフォーマンス・信頼性・スケーラビリティを高める仕事を行う。（実際は、この定義よりさらに幅広い業務を行っているSRE が一般的であると思う。SRE のみなさんこんにちは。）

さて、本記事では、上述した「サイトの信頼性」は、どこからどこまでを指し、また、誰がどうやって守るべきか？という全体の枠組みについて考えたい。

SRE と信頼性

一般論として、SRE が守るべき信頼性は、RASIS , 中でも測定可能なRAS について指す場合が大半である。ということを書いた文章に私は出会ったことはないが、おそらくSRE の方々には、概ね合意いただけるのではないだろうか。

RASIS とは、以下の言葉の頭文字を取った用語だ。

* Reliability (信頼性)
障害、不具合の発生しにくさ

* Availability (可用性)
稼働率の高さ

* Serviceability (保守性)
障害復旧のしやすさ

* Integrity (保全性・完全性)
データの破壊や不整合のおきにくさ

* Security (機密性)
システム内情報の機密保持性

Osushi 事件とサイト信頼性

今回のOsushi 事件だが、上述した信頼性（RASIS ）を損なっていることが分かる。本記事冒頭で引用したtogetter に報告されている事象を一部記載する。
（私自身は、Osushi を利用しないままOsushi がクローズしてしまったため、Twitter の人々の報告が正しい前提で記事を書き進める。）

* 登録時のユーザーID のvalidation が行われていない
* そのため、ユーザーID の重複がシステム的に許可されており、後から登録した人のアカウント情報で、先に登録した人のアカウント情報が上書きできてしまう
* クレジットカード情報が同意なしに勝手に保存されてしまう
* 1回しか決済していないはずが、重複で実行されてしまう（システム的に本当に重複決済されたかどうかは分からないが、少なくとも画面上はそのように表示されていた様子）

（SRE のお仕事に詳しい人にとっては、これらはDEV 側の責務では？と思われるかもしれないが、本記事の主旨の都合上、いったん触れないでおきたい。我慢して欲しい、すまん。そういう話なら、渋谷あたりの居酒屋でぜひ。SRE のみなさんご連絡お待ちしてます。）

また、先ほどのtogetter には引用されていないが、こちらもシステムの信頼性を損なっている状態だ。

これらの信頼性は、SRE も含めたソフトウェア開発者が守るべきである。今回のOsushi 事件は、Osushi がサイト信頼性を守れなかったため発生したと言えるだろう。

サービス運営の信頼性は誰が守るのか？

さて、今回私が考えたかった信頼性の全体観は、実はここではない。今回、考えたかった信頼性は、以下のような信頼性についてだ。

* 利用規約には、「ユーザは、当社が定める方法により、いつでも「Osushi」の利用を終了し、Osushiから退会することができます」と書いてあるのに退会リンクが存在しない
* そもそもビジネスとして法律的にアウトでは？という懸念（この懸念については、こちらの記事に詳しく書かれている。）

本記事の主旨に合わせてこれらの問題について解釈すると、「システムの信頼性も守られていなかったが、サービス運営における信頼性も守られていなかったのでは？」ということである。

つまり、私が本記事でこれまで述べた、SRE やソフトウェア開発者が守るべき信頼性以外にも守るべき信頼性があるということだ。いくらサイト信頼性がしっかりしていても、サービス運営における信頼性が低ければ、利用者に不信感を与えてしまう。

これまで書いたようなことを昨日から考えていて、思い出した話がある。OSI参照モデルの第0層の話だ。

OSI参照モデル第0層と、サイト信頼性における第0層

OSI参照モデルとは、通信プロトコルの構造モデルのことであり、以下7つの層で構成される。

第7層 アプリケーション層 (application layer)
第6層 プレゼンテーション層 (presentation layer)
第5層 セッション層 (session layer)
第4層 トランスポート層 (transport layer)
第3層 ネットワーク層 (network layer)
第2層 データリンク層 (data link layer)
第1層 物理層 (physical layer)

ただし、現実の問題を解決するにあたっては、このモデルにおさまらない範疇の話があると言われており、その1つがOSI参照モデル第0層である。

上述した第1層 物理層は、物理メディアを直接制御する部分のこと（リピータハブなどの機器が代表的）であるが、それに対し、第0層は、ネットワーク機器を収容するラックや建物のことだと言われている。

さらに、通信系の会社で働く人と話す時にこの話題を出すと、第7層より上の層について言及がされ…（おっと、誰か来たようだ。）

さて、OSI参照モデル第0層を今回のOsushi 事件に当てはめて考えてみると、サイト信頼性の考え方においても、OSI参照モデル第0層のような話がひそんでいるのではないか？という思いに行き着く。そして、サイト信頼性における第0層は、前述したようなサービス運営に関する信頼性ではないだろうか。例えば以下だ。

* ビジネスとして法律的に問題がないか
* 利用規約などユーザーとの約束事をきちんと守られているか

さらに、OSI参照モデルの第7層より上に対応するであろう部分には、以下のような信頼性がある。

* サイト上の文言表記の正しさ
* 使用している画像の著作権が守られているか
* ユーザーが理不尽と感じない納得できるUX
* サービスとして信頼感あるブランディング

いかがだろうか。

これらは、必ずしもSRE やソフトウェア開発者の守備範囲である必要性は高くないが、会社やチームとして誰かが守らなければならない信頼性である。RASIS を狭義の信頼性とするならば、広義の信頼性と言っても差し支えないだろう。

本記事を読んだ皆さんが自社における信頼性を考えるきっかけになれば幸いである。

まとめ

最後にいろいろ引っ掻き回すようで申し訳ないが、私は今回の事件が終わり、Osushi の人たちの信頼性は最終的には守られたと思っている。

なぜなら、彼らは自分たちの非を認め、せっかくつくったサービスを即日クローズし、せっかく集まったユーザー情報をすべて削除し、さらに、とてつもなくめんどくさそうな全額返金手続きを即断したからである。

Osushi に限らず、新しいサービスを生み出すのは結局のところ人でしかない。そして、サービス運営するリーダーたちに対する信頼性が、最も協力な信頼性であることを私は過去の投資経験で実感している。

Osushi のみなさんの再起を心の底から応援しています。