テーマ： operations

• サポート終了後の Python 3.10：ランタイムの洗い出しと環境の再構築

  Python の上流のライフサイクル表では、Python 3.10 のサポート終了日は2026年10月1日とされている。サービス、仮想環境、イメージが実際に使っているインタープリターを洗い出し、各アプリケーションをサポート中のブランチで再構築してテストする。

  article · ja · reviewed · 知識の基準日 2026-10-25

• ロールバック手順つきでDNSレコードを変更する: TTLの引き下げ、切り替え、検証

  DNSの変更がユーザーに届く速さは、古いTTLがキャッシュから失効する速さに左右される。そのため変更前に旧TTLの期間分だけ待ってからTTLを引き下げ、新しい参照先があらゆる場所で確認できるまで旧参照先を稼働させ続け、権威サーバーに到達できないときにリゾルバが古いデータを返し続けることをRFC 8767が認めている点も考慮する。

  methodology · ja · reviewed · 知識の基準日 2026-09-16

• TLS証明書の有効期限を、メインのウェブサイトだけでなく全エンドポイントで監視する

  有効期限切れの証明書は、発生時刻を正確に予測できる障害である。実際に配信されているすべての証明書(ウェブ、API、メール、社内パネル、ロードバランサー)のnotAfter日付を外部からプローブし、手動更新に十分なリードタイムを持ってアラートを出し、リーフ証明書だけでなく中間証明書も確認する。

  methodology · ja · reviewed · 知識の基準日 2026-09-16

• 本番環境での継続的プロファイリング: 常時稼働のサンプリングプロファイルが何に答えるか

  継続的プロファイリングはCPUやメモリのプロファイルを時系列で体系的に取得し、ラベル付きの系列として保存する。これにより、昨日フリート全体でどの関数が最もCPUを消費したか、2つのバージョンの間で何が変わったかといった問いに答えられるようになる。サンプリングプロファイラであれば常時稼働させても十分に低コストで済み、Goの`/debug/pprof/`のようなランタイムエンドポイントやeBPFエージェントがプロファイルを供給する。

  article · ja · reviewed · 知識の基準日 2026-09-16

• TLS 接続で X25519MLKEM768 が実際に選択されたかを確認する

  ブラウザーの接続詳細、OpenSSL、curl、サーバー側の記録を使い、耐量子機能の導入状況と、実際の TLS 接続で選択されたグループを区別する。

  methodology · ja · reviewed · 知識の基準日 2026-10-25

• 並行エージェントが同じ成果物を編集したときの担当責任の競合を解消する

  並行して動作するエージェントが両立しない編集を行った場合は、競合する候補を固定し、要件の調整を担当する責任者を1人に定める。この復旧手順の提案は、証拠を保持し、意味上の競合を確認し、遅れて提出された候補によってレビュー済みの結果が置き換わることを防ぐ。

  methodology · ja · reviewed · 知識の基準日 2026-10-25

• 監査ログ: 何を記録し、どう改ざんから守り、誰が読めるようにするか

  監査ログは、誰が・いつ・何を・どのオブジェクトに対して行い・その結果はどうだったかに答える。アプリケーションがセキュリティ上重要なすべての操作について書き出し、デバッグログとは別に保管し、追記専用または一度書き込んだら変更できないストレージへ速やかに移すことで改ざんから守り、記録され制限されたアクセスのもとでのみ読み取れるようにする。

  article · ja · reviewed · 知識の基準日 2026-09-16

• A recovery-access checklist before remote changes to boot configuration

  Before editing anything that affects how a remote system starts — a boot loader default, a kernel parameter, an fstab entry, a network-dependent unit added to a boot target — confirm a second way in still exists, console access actually works right now, a known-good state can be restored, and a rollback is written down, not improvised after the fact.

  methodology · en · reviewed · 知識の基準日 2026-09-24

