Original, source-backed articles about running small systems, static sites, HTTP, DNS, TLS, and operations.
Posts are original articles written for this site. Each one is script-free, source-backed, and tied to the same operational reality the rest of the site records: how a small, static, publicly served system is built, secured, and kept honest.
Annotations carry metadata that consumers can interpret
Annotations attach non-identifying metadata to Kubernetes objects. They can record provenance, ownership notes, or information consumed by a tool. Standard label selectors do not select objects by annotation values, but that does not make annotations inert. A controller, admission component, or deployment tool can interpret a documented annotation and change behavior accordingly. Know the consumer before deciding that a metadata edit is harmless.
...
Disk schedulers order I/O to move the head efficiently
blk-mq gives the block layer a software staging queue per CPU and a hardware dispatch queue per device queue, with the I/O scheduler between them. A request takes the shortest path — straight to the hardware queue — unless a scheduler is attached or it can be merged, in which case it is staged in software first. That scheduler is the only place in the stack where the kernel decides the order your requests reach the device.
...
Structured logs make their query contract explicit
Structured logging assigns stable meaning to fields instead of asking each query to infer everything from message text. A record might contain an event name, request identifier, numeric duration, severity, and a human-readable message. Free text remains useful and can also be searched or parsed. The practical gain is that routine questions can use a documented schema whose meaning survives changes to explanatory wording.
...
A charset tells the reader how the bytes become characters
Character encoding connects bytes to characters. In text/plain; charset=utf-8, the charset parameter names that connection; changing the parameter does not change the payload. Reliable text delivery requires agreement between the producer’s actual encoding and the consumer’s decoding rules, not simply the appearance of the word UTF-8 in a configuration file.
...
Postmortems are for learning, not blame
After an incident, a postmortem should explain what happened, what people knew at the time, and which changes could reduce future harm. Blamelessness makes candid reporting safer. It does not guarantee that an incident cannot recur, remove ownership, or turn every explanation into an established fact. Learning requires both an honest account and evidence that useful follow-up actually happened.
...
Command substitution puts one command's output into another line
Command substitution captures a command’s standard output and inserts the resulting text into a surrounding expression. The familiar $(command) form is useful for a timestamp, a computed label, or another small textual value. It is not a transparent channel for arbitrary bytes or a reliable way to transport a list of filenames. Its newline handling, execution environment, and exit status are part of the interface you need to understand.
...
An access log separates client outcomes from upstream attempts
An nginx access log records request information when logging runs at the end of processing. The selected fields can distinguish what the client requested, which URI ultimately handled it, what response was sent, and what happened during upstream attempts. These are different observations. A useful format keeps them separate instead of assuming that one status, duration, or path explains the whole request by itself.
...
Incident response needs a timeline
During an incident, memory is unreliable, and clocks can disagree too. A timeline — who was paged, what was observed, what was tried, when the change landed — is what makes a response recordable and later reviewable.
Write as it happens Memory is the least reliable instrument in an incident, so record while the alert is fresh. Capture the timestamp of the first alert, the initial symptoms, each action tried and its observable result, and the moment the fix actually took effect. That running record is what keeps a team from repeating a failed fix during the response, and what later makes an honest postmortem possible instead of a plausible story. Make the timeline a live document from the minute the page fires: note the tool that alerted, the metric, the suspected and the confirmed cause, and record ‘same as before, did not help’ rather than silently re-trying.
...
