この番組はエンジニアの成長は楽しい学びからをモットーにエンジニアの技術とかいろいろなものに関する話題をワイワイお届けするラジオですですおはようございますということで本日ですが

最近ですね僕障害試験というものを学ぶ機会があったのでそのインプットアウトプットする回になります障害試験はい一生が役立つ試験ってことですか違います応用情報とかそういうことですかね一生が役立つかなあれ役立つよわかんないけど役立つと思うよおじいちゃんおばあちゃんになった時とかにねはい二進数でこう

会話するもんねしないよモールス信号とかするかもしれないけどツンツンツンって障害試験多分あんまり聞きなじみない人も

いるかなと思います正直初耳です僕も障害試験をちゃんとやるプロジェクトに入ったのはエンジニア始めて以来初めてでございます障害試験はやってたんですけど障害試験っていう名目で気合い入れてやるのはちょっと初めてですなので今日は障害試験とはっていうのを分かるようになるのと障害試験ちょっと考えるの楽しそうだなみたいなっていうのをちょっと伝えられればなと

思ってオーリンスなので今日はちょっとあの座学的な話に入って最終的にめちゃくちゃな 例えして終わるという回になってますめちゃくちゃな例えして終わるはいなるほどめちゃくちゃな例えして楽しかった今日のエピソードで終わる回になってますちなみに地面は大障害大規模障害の障害に試験は高難度試験の試験ですか やってますはい

低難度試験の可能性ありますけどありますかはい合ってますはいじゃあちょっと早速座学の方から参りますねはいあーそうだその前に障害試験ってググってもあんま出てこないんですようーんっていうのはこれは別にあのなんだろう僕の想像も入るんですけど一般的な用語じゃないっていう意味ではなくて体系的に整理された情報が多分ほとんどないうーんへーうん

っていうので本当に唯一ぐらい体系的な資料であったのがフィンタンっていうブログフィンタンTISインテックグループさんTISインテックグループみたいなCMの技術的なノウハウをまとめているブログというかノウハウ集みたいなサイトがありましてそこに障害者

障害テストについて恐ろしく体系的にまとめられているドキュメントがあったのでちょっとそちらを参考にしながらお話をさせていただきますなので今日僕が言ったこと親って思ったら多分実は正しいことが元ネタに書いてて僕が変なこと言ってるだけの可能性あるんでそっちも見に行ってみてくださいということでじゃあいきます障害テストとは

これは広い意味ではシステムが障害に見舞われた時の振る舞いを検証するテストになっています簡単に言うとどこかがおかしくなっちゃったってなったらその時ちゃんとシステムはこういう風なエラー出るよねなのかこうやって復旧するよねみたいな勝手に復旧するよねなのかもしくはこういう手順で復旧できるよねみたいなそういうものを検証するようなテストになっています例えば

使ってるAPIが実は止まってた時にどうこけるかをテストしたりとかってことですか?使ってるAPIがそうですね、そうですね、はいはいはい、あってますとかデータベース止まった時にどういう風にして復旧するかみたいな応用情報でやったけど実際の現場でやることはほとんどないロールフォワードみたいなそういうやつですか?そうそうそうそうそうそう、ロールフォワードとかねあとはフェイルオーバーみたいなキーが生まれてきますけどみたいな領域ですねこれなんでこんなことやるかっていうと

多分ずっと動いてほしいサービスじゃないやつ社内システム特定の人しか使わない社内システムみたいな止まってても最悪大丈夫なやつに関しては多分あんまやらなくていいんですよそうじゃなくてなんだろうな例えばSARSとかですね24365でサービスを提供していてそれに対して月額料金を払っててみたいなで1回

99.9%動いてない場合は返金しますみたいなそれってシステム動いてるかどうかってすごい売上に関わってきたりとかお客さん逃げちゃったりすると思うんで止まるシステムはそういうシステムにならないようにするためにちゃんとこういう障害が起きてもちゃんと復旧するよねなのか30分以内に復旧できるよねみたいなっていうのをちゃんと検査する

意味で障害テストが行われるという風になっています一方でちょっとこのフィンタンさんフィンタンさんフィンタンは会社じゃないかなフィンタンの記事ではメディア名って感じメディア名障害試験似たようなものいろいろあると思うんですよ例えば高負荷がかかった時にどうなるかみたいな

