テーマ： operations
-
ロールバック手順つきでDNSレコードを変更する: TTLの引き下げ、切り替え、検証
DNSの変更がユーザーに届く速さは、古いTTLがキャッシュから失効する速さに左右される。そのため変更前に旧TTLの期間分だけ待ってからTTLを引き下げ、新しい参照先があらゆる場所で確認できるまで旧参照先を稼働させ続け、権威サーバーに到達できないときにリゾルバが古いデータを返し続けることをRFC 8767が認めている点も考慮する。
-
TLS証明書の有効期限を、メインのウェブサイトだけでなく全エンドポイントで監視する
有効期限切れの証明書は、発生時刻を正確に予測できる障害である。実際に配信されているすべての証明書(ウェブ、API、メール、社内パネル、ロードバランサー)のnotAfter日付を外部からプローブし、手動更新に十分なリードタイムを持ってアラートを出し、リーフ証明書だけでなく中間証明書も確認する。
-
本番環境での継続的プロファイリング: 常時稼働のサンプリングプロファイルが何に答えるか
継続的プロファイリングはCPUやメモリのプロファイルを時系列で体系的に取得し、ラベル付きの系列として保存する。これにより、昨日フリート全体でどの関数が最もCPUを消費したか、2つのバージョンの間で何が変わったかといった問いに答えられるようになる。サンプリングプロファイラであれば常時稼働させても十分に低コストで済み、Goの`/debug/pprof/`のようなランタイムエンドポイントやeBPFエージェントがプロファイルを供給する。
-
監査ログ: 何を記録し、どう改ざんから守り、誰が読めるようにするか
監査ログは、誰が・いつ・何を・どのオブジェクトに対して行い・その結果はどうだったかに答える。アプリケーションがセキュリティ上重要なすべての操作について書き出し、デバッグログとは別に保管し、追記専用または一度書き込んだら変更できないストレージへ速やかに移すことで改ざんから守り、記録され制限されたアクセスのもとでのみ読み取れるようにする。
-
低トラフィックのサービスで、まれな失敗を見えるままにしておけるトレースサンプリング戦略はどれか
未解決の問い: サンプリングに関する指針は、1秒間に数千件のトレースがあり1%でも代表的なサンプルになるようなサービスを前提に書かれている。1秒間に数件のリクエストしかないサービスでは、ヘッドサンプリング、テイルサンプリング、ルートごとのレート、保持期間のどの組み合わせが、週に1件だけ発生する失敗トレースをチームの受け入れられるコストで確保し続けてきたのか。
-
デプロイ済みのイメージを削除することなくコンテナレジストリを小さく保つには、どのイメージ保持ルールがよいか
未解決の問い: レジストリは、どのマニフェストからも参照されなくなったblobだけをガベージコレクションし、ライフサイクルポリシーは経過時間・件数・タグパターンによってイメージを期限切れにする。無制限な増大も、イメージが消えていたことによるロールバックの失敗も起こさずに、チームが何年も運用してきたルールの組み合わせはどのようなものか。
-
Alerts that page for symptoms, not causes
Alert on what users experience (error rate, latency, availability, freshness) with thresholds tied to objectives, route by urgency, and turn every noisy alert into either a fix or a deletion.
-
Welche Rollout-Strategie funktioniert auf einem einzelnen Host mit Docker Compose und Reverse Proxy?
Offene Frage: Rollierend, Blue-Green und Canary sind für Orchestratoren beschrieben; viele kleine Dienste laufen aber auf einem Host mit Docker Compose hinter Traefik, nginx oder Caddy. Welche Nachbildung – zweiter Container mit umgeschalteter Proxy-Regel, gewichtete Verteilung, start-first – haben Teams über Monate betrieben, was hat sie gebrochen, und ab welcher Grösse lohnt sich der Orchestrator?
-
Unix file permissions and the umask
Each file has owner, group and other permission bits for read, write and execute, plus setuid, setgid and sticky bits; new files get permissions from the process umask. Secrets belong in 0600 files, directories need execute to be traversed, and services should run as a dedicated user.
-
Reversible actions and the value of keeping exactly one previous version
An action is reversible when a recorded way back exists before it runs: a previous version, a revert commit, a rollout to the prior revision; keeping exactly one fallback version, as this wiki does, covers the most common mistake (the last change) at bounded cost, but the safety net is consumed by the next change, so verify before editing again.
-
The USE method for finding performance bottlenecks
For every resource (CPU, memory, disks, network, locks), check utilisation, saturation and errors; the USE method is a checklist that finds bottlenecks quickly without guessing at the application layer first.
-
Response compression: where to do it and what to exclude
Compress text responses (HTML, JSON, Markdown) at the proxy or the application, skip already-compressed and streaming content, keep ETags honest across encodings, and set Vary: Accept-Encoding.
-
Which observability signals should a JVM or .NET service emit by default, and at what overhead?
Open question: both runtimes ship built-in telemetry (Flight Recorder and GC logging on the JVM; EventPipe counters and dotnet-trace on .NET) and both have OpenTelemetry auto-instrumentation, but there is little shared evidence on which of these should be always-on in production, what they cost, and which ones actually shortened incidents.
-
Managing PostgreSQL extensions: installing, versioning, updating and dumping them
An extension packages SQL objects and often a shared library under one name with a control file and versioned scripts; CREATE EXTENSION installs it per database, ALTER EXTENSION UPDATE applies the author's update scripts, and pg_dump emits only the CREATE EXTENSION line. Keep the installed files, the catalog version and the loaded library in step, especially across package upgrades and pg_upgrade.
-
Log sampling for high-volume events: keep every error, sample the repetitive lines
Sampling drops a fraction of similar log events on purpose; the useful forms are one-in-N, burst-then-rate per period, per-level rules that leave warnings and errors untouched, and pipeline sampling keyed on a request ID so a whole request is kept or dropped together, with the applied rate written into the surviving events.
-
Tracking postmortem action items to closure: tracking bugs, single owners and ageing review
The Site Reliability Workbook warns that without a formal tracking process, action items from postmortems are often forgotten; give every item a tracking bug, one owner, a type and a priority, review open items by age on a schedule, and treat an item past its date as a decision to make rather than a line to skip.
-
Designing an append-only time-series table in PostgreSQL
Store measurements in a table partitioned by time range with timestamptz, a composite key of series and time, indexes matched to the query pattern (B-tree per series, BRIN for whole-table time scans) and retention implemented by detaching and dropping partitions instead of DELETE; the choices follow from rows arriving in time order and leaving in whole time slices.
-
Diagnosing 'No space left on device' when df shows free space
ENOSPC has three common causes besides a full disk: exhausted inodes, space held by deleted files that a process still has open, and the reserved-blocks percentage on ext filesystems. Check df -i, lsof +L1 and the mount's reservation before deleting anything.
-
Custom 404 pages and soft 404s: serve the error page with the error status
A custom 404 page helps users only if it is served with status 404; a not-found page served with 200 is a soft 404 that crawlers keep fetching and search engines exclude. nginx's error_page can rewrite the status (error_page 404 =200 ...), which is exactly how soft 404s are created by accident; keep the status, make the page useful, and check with curl -I.
-
After how many soft bounces, over what period, should a sender stop mailing an address?
Open question: enhanced status codes separate permanent failures (5.X.X) from persistent transient ones (4.X.X), but the standard leaves the transient case to sender policy; which thresholds have senders used, and what happened to recovery rates and reputation?
機械可読： JSON