SRENEXT2022 組織にSREを実装していくまでの道のり

by marnie0301

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

© 2021 eureka, Inc. All Rights Reserved. 3 恋活・婚活マッチングアプリオンライン結婚相談所サービス真剣な交際・結婚を望むすべての人向け 1年以内の結婚を望むすべての人向け Pairsは日本で最も使われている恋活・婚活マッチングアプリ日本人特有の交際相手探し、恋愛に対する障壁を和らげるために設計 24時間365日オペレーターが待機し公的身分証明書の確認、お問い合わせ、パトロール監視に対応登録からお相手の紹介まで全てスマホで利用可能プロのコンシェルジュチームによる24時間サポート毎月20名(紹介10名+検索10名)のお相手候補出典：MMD研究所xスマートアンサー「2020年マッチングサービス・アプリの利⽤実態調査」より  

Slide 4

Slide 4 text

Slide 5

Slide 5 text

© 2021 eureka, Inc. All Rights Reserved. エウレカ SREチーム ● 2017年に設立 ● チームミッション(2017~2020) ○ 会社の目指すビジネスの実現の阻害要因を”全て”排除する ■ 99.95%の可用性を目標に、事業的な機会損失の最小化をめざす ■ ブランドイメージ失墜につながるクリティカルなセキュリティリスクを撲滅する ■ 運用の自動化及び自己修復可能なシステムを構築し、少数での運用体制を確立する ■ 適切なキャパシティプランニングを行い、利益率向上へ寄与する ■ 顧客価値提供を最速化する為のリリースエコシステムの改善と安定化をおこなう ■ 事業価値最大化にむけた施策の技術サポートを行う

Slide 6

Slide 6 text

Slide 7

Slide 7 text

© 2021 eureka, Inc. All Rights Reserved. SREの文化の浸透云々の前にそもそも課題が山積み ● スケールアウトが遅い・しんどい・つらい ○ データストア(MySQL on EC2)のSlaveを追加する際は、サーバーにsshして心温まる手作業 ○ DynamoDBはしょっちゅうスロットリング.. ○ アプリケーションサーバーは起動後にAnsibleでレシピを流す形式,サービスインが長い（たまに壊れる) ● 常時流れてるエラーログと良く鳴る狼アラート ... ○ 慣れた人はいつも流れてるログを脳内でフィルタリング ○ 心臓に悪い、反応できる人は特定の人だけ ● その他、etcetc…,セキュリティ系のベストプラクティスへの追随や改善フロー構築、単一障害点なビルドサーバー、飼い主不明のコンポーネント、カオスなネットワーク構成 …..

Slide 8

Slide 8 text

© 2021 eureka, Inc. All Rights Reserved. まずはSREチーム自身が運用負荷を減らし、未来の時間を作る ● より柔軟なシステム構成への移行 ○ スケーラビリティ不足の解消 ■ MYSQL on EC2 → Aurora ■ Golden AMI Model,ECS Fargate移行+AutoScaling ● 監視・オブザーバビリティ地盤づくり ○ 徹底したエラーレベルの整理と不要なログの排除の実施 ○ Datadog Dashboard、APMなど主要メトリクス整備 ○ 狼アラートの再整備 ● 運用コストの削減 ○ 一部コンポーネントのサーバーレス移行 ○ マネージドシステムの積極採用

Slide 9

Slide 9 text

© 2021 eureka, Inc. All Rights Reserved. 開発チームと協調した品質改善取組の試験運用 ● パフォーマンス定点観測会のスタート ○ バックエンド開発チームとSREチームが週次で行う改善サイクル(1h~2h) ■ 週次のメトリクス確認(errorRate,データベース負荷,5xxの発生)などの重要指標を確認 ○ 重要性に応じて原因分析と修正タスクを積み、余力で消化 ● 一定の成果 ○ 未成熟なマイクロサービスは目に見えてSLOを改善できた。 ○ 一方で主要サービスはほとんどの場合達成していた。 ● 1年近く続いた結果、休止 ○ SLOを達成しているのに工数を支払い続ける判断基準が不明瞭なことによるモチベーションの低下 ■ SLOが全量リクエストに対する失敗率なので、数が少ない重要操作が失敗しても修正が必要なものが検知できない。(SLOは達成できているが、普通に問題は起きていた。) ■ SLOが正直役に立ってない。重要な問題は勘が良い人が掘り当てていた。

