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

Quipper における SRE チームの紹介 ~僕が SRE になった理由~ / Why I Became an SRE at Quipper

Quipper における SRE チームの紹介 ~僕が SRE になった理由~ / Why I Became an SRE at Quipper

StudySapuri Product Meetup #1 〜脱スタートアップフェーズにおける開発チームの現在と未来。少数精鋭の運用体制からデザイン・アーキテクチャまで~ における SRE チーム @yuya-takeyama の発表です。
https://techplay.jp/event/680406

Yuya Takeyama

July 19, 2018
Tweet

More Decks by Yuya Takeyama

Other Decks in Programming

Transcript

  1. @yuya-takeyama 2015 年 9 月 Quipper に転職 Web Developer として

    Rails, Backbone.js, React.js, React Native など 2018 年 4 月 SRE チームに異動 絶賛弱くてニューゲーム中
  2. ➔ 現状: 1 つのソースを数十人のエンジニアで開発している ◆ 境界が曖昧だと空気の読み合い・お見合いになりがち • それでは Ownership を持つのは難しい

    ➔ 各 Service Unit が個別の Service を所有し、責任を持つようにしたい ➔ サービス間のインターフェイスだけ決めて、あとはよろしくやる ◆ 制約があるからこそ自由になれる ➔ それ、Microservices じゃん Ownership
  3. ➔ なんでもやりたい人はなんでもできるように ➔ 権限の制限をできる限り取り払う ◆ アプリケーションエンジニアだってインフラをいじりたい ◆ ネイティブエンジニアも API を作りたい

    ➔ Monorepo にすることで複数領域を一気にガッとやれる状態 ◆ 依存関係のある複数サービスを 1 Pull Request でまとめて変更 Borderless
  4. ➔ 仮説検証のサイクルを高速に回せる ◆ 個別アプリでなく、サービス群全体でのステージングデプロイ ◆ 本番へのデプロイも各 Service Unit の裁量で ➔

    本番環境で、柔軟に少しずつ検証するための仕組みが必要 ◆ Feature Flag, Canary Release ◆ ダメだったらすぐに戻せる ➔ ユーザーに高速に価値を届け続ける Agility