【デブサミ2020】セッションレポート：14-B-4 プロダクトを10年運用するチームをつくる
10年続くプロダクトは、今後増えていくのではないか
登壇：だいくしー（@daiksy ）さん
IT革命（死語）が起きてから20年、ソフトウェアのライフサイクルは長期化しつつある。そこを運用するチーム、というのは興味深いテーマだ。
プロダクトを10年安定稼働させる極意
格言：動いているシステムは触るな
・昔は主流だったのかもしれないが、今はそうではない
・周辺環境の変化が大きくなっている
・OSのメジャーアップデートは年1ペース
・ブラウザのアップデートは月1ペース
・脆弱性は毎日発見されている
新卒のころは、確かに「寝た子は起こすな」的な空気感はあった。
いまや、外部と接続したシステムは変化させていかざるをえないというのは納得。できるようになったというより、やらなければいけなくなったということか。
システムを更新し続ける
・CI/CDの整備
・監視の整備
・DevOpsの構築
Mackerelの場合
・毎週火・木に定期リリース
・Mackerelで監視
・開発とSREで共通のカンバンボード
人の入れ替わりへの対処
・駅伝は3−4年で入れ替わるチームを作ってすごい、とおもった
・しかし、実はプロのITの現場はもっと入れ替わりが早い。もっとチーム作りが難しいのでは、と気づいた
・10年間入れ替わらないチームはいない
・だいくしーさんは5年目で最古参
・そもそも新陳代謝は必要
入れ替わる前提で考えよう、というのは賛成。確かに現場によっては、学生以上にローテーションのサイクル短いな。
どうスキルやドメイン知識を継承していくか
スキルマップ
チームを維持するのに必要なありとあらゆるものを放り込む。
効果としては以下のとおり。
・スキルバランス可視化
・リスクを事前に察知できる
・チームから失われたスキルに気付ける
・学習目標の指針になる
「失われたことに気付ける」は大事だ。けっこう、いなくなってはじめて気づくことって多いんですよね。
維持のコツ
・評価につかわない
・他のチームと比べない
・項目の粒度をきにしない。ちゃんとしようとすると作れない
・定期的なメンテナンス。ふりかえりなどでやるとよい
ちょうど、「ちゃんと作ろう」とおもっていたところだった！このタイミングで聞けてよかったー。
Mackerelでは2週間おきのふりかえりでメンテナンスしているらしい。けっこう高頻度だな。
・あまり効果を実感せず運用していた
・エースが抜けるときに効果を実感した。このままだとやばい！
障害対応演習
新規メンバーからみた障害対応
・何が起きているかわからない
・対応メンバーが何をやっているかわからない
・何を学べばできるようになるかわからない
こういった課題に対処するため、避難訓練のようなことをやっているとのこと。
やり方
・ステージング環境をわざと壊して復旧させる
・半期に1度
・スキルマップの弱点を参考に
・実際の障害が発生した直後に、同じシナリオで
AWSのAZの一つを意図的に壊して復旧させる演習を、昨年実際にあったAZの障害が起こる1週間前にやっていた。そのおかげで早く復旧できた
「これ…ゼミでやったところだ‼︎」の障害対応版だ。
思い立ったときにやる文化ができている
だいくしーさんが休みのときに演習があった。あわてて状況確認したら演習だった
ディレクターの負荷試験になった（笑
技術的負債とシステムのスケール
システム基盤技術の変化
・オンプレ→クラウド→コンテナ
・モノリシック→マイクロサービス
・リーン・アジャイル
Mackerelの基盤の変遷
式年遷宮
・20年に1度社殿を建て替える
・宮大工の技術の継承
・もとの形が保たれる
ソフトウェアの式年遷宮
・アーキテクチャやフレームワークのモダナイズ
・技術的負債の返済
・ポジティブな理由でやるべき
ポジティブな理由でやるべき、というのは完全に同意。古いシステムへの恨み辛みから始まったリアーキテクトは、だいたい失敗する。なぜならあるべき姿であなく、ありたくない姿しかみていないから。
React書けるエンジニアを探している、とのことです。
感想
長年継続しているサービスを扱っているものとして、共感できる部分だらけだった。
やはり学習を戦略的に行うことは大切だと痛感。式年遷宮、いいキーワードだ。