はじめに
この記事は、本番環境などでやらかしちゃった人 Advent Calendar 2023の18日目です。
もう何年も前のことなのでもうそろそろ時効だろうと思い、誰かの学びになればとここに供養します。
やらかしちゃった出来事
ある日の保守作業
保守管理しているWebシステムの調査のためにOracle Databaseが動いているWindows Serverにリモートデスクトップ接続していました。
調査の過程でデータベースインスタンスにアクセスして状態を確認する必要が生じました。
普段は自分のクライアントPCにインストールしたデータベースクライアントツールでつないで確認していたのですが、その時は横着してサーバーにインストールされていたSQL Developer（OracleのGUIデータベースクライアントアプリ）を起動してしまいました。
固まる画面
じんわり起動していくSQL Developer。が、途中でプログレスバーが止まります。
「あれ？なんかすごい時間かかるな…。」
嫌な予感がしマウスを動かすもカーソルが動かない。キーボードも効かない。
このあたりで冷や汗が出てきます。
近くの同僚に聞いてみます。
同僚「OSフリーズしちゃってるね…。」
私「SQL Developer起動しただけなんだけど…。」
同僚「このサーバーメモリ4GBしか積んでないからSQL Developer動かすのもキツイと思う…。」
なるほど、Oracle DBのサーバー最小要件がメモリ2GBとはいえ、GUIがリッチな分メモリを食うWindows Serverでかなり攻めたサイジングです。
少ないリソースで何とか動いてたのを、重めのアプリを立ち上げたせいで、とどめを刺してハングアップさせてしまったのでした。
鳴り響く電話
利用者からシステムエラーが出て動かないと電話がかかってきます。
もうハングってしまったものはどうしようもありません。
サーバーのあるデータセンターに連絡して本体を再起動してもらいました。
クラウドではなくオンプレだったので自分ですぐ再起動もできないのがさらにつらいですね。
再起動後、無事システム復旧しました。
データベースファイルにダメージがなかったのは不幸中の幸いでした。
学びと反省
この件での学びと反省は、サーバーのリソース状況を碌に調べもせず、重たい（可能性のある）アプリだの処理だのをカジュアルに動かさないことです。
本番サーバーともなればリソースに余裕なく常に自分の仕事を淡々とさばいている可能性があります。
普段と違うオペレーションをしない、するのであればその操作の影響や負荷、操作時のサーバーのリソースの状況を確認したうえで細心の注意を払って実施しましょう。
また、極力サーバーで作業せずクライアントPCや他の場所のリソースを使って作業を済ませられないか検討してみましょう。
おわりに
令和になり、クラウドがサーバーインフラのメインになって、今時そんな貧弱なサーバー使わないでしょと思うかもしれませんが、寧ろクラウドの方がサーバーのサイズを簡単に変えられるため、コスト削減のためにギリギリを攻めている可能性があります（オートスケールなどクラウドならではの対策はありますが）。
他にも例えばAWSならEC2のT系インスタンスでCPUクレジットが枯渇したときのように、OSのリソースモニターには表れない制約でサーバーが激重になることもあります。
本番サーバーでの作業はいつだって気を付けましょう。