要坚持底线思维和极限思维，准备经受风高浪急甚至惊涛骇浪的重大考验。

简单说来我是在总结我的愤怒。对别人没啥参考价值。

当你看到一只小强的时候，已经有一千只小强了。

“从 A 语言换为 B 语言导致性能提升 XYZ 倍”这种事一般不是因为换语言本身，而是换语言这个大动作不可能以对旧版系统慢慢重构的方式进行，那么本质上就是重写一遍，那么就要重新架构，重新思考，“终于特喵的有机会偿还技术债了” ^_^

@ql562482472
至于你提到的“同时也能提高平台的安全性”什么的……当然也许在你所在的行业和场景里是这样的。
但我遇到上级信息化主管部门通报过来的安全事件里，有不少案例，但凡乙方的技术团队里有懂运维的，但凡少自作多情写点基础设施代码，但凡老老实实用成熟的基础设施（不论是甲方已经熟悉的还是已经打包在 Linux distro 里的其它第三方组件），就特喵的不会出事！

@ql562482472

2. 我说的不是 all in code （代码） 而是 all in coding （写代码），是个动名词，我想表达的是（念着咒语祭起粗壮高大的巨型 IDE ，用久经产业考验的软工领域热爱的编程语言）来写（业务功能之外的、已有很多“进程外”基础设施组件的）（基础设施功能）代码这个行为。

3. 对于信息化岗位上的人没有技术能力或者没有技术意愿，甚至可能没有专门的信息化部门，只是归在综合管理办公室里的一个科员岗的“文科式”甲方信息化人员来说，可能不管技术细节的 turn key 工程是最好的。而我只是作为一个懂技术也想去考虑技术细节的苦逼又装逼的甲方信息化小主管，希望，乙方能有真正的能通盘做技术考虑的人跟我对应。而不是让 all in coding 蔓延。提到 fat jar 并不是说我认为 fat jar 不好，war 好，而是我遇到的太多阿猫阿狗做的技术“选择”（甚至可能并不是有意选择，而是师傅怎么带我的我就怎么做，网上的 tutorial 怎么写的我就怎么做）图省事，并不是像你说的经过了利弊分析思考的结果。
另外 1 ，如果乙方在文科式甲方只提功能要求的情况下交付了软件代码，要求甲方提供其他基础设施，当然是很扯鸡九蛋的，哪怕是 all in coding 的结果交付了也比这样做好；另外 2 ，在甲方有自己积累下来的 best practice 基础设施意向的情况下，应用交付也应该涵盖对甲方基础设施意向的适配。
再重复一遍，我不是说 fat jar 不好，而是我特喵的特氖氖的特烙烙的遇到的只会用 fat jar 的阿猫阿狗们实在是大概率让我想砍人。我宁肯自己累一点，作为甲方拔拔里的苦逼运维人员，自己来负责基础设施的调校，而不是看着写业务代码的阿猫阿狗们自以为是地重复造烂轮子实现各种非业务的基础设施功能各种不靠谱而我却眼睁睁无能为力。

回报内容的条目要分类+排序（好像两个的英文都是 sort 哈哈哈哈）
抓重点、强调收效，实在没有功劳的时候才讲苦劳
有量化依据的一定要量化，除了汇报时，工作中也注意记录可量化的结果

@mrzx 要是真跳槽了，那可是 EdgeMax 爱好者的一大损失~><~

除了 EdgeRouter ，我还没见过非 OpenWRT 的成品路由器支持 dnsmasq with ipset 并通过 include conf.d 让我导入几千条要按这规则处理的域名（用途不可名状，懂的都懂）

@MilkyWayne 有 19 英寸机柜一样宽度的组装式家用杂货架，甚至立着的四根角铁上的垂直孔距都是按机柜距离打的，唯二问题，一是深度远远不够，二是强度恐怕没法撑住大多数机架式设备

不过在 PVE 的 web UI 里搞这种操作改配置有可能不小心搞断网

PVE 里个给 eth1 、2 、3 做 bridge ，在 bridge 上配置管理 IP ，OpenWRT 的 LAN 口接到 bridge 上

不考虑一互大的秒杀这种极端需求，在普通的信息系统应用场合，绝大多数“顺手写出来”的 log 库，还不如打到 syslog 再用 logrotate 做切分更方便。用 logrotate ，至少我可以配置切分前、切分后调用自己的脚本来做预备和善后处理。而用业务纯程们自己写的日志，十有八九只有他们自己调试时用起来顺手。

