ちょっと前だけど自分が主担当ではないサービスのログ監視を強化したことがあった。強化しようとおもったきっかけは垂れ流しになっている5xxエラーを見て、これらのエラーはユーザに取って良くないという意識というか空気づくりとサービス品質の向上のためだった。
監視をするとやはりある程度の5xxエラーを検知したという通知が飛んできた。ユーザにとってよくない体験が起こっているので、優先度高めで修正するほうがいいと思うけど長く放置されているエラーだとユーザから問い合わせがなかったら「シュッと直すぞ！」っという空気にはなかなかなりにくい。またこれも差し込みのタスクだし、他の予定されたタスクがあれば尚更だと思う。一時期は自分が関わっていたサービスだから自分の責任もあるだろうし、自らやった反面急いで直したほうがいいと力説するのも違うなと思い、とりあえずエラーを修正したPRを出した。翌日主担当のエンジニアに修正を取り込んでもらって本番化され、しばらくの期間動いてなかった機能がちゃんと動くようになった。5xxエラーも減ったし良かったと思う。
そんな感じでちょっとずつサービス品質向上させねばと努めていた時期があった。自分としては
- エンジニアのエラーログに対する意識向上
- アプリケーションの異常検知する体制の強化
- エラーでサービスの一機能に満足に使えなかったユーザの体験を変えた
などの効果はあったんじゃないかと思うし、個人的な振り返りとしても今思うとアンテナ張って能動的に取り組んめてたとは思う。自分で良かったと思うことなので自己満かもしれませんが。
とまあその話を酒の席でする機会があったのでしてみたら「それじゃダメで、みんながそれをできるようにならないとそこまでの行為とは言えない」というお言葉を頂いた。そういう見方もあるのかと思いつつも、そこまだダメかなーってしっくり来なかったのであたまの片隅でもんもんと考えていた。
しばらく考えて自分なりにこうなのではみたいなのが考えがまとまったので忘れないようにブログに書いておく。
バックエンドエンジニアとしての行いが良かったかどうかみるには
- サービスの品質向上に努められているか
- パフォーマンスがでているか
- 安定・安全に運用していけてるか
- etc...
など至ってシンプルで、数値(監視グラフなど)として良くなってるかとどうかでも見ることができると思う。そう考えた時に今回悪かった数字が改善されたのだからやった行いとしては間違ってなかったと思う。でも人に教えるという行為も育成という面では大事だともちろん思う。サービスの品質を改善した行為と技術的なことを教えるという行為を一緒に評価するのではなくて、それぞれ別軸で加点要素としてみていったほういいのではないかな。両方できたらパーフェクト文句のつけようの気持ちで前向きにプラスに考えて行きたい気持ち。
