設計という共通認識

Slide 1

Slide 1 text

Slide 2

Slide 2 text

0. 自己紹介 Yuji Suzuki(@yjszk666) Copyright © Livesense Inc. ● 株式会社リブセンスでSRE的なしごとしてます ○ 採用広報(ブログ運営etc..)もしてる ● 趣味：公営競技の鑑賞、ホームは平塚競輪 ● 略歴 ○ 大学無内定卒業→フリーター ■ 占い師とか出版社で校正とか色々 ○ 金融SE ○ 夜勤オペレータ ○ SIer ○ コンサルでSE ○ リブセンス ● 写真は青森競輪のあおいもりんちゃん ○ 推し

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

1. 自分しかわからないPR - オンプレの社内認証システムをECS Fargateに移す仕事がありました - チームメンバーに現⾏の状態と、これから作るものの共有をしていませんでした - その状態でいきなりステージングを作りました - レビュアーからしたらよくわからない⼤きいPRが突然来ました - ⾃分しかわからない - 結果、誰もレビューせず放置されてました設計を共有せずにステージングを作るPRを出した Copyright © Livesense Inc.

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

移⾏は状況が⼤きく変わる、コミュニケーションコストが⼤きい Copyright © Livesense Inc. - 現状(オンプレ)と移⾏後(クラウド)の認識を共有しつつ進める必要がある - 現状と移⾏後、2つある - つまり新規に作るより単純に2倍コストがかかる - コードの共有の前に設計の共有をした⽅がいい - 設計という共通認識を共有することで、コミュニケーションコストを⼩さくする 2. 共通認識を作ろう

Slide 10

Slide 10 text

経緯を資料として残そう Copyright © Livesense Inc. オンプレの何某をマネージドサービスに移⾏した…etc - こういうのはインターネットにいくらでも情報があるし⽂書化しないでもいいか… - 技術的なことは書かずとも、経緯は書いたほうがいいです - 議事録から経緯だけ抜粋でもいい移⾏に⾄った経緯、関係者の考え、何故そうなったのかを知るのは今いる⼈しかいません「ADR 設計」で検索すると超いいです、今移⾏しているサービスではADRを作っています ※ADR (Architectural Decision Records)とは、特定のアーキテクチャ決定を記述した短いテキストファイルのこと 2. 共通認識を作ろう

Slide 11

Slide 11 text

3. PRを見てもらえるようになるTips 概要に設計が書いてあるPR Copyright © Livesense Inc. - ドキュメントへのリンクが概要に貼られている - ドキュメント書くまでもないなら、概要に設計が書かれている - 図があると分かりやすい - GitHubがmermaid対応しているので、GPTに書かせてもいい - ロジックがあるなら… - ロジックを⽇本語で簡潔に説明 - パラメータ変更や追加なら… - 移⾏だとPRが⼤きくなりがち - 既存とのdiﬀがあると親切 - nginxのconf200⾏を複数ファイルとか読めない

Slide 12

Slide 12 text

No ビッグバンPR 3. PRを見てもらえるようになるTips Copyright © Livesense Inc. - 1つのPRで複数機能を追加すると読む⼈が⾟い - PRを機能ごとに分割する - ちいさくてかわいいPR - 例えばTerraformでECSを作るとすれば… - ECR/IAMロールから作る - どんなコンテナ/権限を使うかで後続作業がチョットわかる - タスクロールとタスク実⾏ロールのPRが来たら… - 次にECSがくるのがわかる - 既存実装のコピーなら、どこどこのコピーと明記してdiﬀを貼り付ける - stg作った後の本番環境etc…