laozhoubuluo

1. 建议还是改了，毕竟有单独的路由器。一般来说少 NAT 几次肯定是好事，而且本版用户一般的路由器肯定比光猫 NAT 好，配置更灵活。比如之前我测试华为某个光猫写静态路由指向 LAN 侧地址看着生效了实际不生效。
2. 端口映射或者开个 VPN 拨号进来。前者方便开销小，后者安全性高不少。看业务安全性决定。
3. 正常思路是非标端口。不过现在有个 Alt-Svc ，配合境外低速主机可以利用一下加速资源加载。

@MagmaBlock 光猫确实存在 NAT 性能不好导致连接数多了就卡问题。近几年的新光猫性能强还带 NAT 加速会缓解不少，不过十个人一起用的话还真不好说。

@luomao 算不到钱可以算（开发 /测试 /产品）人天，懂的管理人员能自动换算成钱，但是数据没有换成钱直观好看就是了。
核心是让管理人员看到技术改造投资物超所值，毕竟即使您直属领导能看懂技术价值，但再往上走很多领导不一定有这么敏锐的技术视角能把技术价值直接转换成业务价值，这就需要您在述职报告里面帮他转换一下，不管是省钱还是省人天。

不少部级别的网络都没有卫星授时 NTP ，这个确实现在对于客户甚至机房运维来说比较新鲜，毕竟很多外包运维都不太挣钱且加班很猛，这种运维就不要对他们有太高的技术要求了。遇上这种只能是有互联网的配置互联网 NTP ，接不了的就指向交换机追求相对一致性或者索性自生自灭了。

不过递归 DNS 设备采购成本不高，UPS 电池反倒是贵不少。这两个不搞只能理解为机房运维销售不会运作或者客户除了维保费一分钱不愿意多掏了。

做业务+技术路线也是个发展路线，不过我理解这句话意思应该是在汇报里面体现业务价值，例如如下修改。

1. 通过建设开放平台，实现内部开发对接流程均在开发平台实现，使得开发间提高沟通效率且对接方式有据可查。本平台上线至今已经实现 XXX 个需求全线上对接，上线后需求上线周期平均缩短 X 天（ XX %），根据团队平均时薪 XXX 元计算上线至今已节约成本 XXX 万元，预计随着开发进一步熟悉开放平台，预计 2023 年度需求上线周期平均较 2022 年平台上线前缩短 X 天（ XX %），每年可节省成本 XXXX 万元。
2. 通过实现 K8S 平台云原生改造，增加平台承载力，推进 DevOps 建设。当前云原生版本相较于原有单体版本资源占用下降 XX% ，承载峰值流量能力上升 XX%，同时支持动态扩缩容可以根据当前业务情况动态增减，从而避免手工预测流量的不准确性，降低公有云采购成本 XX%。通过 K8S 改造实现部署环境与开发环境完全一致，进一步加强开发自测有效性，实现测试团队发现 Bug 率降低 X% ，根据历史数据推算可降低因 Bug 带来的经济损失 XX 万元。同时由于开发自测的有效性，因此测试团队本年度无需根据需求数量增长而新增测试人员，可进一步降低人员成本 XX 万元。

如果上述数据大多数都比较好看，都写到晋级述职里面，那绝对不会被批 "没有呈现业务价值" 。
如果上述绝大多数的数据都 <= 0 ，那么在目前的经济形势下就不是考虑公司业务发展的问题了，那就是考虑下家怎么找的问题了。

不知道是国际统一的标准化版本，还是之前上海电信测试的溯源版本。
前者喜大普奔，后者限制有点大了。

这个主要看互联网大厂对 HTTP/3 的推进，毕竟如果大家都换 HTTP/3 完了相关业务流量都被不合理的 QoS 策略卡掉那投诉率要上天，所以在快速更换 HTTP/3 的前提下运营商迫于投诉压力可能能调整一些比较极端的限制另外进一步推进扩容降低 QoS 概率。
当然能做到的最好结果也就是临近省份内部互通近似于 TCP 水平，境内互通不会遭受极端 QoS 策略例如流量稍大一点直接完蛋。至于境内完全达到 TCP 水平甚至国际层面有什么改善纯属想太多。

1. COBOL 在国内几乎只有银行还在用而且没有新应用，既有应用也在慢慢的被 Java 等语言重写，而且 COBOL 的底层环境也不符合国产化要求，没有企业会去投入一个注定没有未来的项目。
2. COBOL 的系统想求稳的基本上不会接受国产化改造这种有很大业务运行风险的改造，能接受的业务大概率也能接受重新招标一套新系统替换或者用 Java 重写的方案。
3. 即使 1 和 2 都不是问题，想找同时懂 COBOL 和云数据库的可能都不是钱的问题，是找得到找不到一个团队的问题。

@TerranceL 是的，管理和沟通成本高到超出了对于不少人可行的 "父母家宽带提速+设置备份集群" 的模式了，甚至前者还可以给父母提供些点播片源和数据备份服务之类的。
另外几百 GB 数据加密成本都够一壶，更别提加密（除流算法之外）导致文件体积上涨的问题了。

可以这么想，要开发一套操作系统出来基本上就是投钱的问题，投十个亿给靠谱团队做一套完整的图形化操作系统没啥问题，只是还得花几倍几倍的钱投入生态，毕竟信创搞了这么些年，从用户来看生态还是远远不如 Windows 的。
但是 CPU 嘛，设计制造的坎就要多的多了，从底层的材料科学到上层的所谓光刻机，这些肯定不是百亿量级能解决的问题了。

@edis0n0 要考虑个问题，Linux 的驱动优化不一定比 Windows 好，更别提有些好的驱动因为 License 问题无法打包进 Linux 的问题。