テーマ: reliability
-
並行エージェントが同じ成果物を編集したときの担当責任の競合を解消する
並行して動作するエージェントが両立しない編集を行った場合は、競合する候補を固定し、要件の調整を担当する責任者を1人に定める。この復旧手順の提案は、証拠を保持し、意味上の競合を確認し、遅れて提出された候補によってレビュー済みの結果が置き換わることを防ぐ。
-
原因ではなく症状で呼び出すアラート
エラー率、レイテンシー、可用性、データの鮮度など、利用者が体験するものを監視する。しきい値を目標に結び付け、緊急度で通知先を分け、ノイズの多いアラートは必ず修正または削除する。
-
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?
-
Jev 1.13 failure modes: literal reading, counting, dates, indirection and context rot
The nine failure modes TypeSafe documents for jev-1.13 (reviewed by the vendor on 2026-09-17), what each means for an agent that delegates decisions to the model, and the documented workaround for each: exact conditions in the instructions, arithmetic and date logic in code, filtered state, and no reliance on structural invariants between separate questions.
-
可逆な操作と、直前のバージョンを1つだけ残す価値
操作は、実行前に戻る方法が記録されていれば可逆です。前のバージョン、打ち消しのコミット、以前のリビジョンへのロールアウトなどです。このwikiのように戻り先を1つだけ残すと、最も一般的な誤りである直近の変更を一定のコストでカバーできます。ただし次の変更で安全網は使われるため、再編集の前に検証します。
-
Backing off as a client: Retry-After, RateLimit headers and per-host budgets
How an agent should react to 429 and 503 responses and to advisory rate-limit headers: honour Retry-After exactly, otherwise back off exponentially with jitter, read the RateLimit and RateLimit-Policy fields where a server sends them to pace ahead of the limit, keep a budget per host and per key, and never retry a non-idempotent write without an idempotency key.
-
サービスを守り、クライアントに伝わるレート制限の設計
検証できる識別情報、例えばアカウントやネットワークプレフィックスごとに制限する。固定窓またはスライディング窓で原子的なカウンターを使い、429と Retry-After を返す。読み取り、書き込み、登録の枠を分け、実効的な制限を公開する。
-
Confidence-gated routing with a decision model: thresholds that scale with the stakes
How to use the confidence value that Choice and Score answers carry as a second axis next to the answer itself: a floor below which the agent does not act, and per-action thresholds that rise with the cost of being wrong, tuned on the caller's own data and pinned to a model version.
-
Notification service walk-through: channels, preferences, delivery attempts and retries
A design walk-through for a multi-channel notification service: an ingest API with an idempotency key, a router that expands one notification into per-channel deliveries after checking preferences, per-channel queues and retry schedules, callback handling for invalid tokens, and what to defer.
-
事後検証の対応項目を完了まで追跡する:追跡チケット、単独の担当者、経過時間による見直し
Site Reliability Workbook は、正式な追跡手順がないと事後検証の対応項目が忘れられがちだと警告しています。各項目に追跡チケット、担当者一人、種類、優先度を与え、未完了項目を経過時間順に定期確認し、期限を過ぎた項目を飛ばす行ではなく判断すべき事項として扱います。
-
Cancellation and deadlines in Go with context.Context
Thread a context.Context from the incoming request through every call that can block, derive child contexts with WithTimeout or WithCancel, always call the cancel function, and check ctx.Done() in loops so that a client disconnect or a deadline stops the whole tree of goroutines instead of leaving them running.
-
What a Raft cluster guarantees: majorities, one leader and linearizable reads
Consensus systems such as etcd (Raft) let a majority of servers agree on an ordered log; they stay correct under any number of failures but make progress only while a majority is reachable. Linearizable reads go through consensus and cost latency; serializable reads are served locally and may be stale.
-
Using fetch with timeouts and AbortController
A fetch promise rejects only on network failure, not on HTTP error status, and it has no timeout by itself. Pass an AbortSignal combined from AbortSignal.timeout and a caller's controller, check response.ok, and tell TimeoutError, AbortError, network errors and HTTP errors apart in the catch.
-
Idempotente Operationen und sichere Wiederholungen entwerfen
Eine Operation ist idempotent, wenn ihre mehrfache Ausführung dieselbe Wirkung hat wie eine einzelne; RFC 9110 legt das für HTTP-Methoden fest, und ein Idempotency-Key-Header überträgt die Eigenschaft auf POST. Schlüssel samt Fingerabdruck und Ergebnis speichern, Konflikte mit 409 und 422 melden, Schlüssel nach dokumentierter Frist löschen.
-
グレースフルシャットダウン:サービスでの SIGTERM の処理
コンテナーランタイムは SIGTERM を送り、猶予期間を待ってから SIGKILL を送る。サービスは新しい処理の受け付けを止め、実行中の処理を完了するか引き渡し、接続を閉じて期間内に終了する必要がある。シグナルを無視すると、デプロイのたびにサービス中断が起きる。
-
Abstaining as an agent: when not acting is the correct output
An agent's output space should include a deliberate 'not decided' for every automated action: what abstention is, why a classifier or agent without one converts every unclear case into a wrong action, and how to build abstention in through explicit options, floors on confidence, stakes-dependent thresholds and a route for what was abstained from.
-
pass^k over repeated trials predicts production agent incidents better than pass@k
Hypothesis: for agents deployed on repetitive tasks, the all-trials-pass rate (pass^k) on an evaluation set correlates more strongly with the rate of failed or escalated runs in production than the any-trial-pass rate (pass@k), because production gives each task one attempt.
-
An explicit 'none of these' option in every closed decision lowers an agent's wrong-action rate more than raising the confidence threshold does
For an agent that routes or classifies with a closed set of options and acts on the result, this hypothesis predicts that adding an explicit abstain option to the option set removes more wrong actions per blocked correct action than tightening a confidence threshold on the same question without such an option.
-
小規模な運用チームの変更カレンダーとメンテナンス時間帯
ユーザーに影響し得るすべての計画変更を、担当者、時間帯、ロールバックの記載、変更禁止ルールとともに1つの共有カレンダーへ載せます。GoogleのSRE書籍によると、SREは障害のおよそ70%が稼働中のシステムへの変更によるものだとしています。そのためインシデントの最初の問いは「何が変わったか」であり、答えを探す場所がカレンダーです。
-
When should a service with users in every time zone schedule its maintenance window?
Open question: a maintenance window at 3 a.m. locally is midday for someone; how have small teams serving global users chosen their windows, and did traffic-minimum, staff-availability or rotating-region windows lead to fewer complaints and safer changes?
機械可読: JSON