タダです.
SRE NEXT 2022 の Day1 参加レポートを書いていきます.自分が聞いたセッションでのメモを転記しながら感想を書きますが,私用の関係で最後まで参加できていないところがあります 🙇
- How We Foster "Reliability" in Diversity
- SRE の歩き方・始め方
- 事業の成長と歩む、ABEMAのSRE探求の歴史
- LegalForceの契約データを脅かすリスクの排除と開発速度の向上をどうやって両立したか
- 一人から始めるプロダクトSRE
- まとめ
How We Foster "Reliability" in Diversity
SRE as Service で他社の SRE プラクティスを実践してきた経験からどのように組織で SRE を実践.組織に適した SRE を定義して育てていくための取り組みの紹介するお話でした.SRE の実践の5つのステップは自分が体感したものと合致したので納得感があったり,組織変革のためのアプローチで MVV の作成や環境変化に伴うためのアプローチで組織の多様性が役立つというのは新たな気づきを与えてもらったセッションでした.
資料
メモ
- 適切な SRE の実践がなぜ難しいのか
- 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とはなにか？
- SRE は 2004年からGoogleにチームが発足
- サーバー/MW のセットアップをソフトウェアの課題として扱う
- オペレーションに正しくエンジニアリングを取り入れて改善し続けること
- システムが安定してればいいというのではなく,数字でコントロールする
- 手作業を行わず自動化してサービスをスケールさせていく(人を増やすのではなく)
- SRE と DevOps の関係とは？
class SRE implements DevOpsを踏まえ、どういう形で SRE の実践・プラクティスを実践するか- SLI/SLO & Error Budget -> 信頼性のプラクティス,Window: SLI/SLOを評価する期間
- SLI/SLO , Error Budgetの決め方
- Toil はSREのエンジニアリングの時間を奪うものになるので削減していく
- ほっとくと増えるからSREの作業の50%未満になるように意識する
- Toil はすべて解消しないと、仕事の時間を確保できないし、キャリアの停滞、燃え尽きなどの悪影響
- 解消しなくてもいいものも多少はあることを受け入れる
- ポストモーテムは組織全体がインシデントから学ぶフロー
- ポストモーテムをかく基準や文化の醸成が必要
- SRE プラクティスを組織に導入するためにきをつけること
- SRE がエンジニアリングができるようにすること
- 実践例として Embeded SRE がある
- 開発チームに SRE が入ることで開発側からすると SRE の実践をそばで見れる
- 開発チームの事情も SRE がチームに持ち帰れる
事業の成長と歩む、ABEMAのSRE探求の歴史
SRE のプラクティス実践における活動の中での行ってきたこと,振り返り,そこから改善したことをユースケースで知ることができました.SRE の実践は小さく初めて素早く失敗する大切さと関連するステークホルダーとの関係性を考えつつ進める必要があると感じた事例セッションでした.
メモ
- ABEMA のサービス紹介からチームとして活動してきたことと今後について
- SRE チーム発足の背景
- 2018~2020年の活動
- 2021年〜現在の活動
- 体制変更の実施
- クラウド基盤のチームと SRE のチームを分離
- 開発チームの中でも SRE の実践メンバーを抽出
- SLI/SLOの先導
- リクエスト数の少ないサービスでのアラート調整
- 新しい計測手法の導入
- 設定の簡略化
- 効果としてサービス全体を俯瞰して品質が把握できるようになった
- インシデント関連
- インシデントへの参加やポストモーテムの先導を通して,インシデントフロー見直し,障害レベルの設定や障害を先導する Bot の開発
- 効果として組織全体の障害への練度上昇
- モニタリング課題の解決
*フロントエンドにおけるモニタリング強化するために要件,検証して New Relic 導入
- 効果として広い範囲での可視化,アラート対応がフロンエンドエンジニアだけでできるようになってる
- 体制変更の実施
- 今後として FIFA の無料放送を行うことになったので負荷対策や障害対策をしていく
LegalForceの契約データを脅かすリスクの排除と開発速度の向上をどうやって両立したか
プロダクトで重要なセキュリティの管理と開発のアジリティを維持しながら顧客への価値提供を行っていくための取り組みを紹介するセッションでした.セッション中に出てきた認知過負荷という言葉を初めて知り,組織スケールや扱うプロダクトの複雑性が増してくると発生しそうで早めに手を付けて改善しとかないと手がつけられなくなりそうだなと思いました.自分が遭遇したら改善や明瞭にすることを図っていきたいです.
- 契約データの重要性
- 第三者へ漏洩すると犯罪に発展する可能性がある
- インサイダーや詐欺などの悪用される
- 契約データは最優先で保護する必要があるが、開発上の課題がある
- 認知過負荷の課題
- 変更に対するリスク制御が困難、リスク肥大化のおそれ
- 変更時や動作確認テストの工数増大 -> デプロイ頻度低下 -> 顧客への価値提供低減
- 認知過負荷に対する取り組み
- 守るべきものの定義
- PRR & Premortem(大きめの機能開発時に実施)
- PRR:機密情報の有無、リスク
- Premortem:扱う機密情報が漏洩しないかの議論
- ガードレールの導入
- AWSのサービスで実施(アカウント分離,SSO,監査ログ基盤に集約 etc)
- 人の権限情報のコード化と自動デプロイ:誰でも閲覧・編集できるような状態にするため
- 既存の権限内容の簡素化:条件分岐図と真理値表、論理式を書いて実装に落とす
- 認知負担がへった
- 環境差をなくす
- PRR & Premortem(大きめの機能開発時に実施)
- 守るべきものの定義
- 実践の効果
- 開発者に体験向上した点をヒアリングして,認知的負荷の低減を確認
一人から始めるプロダクトSRE
プロタクト SRE のロールを持っているのは1人だけという状況で現場に合わせて意思決定を行ったり,目の前の課題解決,SRE 立ち位置の定め方,メンバーの巻き込み方を紹介のセッションでした.
資料
メモ
- クラウド勤怠の場合
- 最初のSREとしてはいった
- 開発者はSREにコンバートする余裕はなく、経験している人もいない
- 現状把握
*ドメイン知識やチーム状況を把握
* チームの課題状況を観察する- 運用ペインが発生している可能性があるので理想と実態とのギャップを埋める
- 無差別アラートによって開発者生産性が低下
- 適切なモニタリングを行うのをやる
- SLI/SLO策定
- ダッシュボードの構築
- 運用ペインが発生している可能性があるので理想と実態とのギャップを埋める
- プロダクトチームへの安心してもらうための取り組み
- SREの責務 -> どうプロダクトに関わらるのか、誤解があれば解消
- 在り方を伝える -> ミッションを決める
- SRE1人問題への向き合う
- Core? Embederd? Enabling? => Enabling を選んで取り組んだ
- Enabling SRE としてやってきたこと
- メンバーの活動をフォローや感謝を送る
- システムダッシュボード振り返り会
- 工数の調整と優先度付(dely さんの取り組みを参考)
- 人として信頼されること
まとめ
Day1 で参加したセッションとそのメモ,所感をまとめてみました.運営の皆さん,登壇された皆さん，お疲れさまでした！Day2 も楽しみ！
Day1 の公開された資料
直接セッションを見に行けてないですが,公開された資料のリンクもまとめていきます.
