Speee DEVELOPER BLOG

Speee開発陣による技術情報発信ブログです。 メディア開発・運用、スマートフォンアプリ開発、Webマーケティング、アドテクなどで培った技術ノウハウを発信していきます!

良いSRE(Site Reliability Engineer)、悪いSRE

お疲れ様です、2週間前に思いついた自作キーボードがさっき完成したSREの西田(k.bigwheel)です。

僕がSRE(Site Reliability Engineer)という職種を知ったのは一年前のSpeeeの採用面接の中でした。SREになったのも入社のときからなのでやっと1年経ったばかりですね〜。 この1年のSREとしての自分を振り返ると、元バックエンド屋・インフラ屋としての経験もあって技術選定やアーキテクチャ的な面での大きな失敗は幸いにしてありませんでした。 発生した失敗もすべて想定の範囲内でその面ではよく価値を発揮できていたかなと思います。 一方でSREとしての振る舞いとしては想定できていなかった失敗や後になって思い返すと最善でない意思決定をしていたことに気づくことが多くありました(たぶん現時点で気づいていないことも多くあると思います💦)。

f:id:den8:20170627120210j:plain:h360

そうやって自分のSREとしての活動を振り返ったとき、よいSRE像とはどういったものかをイメージして浮かんだのが以前読んだこの記事です。

そこで振り返りも兼ねてこの記事のSREバージョンを書いてみることにしました。

注意書き

SREというのは各社で役割・実態が結構異なります。ここで書くのはSpeeeのDX事業本部のSRE固有の話で他社さんのSREには当てはまらないものもあるかもしれませんのでその点だけご了承ください。必ずしても以下に当てはまらないから良くないと一概には言えないと思います。 また以下はあくまで僕の個人的経験に端を発しており特定の誰かを揶揄したり指摘したりする意図はありません。以下で書いた個別の項目についてどの時期のどの仕事からそういった風に考えるようになったか、どういった失敗をしたかはまた別の機会にでも書こうと思います。

良いSRE(Site Reliability Engineer)、悪いSRE

チームワーク / Teamwork

良いSREは担当プロダクトチームの一員としての役割とSREチームの一員としての役割のバランスが取れている。自分の成功とは担当チームの成功と隣のチームの成功(現在存在する、または未来にできるものも)と考える。インフラストラクチャの構築・運用に責任を持ち、プロダクトチームがプロダクト開発へ注力できるようにする。プロダクトチームの課題を共有し、インフラストラクチャで解決するのがふさわしい課題は適時解決する。

悪いSREは担当プロダクトチームまたはSREチームにバランスが偏っている。プロダクトチームに偏っているSREはチームの横断的な課題を自動化・コード化しないため、ノウハウが属人化する。そのためトイルは減らず運用コストが減らないのでサポートできるプロダクトチームの数は一定で頭打ちになりスケールできない。SREチームに偏っているエンジニアは自動化・コード化に注意が向き過ぎておりプロダクトチームが泥臭い作業を必要としているときに支援しない。そのためプロダクトチームの信頼は得られずプロダクトの成功確率は落ちる。

技術的ビジョン / Technical vision

良いSREはシステムのインフラストラクチャの長期的な展望についてビジョンを持ち、それをプロダクトチームと共有する。良いSREはプロダクトチームとそれらの決定権を共有し、プロダクトの要求に応じて従来と異なるインフラストラクチャを部分的に採用しつつ同時に既存のインフラストラクチャを踏襲することで構築・運用コストを抑える。

悪いSREは既存のインフラストラクチャを考慮せず一からインフラストラクチャを設計する。その結果未知の部分が多いために失敗確率は上がり運用を共通化することもできないため運用コストが上がる。または単に既存のインフラストラクチャに固執してプロダクト固有の要求に応じない。その結果プロダクトチームはインフラストラクチャの制限により最新の技術が使えなかったり、インフラストラクチャ変更であれば簡単に実現できる機能をアプリケーション側で数倍のコストを払って実装することになる。

議論 / Discussion and debate

