プロダクトを10年運用するチームをつくる

2020-02-16

概要

世間に認められたプロダクトは、その後長い年月をかけて運用していくことになります。その長い期間の間には、チームメンバーが入れ替わったり、上司が変わったり、アプリケーションそのもののアップデートやアーキテクチャの刷新もあったり、さまざまなことがおこります。それは新規開発の経験だけからは決して想像しえないことばかりです。 Mackerelというサーバー管理サービスが運用された5年間を例に、次の5年を見据えた「10年続くプロダクト」を維持するチームづくりについて考えていきたいと思います。

スピーカー

粕谷大輔 [はてな] @daiksy
- 2012年入社してからMackerelチームディレクター

スライド

内容

Mackerel
- サーバー用のBI
変化し続けるとシステム
- - 「動いているシステムには触るな」は昔の話
  - 周辺環境が変化している
    - OSのメジャーアップデート（年1回）
    - ブラウザのアップデート（月1回）
    - 新たに発見される脆弱性（ほぼ毎日）
    - スマートフォンもほぼほぼ自動最新化
    - 現代のシステムは常に更新しつづける
  - システムを更新し続ける
    - CI/CDの準備
      - テストの自動化・デプロイの自動化
      - Mackerelで毎週火・木に定期リリース
    - 監視の整備
      - Mackerelのドッグフーディング
    - DevOpsの構築
      - 開発と運用の融合/SREing
  - まずは、システムを触り続ける環境を整える
人の入れ替わりへの対処
- 箱根駅伝の話「4年で人が入れ替わるのはすごいが、社会人ってもっと短いサイクルで入れ替わってないか？」
- システムを維持するのは「人」
  - 10年間人が入れ替わらないチームはない
  - 異動や退職などそもそも新陳代謝も重要
  - 人が入れ替わると困ること
    - その人と過ごすかけがえのない日々
      - SNSでのつながりや年賀状
    - その人が持っているプロダクト固有のスキルやドメイン知識
  - スキルマップ
    - チームのスキルバランスの可視化
    - リスクを事前に察知できる
    - チームから失われたスキルに気付ける
    - 学習目標の指針になる
    - 運用のコツ
      - 評価に使わない
        
        心理的安全により正直なスキルが可視化
      - 他のチームと比べない
        
        チームの状態を可視化するためのものなので、意味がない
      - 項目の粒度を気にしない
        
        雑に思いついた項目をならべるぐらいでよい
        
        ちゃんとしようとすると作れない
      - 定期的なメンテナンス
        
        古い返り会のアジェンダに入れるのがおすすめ
  - 障害対応演習
    - 属人化しがち
      - 古参メンバーの独壇場
      - 新規メンバーはなかなか入り込んでこれない
      - 緊急事態なので丁寧に対応できない
      - 新人メンバーからは
        
        何が起きているのかわからない
        
        対応メンバーが何をやっているかわからない
        
        何を学べばできるようになるのかわからない
    - 障害対応演習を行っている
      - ステージング環境をわざとこわして復旧させる
      - 頻度
        
        半期に1回程度スキルマップを参考に
        
        実際の障害が発生した直後に、同じシナリオで
        
        統一障害対応オペレーションに参加できなかった人を中心に
      - Mackerelの例
        
        AWS（Multi-AZ）のAZのひとつと意図的に壊して復旧させる
        
        データベースを意図的に壊して復旧させる
        
        その他実際の障害発生のポストモーテム後に同一シナリオを再現させる
        
        日頃から訓練しておくといざというときに落ち着いて対応できる
  - 式年遷宮（次のパートで）
技術的負債とシステムのスケール
- サービスの成長速度
  - 2015−2019で400倍の顧客数
- システム基盤技術の変化
  - オンプレ→クラウド→コンテナ
  - モノリシック→マイクロサービス
  - 小さく作って大きく育てる
    - 当初から規模間を予測してアーキテクチャを設計して周辺環境の変化や、ときには予想を超えるスピードでシステムがスケールすることがある
- Mackerelの基盤の変遷
  - オンプレ環境でモノリシックなシステムを構築
  - うRL外形監視機能を新規開発
    - モノリシックなシステムから分離したサブシステムを構築
    - これを機にマイクロサービス化が進む
  - オンプレからクラウドシフト
  - サブシステムかから順次コンテナ化
- 技術的負債を支払う
  - 式年遷宮
    - 20年に一度社殿を建て替える（隣にまったく同じものを建てる）
    - 宮大工技術の継承
    - 社殿の姿が恒久的に維持され続ける
    - これをソフトウェアに例えると
  - アーキテクチャやアプリケーションフレームワーク、データストアなどシステムの基幹部分に手を入れるようなPJを一定かkン各で行う
  - 技術的負債の返済
  - モダンなソフトウェア環境への適応
  - エンジニアの技術継承
  - フルスクラッチをしにあ。フルスクラッチをしないためのエンジニアリング
  - スケールアップへの対処。
    - モダンなアーキテクチャの以降といったポジティブな理由をモチベーションとする
  - エンジニアの技術継承
    - 式年遷宮実施以前：プロダクトに最も詳しい人＝新規構築時のメンバー
    - 式年遷宮実施以降：プロダクトに最も詳しい人＝式年遷宮に参画したメンバー
    - 世代交代が進む
    - Mckerelの事例
      - 2017 AWSへ
      - 2017 時系列データベースの刷新
      - 2019 決済システムの移行
      - 今：フロントエンドをAngularJSから全画面Reactへ移行