これは SRE Advent Calendar 2023 DAY 22 の記事です。
リブセンスでインフラグループに所属している鈴木です。競馬に行きすぎて、行ったことない地方競馬場が水沢と高知だけ1になりました。今後は釜山か済州2を考えています。 オンプレのVMで動いていた社内認証基盤をECS Fargateに移行する案件がありました。構成は下記となります。 Google認証ができたら、とある管理画面に入れる認可をするといったものです。 共通認識がなかった、それだけです。以下のことをしていなかったのが原因でした。 移行というのは情報が大きく変わり、コミュニケーションコストが大きいです。単純に現状と移行後のアーキテクチャが2つ存在し、新規に作るより、他人に伝える時に2倍コストがかかります。 基本設計や移行設計はもちろん、経緯を残すという観点でのADRも作った方がいいです。 1つのPRで複数機能を追加したり、行数が多いと読む人が辛いです。PRを機能ごとに分割すると確認しやすく、レビュワーファーストです。 今までレビューしやすい思ったPRのTipsを紹介します。 例えばTerraformでECSから作るとします。 自戒として書きました。日々レビュワーファーストに気をつけていきましょう。
はじめに
ところで、クラウド移行を複数経験したことで感じたことを共有しようと思います。なお本記事は第2回ゆるSRE勉強会の登壇資料をもとに作っています。自分しかわからないPR
このシステムをECSに移行する際、チームメンバーに設計の共有をせず、いきなりステージングを作るPRを出しました。TerraformによるクソデカPRです。
レビュワーからしたらよくわからなくて大きいPRが突然来ました。結果誰もレビューせず放置されていました。
わかります。自分も巨大なPRを見ると脳がフリーズします。後で見ようと新規タブで開いて、30分後に無意識に閉じたことは何回もあります。なぜ読まれなかったのか
実際のPR
設計という共通認識の重要性
今回は、現状(オンプレ)と移行後(クラウド)の認識を共有しつつ進める必要がありました。コードの共有の前に、設計の共有をするのが正解でした。
設計という共通認識を共有することで、コミュニケーションコストを小さくすることができます。
個人的な感覚ですが、お客さんにヒアリングシートを作って送るのと、100行Pythonを書くのは同じくらいのコストだと思います。コミュニケーションコストは小さい方が絶対に良いです。経緯を残すと++
ADRとして残しましょう、資産になります
システムに敬意を持って経緯を残しましょうちいさくてかわいいPR
これをちいさくてかわいいPR、ちいかわPRと呼びます。ちいかわPRについての記事です。↓
made.livesense.co.jpわかりやすいPRのTips
直したPR
終わりに
