以下の内容はhttps://ozaki25.hatenadiary.jp/entry/2025/01/26/174318より取得しました。

「SRE Kaigi 2025」に参加してきました

勉強会メモ

SRE、開発、QAが協業して挑んだリリースプロセス改革

宮後 啓介さん(ニーリー)
https://speakerdeck.com/nealle/sre-kai-fa-qagaxie-ye-sitetiao-ndaririsupurosesugai-ge-at-sre-kaigi-2025

  • 過去の課題
    • デプロイ頻度の低さ
      • 月に2-5
    • 変更障害率の高さ
      • 40%くらい
  • 開発-運用までのプロセスを改革していった
  • ゼロダウンタイムでのリリース
  • Feature環境導入
    • 開発環境へのマージ前にクラウド上にあげて確認できる環境
    • PRトリガーで構築
    • PR閉じたり定期的なタイミングで削除
  • 開発DBを自動複製
    • Feature環境と開発環境のDBを共有していた
    • 変更はいるときに手動複製していた
    • PR単位で専用DB構築するようにした
  • テストでの本番データ利用
    • 複雑なテストデータの準備が大変だった
    • データの自動マスキング
    • 外部への通信を遮断
  • テストをパラレルに
    • 開発チームのテストとQAのテストを並行して実施できるように
    • Feature環境を活用して
  • リリーストグル
    • デプロイと機能の有効化をフラグで切り替える
    • トグルを横断して確認できるダッシュボード
    • 不要トグルを検知して複雑になってるコードを消していく
  • 今後の改善
    • stgに変更をためてまとめてリリースしてる
    • チーム間の調整など発生しているから解消したい

一人から始めたSREチーム3年間の歩み -求められるスキルの変化とチームのあり方-

VTRyoさん(マネーフォワード)
https://speakerdeck.com/vtryo/the-three-year-journey-of-the-sre-team-which-started-all-by-myself

  • 各部署特化のSREチームとその他を見る横断のSREチーム
  • SREの取り組み
    • 最初は開発チームに入ってSREっぽいことをやった
      • アラート設計見直し
      • ダッシュボード作成
      • ミッション/ビジョンを早めに作った
        • 採用なども見据えて
    • 人が少し増えて各人が複数チームを担当するような体制
      • フェーズの違う複数の課題が起きていた
      • 1人が休むとその担当先の進捗が0になってしまう
      • Embeddedでは無理なのでEnablingに
    • さらに拡大してチームとして各プロダクトの対応をできる状態に
      • 専門性の高いメンバーが増えた
        • 経験が浅い領域にチャレンジできるようになった
      • 緊急ではないが重要なこと
      • 将来発生する問題への検討
        • データの肥大化
      • SREチームと開発チームの距離
        • 双方の規模拡大に伴い関係性が薄くなる
        • リリース情報を全部把握できなくなった
        • プロダクトの懸念を敏感にきゃっちできなくなった
        • 言葉だけでは人の入れ替えで文化は残らない
          • 仕組みで残すのが大切
        • 依頼に対応してるだけだと作業員感が強くなってしまう
  • SRE個人として
    • 自分がどのフェーズで活躍できるかわからなくなる
    • 立ち上げ/拡大/安定フェーズ
    • 得意なフェーズが異なる人が混ざってる方が価値観があわさっていい

サービスローンチを成功させろ！〜SREが教える30日間の攻略ガイド〜

松田正也さん
https://speakerdeck.com/mmmatsuda/sabisurontiwocheng-gong-sasero-sregajiao-eru30ri-jian-nogong-lue-gaido

  • ローンチ前にSREがやること
    • パフォーマンス
      • 想定リクエスト数を目標レイテンシでさばけるか
      • 負荷試験が行われている？
    • 耐障害性
      • 単一障害点はないか
    • 監視設定
      • 監視、アラート、ログ監視、Trace
      • SaaSを使っていればその設定
    • インデント管理体制
      • 障害対応フローなど
      • 人員の確保や体制構築
    • セキュリティ対応状況
      • 診断、脆弱性対応、個人情報管理
    • ドキュメント整備
      • 運用に必要なドキュメントがあるか、周知やレビューされているか
    • キャパシティプランニング
      • コスト最適化
      • 需要拡大時のパフォーマンス維持
    • これらをシフトレフトして対応できる体制を目指す
  • Production Readiness Checklist
    • サービスが本番稼働可能な状態になってるかのチェックリスト

どうやればインシデント対応能力を鍛えられるのか？