あとはアラートDBが落ちましたとDBが落ちたらDB落ちたよってちゃんと監視アラートが鳴ることみたいなのも一見ちょっと広い意味では障害試験に含まれる障害テストに含まれるんですけどフィンターさんの記事では例えばアラートが出るよねとかは運用シナリオテストでやりますとか性能に関しては性能試験でやりますとかあとは

対抗システムうちのシステムが叩いている向こう側のシステムが500入っているときどうなるかこれは機能テストで打ち取りますこんな感じでもっと細かく分けてたりしますこれはプロジェクトによると思います本当にウォーターフォールとかではよくあったんですけど多分アジャイルでもあるんですけどテスト計画みたいなものを立ててこういうものはここのテストで打ち取りますみたいなチーム方針プロジェクト方針みたいなのを決めた上で

障害テスト試験やるかやらないか決めてじゃあ障害試験ではこれをやりましょうみたいなそういうものが決められるようなものになっていますここまででざっくり障害テスト試験障害テスト障害テストどんなものかイメージ使われましたか質問があるんですけどなんか

たまに聞くカオスエンジニアリングってあるじゃないですか僕キーワード知ってるだけのあっさり知識で話すととりあえずぶっ壊してどうなるか試してみるみたいなテストだと思ってるんですけどあれとは何か違うんですか多分なんだっけなこれちょっとうろぼえなんですけどマイクロソフトのブログで読んだ記憶があって障害試験の中のカオスエンジニアリングですね一個の手法というかはいはいはい

一応調べていいですかカオスエンジニアリングって確かランダムに障害を起こすんですよねそれによって今のシステムって割といろんなこと起きてもサービス提供し続けられるよねみたいなものをやるんじゃなかったっけなちょっと待ってくださいねザクッとググったぐらいでちょい違うかもしれないですけどやることは似てそうですね一方でテストの目的が異なりそうでなんとなくうん

障害テストは障害に対してシステムがどう動いてそれに対して何をするかこうしたら想定通り元に戻るかみたいなものを検証するものでカオスエンジニアリングはどっちかっていうといろんなことやってみて未知の障害とか予期しない強度を発見してそれでじゃあここ直さなきゃいけないよねみたいなものを見つけるうん

だから動くことを確認するのが障害テストで問題を見つけるのがカオスエンジニアリングではという理解ですが多分ねっていう感じですですね多分そんな感じでした僕が事前にふわっとしてたこととそんなにギャップはないっていう感じですじゃあちょっと実際に障害試験障害テスト

こういうシステムあるんでやってくださいって言われた時何をしたらいいか頑張って障害を起こすなんかネットワークとか遮断してみるまず行動から入るのはなんとなく悪手感あるじゃないですかソフトウェアのプログラミングもそうですけど結構流れがあってどうやってやっていくかというと障害テスト計画っていうのを作ってテストの設計してあと準備して

でテスト実施して結果評価して課題解消してでテスト落ちてたら再実施と再評価みたいなのになってるんですけどなるほどなんでこんなちゃんとやらなきゃいけないかっていうと障害テストって例えばですよネットワークなんとなく落としてみるでその後何がどうなってるかを確認しなきゃいけないじゃないですかうんうん

そのために例えば定常的にリクエスト送り続けておいて落とした瞬間エラー率がこうなりましたみたいな計測しなきゃいけないかもしれないじゃないですかそうするとガトリングみたいなリクエストいっぱい送るツールですねとかを用意しておかなきゃいけないかもしれないしなんなら障害を起こすんで

壊していい環境を用意しなきゃいけないししかも対抗システム込みでテストデータ用意しなきゃいけないかもしれないしそういう調整とかもいろいろ大変なので多分障害テストここからここの日付でやるってこの間触らないでくださいとかやらなきゃいけないしっていうのでだからちょっと結構計画からやらなきゃいけないっていうのがありますなるほど

障害テストってアウトプットとかチームそれぞれかもしれないですけど多分一般的には試験結果表みたいなものがこの工程の一連の作業で最終的に出来上がるんですよその表っていうのはこういうことやったらこういう障害が起きてサービスとしてはこういう影響があるはずこういう予期せぬエラーみたいなのが出るのか瞬断があるけど復旧するのか

復旧手順としてこれをやったら元通りになりますOKNG何月何日に誰々さんがやりましたみたいなこう目標ができるんですけどそれは多分他のテストでも一緒ですねきっと確かになので他のテストと同じ部分は今日はあまり話しませんテスト計画作るとこがちょっと面白かったのでそこを厚めに紹介します何が面白かったかっていうと

