システム運用アンチパターン読んで思ったことメモ
システム運用アンチパターン読んだ。
あまりゆっくり時間とれなくて結構時間かけて少しづつ読んだのでもう忘れてるところもあったり、ちょっとうまく読み取れなかったところもあったりして間違った理解あるかもだが、印象に残った部分だけ書いてみる。
何が目的なのかを見失わないようにする
いくつかエピソードがあったが「何が目的なのかを見失わないようにする」というものが共通してあった気がする。
アラート通知
例えば、アラート通知が頻発するような状態だと人は次第にそれを無視するようになる。
なんのためにアラート通知を出しているのかと言うともちろんアラートの発生原因である問題を確認・解決するためなので、アラート通知を発生させまくることによってそれを無視するようになってしまうのは本末転倒というわけである。
- 少し待てば自然解決する可能性があるならアラート通知せず少し待たせるべき。
- 障害が起こる未来を予想してアラート通知しない。
など、アラート通知を出すかどうかは思っている以上に慎重になるべき。
なお、アラート通知の判断材料となる「しきい値」はだいたいにおいて「率」を利用すると良い。 例えば、http_status: 500の件数が100件あったとして、全体のリクエスト数が200リクエストだったのと、1億リクエストだったのとでは印象や、おそらく事象も全く異なる。
ゲートキーパー
なにかシステム関連で事故や問題が発生したとき、再発防止としてチェック項目や責任者のレビュー体制が設けられる事が多い。
レビューがあるおかげで事前にミスがあぶり出せる可能性はあるが、逆に失われている物があることも認識しておくべき。
失われているのはデプロイの回数や開発工数である。
重いレビュー体制を置いて些細なバグを事前に洗い出せることと、開発速度を鈍化させ、リリースのタイミングを遅らせることを天秤にかけて、本当にそのレビューは必要なのかどうかを考えたほうがよい。
普段の業務で蜜に関わっていない少し上の責任者へのレビュー準備はコスト的にかなり大きいので（2人日くらい使う気がする。。）よほどのメリットが無いと釣り合わないよな、と個人的には思ってます。
