趣味と実益を兼ねたVPS運用。その核となる心構えについての個人的なメモを、具体例を交えつつ方法論（メソドロジー）について記しています。

  • Linuxの基本的な知識はあると思う
  • Linuxサーバを個人で運用したい
  • チューニング、設定変更、パッケージ管理のコツを知りたい
  • 管理者は自分一人を想定している

方の参考になれば幸いです。

壊れる前の切り戻しの準備。

これが基本かつ重要な心構えです。

  • プログラム1つの更新
  • 設定ファイルの修正
  • コマンドミス

などで、サーバは瓦解します。しかも、自分の指先一つで壊れるのですから、何があっても

誰かのせいにしたいが自分の顔しか思い浮かばない
I'm casting around in my head for someone to blame and it's just me, keeps coming back at me.

という状況です。筆者が手順メモで

sudo cp -pi /etc/something/imporotant/config.file /path/to/backup/config.file.$(date +%Y%m%d)

とバックアップを取り、

diff -u /path/to/backup/config.file.$(date +%Y%m%d) /etc/something/imporotant/config.file

と、diffで差分を取るのは「何を変更しても（戻せる範囲で）切り戻せる」を体でたたき込んでいるからです。

バージョンアップ時にmysqldumpでDBのバックアップを取ったり、ディレクトリごと/サーバのイメージごとバックアップを取るなどもその表れです。

「何を」実行するのではなく「どこで」実行するか？

ふわっとしていますが、以下の状況を考えましょう。

/tmpディレクトリで

sudo rm -rf *

を実行するのと、

/etc/apache2/sites-available ディレクトリで

sudo rm -rf *

を実行するのでは、その後のサーバの状況（というよりも惨劇）がまるで違います。

「このコマンドを実行するのか」以上に「どのディレクトリでこれを実行するのか」を念頭に置いて、

cd /var/log && pwd

(cd /var/log ; pwdでも可)

を実行する習慣は極めて大事です。或いは、

/etc/profile.d/pwd.sh等のシェルスクリプトを作り、

#!/bin/bash

# カスタムcd関数を定義
cd() {
    # ビルトインcdコマンドの実行
    builtin cd "$@" || return

を登録しておけば、

cd /var/log

と実行するだけで、

cd /var/log && pwd

と同じ効果が得られます。

それ以上に大切な「いつ実行したか？」

「いつ」実行したかは「何を」よりも「どこで」実行したかよりも大事な証拠となり得ます。

設定がおかしくなった、または復旧したかのトリガーは

「いつ、何かをやったか」に、historyコマンドに明確に現れています。

また、これが、上述したバックアップしたときに

sudo cp -pi /etc/something/imporotant/config.file /path/to/backup/config.file.$(date +%Y%m%d)

と、$(date +%Y%m%d)変数をつけてまでファイルの変更管理を行うのは、その表れです。

チューニング時、「どの数値まで耐えられたか？」を記録するための多いな助けになります。

手順化するときは1コマンド1行。

復旧手順、慣れている作業ほど陥りやすいミスです。

こちらはサーバの証明書の整合性を確認するためのコマンドメモですが

  • 期限が延びていることを確認
openssl x509 -noout -dates -subject -in example.com.crt.$(date +%Y%m)
  • 証明書から公開鍵を取得
openssl x509 -pubkey -in example.com.$(date +%Y%m) -noout | openssl md5
  • 秘密鍵から公開鍵を取得
openssl pkey -pubout -in example.com.$(date +%Y%m) | openssl md5

と、1行に書くことで、視認性や意図が明確になります。これが

# 期限が延びていることを確認

openssl x509 -noout -dates -subject -in example.com.crt.$(date +%Y%m)

# 証明書から公開鍵を取得

openssl x509 -pubkey -in example.com.$(date +%Y%m) -noout | openssl md5

# 秘密鍵から公開鍵を取得

openssl pkey -pubout -in example.com.$(date +%Y%m) | openssl md5

と書かれていたら、1行ずつコピーする羽目になり、作業時の手間と効率化がまるで違います。

特に：サーバのバックアップ、復旧、切り戻しといった緊急と正確さが要求される状況下では、手順作成時のちょっとした手間がストレスを大きく軽減します。

最後に「記憶に頼るな、ログを信じろ」

  • 何かおかしい
  • 突然サーバが止まった
  • 誰かが攻撃している？

などのほぼ全ての証跡はログに残されています。ログに残っていなければその途絶えたところが証拠です。（いわゆる『吠えなかった犬の推理』）

例えば、先日、Nextcloudのレスポンスが悪い、という時の決定的な証拠は/var/log配下のphp8.3-fpm.logに現れていました。

[04-Oct-2025 17:32:36] WARNING: [pool www] server reached pm.max_children setting (5), consider raising it
[04-Oct-2025 18:45:55] WARNING: [pool www] server reached pm.max_children setting (5), consider raising it
[04-Oct-2025 21:28:57] WARNING: [pool www] server reached pm.max_children setting (5), consider raising it

これにより、PHP-FPMのプールの設定値に問題があったと特定できたのです。

何か怪しいと思ったら自分の設定値と同時に/var/log配下の関連しそうなところを確認しましょう。

そして、ログをそのままググり、どこかで誰かがエラーを元に解決策を残しているという期待もしましょう。

まとめ

と、わりとさっくりとした言い方ではありますが、

  • 切り戻せる姿勢
  • バックアップの大切さ
  • 手順の明確さ
  • タイムスタンプ

という4本の柱をメインにすれば、まず問題は無いかと思います。

『むこうぶち』の中にも

「船が陸にたどり着く寸前に生憎の嵐…… どうすればいいと思います？
いったん沖に引き返すんですよ
船ってのは水に浮かぶようにできているんです
無闇に上陸を焦って座礁する事が一番怖い」

は、サーバ運用にも通じるアナロジーとなっています。