髙石 諒さん
https://speakerdeck.com/takaishi/sre-kaigi-2025

  • インシデント
    • 定義はコンテキストによって様々
    • ここではユーザに影響が出る/出る可能性のある障害
  • インシデント対応
    • 影響を最小限に抑えて信頼性を維持
    • 原因特定/暫定対応
    • 高級対応/再発防止
    • 社内外とのやりとり
    • ポストモーテム
    • などなど
  • インシデント対応に必要なスキルは多様
    • ハードスキル
      • プログラミングスキル
      • DB/Linux/各種ツール等々
      • 時代とともに移り変わるし、職場やチームに寄っても必要なスキルは変わる
      • 可搬性の高いもの
        • データベーススキル
        • Linuxオペレーション
        • ターミナルオペレーション
    • ソフトスキル
      • 社内のステークホルダーへの情報共有
      • 各メンバーの役割の明確化
      • リーダーシップ/判断/決断
      • どの組織でも重要
      • 体制を整えられるスキルも重要
    • 対応経験
      • 経験を積むのが難しくなってる
        • システムやインフラの進化で障害発生しにくくなってる
        • 自動修復されるものも
        • 人間が対応しないといけないトラブルは難易度が高い
      • 擬似的な経験
        • シャドーイング
          • 経験豊富なメンバーの対応を観察して学ぶ
          • 観察だけで対応はしないので責任は発生しない
        • 障害対応訓練
          • 開発環境などで障害を発生させて経験を積む
          • 効果は高いが準備など考えるとコスト高め
    • システム理解
      • 対象システムについての理解度
      • アーキテクチャー/設計/データベース/ドメイン知識/過去の経緯
      • いくらその他のスキルがあってもシステム理解がないと対応は難しい

Improving Incident Response using Incident Key Metrics

髙村成道さん
https://speakerdeck.com/nari_ex/improving-incident-response-using-incident-key-metrics

  • MTTRの問題点
    • 平均復旧時間
    • 障害発生から復旧するまでの平均時間
    • FourKeysの1つ
    • TTRを短縮してもMTTRは改善しないという検証結果
      • ブラックスワンイベントがあると指標の数値が変わってしまう
      • 変動が少ない指標でないと目的にあわない
    • MTTRは大雑把なので課題発見の糸口として使うくらいがいい
  • TTX
    • 網羅的/粒度が細かい/収集できる
    • 発生/検知/認知/チーム構成/解決策特定/緩和/復旧/解決/完了
    • どのステップまでの時間をとるといいか

2,000万ユーザーを支えるSREチームの6年間のスクラムのカイゼン

HonMarkHuntさん
https://speakerdeck.com/honmarkhunt/2500mo-yuzawozhi-erusretimuno6nian-jian-nosukuramunokaizen

  • SREでスクラム
    • 6人の独立したSREチーム
    • バックログを優先度順に並べてスプリント回していった
    • 個人ごとにアサインして各自が消化していたのでスプリントが効果的でなかった
    • 差し込みが多くて予定通りに進まない
      • 問い合わせ
      • インシデント
    • SREのタスクをユーザーストーリーにしにくい
    • バックログ上にhowのわかりきった運用とわかっていないストーリーが乱立
      • 大きいタスクで止まってそこが属人化
    • 中長期の目標が立てにくい
      • 振り返ってEOL対応ばっかやってたとか
  • 差し込みが多い
    • プラットフォーマーとしてのタスクやアラート/インシデントなど避けられないものが多い
    • 計画通りに進められないとベロシティが安定しない
    • スプリントゴールが達成できない
    • 一定あるものとして受け入れるしかない
  • バックログに性質が違うものが並ぶ
    • PO/PdMがいない
    • バックログで管理するものとそうでないものを分けた
      • howのわかりきったものは別で管理
  • 中長期の目標を描きづらい
    • スプリントからの積み上げを意識する
    • MVVからブレイクダウンする

AWSにおける横断的なログ分析とコストの管理

山北 尚道さん
https://speakerdeck.com/naomichi/awsniokeruheng-duan-de-narogufen-xi-to-kosutonoguan-li

  • オブザーバビリティを高めるにはログの一元管理は重要
    • コストとの兼ね合い
    • 役割に応じて必要なところに配置
      • 監査ログ
      • イベントログ
  • EventBridge+Lambdaでだいたいのサービスのログを収集できる
    • ログが数十分で消えるサービスもあるから
  • AWS Cost Explorer
    • 13ヶ月分の請求を確認できる
    • アラートも設定できるが細かくやろうと思うと大変
    • 複数サービス組み合わせて構築しないといけなかったり

Platform EngineeringがあればSREはいらない!? 新時代のSREに求められる役割とは

渋谷 充宏さん/那珂 将人さん
https://speakerdeck.com/mshibuya/platform-engineeringgaarebasrehairanai-xin-shi-dai-nosreniqiu-merareruyi-ge-toha

  • Platform Engineering
    • セルフサービス型の開発者プラットフォームの構築運用
    • バックエンドとインフラの一部がプラットフォームによって提供される
    • 構造が変わってもSREの役目はある
  • プラットフォームがある中での開発
    • 認知不可が高い
      • 提供される・ツールやサービスが多岐にわたる
      • ツールやサービスの進化のはやさ
    • ツール間の非互換
    • 日々のメンテや組み合わせによる試行錯誤で生産性が低下
    • プラットフォームと開発の橋渡しとしてのSRE

その他



以上の内容はhttps://ozaki25.hatenadiary.jp/entry/2025/01/26/174318より取得しました。
このページはhttp://font.textar.tv/のウェブフォントを使用してます
不具合報告/要望等はこちらへお願いします。
モバイルやる夫Viewer Ver0.14