3月からYOUTRUSTにSREとして入社した須藤(YOUTRUST/X)です。
1人目のSREとして組織に参画したタイミングということで、改めて既存組織に対しどのようにSREを進めていくか、という決意表明も含めてブログにしたためたいと思います。
これからSREを始めようと思っている、そこのあなたにも参考になれば幸いです。
いろはの「い」
SREとはSite Reliability Engineering（サイト信頼性エンジニアリング）の略です。ウェブサイト（やサービス）の信頼性をエンジニアリングで解決しよう！という考え方から生まれた言葉になります。
信頼性とは？
これは個人的な意見ですが、サイトやサービスに限らず、信頼されるための基本的な考えは人と同じだと考えます。約束を守る、嘘をつかない、ごまかさない、相手の気持ちに立って考える、誠実に謝れる、何かあった場合はすぐ連絡が取れる、自己管理ができている、などなど。
サービスも使ってくれる（付き合ってくれる）ユーザーやビジネスパートナーという人がいて成り立つものなので、システムの問題解決だけにフォーカスしていると大事な部分を見落としてしまいます。
SREという職種
巷では未だにSREの定義についての議論を目にします。それは偏にSREという言葉が職種として広まってしまったからだと思います。職種という概念にとらわれていると、インフラエンジニアやソフトウェアエンジニアとの違いに目が行きがちです。
私も以前いた組織では、職種と改善する組織文化とを分けて定義していましたが、それぞれの職責がどうこうというところまで言及していませんでした。
SRE＝信頼性を改善するプロセスの集合と考える
あれから時は経ち、最近はプロセスと捉えるのがしっくり来るなと感じています。きっかけは、『ザ・モデル』*1を読んだことです。マーケティングや営業のビジネスプロセスを分け、それぞれが協業するように組織を構成するというアイデアは、職種ありきのチーム構成になることが多いエンジニア組織でも参考になるのではと思いました。
ザ・モデルのようにプロセスごとに組織するわけではないですが、監視やポストモーテムなどのSREのプラクティス、SRE以外のエンジニアリングについても、事業課題を解決するためのプロセスと考え、どの職種がどのプロセスを担当するかをその組織体やメンバーによってモデリングすることによって、新たな職種やチームをつくるよりもシームレスに組織を成長させることができるんじゃないかという仮説（妄想）を立てています。
たとえばインフラエンジニアとソフトウェアエンジニアが分かれている組織であれば、インフラエンジニア側のチームが持つSREプロセスを増やす、まだSREを担当するチームがないのであれば、自分たちで最低限必要なSREプロセスを定義し進めていく、横断組織が複数のプロダクトチームを見るような場合は、イネーブリングする担当者が各プロダクトでSREプロセスを定義し推進していく、といった具合です。やり方としては既視感がありますが、プロセスという考え方を持つことでよりSREの実現性が見えてくる気がしませんか？
プロセス改善により再現性を高める
仕事をしたり、組織をつくる上で何より重要なことは再現性だと思っています。会社は人も変わるし組織も変わります。そのためプロセスや文化といった形で残すことで変化が起きても対応することができます。
再現性が高いと確実にプロセスが繰り返されることでアウトプットの品質を維持、向上することができますし、予測可能性にもつながります。予測可能性が上がれば想定外の問題を減らすことにも繋がります。
プロセスの再現性を上げていくためには、各プロセスの定義を明確にし、振り返り改善を重ねていくことが重要です。
SREのはじめ方
では、どのようにしてSREプロセスを定義し改善していくのか。
そこで利用するのが、手前味噌ですがSRE成熟度評価です。必須の評価項目は「信頼性の階層」のベースであるモニタリング、インシデント対応、ポストモーテムになると思いますが、それより上（またはこの項目にないもの）については、前述の信頼性について話したように事業規模であったりフェーズによって異なってきます。また、この図の上位層は抽象的に記述されているのでこの通りにはならないと思います。
例えば、サービスレベル目標はSaaS事業では必須になってくると思いますが、BtoCなどの初期フェーズでは、ベースの項目を改善することの方が重要になってくるでしょうし、成長段階に入った事業ではコストが雪だるま式に増えていかないよう最適化する必要がありますが、まだ発展途上の段階では優先度は低くなるでしょう。また、成長した結果システム負荷や課題がたくさんある状態であれば、足元の課題解決をする必要もありますが、今後そうならないためのシステム設計や保守のプロセスの精度を上げる必要があります。
大事なのは、事業課題から掘り下げて中期〜長期目線で必要な項目を定めることです。
事業ドメインの理解を行い、評価項目を決めたら評価項目のレベリングを行います。基本的な考えは成熟度評価を作成した頃より変わっていませんが、レベリングの基本方針は以下のように変更しました。
- レベル1 : プロセスが定義されておらず場当たり的な状態
- レベル2 : 組織内でプロセスが定義、認知されている状態
- レベル3 : プロセスが継続的に改善され、再現性を持って実行されている状態
非エンジニアチームとの協業
これだけでもSRE活動のスタートは切れると思いますが、インシデント対応やポストモーテム、サービスレベル目標、セキュリティなどはBCP（事業継続計画）*2、SaaS事業であれば企業のセキュリティチェック*3など、リスクマネジメントの観点でも関連する要素になってきます。
企業によって担当する部署もアプローチも異なり、あまり同時に語られることは少ないと思いますが、考え方で一致する部分は多々あります。これらの部署と協業することができれば、事業としてよりレバレッジを効かせることができるのではないでしょうか。
SREを推進していくためには、真の信頼性を考えるためプロダクトチーム全体に理解してもらうことも必要ですが、こういった意味でも非エンジニアチームにSREのコンセプトを理解してもらい、協業していくことは重要だと考えています。
最後に
今はまだ構想段階ですべてを実施できているわけではないですが、今後の進捗に合わせてまた報告できればこれ幸いです。
そんなYOUTRUSTではSRE含め、エンジニアを積極的に採用しています。
様々なポジションで求人を出しておりますので、ぜひご応募ください！
