SREsのためのSRE定着ガイド

#SHIFT_SRE
No SRE，No life｜教科書には載っていない！俺たちが考えたSRE推進の道しるべ｜ #SHIFT TECH TALKS#1
登壇資料

Transcript

1. SREsのためのSRE定着ガイド ⾺場俊彰 @netmarkjp （⼀般的な意⾒はあるけど汎⽤的な答えはないよ） SREサービスで『運用現場を、楽しく。今日より、一歩前へ。』
 X-Tech5のエンジニアがプロジェクトに参画し SRE ・ DevOps ・ オブザーバビリティ の実現や定着に取り組みます
 https://x-tech5.co.jp/service/sre-service/
 Ads
2. SEE ALSO 2 もしあなたがピチピチのSREsであれば→も⾒ていただくとスムーズです （⾒ていなくても⼤丈夫） 今⽇はもう少し実践寄りのお話をします 参考：右の資料のサマリー • 始めるより続けるのが難しい。銀の弾丸はない - 苦戦ポイント1. ⾔外の前提条件の認識不⾜ - 苦戦ポイント2. 変化を定着させる困難さ - 苦戦ポイント3. 取り組みの事業的価値‧商業的価値の⾔語化不⾜ • 理論も理性も情熱も全部だいじ • ⾦⾔『信頼性は会話です』 信頼性⽬標とシステムアーキテクチャー / Reliability Objective and System Architecture - Speaker Deck https://speakerdeck.com/ymotongpoo/reliability-objective-and-system-architecture?slide=55 https://speakerdeck.com/netmarkjp/ SREサービスで『運用現場を、楽しく。今日より、一歩前へ。』
 X-Tech5のエンジニアがプロジェクトに参画し SRE ・ DevOps ・ オブザーバビリティ の実現や定着に取り組みます
 https://x-tech5.co.jp/service/sre-service/
 Ads
3.   ⾺場俊彰 / X: @netmarkjp / Bluesky: netmarkjp.bsky.social 株式会社X-Tech5 取締役 CTO、株式会社iCARE技術顧問 運⽤エンジニアリング/DevOps/SRE/コンサルティング/組織構築/事業運営... 主な守備範囲：Webシステムのインフラ‧ミドルウェア全般、モニタリング、チューニ ング、プログラミング（Python、Go） 3 Amazon著者ページ https://www.amazon.co.jp/~/e/B004Y4SUBY SREサービスで『運用現場を、楽しく。今日より、一歩前へ。』
 X-Tech5のエンジニアがプロジェクトに参画し SRE ・ DevOps ・ オブザーバビリティ の実現や定着に取り組みます
 https://x-tech5.co.jp/service/sre-service/
 Ads
4. おさらい 4
5. SRE=Site Reliability Engineering. SREs=~Engineers 5 モチベーション： 複雑で⼤規模なコンピュータシステムを運⽤ する際、システムの成⻑‧拡⼤に⽐例して Ops（運⽤系エンジニア）がどんどん増えて いかないようにしたい コンセプト： ソフトウェアエンジニアリングで、運⽤を再 定義する コアプラクティス： 伝統的オペレーションを⾏うOpsを全廃する 実現のためのアクション： ソフトウェアエンジニアがソフトウェアエ ンジニアリングを⽤いて伝統的オペレーショ ンを破壊‧再定義‧置換する 実現のために会社が、SREを⽀持‧⽀援する SLI リスク受容 オブザーバビリティ ポストモーテム SLO/エラーバ ジェット ソフトウェア エンジニアリング リリース エンジニアリング オンコール マネジメント トイル削減 ︙ 【SRE本】 O'Reilly Japan - SRE サイトリライアビリティエンジニアリング https://www.oreilly.co.jp/books/9784873117911/ （2017/08）
6. 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/ 6
7. 本⽇のお悩み 「SREをもっとうまく実践したい」 7
8. 本⽇のお悩み「SREをもっとうまく実践したい」 • SREチームは⽴ち上がったが、責務があいまい。何でも屋さんだったり、名 ばかりチーム状態になっている • 属⼈化したシステム運⽤が⾟くてツールを導⼊したが、⼀部を⾃動化しただ け。痒いところは改善していない • 課題のボトルネックを考える余裕も時間もとれない • 組織横断で取り組みたいがDev↔Opsの溝がある。⼼理的安全性もないので 何も⾔えず⾟い 8 正しいけど実⽤性が低いアドバイス（でも忘れちゃいけない） 「時間はつくるもの」 「⽂化はつくるもの」 「居場所はつくるもの」 「権利や裁量は獲得するもの」 「そこはあなたが居続けるのに適した場所ではないのでは」
9. SRE実現/拡⼤/継続/定着に効いた3つの取組み 9 定点観測会 モブプロ、モブオペ 外部リソース注⼊ 取り組み 狙い 改善サイクルを回す（OODAループ） ⾔外の前提条件を共有し浸透させ実現し続ける "知識"と"価値の認識"を共有し浸透させ 実現し続ける タッチポイントやコミュニケーション回数を増や して関係者との関係性を作る‧深める 今⽇はこっち
10. 定点観測会：なにをするのか 定点観測会がいちばんのお気に⼊り Do：参加者に価値を • ⼀回30-60分程度。できるだけ週⼀回 • Dev と Ops に、できればBizにも参加してもらう • 事前準備有り ◦ 重要な状況変化をピックアップして振り返る ◦ インシデントの振り返り（Learn from incidents） • 穏やかに、学びになるように（blameless, keep constructive） Don't：「こなす」にしない • 網羅的なメトリクスやタスクの確認はしない • 「こうあらねばならない」を軸にしたやり⽅や話し⽅はしない ◦ ToBeよりも、AsIs, +0.5, +1.0 ◦ 伸びしろは常にある • SLOで⼀喜⼀憂しない 10 SRE成功の鍵は「定点観測会」だと思っている
 https://x-tech5.co.jp/2023/12/08/1331/
 Ads
