継続は力なり

タイトル通り定期的な更新を心掛けるブログです。

SRE NEXT 2022 Day1 参加レポート #srenext

タダです.

SRE NEXT 2022 の Day1 参加レポートを書いていきます.自分が聞いたセッションでのメモを転記しながら感想を書きますが,私用の関係で最後まで参加できていないところがあります 🙇

sre-next.dev

How We Foster "Reliability" in Diversity

SRE as Service で他社の SRE プラクティスを実践してきた経験からどのように組織で SRE を実践.組織に適した SRE を定義して育てていくための取り組みの紹介するお話でした.SRE の実践の5つのステップは自分が体感したものと合致したので納得感があったり,組織変革のためのアプローチで MVV の作成や環境変化に伴うためのアプローチで組織の多様性が役立つというのは新たな気づきを与えてもらったセッションでした.

sre-next.dev

資料

メモ

  • 適切な SRE の実践がなぜ難しいのか
    • SRE に求められるものが多様化している
      • 組織ごとに信頼性が異なる(サービスを取り巻く全ての要素が同じにならない)
      • 信頼性の計測方法も異なる
  • システムの特性によって信頼性が異なる(緊急速報とコーポレートサイトの比較)
    • 短距離じゃなくて長距離
  • 技術的な側面と文化やプロセスなどの組織的な課題が関わる
    • SRE は組織の変革を伴うから一朝一夕にできない
  • SRE の実践の取り組み
    • SRE の実践における5つのステップ
    • 組織が自律的に動けるようにする
    • 組織の氷山モデル
      • 組織変革は上からも下からもアプローチが必要
      • Level3 からのアプローチ
    • SRE の方向性と価値観を明確にする
      • SRE のミッション、ビジョン、バリューを定義する
    • 企業・組織コンテキストの把握
      • 会社の方向性と SREs の MVV を合わせる
      • 企業活動を俯瞰的に捉えて,SRE の影響のある主要な変数を整理する
      • 様々なリソース:企業方針/サービス/組織のコンテキストを把握する
  • MVV 作成のステップ
    • 関係者へヒアリング
    • たたき台作成(8割位作る)
    • レビュー&修正
      • 大枠を固めたら使う言葉の選定やニュアンスの確認を同期的に行う
    • KPI
      • 文化情勢のためのMVVを作るだけでなくKPIを定めていく
  • 環境の変化に対してどのように取組むか
    • サービスによって適切な信頼性は変わるので変化の対応するための良いアプローチがないか模索
    • SRE 本 18.3.5 チームの力学 では多様性によってチームの問題点への盲点をなくす
      • 組織の環境変化への耐性を保つために組織の多様性が役立つ

SRE の歩き方・始め方

Q&A 方式で SRE とは?実践の仕方の紹介のセッションでした.特に Toil 削減の話は SRE 本でも見て実施していく必要があると思っていましたが,なぜやるのかの部分で改めて SRE の時間の確保だけでなくキャリアの停滞や燃え尽きなどの悪影響を見て,自動化できるものはしていく必要があると再認識しました.

sre-next.dev

メモ

  • そもそもSREとはなにか?
  • SRE は 2004年からGoogleにチームが発足
    • サーバー/MW のセットアップをソフトウェアの課題として扱う
    • オペレーションに正しくエンジニアリングを取り入れて改善し続けること
      • システムが安定してればいいというのではなく,数字でコントロールする
      • 手作業を行わず自動化してサービスをスケールさせていく(人を増やすのではなく)
  • SRE と DevOps の関係とは?
    • 同じ課題を別のアプローチで解こうとしている関係性
    • Dev/Opsのサイロ化という課題を解消しようとする側面がある(オペレーションをソフトウェアとして扱う、DevとOpsを分業するのではなく協業していく)
      • class SRE implements DevOps
    • SRE のプラクティスはDevOpsの範囲外(TOILの削減)範囲内(Dev / Ops の協業体制)の具体的な手法が提案されている
  • class SRE implements DevOpsを踏まえ、どういう形で SRE の実践・プラクティスを実践するか
    • SLI/SLO & Error Budget -> 信頼性のプラクティス,Window: SLI/SLOを評価する期間
  • SLI/SLO , Error Budgetの決め方
    • SLI :何らかの割合となるように値を定める
      • サービスや事業の目標と関連するような指標を定めるといい
      • サービスステークホルダー目線にもそったものにして、指標の状況に沿って開発の課題も向き合えるようにすると良い
    • SLO: 高い値を目指しすぎないこと
      • 開発速度とサービスの信頼性をうまくコントロールできるように値を調整
    • 大事なこと:サービスのステークホルダーや関係者と合意を取りながら決めること,決めたものを改善し続けること
  • Toil はSREのエンジニアリングの時間を奪うものになるので削減していく
    • ほっとくと増えるからSREの作業の50%未満になるように意識する
    • Toil はすべて解消しないと、仕事の時間を確保できないし、キャリアの停滞、燃え尽きなどの悪影響
      • 解消しなくてもいいものも多少はあることを受け入れる
  • ポストモーテムは組織全体がインシデントから学ぶフロー
    • ポストモーテムをかく基準や文化の醸成が必要
  • SRE プラクティスを組織に導入するためにきをつけること
    • SRE がエンジニアリングができるようにすること
  • 実践例として Embeded SRE がある
    • 開発チームに SRE が入ることで開発側からすると SRE の実践をそばで見れる
    • 開発チームの事情も SRE がチームに持ち帰れる

事業の成長と歩む、ABEMAのSRE探求の歴史

