見出し画像

「止まらないシステム」という幻想

gami | エンジニア

2020年11月30日、東証の宮原社長がシステム障害の責任を取って辞任する意向を発表しました。この辞任は、「止まらないシステム」という幻想を信じる人を増やしそうで、個人的にはとても残念でした。

Twitter上でも、同じような意見が目につきました。

（実際には、障害の原因はNASの故障だけではなく、マニュアルの不備と設定ミスで2号機への自動切替えが行われなかった点にあったことがJPXから発表されました。）

確かに今回の障害の原因を見ると、オペレーション上の問題が全く無かったとは言えないと思います。しかし、社長の引責辞任にまで至った背景にある本当の問題は、「不適切な合意形成」に関する問題に見えます。

このnoteでは、「止まらないシステム」というのは幻想であること、システム障害から建設的な学びを得るための方法などについて一緒に考えましょう。


「Never Stop」という不適切な合意

2015年に公開された富士通の記事を見ると、東証の株式売買システムarrowheadは「Never Stop」という合言葉の元で構築されてきたことがわかります。

新arrowheadが目指したのは、とにかく「止まらない（Never Stop）」こと。世界の取引システムは、処理スピードだけをひたすら競う時代から、安定性や信頼性を重視する傾向があります。新arrowheadは、安定性と信頼性を継承しつつ、利便性、処理能力の向上を図った、世界最高水準のシステムです。
（中略）
富士通は今後も、東京証券取引所様とともに、決して止まらない「Never Stop」を合言葉にした信頼性のシステムの開発を進めていきます。

文字通り、開発を担当した富士通と東証などステークホルダの間で、「絶対に止まらないシステムを作る」という合意形成があったことが伺えます。

しかし、一定以上の複雑なシステムにおいて「ずっと止まらない」というのは幻想です。現に東証arrowheadも今回障害を起こして丸一日取引ができなくなりました。他にも、たとえばみずほフィナンシャルグループは2002年と2011年に大規模なシステム障害を起こしています。様々なITサービスの裏側で使われ今や社会の基盤とも言えるクラウドインフラサービスであっても、定期的に障害が発生し使えなくなることがあります。直近の例では、AWSは2020年11月、GCPは2020年8月、Azureは2020年9月に大規模な障害を起こしており、その影響で一時的に使えなくなったシステムが世界中にありました。

近年、情報システムはますます複雑化しています。またシステムの開発や運用は、自動化されている部分ももちろんありますが、まだまだ人手が必要であり人為的なミスをゼロにすることはできません。

このような状況の中では、「止まらないシステムを作る」という合意を取ったこと自体が不適切であると思います。東証の例は極端かもしれませんが、世の中のシステム提供においては、「このシステムはたまに止まります」という合意を取った上で、障害から学びを得るための仕組みや文化を作っていくのが、最も建設的な態度といえそうです。

「SLA」で「このシステムはたまに止まります」という合意を得る

一方、「このシステムはたまに止まります」という合意をステークホルダーと得ることは、直感的には難しく感じます。そんなことを実施している会社はあるんでしょうか？

主にクラウドサービスの分野では、こうした「このシステムはたまに止まります」という合意を得るために「Service Level Agreement（SLA、サービス水準合意）」と呼ばれる文書を作って公開することがよくあります。

前述したAWSでは、提供する多くのサービスについてSLAを作成し、Webサイト上にPDFファイルで公開しています。たとえば、Amazon Computeと呼ばれるカテゴリのサービスについてのSLAでは、次のように「99.99%以上の月間稼働率」を約束しています。

一般サービスコミットメント
AWSは、各AWSリージョンの各対象サービスを、毎月の請求期間において99.99%以上の月間稼働率で利用可能にする商業上合理的な努力を行う（「サービスコミットメント」）。

つまり、1ヶ月を30日=43,200分とすると、その0.01%である4.32分/月まではシステムが止まる可能性がありますよ、という合意を取っていることになります。AWSのサービスを使うということは、必然的にこうしたSLAに合意をしたことになります。

また、この「99.99%以上の月間稼働率」が障害などによって守られなかった場合、利用者は「サービスクレジット」の形で利用料の返還を受けられることになっています。

対象サービスのいずれかがサービスコミットメントを満たさない場合、サービス利用者は以下に記載するサービスクレジットを受け取ることができる。

多くのクラウドサービス提供者は、同様のSLAを作成・公開し、顧客との合意に使っています。このように、SLAは「このシステムはたまに止まります」という前提に立ち、「どのくらい止まらないようにします」という数値目標を顧客と合意した上で、「それ以上止まったら返金します」と決めることでその数値目標に実効力を持たせているのです。闇雲に「Never Stop」を掲げるよりも、サービス提供者と利用者の双方にとってよっぽど建設的な仕組みです。

「エラーバジェット」と攻めのシステム開発

SLAによって利用者と「このシステムはたまに止まります」という合意を得ている状態は、機能開発が盛んなシステムにおいては特に重要になります。

たとえば99.99%以上の月間稼働率をSLAで合意していたとすると、0.01%分は障害を発生させてもいいことになります。この「まだ障害を発生させてもいい度合い」が数値化されていることで、その範囲内で攻めのシステム開発ができる、という考え方があります。

一般にシステムは、新しい機能を追加すればするほど、バグや障害が多くなります。新機能のリリース時には、ソースコードやサーバーの構成を変更する必要があります。こうしたシステムに対する変更によって想定外の事態が発生することが、多くのバグや障害の原因となります。もし「システムを止めてはいけない」という合意の元でシステムを開発するとなると、一度リリースしたら機能は全く増やさない、というのが最善手になります。しかし、実際には機能をどんどん追加していくことで、利用者にとって魅力的なサービスを提供することも事業上重要です。

