第3回 Chaos Engieering 読書会@リモートのログ
引き続き Discord によるオンライン開催。
合計 300 ページくらいのところを毎回 30 ページくらい進んでるので、全部で 10 回くらいになるのかなぁ。
次回は 7/18(土曜日)です。
- 対象
- トピック
- ディスカッション
対象
4. Slack’s Disasterpiece Theater
のGetting Management Buy-in
から
トピック
- 最近は face to face の大切さを実感してる
- いいマイク買った! (RODE NT-USB Mini)
- 40 秒で構築できる仕事環境を準備した
- 大ニュース! AdoptOpenJDK が Eclipse Foundation に移管される
ディスカッション
4. Slack’s Disasterpiece Theater
Getting Management Buy-in
- "buy-in" ってなんだろう
- BUY-IN | meaning in the Cambridge English Dictionary
the fact of agreeing with and accepting something that someone suggests:
- 同意を得るとかそういう意味かな
Impossibility Result
- 設定変更を司るサービスを停止しても本体機能には何も影響しないと期待していた
- 実際は本体機能の設定変更 API をつついたら応答が返ってこなかった
- 本体は設定変更ができないときはエマージェンシーモードで動くようになっていたけど、通常モードのときと同じく Slack Channel に投稿して何かを待機する状態になっていた
- こちらはタイムアウト時間が設定されていなかった
- ということで設定の不整合があるのは残念な結果だった、ということかなと
そのほか
この文章書いたの誰だっけ
結構前から仕事でも Slack 使ってるけどときどき意味不明なエラーが起きることがあった
- もしかして実験してたのかな
- 人によって問題に対する感度が違うような気もする
5. Google DiRT: Disaster Recovery Testing
LEGENDS: テックリードが休暇に入るとコード検索が途切れる
- あるあるすぎて辛い
The Rules of Engagement
- 絶対に本番環境でやるぞ、という強い意志を感じる
- それぞれは納得感あるけど実際にどう判断するのか難しそう
- 知らされている人の範囲が気になる
- 「知ってる」場合と「知らない」場合では決定的に異なる行動をする場合があるよね
- 頭では分かっていてもできないことはあるので (実体験)
- インシデントコマンダー的なやつですかね
What to Test
- 項目の粒度がばらばらなのが気になる
- 分散サービスだとバックアップからのリストアがとてもややこしい問題になりそう
- Kafka のバックアップについて
- 伝統的には別々の SAN を用意するんだけどできない
- バックアップクラスタを用意するのが無難
- 結果整合性に基づくシステムではどこにバックアップの断面を設定することになるのか
- サーガしてるならその辺でどうにかする
- Event Sourcing してるならメッセージングブローカーでどうにかする
- 孤立したそれぞれのリージョナルネットワークで発生したトランザクションを同期するのは難しそう
- それぞれの水準でどこまで何を保証するのか設計しないといけないね
How to Test
- かなり影響を気にしながらやっているんだなという雰囲気
全体
- この水準の取り組みができる会社はそれなりにあると思った派と、この水準の取り組みができてるのが恐ろしいと思った派の会話
lottery factor
はトラックナンバー
やバスファクター
より配慮されたフレーズだなと思った- 流行って欲しい
Scope of Tests at Google / Conclusion
Borg のケーススタディで言いたいこと
- ユーザーはタスクがエビクションされないことに慣れきっている
- それでは信頼性のあるタスクを開発できない
- 強制的にエビクションする実験をすればどういうふうに対応したらいいか学んでくれるはずだ
嫌なことを頑張る印象があったけど、前向きに取り組むような記述に感動した
Microsoft Variation and Prioritization of Experiments
Varying real-world events in Chaos Engineering is exactly what we’re concerned about here.
の解釈カオスエンジニアリングでは多様な現実世界の事象こそが,ここでの私たちの関心事です。
のほうが妥当かなと
参考: カオス原則
実世界の事象は多様である
カオス変数は実世界の事象を反映します。潜在的な影響または推定頻度のいずれかで事象の優先順位付けを行います。サーバーが落ちているようなハードウェア障害、不正な応答のようなソフトウェア障害、トラフィックやスケーリングイベントの急増など障害ではない事象に対応する事象を考えましょう。定常状態を破壊することができる事象は、カオス実験において潜在的な変数となります。