• サービス拡大に伴ってインフラチームの負荷増大 → コンテナ化、マネージドサービスの積極的利用によりアプリケーションチームに権限移譲
• 今後はTeraform/Kubernetes YAMLの作成・利用の効率化や、AWSアカウントの統制、アプリケーションランタイムのサンドボックス化を進めていく

• 背景:
  • これまでコンテナ化の推進やCI/CD、ログ基盤の整理などを行ってきた
  • SREチームが手広くやりすぎたかも→開発チームの問題解決をサポートする立場に変更したい
• やったこと:
  • SREのミッションとバリューを策定し、チーム内外でゴールを揃えた

• トイル削減が目的化する(削減までのプロセスや作業自体がトイルになってしまう)のはよくない
• 本質は長期的なエンジニアリング業務・プロジェクト業務に時間を割けるようにすること
• その組織が何を大切にするかによって選定するサービスが変わる

開発組織とSREの立ち位置、関係性は？

• 元々の組織の距離感で違うかも
• 理想はコミュニケーションが密に取れること。いざ障害が起こった時に協力してことに当たれるかが大切
• 組織間で留学するといいかも

分担はどうする？

• SREよりも開発がSLO/SLIを設定した方が適切に設定できる
• 開発チームにSLO/SLIの必要性を理解してもらうためには、課題観の共有から始めるといいかも

どの段階でSREを始める？

• 兼務に限界が出てきたら
• どれくらいインパクトが出せるか

SREのスキルセットは？

• 最低限のレベル感
  • コーディング経験は欲しい
  • インフラスキルが高い人
• チームとして「今この領域に強い人が欲しい」という場合もある
• コミュニケーションスキル、ソフトスキル重要

トイル撲滅とLambda

• 今はマネージドサービスの充実によりLambdaを使う機会は減っている
• 最終手段で必要悪としてLambdaを書く。気軽に書くと負債になる
• 目の前の運用負荷の削減を考えるのではなく、
  統合的に複数のプラットフォームの運用負荷を削減していくためにシステム構築していくことが重要

セキュリティ

• ECRのイメージスキャン(CI/CD前提)

モニタリングに利用しているサービスは？

• Prometheus & CloudWatch → Grafana で監視
• S3 → Amazon Athena で分析(Athenaの活用はなかなかしんどい)

• 2種類のチームを設けている
  • 問い合わせに対応するチーム
  • 治安維持的なチーム(Trust and Safety)
    • 問い合わせや通報がそもそも発生しない状況作り
• CSツールを内製している
  • 仕様はCS, PdM, エンジニアでディスカッション
  • 並行してCSオペレーションを構築
  • 現在ツール自体の改善にも取り組んでいる
• CREはCSのクリエイティビティ(より良いパフォーマンス)を引き出す

• 元々お客様の体験向上を行うチームが存在していた。共通の名前で認識できるように、「CRE」という名称になった
• お問い合わせの流れは ユーザ ⇔ CS ⇔ CRE
  • CSがユーザとのフロントのやり取りを行う
  • CREは技術的質問の一次調査やCSツールの開発を行う
• KPIを設定するのは難しい
  • これについてブログを書かれている(カスタマーサポートの真のKPIを求めて)
  • わかりみしかない参加者
• サポートのSLIについて: toC サービスの CRE における SLO の考え方

• プロダクトの開発者が必ずしも良いCSツールを作れるとは限らない
• CSや業務に関するドメイン知識が必要
• モチベーションが異なる (製品で世界を良くしたい or 身近な人、ユーザを幸せにしたい)

• 事業Aの問い合わせが事業Bの窓口にきてしまう(導線)
• グループごとにCSツールが別建てなので、共通化しようか悩んでいる
• 組織的にCREを事業部につけるのか、CSにつけるのか悩む
  • ミクシィさんの場合、CS1つ・CRE1つが事業部を横断する
  • KPI設定を事業部と分けた方がうまくいく
• 海外事業との組織的分割は？
  • メルカリさん
    • 海外用アプリは完全に組織を分けており、CSツールも別
    • 以前は同じCSツールで多言語対応していたが、アプリが別なのでツールも分割した
    • 日本向けアプリへの英語の問い合わせをどうするかは今悩んでいる
  • ミクシィさん
    • CSツールは同じで多言語対応している