@vtgoal 后面我思路被他带过去了，在吐槽他说的管理上万台物理机的假设对我的现实情况没意义，看起来好像我要表达的重点成了大 vs 小的规模……其实我本来不是要说这个的。

不过说起来，规模大的场景里，对技术细节的要求的确不是重点考虑的，而且也是难以去重点考虑的。只要钱到位，用管理手段和所谓的职业化精神，总可以包装出巧克力盖浇屎，来掩盖内部实现的恶臭。

但是没这条件的时候（所谓没条件不一定是因为小厂，也可能是因为体制问题，比如叠床架屋的婆婆机构，业务单位拿不到 infra 的经费，只能做纯业务系统，而且经费只够勉强把业务功能做好，不会有余量来提升 infra ，但同时本该负责 infra 的信息化平级负责单位的 infra 水平又不够让业务单位放下心不去考虑 infra ），没办法像他说的用当代一互大的先进运维方式去提升 infra 水平，只能去抠类似“在 RH 系上，自己手工编译一堆基础组件，装好的路径乱七八糟各种不可预测，可执行程序的 FS owner 和启动的 euid 一样，在 shell 里手工 nohup 交互启动，而且从来特奶奶的不管任何更新”的 bad practice 细节。

他以为我不想“清楚自己的定位”，以为我想啥都管，以为我不想搞 baseline 每个基础组件变更都审核，不想用一互大的先进理念吗？除了你说的小规模（另外提一下，小规模不一定是小“厂”）条件下不一定有必要用大长的思维，再就是没条件啊。除了没钱，也没这样做机制。

他说我关注的这些技术细节的玩法是 10 年前的……可是如果我像业务部门人员、技术部门里技术能力停留在入职前永远不再更新的伪技术人员一样只关心业务功能实现，不关注这些东西，那我的“地行小”vendors 送给我的可不只是 10 年前……恐怕放到 20 年前都算烂的了。我在没条件把我手上的 infra 拉到 1 年前的情况下，至少还努力尝试从 20 年前拉到 10 年前。他说的那些再先进的，臣妾真的没力气做到了。

另外，我认为，以前做事不讲究，动辄搞出“在 RH 系上，自己手工编译一堆基础组件，装好的路径乱七八糟各种不可预测，可执行程序的 FS owner 和启动的 euid 一样，在 shell 里手工 nohup 交互启动，而且从来特奶奶的不管任何更新”等各种运维屎的那些乙方“（又做业务对接又写代码又勉为其难给甲方做部署和运维的）综（合）信（息化人员）”们，在现在流行的容器化 infra 下，实际上只是在做巧克力盖浇屎，虽然容器化在一定程度上可以减缓原来不懂 infra best practice 带来的问题（比如容器内环境较为精简可以减少攻击面，比如可执行程序文件的 FS owner 和启动的 euid 一样导致的远程溢出获取 shell 来修改可执行程序埋桩可以随着容器的毁灭重建复原），但屎还是屎，不能因为浇了一层巧克力壳就变成巧克力。