まえの話の続き。

アプリにデバッグ用の UI を入れる狙いを広く捉えると、これは observability の改善だと言える。Observability, ソフトウェアの状態を外から見えるようにすること。場合によっては状態をいじれること。

Monitoring なんかは observability の一部と言える。ただしここでは主に対話的な observability, つまりデバッグ UI みたいなものを念頭に置いている。対話的な observability の実装に限っても色々な形がありうる。デバッグ用の dashboard かもしれないし、HUD 風の overlay かもしれないし、気の利いたCLI かもしれないし、何らかの shell かもしれない。

Observability の高さはそのチームやインフラの maturity を示す良い指標の一つだと思う。Maturity の高いインフラは低レイヤでプラットホーム寄りの observability が高い。Maturity が高いチームのソフトウェアはドメイン寄りの observability が高い。両方の水準が高いとインフラがアプリレベルの observability を高める仕組みを用意しつつアプリがきちんとそれを使いこなし、プラットホームレベルの指標とドメインがむすびついて見える。たとえば各 HTTP リクエストにタグをつけられるインフラがあり、アプリは機能を表すタグをつける。すると dashboard で機能毎の aggregation が見える、など。

今はオープンソース経由でインフラがどんどん進化しているから、インフラレベルの observability はちゃんとツールを持ってきて 使おうというだけの話かもしれない。たとえば API のクリーンさで新しいライブラリを選んだら observability がいまいち、みたいなパターンもある。逆にいうとライブラリやツールは observability で差別化することができるとも言える。React Debugger や Spark の History Server が良い例。

そしてアプリケーションレベルでの observability は未だに各プログラマやチームに委ねられている。結果として出来の良さにはばらつきがある。

Observability をがんばる価値は、一見するとそれほど自明でない。余計な仕事に感じるし、ソフトウェアのサイズが大きくなったり、ちょっと遅くなったりする。なにより observability のためのコードは多くが instrusive で見苦しい。何を observable にすべきかもアプリ次第ではっきりしない。これはかつての testability に似たところがある。テストは余計な仕事に思えるし、コードが複雑に、場合によっては少し遅くなる。けれど各種宣伝活動が実って人々は説得され、今は testability のコストに文句を言う人は少なくなった。

たぶん observability についても誰かが頑張ってアイデアを整理し、啓蒙する必要があるのだろう。どんな風に整理されるべきなのだろうね。自分はまだ考えが足りない。無念。