以前的企业级虚拟化方案，跟非虚拟化的服务器方案一样用的是集中式的共享存储，存储部分是厂家的私有系统，跟服务器之间通过 FC 、FCoE 、iSCSI 等协议连接，划分出一个个的块存储，在服务器端看来就是跟硬盘一样的 SCSI 块设备。不同的服务器可以连接同一个块设备，但只有虚拟机所在的物理机才挂载，这样迁移和故障转移只要把挂载机切换到目标物理机就可以。

超融合架构里不再有集中式的存储。每个节点都可以同时做虚拟机 host 和块设备的 provider 。为了解决迁移和故障转移的问题，用的是多副本写入方式。可以是 VMM 负责多副本写入，也可以是 Ceph 之类的分布式文件系统来负责多副本写入，从 VMM 来看是只写一份。

要运行的业务系统所服务主要对象的主要时区。

在未扩容的斐讯 N1 上跑了 3 个虚拟机的表示啥都不是事

你看，你也觉得生产分支应该 protect……所以没 protect 了你就任意提交？你是坚持自己的底线，还是跟着外部条件摆烂？

关于 3 ，请认真阅读 Filesystem Hierarchy Standard 以及你所用发行版的 packaging guide ，了解这样做的理念。

当然，你可以不同意。但人家这样设计是有原因的，而不是乱搞。

你自己编译安装的话，一般默认就是你喜欢的 ./configure --prefix=/some/prefix/that/everything/goes/on

@Worldispow 技术人员未必喜欢。喜欢的是管技术团队的人。

标准的问题就是有太多互相不服气的标准。

日本人写的《明解 Python 》

如果只是登录时看这个难受，并不介意实际更新，可以看看 /etc/update-motd.d 下面有没有 needrestart 更新 motd 的脚本干掉它

你拒个酒都这么扭扭捏捏怕三怕四的非要找借口，还不如早点想通，干脆破戒吧。

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

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

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

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