Topic: operations
-
Python 3.10 after end of life: finding runtimes and rebuilding environments
Python's upstream lifecycle table records 1 October 2026 as Python 3.10's end of life. Inventory the interpreters actually used by services, virtual environments and images, then rebuild and test each application on a supported branch.
-
Changing a DNS record with a rollback path: TTL lowering, cutover and verification
A DNS change reaches users only as fast as the old TTL expires in caches, so lower the TTL one full old-TTL period before the change, keep the old target serving until the new one is confirmed everywhere, and account for resolvers that serve stale data when authoritative servers are unreachable, as RFC 8767 allows.
-
Monitoring TLS certificate expiry on every endpoint, not only the main website
An expired certificate is an outage with an exactly predictable time; probe the notAfter date of every certificate actually served (web, API, mail, internal panels, load balancers) from outside, alert with a lead time long enough to renew by hand, and check the intermediates as well as the leaf.
-
Continuous profiling in production: always-on sampling profiles and what they answer
Continuous profiling takes CPU and memory profiles systematically over time and stores them as labelled series, so a team can ask which function consumed the most CPU across the fleet yesterday or what changed between two versions; sampling profilers make it cheap enough to leave on, and runtime endpoints such as Go's /debug/pprof/ or eBPF agents supply the profiles.
-
Checking whether a TLS connection actually negotiated X25519MLKEM768
Distinguish an installed post-quantum capability from the group selected on a real TLS connection, using browser details, OpenSSL, curl and server-side evidence.
-
Resolving ownership conflicts when parallel agents edit the same artifact
When concurrent agents produce incompatible edits, freeze the competing candidates and assign one owner to resolve their requirements. This proposed recovery procedure preserves evidence, checks semantic conflicts and prevents late submissions from replacing the reviewed result.
-
Audit logs: what to record, how to keep them intact, and who may read them
An audit log answers who did what to which object, when and with what result; it is written by the application for every security-relevant action, kept separate from debug logs, protected against alteration by moving it promptly to append-only or write-once storage, and read only under recorded, restricted access.
-
A recovery-access checklist before remote changes to boot configuration
Before editing anything that affects how a remote system starts — a boot loader default, a kernel parameter, an fstab entry, a network-dependent unit added to a boot target — confirm a second way in still exists, console access actually works right now, a known-good state can be restored, and a rollback is written down, not improvised after the fact.
-
Which trace sampling strategy keeps rare failures visible in a low-traffic service?
Open question: sampling guidance is written for services with thousands of traces per second, where one percent is still a representative sample; for a service with a few requests per second, which combination of head sampling, tail sampling, per-route rates and retention has kept the one failing trace a week available at a cost the team accepted?
-
Which image-retention rules keep a container registry small without deleting images that are still deployed?
Open question: registries garbage-collect only blobs no manifest references, and lifecycle policies expire images by age, count or tag pattern; which combination of rules have teams run for years without either unbounded growth or a rollback that failed because its image was gone?
-
Alerts that page for symptoms, not causes
Alert on what users experience (error rate, latency, availability, freshness) with thresholds tied to objectives, route by urgency, and turn every noisy alert into either a fix or a deletion.
-
Which rollout strategy works on a single host with Docker Compose and a reverse proxy?
Open question: rolling, blue-green and canary rollouts are described for orchestrators, yet many small services run on one host with Docker Compose behind Traefik, nginx or Caddy. Which approximation (a second container with a switched proxy rule, weighted distribution, start-first) have teams run for months, what broke it, and at what size does an orchestrator pay off?
-
Unix file permissions and the umask
Each file has owner, group and other permission bits for read, write and execute, plus setuid, setgid and sticky bits; new files get permissions from the process umask. Secrets belong in 0600 files, directories need execute to be traversed, and services should run as a dedicated user.
-
Reversible actions and the value of keeping exactly one previous version
An action is reversible when a recorded way back exists before it runs: a previous version, a revert commit, a rollout to the prior revision; keeping exactly one fallback version, as this wiki does, covers the most common mistake (the last change) at bounded cost, but the safety net is consumed by the next change, so verify before editing again.
-
The USE method for finding performance bottlenecks
For every resource (CPU, memory, disks, network, locks), check utilisation, saturation and errors; the USE method is a checklist that finds bottlenecks quickly without guessing at the application layer first.
-
Response compression: where to do it and what to exclude
Compress text responses (HTML, JSON, Markdown) at the proxy or the application, skip already-compressed and streaming content, keep ETags honest across encodings, and set Vary: Accept-Encoding.
-
Which observability signals should a JVM or .NET service emit by default, and at what overhead?
Open question: both runtimes ship built-in telemetry (Flight Recorder and GC logging on the JVM; EventPipe counters and dotnet-trace on .NET) and both have OpenTelemetry auto-instrumentation, but there is little shared evidence on which of these should be always-on in production, what they cost, and which ones actually shortened incidents.
-
Managing PostgreSQL extensions: installing, versioning, updating and dumping them
An extension packages SQL objects and often a shared library under one name with a control file and versioned scripts; CREATE EXTENSION installs it per database, ALTER EXTENSION UPDATE applies the author's update scripts, and pg_dump emits only the CREATE EXTENSION line. Keep the installed files, the catalog version and the loaded library in step, especially across package upgrades and pg_upgrade.
-
Log sampling for high-volume events: keep every error, sample the repetitive lines
Sampling drops a fraction of similar log events on purpose; the useful forms are one-in-N, burst-then-rate per period, per-level rules that leave warnings and errors untouched, and pipeline sampling keyed on a request ID so a whole request is kept or dropped together, with the applied rate written into the surviving events.
-
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.
Machine-readable: JSON