どういう観点でテストすべき項目を作っていくのか気になりましたそれこそさっき目的が違うと言ってたカオスエンジニアリングをやって実際にこっちの障害テストの方に入っていくのかなとか思ったりしておりましたそれもあるかもしれないねけどカオスエンジニアリング最初からやるとこってあるんですかねちょっと分かんないですね一歩目じゃないんじゃない分かんないけどサービス運用し始めてから

もうちょっと可用性を上げたいよねこれはやったことなさすぎてよくわかんないので適当なことを言ってるんですけど障害テストどうやってやることを考えていくかテストシナリオを作っていくまでの流れいきますねまずこれは真っさらな状態から作るものじゃないですプログラムのメソッドと一緒で引数があります

引数インプットこれインプット何が軸化になるかというと可用性です基本的には可用性がインプットどのくらい動かなきゃいけないサービスだから障害が起きても自動復旧しなきゃいけないかもしれないし復旧しなくてもいいかもしれないし手動で何分以内手動じゃないか何分以内に復旧しなきゃいけないかもしれないしみたいなのが決まってくるとなのでプロジェクトによるんですけど

よって様々ある可用性ですねまあ何%とか言われますね99.9なのか99.95なのか99.95だと年間4時間ぐらい停止だった気がする99.9だと確か8時間とかだった気がするそれなんか1回のテストでそんなの難くないですか

例えば復旧時間をこれくらいの火曜祭欲しいから30秒以内に復旧させたいってなるとするじゃないですかその30秒が障害年に1回しか発生しないなら大丈夫じゃないですかでも年に100回発生してたらアウトじゃんみたいなことが起きそうな

気がしててすごくいい疑問と指摘だと思ってます僕はそれに対してどうアクションするかはブログ記事には書いてないんですけどこれはもう仮説を持っていくしかないと思いますエンジニアの長年の経験としてこういう種類の障害はこのぐらいの頻度で起きる別にその仮説が外れていたのであれば30秒で復帰する障害が年間例えば

100回起きちゃったから4時間超えちゃったみたいな起きた場合にじゃあこの100回を何回にしなきゃいけないってすごい明確に出るわけじゃないですかその100回を何回にするための対策は考えられるんですよっていう運用した後の指標とか仮説のずれとかあとそれが知見になりますからっていう風に作っていくんだと思いますなるほどね

っていうので可用性がインプットなんですねでもノリさんが言った通りこの可用性満たすためにどうしたらいいかこれはまじ職人技だと思いますこれは難しいですねAWSをクラウドの基盤として使ってるんだったら年間アベラビリティゾーンの障害こんぐらい起きてるよなみたいな感覚値を持っとくべきなんでしょうね本当だったらねそっかその辺は統計あんのかあると思いますあるのかなあると思います

だからそういうニュースを追っておくのも大事なんだなって僕はこの障害テストについて勉強している中で思いました去年こういうでっかい障害あったからここの試験やっとくかみたいなねあー確かにまた分かりやすいのは目標復旧時間っていう概念があってそれが定義されてたら1個障害試験の目安として作りやすいですね確かにこの可用性の検討についてえー

プロジェクトによって大きく異なるのがまあいろいろあるんですけど 基盤のみとアプリケーション全部ひっくるめて定義するのかアプリケーションだけ考えるのか機能ごとに可用性を分けるのかとか 機能ごと機能ごとすごいなそれなんか大事なやつと大事じゃないやつあるじゃないですか多分アプリケーションによるかもしれないですけど 最悪アカウントの名前変えれなくてもいいよねみたいなね

例えば聞いたなら記事書ける機能はキープしたいし見る機能もキープしたいけどプロフィール編集はどうでもいいよねみたいなだからむしろ後ろ側がマイクロサービスアーキテクチャになってるんだとしたら名前変えるAPIだけちょっと雑みたいな雑というかそんなに真面目にクラスター組まないみたいなそういうことがあるかもしれないですね結構コストに跳ね返ってくると思うんで

という形で初期条件で可用性を整理したりしなきゃいけないです場合によっては整理されていない場合もあるのであなた障害テストやってって言われた人が気づいてこれちょっと整理したいんですって動きをしなきゃいけないですねしんどいですねなるほどねじゃあインプット可用性ありましたなった時に次何を考えるかというと品質コストスケジュールQCDを考慮してどのくらいちゃんとやるかを定義します