そこで、実際にシステム障害を起こした度合いがまだSLAの範囲内であれば、アグレッシブに機能追加などの変更をシステムに加えていこう、という考え方や仕組みが生まれました。たとえばシステム運用の世界では、「エラーバジェット」というリスクコントロール手法があります。単に「障害を起こしてはいけない」という暗黙の前提を共有するのではなく、「障害を起こしてもいい度合い」を予算（バジェット）として数値で管理します。それによって「まだ今月は予算があるから、ちょっと攻めた機能リリースを入れちゃおう」といった予算に基づく開発上の意思決定を実現します。

ちなみに、機能を追加したい開発（Development、Dev）チームと、障害を減らしたい運用（Operations、Ops）チームは、前述した理由からしばしば対立します。この対立をなんとかしようぜというムーブメントは、「DevOps」と呼ばれています。「エラーバジェット」もまさに開発チームと運用チームとの間で合意を取りやすくするための仕組みであり、「DevOps」の文脈でよく紹介されます。

障害の後は、「ポストモーテム」を社内共有して失敗から学ぶ

では、実際に障害が発生した場合、どのようにその事実を扱えばいいでしょうか？

対外的には、「なるべく早く、正確な障害情報を公開する」ということが当然重要になります。たとえばAWSでは、各種サービスの状態が常にステータスページで公開されており、利用者が「障害かな？」と思ったときにすぐに確認できるようになっています。AWSに限らず、多くのクラウドサービス事業者はこうしたページを公開しています。（もちろん、全てをSLAで合意することはできないため、障害の影響範囲によっては特別な形で報告や謝罪をすることが事業上重要であるというケースはあります。）

また、富士通などのSIerが個別に構築しているシステムについては、障害発生時の個別連絡だけでなく、事後的に「障害報告書」の形で原因や影響範囲がまとめられます。

一方、こうした対外的な「障害報告」だけではなく、社内で失敗を学びに変えて再発を防ぐために記録を残そうという考え方や仕組みもあります。障害発生後に書かれる内部向けの報告書は、システム運用の世界で「ポストモーテム」と呼ばれます。元々は「死後の」とか「検死」という意味で、転じて「失敗の事後検討」という意味があるようです。（失敗を死に例えるのは大袈裟な気がしますけど。）

たとえばGoogleでは、定期的に社内の重要な「ポストモーテム」をみんなで共有する会が開かれているそうです。SLAによって一定の障害が許容されるといっても、なるべく障害を起こさず「エラーバジェット」を消費しない方が、より攻めの開発を継続できます。障害という「失敗」を個人やチームの責任にして責め立てるのではなく、それを「ポストモーテム」にまとめケーススタディの題材にして学びを共有することで、サービス改善のスピードを上げることができます。

ちなみに、ここで紹介した「エラーバジェット」や「ポストモーテム」が実際にどのように活用されているかについては、『SRE サイトリライアビリティエンジニアリング――Googleの信頼性を支えるエンジニアリングチーム』という書籍にGoogleにおける例が詳しく書かれています。（ただ、専門書なので基本的には読まなくていいと思います。僕も紹介記事を読んだだけで、原典はまともに読んでないです。。。）

失敗を許容しそこから学ぶ「文化」をつくるには？

前述したように、ずっと止まらずバグもないような「完璧なシステム」というのは、基本的には存在しません。システムを作っているのが不完全な人間である以上、システムもどこか不完全になってしまうのは当然です。その「不完全さ」を数値化して合意し、その合意の下で日々障害に学びシステムを改善していくことが、現時点でわかっている最良の選択です。そのための方法論や考え方として、「SLA」、「エラーバジェット」、「ポストモーテム」を紹介しました。

しかしながら、こうした方法論を振りかざすだけでは解決しない問題があります。それは、「文化」の問題です。

たとえば「99.99%以上の月間稼働率」をSLAとして掲げたとしても、「止まらないシステムが欲しいから合意できない」とか「SLAの範囲内だとしても障害が起きたら謝罪に来るのが当然だ」といった文化的なギャップによってSLAを適切に合意できないケースがあります。

今回の東証の宮原社長の引責辞任は、こうした「システム運用の失敗を許容する文化」の醸成に対して、マイナスに影響する可能性があります。そこが僕が一番残念に思う点です。

仕組みを導入するのは簡単ですが、「文化」を醸成するには時間がかかります。また、誰か一人が大鉈を振るって解決するような問題でもありません。僕としても、日本に「失敗を許容する文化」が広がり、楽しく本質的な仕事ができる人を増やせるように、日々発信を続けていきたいなあと思います。よければ一緒に頑張りましょう。

ここから先は

0字
同僚と飲むビール1杯分の金額で、飲み会で愚痴るよりもきっと仕事が楽しくなる。そんなコラムを月に3〜4本お届けする予定です。

仕事を楽しくするデジタルリテラシー読本

¥500 / 月 初月無料

【初月無料】デジタル時代の歩き方について考えたことを発信します。ソフトウェアの時代とは何か。エンジニアの頭の中はどうなっているのか。NoC…

ログイン

サポートをいただけると、喜びドリブンで発信量が増えます！初月無料のマガジン『仕事を楽しくするデジタルリテラシー読本』もおすすめです！