サーバ管理者がサーバで作業する時に知っておいて欲しい5つの心得

id:akio0911さんと話してた時に、こういう話ってニーズがあるんだって気づいたので、
簡単にまとめて見る。

心得としてはこんな感じ。

コマンドの実行時は履歴を確認
なるべくフルパス指定で
サーバのトラブル時、リソースを確認する手段(CPU,メモリ,ポート,HDD)
サーバで一番重要なのはログ
再起動手段、確認する手順、緊急対応に行った内容は記録に落としておく。

もちろんの事ですが、プロジェクト毎にルールが決まってればそれを優先して下さい。

一個ずつ解説していきます。

コマンドの実行時は履歴を確認

サーバの再起動とか、サーバのプログラムを確認する時、履歴を検索するのは非常に有効な手段です。
Ctrl + r のショートカットでrestartとかで検索し、ヒットしない場合は何度かCtrl + rを押して
遡れば見つかります。*1
再起動のコマンド等がドキュメントに書いてない場合等は特に重宝します。
で、見つけた後は、↑、↓キーでこのコマンド実行前や実行後に何が行われていたかと
いうのを確認します。
よくある例としてはこんな履歴を見つける事とかあります。

$ cd /usr/local/apache2
$ vi ./conf/httpd.conf
$ ./bin/apachectl configtest
$ ./bin/apachectl restart
$ exit

この場合は、apacheの再起動には/usr/local/apache2/bin/apachectlを使って再起動してるなー
というのがわかります。
Ctrl + rで一個しか見つけてないと、./bin/apachectlってどこだーって事になりますので
上下を確認する必要があるわけです。
後、実際見た事ないですが、仮にこんな履歴があったらどうでしょうか

$ /usr/local/apache2/bin/apachectl restart
$ /etc/init.d/httpd restart
$ exit

/usr/local/apache2/bin/apachectlで再起動したけど失敗したので
/etc/init.d/httpdを使ったと推測できます。

基本的にはサーバのドキュメントに重要なコマンドは書いておくべきですが
ドキュメントがなければこういう対処方法もあります。
サーバのプログラムの配置場所なんて、好きにできますから(セオリーは決まってても)
こうやって確認しないと痛い目にあいます。

また、ドキュメントに/etc/init.d/httpd restartで再起動すると記載されていても、
実はその資料が古くて/etc/init.d/httpd2 restartを使う様になっていたり
su -でrootユーザーになってから再起動コマンドを実行していたりする可能性もあるので、
ドキュメントに書いてある事と同じコマンドの履歴があるか検索して作業をすると
確実になります。
コマンドの履歴がちゃんとあれば安心しますし、なければ可能な時は元の作業者に確認して
見ると、意外と「あー、そこ変わってるんだよー」っていわれるかも知れません。

なるべくフルパス指定で

作業する時、特に理由がなければフルパスで作業した方が良いです。
一つ目の項目に関連しますが、コマンドの履歴を中心に作業すると、移動して再度再起動を実行。と
2回のプロセスを経るより、1回で済ませた方が当然早いので。

$ cd /usr/local/apache2
$ ./bin/apachectl restart
$ exit

$ /usr/local/apache2/bin/apachectl restart
$ exit

実際、上の2つだと、下のほうがコマンドが少なく済むので、必要がなければ移動しない方が作業も効率的になります。
後、履歴から探すと、cdコマンドで間違えた場所に移動したりを考えるとこんな履歴の時が怖かったりします。

$ cd /usr/local/apache2
$ ./bin/apachectl restart
$ exit
＝＝＝＝中略＝＝＝＝＝
$ cd /usr/local/apache ←誰かが間違えて古いファイルの場所に移動した

先にcd で検索すると逆順になるので
本当は/usr/local/apache2/bin/apachectlなのに
/usr/local/apache/bin/apachectlで再起動してしまうことに。

まあ、めったに無いと思いますが、フルパスでできない作業以外は、
まとめる事でリスク回避と作業の効率化ができるのでお勧めです。

サーバのトラブル時、リソースを確認する手段(CPU,メモリ,HDD,ネットワーク)

まずコマンドの一覧から

uptime CPUのロードアベレージを取得する。
free 空きメモリの容量を取得する。
ps 稼動してるプロセスのリストを出す。
top タスクをリアルタイムで出力する。
df HDDの空き容量をチェックする。
du HDDを使っている箇所を確認する。
netstat 使っているポートを表示する。
nslookup DNSで参照できるかを確認する。
ping ネットワークで通信が届くかを確認する。
telnet そのポートに接続できるか確認する。

それぞれのコマンドのオプションはmanでも見てもらうとして
uptimeやfreeなどでCPUやメモリに問題があると特定した場合は、psコマンドなどでCPUやメモリを利用してるプロセスを特定し、可能であればそれを停止します。
もしくは問題解決のためにそのプロセスを軽くします。*2

dfなどでHDDの空き容量が無いとわかった場合はduの結果をソートするなどして、どのディレクトリで容量を使ってるかを特定して、不要ファイルを削除し、軽くします。

ネットワークがつながらない場合は、
pingでまず外部に接続できるか確認します。
外部に接続できない場合は、ネットワークが切れている可能性があるので、ネットワークケーブルや回線を提供する会社を確認。

netstatで対象のアプリケーションがポートを確保してるかを確認し、
telnet localhost 80などで対象のアプリケーションのポートにローカルから接続できるかを確認します。
ローカルから接続できないとか、ポートが使われて無い場合は、アプリケーションが死んでたり、
正常に動いてない可能性があります。アプリケーションを確認しましょう。

後は外部からtelnetで接続可能かチェックして、そこがつながらない様であればFWとかallowの設定などを確認でしょうか。
ネットワークの場合は、本当にいろんな原因があるので、特定する為のマニュアルが難しいですけど……。

サーバで一番重要なのはログ

サーバに接続する時、個人情報の関係でログの破棄が必要な場合以外は、
基本的にsshのログやコンソールのログを取る様にしてください。

原因究明の際に、「問題が無い作業が行われた｣確認になります。
社内の人も、今ではログとらない人はいないんですが新人には毎回言ってるので……。
ログは偉大です。

後、原因究明をする時にログを元に探すようにしましょう。
大体トラブルが起きた時はログを見れば原因がわかります。
9割はログのおかげで原因の特定ができます。

後はログの確認用にtailとgrepとlessコマンドだけ覚えておきましょう。

再起動手段、確認する手順、緊急対応に行った内容は記録に落としておく。

一つ目でドキュメントを信用するなって言った気もしますが、
ドキュメントはドキュメントで偉大です。
アプリケーションの場所と再起動の手順、トラブル対応時の内容はドキュメントに
落としていきましょう。

*1:シェル上のショートカットキーは一度まとめてエントリにしてます。

*2:この辺はプロセスの性質によって対処が変わる