クオリティコンテンツデリバリー惜しい惜しいかな言ったけどな確かに英語になってなかったギリギリかな言ってたと思うよクオリティコストデリバリーですね惜しいさっきコストって多分言ってたよコンテンツって言ったのかこれ要するにどういうことかっていうと真面目に100%テストするのが一番いいんですけど

そんなコストとかスケジュール的に無理なことあるじゃないですかだからやらなくて良さそうっていうリスクが低いものは除くことも検討すべきというか大抵の場合そうなんじゃないかなリスクが低いものは多分やらないんでしょうねリスクが低いの判断難しいですねリスクってなんだろうね経済的なリスクもあれば信用系のリスクもあるしあとなんだこのフィンタンの記事では

発生リスクが高い障害リカバリが困難な障害影響範囲が大きい障害これらを選んでいきましょうねと言ってますなるほど確かにこういうのを中心に選択して100%やるんじゃなくて大事そうなとこだけやっていくとあとは外部システムの障害を含めるかどうかはここも要検討事項ですねプロジェクトによるというか

向こうは向こうでやってるはずですし確かにやった上でこういう500が返ってくるんだったらね500が返ってきてそういう時はちゃんと予期せぬエラーが発生しましたって出るみたいなのはひょっとしたらアプリケーションのテストで打ち取ってるかもしれないですねそこで打ち取りたいですよねっていうので全てやる上でじゃあうちのプロジェクトではめっちゃ大事そうなやつだけやりますえーなんだろう

動かなくてもそんなに困らないやつに関しては1シナリオだけやりますみたいなというような形でQCDに伴う網羅性はい決めましたとはい可用性こんぐらいで網羅性こんぐらいで決めましたよしじゃあ障害テスト考えていこうと障害テストですね障害っていろんなレイヤーで発生するんですよね確かにいろんなレイヤー例えば何でしょうじゅんぺんさんアプリケーションレイヤーはい

インフラレイヤーインターネットレイヤーみたいなありません?ネットワークレイヤーみたいな多分出せば無限で無限ではないか無限ではないんですけどあとはOSとかVMとか仮想マシンあとはハードウェアインフラとはちょっと違う埃詰まっちゃったみたいなね

なるほどあとはSaaSAWSの障害とか実際にテスト対象のシステムにもよるんですけどいろんなレイヤーがありますそう考えるとやっぱクラウド使ってると楽だなって思いますね確かにSaaSのレイヤーというかクラウドのレイヤーのテストは1個やれば進みますからねうんうんうん

まあっていうのでまあいろんなレイヤーでいろんなレイヤーごとに起きる障害を切り分けてある程度羅列した上でさっきの影響でかいとか発生リスク高いとかリカバリ困難のどれかなっていう考慮で考慮しながらやるシナリオを決めていきますレイヤーごとに切り分けてっていうのは常識かもしれないですけどあーなるほどなーって思いました割となんか今まで僕やってきた障害試験って

ライトのやつしかやってなかったんでポックのアプリしかやってなかったからDB落ちた時とかザクッとDB落としてみてこうなるねよしよしみたいなのしかやってこなかったんで

こういうレイヤーを切り分けた上でみたいなのはあまり考慮できなかったからすごく学びになりましたねこの試験の時にアプリケーションレイヤーの何かみたいなのもやるんですかやりますやりますアプリケーションレイヤーで何かが起きた時めっちゃ分かりやすいんだったらなんだろうな例えばアプリケーションレイヤーって言ってしまっていいのか微妙かもしれないですけどKubernetesで言うとポッと落ちたらとかそれはアプリケーションなのかまあなんて言うんでしょう相度分け方によりますけど

インクラネットワークかアプリかみたいなレイヤーだとエンジンXもアプリになるしポットマイアアプリになるそういうことかミドルウェアレイヤーなのかめっちゃ細かく言うとなるほど本当のアプリだとなんでしょうねフィンタンさんの定義する障害テストで言うと例えば対抗システムDBがタイムアウトした時とかかな

そこもアプリケーションレイヤーになるのか一方コードのテストじゃチェックできないよねって感じかそうだと思いますゴニョゴニョすればできそうですけどねモックしてタイムアウト書き換えてとかゴニョゴニョすればできるかもしれないですけど例えばですねいろんなレイヤーで発生するねとかあとは可用性要件で障害テストだからなんて言うんでしょう

