テーマ： incident-response
-
A secret was committed: why deleting the file is not enough and what the response order is
A credential pushed to a Git repository persists in history, forks, clones, caches and CI logs. Rewriting history reduces future exposure but cannot recall copies, so the first step is to revoke and rotate the credential, then clean the history, then check for use.
-
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.
-
After a vulnerability report arrives: acknowledge, assess, fix in private, disclose
Once a report reaches the project's security contact, the work is a sequence with dates: acknowledge quickly, classify (working as intended, bug, feature request, vulnerability), agree an embargo with the reporter, develop the fix privately, obtain a CVE identifier, then release and publish an advisory that names affected and fixed versions and credits the reporter. The OpenSSF maintainer guide and GitHub's disclosure guidance describe this process; this article compresses it for a project with one to five maintainers.
-
Security incident response for a small team: a minimum procedure
A two-person team cannot run a security operations centre, but it can prepare a contact list, a containment checklist and an evidence rule in advance; NIST SP 800-61 Rev. 3 frames incident response as part of ongoing risk management, and this procedure is the minimum that makes the first hour predictable.
-
Postmortems ohne Schuldzuweisung: Ablauf, Ursachen und Massnahmen festhalten
Ein Postmortem beschreibt, was während eines Vorfalls geschah, wen es wie lange traf, welche Umstände es ermöglichten und welche Massnahmen eine Wiederholung unwahrscheinlicher machen. Schuldfreiheit ist kein Höflichkeitsgebot, sondern die Bedingung dafür, dass Beteiligte Fakten berichten statt sich zu verteidigen.
-
Correlation versus causation in incident and operations data
A correlation coefficient measures how two series move together; it says nothing about which one drives the other, whether a third factor such as traffic drives both, or whether the data were selected by the outcome. Plot first, condition on the obvious common causes, check timing, and confirm with an intervention such as a flag or canary before acting.
-
A first game day: one chaos experiment with a hypothesis, a blast radius and an abort rule
Run a first fault-injection exercise as a scheduled, announced experiment: define the steady state as a measurable output, hypothesise that it holds under one specific fault, limit the blast radius, set an abort condition, inject, and record what the system and the people did; the Principles of Chaos Engineering give the four steps and the Google SRE book describes disaster role-play as a weekly ritual.
-
Runbooks für den Betrieb: Anleitungen, die eine Fremde nachts ausführen kann
Ein Runbook pro Dienst beantwortet in dieser Reihenfolge: Was tut der Dienst, woran erkennt man in einer Minute, ob er gesund ist, welche bekannten Störungen gibt es mit Symptom, Diagnosebefehl und Gegenmassnahme, welche Handlungen sind sicher, welche gefährlich, und wer ist wann zu eskalieren; geprüft wird es von jemandem, der es nicht geschrieben hat.
-
Teams with fewer, alert-linked dashboards diagnose incidents faster than teams with many unowned dashboards
Hypothesis: for services of comparable size, the time from a page to a named probable cause is shorter when the team maintains a small number of owned dashboards that alerts link to directly, than when it maintains many copied or auto-generated dashboards that responders have to browse; a proposed comparison using incident timelines and dashboard inventories.
-
Running a public status page honestly: components, automation and history
A status page earns trust only when it turns red when users see red; host it off the infrastructure it reports on, list components users recognise, let everyone on call post without approval, update on a fixed cadence during incidents, and keep the history visible.
-
Incident status updates: a template and a cadence
During an incident one person owns communication and posts updates on a fixed schedule from a template: status, user-visible impact, what is known, what is being done, and the time of the next update; the update goes out on time even when nothing has changed.
-
Alerts that carry a runbook link are acknowledged faster and silenced less often than alerts without one
Hypothesis: alerting rules can carry annotations such as descriptions or runbook links, as the Prometheus documentation describes; the proposal is that pages from rules with a working runbook link are acknowledged and resolved faster and are silenced or muted less often than pages from rules without one, on the same team and in the same period.
-
Incident severity levels: definitions, who declares them and when to assume the worst
A severity scale works only if anyone on call may declare an incident and pick a level without asking, if each level is bound to a concrete response, and if the rule under uncertainty is to take the higher level and review it in the postmortem; PagerDuty's public response documentation and the Google SRE book both give conditions for declaring early.
機械可読： JSON