良いSREは議論の中で長期的なビジョンに責任を持つ。短・中期的なメリットに目が行きがちなプロダクトチームのカウンターパートとしてプロダクトの長期的継続性の視点から意見を出す。プロダクトの最終的な決定権はプロダクトチームに委ね、もしその結果運用性に支障が生じる場合は対策を立案する。

悪いSREはプロダクトチームと議論をせず責任を共有しない。プロダクトの長期的成長に責任を持たず、インフラストラクチャの構築・変更は単なるプロダクトチームからの作業依頼になる。またはSREチームと議論しない。結果会社全体のインフラストラクチャの共通化・最適化・自動化・ナレッジ化が進まず運用コストは上がり続ける。

プロジェクトマネジメント / Project management

良いSREは先を見越して行動する。新規開発や大きなインフラストラクチャの変更にアンテナを張り、プロダクトチームが滞りなく開発できるようにインフラストラクチャを用意する。良いSREはプロダクトチームに見積もりと進捗を共有し、遅延が出るようであれば速やかに共有する。従来と異なるインフラストラクチャを採用する場合はバックアッププランを用意する。プロダクトチームにインフラストラクチャ関連のタスクを制御できている実感がある。一方で特定のチームからのタスク量が過大である場合は差し戻す。

悪いSREは計画性がない。新規開発や大きなインフラストラクチャの変更にアンテナをはらず、直接話が来るまでアクションしない。悪いSREはプロダクトチームと見積もり・進捗を共有せず遅滞も伝えない。バックアッププランを用意せず、プロダクトチームにはインフラストラクチャ関連のタスクを制御できている実感はない。担当している複数のチームがあり、タスク量が特定のチームからに偏っていたとしても対処しない。

現実主義 / Pragmatism

良いSREは現実主義で、正しい事を行うことと仕事を片付けることのバランスを心得ている。自動化・コード化の重要性を知っているが、オートスケール化にこだわらずときに手動でインスタンスを追加したりインスタンスタイプを上げる選択肢を取ることもある。一方でそれが一次対応に過ぎないことを認識して長期的にはオートスケール化で根本対応する必要があることを認識している。

悪いSREは正しいことをしようとするあまり、明日必要なキャパシティに備えて今からオートスケール化を始める。悪いSREは明日プロダクトが必要としていることと長期的に解決しなければいけない課題の区別がつかない。

コミュニケーション / Communication

良いSREは成功の鍵がプロダクトチームとSREチーム両方とのコミュニケーションだと理解している。効果的なコミュニケーションが自分の仕事に必要不可欠であり、両者の潜在的な対立関係について理解しそのバランスを取る必要を知っている。必要であれば納得行くまで説明・議論することを厭わないが一方で全体の利益にならない局所最適化をプロダクトチームから求められた場合は断固として拒否する。

悪いSREはインフラストラクチャは自分の領分と考え、プロダクトチームに口を挟ませない。プロダクトがインフラストラクチャに合わせることを要求し、プロダクトチームに合わせた対応を行わない。逆にプロダクトチームへ寄りすぎてしまい、SREチームで連携を行わず会社全体の自動化・ミドルウェアや機能の横展開を行わない。

プロダクトとの関係 / Relationship with Product

良いSREはプロダクトマネージャーや開発リーダーと将来のプロダクトのインフラストラクチャがどうあるかについて議論する。会社全体のインフラストラクチャを見据えた上でできないこと・すべきでないことについて表明することを厭わないが、プロダクトのゴールを達成できるよう全力で支援する。良いSREはインフラストラクチャの選択肢をたくさん持ち、1つのやりたいことに対してそれらのメリットデメリットを比較してそのプロダクトにとって最適なものを選択できる。

悪いSREは特定のプロダクトに視点が寄りすぎていたり、逆にプロダクトへ関心がない。どちらに寄っていても長期的・会社全体の観点で見ると最適ではない。

柔軟性 / Resiliency

良いSREはプロダクトチームからの急な依頼に柔軟で、ユーザー価値への影響が大きいものであれば突発的な仕事にも対応する。

悪いSREはすべての依頼についてチケットを切らせて週明けのプランニングで優先度を確認するところから始める。またはすべての依頼を見境なしにすべて受け入れ他のタスクの期限を守れない。