こういう障害が起きたらこうなるよねっていう期待する動きみたいなのがあるわけじゃないですかその期待する動きを定義するとかね何秒以内に復旧するとかこの辺は可用性に紐づいてそれぞれ頑張って定義していくでその上でどういうものを確認していくかで言うとトラフィックの量が変わってないかとかレンティングしないかとかトラフィックの量ってのはどこで計測するんですか

例えばフロントのアプリだと難しいかもしれないんですけどAPIを公開しているのを想定して100リクエストパーセカンドを処理できなきゃいけないみたいな要件があった時に定常的には30ぐらい来るよねみたいな30ぐらいずっと処理しなきゃいけない

世なみたいなものを障害試験のシナリオで定義したときになんか裏側の何かが落ちてもその処理数が変わらないかをガトリングで秒間30リクエスト送り続けてガトリングのログ見て30個ログが残ってるねみたいななるほどそういうのを見る例えばインスタンス1個落ちた状態でそれもできるかみたいなインスタンス1個落ちてそのインスタンスがもう1回起きてくる

間その30の処理ができるかとかあとは多分何かが落ちると30分の5ぐらいはエラーになるはず例えばねその失敗リクエスト30分の5だと0.1660.167違う1.671.67

エラー率1.6716.7エラー率16.716.7以下かなみたいなとかを見たりしますねCPU使用率も見るかもしれないですけどこんな感じで障害テストの観点を整理していきますちょっとおさらいするとどんなレイヤーで障害が起きるかなバーってラレットしますこの中で大事そうなやつこれだねって選択したやつに対して

どうなるべきかその障害が起きた後にどうなるべきかを可用性の要件とかでN分以内に復旧することとかあとは復旧した上でエラー率何倍かとかレイテンシーどんぐらいとかそういう確認項目を定義していくみたいなのが障害試験のシナリオ作りになりますねだからちょっと具合というか考え方は割とアプリケーションのテストとはちょっと違う感じしませんか

広い知識が必要というかアプリケーションテストってなんだろうねAPIもそうですしフロントもそうですけど結局設計書通りになってるか見るだけじゃないですかユニットテストとかではなくてE2Eテストとかあとは結合テストかそういうレイヤーだと割と設計書通りになってるか見るぐらいだと思うんですけど障害テストはもっと流動的な職人技が挟まる感じで

こういうケースの時はこれを見るべきだなみたいな職人の感と経験に基づいた確認項目を頑張って年出して試験項目を作っていく必要がありそうだなと思うのでお願いします確かにテストだと仕様が丸抜で簡単に判断できるけどそういうのってここまでできたらこれ担保できるよねみたいなところから自分で考えてそのレンジに収まってるかどうかをチェックしなきゃいけないってことですもんねそうそうそうそうそうそう

それをハックしなきゃいけないんですよね結構今まで難しい話をしてきたと思うんですけどこれって僕これを専門として生きていきたいという気持ちは全くないんですけど面白みをちょっと感じたんですね勉強している中でCTFやっている気分になるというかキャッチザフラッグセキュリティの脆弱性を見つけて点数を取っていくコンテストこのアーキテクチャだとここ弱そうだなみたいなものを頑張って見つけて

良かったもしくはダメやんけっていうのを試していくのが障害テストだなと僕は思ったんでその面白さを伝えるべくパワー例えを持ってきましたパワー例えこの例えを聞くとさっき僕が言った難しい障害テスト方針の話が直感的に理解できるようになるんじゃないかなということで例え話していきますで

攻めるんで結構ダメそうだったら言ってくださいわかりました言ってください障害テストやっていくんですけど思い浮かべてほしいのがひまプロパークって言うやつですねひまプロパークいいですねひまプロパークこれ日本を代表するテーマパークで365日営業になってますうん

ヒマピーハイランドの方がいいかもしれないヒマプロパークですヒマプロハイランドヒマプロパークです営業時間は営業してないんですけど営業してない時間もメンテナンスやら清掃やら色々あるんで結局24時間超えてますうんうん

じゅんぺいマウスはいるんですかじゅんぺいマウスはいないですただひまわりパークすごいでっかいんでいろんなところですごい安定したサービスの提供を求められていますそれゆえ全部話すと大変なことになるので1章について1章1つの章について考えていきますまさかの章ジャンピング耳機っていう

ごめんなさいミミックですかヒマプロランダーなんでウサギとキツネとカエルのキャラクターがいるんですけどなるほどウサギのキャラクターですね今回ミミッキーという名前になってますミミックかと思ったウサギがひたすらジャンプをするっていうショー目玉ですね観客一体となってみんなジャンプするんでフェスのような一体感を楽しめるというのが

