初めに
今年初めておじいちゃんな大規模システムでシステム更改PJ（AWS化）の
インフラ担当（発注側・インフラチームリーダ）を経験したので、
その際に学んだことを共有します。
※学んだ＝私が失敗したなと感じたことがほとんど
発注側目線の戒めとして作成したので技術要素は無茶苦茶に排除しました。
どんなシステム？？
詳細書けないので概要と規模間だけさらっと
提供サービス
メイン
各種お客様応対機能の提供（利用者は社内）
サブ
周辺システムへのAPI提供
プロジェクト方針
・お客様応対システムが乱立しているので統合（5システム⇒1システム）
・機能としてはリフトだが、UIは使いやすいよう刷新
・維持管理コストは今より下げたい
・安全第一。3フェーズでリリースする。（トータル3か年計画）
・Managedサービスは積極的に使う（EKS、RDS、Elasticache、API-GW 等々）
規模感
・サーバリソース：EC2、コンテナPOD含め100+
・DBリソース：10TB＋
・対向システム数：90+
学び
学び① PJ中のバージョンアップ計画は考慮すべし
AWSあるあるですがサービスの更新やパッチ提供頻度が多いです。
1年以上のPJならまず間違いなく最新パッチは更新されているので、
リリース前にアップデートする計画を盛り込んでおくべきでした。
私はリリース前がドタバタで隙が無く、
リリース後すぐアップデートをしなければならない事態に(´;ω;｀)
学び② リリース後のサイジングは発生するので計画しておくべし
AWSのメリットはリソース増強しやすい点があります。
これは商用設備でもある程度気軽に増強出るので大変ありがたいのですが、
リリース直後で盲点となるのがリソース縮小の可能性です。
ものによっては増強は活性でできるけど、縮小は停止/断を伴うものが
意外とあります。
リリース後にトランザクションが少なくリソース無駄なので減らしたい、
って要件がある際は、小さく作ってすぐ増強できるようにしておくか
縮小時の影響と縮小対応日の合意をしておくと
調整に奔走することが無くなります。
またそういうもんだという周囲への刷り込みも結構大事。
私はelasticacheのダウンサイズの調整で苦労してます。（23年12月現在、現在進行形）
小さく作るはパブクラで良くある格言ですが、影響の大きさ（お客様への影響度合い）では選びにくい選択です。
ムリの無い選択をおススメします
学び③ 皆人間。発注側は驕るべからず
（何より大事。唯一自信をもって、出来た！と思うことｗ
というよりAWS関係なくいつでもやるべきだしやってます）
受注・発注関係があるとどうしても発注側が指示とか依頼する形になりますが、
上下関係では無いのでそこを間違えないようにしましょう。
命令すること・出来てないことを怒ることに快感を覚えている人を見ますが、
自分がそれをされ、嫌になって適当に済ませたことはあっても、
効率が上がった経験は一度も無いです。
発注をしている＝自社がやるより依頼の方が良いと判断して発注しているはず。
自分では能力/コスト面で出来ないことをやってくれているという、
感謝の気持ちで接しましょう。
嫌な現場より気安い現場の方が報連想や相談もすぐもらえます。（経験談）
①やって当然ではなく、やってくれてありがとう
②何でミスしたんだではなく、どうリカバリしようかと一緒に考える。
なぁなぁを良しとするわけでは無いので、私の関係者の方見ていたら
勘違いしないようにしてくださいm(__)m
というわけで以下続き
とは言ってもどうしても踏ん張りどころでは無理強いします。。
そんな時にも節度ある態度を
①急ぎの対応については何故急ぎなのか？を説明する。
いいからやれと上司やお客様に言えますか？の精神で
②受けるうえで発注側にしてほしいことが無いかを確認する。
私くらいペーペー相手でも言いづらいという方も多いと思います。
急ぎお願いする以上最大限誠意を示すのがあるべき姿。
③やってもらったら最大限の御礼を。
私はやってもらった方の上司がいる場やいるチャットでどれだけ助けられたかを
伝えるようにしてます。（私が出せない分、社内で評価とボーナスもらってほしい）