Upgrade to Pro — share decks privately, control downloads, hide ads and more …

プロダクト全体で取り組むSREing イシューから始める信頼性・生産性向上の実践/SRE NE...

プロダクト全体で取り組むSREing イシューから始める信頼性・生産性向上の実践/SRE NEXT 2024

2024年8月3日より開催された「SRE NEXT 2024 IN TOKYO」の登壇資料です。
https://sre-next.dev/2024/

▼関連資料
ユーザー数100万人規模の事業成長を止めずに、レガシーコードと戦う
https://speakerdeck.com/visional_engineering_and_design/jjug-ccc-2022-fall

職能を越えた連携で「目先の数字に囚われないSQLチューニング」を実現する
https://engineering.visional.inc/blog/535/essential-sql-tuning/

-----
Visionalのエンジニアリングに関する最新情報はX、ブログで発信しています!📣

▼Visional Engineering Blog
https://engineering.visional.inc/blog/

▼VISIONAL ENGINEERING / X
https://twitter.com/VISIONAL_ENG

More Decks by Visional Engineering & Design

Other Decks in Technology

Transcript

  1. 菊池 信太郎
 
 2012〜 株式会社ニトリ
 • 店舗 / 物流でトラブルシューティングしたり、現場の改善を回したり 


    2014〜 SIer
 • 受託開発やSESで複数プロジェクト経験 
 • テックリード・PM・EMとして開発経験を積む 
 2018〜 株式会社ビズリーチ 
 • ビズリーチサービスの toBプロダクトを中心に開発 
 • EMとしてリアーキテクティングの推進、組織横断プロジェクトなどのリード 
 • 現在はリクルーティングプロダクト本部プラットフォーム開発部部長 
 
 麻雀と読書が好き。
 最近は3歳児に毎日翻弄されています。 
 2 自己紹介

  2. • インシデント対応プロセスを整備する 
 • QAチームを組閣し、フェーズゲートとする 
 • ポストモーテムを通じて根本原因を改善する 
 セキュリティリスクを抱え

    ているものはないか? 
 障害件数が多い
 16 「応急処置すべき緊急度の高いリスク」をイシュー分析した例
 潜在的なリスクはなに か?
 障害発生に正しく気づけ るか?
 イシュー
 • モニタリングを機能させる 
 ◦ エラーログを減らす
 ◦ アラートを設計する
 サブイシュー
 アクション
 • 構造的に脆弱性の多い Web Application Frameworkを入 れ替え
 • 継続的にEOL対応を実施する
 すでに顕在化しているリ スクはなにか?
 表示速度が3秒以上か かっている画面が存在す る
 • レスポンスタイムが3秒以上の画面を修正する 
 ◦ スロークエリ改善
 ◦ n+1対応
 ◦ テーブルリファクタリング 

  3. • 技術・組織の改善はすでに計画されていたため、ここではプロセスにフォーカス
 • 誰がプロセス改善を実行するか?
 ◦ チームを横断するプロセス改善は調整コストが高く優先順位が上がりづらい構造がある
 ◦ SRE、QAのSETから一部メンバーを異動して、「プロセスエンジニアリンググループ」を組成
 • クロスファンクショナルな小さなチームを構成し、意思決定を

    素早くできるようにする 
 • DevOpsのケイパビリティを上げる 
 プロセス
 • リアーキテクティング、リライトによって変更容易性、テスト容 易性を獲得する
 20 イシューの見極め
 改善サイクルを早くする には?
 技術
 イシュー
 サブイシュー
 アクション
 組織
 • リリースプロセスのボトルネックをなくし、リリース頻度を上げ られるようにする

  4. • リリースエンジニアの手作業をなくす、自動化する 
 • 変更承認プロセスを最適化する 
 • バッチ処理を止めなくてもリリース可能にする 
 QA期間を短縮する


    • 手動シナリオテストを自動化した E2Eテストに置き換える
 • テストピラミッドを形成するため、 E2Eテストではなく、なるべく 単体テストやAPIテストに寄せる(リアーキで段階的に実現) 
 23 可視化されたボトルネックを踏まえ、イシュー分析
 リリースプロセスにおける ボトルネックはなにか? 
 手動シナリオテストをなく す
 イシュー
 サブイシュー
 アクション
 リリースエンジニアの作 業を減らす
 • 開発チームにインプロセス QAを入れることで、開発チームの 外で実施しているQAテストをシフトレフトする 

  5. E2Eテスト自動化を最優先
 • なぜなら複数の問題を同時に解決できるから
 • 開発者体験が改善され、アジリティを手に入れることができる
 • 安心してコード変更できるようになり、ライブラリアップデートやEOL対応にも役立つ
 
 インプロセスQAは着手自体は早かったが、体制構築に時間がかかった
 •

    採用するとなると、リードタイムとして半年は見ておく必要がある
 • シフトレフトが定着するのもある程度時間がかかる
 
 リリースエンジニアの手作業を減らし、リリースプロセスを実際変えるのは最後
 • 手作業が減ること自体のインパクトはそこまで大きくなかった
 • 内部統制のことを考慮する必要もあり、一気に進める必要があった
 • デプロイを完全自動化するにはバッチアーキテクチャの載せ替えが必要だったため後回し
 24 優先順位のつけ方:重要なもの、効果が高いものにフォーカス

  6. 主な成果
 • 手作業をなくしていったことで、リリース作業が効率化
 • リリース1回あたりのバッチサイズが小さくなった
 • QAのシフトレフトが起こり、テスト分析を開発プロセスの中で実施できている
 • E2Eテストが整備されたことでライブラリのバージョンアップなどが気軽にしやすくなった
 


    今後の展望
 • デプロイが完全自動化できていないので、次はそのボトルネックを取り除きたい
 • CI/CDの改善で、より短時間で開発サイクルを回せるようにしていきたい
 • リアーキテクティングで段階的に内部品質を上げることによって、開発のリードタイム短縮を狙いに行く
 25 成果:リリースプロセスが効率化され、リリース頻度が2倍に

  7. 分析の結果、特に採用活動が活発なお客様ほど表示速度の問題が顕著になることが判明
 • 定性分析:
 ◦ カスタマーサクセスを通じ、お客様からのフィードバックを回収
 ◦ 自ら実際に利用し、期待の速度に対して遅い表示画面を特定
 • 定量分析:
 ◦

    Datadog等を用いて、各エンドポイントごとのLatencyを計測し、モニタリング
 ◦ BigQueryに集約しているサービスデータとDatadogのデータを突合し、お客様の属性と利用状況に基づい て速度をモニタリング
 28 現状分析
 各エンドポイントごとのLatency等をまとめた信頼性ダッシュボード

  8. SRE以外のポジションも募集中!
 • ソフトウェアエンジニア
 • エンジニアリングマネジャー
 • QAエンジニア
 • MLエンジニア
 •

    MLOpsエンジニア
 32 本質的な課題解決を志向するSREを絶賛募集中!
 https://hrmos.co/pages/hrmos/jobs/3100100100963/apply
 カジュアル面談はこちらから Engineering Blog https://engineering.visional.inc/blog/

  9. SRE
 • O'Reilly Japan - SRE サイトリライアビリティエンジニアリング 
 • SRE

    - エンタープライズ ロードマップ
 イシュー
 • イシューからはじめよ ――知的生産の「シンプルな本質」 | 安宅和人 | ビジネス教育 | Kindleストア | Amazon
 • 【マッキンゼーの思考法を実際のビジネスでどう使うか①】仕事が 10倍早くなる「イシューの定め方」/イシューとはカギとなる問い/会議の生産 性が見違える/ヒカルさんとのコラボを例に解説【ロコンド田中 CEO】
 • イシューからはじめる FF10【前編】 | ドラクエ好きに悪い人はいない 
 VSM
 • 組織内でバリュー・ストリーム・マッピング (VSM) の宣教師をやってみてわかった、 VSMを組織に広める3つのポイント - Speaker Deck
 資料内で引用した過去の弊社事例 
 • ユーザー数100万人規模の事業成長を止めずに、レガシーコードと戦う / JJUG CCC 2022 Fall - Speaker Deck
 • 職能を越えた連携で「目先の数字に囚われない SQLチューニング」を実現する - Visional Engineering Blog
 34 参考にしたもの

  10. 35