非常に人気のショーになっています確かに結構高くジャンプしそうですねこれどんな構成になっているかというと音響さんとかステージとかいろいろある中でもキャラクターは3匹出てくるしダンサーさんも3人いるよと6人でやるショーになっていますなるほどキャラクター3人とダンサー3人いるんですねそうですこのショーを365日営業の中でうまく回していきたいと

ここからが障害試験の話になってきますこの安定的な章をあなたは提供しなければいけませんそのQA障害試験をしなきゃなと思った時にまず可用性これインプットになってくるので整理していきます可用性はですね1日4回章をやって365日1日4回やります一方で

年間4回分くらいはお休みしてもいいかなみたいな何かしらのアクションとねこれ数字にすると火曜星99.7%なんですけどこれは説明のためにある数字ですただただし火災とか大規模災害とかがあったときは直ちにショーを中止して避難誘導を実施するとこちらの今回のジャンピングミミッキーの火曜星になってます火曜星整理しました次やること

QCDを踏まえた網羅性に関する方針の定義ですねこれやっぱり無限にできないのとあと人間は使うんでちゃんとやるとかないですとなのである程度やれればOKですしこれもポッドキャストなんで面白い範囲でやれればいいなと思ってます

ショーが盛り上げればOKってことですかショーというよりはエピソードが盛り上がればいいなという範囲で障害テストのシナリオを考えればいいなと思っています本当だったらちゃんとこういう風な方針でいきますって言って関係している人の合意を得た上で進めていくのがせいですね今回は面白いわけはOKです次障害テストの観点これあれですね各レイヤーでどんな障害が起きるかまず一旦

考えてみましょうレイヤーなんですけどネットワークインフラアプリみたいなレイヤーで3つに分けてみようかなと思ってますこれは僕の特段と偏見でネットワークこれ多分音声さんとダンサーさんキャラクターの間で何かしらの無線があって3219みたいなやりとりがあるのではと想像しています通信ができなくなるとか

あとは音声流した時にスピーカーから音が流れないとかそういうのがネットワークレイヤーではありそうだなとか想像できますね次インクラレイヤーはステージセットスピーカーとかライトとか壊れるあとは火事とか災害とかみたいな感じですね多分会場そのもの会場そのものぶっ壊れる系はい

次アプリケーションレイヤーアプリケーションレイヤーはダンサーさんが体調不良になるとか振り付け間違えるとかあと何でしょうね狂人が乗り込んでくるとかとかねやべえやつ来るとかねこういうのが想像できます洗い出しが終わった上で多分100%やっても

障害試験大変だし効率も悪いのでやるべき障害ケースを選んでいきますどういうケースで選んでいくかというと発生リスクが高いものリカバリーが困難なもの影響範囲が大きいものになりますね発生リスクが高い障害これだったら多分ねダンサーが体調不良になるとかこれ発生リスクありそうですねあとは機材トラブル系機材トラブルもありそうダンサーさんもしゃべりながらジャンピングするんでね

マイクバッテリー終わるとか不良があったりとかするかもしれないとかあとは何でしょうねステージやセットが壊れるはね多分あんまないと思います多分ね確かに強靭が乗り込んでくるのはあんまないですねあんまない別のサービスで打ち取ってほしいところですねそこはねエントランスの方でね確かにね警備員

あとは発生率が高いのはリカバリが困難なやつこれちょっとあまり事前に考えてて思いつかなかったんですけど例えばダンサーが一人どころじゃないぐらい全員体調不良になってリカバリが効かないケース復旧困難ですねこういうのも実際のシステムだとめっちゃレアケースだと思うんですけど2リージョン同時崩壊みたいなねまあまあそうね

そういうケース一旦考えますあとは影響範囲が大きいこれもまあむずいんですけど大きい災害が起きたらとか不発弾見つかったとか大きいなそれもねそういうものを想定してエラーケースを障害ケースを考えてみましたここからですね実際に障害試験のシナリオを考えていきます例えば

ダンサーに体調不良者が出たこれどうなるべきか多分誰か代わりに出れる人いないみたいなECSというかコンテナオーケストレーションサービス的なものであるタスクが一個死んだら別のタスク立ち上がらせるみたいなそういう操作が必要ですねもしくは

