本番環境でやらかしちゃった人 Advent Calendar 2019 16日目の記事です。
内容はタイトルの通りです。
10年前くらいの話なので少しふわっとした部分もあるかもしれませんが、ご了承ください。
その当時やっていた業務内容
システムのサーバー移行作業
東京のとある会社で、とあるシステムのサーバー移行の作業をしていました。
そのシステムは大阪にあるデータセンターの物理サーバーで動いていて、今使っているサーバーの使用期限が切れるため、新しいサーバーへ移行するというものです。
客先常駐で、クライアントさんとやり取りしながら仕事をしていました。
ちなみに当時の僕はエンジニアになって2年目くらいの時期でしたが、大手SIerでのシステム移行のを1作業員として経験(手順書通りにコマンドを実行したりする)したくらいの状態で、まともにプログラムやコンソールを業務で触るのは初めてでした。
今回の事件とは直接関係ありませんが、移行と併せてミドルウェアなどのバージョンアップも実施していました。
ApachやMySQLはいいとして、PHPの4→5への移行もあってそれが色々大変だった記憶・・・
ミドルウェアのインストール、設定の変更、プログラムやリソースのコピー、etc...
実際の作業としては、サーバーにsshでログインし、
- 必要なミドルウェアをインストール、設定
- 古いサーバーからプログラムやリソースをコピー
- バージョンアップに伴う設定、コードの修正
などの作業をしていました。
ターミナルソフトから新しいサーバー、古いサーバーそれぞれ立ち上げてscpで送信したり、バージョンアップでそのまま使えないものは古いサーバーの画面をみながら新しいサーバーの設定を手作業で書き換えたり。
ミドルウェアのインストールも yum でインストールではオプションが足らないとかで、 wget で色々オプション付けて落とし、makeコマンドでコンパイルしてた記憶があります(うろ覚え)。
物理サーバーだったこともあり、今思うとすごく面倒で恐ろしい作業していたなと思います。
(クラウドならAWSでAMI作ったり、コンテナ化したり・・・で簡単にできる)
事象:ターミナルを落としたらrootユーザーでログインできなくなる
理由は忘れてしまったんですが、ユーザーのログインシェルの設定を書き換えないといけない手順がありました。
確かデフォルトbashになっているところを、全て別のshellに書き換える必要があり(うろ覚え)。
変更のやり方は下記のあたりが参考になるかと思います。
確かその時は /etc/passwd を直接書き換えてターミナルを再起動という一番危なそうなやり方でやってたと思います。
このファイルはrootユーザーでないと変更できないので、rootユーザーで作業していました。
そうして設定ファイルを色々といじっていて、一区切り着いたところでターミナルを落とし休憩。
そして戻ってきて再度ログインしようとすると・・・
rootユーザーで入れなくなっていました。
原因としてはshellの設定を間違った情報に書き換えてしまっていたから。
どう書き換えたのかは覚えてないんですが、shellのパスを存在しないものにしたりするとそのユーザーでログインできなくなるので、たしかそんなとこだった気がします。
興味ある方は試してみてください←
他のユーザーではログインできるんですが、rootユーザーでないと触れない場所やできない作業が色々とありました。
そしてrootユーザーのログインシェルの書き換えはrootユーザーでないとできません。
(/etc/passwd もrootユーザーでないと触れない)
八方塞がりです。
その時やった対応
①シングルユーザーモードなら入れることを知る
なんとかできないかと対応方法を調べていたところ、シングルユーザーモード であれば入れるという情報を見つけます。
シングルユーザーモードはWindowsのセーフモードのようなものです。
端末のコンソールを直接操作する場合に限り、rootユーザーのみでログインしてOSを操作することができます。
3日目の@dala00さんの記事、さよなら本番サーバーでも触れられてますね。
(実は結構ネタ被ってます)
ただし、シングルユーザーモードはリモートでは入れません。
対象のマシンに直接アクセスする必要があります。
冒頭に書いた通りこのシステムは大阪にあるデータセンターの物理サーバーで動いていました。
つまりログインするには大阪に行く必要があったのです。
そして僕が当時作業していたのは東京のとある会社。
終わった・・・。
②大阪の人に助けてもらう
で、どう対応したかというと、クライアントさんに相談したところ幸いサーバーのある大阪にもエンジニアの人がいたため、そちらで対応してもらいました。
リモートでは一生ログインできなくなりましたが、前述の通り現地で直接サーバーにつなげばシングルユーザーモードでログインすることができたので、それで修正してもらうことでことなきを得ました。
ログインシェルをデフォルトの状態に戻してもらい、無事リモートからも入れるように。
リモートからはなにもできなくなりますが、シングルユーザーモードであればログインシェルの設定がバグっていてもログインできたのは不幸中の幸いでした。
③謝る
そしてクライアントさんに謝る。
結構広い範囲の人を巻き込んでご迷惑をかけてしまいました。
ただ、その時のリーダーの方が謝っているメールが自分にもCCで飛んできた時が一番辛かったです。
再発防止策:どうすれば防げたか？
当時言われたこと(原始的な方法)
その時言われたのは「rootユーザーでログインできている状態のターミナルを1つでも落とさず残していれば対応できたよね」ということでした。
まあ確かにそうなんですよね・・・なんか原始的な感じがすごいですが。
とか言いつつ、これが起きた3日後くらいに同じことやらかす寸前まで行ったところをこの方法でこっそり切り抜けるということがありました。
本当に自分を殴りたくなりました。
今だったらどうするか(先進的な方法)
多分コンテナ化したりTerraformでコード管理したり、そもそもこの作業自体手作業でやらないようにすると思います。
移行作業というよりそもそもの元のサーバーの構成管理の話。
もし仮にその当時の状態で渡されても、これを機にちゃんと構成管理しようという提案をすると思います。
クラウド環境に生存するようになってから久しいため、物理サーバーの環境とか6年くらい触ってないですが・・・
最後に
10年前の若かりし頃にやらかした思い出ですが、今でも「過去の失敗談」とか聞かれた時に真っ先に思いつく3傑くらいに入るやらかしです。
本番環境と言っても移行先サーバーなのでユーザーさんに影響が出たりはしてないのですが、かなりの絶望感がありましたね。
ただ、こういう経験を積んだからこそ今サーバー環境をいじるのにすごく慎重になれているところもあります。
当時関わっていた方がもし読んでいたら、こんなネタにしてしまって大変申し訳ないのですが、とても大きな糧になった経験だったと思っています。