この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
この記事では、20年以上Linuxサーバーを運用してきた経験から、複数人管理で必ず発生する「属人化・情報共有・変更追跡」の問題と、最低限決めておくべきルールの考え方を解説します。
この記事のポイント
・複数人管理では「誰が・いつ・何をしたか」の記録が最重要
・設定変更前後のバックアップと変更理由の記録が事故を防ぐ
・sudo権限は最小限にし、作業ログを残す仕組みを先に作る
・「口頭で伝える」だけのルールは必ず崩壊する
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
複数人管理で必ず起きる3つの問題
私がSE時代（2001年～2006年）に客先常駐で経験したことですが、複数人でサーバーを管理している現場には、ほぼ例外なく3つの問題が潜んでいます。問題1: 「誰かが変えた」問題
障害が発生した時に「最近設定を変更しませんでしたか？」と聞くと、「俺は変えていない」「私もやっていない」という返答が返ってくる。しかし実際にはApacheの設定ファイルのタイムスタンプが昨日の夜更新されている、という状況です。
セミナーで3,100名以上を指導してきた中で、この「誰も変えていないのに変わっている」問題は本当によく聞かれます。原因のほとんどは「誰が変えたかを記録する仕組みがない」ことです。
問題2: 設定の根拠が消える問題
設定ファイルに不思議なパラメータが書かれていても、なぜそう設定したのかが分からない。担当者に聞くと「前の人が設定したやつで、理由は知りません」という返答。触ったら壊れそうなので誰も変更できず、設定が化石のように残り続けます。
問題3: 権限が曖昧になる問題
「とりあえず全員sudoができるようにしてある」という現場は意外と多いです。これは作業効率を優先した結果ですが、誰でも何でもできる環境では責任の所在が曖昧になり、慎重さが失われます。
最低限決めておくべき4つのルール
1. sudoの使用を記録する仕組みを作る
まず最初にやるべきことは、誰がsudoを使って何を実行したかをログに残す仕組みの整備です。Linuxのsudoはデフォルトで/var/log/secure（RHEL系）や/var/log/auth.log（Debian系）にログを記録しますが、これをすぐに確認できる状態にしておくことが重要です。# sudo実行履歴をリアルタイムで確認する（RHEL系） # journalctl -f _COMM=sudo # 直近のsudo実行をまとめて確認する # grep sudo /var/log/secure | tail -50 # sudoで実行されたコマンドを確認する（RHEL系） # grep COMMAND /var/log/secure | tail -20 Apr 15 09:12:34 server01 sudo: miyazaki : TTY=pts/0 ; PWD=/etc/httpd/conf ; USER=root ; COMMAND=/bin/vi httpd.conf Apr 15 10:45:21 server01 sudo: tanaka : TTY=pts/1 ; PWD=/etc/nginx ; USER=root ; COMMAND=/bin/systemctl restart nginx
私が現場でよく見かけるのが、ログが/var/log/secureに何百MBも積み上がっていて、実際に調査が必要な時に誰も見方を知らないというケースです。チームメンバー全員が確認方法を理解しておく必要があります。
2. 設定変更前のバックアップと変更理由の記録を義務化する
設定ファイルを変更する前には、必ずバックアップを取ることを習慣化します。# 設定変更前のバックアップ（日付付き） # cp /etc/httpd/conf/httpd.conf /etc/httpd/conf/httpd.conf.bak.$(date +%Y%m%d_%H%M%S) # バックアップの確認 # ls -la /etc/httpd/conf/httpd.conf.bak.* -rw-r--r-- 1 root root 11803 Apr 15 09:10 /etc/httpd/conf/httpd.conf.bak.20260415_091012 -rw-r--r-- 1 root root 11823 Apr 20 14:22 /etc/httpd/conf/httpd.conf.bak.20260420_142201
私が実践してきたのは、設定ファイルのコメント行に変更理由を書き残すことです。
# /etc/httpd/conf/httpd.conf の変更例 # 変更日: 2026-04-15 # 変更者: miyazaki # 変更理由: 画像ファイルが大きいため、タイムアウト値を120秒に延長 # 変更前: Timeout 60 Timeout 120
3. sudo権限の範囲を役割ごとに分ける
全員に全権限のsudoを与えるのではなく、役割に応じた権限設計を行います。/etc/sudoersをvisudoで編集して、実行できるコマンドを制限します。# visudoで編集する（/etc/sudoers） # Webサーバー担当者はApache・Nginxの操作のみ許可 %web_admin ALL=(ALL) /bin/systemctl start httpd, /bin/systemctl stop httpd, /bin/systemctl restart httpd # DB担当者はMySQLの操作のみ許可 %db_admin ALL=(ALL) /bin/systemctl start mysqld, /bin/systemctl stop mysqld, /bin/systemctl restart mysqld # 確認コマンド（sudo -l で自分が使えるコマンドを確認） # sudo -l Matching Defaults entries for miyazaki on server01: !visiblepw, always_set_home, match_group_by_gid User miyazaki may run the following commands on server01: (ALL) /bin/systemctl start httpd, /bin/systemctl stop httpd, /bin/systemctl restart httpd
4. 変更を事前に共有するプロセスを作る
本番サーバーへの変更は、事前にチーム内で共有するプロセスを設けます。手軽な方法は、SlackやメールのチャンネルにSECHANGE_LOGとして変更予定を投稿するルールを作ることです。投稿する内容の最小セットは以下の通りです。
・対象サーバー: 変更するサーバーのホスト名
・変更内容: 何をどう変更するか
・変更理由: なぜこの変更が必要か
・変更予定時刻: いつ作業するか
・影響範囲: サービスへの影響があるかどうか
・ロールバック手順: 変更を戻す方法
これは障害発生時の「最近変更を加えましたか？」という確認を、数秒で行えるようにするための仕組みです。
ルールを形骸化させない3つの鉄則
ルールを作っても、時間が経つと守られなくなることがあります。20年以上の経験から、形骸化を防ぐために重要なことを3つ伝えます。鉄則1: ルールは文書化して共有ディレクトリに置く
「口頭で決めたこと」は必ず忘れられます。どんなに簡単なルールでも、共有できる場所に文書として残してください。社内Wikiでも、サーバー上の/etc/admin-rules.txtでも構いません。大切なのは「探せば見つかる場所」に書いてあることです。
鉄則2: ルール違反を見つけたら即座に指摘する
「まあ今回くらいはいいか」という一度の見逃しがルールの崩壊を招きます。ルール違反（例: バックアップなしで設定を変更した）を見つけたら、責める口調ではなく「次からはこの手順で」と即座に伝えることが重要です。
鉄則3: ルールは定期的に見直す
半年前に作ったルールが今の運用に合っているとは限りません。3ヶ月に1度程度、チームでルールを見直す機会を設けることを推奨します。「使いにくいルールは守られない」という現実を受け入れ、実態に合わせて改善することが大切です。
まとめ
複数人でのLinuxサーバー管理で最低限決めておくべきことをまとめます。| 課題 | 対策 |
|---|---|
| 誰が変更したか分からない | sudoログを確認できる状態にする |
| 設定の理由が分からない | 変更理由をコメントとして設定ファイルに残す |
| 変更後に壊れた時に戻せない | 変更前のバックアップを日付付きで取る |
| 誰でも何でもできてしまう | sudo権限を役割ごとに制限する |
| 変更を誰も知らない | 事前共有プロセスを設ける |
これらのルールは、大規模なツール導入や複雑な設定なしに、今日から始められるものです。20年以上の経験から断言できますが、こうした「基本の仕組み」を先に整えておくと、障害対応の時間が劇的に短くなります。
Linuxサーバー管理の基礎的な知識体系や、実務で使えるコマンドの使い方については、以下の記事も参考にしてください。
・Linuxの作業記録を残す習慣が現場の評価を変える理由｜historyとscriptの活用法
・Linuxサーバーの「引き継ぎ地獄」を防ぐ3つの習慣｜現役講師が現場で学んだ属人化対策
チームでのLinux運用の「正しい型」を学びませんか？
複数人管理では、個人の技術力だけでなく「チームで動く仕組み」が求められます。
ネットの切れ端の情報をコピペするだけでなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
P.S
セミナーでは、複数人での安全なサーバー管理の「考え方」を実践的に学べます。1人で動かして終わりではなく、チームに展開できるスキルを最短で身につけることができます。
【Linuxセミナー】リナックスマスタープロセミナー
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 次のページへ：Linuxの本番サーバーでchmodを間違えた話｜現役講師が語る権限ミスの実体験と正しいパーミッション設計の考え方
- 前のページへ：Linux学習を毎日続けるための習慣術｜現役講師が語る「消えない力」の作り方
- この記事の属するカテゴリ：Linux学習ガイドへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます