Chapter 28 — Field practice
Lesson map
Lesson 28 published. Map, example, EX082.
flowchart TD
N0["Learning outcomes"]
N1["28.1 The event"]
N2["28.2 Coordination"]
N3["28.3 Communication"]
N4["28.4 Timeline"]
N5["28.5 Reflection"]
N6["28.6 Lessons"]
N7["Compared with January"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX082"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["28.1 The event"]
N2["28.2 Coordination"]
N3["28.3 Communication"]
N4["28.4 Timeline"]
N5["28.5 Reflection"]
N6["28.6 Lessons"]
N7["Compared with January"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX082"]
[Learning outcomes]
|
v
[28.1 The event]
|
v
[28.2 Coordination]
|
v
[28.3 Communication]
|
v
[28.4 Timeline]
|
v
[28.5 Reflection]
|
v
[28.6 Lessons]
|
v
[Compared with January]
|
v
[Worked example] --> [Exercise EX082]
Learning outcomes
You will (1) apply the course in a real-style advisory response; (2) coordinate across clients; (3) communicate clearly; (4) reflect on what worked.
28.1 The event
In the final month, a synthetic high-severity advisory is published for a widely used form library. This time, the nightly job matches it to nine client projects within hours of publication. The contrast with January is the point of the event. Instead of three days of manual searching, the nightly job reads every project's lockfile, compares versions with the advisory and produces tasks with owners attached. Diego starts the day with a list of nine affected projects rather than a question nobody can yet answer.
28.2 Coordination
Owners receive tasks automatically. Diego coordinates: sensitive clients first, updates through the weekly bot pipeline, validation tests rerun before deployment. Ordering by sensitivity uses the context notes recorded earlier, so Greenleaf and other clients with personal data are updated first. Using the weekly bot pipeline means each fix is tested, reviewed and recorded by digest like any other change. Rerunning the validation tests before deployment confirms the update did not break uploads, pinning or digest recording. Diego tracks each project's status in the client security status page.
28.3 Communication
Affected clients get a short message: what the issue is in plain terms, whether their site was affected, what was done and when. Unaffected clients who ask get a clear "not affected" answer from the inventory record. Clients unaffected by the advisory and who ask get their answer from the inventory record, which lists every project's form-library version. Affected clients receive the message once the fix is deployed, so it can state what was done and when. The shortened template that came out of this event keeps each message to a few plain sentences.
28.4 Timeline
All nine projects are fixed within four days, well inside the 7-day target. Compared with January's three days just to find affected clients, the difference is clear. The comparison is not exact, since January's library and this event's library differ, but both were high-severity advisories affecting several clients. The four-day figure covers matching, fixing, validating and deploying for all nine projects. That margin left time to handle the legacy project's slower fix without missing the 7-day target. Each project's fix date is recorded, so the timeline can be checked against the tasks.
28.5 Reflection
The team notes that the slowest fix was in a legacy project, again pointing to the rebuild. The legacy project's slower fix came from its missing update automation and older code, the same causes noted in Diego's research. That pattern now appears in the research, the troubleshooting page and the field event, which together give the directors a clear case for the rebuild. The team also notes which steps went smoothly, so they are not changed unnecessarily. The rebuild decision is left to the directors, who receive the evidence in one place.
28.6 Lessons
Two runbook steps are improved and the client message template is shortened after feedback. One runbook step improved is how to add a temporary hold when a client asks to delay an update during the event. The other clarifies how to confirm an inventory match before tasks are opened. Client feedback says the message template was too long, so it is cut to the three answers clients want. Both runbook changes are reviewed and merged within the week, while the event is still fresh in everyone's memory.
Compared with January
In January, three days went on manual searching before any fix began, and the full extent was unclear. In the field event, matching took hours, owners were known, fixes followed the update pipeline and validation, and every client received an accurate answer. The difference came from routine work done earlier: the inventory, the nightly job, the pipeline template and the runbooks. None of it was dramatic, but together it changed how the agency responded, and the directors agreed to keep funding the time owners spend on these processes.
Worked example
Aiko presents the event to Brightwave's directors as evidence that the placement's three goals have been met: the inventory answered in minutes, highs were fixed within 7 days, and every deployment was a recorded pipeline build.
Synthetic case. The event and results are synthetic.
Errors and limits
One good event does not prove the process always works; keep measuring.
Exercises
- EX082 — Detection. How quickly were affected projects found? Rubric: 3 = within hours via nightly job; 2 = partial; 1 = vague; 0 = none.
- EX083 — Fix time. How long did fixing take? Rubric: 3 = four days for all nine; 2 = partial; 1 = vague; 0 = none.
- EX084 — Goals met. Which goals were shown to be met? Rubric: 3 = inventory minutes; 7-day highs; recorded builds; 2 = two; 1 = one; 0 = none.
Synthesis
The controls turn a three-day search into a four-day fix.
Continue studying — chapter 28 of 30
← Chapter 27 (draft) · Course chapter index · Chapter 29 (draft) →