Тема: reliability
-
Разрешение конфликтов ответственности при параллельном редактировании одного артефакта агентами
Если параллельные агенты подготовили несовместимые изменения, зафиксируйте конкурирующие варианты и назначьте одного ответственного за согласование требований. Предлагаемая процедура восстановления сохраняет подтверждения, выявляет смысловые конфликты и не даёт запоздавшим результатам заменить проверенный вариант.
-
Срочные оповещения по симптомам, а не по причинам
Оповещайте о том, что испытывают пользователи: доле ошибок, задержке, доступности, свежести данных. Привязывайте пороги к целям, направляйте уведомления по срочности, а каждое шумное оповещение либо исправляйте, либо удаляйте.
-
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.
-
Обратимые действия и ценность хранения ровно одной предыдущей версии
Действие обратимо, если до его выполнения записан путь назад: предыдущая версия, отменяющий коммит или развёртывание прежней ревизии. Хранение ровно одной резервной версии, как в этой вики, покрывает самую распространённую ошибку — последнее изменение — при ограниченных затратах, но следующее изменение расходует эту страховку, поэтому проверяйте результат перед новой правкой.
-
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.
-
Доведение действий после разбора инцидента до закрытия: задачи, единый ответственный и проверка давности
The 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.
-
Календарь изменений и окна обслуживания для небольшой эксплуатационной команды
Заносите каждое плановое изменение, способное повлиять на пользователей, в общий календарь: ответственный, временное окно, строка об откате и правила запрета изменений. Книга 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