Slide 10

Slide 10 text

© 2021 eureka, Inc. All Rights Reserved. 改善が進む一方、綻びが目立ち始める ● SREボトルネック問題 ○ 個人プレイの積み重ねが続いた結果、SREの特定の担当しか触れない領域が増える ○ 拡大するシステム規模に対してカバーしきれない ■ 機能しきらない移譲と改善サイクル ■ 複数並列で起き続けるドメイン知識の必要な問題をチーム外から把握し続けるのは至難 ○ 限られた人しかアラート対応できない ● 外的要求への対応+広すぎる守備範囲によるリソースが枯渇 ○ メンバーがセキュリティチームの立ち上げに奔走や大型プロジェクトに捕まったり.... (ひとり時代) ○ 上記のボトルネックも加わりさらにスパイラル。 ● 不明瞭なチームアイデンティティ ○ SRE本来の活動が進まない事による葛藤・モチベーションダウン

Slide 11

Slide 11 text

© 2021 eureka, Inc. All Rights Reserved. ● 順調に事業が成長していく前提において、システムは時間と共により高水準な事を求められていく ○ 複雑性、ワークロードやデータ量の規模、求められる信頼性やセキュリティなどの要求 ○ 激化する競争で生き残る為の変更速度の維持 ● 構成する各コンポーネントへのアップデートや変更要求は繰り返し行われるものシステム開発とその運用はそもそも長期戦

Slide 12

Slide 12 text

Slide 13

Slide 13 text

© 2021 eureka, Inc. All Rights Reserved. ここまで(2017~2020)のSRE実施フェーズを振り返る ● フェーズ1 消化活動 → フェーズ2 門番 (Seeking SRE 22.4から引用) ● 問題自体を減らす事による悪循環からの脱出 ● プロダクトリリースに対する確認や干渉 ● SREの取り組みはほぼ全てチームに集約されている。 ○ ゆえにスケーラブルではないし、ボトルネックにもなっていた。

Slide 14

Slide 14 text

© 2021 eureka, Inc. All Rights Reserved. チームではなく組織でSREを実践していくフェーズへの移行 ● 門番ではなく、パートナー・触媒としての役割への移行 (Seeking SRE 22.4から引用) ● 共通の指標を一緒に守っていくパートナーシップの関係 ● SLOの再構築(本スライドでは割愛) ● 自分たちで全てを守らない ● 組織にSREの機能をインストールするフェーズへの移行 ● SRE機能のガイドとそれを実現するプラットフォーム化をチームの焦点におく

Slide 15

Slide 15 text

© 2021 eureka, Inc. All Rights Reserved. Vision,Mission,Valueの再定義 ● Vision ○ 自律的にリライアビリティとアジリティを両立するプロダクト開発組織の実現 ● Mission ○ SREプラクティスを開発組織にインストールする ● Value ○ Metrics First ○ Draw a Blueprint ○ No Blame ○ Learning Animal ○ Change Agent

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

© 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) ● などなど

Slide 19

Slide 19 text

© 2021 eureka, Inc. All Rights Reserved. 実現の為のリソース戦略と開発組織の協力 ● 外部向け工数とシステム改善・仕組み作りの工数を分離 ○ 40%は外部工数,10%はToil/日常運用,50%はシステム改善とSREとしての取り組みに充当させる ■ Toil工数が10%を超えるようなら、Toil改善に力を傾ける ■ 外部工数がこれ以上必要でも、内部工数からは削らない（必要なら採用） ● 他チームへの責務譲渡 ○ 直接的な機能開発・問い合わせ対応は開発チームに移譲。 ○ コーポレート関係をコーポレートチームに移譲。 ○ データ関連は新設したデータマネージメントチームに移譲。 ■ ➡ チームではなく、技術組織全体の理解と協力と採用活動の結果

Slide 20

Slide 20 text

© 2021 eureka, Inc. All Rights Reserved. まとめ ● チームの役割やリソース戦略は組織や事業の規模に合わせてアップデートしていく事が望ましい ○ 結局地道な積み重ね ○ まずは自分たちが小さく実践を繰り返し、プラクティスや課題感への習熟を深める ○ SREはチーム完結ではなく、開発組織全体の理解と協調が必要 ● 取り組みはまだまだ始めたばかりなので、また年内目処にアウトプットできたら... :)