大家好，我是老马。
作为一名程序员，我常常思考产品设计、版本迭代、用户体验、高可用架构、MVP模型……这些名词我们熟得不能再熟。
但回头看看自己的生活，却总觉得被困在某种循环里：每天重复敲代码、开会、修 Bug、迭代，连思考“我想要什么样的人生”都变得奢侈。
有没有想过，我们既然能设计出好用的 App、稳定的系统，为什么不能设计我们的人生？
最近我无意间刷到了一场来自斯坦福大学的演讲，名字就叫《设计你的人生》（Designing Your Life）。
今天想在这里记录一些自己的思考，分享给同样困惑的你。
用户痛点===》业务需求===》研发实现===》测试验证（功能/性能）===》QA（安全性、代码质量、依赖冲突等）===》上线发布===》日常运维===》（可观测）相关内容以前记录的比较多。
资源
应用视角==》单个报警
报警的主视角
普米: （cpu/mem/disk/net）
SQL: SQL 报警
CAT
log===>异常日志
知识库
top3 去重的异常日志？
cmdb
rpc
变更（标准化）
如果一个变更，可能会导致对应的异常。
首先要对报警的数据进行标准的格式化处理。
比如应用名，执行时间等等
ip + appName
比如：18:00~18:30
那么，对应的变更事件应该怎么办呢？
1）create_time
事件的创建时间刚好介于 18:00~18:30
16:00 and 18:30
都是这样来处理是不是比较合理？
要考虑哪些异常的内因呢？
同时考虑一些依赖资源的异常。
特别精确的时间范围控制，会导致无法准确的命中。
磁盘 一般 A2 以及以下可以忽略
mem 内存 A2 以及以下可以忽略?
disk ?
cpu ?
可以看一下 A2 以及以下的是不是没什么用？
GC
服务不可用
app
vm
phy
从报警的应用触发，经过 3 层左右，关联到所有报警的物理机器资源？
可以考虑将开头的 appList 放在入参，和目标存在问题的资源 ipList 放在那里？
可以把各种资源还是区分开？
统一调整一下【查看子图】的具体实现逻辑？
去重的时候，不要把 app 之类的给去没有了？？
我们接收到报警之后，需要把报警信息落库。
其实有两种思路。
一种是流，一种是批模式。
批模式可以做一些批量的优化操作。
比如 A2 的 disk 之类的无用异常过滤。
批模式如果改为 10 秒一次呢？
有什么问题？
批模式还可以支持数据的重跑，但是流没有这个能力。
可以两种模式都保留。
流模式可以在数据全部落库之后，最后做一下数据的落库处理。
实时性比较高。
我们需要分析报警，但是资源信息等很多，所以需要分级+剪枝过滤
1）从 alarm==>app
从报警关联到所有的 app
app
phy / vm / redis / mysql / pod / ...
包括网络：
vm / phy ====> nginx
结合 ai 打造 rca 系统，先让 ai 回答一下。
NOC 是 Network Operations Center（网络运营中心）的缩写。
NOC 是一个集中监控、管理和维护 IT 基础设施和服务可用性的指挥中心，主要职责是确保网络、服务器、应用、服务等持续稳定运行。
| 功能 | 说明 |
|---|---|
| 🔍 实时监控 | 网络设备、服务器、应用、链路、指标、告警等 |
| 🚨 故障响应 | 第一时间响应报警，初步诊断、升级或处理 |
| 📈 性能分析 | 长期观察网络与系统的健康状态，识别瓶颈 |
| 🛠️ 例行运维 | 执行计划任务、补丁更新、重启、配置调整等 |
| 📊 报表输出 | 生成服务SLA、可用性、故障统计等运营数据 |
| 📞 客户支持对接 | 某些NOC也兼任部分一线技术支持角色 |
结合 ai 打造 rca 系统，先让 ai 回答一下。
“COT” 有多个含义，具体要看上下文。但结合你目前的关注点（AI + 根因分析 + 智能推理 + 运维场景），COT 更可能是指：
这是在使用 大语言模型（LLM） 时的一种提示工程和推理策略，它通过**引导模型“逐步推理”**来提升复杂任务（如故障分析、逻辑推理、多步骤计算等）的准确率。