11. 定点観測会： なぜするのか • OODAループを回す起点 に • ⾔外の前提条件を共有‧ 確認 11 上：Webエンジニアのためのモニタリング‧オブザーバビリティ実践ガイド    https://x-tech5.co.jp/download/ 下：サーバ∕インフラエンジニアの基本がこれ1冊でしっかり⾝につく本   https://gihyo.jp/book/2021/978-4-297-11944-7 • それぞれの視点や価値の認識を共有 • ⼈と⼈の距離を近づけて信頼関係を構 築‧維持するために不可⽋な 「コミュニケーションの量」を増やす • 個⼈の技術⼒を磨く ◦ システム状態把握、判断、⾏動決定、⾏動
12. 定点観測会：どうやるのか Do：準備して、参加者にとって価値あるものにする • あらかじめwikiなどにアジェンダと注⽬ポイントを書く • トピックはMELT、コスト、アラート、ポストモーテムなど • 過去だけでなく未来のことも共有する Don't：「こなす」ことはしない • タスク進捗報告会にならないように • 網羅しようとしない • 参加者がお客さんにならないように • 仕事が定例駆動にならないように ◦ 会のあとにカッとなってガッとやる時間をとっておくとよい 定番のお悩み： • だんだん準備しきれなくなって開催できなくなる ◦ 準備⾃体は⾃動化したり省⼒化したり。外部リソース使うとかでがんばる ◦ 最初の⼀歩と最後の⼀押しは気合と根性と執念 • BizやDevが参加してくれない、参加してくれなくなる ◦ 最初の何回かに出てくれるかは仲の良さや信頼関係によることが多い ◦ その最初の何回かで「実務的な価値を実感」してもらう。ログ確認が楽になったり、やらなくていい仕事をみ つけたり、ユーザー動向について発⾒があったり 12
13. モブプロ‧モブオペ：なにをするのか Do • 複数⼈でプログラミングやオペレーションする ◦ ペアプロやペアオペのn>=3バージョン • やるひと（ドライバー）を決めて、やるひとはself-describeしながらやる ◦ メンバーは広く浅くではなくSREingに深く関わるひと • みるひとはうなずいたり相槌をうつ。リアルタイムに適宜突っ込む Dont • レビューを兼ねない ◦ レビューはレビューでやる • このへんは⼀般的なペアプログラミングのプラクティスを参考にする 13
14. モブプロ‧モブオペ：なぜするのか • 個⼈の技術⼒の育成 ◦ ⾃分の思考や⾏動の⾔語化の練習 • 具体的な知識‧価値の認識の共有 ◦ 雑談やつぶやきレベルから暗黙知を共有 ◦ 細かいところが⽣産性をわけたりするやつ ◦ 「いままで⾃分がヨシとしてきた世界観」から変わ るチャンス。たとえばどのくらいセルフ化で実施で きるようにするか（委譲という意味で） • 具体的な技能の共有 ◦ エディターのいい感じの使い⽅とか ◦ 他の⼈のコーディングの速さを知るとか ◦ ドキュメントの読み⽅とか ◦ ⾃分のやりかたと他の⼈のやりかたが具体的にどう 違うか⽬の当たりにするチャンス ◦ 「いまの⾃分ができるやりかたありき」から変わる チャンス。たとえばsysadminアプローチから software engineeringアプローチへの変化 • チームビルディング ◦ 仲間とひとつのことをする経験を増やす 14 サーバ∕インフラエンジニアの基本がこれ1冊でしっかり⾝につく本 https://gihyo.jp/book/2021/978-4-297-11944-7
15. モブプロ‧モブオペ：どうやるのか • 「全部の作業をモブで」はしない ◦ 多くの場合は網羅性は⾮現実的 • まずは定期的に時間を設けるとよい ◦ そこでやるほどでもない、ようなことをやる⽇もある ◦ 意外と発⾒があったりする • やろうとしていること、なぜそれをやろうとしたか • オペレーション実⾏前に結果を予想して話す、出⼒された内容のどこを⾒た か話す、それをどう判断したか話す • 改善の種にもなる ◦ 誰かが迷ったり間違えるところは、他のひともいつか迷ったり間違える • MeetとかZoomの画⾯共有でじゅうぶん ◦ ひとつ画⾯を⽤意してそこを全画⾯共有すると楽ではある。terminal / vscode / browserを併 ⽤することが多いので ◦ ガチでペアプロ/モブプロするならvscode liveshareではあるけど、meetならそれぞれ画⾯共 有すればいいからgood 15
16. 外部リソース注⼊ • X-Tech5のようなSREingを⽀援 するサービスにお願いする ◦ 例：X-Tech5, Topotal, 3-Shake • 前提として、⾃分たちでやりきれるならそのほうがいいです ◦ 定点観測をしつこくやるとかは割と頼りたくなるポイント ◦ 組織や他⼈に変化をもたらすために「外部エキスパートの助⾔」に価値があるケースは往々 にしてあるので、うまく使ってください • ⾔いづらいことを⾔う係みたいなときもある ◦ 外部のひとがいると、アメとムチ作戦がしやすいというのもある • 観点：プロジェクトコードに紐づいた稼働管理や稼働率に縛られると改善で きるものも改善できないので、ある程度浮かせる必要がある ◦ このあたりはas a Serviceとしてやる意義がある ◦ 派遣であったり、プロジェクトコードと稼働率を重視する状況では厳しい ◦ 絶対にプロジェクト化しなければならない、かつプロジェクト化できないのであれば、いま はSREに⼿を付けるときではないのかも。もしくはそこはあなたが居続けるのに適した場所で はないのかも 16 SREサービスやってます
 https://x-tech5.co.jp/service/sre-service/
 Ads
