サービスが大きくなると開発速度以上に信頼性が大切になってくると思う。ビジネスの形にもよるけど、成長させて、大きな障害が発生して信頼性を落として、また頑張って信頼背上げて、そしてまた見過ごせない障害が発生して信頼性が落ちる。イタチごっこだよね。だから一度しっかり信頼性をエンジニアリングしたほうがみんな幸せだよね。という気持ち。
SREを勉強すると一番最初にでてくるのがSLO。これをチームに導入しようとがんばることになる。でもこれまで信頼性エンジニアリングをやってこなかったチームにSLOを入れるのは大変。
ここからは私の経験とか推測の話。
なんで大変なのか？のコアなところにSLOに対する誤解があると思う。どんな誤解か？というとSLO≒SLAという誤解。つまりどういうことかというと、「SLO is 何？」という問いに、「よくわからんけど、外部に約束してないSLAでしょ？」という回答がでてきちゃったら、それはSLO≒SLAと誤解してると思う。結構多いんじゃないかな、と思う。
じゃぁ「SLO is 何？」という回答は、Googleさんのこの辺（https://sre.google/intl/ja_jp/resources/practices-and-processes/art-of-slos/）読んでほしい。余談で個人的にはSLOとSLAは全くの別物だと思っている。
とにかくこの誤解が曲者。これのせいで、SLOをあまり知らない人のSLO印象が「ただのビジネス上の約束。しかも外に出さず内部で閉じるなら形骸化するだろうし無駄なもの。しかもこれ決めると追々SLAとか出てきそうで、できるだけ触れたくない」というネガティブなものになっちゃっていると思う。（SLAをディスる気持ちは一切ありません🙇♂）
ネガティブなものになっちゃってるとどうなるのか？という話。プロダクトの改善とかの話をしているときに、安易にSLOという単語を使ってしまうとどことなく空気が冷める。そして誰の心にも響かず、誰にも拾って貰えないで終ってしまう。そうなると導入するの大変。協力者が現れないから。一人で導入してもうまくいかないのわかってるし。だから自分はそんな場合にSLOって言葉を封印した。やっていることはSLOだったりSLIを決めに行っているんだけれども、ある程度形になるまでは「モニタリングの強化」とかそんな言葉を使っている。
プロダクトの改善もSLOだと響かないんだけど「モニタリングの強化」だとみんなの関心や、課題間はあるみたいで、一定の興味はもってくれる。そんな肌感なこの頃。