毎朝5分の自分語り 2023/12/25
金曜日に打ち合わせがあった。
監視の閾値を1つだけ変更するというものだ。
たった1つだがタフな打ち合わせだった。
①バックエンドを変更しない
②フロントエンドも変更しない
③今出ているエラーは抑止したい
④本来検出したいエラーは検出したい
これらを矛盾せずに成立する閾値に変えるということだ。
①②は年末に向かっての工数不足で実現が出来ない。
だが、この閾値反映は年末年始に連絡を受けたくないので早く適用したい。
③④が矛盾になりやすい。
ここが要注意ポイントだ。
連絡を受けたくないので③の実現に偏りがちだ。
だが④が疎かになるとそもそも何のために監視しているのか分からない。
監視対象のエラーは本当に検出しないといけないものとそうでないものの区別が付かない。
区別するためにはバージョンアップしなければならないが、諸事情でそれは出来ない。
同じ監視に混ざっているエラーをひとつひとつひとつ紐解き、ユーザー影響をひとつひとつ確認してなんとか③と④の矛盾しない閾値を導き出すことができた。
設計者はおそらくこんなにチェックを受けるものだとは思わなかっただろう。
たったひとつの閾値でもこれだけの設計的な検討が必要になる。
監視運用やログの設計はお座なりになりがちだ。
だいたい最後のおまけくらいという意識だ。
こういうしっぺ返しをくうことになる。
開発者にとっては新機能開発→バグの修正→あとはリリースのみ、なんとか息絶え絶えになって終わろうとする時に、さらに追い討ちという感じだろう。
例えるなら
水の中に1分しか潜ってられない男が、限界1分目にやっと水面で呼吸しようとした瞬間！
グイイ！！
とさらに足をつかまれて水中に引きひきずり込まれる気分に似ている。
この記事が気に入ったらサポートをしてみませんか？