上线发布真正有用的不是说怎么样一个流程怎么一个 Checklist ，而是整个研发团队对于生产环境要有敬畏之心……
与其推动团队严格执行 Checklist ，不如把配套的工具能力搭建起来，不依赖于人去执行这些繁琐的事情，而是通过自动化的流水线工具，保障发布流程过程中错误能被准确及时暴露出来……

就同步的把人和货一起独占一台车送过去这个服务比较贵……返程 99%概率是空驶，所以你付钱肯定是付双向的钱……
想节约成本的话就需要找切入点，通过物流的方式一方面可以和其他同样流向的货物共享运输工具，且通常返程也有货可运，整个成本就便宜很多，缺点就是牺牲时效性……

6S Plus 使用的 A9 处理器即使到现在也不算非常拉胯，因为隔壁 Android 的低端机比他更菜……
比如 6S Plus 的 A9 处理器和某 1999 元手机的骁龙 680 能五五开……

XDR6086

这个是因为 Apple 在 iOS17 把 Carrier 信息的 API 给去掉了……

vacuum

XDR6078 两台正好

@dongpengfei1 设备网络能不能换，比如搞个啥 5G CPE 专门跑这个业务……其实相当于拉专线把高优先级业务跟低优先级业务隔离开来

客户端向服务端同时发起三个请求，任意一个请求成功了就认为成功了……
服务端向客户端下发支付成功消息，发三遍，收到任意一个消息就认为成功了……
三个请求都发生丢包的概率 = 5%^3 = 十万分之 125……

流量不够大……亿级 Key 百万 QPS 下边愁的是分片不能无限可分和节点负载不均

背景：XX 集团车辆管理模块有超过 XX 台车的运输状态跟踪需求。
问题：XX 集团的 XX 台车需要完成 XX 天 GPS 定位可追溯，如何低成本可靠实现？
方案：为了应对 IoT 上报数据流量不丢失，同时实现削峰填谷，上报 API 走 Kafka 存储。经消费到 MongoDB 后按日进行分片。为了节约成本使用冷热数据分离，冷数据定时任务转移到 HBase/Clickhouse 上。
结果：XX 台车每分钟上报 XX 个数据下，支持 XX 天内 XX 查询，资源成本 XX 元/日。

背景：以 XX 为核心业务的 XX 集团，其有 XX 台运营车辆用于 XX 业务。
问题：传统模式下，车辆依赖地面人员管理，在业务扩张过程中遇到诸多问题：车辆损坏不可用、年检到期不可用、在途情况不明等，经常导致部分地区无车可用，使得 XX 业务低效运转。
思路：XX 集团通过数字化转型，建设车辆管理模块，实现车辆信息与状态集中管理，进一步让车辆运行状态可视化，允许地面人员快速掌握车辆情况，提前做出准确的车辆调拨决策。
方案：车辆管理模块设计能够较好的服务业务开展，提供基本信息登记、维修状态登记流程、运输状态跟踪以及证件信息到期提醒等功能。
结果：车辆管理模块上线后，XX 地区无车可用情况大幅减少。承载 XX 业务下 XX 台车的日常运营工作，服务运营里程超过 XX 公里。证件到期提醒功能模块提醒次数 XX 次，减少车辆停驶 XX 日。

在用石英峡谷 i7 9850H + 64G DDR4 + 500G RC10 系统盘+ 2T PM981 数据盘
帅是真的帅 Intel AMT/vPro 是真的没法用……
拓展性上限很低，板上 2 个 M.2+底部 16x 加起来上不了几块盘，毕竟桌面级玩具……

ingress 只是对象，声明了路由……
traefik 是 ingress-controller ，监听 ingress 变化并根据 ingress 路由流量……
nginx 也可以改一改拿来做 ingress-controller ，具体的方案就是 ingress-nginx-controller……
CA 管理建议 cert-manager ，只需要先配个 ClusterIssuer ，对应证书只需要写好 Certificate 以后还能帮你自动 Renew……
比如我现在部署服务只需要先写份 Certificate 申一本证书，Helm 的 values.yaml 里给打上 ingress 配置，就可以 helm install 完直接域名访问……

买 3 片 J1900

看 SEA 股价就知道大家对于虾皮并不乐观，但是好在虾皮自己盘子规模够大，所以至少短时间内不愁吃不愁穿……下行周期里还开的出工资的总是比直接开始裁员的更好一些……

选不如买……

为啥是 K8S 而不是 YARN+Spark

k8s 用户有 traefik
全靠 cccv yaml 过日子
先复制个 yaml 去申请 cert
然后再复制个 yaml 写 ingressroute…