3-3というバランスを崩す崩すと言いますとダンサーは2人でもいいかみたいななるほどなるほどキャラは3人いないとあれだけどダンサーは2人でもいいかみたいな確かに確かにそれもいいですねその理論で言ったらキャラクターの中1人ダメになってもねダンサーからシフトすればいいみたいな教育しとけばいいかもしれない振り付けを同じにしておくみたいなそういう訓練ねっていうシナリオが思いつきましたはい

このシナリオをやるには実際のステージングひまプロパークひまプロパークの隣にはあるんですけどステージングひまプロパークステージング環境あるんですねなるほどこれもちょっとプロジェクトによりますねプロダクション環境でやる場合もありますねサービスメンテと称して一時的にお客さんを入れずプロダクション環境で実際になんだろうな

じゃあ明日プロダクション環境でのダンスショーの訓練なので皆さん遅れずに来てくださいって言った上で前日にダンサーの一人を体調不良にさせるっていう障害試験ができますね本当はなってないけど本当に体調不良にさせます神の力で毒の力じゃなくてもしくは牡蠣とかめっちゃ食わせます体調悪いときはね崩せるらしいですからねオイスターバーに連れて行きますねはしご昼から夜まで

結構あれですね運任せな運任せないことするんだよ一回またったことないけどあとはしこ玉飲ませるとかねそれは効くねグロッキーで来る可能性もあるから仕事だからそれは体調不良ですからねあとは怪我人としてグーでバンってやるかもしれないですね後ろから夜道遅いパターン復旧困難だな困難ですねそれは

あとは機材トラブルもありますよ本番直前にダンサーさんが使うマイクにちょっと塩水かけとかね音響大激怒ですよね電池抜いとくだけでいいじゃんバレちゃうかもしかして電池切れてる電池入れるかもシンプルにねみたいな感じで障害試験するときは私は神だっていう気持ちで障害を注入して

ほうほうちゃんとこいつら代わりのダンサー用意するじゃないかよしよしOKみたいな感じで障害テストやっていくと計画から何から全て楽しいんじゃないかなと実際にテーマパークでテストしようってなったらそうやるしかないのかこっそりそれを拡散するしかないのかそうですね実際そうやってんじゃないですか多分やってんの?体調不良に関しては柿壊すとかやってないと思うんですけど

でもいなくなった時のオペレーションちゃんとできるかとかやってんじゃないですか確かにマイクの替えを用意しておくとか清掃員に踊れる人を配置しておくとかそこまでそこまでってか分かんないですけどねたまにSNSのショート動画とかでありません?あるかもしれない清掃員っぽい人が踊ってるみたいなやつあるかもしれないあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるあるるあるる

あれ実はその人なんじゃないですか障害対応用の障害対応用のスタンバイインスタンスなんじゃないですかなるほどな別リージョンになる別ロールのそうかもしれないっていう風なものをちょっと想像すると障害テスト楽しいなっていうので障害試験楽しい人もいるというか

楽しいって言ってる人いたんだチームにもシナリオを考えるのはやるのは楽しくないし方針考えるのも楽しくないけど実際のシナリオを考えるのは楽しいあーまあ確かにねこうやったらいけるかみたいなしかもなんか想像通りになったら締め締めって思いません?普通にアプリケーションがあったとしてえーなんだろうなDBズドンって落ちましたってなった時にちゃんと別リージョンに切り替わるかみたいな

ドキドキじゃないですか確かに切り替わった時嬉しいなちゃんとデータの保存期間というか切り戻しもちゃんとできてて締めって思うと思うこう思うと障害テストちょっと

何?新銀行枠かなと思って無理やり例えてみましたが全然体系的なドキュメントがなくて僕はすごい戸惑ってるんでもしちょっとこれ見るといいよみたいなのがあれば教えていただけるとありがたいですそしてフィンタンのブログというかTISインテックグループの有志な技術者さんの皆さんにはすごく感謝してますうんうん

すっごいちゃんとしたドキュメントなんですけどいいね9件しかなかったんで10件目押しておきましょう聞いたなんですかそれいや金単独自メディアやってるのか独自メディアの自分でいいねキーワードつけてるのかマジでiPadのドキュメントかと思ったもんちゃんとしすぎてそうなんだおー

それはすごいな生涯テストを紹介してみましたのでなんとなくわかったかなテスト項目見つけるの僕難しいなって思っちゃいました経験ですかね経験だねこれは

