hacomono TECH BLOG

フィットネスクラブやスクールなどの顧客管理・予約・決済を行う、業界特化型SaaS「hacomono」を提供する会社のテックブログです!

Site Reliability Engineeringをポジティブに捉える



はじめに

こんにちは。SRE部のiwachan( @Diwamoto )です。
最近人生で初めて登壇をしました(資料)。hacomonoは私のSRE人生2社目ですが、ようやくエンジニアとしてやりたかった外部登壇や社外への貢献ができるようになり、とてもありがたく思っています。


💡 記事中のSREはSite Reliability Engineeringを指します。
  職業としてのSREは記事中ではSREエンジニアとしています。

TL;DR

  • 万事ポジティブに捉えた方が幸せになれる
  • SREは「やらされるもの」ではなく「便利なツール」
  • その為に、SREエンジニアはやれることは何でもやるべき

想定読者

  • 社内にSREを広めたい人
  • SREやってる人
  • 運用業務が苦手と考えてる開発エンジニア


導入: SRE導入の文脈は開発エンジニアから見ると消極的であることが多い

SREエンジニアの皆さんはこんな経験はないでしょうか?

あなたは社内にSREを広めていく役割を担い(指示され)ました。

そのために必要なツール(DatadogやNew Relicなど)を勉強・実装し、いざ社内に広めていこう!というフェーズまで来ました。

ところが開発者から、「またやることが増える」「今のままで十分」と、かなりネガティブに受け取られて導入が頓挫してしまいました。

なぜこうなってしまったのでしょうか?

こうなってしまう理由は色々あるとは思いますが、「SREをポジティブに捉えてもらう努力が足りなかった」と私は考えます。

概念: ポジティブに捉えれば万事うまくいく

SREをポジティブに捉えるとはどういうことでしょう?
人間は大きく分けて二つのタイプに分かれると考えています。ポジティブネガティブかです。
同じ状況でも捉え方によって、その後の行動や感情が全く違ってきます。
例えば、500mlのペットボトルに水が半分(250ml)入っているとしましょう。
この時、「あ、まだ半分もある!」と思いますか。
それとも「ヤバい、もう半分しかない...」と思いますか。
私はこの小さな違いが、その後の心の余裕や集中力に大きく影響すると考えます。
「まだ半分もある!」と思える人は、水不足について考える必要がないため、次にやるべきことに集中できます。一方で「もう半分しかない...」と思ってしまうと、水が足りなくなることへの不安が頭をよぎり、人によってはその問題を解消しないと次に進めなくなってしまうでしょう。

転換: SREをポジティブに捉える

物事をポジティブに変換するということが仕事に対していい影響を与えることはわかったと思います。
それをSREで考えてみるとどうなるでしょうか。

  • ネガティブ: 「また新しい仕事が増えた」と捉える
    → SREの取り組みに対して受動的になり、十分に時間を投資せず最小限に留めてしまうことで、本来得られるはずの効率化や安定性向上の恩恵を受けられない。
  • ポジティブ: 「システム安定化のための便利なツールを手に入れた」と捉える
    → 開発ツールの一環としてSREを積極的に活用し、長期的に運用コストの削減や開発速度の向上を実現する

つまり、SREを「便利なツール」としてポジティブに捉えてもらうことで、その後の組織やシステムの健全性に大きな差が生まれると考えます。

根拠: ライブラリ入れる時はテンション上がるよね?

ではなぜSREを「便利ツール」として捉えると効果が増すのでしょうか?
理由として、開発者にとってSREがポジティブに捉えやすい領域になるからです。
開発者が新しいライブラリを導入するモチベーションは基本的にポジティブで、多くの場合「これで開発が楽になる!」「新しい機能が実装できる!」といったワクワクした気持ちで導入されます。
ここにSREも乗ることで、その恩恵を享受しようというわけです。

実例: そのためにSREとしてやったこと - hacomono-slo-platformについて -

前述の通り、開発者は常にネガティブというわけではなく、新しいライブラリや技術に対してワクワクする分野が必ずあります。
そこでhacomonoでは、まず初めにSLOをツール化し、YAMLファイルを操作するだけでSLOのダッシュボードとアラーティングをすべて提供してくれるhacomono-slo-platformを作成しました。

hacomonoの予約機能に関するSLOを定義したslo_configです。availabilityとlatencyをyamlで定義することができます。

作成されるダッシュボードの一つです。エラーコード別のリクエスト数や、レスポンスタイム等が表示できます

YAMLファイルの構成については以前のブログを参考にしてください

結果として、これまでなかなか進まなかったSLOのEnablingが複数チームに同時に進められるようになりました。
開発チームからも、「コードをAIに読み込ませて、YAMLファイルを作ってもらうだけでSLOが始められるので楽」だったり、そもそもSLOを導入して信頼性が可視化されることに対する肯定的なフィードバックをいただけました。
これだけに留まらず、SREエンジニアはSREを広めるために、できることは何でも積極的に取り組むべきだと考えます。

まとめ

今回はSREをポジティブに捉えてもらい、有用なツールとして使ってもらうことで広めていくという方法を紹介しました。
特にSREに限ることはなく、ポジティブに生きることで幸せになれると思っています。
エンジニアは室内で作業することが多く、ネガティブ思考に陥りがちだと言われることがあります。
皆さんもぜひ、日々の仕事や生活で物事をポジティブに捉える習慣を身につけてみてください。それだけで、同じ状況でも全く違った景色が見えてくるはずです。



💁 関連記事