SRE のプラクティス実践における活動の中での行ってきたこと,振り返り,そこから改善したことをユースケースで知ることができました.SRE の実践は小さく初めて素早く失敗する大切さと関連するステークホルダーとの関係性を考えつつ進める必要があると感じた事例セッションでした.

sre-next.dev

メモ

  • ABEMA のサービス紹介からチームとして活動してきたことと今後について
  • SRE チーム発足の背景
    • 24/365だから障害時のインパクトが高い
    • 映像の通信トラフィックが多いので、物理的な限界を考慮する必要あり
    • 様々なデバイス対応しているため、デバイスに応じて品質維持
    • サービス、組織規模、システムの巨大化に伴いサービス品質維持しつつ、事業成長に伴ったシステムをスケールするためのチーム発足
  • 2018~2020年の活動
    • 横断的な活動をして、アジリティとプラクティスの導入をやった
      • マイクロサービスも非常に多くあったので,SRE だけで品質担保が難しく開発プロセスを含めていった(Production Rediness Checklist 作成)
      • キャパプラを開発チームに移譲
      • On-Callからの離脱(自律性向上)
      • SRE 文化の推進
    • 多くの課題が発生
      • 開発チームのリソースが確保できない
        • 開発チームのベネフィットを意識すること(アジリティと信頼性を保つ)
      • システム構成が少しずつ不明
      • リスク把握のコスト増
      • SRE チーム内で優先度が決めづらい
        • 兼務は難しい
  • 2021年〜現在の活動
    • 体制変更の実施
      • クラウド基盤のチームと SRE のチームを分離
      • 開発チームの中でも SRE の実践メンバーを抽出
    • SLI/SLOの先導
      • リクエスト数の少ないサービスでのアラート調整
      • 新しい計測手法の導入
      • 設定の簡略化
      • 効果としてサービス全体を俯瞰して品質が把握できるようになった
    • インシデント関連
      • インシデントへの参加やポストモーテムの先導を通して,インシデントフロー見直し,障害レベルの設定や障害を先導する Bot の開発
      • 効果として組織全体の障害への練度上昇
    • モニタリング課題の解決 *フロントエンドにおけるモニタリング強化するために要件,検証して New Relic 導入
      • 効果として広い範囲での可視化,アラート対応がフロンエンドエンジニアだけでできるようになってる
  • 今後として FIFA の無料放送を行うことになったので負荷対策や障害対策をしていく

LegalForceの契約データを脅かすリスクの排除と開発速度の向上をどうやって両立したか

プロダクトで重要なセキュリティの管理と開発のアジリティを維持しながら顧客への価値提供を行っていくための取り組みを紹介するセッションでした.セッション中に出てきた認知過負荷という言葉を初めて知り,組織スケールや扱うプロダクトの複雑性が増してくると発生しそうで早めに手を付けて改善しとかないと手がつけられなくなりそうだなと思いました.自分が遭遇したら改善や明瞭にすることを図っていきたいです.

sre-next.dev

  • 契約データの重要性
    • 三者へ漏洩すると犯罪に発展する可能性がある
    • インサイダーや詐欺などの悪用される
      • 契約データは最優先で保護する必要があるが、開発上の課題がある
  • 認知過負荷の課題
    • 変更に対するリスク制御が困難、リスク肥大化のおそれ
    • 変更時や動作確認テストの工数増大 -> デプロイ頻度低下 -> 顧客への価値提供低減
  • 認知過負荷に対する取り組み
    • 守るべきものの定義
      • PRR & Premortem(大きめの機能開発時に実施)
        • PRR:機密情報の有無、リスク
        • Premortem:扱う機密情報が漏洩しないかの議論
      • ガードレールの導入
        • AWSのサービスで実施(アカウント分離,SSO,監査ログ基盤に集約 etc)
      • 人の権限情報のコード化と自動デプロイ:誰でも閲覧・編集できるような状態にするため
      • 既存の権限内容の簡素化:条件分岐図と真理値表、論理式を書いて実装に落とす
        • 認知負担がへった
        • 環境差をなくす
  • 実践の効果
    • 開発者に体験向上した点をヒアリングして,認知的負荷の低減を確認

一人から始めるプロダクトSRE

プロタクト SRE のロールを持っているのは1人だけという状況で現場に合わせて意思決定を行ったり,目の前の課題解決,SRE 立ち位置の定め方,メンバーの巻き込み方を紹介のセッションでした.

sre-next.dev

資料

メモ

  • クラウド勤怠の場合
    • 最初のSREとしてはいった
    • 開発者はSREにコンバートする余裕はなく、経験している人もいない
  • 現状把握 *ドメイン知識やチーム状況を把握
    * チームの課題状況を観察する
    
    • 運用ペインが発生している可能性があるので理想と実態とのギャップを埋める
      • 無差別アラートによって開発者生産性が低下
      • 適切なモニタリングを行うのをやる
  • プロダクトチームへの安心してもらうための取り組み
    • SREの責務 -> どうプロダクトに関わらるのか、誤解があれば解消
    • 在り方を伝える -> ミッションを決める
    • SRE1人問題への向き合う
      • Core? Embederd? Enabling? => Enabling を選んで取り組んだ
  • Enabling SRE としてやってきたこと

まとめ

Day1 で参加したセッションとそのメモ,所感をまとめてみました.運営の皆さん,登壇された皆さん,お疲れさまでした!Day2 も楽しみ!

Day1 の公開された資料

直接セッションを見に行けてないですが,公開された資料のリンクもまとめていきます.