あと僕の会社のチームの人がいてなるほどなと思ったのは構成図ありきなんです障害試験考えながらってなるほど構成図がある状態でどの点を落とすかどの線を切るか分かりやすいかもしれないこれを考えるだけ分かりやすいなるほど分かりやすいなるほど確かにと思いました勉強になります確かにただその点落とすのは

QCDの観点でどうなんだろうみたいなQCDって言ってるのは障害テストやるリソースが限られる中でこのテストやるべきかはまじ職人芸ですねさっき言った発生頻度と影響とリカバリが困難かこの観点でやるべきかやらないべきかを決めていくというお話でしたなるほど

非常に厳しいです厳しいというか難しい世界ではあるんですけどちゃんと人にめっちゃ使われるサービスを作る上で大事な工程なので勉強になりましたって感じですミッションクリティカルのやつだと余計にそうですよねそう思いますこういうのってアジャイル開発とかやっていく上でどの工程でどうやってやっていくのかどっかのスプリントでやるのか

どっかのスプリントでやるんだなきっとななんかそうですよね事前に用意しておけたらいいですけど実際顧客で障害起きてこういうのやっとかなきゃだったなっていうので手順書整理してっていう現場の感じですよね100%は絶対無理だからねでも経験ある人はねそういう確率は減らせるからね絶対ねっていう感じです

ちょっと最後に余談を話しても締めるんですけど余談全然関係ない話なんですが関係なくないかこのエピソードを作る上でチャットGPTにもいろいろヒントをいただきながらミミッキーの命名とかはGPTなんで僕のせいじゃないんですけどせい僕のせいじゃないんですけど障害の中で発生頻度が高い障害をちょっとGPTに考えてもらっている中で

これはないやろって思ったのがあったんで紹介するんですけど主役キャラクターの衣装や着ぐるみが大破してしまいすぐに修復できないいやあるかもよ大破ってないアルバイトにとんでもないやつが混ざってて衣装をズタズタにしてしまったみたいな狂人のおやぎが狂人のおやぎバックでバックというかなんだ

控室みたいなところで衣装をズタズタにされるってことかたまにないですかそういうアニメでちょっといじめっぽいシーンみたいな名探偵コナンで見たことがある気がしないでもないありそうだよねなるほどね大破って言われると急に爆発したみたいな爆散したみたいな感じになっちゃうけど来てたらなるほど確かに妬みから本当はあのポジション私の場所だったのにみたいな

そうそうそうそういうこと実は一緒に踊ってるダンサーが犯人だった困難でありそう耳機の衣装がね急にジャンプしてる途中に爆散するバーントリックですね面白い単発で終わるやつ単発で終わるやつそれは壮大なトリックがあるやつ

っていうのとかはあるかもしれない想像するとおもろいっすね大事故ですもんねそうだよ着てる側はもうやばいよとりあえず全員パークから出す必要ありますからあるねあるわ爆発物があるみたいだねそうだよね爆発して頭だけ残っても体おじさんになってる中の人どうなってるんですかね普通ごと行きそうですよねそうだよねあー面白い

風船太郎みたいな風船太郎懐かしい風船太郎って分かります?分からない風船に入ってるおっちゃんなんですけど荒引き団っていう昔やってた番組の芸人それは分かるんだ荒引き団って言えば風船太郎みたいなとこない?荒引き団見てないから分かんない深夜ですよね風船太郎パーンって風船したらおじさんの子じゃんあれと一緒ですよねそうそうはい

今日は障害テストの話でした終わりますありがとうございますハッシュタグひまじんプログラマーでSNSでフィードバック募集してますので今日のお話の感想とかあとはこれ見るといいよみたいなのがありましたらぜひシェアお願いしますアラピキタン見るといいよってことですかそれでもいいよありがとうございますポッドキャスト説明欄からGoogleフォームで番組への感想要望質問何でもお待ちしてますのでお願いしますお願いします

あとは各種ポッドキャストプラットフォームでの高評価フォローお待ちしてますのでこちらもお願いしますお願いします呼んでおりますはいではまた次回バイバイバイバイある夜ねいつものようにラジオのお便りのチェックをしていたんですよそしたらね夜なのにねお便りの通知がねポーンってなってねこんな時間におかしいなあおかしいなあおかしいなあと思ってリスナーも寝てる時間なのになあって思ってメールフォルダー上げたらねうわああああ

番組では叫ぼうほどたくさんのお便りをお待ちしております