はじめに
2020年2月14日に開催されたDevelopers Summit2020に参加してきました。
テーマ
【14-B-4】プロダクトを10年運用するチームをつくる
カテゴリ
エンジニア組織
登壇者
- 粕谷 大輔さん [はてな]
- @daiksy
- はてな
- 2012年入社
- KPTとは
- かすや ぱねえ 天才www
- Mackerelチームディレクター
- 認定スクラムマスター
- Mackerelとは
- サーバ監視をSaaSで行っている
発表資料
講演メモ
変化し続ける周辺環境とSystem
- プロダクトを10年安定稼働させる極意とは？
- 昔はCloudなんてなかった。基幹システムなどがメイン
- 当時の格言
- 動いているシステムはさわるな
- 10年触らないことが極意？
- 今日のセミナーは、完wwww
- 周辺環境の変化が激しい
- OSのメジャーアップデート
- およそ1年に1回
- ブラウザ
- およそ月1回
- Chrome80とか
- およそ月1回
- 脆弱性
- およそ毎日
- OSのメジャーアップデート
- 手元のスマホ
- 自動アップデートが当たり前
- 意識せずとも更新されている
- 現代システムは常に更新され続ける
- 更新し続けるために
- CI/CDの整備
- テスト自動化
- デプロイ自動化
- 監視の整備
- 触ったら壊れるリスクはある
- DevOpsの構築
- 開発と運用の融合
- 毎日リリースすると開発、運用が不可分になってくる
- SREing
- 開発と運用の融合
- CI/CDの整備
- Mackerelの場合
- Jenkins
- 毎週火・木に定期リリース
- 監視
- Mackerelのドックフーディング
- Jenkins
- システムを触り続ける環境を整える
- 去年、200週連続リリースした
人の入れ替わりへの対応（本題）
- 箱根駅伝はいいチームが優勝する的なツイートを見た
- 学生スポーツのチームは有限
- 4年で人が入れ替わるのにすごいな～
- 実は、IT業界の方が入れ替わりがもっと早い
- システムを維持するのは人
- 10年間人が入れ替わらないチームはない
- 異動や退職など新陳代謝は必要
- 10年同じメンバーというのも問題
- 個人のキャリアの問題もある
- 人が入れ替わることで困るもの（失うもの）
- その人とのかけがえのない日々www
- 対策
- SNSでつながる
- 年賀状送るww
- 対策
- その人が持っているプロダクト固有スキル
- 対策
- スキルマップ
- 障害対応演習
- 式年遷宮www
- 対策
- その人とのかけがえのない日々www
スキルマップとは
- 横軸がスキル
- Ruby
- RSpec
- HTML5
- AWS
- Git
- 設計
- 障害対応
- ファシリテーションなど
- 評価
- ★がエース
- ○1人でやれる
- ▲サポートが必要
- ↑習得希望
- -未習得
- 効果
- チームのスキルバランスが可視化できる
- 人がいなくなることで、リスクを事前に察知できる
- チームから失われたスキル（知識）に気づける
- 学習目標の指針になる
- 維持のコツ
- 評価に使わない
- 心理的安全により、正直なスキルが可視化される
- 他のチームと比べない
- 自分のチームの状態を可視化するためのもの
- 項目の粒度を気にしない
- 雑に思いついた項目を並べるくらいでいい
- Networkとか、いくらでも細かくできる
- まずは始める
- 雑に思いついた項目を並べるくらいでいい
- 定期的なメンテナンス
- 振り返り会のアジェンダにいれるといい
- 1年前に作りっぱなしでは意味がない
- Mackerelでは2週間毎に振り返りをしている
- スプレッドシートに履歴を残している
- 評価に使わない
- 効果の実感
- エース級のCさんが異動に・・・
- 新卒からずっとCさんはMackerelチームだった
- いなくなる前提で、同スキルを移譲していくか
- 自信をもってできるひとが１以下になると、条件付き書式で赤にする
- 具体的に危機感がチームに共有できる
- 愕然とした
- エース級のCさんが異動に・・・
障害対応演習
- あるある
- 属人化しがち
- 古参メンバーの独壇場
- 緊急事態なのでそもそも教育できない
- 新規メンバー
- 何が起きているのかわからない
- メンバーが何をやっているのかがわからない
- 何を学べば良いのかわからない
- 属人化しがち
- そこで演習
- 避難訓練みたいなもの
- ステージング環境でやる
- わざと壊して復旧させる
- 頻度
- 半期に１度
- スキルマップを参考に
- 実際の障害が発生した直後に、同じシナリオで
- 当日障害対応オペレーションに参加できなかった人にやってもらう
- 例
- AWS のAZを１つ意図的に壊す
- DBを意図的に壊して復旧させる
- 障害発生のポストモーテム後に、同一シナリオを再現させる
- 実際、昨年にAWSでAZ障害があった
- １週間前にちょうど演習していた
- 日頃からの備えは大事
- ある日
- 休みの日に訓練された
- 居酒屋で飲んでたらストレージ破損
- 急いで家に帰ったら訓練だった
- ディレクターの負荷試験www
- やるなら事前に言えwwww
- 休みの日に訓練された
技術的負債とシステムのスケール
- サービスの成長速度
- 累積顧客指数
- FY15を100とすると、FY19 は4150
- 負荷が膨大に
- システム基盤技術の変化
- オンプレ＞Cloud＞コンテナ
- モノリシック＞マイクロサービス
- 小さく作って大きく育てる
- 当初から規模感を予測して設計しても、環境が変化する
- Mackerelの場合
- 最初はオンプレだった
- URL外形監視機能を新規開発
- ここはマイクロサービス化
- AWSへ完全移行
- サブシステムからコンテナ化
- 一定のタイミングでシステムの根本に手を入れる
- そこで式年遷宮
- 会社の言葉ではなく、粕谷さんが勝手に呼んでるwww
- 伊勢神宮
- 20年に1度社殿を建て替える
- ソフトウェアの式年遷宮
- 根幹部分に手を入れるようなPJを一定間隔で行う
- フルスクラッチではない
- 技術的負債の返済
- モダンなソフトウェア環境への適用
- ポジティブな理由をモチベーションにする
- 10年前のアーキテクチャで動いていてよいのか？
- モダンになれば運用も楽になる
- 技術継承
- 世代交代ができる
- 遷宮前
- プロダクトに一番詳しい人：新規構築時のメンバー
- 遷宮後
- プロダクトに一番詳しい人：式年遷宮のメンバー
- 遷宮前
- 世代交代ができる
- 根幹部分に手を入れるようなPJを一定間隔で行う
- Mackerelの式年遷宮
- オンプレからAWSへのインフラ全面移行(2017)
- 時系列DBの刷新（2017）
- 決済システムの以降（2019）
- フロントエンドをAngulerからREACTへ（Now）
感想とまとめ
今回、一番聞きたかったセッションです。自分が携わるプロダクトを10年運用するためにはどうしたらよいか、という視点でお話を伺いました。結論、めちゃめちゃ参考になりました。
人の入れ替わりは止められない。むしろ入れ替わったほうが良い。ということを学びました。まさに今、チーム内で人の入れ替わりがあり、今後チームビルディングをどうしていくべきかと悩んでいたところだったため、スキルマップは早速作ろうと思います！
式年遷宮PJは会社の経営層の理解も必要と感じました。リファクタリングやモダンな技術環境に変更することに、どれだけ理解を示してくれるかが課題かもしれません。
今私がリーダーを務めているプロダクトも、いつか他の人に受け継ぐ時が来ると思うので、今のうちから準備を進めたいと思いました。
