# OSINT for SRE: 学術論文とポストモーテムから探るシステム障害の共通パターン — transcript source スライド: [OSINT for SRE: 学術論文とポストモーテムから探る システム障害の共通パターン / SRE NEXT 2026 - Speaker Deck](https://speakerdeck.com/tomoyk/sre-next-2026)（[[OSINT for SRE - slides.pdf|ローカル保存版]]） ## 公式アブストラクト 私はソフトウェアエンジニア(DBRE)として実務におけるシステム運用に関わりながら、博士後期課程でシステム障害原因の分析を研究しています。研究活動で学術論文やポストモーテムの記事を読むうちに、システム障害の事例や分析結果が十分に運用で活用されていないことに気づきました。こうしたシステム障害の知見が活用しきれていない要因の一つは、システム障害の事例を包括的に分析した日本語の資料の不足にあると考えます。本セッションではインターネットに公開されている20以上の英語で書かれた論文やポストモーテムを使い障害原因の傾向の分析(OSINT for SRE)を行います。セッションでは、まずMicrosoftやeBayのエンジニアによるものを含む5件の論文を分析し、その中から主要な4種類の共通した障害原因を紹介します。さらに、それら4種類の主要な障害原因をポストモーテムや論文、具体的な事例とともに詳細に分析します。4種類の主要な障害原因の1つには連鎖障害があります。マイクロサービスアーキテクチャで設計されたシステムでの連鎖障害は、あるマイクロサービスで起きた障害が別のマイクロサービスへ連鎖して障害が発生することです。システムの運用で連鎖障害を知っていても、いくつのマイクロサービスに連鎖するケースが最も多いか、どんな種類のシステムから連鎖障害が発生しやすいかを把握しきれていない状況にあると考えています。本セッションでは運用経験にもとづく感覚的な認識ではなく、データを使った定量的な分析を行います。本セッションを通じてシステム障害の原因の傾向を具体的なデータをもとに定量的に把握できます。またデータを把握することにより、自社でのシステム障害の対策において対象や優先度の決定を正確に行えます。 ## 登壇者略歴 株式会社メルカリ DBRE 小山 智之 tmyk_kymtomoyk 2024年より株式会社メルカリにてDatabase Relibility Engineer。同年より東京工科大学大学院 バイオ・情報メディア研究科 コンピュータサイエンス専攻 博士後期課程（社会人学生）。研究対象は、障害の根本原因の分析、故障の局所化。 ## タイムスタンプ付き逐語文字起こし **00:00** （会場のアナウンス、拍手の音） OSINT for SRE: 学術論文とポストモーテムから探るシステム障害の共通パターン 小山 智之 **00:29** はい。よろしくお願いします。「OSINT for SRE」というタイトルで、株式会社メルカリの小山智之が発表します。 まず簡単に自己紹介です。小山智之と申します。株式会社メルカリでDBREチームに所属しています。主に我々のチームはですね、40テラバイトオーバーのDBの運用、特にMySQL、TiDBを行っているチームです。現在、メンバーを大募集中なので、よろしければお声がけください。 私はですね、仕事の傍らで、東京工科大学大学院の博士後期課程に所属して、社会人学生として研究活動を行っています。特に分野としてはITシステムでの障害原因分析みたいなところをトピックにしています。SRE Lounge（SRE Next？）に関しては、SRE paperというチャンネルがあるんですが、そこに、よく論文をポストしたりしています。はい。 **01:31** 今日のセッションについて、まず初めに、研究とは何かっていうのがパッと思い浮かばないと思うので、簡単に概要を説明します。大学院の研究活動で何をするかというと、簡単に言えば論文を書くということです。論文を書くというのは、例えば、右側にあるような英語で論文を書いて公開するという流れです。 論文を書く中ではですね、関連する分野の文献調査というのを行います。文献調査の中ではですね、今、人類が何ができているのか、到達点、そして、何ができていないか、未到達点を明確に示す必要があります。この文献調査の過程で、50件から100件といった大量の論文を文献調査するわけですね。この中でですね、やっぱりビックテックと言われるマイクロソフトであるとか、ウーバーであるとか、そういった大企業の論文があるわけです。こういった論文にいろんなデータがあって、こういったデータを運用の現場にもっと活用できないかというのがこのセッションの動機になっています。 **02:37** 本セッションの位置づけについて、簡単に説明します。タイトルとして「OSINT for SRE」と付けたんですが、オープンソースインテリジェンスの略でして、よくセキュリティや軍事の面でよく使われる言葉なんですが、公開情報の論文とかポストモーテムの解析を行って、そこから障害の原因のパターンや共通点がないかっていうのを解析します。 特にどういうふうに集めたかというと、Googleアラートで、公開されたポストモーテムを集めてきたり、Google Scholarを使って、Googleにある論文の検索エンジンなんですが、そういうものを使ったり、ChatGPTとかClaudeのディープサーチ機能を使って論文を書き集めています。そこの、体系的にそれらを分析するのを人間がやって、最後、分析した結果をもとに、どんな傾向やパターンがあるかっていうのを明らかにするということをやっています。 これによって、例えばどういうシステム障害が、会社に関わらずどんな共通パターン、傾向があるかっていうのを明らかにしたいというのが動機付けになっています。 **03:39** まず、一番最初に考えたことは、何が障害の原因なのかということ、が、まず知りたいことです。ここでいう障害というのは、システムが正常な状態から逸脱している時と定義しました。 まず、最初にやったのがGoogle Scholarで、ルートコーズアナリシス、根本原因分析、みたいなトピックで論文を探すこと。そして、生成AIを使ってですね、ディープサーチ機能を活用して、以下のようなプロンプトを使って論文を調査して、そうすると、多分、皆さんこのプロンプトを使えば、誰でもディープサーチ機能で論文探すのが簡単にできます。ここから出てきた論文5種類くらいを見つけて、そこをサマリーしたというのがまず最初にやったことです。 **04:25** ここが一番の、多分、結構、情報量の多いページなんですが、まず、その結果、論文5本まとめてサーベイして、上位5件をまとめました。これは横に、論文の横に論文が並んでいます。縦に順位です。 左から見ていくと、中国の交通銀行という、中国にある銀行のシステムの障害を分析した論文です。次がマイクロソフト、これマイクロソフトのアジュールの論文だったと思います。あとはサーベイは、いろんなポストモーテムを集めてきて、解析した論文。ディープフローは、クラウドネイティブコンピューティングファンデーションの傘下にある、eBPFベースのオブザーバビリティのプロジェクトがあるんですが、そこの開発元が書いている論文です。 最後がeBayですね。eBayはメルカリに近いようなECのサービスです。このランキング、近いものを、同じ色で塗っています。そうすると、黄色のコードのバグとかコードの欠陥というところ、そして、コンフィグエラー、コンフィグミスといった赤いところ。あとは、ネットワーク障害、といった青い部分、そして、最後はインフラの緑。ここが大体共通して出てきている障害の原因パターンだということが分かってきています。この以降ではこれらをもう少し、こう、深掘りして分析するというのをやっていきます。 **05:49** まず、インフラです。ちょっとここポンチ絵書いたんですけど、インフラって結構すごい広くて、ミドルウェア、OS、ハードウェアとか、あとはデータセンター、やっぱりデータセンターとか、そういうかなり深い幅広いところなので、ちょっとこう範囲としてすごい広がってしまうので、ここらはちょっと、こう、簡単にサマリーをしてお話をします。 **06:11** インフラ、まず、こう、皆さん多分、オンプレミスよりはパブリッククラウドを使われているケースが多いと思っていて、データセンターネットワークとか、あとは物理サーバーの故障っていうのに対する、こう、調査とか対処っていう機会は多分減っていると思っていて、やっぱりこの、ここを調査してわかったのは、クラウド事業者のオンプレミスの視点での障害分析がすごい大半でした。一方で言うと、クラウドユーザー側の調査っていうのがなかなかないと。 なので、ここではその紹介できる内容として、クラウドのユーザー側というよりも、データセンターとか、オンプレミスを使っているケース。あとは、パブリッククラウド提供者側の解析みたいな部分を紹介します。 **06:52** まず、一番、こう、故障として思いつくのはハードウェアの故障だと思います。壊れやすいハードウェアの調査をした論文がいくつかあって、これはバイドゥ、中国の、ビックテックですね。あとはマイクロソフトの、データセンターでのサーバーの壊れ、ハードウェアを解析した論文があって、それをこうまとめたものです。 この右側の表は上位5件、それぞれの論文の上位5件なんですが、まあ、1番上に出ているのはHDDで、これが70〜71%とか81%という形で、圧倒的にHDDの故障が多いということがわかっています。これは、こう、1個の会社だけじゃなくて、複数の会社で同じようなデータが出ているということが分かっています。 SSDはどうかというと、実はバイドゥとかだと0.31%ぐらいで、全然、故障率としてはHDDの方が圧倒的だということがわかっています。 HDDって右上に載せたんですけど、HDDって円盤を回転しているので、ハードウェアのプラッターっていうこの、キラキラした板が、高速で回転しているので、やっぱり摩耗、ハードウェアが摩耗して壊れるというパターンが多いというのが、多分、おそらくこうなっている理由だなと思います。よく、こういうハードウェア系の話ってバスタブ曲線って、こう、言われたりして、壊れ方がこれにリンクされてたりします。 **08:10** ただ、ハードウェア故障が確かに支配的なんですが、ハードウェアの故障がサービスレベルに影響を与え、障害の主な原因ではないということは言われています。これは、かなり知られていることで。 一般的にハードウェアの実装、ハードウェアのバグに対処する、オペレーションミスを対処する方が実は難しくて。むしろ、ハードウェアの障害、ハードウェアの故障っていうのは、実はそんなに、こう、致命的ではないということは知られています。 ディスク故障が特に、例えば、ストレージシステムでの障害の主要な原因ではないことも知られていて、ネットアップとか、グーグルのリサーチの結果でも同じような結果が出ていて、実はハードウェア故障というのは、確かに起きはするんですが、実はそのサービスに影響を与えるような故障ではないということが知られています。 **08:57** で、次が、データセンターネットワークです。これはですね、メタとアリババの、えっと、論文から探してきました。で、これはメタ、アリババともに、えっと、上位、乗せられる分だけ乗せて8件まで、8位まで出ていました。 この表は、上位2件をピックです。ハードウェア、機器のハードウェア、そしてハードウェアがデータセンターネットワークの、故障、障害の原因だと。 ということで、まず言えることはですね、上位1件を見るとハードウェアがやっぱりよく壊れやすいと。その次にきているのが、やっぱりこう、赤のバグですよね。共通で4位にきているのはバグ。 **09:57** その下にきているのが設定ミス、コンフィグミス、みたいな形で。まあ、このあとコンフィグミスの話もするんですが、やっぱり共通して起きているっていうのは、皆さんお心当たりあるんじゃないかなと、こういう故障原因。 ただ、この表を見てわかることは、1つは、やっぱり、基準が統一されていないですよね。なので、会社によって分類の仕方が食い違っています。なので、こう、単に同じものが含まれているからって言って、含まれてないからっていうのは、分類の仕方が違うので、一概には言えないんですが、ある程度の傾向は似ていることが言えます。 **10:13** で、ここまでちょっとインフラの障害のあたりをまとめるとですね、HDDの故障がバイドゥとマイクロソフトで、70%から80%で大体一番多いということ。ただし、ディスクの故障は、システム障害の中で支配的ではないということですね。そして、データセンターネットワークで言うと、やっぱりトップはハードウェア、機器のハードウェアのフェイラーであるということが言えます。 ただ、一方で、ここで分析をしてみてわかったのはですね、クラウドベンダー側の、プロバイダー側の障害は、データは色々集められているんですが、やっぱりユーザー企業、特に皆さんそういうユーザー企業側だと思うんですが、そういったデータがなかなかなおかつなくて。この分析から、なかなか、まだ足りていないというのが現状です。 これは、こう、自分の、こう、分析というか考察なんですが、やっぱりクラウドの時代になると、すべてがソフトウェアになってくると思うんですよね。そうなると、どちらかというと、ハードウェアの故障とかっていうよりは、ユーザー側、使う側で言うと、コンフィグミスとか、バグ、あとは、バグとか、そういうソフトウェアベースの問題が、メジャー、主要になるんじゃないかなというふうに思っています。 **11:26** で、次が連鎖障害ですね。連鎖障害は、何かあるシステムで障害が起きると、別のシステムに障害が発生する、というような話。 連鎖障害、これ聞いて、簡単にアンケートなんですけど、聞いたこととか、思い当たることあるかっていうのは。あ、結構、そうですね。意外といますね。はい。 もう少し、具体的に話をします。連鎖障害とかカスケードフェイラーって言ったりします、英語でよく。 マシンの内部の例えば、あるマシンのなかでも複数プロセスが動いていて、あるプロセスがメモリをたくさん使用して、別のプロセスが影響を受ける。色んなこういうケースが連鎖障害。あとはマシンを超えて、あるマイクロサービスが別のマイクロサービスに伝搬するのもこのケースです。 例えば、去年、2025年の10月のAWSのUS-EAST-1リージョンの障害ですと、DynamoDBのDNSの障害がEC2、NLBにプロパゲーションして連鎖していたと、いうことですね。マイクロソフトでも67%が、システム、あるシステムの障害が別のシステムに連鎖していると。 なので、かなり、こう、特にマイクロサービスとかSOAの中で連鎖障害、こういった連鎖していくっていうのがよくある障害だということが言えます。 この下は自分の、こう、感覚というか分析なんですが、やはり、連鎖障害がどうして起きるかというと、1つは、ある1つのシステムを、2つのシステム、3つのシステムで共有する。シェアードDB、共有DBがあること。そうすると、どこかノイジーネイバーがいると、結果的に別のシステムも影響を受けてしまう。これ、信頼性工学だと、こう、共通原因故障、CCFと呼んだりするそうです。 もう1つはですね、1つのシステムを複数のシステムに分けることですね。これは例えば、モノリスアプリケーションをマイクロサービスに分割して、結果的にシステム同士に粗（疎）が発生して、その結果、別の、あるシステムが起きるとその巻き込まれた別のシステムも影響を受けるケースですね。 **13:34** ここから、ちょっと少し、こう、興味深いデータがかなり出てくるかなと思います。まず、障害の連鎖する深さ、つまり、1個マイクロサービスが落ちたときに、どれくらいそれが影響するのか。英語で言うとブラストラディウス（Blast Radius）って言うんですけど、これを分析してます。これは、1つはサーベイの論文、でもう1つはUber Technologies、Uberの分析です。 結果は左の、右の上の表なんですが、まず、ちょっと見方を、簡単に説明すると、まず、深さ、一番左の列に深さがあります。この深さは、まず1は、1箇所、その壊れたシステムが1と数えます。で、別のシステムに行くときに初めて深さ2になるんですね。なので、1というのは、別のシステムに連鎖をしていないということになります。 この表を見ていただくと、一番多いのは2ですね。この、深さ2。52.6、37.48で、一番多いのが深さ2なんですね。なので、まず言えることは、1箇所に、あるシステムが壊れたときに、別の1箇所に連鎖するってことがこのデータからわかります。 これはサーベイとUber両方とも同じデータです。で、Uberの面白いケースですと、深さが26、21、1つのフェイラーが26個 of システムにシーケンシャルに、連続に、こう、伝搬しているっていうケースが、ごくすごいレア、0.何パーセントっていう細かい割合なんですが、起きているということがわかってます。 そして、大半の障害っていうのは、実は深くなくて、そんなにたくさん連鎖していなくて、ほとんどが3つのマイクロサービス、3つのサブシステムに連鎖しているということが、実は分かっています。なので、ブラストラディウスは小さいんですね。はい。ということがわかっています。 **15:24** で、次、連鎖するパターンです。どんな種類のシステムからどんな種類のシステムに連鎖しているかという話。 これも、右側にあるのは２部（二部）グラフです。２部（二部）グラフっていうのは、こう、丸いのがノードっていって、こう、線で繋いで、例えば、左上のサードパーティから線が伸びてストレージに、こう、線が伸びて、サードパーティのシステムからストレージに障害が連鎖しているってことが、この図からわかると。 この線の太さがどれくらいの件数障害が、件数の割合で起きているのかっていうのを表していて、太ければ太いほどそれが多く、多く起きているということが言えます。 これ見ていただくと、ストレージ、ネットワーク、ミドルウェア、バックエンド、アプリケーションからアプリケーションに対して、プロパゲーション、連鎖が、こう、していると。いうことがわかってます。 この表でも整理したんですが、やっぱりトップはストレージアプリケーション。で、次がネットワークアプリケーション、ミドルウェアアプリケーションっていう風に、とにかく、アプリケーションに、その下のレイヤーですね、インフラストラクチャとか下位層から上位層に対して障害が連鎖しているってことが、この分析から分かってきています。はい。 **16:34** で、連鎖障害の対策としてですね、いくつか、ここであげます。まず、隔離と最小化っていう風に分けていてですね。 隔離の点で言うと、まあ、よく多分、他のセッションでも、この後の、セッションでもあると思うんですが、サーキットブレイカー、スロットリングといった形で、こう、負荷の高いときにそれを拒否する、制限するような仕組み。例えば、SDKアリアのケースですと、レジリエンス4J（Resilience4j）とかポリー（Polly）とかっていうようなライブラリがあります。あとは、サービスメッシュ、IstioとかLinkerdに、こういった、記述があります。 あと、セルベースドアーキテクチャっていうものがあります。これは、AWS、Amazonが確か最初に言い出していたと思うんですが、最近で言うと、AWS re:Inventの2024年にSlackがセルベースドアーキテクチャを提唱しています。 これに、セルベースドアーキテクチャって何かというと、リージョンやアベイラビリティゾーンで、システムを論理的ユニット、論理単位 of ユニットのセルで分割をします。で、セルのなかに、LBやアプリケーション、DBを入れて、それをたくさん分けて配置します。これによって、障害があるセルで起きても、別のセルに障害が起きないように閉じ込めるってことができます。 もう1つの、最小化の単位で言うと、やっぱりリリースを小さく切って分割していくってことが、やっぱり大切だと思っています。 例えば、リリースの分割で言うとですね、例えば、マルチリージョンとかマルチゾーンの場合ですと、リージョンを分けるとか、ゾーンを分ける、ではなく、一部のリージョン、一部のゾーンにリリースをするってことがあると思います。 もう1つはカナリアリリースですね。これはもう、皆さん多分、よく聞くと思うんですが、とにかく、こう、トラフィックシフトとか、アプリケーションのフィーチャフラグとかを使って、こう、アプリケーションの、段階的なリリースをする。それによって、仮に何か混入しても、それを、すぐ、影響範囲を小さくするということができます。 **18:31** で、連鎖障害の話ちょっとまとめます。まず共通パターンとしては、連鎖障害のほとんどが連鎖数が3つ。なので、2つのマイクロサービスに連鎖しているということ。多くが、大半だということ。 そして、アンダーの、その、インフラストラクチャですね、ストレージとかネットワークの障害が、アプリケーションに連鎖しているっていうケースがすごい多いということ。 で、緩和する方法としては、やっぱりサーキットブレイカーとかスロットリング、あとはセルベースドアーキテクチャを、あとは、リリースの分割、カナリアリリース、っていうものがあります。 この下にあるのはですね、バルクヘッドパターンって、いう話で、セルベースドアーキテクチャは、バルクヘッドパターンとも呼ばれるんですけど、バルクヘッドって何かというと、船の、船頭（※船首）のところ、なんですね、確か。 船って、こう、水が一度穴が空いて入ってきたときに、こう、そのまま全部船に水が入ってしまうと、船が沈んじゃいますよね。で、どうやっているかというと、今、水密隔壁って壁を作って、水が入ってきたとしても、その、壁で水が、こう、中深く入らないように、ちゃんと守るんですね。こういうのがやっぱりシステムにおいても必要な、システムなんですよね、ということ。やはり、コンセプトとしてやっぱりあるということですね。 **19:46** はい。で、ここまで、連鎖障害とインフラの話をしてきました。はい。で、次はですね、コード of バグに行きます。 皆さんバグって何か知ってますか？はい。 バグっていうのは、実は本当にバグって英語で虫です。バグ、世界で最初の虫は、バグっていうのは、リアルな本当の虫で、機械式のコンピューターに挟まったことから呼ばれて。ちなみにデバッグっていうのは、バグを取り除くからデバッグになったそうです。はい。 **20:14** で、ソースコードのバグの話です。去年の8月にPagerDutyで起きた障害ですね。これはですね、Kafkaのプロデューサーが使い回されるのではなくて、APIリクエストごとにKafkaプロデューサーが作られた結果、JVMのヒープメモリが、こう、使用量が増えていって、枯渇してしまって、というインシデントです。 まあ、こういったバグっていうのは結構売れているし、多分、僕も多分ここら辺、心当たりがいろんなところであるんですけど、はい。 これはですね、下の表は、マイクロソフトアジュールの本番環境で6ヶ月に起きた、112件のインシデントを、分析してます。 特に多いのはですね、コンポーネントの障害、故障、コンポーネントのフェイラーで、次がデータ形式のバグ。で、この上位を2つをちょっと今日、この後説明をします。 **21:03** で、ソースコードのバグの中でも一番多いのはコンポーネントの故障で、これは何か表达というと、あるソフトウェアコンポーネント、例えば、マイクロサービス、と捉えていただいていいと思います。そこで、障害、故障が起きたときに、こう、検知がうまくいっていないケース。そして、対処が不正確なケースっていうのが、ハンドリングの問題です。 この下の分類ですね、どう、壊れたかということを、分類したものです。大きく分けると3つあります。 1つは、コンポーネント、ソフトウェアコンポーネントのエラーの、エラーハンドリング。 あるコンポーネントが、青いコンポーネントから灰色のコンポーネントを呼び出しました。その結果、灰色のコンポーネントがエラーをレスポンスで返したというケースですね。このときに、青色のコンポーネントで結果的にエラーが起きてしまうということです。 これ例えば、こう、マイクロサービスで別のマイクロサービス呼んだらエラーになったとか、あと外部APIをコールしたけれど、それがエラーになっていて、結果的に障害になっているケースですね。 次がですね、29%で、応答不能なコンポーネント。よくあるのは、ウェイトして、こう、リクエストを送ったんだけれども、返ってこない、ずっとタイムアウトまで待たなきゃというケース。例えば、ロードバランサーの切り離しに失敗して、そのままずっと返ってこないみたいな。 ヘルスチェックも受けているのになぜか、リクエストがルーティングされちゃって返ってこないみたいなケースですね。 最後はサイレント故障で、これかなり厄介で、永続データとかが、実際にはストアされているのが、コンテンツとしては返ってきているけれど、実際の中身に、が、壊れているとか、データ形式がおかしいとか、そういうケース、です。 **22:53** で、故障検知がどうして、じゃあ、壊れてる、どういう壊れ方さっきしたのかって話をしたんですけど、どうして、故障を気づけなかった、検知できなかったのかという話。つまり、エラーハンドリングのバグの話です。 1つは、エラーハンドリング自体がちゃんとしてないとか、っていうケース。なので、ここで言うと、GからFを呼ぶっていう風な構造なんですけど、GからFを呼んで、Fがエラーを返したときにGが検査するような、機能がついていないというケース。で、こういうケースがあります。 右側の方はですね、故障検知のロジックはある、エラーハンドリングはしてるんだけど、それが途中でデータが消失してるケースですね。例えばこう、エラーのシグナル、例えばログに書いてるんだけど、なぜかログに書く前に落ちてるとか、あとは、なんか、欠損しているというケースですね。そうすると結果的に外部から見ると正常に動いているように、こう見えてしまう。 あとは、途中、伝送経路で、その、エラーだったりログだったりレスポンスが消失するケースとか、特にネットワークの輻輳とか起きるとこういうケースが起こりうると。なので結果的に検知ができないという話です。 **24:08** 次がですね、データ形式のバグです。これ多分かなり、こうすごい自分にも思い当たることがありますね。異なるシステムコンポーネント間でこうデータ形式が衝突するケース。で、この下はどう壊れたかって話なんですけど、 左側ですね、40%ぐらいあるのは、DBのスキーマが食い違っているとか、ファイルのフォーマットは変わった、変わって食い違っているケース。例えばこう、この下の図ですとオルターテーブル（Alter Table）して、カラムを消したんだけれども、アプリケーションに参照が残っていて、そのままアプリケーションでカラムがなくてエラーになって障害。 あとは、メッセージインターフェースの右側の方ですと、例えばAPIですね、マイクロサービスとかでAPIを呼んだけれども、スキーマが違ってて、こう変更を加えた後のスキーマの参照が残っていて、フィールドがないとかカラ、こういうことでエラーになっちゃうと。はい。 **25:05** ここまで、ソースコードのバグの、対策とまとめだったんですけども、コンポーネントの故障はやっぱり、こう、エラーハンドリングが足りていないということがあります。 コンポーネントのエラーはやっぱり、こう、故障っていうのが、エラーになって、こう、壊れて、それはやっぱり要は連鎖障害なんですね、さっき言ってた。なので、かなり、こう、マイクロサービスみたいな、システムで、複数のコンポーネントがあると、こういう壊れ方が結構しやすいということです。 データ形式のバグで言うと、コンポーネント間でデータが衝突した結果がすごい多いと。 やっぱり、データ形式が変わっても、この辺をこう一貫性を保てるような仕組みがないと、自分、ある、こうマイクロサービスと、別のマイクロサービスが参照しているインターフェースが違うと、結果的にこういう問題は十分起きると。なので、こう、伝える仕組みがあるか、一貫性を保つような仕組みが必要かなと思っています。 **25:54** ちょっとコンフィグミスですね、次行きます。はい。で、コンフィグミス多分、皆さん大体、思い当たる、絶対全員、思い当たると思うんですけど、はい。 Googleでもサービスレベルに影響を与えている障害の1つになってます。これネットアップだと思うんですけど、ストレージ企業のテクニカルサポートに、リクエストが来ている27%はコンフィグの問題。 例えば、スカイスキャナー（Skyscanner）では、Argocd（Argo CD）のクラスターの変更をしたんですが、青色、緑色の、グラ（クラスター）を変更したんですね、で、括弧が抜けていたそうです。その結果、新しいネームスペースがなくて、世界中のアジュールのリージョン、すべてのネームスペースのリソースが一括で消され始めたという、とても怖い障害が起きました。こういうミスコンフィグが起こりうると、いうことです。 **26:40** コンフィグミスをもう少し、こう、タクソノミーというか分類した話がここです。 実際に、ネットのフォーラムと、あとはコンプウェア、ネットアップの本番のシステムのインストラクションのシステムがあって、ここを分析したものです。 一番多いのは何かというと、パラメーターの部分です。この、パラメーターっていうのは何かというと、設定パラメーターを間違えているケース。 コンソールのコマンドを間違えているケース、です。 70%から80%ぐらいは大体こういう原因があるというのが分かっています。 **27:14** 例えば、ちょっとここでは具体的な例を出します。この論文すごい、ちょっと昔なので、ランプ（LAMP）時代ですね、の、設定ミスが多いんですけど。 Apache HTTPサーバーの話で、モジュールの読み込み順番が間違っている結果、セグフォ（Segmentation Fault）が起きていると。本当は、mod_record.soを先に読んでからmysql.soを読まなきゃいけないらしいんですが、その順序が間違ってた結果、セグメンテーションフォールトが起きていたと、いうことです。 下の例はですね、値の不整合って話で、よくよく見ると変で。 ログを書き出すのはテーブルに、mysqlのテーブルに書き出す。はず。なんですが、次のパラメーターは、query.logというファイルに書き出す設定になっています。 なので、結果的に不整合が起きてしまっていて、本当は何が正しいのか、これだけ見てもわかんないですね。 **28:10** ただ、こう、今までコンフィグミスはなんか人間が書き間違えたから悪いみたいな、こう考えにどうしてもなるんですが、本当にそうかというとも、そんなこともないんじゃないかという意見はあって。 コンフィグミスを、こう、ソフトウェアに、間違ったコンフィグミスを入れて、実際に挙動分析したような論文がありますと。 ここで紹介したのは2つあります。1つは、パラメーターの単位が不整合という話で、 例えば、これグラフになっているのは、コンフィグの中にある、時間の、単位、単位です。例えば、タイムアウトを設定するパラメーターの時間の単位が何かというと、例えば秒であるという箇所と、ミリ秒である箇所、が、あったりとか、混ざってたりすると。そうすると、ある箇所を秒で指定したのに、別の箇所がミリ秒になってたりすると、こういうバグ（不具合）が起きます。 安全でない関数の使用という言葉で言うと、時間の単位ではなく、関数のなかに、こう、1を0みたいに書いたのに、実際に1で解釈されたりしてしまうということです。 **29:11** はい。で、ここまでまとめるとですね、ソフトウェアの開発者側の視点で言うと、パラメーターに時間をつけましょう、単位を。そうすると、絶対間違えない。 単位をちゃんと、つけるような必須なバリエーションを入れるとか。ですね。 さっきの安全でない関数を使わないという話だと、JPサード（JPCERT）とか、が、日本語に、コーディングスタンダードがあるので、ぜひこういうのを使うと防げます。 ユーザー側で言うとですね、ケアレスミスを防ぐためには、シンタックスチェックとかが必要ですね。 値の整合はやっぱり今も解ききれていないので、今後もやっぱり、何かしらの方法で解決すべき問題として残っています、まだ。 やっぱり、人がコンフィグミスをするので、認知特性みたいな部分をやっぱりこう分析しないと、人のミスっていうのは防げないんじゃないかなというのは、今、考えているところです。 **30:02** はい。最後にまとめです。今日の話はですね、やっぱり論文の、運営の内容をですね、自システム運用で何か役立てられないかというのが動機でした。 主要な原因はですね、こう、インフラ、そして連鎖障害、そしてバグ、ソフトウェアのバグ、コンフィグミスの4つありました。 残された課題としてはですね、クラウド時代のやっぱり、こうコンフィグミス、ユーザーのコンフィグミスがまだまだ足りていないということ。 そしてですね、障害データが、とにかくやっぱ足りていないんですね。2017年、2017、3年のデータを使ってます。とにかくデータが少ない。 やっぱり公開、皆さんがそれぞれデータを公開していただくことが、とっても、こういう分析とかインテリジェンス、とっても役に立つので、ぜひこうポストモーテムを公開していただけると、こういった分析が、他の会社のためにもきっと役立つはずです。 ぜひ、こう、論文化したいって話があれば、ぜひ、僕に教えてください。 最後、メルカリ、あとこの後2セッションあるので、よければこちらもご覧ください。以上で発表を終わります。ありがとうございました。 **31:06** （拍手）