17. 余談：たまにある「SREingをSREsだけがやっている」のコンプレックス 17 全員でやるべきでは？ それはそう つまり専任SREsは不要になるべきでは？ それは...そう？ 「全員で守備すればディフェンダーはいらない」 「全員が考えれば監督はいらない」 みたいな思考になってない？
18. 余談：SREing難しすぎない？ 18 わかる 考えて実践したGoogleはすごい それを学んで取り組んでいるみなさんもすごい SREエンタープライズロードマップを思い出して 「正しい⽅法は、あなたが成功した⽅法だけ」 「Googleのものと完全に⼀致する必要はありません。原則だけは⼀致させてください」 できていないことよりも、 できていることと、次にできるようになることに ⽬を向けましょうよ
19. まとめ • SRE定着に効いたオススメの取り組み • 理論も理性も情熱も全部だいじ • ⾦⾔『信頼性は会話です』 信頼性⽬標とシステムアーキテクチャー / Reliability Objective and System Architecture - Speaker Deck https://speakerdeck.com/ymotongpoo/reliability-objective-and-system-architecture?slide=55 19 1. 定点観測会 2. モブプロ‧モブオペ 3. 外部リソース注⼊ SREサービスで『運用現場を、楽しく。今日より、一歩前へ。』
 X-Tech5のエンジニアがプロジェクトに参画し SRE ・ DevOps ・ オブザーバビリティ の実現や定着に取り組みます
 https://x-tech5.co.jp/service/sre-service/
 Ads