仮説・計測・結論をそれぞれ別の時点で残す
一言でいうと
実験の成果物は、故障ではなくノートです。仮説・測定・結論の3つが互いに合っているときだけ、そのノートが役に立ちます。
なぜ必要なのか
障害を注入すること自体は、難しくありません。コマンド1行で済みます。難しいのは、翌週にも残る何かを作ることです。実験が終わると、人の記憶は驚くほど早くぼやけ、方向まで変わります。成功率が76%だったのを「ほとんど全部失敗していましたよね」と記憶し、逆に、はっきり失敗した実験を「あのときもよく耐えたような気がするんですが」と記憶します。そのため、実験は、3つの部品をそれぞれ別の時点で文章に残します。
どう動くのか
1つ目、仮説は壊す前に書きます。あとで書けば、それは仮説ではなく、結果の要約です。人は結果を見たあとは、「そうなると思っていた」という感覚を、実際の予測と区別できません。そのため、順序そのものが方法の一部です。仮説には、何が起きるかだけでなく、なぜそう予想するかといつ止めるかも一緒に書きます。
2つ目、測定は実験ウィンドウの中で行います。障害を起こしたあとに別に測ると、すでに復旧が始まったあとの数字を測ることになります。先に負荷をかけておき、そのウィンドウの中で障害を起こし、ウィンドウが閉じたあとで結果を読む順序である必要があります。
3つ目、結論は、仮説と測定を突き合わせた結果です。ここで、最も重要なルールが1つあります。反証された仮説は、失敗ではありません。むしろ、予想と違う結果こそ、その実験が稼げる最も高価な情報です。「レプリカを3つに増やせば、リクエストは1つも壊れないだろう」と書いたのに、実際には数件が壊れたなら、その日学んだことは、「レプリカ数だけでは足りない」という事実です。結論にconfirmedだけが書かれている実験ノートは、たいてい、仮説をあとから書いたという意味です。
실험 한 건의 최소 구성
가설 availability: ok / latency: slower + 왜 + 중단 조건
측정 성공률 0.993 · p95 291ms (기준선 33ms)
결론 관측 ok / slower → 가설과 같음 → confirmed + 무엇을 바꿀 것인가
この3つの部品を、それぞれ別のファイルに残すことも、方法の一部です。1つのファイルに書き足し続けると、仮説がいつ書かれたのか、どの数字がどの実験のものなのかが、すぐにぼやけます。仮説のファイルは、実験が始まったあとは触らず、測定のファイルは、ツールがその瞬間のクラスターと一緒にまるごと書き、結論のファイルは、一番最後に別に作ります。あとで誰かがこのノートを読むときに、「この文がいつ書かれたか」をファイル単位で答えられることが、信頼の大半です。
数字に名前を付けるルールも、あらかじめ決めておきます。成功率0.993が「問題なし」なのか「悪化」なのかは、人によって読み方が違うからです。このコースのラボは、成功率0.98以上をok、0.5以上をdegraded、それ未満をdownと呼び、レイテンシは、ベースラインp95の2倍以上ならslowerと呼びます。ルールが先にあれば、結論が言い争いになりません。
現場での姿
実験ノートには、限界も一緒に書く必要があります。このラボで、観測ファイルはツールが作りますが、そのファイルは、結局VMの中の編集可能なテキストです。そのため、採点は数字だけを見ず、クラスターに実際に残った痕跡、つまりデプロイのたびに新しく生まれるReplicaSetと、今生きているPodも、一緒に見ます。数字はでっち上げられても、行っていないデプロイが残したReplicaSetは、でっち上げられないからです。現場でも同じです。報告書の数字は、常に再確認できる経路と一緒に書いておく必要があります。
ノートの最後の欄は、「では何を変えるのか」です。この欄が空なら、実験は見せ物で終わります。変えるものは、コードかもしれず、設定かもしれませんが、「アラートの基準を、レイテンシ側にもう1つ作る」のように、運用手順であることも多いです。特に、成功率は問題ないのに、レイテンシだけが悪くなる種類の事件は、既存のアラートにまったく引っかからないので、実験でそれを確認したなら、その場でアラートをもう1つ作ることが、適切なフォローアップです。5回の実験から5つの異なる決定が出るのが理想で、5つの欄に同じ文が書かれているなら、たいてい実験を1つしかしていません。
そして、実験が終わったら、必ず元どおりに、あるいは学んだことを反映した、より良い設計に戻します。戻していない実験は、次の人に、ただの故障として引き継がれます。動いているPodをのぞく方法を身につけておくと、復旧直後の確認も速くなります。
ノートが溜まったら、次の段階は自動化です。手で行っていた実験を、決まった時刻に実行し、定常状態から外れたら、自分で止まるようにすることですが、その出発点は、常に手で1回やってみた実験1つです。人が読めるノートが先にあって初めて、そのノートを機械が書き直せます。
次のラボですること
本物のk3sの上で、5回の実験を行います。正常なベースラインを測り、5つの実験の仮説をまとめて書いたあと、Podを殺し、CPUを絞り、メモリを干上がらせます。最後に、学んだことを反映して設計を直し、同じ攻撃をもう一度受けます。