こう
- 「監視では
何を 見て、 どんな ときに 警報を 出しますか」 - 「CPU の
使い方が 80% を 超えたら 警報、 で十分ですか」 (裏から聞く形) - 「夜中に
何度も 警報が 鳴って、 みんなが 見なくなりました。 どうしますか」
面接官が
- 何を
見るかを、 決まった 型 (4 つの ゴールデンシグナル) で言えるか - 原因ではなく、
利用者に 出ている 症状で 人を 呼ぶ、 と分かっているか - 鳴りすぎると
誰も 見なくなる、という 運用の 現実を 知っているか
短い答え
- 遅さ (レイテンシ)、
量 (トラフィック)、 エラー、 どれだけ埋まっているか (サチュレーション) の 4 つを 見ます。 4 つの ゴールデンシグナルと 呼ばれる型です。 - 人を
呼ぶ警報は、 利用者に 影響が 出ていて、 人が 判断して 動く 必要が ある 物だけに 絞ります。 鳴りすぎると、 本当に 大事な 警報まで 見られなくなるからです。 - 「どれだけの
要求が、 どれくらいの 速さで 成功すれば よいか」という 目標 (SLO) を 数字で 置き、 それを 外れそうな ときに 鳴らします。
少し
4 つの
Google の SRE の
- レイテンシ (遅さ) 要求に
答えるまでの 時間です。 平均だけでなく、 遅い ほうの 人 (上から 数 % の 人) が どれだけ 待っているかも 見ます。 失敗した 要求の 速さは、 成功した 要求と 分けて見ます - トラフィック (量) 1 秒あたりの
要求の 数など、 どれだけ 使われているかです - エラー失敗した
要求の 割合です。 500 番台の 応答だけでなく、 200 で 返したのに 中身が 間違っている 物も 含めて考えます - サチュレーション (埋まり具合) CPU、
メモリ、 DB の 接続、 キューの 長さなど、 限界まで どれだけ 近いかです
目標を
SLI は
SLI 成功した要求のうち、1 秒以内に返った割合
SLO 30 日の間で 99.9% 以上目標を
何で
人を
症状だけで
話すときは、
よく
- CPU や
メモリの 数字だけで人を呼ぶ 利用者に 影響が 無い山でも 鳴り、 だんだん 誰も 見なくなります - 平均の
遅さだけを見る 平均が 速くても、 一部の 人は とても 待っている ことがあります。 遅い ほうの 人の 時間も見ます - 鳴った
警報に、 する ことが 書いていない 夜中に 起きた 人が 何を すれば よいか 分かりません。 手順を 付けるか、 要らない 警報なら消します
深掘りの問い
- 「ログ、
メトリクス、 トレースは 何が 違いますか」 ログは 出来事の 記録、 メトリクスは 数の 時系列、 トレースは 1 つの 要求が 通った 道筋、と答えます - 「外から
見る 監視は 要りますか」中の 数字が 正常でも、 DNS や 証明書の 不具合で 外から 開けない ことがあるので、 利用者と 同じ道で 外から 確かめる、と答えます - 「警報が
鳴りすぎる ときは、 どう 減らしますか」 鳴った 警報を 振り返り、 動かずに 済んだ物は 消すか 日々の 報告に 移し、 同じ 原因の 警報は まとめる、と答えます