@ql562482472 甲方一般不关心技术。我是异种。

@ql562482472 主要是后者。

因为面向行业信息化的软件系统里，业务功能和基础设施功能可以看作是两个不同的领域。既然是不同领域，就有不同的知识模型。不排除做行业信息化的公司里也有相当的专家熟悉基础设施领域的知识，但因为做行业信息化的公司其核心价值是解决客户的业务发展需求，所以首要的关注点、投入最大技术人力成本的方向是实现业务功能。而基础设施领域里则有更擅长的参与者。对于做行业信息化的公司来讲，要业务功能开发人员兼顾基础设施开发，实际上是逆分工而行，出力不讨好。尤其是，相当一大部分程序员是没有能力写高质量的基础设施的。

给你举个我遇到的真实例子。上级信息主管部门发来安全通告，某个业务系统的后台管理模使用的开源组件老版本爆出 CVE ，要求限期内处理。问供应商，答曰我们用的这个业务系统已经是老版本了，他们公司现在主推新版，老版不再更新，而且那个开源组件直接换成新版的可能不兼容……可以给我们安装新版本的业务系统并迁移数据，不额外收钱。但是新版本安装实施时间挺长的，超过处理期限了。我说你们老系统的 web server 是 IIS 这种通用的玩意，你后台管理模块路径是确定的，在 IIS 里配一个 ACL 规则，先把后台管理限制在我们单位的 IP 范围内，对最终用户还是全部开放，这样不行么？对方说，加上限制 IP 的功能要排期做开发，旧版系统他们不改动了。我说这是运维手段解决问题，不需要你们程序员改代码。对方还是坚持这是功能变更。吵了好几轮，最终还是我放弃了。先停掉有问题的旧版系统再说。

举这个例子是想说明，像分模块做 IP ACL 之类的功能，其实是和客户的“业务”功能没有关系的基础设施功能。做基础设施软件的开发商（不论是 IIS 开发者微软这种真的“商”，还是免费的 Apache 、Nginx ）早就把基础设施功能玩得溜溜转，你能想到的基础设施功能需求很可能就是用现成软件做做配置就好了，你没想到的，他们也都早替你想到了。而他们在基础设施领域的经验、技术能力、成本投入，都不是做业务系统的开发商在完成客户业务功能开发这一核心价值之外顺便来开发基础设施功能所能比拟的。善用成熟的第三方基础设施软件，善用运维手段解决非业务方面的功能需求，这在某种意义上也是解耦，不次于“开发”中所做的解耦。尤其是复杂的软件系统会跨越不同编程语言、运行在不同进程甚至不同机器上，用好成熟基础设施，往往能比业务纯程们在写业务功能之余自己去造基础设施的轮子，甚至比起用现成的基础设施库或框架嵌到自己写的程序里调用，都有更好的收效。据说 Spring Boot 时代，主流的做法是构建一个巨大的 jar 用 java 命令启动，不提倡构建成 war 放到 tomcat 之类容器里运行。这种做法当然有其应用场合和原因。但是我想问一下，从来不碰生产环境运维配置的纯程们，是否知道只靠修改 tomcat 的 server.conf 、不自己写代码，能对 tomcat 的行为做多少控制，能解决多少你们第一反应是写代码实现的非业务功能需求？这些如果都靠业务纯程们来写，要多少工作量？代码质量如何，是否能担得起“基础设施”的质量要求？即使不自己写，靠项目里 embed 一个 tomcat 或者 jetty 的核心包，如果要达到打包好的 tomcat/jetty 的可配置程度，你又要在自己的项目里写多少代码来处理配置？

Everything in Java, everything in coding……反正我是不太喜欢这样的乙方团队给我干活的。

跟业务功能无关但又需要根据项目实施场景来定制的基础设施是放在哪里？通过库 /组件引入业务系统，还是在业务系统之外作为独立的基础设施用运维手段搞定？不同背景的人有不同的答案。

单一技术栈、以纯程序员为主的团队，用 SpringCloud 或者类似的其它能把基础设施集成到程序里的“全开发”式方案会比较顺手，而混合技术栈、运维技能全面的团队，可能更适合业务逻辑归业务逻辑，基础设施归基础设施，后者多使用运维手段来解决。

如果这两个节点在同一二层网络，把做配置的拖出去打死。
如果在不同的二层网络，把提要求的拖出去打死。

@JoeoooLAI 但是 UISP 那个 OS 目前还看不到详细资料，尤其是 CLI 的资料……如果是作为 EgdeMAX 的后继，这样很难平替的。