SRE、このへんで 苦戦しがちじゃないですか？ ⾺場俊彰 @netmarkjp （⼀般的な意⾒はあるけど汎⽤的な答えはないよ）

  ⾺場俊彰 / X: @netmarkjp / Bluesky: netmarkjp.bsky.social 株式会社X-Tech5 取締役 CTO、株式会社iCARE技術顧問 運⽤エンジニアリング/DevOps/SRE/コンサルティング/組織構築/事業運営... 電気通信⼤学⼈間コミュニケーション学科（2004年卒） →社会⼈（SCC→ハートビーツ→X-Tech5） →産業技術⼤学院⼤学（AIIT）情報アーキテクチャ専攻（2011年卒） 主な守備範囲：Webシステムのインフラ‧ミドルウェア全般、モニタリング、 チューニング、プログラミング（Python、Go） 2 Amazon著者ページ https://www.amazon.co.jp/~/e/B004Y4SUBY

おさらい 3

SRE=Site Reliability Engineering. SREs=~Engineers 4 モチベーション： 複雑で⼤規模なコンピュータシステムを運⽤ する際、システムの成⻑‧拡⼤に⽐例して Ops（運⽤系エンジニア）がどんどん増えて いかないようにしたい コンセプト： ソフトウェアエンジニアリングで、運⽤を再 定義する コアプラクティス： 伝統的オペレーションを⾏うOpsを全廃する 実現のためのアクション： ソフトウェアエンジニアがソフトウェアエ ンジニアリングを⽤いて伝統的オペレーショ ンを破壊‧再定義‧置換する 実現のために会社が、SREを⽀持‧⽀援する SLI リスク受容 オブザーバビリティ ポストモーテム SLO/エラーバ ジェット ソフトウェア エンジニアリング リリース エンジニアリング オンコール マネジメント トイル削減 ︙ 【SRE本】 O'Reilly Japan - SRE サイトリライアビリティエンジニアリング https://www.oreilly.co.jp/books/9784873117911/ （2017/08）

SREエンタープライズロードマップ（2023/01） 現状に関わらず、SRE の導⼊で最も成功するのは、既存のフ レームワークと 真っ向から戦うのではなく、進化させ、補完 することを選択した場合です SREの実践はITILフレームワークと共存できる ...しかし結果が⼀致していてもやり⽅を調整する必要がある DevOps と SRE の取り組みを両⽴させるためには、現実的で あることが必要です 網羅的なルールを設定するよりも、核となる原則に集中する ことを奨励する⽅がよいでしょう 特定の組織で SRE を導⼊するベストプラクティスは 1 つでは ありません。正しい⽅法は、あなたが成功した⽅法だけです あなたのSREのバージョンが Googleのものと完全に⼀致する 必要はありません。原則だけは⼀致させてください SREエンタープライズロードマップ - Google - Site Reliability Engineering https://sre.google/intl/ja_jp/resources/practices-and-processes/enterprise-roadmap-to-sre/ 5

やってみて、こうなりがち SREの技術的なハードルは越えられることが多いものの、なーんかうまくいかな かったり、他チーム‧他部⾨との協調が進まなかったり、縮⼩/⽴ち消え/有名無 実になったり...... （私⾒）苦戦しがちなポイント： 1. ⾔外の前提条件の認識不⾜ 2. 変化を定着させる困難さ 3. 取り組みの事業的価値‧商業的価値の⾔語化不⾜ 6

⾔外の前提条件の認識不⾜ ステークホルダーとの対話が成⽴するかしないかをわける⽂化‧価値観 ● You build it, you run it に価値を置いているか ● HRTを重視する（Humility：謙虚、Respect：尊敬、Trust：信頼） ● 建設的な⾔動に価値を置く ● ⼼理的安全性を実現することに価値を置く ● 検証し失敗して学ぶことに価値を置く ● システム/サービスの価値構造の認識、あるいは価値観 ＝信頼性に価値を置いているか 7 1. ⾔外の前提条件の認識不⾜ 2. 変化を定着させる困難さ 3. 取り組みの事業的価値‧商業的価値の⾔語化不⾜

信頼性に価値を置いているか 8 1. ⾔外の前提条件の認識不⾜ 2. 変化を定着させる困難さ 3. 取り組みの事業的価値‧商業的価値の⾔語化不⾜

変化を定着させる困難さ ● 不安が先に⽴ちがちなところの信⽤獲得 ○ 検証し失敗して本当に評価されるか？逆に下がらないか？ ○ ポストモーテムで本当に⾮難されないか？ ○ →たぶん決定打はないので、普段からのステークホルダーとの信頼貯⾦が重要 ● 根本的に⼤⼈の⾏動変容は難易度が⾼い ○ 「やってみる」から先で定着しないがち ○ →定点観測会がお勧め。最初何回か来てくれがちなのでそのうちに成果を⾒せて巻き込む ● 仕組みや構造が重要。その上で最初の⼀歩と最後のひと押しでは気合と根性 と執念が不可⽋ 9 1. ⾔外の前提条件の認識不⾜ 2. 変化を定着させる困難さ 3. 取り組みの事業的価値‧商業的価値の⾔語化不⾜

取り組みの事業的価値‧ 商業的価値の⾔語化不⾜ ● ITIL 4も⾒てみると良い（バージョンは重要。4を⾒てみよう） ○ ITILの⾔語化は凄い ● 価値が認識されないなら、⼀度スッパリやめてみても良い ○ 陰で⽀え続けるのは不健全。（⼀般的に）たいていロクなことにならない ○ SRE的にも『ヒロイズムを積極的に阻⽌』 ○ SREでは『検証し失敗して学ぶことに価値を置く』 ○ 例：SLOは⼀般にSREのコアプラクティスだけれども、SLOを軸に組織内展開するのが「その 組織でSREを実現‧浸透できる道筋」とは限らない 10 1. ⾔外の前提条件の認識不⾜ 2. 変化を定着させる困難さ 3. 取り組みの事業的価値‧商業的価値の⾔語化不⾜

まとめ SREに限らずだけれども ● 始めるより続けるのが難しい。銀の弾丸はない ● 理論も理性も情熱も全部だいじ ● ⾦⾔『信頼性は会話です』 信頼性⽬標とシステムアーキテクチャー / Reliability Objective and System Architecture - Speaker Deck https://speakerdeck.com/ymotongpoo/reliability-objective-and-system-architecture?slide=55 11 1. ⾔外の前提条件の認識不⾜ 2. 変化を定着させる困難さ 3. 取り組みの事業的価値‧商業的価値の⾔語化不⾜ SREサービスで『運用現場を、楽しく。今日より、一歩前へ。』
 X-Tech5のエンジニアがプロジェクトに参画し SRE ・ DevOps ・ オブザーバビリティ の実現や定着に取り組みます
 https://x-tech5.co.jp/service/sre-service/
 Ads