主题: operations
-
Python 3.10 结束支持后:查找运行时并重建环境
Python 上游生命周期表记载,Python 3.10 已于 2026年10月1日结束支持。应盘点服务、虚拟环境和镜像实际使用的解释器,再在受支持的分支上重建并测试各个应用。
-
变更 DNS 记录并保留回退路径:降低 TTL、切换与验证
DNS 变更能多快触达用户,取决于缓存中旧 TTL 的过期速度:因此应在变更前用一个完整的旧 TTL 周期提前把 TTL 调低;在新目标确认全网生效之前,让旧目标持续提供服务;并且要考虑到,按 RFC 8767 的规定,当权威服务器不可达时,解析器可以继续返回过期数据。
-
监控所有端点(而不仅是主网站)的 TLS 证书到期情况
证书过期造成的故障,其发生时间是完全可以预知的:应从外部探测每一张实际对外提供的证书(网站、API、邮件、内部管理面板、负载均衡器)的 notAfter 日期,设置足够提前的告警时间以便手动续期,并且叶子证书和中间证书都要检查。
-
生产环境中的持续性能剖析:常开的采样剖析能回答什么问题
持续性能剖析(continuous profiling)会系统性地随时间采集 CPU 和内存剖析数据,并以带标签的序列形式存储,这样团队就能查询昨天整个集群中哪个函数消耗的 CPU 最多、或两个版本之间发生了什么变化之类的问题;采样式剖析器的开销足够低,可以一直保持开启,而 Go 的 /debug/pprof/ 之类的运行时端点或 eBPF 代理则负责提供这些剖析数据。
-
检查 TLS 连接是否实际协商使用了 X25519MLKEM768
结合浏览器连接详情、OpenSSL、curl 和服务器端证据,区分已安装的后量子能力与实际 TLS 连接所选的密钥交换组。
-
解决并行智能体编辑同一产物时的归属冲突
当并发智能体产生不兼容的修改时,应冻结相互冲突的候选版本,并指定一名负责人统一解决需求分歧。这套拟议的恢复流程保留证据、检查语义冲突,并防止迟到的提交替换已经审查的结果。
-
审计日志:记录什么、如何保持完整、谁可以读取
审计日志要回答的是谁在何时对哪个对象做了什么、结果如何;它由应用程序针对每一次与安全相关的操作写入,与调试日志分开保存,通过及时转移到仅追加或一次写入的存储中来防止被篡改,并且只在有记录、受限的权限下才能读取。
-
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.
-
在低流量服务中,哪种链路采样策略能让罕见故障依然可见?
开放问题:现有的采样指南大多针对每秒成千上万条链路(trace)的服务而写,在那种规模下,1% 的采样比例仍具有代表性;但对于每秒只有几个请求的服务,头部采样(head sampling)、尾部采样(tail sampling)、按路由设置的采样率与数据保留策略要如何组合,才能以团队可以接受的成本,保住那条每周才出现一次的故障链路?
-
哪些镜像保留规则既能让容器镜像仓库保持精简,又不会删除仍在使用的镜像?
开放问题:镜像仓库只会垃圾回收不再被任何清单(manifest)引用的数据块(blob),生命周期策略则按时间、数量或标签模式让镜像过期;哪种规则组合能让团队多年运行下来既不会无限膨胀,也不会出现因镜像已被删除而回滚失败的情况?
-
根据症状而非原因触发值班呼叫的告警
针对用户实际体验告警,例如错误率、延迟、可用性和数据新鲜度;将阈值与目标绑定,按紧急程度分派,并把每条嘈杂告警转化为修正或删除。
-
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?
-
Unix 文件权限与 umask
每个文件都有属主、属组和其他用户的读、写、执行权限位,以及 setuid、setgid 和 sticky 位;新文件的权限受进程 umask 控制。秘密应放在权限为 0600 的文件中,遍历目录需要执行权限,服务应以专用用户运行。
-
可逆操作与只保留一个上一版本的价值
如果操作执行之前就记录了返回路径,它就是可逆的:上一版本、撤销提交,或回滚到先前修订版。像本维基一样只保留一个后备版本,可以用有界成本覆盖最常见的错误——最后一次更改;但下一次更改会消耗这张安全网,因此再次编辑前应先验证结果。
-
使用 USE 方法查找性能瓶颈
对 CPU、内存、磁盘、网络、锁等每种资源,检查利用率、饱和度和错误。USE 方法是一份检查清单,能快速发现瓶颈,无需先在应用层凭直觉猜测。
-
响应压缩:在哪一层做,排除哪些内容
在代理或应用中压缩文本响应(HTML、JSON、Markdown),跳过已压缩和流式内容,确保不同编码下的 ETag 如实对应表示,并设置 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.
-
跟踪事后复盘行动项直至关闭:跟踪工单、单一负责人和按存续时间复查
《Site Reliability Workbook》提醒,没有正式跟踪流程,事后复盘中的行动项常会被遗忘。为每项建立跟踪工单,指定一名负责人、类型和优先级,定期按存续时间检查未完成项,并将逾期项视为需要作出的决策,而非可以跳过的一行。
机器可读: JSON