デザインワン・ジャパン Tech Blog

DesignOne Japan | Activate the World.

ウミガメは障害調査に役立つ

はじめに

こんにちは!株式会社デザインワン・ジャパンでエキテンの開発を担当しているサービス開発部の寺井です。

 

最近社内でウミガメのスープが流行っています。私は出題者に回ることが多いのですが、回答者になって質問している時、ふと気づきました。

「最初何もわからない状況から答えを探し出すのは、障害調査と似ているのでは?」

と。そして、

ウミガメのスープを解く能力は、障害調査に役立つのでは?」

と。そのことを実際の障害調査を出しながら見ていこうと思います。

 

ウミガメのスープとは

まず、水平思考という用語について触れていきます。Wikipedia によりますと、

水平思考(すいへいしこう、英:Lateral thinking)は、問題解決のために既成の理論や概念にとらわれずアイデアを生み出す方法である。エドワード・デボノが1967年頃に提唱した。

水平思考 - Wikipedia

と説明されています。簡単に言うと、固定概念に囚われずに思考していくのが水平思考になります。

(水平思考の対となる用語として、垂直思考というものがあります。既にある情報などを使って論理深めていく方法です)

 

ウミガメのスープは、その水平思考ゲームの一種です。出題者が問題を出し、回答者は「はい」「いいえ」「関係ない」で答えられる質問を出題者にしていき、答えを導くゲームとなっています。

 

ウミガメのスープを解いてみよう

「温度計を買いに店まで行ったが、結局買わなかった。なぜ」

という自作問題を社内で出してみました。

 

絵文字は質問に対する回答を表しています。

🙆: はい

🙅: いいえ

🙂: 関係ない

 

「売り切れだったからですか」🙅

「本当に店までは行きましたか」🙆

「そこは一般的に温度計が売っている店舗ですか」🙆

 

という想定通りの質問が飛んできました。ただ、定番の質問だけで先に進むことは珍しいです。

 

「室内の温度を測るものですか」🙆

「買いに行った理由はその時の温度に関係がありますか」🙅

「温度計の大きさは一人で持ち帰られるものですか」🙅

「その買いに行った人と同居している人はいますか」🙂

 

などと、自分が想定していなかった質問も飛んできました。ウミガメのスープで大切なことの一つは、「室内の温度を測るものですか」のような、当たり前だと思っていることを聞くことです。叙述トリックとかで騙されることがあるためです。

 

「温度計に満足しなかったからですか」🙆

「°F仕様が欲しかったのに℃仕様しか売ってなかったとかですか」🙅

「温度計を1つだけ買おうとしていましたか」🙆

「他に温度計を買おうとしていた人がいましたか」🙅

 

という鋭い質問も飛んできました。今回は関係なかったですが、摂氏と華氏は作問のアイデアの一つとして使えそうだなぁと思いました。

 

ウミガメのスープの欠点としては、出題者がいないと進まないことです。つまり、業務中の雑談では向いていないということです。特に、ブログなどだと問題と答えを載せるだけになってしまいます。なので、この続きが気になる方は答えを見るなり、人に答えを見させて出題者になってもらってください。

 

答え:売り場に置いてあった温度計が全部バラバラの値を指していたので、精度がよくないと思って買わなかった

 

実際の障害調査

20XX年X月X日——。 障害は突然起こった。

Yはいつも通り起床し、twitter を見ようと寝ぼけ眼でスマホを手に取る。

「なんかメールが来ているなぁー。まぁ、またスパムメールかなぁ...、って、サービスZへの連携バッチが落ちとるじゃん!!!!!!!!!!」

波乱の一日となりそうだなと思った朝だった。

この場合、ウミガメのスープ風に問題をおくと「サービスZへの連携バッチが落ちた。なぜか」という問題になります。そして、出題者と回答者は基本的に自分となります。

 

「そのバッチは毎日動いていますか」🙆

「前回実行は正常でしたか」🙆

「前回実行時から、バッチのソースコードはいじっていますか」🙆

「前回実行時から、何かしらのソースコードのリリースはなにかありましたか」🙅

毎日起動しているバッチで、前日は成功している。前日と今日のソースコードの差分はない。つまり、弊社要因である可能性は低い?

 

「サービスZに障害情報はでていますか」🙅

ほほぅ。出ていないのか。そしたらサービスZも関係ない?

 

「バッチのログで落ちた箇所がわかりますか」🙆

ログを見ると、サービスZへの curl が落ちていることがわかった。リトライ 10 までするようにしているが、全て落ちていた。

ということは、ネットワーク周りの障害?

 

「他にネットワークに関するエラーログは出ていますか」🙅

ステータスコードは出ていますか」🙅

ステータスコードすら出ていないのか...。これは辛い。

 

ステータスコードを出す処理はありますか」🙅

そもそも出そうとしていないのかい!誰だよ実装した人は。

(一年前の僕です。すみません)

 

ステータスコードやエラー詳細を出すような修正を行ってもいいですか」🙆

「修正後、再実行してもいいですか」🙆

上長から修正と再実行の許可をもらったのでやってみる。

 

curl の結果でなにか特殊なログが出ていますか」🙆

ログを見ると ssl_verify_result の値が 10 であることがわかった。そのエラーコードは証明書の有効期限切れを指している。

 

「サービスZの証明書は直近で入れ替わりましたか」🙆

証明書を見ると前日に入れ替わっていることがわかった。そして Let's Encypt の証明書を使っていることもわかった。

 

「EC2 で Let's Encypt の証明書が使えないことがありますか」🙆

ようやく原因が突き止められた。やったぜ。

aws.amazon.com

 

追伸: そのあと、上記ページの解決方法を情シスにやってもらい、再実行することで今度はちゃんと動きました。めでたし、めでたし。

 

まとめ

障害調査は、最初は思いつくものを確認していく感じになります(水平思考)。とっかかりを見つければ、それを深掘りしていきます(垂直思考)。その水平思考を鍛えるには、ウミガメのスープが役立つのではと思った次第でした。

 

仲間を募集しております

募集中の職種については以下を御覧ください。

www.wantedly.com