エンジニアがプログラミングできれば、よくスキルが高いと思われます。
実は上手にプログラムを書くと本番環境の問題解決能力は二つの分野と言っても過言ではありません。
つまり、コーディングができて、本番環境が出る際に問題解決できない人も結構います。

本番環境の問題解決能力はエンジニアの最高スキルを表していると言っても過言ではないと思います。

理由は3つ

いかなる厳しい状況にパフォーマンスを安定的に出すのが大事
制限時間内で冷静に考える、問題分析、判断力どれも必要
プログラムは結局サービスとして提供しないと意味ない

実例で説明していきます。

あるシステムに数万の代理店データがあって、各代理店の配下に数十〜数万のショップがあり、
ある休日でで移行作業を決めて、事前にサービスの停止時間を連絡し、移行作業を行います。

事前に移行プログラムを作成し、十分にテストして、
メンテナンス時間内で問題なく移行できるという報告がありましたが、
本番作業の際に意外に重くて、なかなか進まないです。

確認したところ、テストに中小代理店のデータでテストを行ったため、
本番環境には全体取引量の5％〜6％を占める大型代理店もあるので、
当然移行時間も異なり、なかなか終わりません。

もちろんテストサンプルの選び方が悪かったですが、本番作業が始まり、
改めてユーザーにメンテナンス時間をいただくことも難しいですので、
予定時間内に移行作業を済ませないと翌日の取引ができなくなって、
数千の代理店、数万百ショップに連絡するのは無理でしょ！

解決しなければ、クレーム電話が殺到し、運営チームがお詫びで倒れそうで、ユーザーに対する賠償が発生、
さらに会社の信頼問題で、大変なことになります。

とにかく、問題解決が一番先にやること！

解決案1

コアデータを先に同期させて、メンテナンス後のサービス提供を確保する。手動インポート＆エクスポートでDB移行。
現状
- DBの規模によって、数千テーブルがあり、複雑性が半端ない。
問題点
- DBAにとって、瞬時に終わる作業ではない、不可能なタスクであり。

解決案2

移行プログラムを改善
現状
- 確認したところ、移行プログラムのWebページに代理店の番号を入力して、ループでデータ遷移処理を回しているようで、
  ショップの方は複数スレッドで行なっているが、代理店の部分は複数スレッドで実行することで移行を加速化。
問題点1
- すぐに移行プログラムを改修して、テストをしないとリスクが大きくて、怖い
改善案
- Webページは1回のリクエストにバックエンドに1つのServletで処理する
改善案テスト
- 4つページを開き、違う代理店の番号を入力してテストして、スムーズに実行できた
- さらに数十ページで開いて、テスト実行。時々エラーになる
改善案エラー分析
- エラー確認して、スレッドセーフではないのが問題
- あるスレッドで変更した共有データが、他のスレッドによって上書きされてしまう可能性があります
- クラス変数とインスタンス変数はスレッドセーフでない
改善案のエラー解決
- ThreadLocalで改善
改善案再テスト
- 1つTomcatは6つのスレッド並行処理すると、負荷が高い
改善案原因分析
- 各スレッドはさらに他のスレッドを使って移行処理を行う
改善案の改善案
- クラウド環境で複数サーバを立ち上げて、物理で負荷分散
結果
- メンテナンス時間内に無事に移行できた

以上、プログラムを書いて問題解決ではないか、
本番環境の問題に対する原因分析や考え方など結構大事だと思います。

移行作業のあるある

事前テストは十分だと思ってるが、データ量は本番と異なると作業時間が長さが変わって、サービスに影響がでる
移行データの多様化による、テストデータが全てのパターンにカバーできない
どうしても完全なる本番作業にできないので、予想外の問題が出てくる

本番問題解決のコツは？

簡潔に一言でまとめます。

実践！実践！実「戦」！

個人の意見ですので、不足な部分を指摘いただければと思います。<(_ _)>