※ MySQL5.7のアップグレードに関しての実際の作業内容に関する話はありません。
どういう話？
最近課金したGTP-4を使用して、自分で終了させたタスクに対して、生成AIならどういう答えを出すのか確認してみたところ、自分では2日かかった答えを秒で出力してしまい、自分の頑張りは何だったのかという失念と、やっぱり生成AIは今後活用しないといけないな、という教訓を遅ればせながら得た時のお話です。
経緯
サポートが終了するMysql5.7のアップグレード作業を依頼されたときの話です。
細かい詳細は省きますが、当時の内容としては以下の通りです。
投稿者スペック
・Railsの基本知識はある。（実務３年）
・データベースの基本知識はある。（実務３年）
・Mysqlアップグレードはやったことがない。
Missionと聞き取り調査
・Mysql5.7をMySQL8.0にして、Railsアプリが正常に動作する部分までもっていく。
・本番環境でアップグレードする際のダウンタイムを許容できる。
・DBのエンドポイントが変わることは許容できない。
・テスト環境からイメージを作ってインスタンスを立ち上げて実験してもよい。
・同じアーキテクチャのアプリも作業を行いたいので作業フローをまとめて報告する。
・アプリにドキュメントなどない。( ‘ᾥ’ )
といった感じでした。
アップグレード作業の計画する(投稿者)
初めての作業となるので、色々と調べながら実際に行う作業計画を確立していきました。
他業務の割り込みもあるので正確な時間は出せませんが、アップグレード作業の計画については、少なくとも着手から終了まで2日かかりました。
結果から言ってしまえば、ここの作業がわからされた部分になります。
ちなみに僕が考えた計画は以下のような感じでした。
1.バックアップは必ず取る
→ とにもかくにもバックアップを取る。いつでも戻せる状態にする。
2.テスト環境の構築
→ 色々いじる必要があっため、テスト環境のイメージを作成。実験場作成。
3.実験開始
■ 方向性
アプリのコードを読んで問題点を洗い出すのではなく
アップグレードで発生したエラーを問題点として洗い出す
→ テスト環境でいきなりMysqlをアップグレードする。
→ 発生するエラーを逐次解消する。その全てをメモする。
→ この作業でアプリとMysqlとの互換性を取り除く。
→ アプリの改修（コード修正）を行う。
→ 逐次テストをする。
→ 上記内容をくり返し、全てのエラーや不具合を解消。
→ 完全に解消できた作業をフローとして確立させる。
4.スケジュールの設定
→ 本番環境で実施するスケジュールを立てる。
5.本番での実施
→ 全てが確立出来たら実施する。
6.経過観察
→ 問題ないかの確認。
言語化しつつ、色々頭の中をまとめながら「この流れでやります」と報告。
そのままGOが出たので、上記の作業を開始しました。
ちなみに、このタスクはすでに完了したタスクになります。
しかし反省や興味本位の気持ちもあり、後日GPT-4に同じ内容で計画をしてもらいました。
アップグレード作業の計画する(GTP-4)
■ 投稿者
~省略~ おすすめなアップグレードのフローを教えてください。
■ GTP-4
GTP-4の結果を見て
ほぼ同じじゃん。
ぼくがかんがえたさいきょーのけいかくを、GPT-4は一瞬で生成してしまいました。
正解を導けた自分を褒めるべきか、2日もかけた自分を貶すべきか...
この結果には目が点になってしまいました。
まとめ
今回は本当にきれいに「よもやここまで」といった体験をすることが出来ましたので記事として投稿しました。
上記の質問も、GPTがブラウジングしてMySQLの公式リファレンスを見に行っていることもあり、情報に関しても正確なものになっていると思います。
今後の生成AIの動向については、今まで以上にアンテナを張って活用していかなかればならないな。と感じた1日になりました。(遅い)
終わり。