SREメンタル
はじめに
はじめまして、 strsbn です。
私は SREチームの一員として もしくは Infraチームの一員として、業務委託契約を複数社と交しインフラレイヤーの業務を行なっております。
本日一つの発見と共に、自分としてしっくり来た感じがしたので考えを記載しておこうと思います。
SRE とは。
SRE とは Google が提唱すr(以下略
ありふれた概要なので飛ばします。
主たる概念
- SLOの採用
- SLOに基づくアラート設定
- エラーバジェットの採用
- Toil計測/撲滅
- 派生して 自動化 ≒ Infrastructure as Code
- モニタリング
- ≒ 監視システム
- オンコール
- ≒ インフラレイヤの障害
- ポストモーテム
- 負荷の管理
結論
SREチームとは、インフラレイヤを設計管理開発運用するインフラチーム改め、SREチームです！ではなく、
SRE の 考え方 概念 を伝搬し、
- SREの考えで Frontend を開発します！
- SREの考えで Backend を開発します！
- SREの考えで Infra を開発します！
といった、アジャイルコーチが開発組織論を伝搬するように、サイト信頼性を向上させる心構えを伝搬することが主たる業務になるのではないだろうか。
例えば、GitHubでコードを管理し、Terraformでインフラを構築し、何度もやるような作業を省力化（Toil削減）したからSRE...!ではなく、たまたまインフラに従事していたエンジニアがSREの概念を取り入れたに過ぎないのではないだろうか。
同様にBackendのエンジニアが信頼性向上の為に MultiDB を取り入れ単発DBでは捌き切れないアクセスを捌けるようにした。Job実行サーバ（Sidekiqなど）でcron実行していたが単発hostとなる為、冗長構成にしても job 実行で問題ないように Sidekiq Scheduler を取り入れた。
更新頻度の薄いページについて更新処理時にキャッシュを削除するように改修するからGETはとりあえず全部キャッシュに乗せられるようにしよう！
など、どのような職種であっても概念を共有し、行動の基本原則（優先順位付け）として SLO を利用すれば良いのではないだろうか。
infraチームがinfra知見を元にアプローチするだけでなく、backendはbackendとして、frontendはfrontendとしてのアプローチは存在するのだから。
そもそもの疑問
- SREチームとして、各プロダクトのインフラを見ている。
- インフラチームとして、各プロダクトのインフラを見ている。
この違いはなんだろうか？
SRE とはエンジニアリングと付くが、 考え方 概念 であり、直接的なエンジニアリングには影響しないのではないだろうか？
※ 直接的と表現している対象は、Terraform、 K8S、 Golang、 AWS、 GCP、 MySQL、 PostgreSQL など、採用募集要項で上がりそうなアーキテクチャ群
現状の風景
インフラチーム改め、SREチームといった SRE = インフラ の結びついた表現を多く目にしており、採用募集でも SRE 募集といえば、インフラレイヤーのエンジニア募集が主になっているように見受けられる。
上記の強い先入観により、SREといえばインフラエンジニアがやるもの、率先するものといった固定概念が植え付けられているように思う。
そもそものゴール
ユーザが中心、ユーザファーストは当たり前。では、ユーザへの Value 提供のために何からしかかるか、を決めるために SLO を採用する事ではないだろうか。
SLO はシステムメトリクスだけか？（何からしかかるか の補足）
SLO指標に利用される項目として真っ先に上がるのは システムアップ時間 次点で 応答性能 などだろうか。
これだけでは ユーザの為に何からしかかるか は判断できない。できても極一部の要望（重いんだが...使えないんだが...）に対してだけだろう。
で、あればシステムメトリクス以外の有効な指標を追加し、開発サイクルの変更までひっくるめてワークフロー自体を最適化しよう。
以下、 ポッ とでの例えばこんなところかなー？です。
- ユーザ万人あたりの問合せ/クレーム件数
- 操作方法、パスワードリセット、メール付着など問い合わせ内容の分類、比率から開発アプローチの変更、改善の優先順位づけなど
- バグ問い合わせ件数
- バグ発生数、種類からテストケースの濃淡による最適化
- エラーバジェット / 開発速度 での 費用対効果 判断
- 平均チケット消化時間計測
結論（二度目）
要するに、SREはインフラのものでも、専売特許でもなく、どのレイヤー、どの職種であっても大切な 考え方 概念 であり、インフラチーム改め、SREチームとなった場合に単独チームで担保するものではない。
プロダクトとして、各職種みんなで必要な指標を洗い出し、合意にいたったら、SLOを定め、SLOを元にチケットの優先順位を決め、みんなで達成しようね...!というだけですね。
なので、インフラ見る人だけのSREはやめて、みんなでSRE魂...!
参考資料
Discussion