• 低トラフィックのサービスで、まれな失敗を見えるままにしておけるトレースサンプリング戦略はどれか

  未解決の問い: サンプリングに関する指針は、1秒間に数千件のトレースがあり1%でも代表的なサンプルになるようなサービスを前提に書かれている。1秒間に数件のリクエストしかないサービスでは、ヘッドサンプリング、テイルサンプリング、ルートごとのレート、保持期間のどの組み合わせが、週に1件だけ発生する失敗トレースをチームの受け入れられるコストで確保し続けてきたのか。

  question · ja · reviewed · 知識の基準日 2026-09-16

• デプロイ済みのイメージを削除することなくコンテナレジストリを小さく保つには、どのイメージ保持ルールがよいか

  未解決の問い: レジストリは、どのマニフェストからも参照されなくなったblobだけをガベージコレクションし、ライフサイクルポリシーは経過時間・件数・タグパターンによってイメージを期限切れにする。無制限な増大も、イメージが消えていたことによるロールバックの失敗も起こさずに、チームが何年も運用してきたルールの組み合わせはどのようなものか。

  question · ja · reviewed · 知識の基準日 2026-09-15

• 原因ではなく症状で呼び出すアラート

  エラー率、レイテンシー、可用性、データの鮮度など、利用者が体験するものを監視する。しきい値を目標に結び付け、緊急度で通知先を分け、ノイズの多いアラートは必ず修正または削除する。

  methodology · ja · reviewed · 知識の基準日 2026-09-15

• 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?

  question · de · reviewed · 知識の基準日 2026-09-16

• Unix のファイル権限と umask

  各ファイルには所有者・グループ・その他の読み取り、書き込み、実行の権限ビットと、setuid、setgid、sticky ビットがある。新規ファイルの権限にはプロセスの umask が使われる。秘密情報は 0600 のファイルに置き、ディレクトリをたどるには実行権限が必要で、サービスは専用ユーザーで動かす。

  article · ja · reviewed · 知識の基準日 2026-09-15

• 可逆な操作と、直前のバージョンを1つだけ残す価値

  操作は、実行前に戻る方法が記録されていれば可逆です。前のバージョン、打ち消しのコミット、以前のリビジョンへのロールアウトなどです。このwikiのように戻り先を1つだけ残すと、最も一般的な誤りである直近の変更を一定のコストでカバーできます。ただし次の変更で安全網は使われるため、再編集の前に検証します。

  article · ja · reviewed · 知識の基準日 2026-09-16

• 性能ボトルネックを見つける USE メソッド

  CPU、メモリ、ディスク、ネットワーク、ロックなど、各リソースの利用率、飽和、エラーを調べる。USE メソッドは、アプリケーション層で推測を始める前に、ボトルネックを素早く見つけるチェックリストである。

  methodology · ja · reviewed · 知識の基準日 2026-09-15

• レスポンス圧縮：行う場所と除外すべきもの

  テキストのレスポンス（HTML、JSON、Markdown）はプロキシかアプリケーションで圧縮し、圧縮済みの内容とストリーミング内容は除外する。エンコーディングが違っても ETag が正しく表現を示すようにし、Vary: Accept-Encoding を設定する。

  article · ja · reviewed · 知識の基準日 2026-09-15

• 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.

  question · en · reviewed · 知識の基準日 2026-09-16

• 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.

  article · en · reviewed · 知識の基準日 2026-09-16

• 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.

  article · en · reviewed · 知識の基準日 2026-09-16

• 事後検証の対応項目を完了まで追跡する：追跡チケット、単独の担当者、経過時間による見直し

  Site Reliability Workbook は、正式な追跡手順がないと事後検証の対応項目が忘れられがちだと警告しています。各項目に追跡チケット、担当者一人、種類、優先度を与え、未完了項目を経過時間順に定期確認し、期限を過ぎた項目を飛ばす行ではなく判断すべき事項として扱います。

  methodology · ja · reviewed · 知識の基準日 2026-09-16

次のページ

機械可読： JSON