仕事でコードを書くときは、バグを見つけられるようにテストをする。機能が仕様通りになっているかも確認する。
それ以外に。
運用することを考えてログを仕込む。1行1行どこで何が起こるかを考えて、そこで問題が発生したときに、どんな情報があれば調査できるかを考えてログを入れる。いくつかつなげないと分からないものは、つなげるための情報を入れておく。それか、ひとつにまとめてログを残す。
運用のことを考えると、ログじゃなくてイベントとしてデータストアに保存する方が良かったりもする。そういうアーキテクチャの部分から考える。
想定外のことが起こった場合に備えてアラートも仕込む。アラートは受け取ったらすべてに反応するつもりで仕込む。「これは無視していいやつです」って言うならアラートを飛ばさない。アラートは、何が起こっているのか、ユーザーへの影響は何か、対応として何をしないといけないのかが分かるような内容で送る。
システムが想定通りに動いていることを確認するためのダッシュボードを用意する。200msで返せているのか。リクエスト数は想定通りか。CPU利用率がはねてないか、メモリが徐々に増えていないか。リリース直後は毎日確認。落ち着いたあとも週に1回は眺めて過ごすためのもの。
ユーザーがどう使ってくれているかが分かるようなメトリクスも残してダッシュボードを用意する。プロダクトとして追いかけたい数字がどう変化したか。想定通りか、想定と違うか、違うならどの部分が原因か。そういう情報が追いかけられるようにシステムを設計する。
そんなことを考えているかな。なんとなく書いた。