Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
SRENEXT2022 組織にSREを実装していくまでの道のり
Search
marnie0301
May 18, 2022
Technology
7.8k
2
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
SRENEXT2022 組織にSREを実装していくまでの道のり
marnie0301
May 18, 2022
More Decks by marnie0301
See All by marnie0301
EurekaのSREチームの実践してきた事と未来像
marnie0301
1
8.7k
[20210617 そろそろマネージド、クラウドネイティブで行こう! コンテナサービスへの移行祭り]Pairs, PairsエンゲージにおけるECS Fargateの移行・活用事例
marnie0301
1
370
平成最後なのでEC2からECS+Fargateに 置き換えた話
marnie0301
11
11k
Other Decks in Technology
See All in Technology
フルカイテン株式会社 エンジニア向け採用資料
fullkaiten
0
12k
なぜ「決定性」が 決定的に重要なのか? Durable Execution 基盤の数理的理解 #serverlessjp / ServerlessDays Tokyo 2026
ytaka23
3
1.1k
作って終わりじゃないサーバーレス 〜9年運用する大規模EC物流API基盤の設計・運用のリアル〜
zozotech
PRO
0
430
Genieを崇めよ
kameitomohiro
0
170
AIに任せた品質は、誰が見立てるのか - AI時代のテストマネジメント
nakanao
3
2.7k
Making AI Agents Safe and Fast- Jev, Obsidian, and the Meta-Harness
x5gtrn
PRO
0
110
aws-iot-platform-architecture-use-cases.pdf
ma2shita
0
500
AI時代の「技術的負債」の変質ー概念の終焉と再解釈、エージェントと共に向かう先
nwiizo
1
3.1k
AI 時代のスタートアップエコシステ厶から考究する技術的負債との向き合い方
m3m0r7
PRO
3
2.5k
C#コードの結合を可視化する Roslyn解析による設計改善と リファクタリング判断
dora56
0
330
GoのInterface内部構造から学ぶ!最高パフォーマンスを出すコード設計
yappli_developers
1
250
Goodbye ShellScript, Hello File-based App
shunsock
0
650
Featured
See All Featured
Unsuck your backbone
ammeep
672
58k
Become a Pro
speakerdeck
PRO
31
6.3k
Statistics for Hackers
jakevdp
799
230k
Design of three-dimensional binary manipulators for pick-and-place task avoiding obstacles (IECON2024)
konakalab
0
600
Thoughts on Productivity
jonyablonski
76
5.4k
A better future with KSS
kneath
240
18k
brightonSEO & MeasureFest 2025 - Christian Goodrich - Winning strategies for Black Friday CRO & PPC
cargoodrich
3
850
Designing for Timeless Needs
cassininazir
1
480
Agile Actions for Facilitating Distributed Teams - ADO2019
mkilby
0
280
The Limits of Empathy - UXLibs8
cassininazir
1
680
Taking LLMs out of the black box: A practical guide to human-in-the-loop distillation
inesmontani
PRO
3
2.4k
4 Signs Your Business is Dying
shpigford
187
23k
Transcript
© 2021 eureka, Inc. All Rights Reserved. 組織にSREを実装していくまでの道のり SRE NEXT
2022 2022年05月15日
© 2021 eureka, Inc. All Rights Reserved. About Me masashi.yamamoto
(@marnie0301) • 株式会社エウレカ ◦ 2015年に入社 ◦ 2017 機能開発チームからSREチームに移籍 ◦ 2020~ Head of SRE
© 2021 eureka, Inc. All Rights Reserved. 3 恋活・婚活マッチングアプリ オンライン結婚相談所サービス
真剣な交際・結婚を望むすべての人向け 1年以内の結婚を望むすべての人向け Pairsは日本で最も使われている恋活・婚活 マッチングアプリ 日本人特有の交際相手探し、恋愛に対する障壁を和らげ るために設計 24時間365日オペレーターが待機し公的身分証明書の 確認、お問い合わせ、パトロール監視に対応 登録からお相手の紹介まで全てスマホで利用可能 プロのコンシェルジュチームによる24時間サポート 毎月20名(紹介10名+検索10名)のお相手候補 出典:MMD研究所xスマートアンサー「2020年マッチングサービス ・アプリの利 ⽤実態調査」より
© 2021 eureka, Inc. All Rights Reserved. Agenda • 今日話すこと
◦ チーム立ち上げフェーズから数年間におけるSREチームの自身の取り組みの紹介(~2020) ◦ SREフェーズ移行期の到来と戦略の変更(2021~) • あまり話さないこと ◦ 各要素で扱われている技術についてはあまり深くふれません。
© 2021 eureka, Inc. All Rights Reserved. エウレカ SREチーム •
2017年に設立 • チームミッション(2017~2020) ◦ 会社の目指すビジネスの実現の阻害要因を”全て”排除する ▪ 99.95%の可用性を目標に、事業的な機会損失の最小化をめざす ▪ ブランドイメージ失墜につながるクリティカルなセキュリティリスクを撲滅する ▪ 運用の自動化及び自己修復可能なシステムを構築し、少数での運用体制を確立する ▪ 適切なキャパシティプランニングを行い、利益率向上へ寄与する ▪ 顧客価値提供を最速化する為のリリースエコシステムの改善と安定化をおこなう ▪ 事業価値最大化にむけた施策の技術サポートを行う
© 2021 eureka, Inc. All Rights Reserved. 2017~2020におけるSREの主な戦場と責務 • 機能開発以外ほとんど全部
• コーポレート関連やデータ関連も有り、結構煩 雑...
© 2021 eureka, Inc. All Rights Reserved. SREの文化の浸透云々の前にそもそも課題が山積み • スケールアウトが遅い・しんどい・つらい
◦ データストア(MySQL on EC2)のSlaveを追加する際は、サーバーにsshして心温まる手作業 ◦ DynamoDBはしょっちゅうスロットリング.. ◦ アプリケーションサーバーは起動後にAnsibleでレシピを流す形式,サービスインが長い(たまに壊れる) • 常時流れてるエラーログと良く鳴る狼アラート ... ◦ 慣れた人はいつも流れてるログを脳内でフィルタリング ◦ 心臓に悪い、反応できる人は特定の人だけ • その他、etcetc…,セキュリティ系のベストプラクティスへの追随や改善フロー構築、単一障害点なビルドサーバー、 飼い主不明のコンポーネント、カオスなネットワーク構成 …..
© 2021 eureka, Inc. All Rights Reserved. まずはSREチーム自身が運用負荷を減らし、未来の時間を作る • より柔軟なシステム構成への移行
◦ スケーラビリティ不足の解消 ▪ MYSQL on EC2 → Aurora ▪ Golden AMI Model,ECS Fargate移行+AutoScaling • 監視・オブザーバビリティ地盤づくり ◦ 徹底したエラーレベルの整理と不要なログの排除の実施 ◦ Datadog Dashboard、APMなど主要メトリクス整備 ◦ 狼アラートの再整備 • 運用コストの削減 ◦ 一部コンポーネントのサーバーレス移行 ◦ マネージドシステムの積極採用
© 2021 eureka, Inc. All Rights Reserved. 開発チームと協調した品質改善取組の試験運用 • パフォーマンス定点観測会のスタート
◦ バックエンド開発チームとSREチームが週次で行う改善サイクル(1h~2h) ▪ 週次のメトリクス確認(errorRate,データベース負荷,5xxの発生)などの重要指標を確認 ◦ 重要性に応じて原因分析と修正タスクを積み、余力で消化 • 一定の成果 ◦ 未成熟なマイクロサービスは目に見えてSLOを改善できた。 ◦ 一方で主要サービスはほとんどの場合達成していた。 • 1年近く続いた結果、休止 ◦ SLOを達成しているのに工数を支払い続ける判断基準が不明瞭なことによるモチベーションの低下 ▪ SLOが全量リクエストに対する失敗率なので、数が少ない重要操作が失敗しても修正が必要なものが検知でき ない。(SLOは達成できているが、普通に問題は起きていた。) ▪ SLOが正直役に立ってない。重要な問題は勘が良い人が掘り当てていた。
© 2021 eureka, Inc. All Rights Reserved. 改善が進む一方、綻びが目立ち始める • SREボトルネック問題
◦ 個人プレイの積み重ねが続いた結果、SREの特定の担当しか触れない領域が増える ◦ 拡大するシステム規模に対してカバーしきれない ▪ 機能しきらない移譲と改善サイクル ▪ 複数並列で起き続けるドメイン知識の必要な問題をチーム外から把握し続けるのは至難 ◦ 限られた人しかアラート対応できない • 外的要求への対応+広すぎる守備範囲によるリソースが枯渇 ◦ メンバーがセキュリティチームの立ち上げに奔走や大型プロジェクトに捕まったり.... (ひとり時代) ◦ 上記のボトルネックも加わりさらにスパイラル。 • 不明瞭なチームアイデンティティ ◦ SRE本来の活動が進まない事による葛藤・モチベーションダウン
© 2021 eureka, Inc. All Rights Reserved. • 順調に事業が成長していく前提において、システムは時間と共により高水準な事を求められていく ◦
複雑性、ワークロードやデータ量の規模、求められる信頼性やセキュリティなどの要求 ◦ 激化する競争で生き残る為の変更速度の維持 • 構成する各コンポーネントへのアップデートや変更要求は繰り返し行われるもの システム開発とその運用はそもそも長期戦
© 2021 eureka, Inc. All Rights Reserved. • そもそもSREに限らずエンジニア採用は難しい ◦
競争激化 ◦ 求める職掌が多いほど、難易度をさらに向上させる ◦ 開発チームの規模も拡大していく ▪ 開発ラインが並行する中、ライフサイクルの外から全てを把握し続けるするのは至難 人が足りないなら採用がんばればいいんじゃない? チーム戦略のアップデートが必要
© 2021 eureka, Inc. All Rights Reserved. ここまで(2017~2020)のSRE実施フェーズを振り返る • フェーズ1
消化活動 → フェーズ2 門番 (Seeking SRE 22.4から引用) • 問題自体を減らす事による悪循環からの脱出 • プロダクトリリースに対する確認や干渉 • SREの取り組みはほぼ全てチームに集約されている。 ◦ ゆえにスケーラブルではないし、ボトルネックにもなっていた。
© 2021 eureka, Inc. All Rights Reserved. チームではなく組織でSREを実践していくフェーズへの移行 • 門番ではなく、パートナー・触媒としての役割への移行
(Seeking SRE 22.4から引用) • 共通の指標を一緒に守っていくパートナーシップの関係 • SLOの再構築(本スライドでは割愛) • 自分たちで全てを守らない • 組織にSREの機能をインストールするフェーズへの移行 • SRE機能のガイドとそれを実現するプラットフォーム化をチームの焦点におく
© 2021 eureka, Inc. All Rights Reserved. Vision,Mission,Valueの再定義 • Vision
◦ 自律的にリライアビリティとアジリティを両立するプロダクト開発組織の実現 • Mission ◦ SREプラクティスを開発組織にインストールする • Value ◦ Metrics First ◦ Draw a Blueprint ◦ No Blame ◦ Learning Animal ◦ Change Agent
© 2021 eureka, Inc. All Rights Reserved. Mission達成のための取り組み全体像
© 2021 eureka, Inc. All Rights Reserved. インストールするべきSRE機能 • SLI/SLO
• Monitoring/Alert • Capacity Planning • Incident Response & Postmotem • Peformance analysis & Optimization
© 2021 eureka, Inc. All Rights Reserved. インストールの実現方法 • Install
SRE • SREアセスメント • プロダクション環境チェックシート • Enabling & Embed SRE • Platform Engineering • SLO,Monitoring/Alert の運用を支援するメトリクス収集基盤の構築・運用 • Capacity Planningを支援するためのLoadTestを簡単に行える基盤整備 • インシデント対応~ポストモーテム完了までのタイムライン管理をChatOpsのインターフェースでの提供 • パフォーマンス最適化を行うための観測情報やアプローチの整備 • 移譲やセルフサービス化に適した技術の採用(Policy as Code,etc) • などなど
© 2021 eureka, Inc. All Rights Reserved. 実現の為のリソース戦略と開発組織の協力 • 外部向け工数とシステム改善・仕組み作りの工数を分離
◦ 40%は外部工数,10%はToil/日常運用,50%はシステム改善とSREとしての取り組みに充当させる ▪ Toil工数が10%を超えるようなら、Toil改善に力を傾ける ▪ 外部工数がこれ以上必要でも、内部工数からは削らない(必要なら採用) • 他チームへの責務譲渡 ◦ 直接的な機能開発・問い合わせ対応は開発チームに移譲。 ◦ コーポレート関係をコーポレートチームに移譲。 ◦ データ関連は新設したデータマネージメントチームに移譲。 ▪ ➡ チームではなく、技術組織全体の理解と協力と採用活動の結果
© 2021 eureka, Inc. All Rights Reserved. まとめ • チームの役割やリソース戦略は組織や事業の規模に合わせてアップデートしていく事が望ましい
◦ 結局地道な積み重ね ◦ まずは自分たちが小さく実践を繰り返し、プラクティスや課題感への習熟を深める ◦ SREはチーム完結ではなく、開発組織全体の理解と協調が必要 • 取り組みはまだまだ始めたばかりなので、また年内目処にアウトプットできたら... :)
© 2021 eureka, Inc. All Rights Reserved. 前半部分の取り組みの歴史や変遷をより詳しく知りたい方はこちら :) https://speakerdeck.com/marnie0301/eurekafalsesretimufalseshi-jian-sitekitashi-towei-lai-xiang
© 2021 eureka, Inc. All Rights Reserved. SLO改善・再構築の別スライドもぜひ :) https://speakerdeck.com/takumiogawa/slozai-ding-yi
© 2021 eureka, Inc. All Rights Reserved. セルフサービス化の取り組み資料 https://speakerdeck.com/fukubaka0825/steps-toward-self-service-operations-in-eureka-at-sre-next-2022-1-da1455f1-f727-4d73-84e5 -ced5ae517202
© 2021 eureka, Inc. All Rights Reserved.