カテゴリ

サーバー

LinuxやWebサーバー、デプロイ、保守まわりで手を動かした記録をまとめます。

まず押さえたいこと

サーバーは構築して終わりではなく、更新、バックアップ、監視、ログ、障害時の復旧まで含めて運用を考えます。

よくある入口

Linux初期設定、Webサーバー、メール送信、VPS、バックアップ、デプロイの記事を順に読むと全体像がつかみやすいです。

実務で見るポイント

設定値そのものより、なぜその設定にしたのか、障害時にどこを見ればよいのかを残しておくと後で助かります。

サーバー 2026.09.12 19

robots.txtでUser-agentを名指しすると、アスタリスクの指定が効かなくなる|AIクローラーの止め方

robots.txt にクローラー名を書いたグループを作ると、そのクローラーにはアスタリスクのグループが一切適用されなくなります。結合ではなく置き換えなので、拒否を1行も書いていないグループを足しただけで制限が外れることがあります。標準ライブラリで再現した結果と、AIクローラーを検索用と学習用で書き分ける方法をまとめます。

アラートが多すぎて見なくなる|監視の誤検知が減らない3つの原因と直し方

毎週アラートが出るのに対応した記憶がない。原因はたいてい対象の数ではなく検知の書き方です。行が無いことを停止と読む、全文の変化を異常として通知する、決め打ちのパスで探す。この3つを実際に動かして再現し、さらに通知そのものが届いているかを確かめる方法までまとめます。

メモリ監視は正常なのにプロセスが落ちる|空きメモリではOOMを検知できない理由

空きメモリのしきい値でアラートを組んでも、メモリ不足による強制終了は検知できません。強制終了の瞬間にメモリが解放されるためです。上限64MBのコンテナで2回OOMを起こした直後の使用量は上限の3.8%でした。真偽値と累積カウンタの違い、安全に再現する手順までまとめます。

docker builder pruneで容量が減らない原因|上限指定が0Bしか消さない仕組み

ビルドキャッシュの掃除を定期実行しているのに容量が減らない。上限を指定する方式は、使用量が上限を超えていなければ何も消しません。上限指定・時間指定・全件指定がそれぞれ何を消すかをDocker 29.7.2で実測し、公式ドキュメントと実機の食い違い、そして既存のキャッシュを壊さずに試す方法までまとめます。

「最終実施日」が信用できなくなる設計|実施と通知を同じ列に書かない

運用タスクの一覧に「最終実施日 3日前」と出ていても、実施した日とは限りません。通知を送る処理が同じ列を更新していると、一度も実行していなくても最近やったように見えます。SQLiteで動く形で再現し、事実を1行ずつ残す設計への直し方と、手元のデータが信用できるか調べるクエリまでまとめます。

脆弱性スキャナが緑でも本番は古いことがある|lockと実体がずれる原因と確認方法

ロックファイルが新しく脆弱性スキャナも0件なのに、実際に動いているものだけが古いことがあります。スキャナが見ているのは宣言であって実体ではないためです。ロックは0.35.4、実体は0.35.1、audit は0件という状態を手元で再現し、確認方法とその盲点まで実測でまとめます。

while readループが1回で終わる原因|docker execとsshが標準入力を食う

リストを1行ずつ処理するシェルのループが、エラーも出さずに1件目だけで終わる。原因はループではなく、中で呼んでいるdocker exec -iやsshが標準入力を読んでしまうことです。20行のリストで実際に測った処理件数と、4つの直し方、そして再発を検知する書き方までまとめます。

DBのdry run(ドライラン)とは?本番でUPDATE・マイグレーションを流す前の確認方法

DBのdry run(ドライラン)は、実際には変更せずに「実行したら何が起きるか」だけを確認することです。本番のUPDATE・DELETE・マイグレーション事故の多くは、実行前の数分で防げます。同じWHERE句でSELECTして件数を数える基本から、BEGIN→ROLLBACK、Laravelの migrate --pretend、pt-online-schema-changeやgh-ostのdry run、バックアップから復元してのリハーサルまで、確実さと手間の順に5段階で整理。MySQLのDDLは暗黙コミットでROLLBACKできないという重要な落とし穴も公式マニュアルの記述とあわせて解説します。

RDBMSパフォーマンスチューニングの基礎|SQL・索引・キャッシュの順で考える

RDBMS(MySQL・PostgreSQL・Oracleなど)のパフォーマンスチューニングの基礎を、共通する考え方として整理します。鉄則は「安くて効果の大きい順」に手を打つこと。まず推測せず実行計画やスロークエリで測り、次にSQLと呼び出し側のプログラム(N+1や取りすぎ)を疑い、それから索引(インデックス)を付け、どうしてもダメなら非正規化・マテリアライズドビュー・キャッシュを検討します。なぜこの順番なのか、なぜ主要RDBMSで共通なのか(コストベース最適化・統計情報・B-treeインデックス)まで、初心者にも分かるように解説します。