最近「いかに運用作業に手を抜くか」というのを考えているので、なんとなーくアウトプットしてみようと思う。
運用作業とは?
自分が想定する "運用作業" というのは機能開発に関係ない作業全般である。 例えば以下の作業は "運用" にカテゴライズしていいと思う。
運用作業はゼロが理想だけど、そーもいかない
自分は運用作業がゼロになるのが理想だと思っている。 可能であれば、機能開発にすべての工数を投じて、自身が開発するプロダクトを進化させていきたい。
ただ、運用作業をゼロにするのは不可能である。 ソフトウェアのバージョンアップは定期的にしなければいけないし、リファクタリングもしなければいけない。
そうなると「どの程度運用作業をするべきなのか」を考えてなければいけなくなってくる。 具体的には "運用作業に手を抜けるギリギリのライン" を探る必要がある。
運用を頑張りすぎてしまうエンジニア
自分自身もそうだと思うが、エンジニアは運用を頑張りすぎてしまうように思える。 これは "日本人の真面目さ" が悪い方向に働いているように思える。 例えば以下である。
- 不具合は見つけ次第、すべて修正する。
- アラートを厳しく設定し、毎回対応するが、様子見で終わるような対応が多い。
- コードの品質を高めるためにリファクタリングを頑張りすぎる。
- ソフトウェアを毎週バージョンアップする。
上記は一例になるが、これらをまともに実践すると運用工数が大きくなり、開発に割ける工数が限られてしまう。
DMMはメガベンチャーということもあり、（部署によると思うが）当たり前のことを当たり前にできる環境が用意されている。 ユニットテストを書く時間も確保できるし、 不具合を修正する時間も確保できるし、、 リファクタリングする時間も確保できる。 だからこそ、本来目指すべき "運用作業に手を抜けるギリギリのライン" を探ることなく、 運用に工数を割いてしまう可能性がある。
pospomeはどうしているか?
自分は可能な限り手を抜きたいと思っており、それを試行錯誤している。
例えば "DMMプラットフォームにおけるSLO導入" がその1つである。
DMMプラットフォームの各チームはとにかく "アラートの静観" が多かった。 アラートのしきい値が厳しすぎて、対応する必要のない一時的なレイテンシの増加などにも対応していた。 まさに "SLO=100%" を目指すかのようなスタンスで、どう考えても辛い環境だった。
以下はpospomeが困っている様子。
現在はSLOを導入することで "アラートの静観" は減少傾向にある（最初に比べるとかなり減ったので嬉しい）。 それどころかSLOをベースに運用工数を適切に制御することができるようになった。
以下は「SLOを割らないから対応しない」というケース。
以下は「SLOを割るから対応する」というケース。
SLOの件以外にも、いかに運用工数を減らし、開発にコミットするかを考えないといけないなーと思っている。
まとめ
"運用作業に十分な作業工数を割ける環境" というのはとても幸せなことだと思っているけど、 その環境を与えられている以上、開発スピードを向上させるために試行錯誤する責任みたいなものを背負っていかないといけないなーと思っている。
