................GITLAB 这种重要数据库都没备份？！

@mandymak
估计他想折腾的是 ESXI+磁盘直通跑 ZFS

@yongw520
CPU 不带核显即可
服务器主板自带的显卡也就仅仅够让你用来看个日志，那玩意大多是 ATI 的 32M 闪存走 PCI 总线的亮机卡
另外 楼上有人提到了小马的 V5 ，其实还有一个选择是带外壳的 3215U ，性能不咋地，但是做软路由很合适。
（小马的 CPU 是 ES ，务必注意）

我说 ESXI 不适合折腾也和软路由有关，因为折腾的过程中必然会频繁的重装系统 /修改配置。
如果是 ESXI+显卡直通的结构，配置会增加不少复杂度，略显麻烦与复杂
倒不如设备分区那么在折腾的时候不会导致全屋网络中断

我现在比较倾向于一个高可用的结构 EdgeRouter X + 3215U （需要地址我去淘宝找 699 标价）组合成双路由
（路由架构： ERX 提供 NAT ， 3215u 配置 ESXI ，上层虚拟机使用 VyOS 做软路由，两个路由使用 VRRP 保持可用）
（ ERX 提供多线 NAT ，毕竟支持硬件 offload ， VyOS 提供基于 IP 的策略路由与负载均衡）
这时候，如果需要额外的虚拟化可以在 PC 平台上完成(毕竟新平台都有 VT-D ，而且内存便宜不少)
NAS 需求看情况直接使用阵列卡 /独立组建存储柜，避开性能瓶颈并提高可靠性（耗电应该差不多）

另：如果能接受老平台，淘宝有个 1150 平台的万兆神板可供考虑

@Showfom
带 BBU （当然也有电池）， CV 后缀是那个超级电容做后备的技术缩写
掉电以后以来电容的电量把缓存的数据写入闪存持久存储
价格是挺划算的，就是不知道是啥货源，看成色不像是拆机品

ZFS 貌似 SUN 当年是有单柜 PB 级的存储设备在卖了，不知道和现在开源的那个 ZFS 是不是一回事。

UPS 如果买在线式其实还有个问题是效率。。毕竟两头 90%效率最终只剩下 81%了。。。。
后背式在老化以后切换时间会变长，电源扛不住就停机了，就怕这事。

@Showfom
最近上了个不知道啥货源的 LSI 9286CV-8eCC ，算上线材 1300 。
价格感觉相比 ZFS 所需的多出来的的内存、处理器需求，还算可以接受。
除了没 ZFS 的块级校验特性，其他还好，能动态扩容这点很不错。

另： UPS 求推荐，寻找许久，在线式 UPS 似乎没有相对廉价的选择。

@Showfom
最近上了硬卡，发现有件事比软阵列好太多：方便（不用敲命令了）
所以看上去家用上硬卡也没啥问题

防御式开发“不应”用于此处。
代码问题就该老老实实抛出异常。

就像不应使用 try catch 来捕获因代码文件缺失而导致的异常，这样会隐藏问题的准确位置。

ESXI 不支持核显（如果有成功案例求教程）
E3C236D4M-4L 板子略显奇葩，但没问题
ZFS 请备好足量的内存
需要图形界面请自备 A 卡，并做好折腾的准备

最后提示： All in one 对于喜欢折腾的人来说不是一个好选择

@noli
总觉得我们俩不在一个频道上，这话题就此终止吧。

@noli
1 、只要 200 就意味着 API 可访问， 200 以外数值一律当成异常处理（例如程序错误会抛个 500 ）
2 、缓存可依据 HTTP 头信息判断，不仅仅是状态码
3|4 、重看一遍我的回复， 200+json 我认为很适合于 Web API ，啥时候我说不看场景强制用这种模式了？

@noli
1 、 API 监控报警只监控 200 以外的状态码即可判断 API 失效
2 、 API 的缓存从不应只依赖返回码
3 、 JSON 是一个很通用的实现，除嵌入式以外，暂时没想到哪个领域不具有解析 JSON 的能力。
（别忘了我坚持 200+JSON 的领域是 Web ，本来 Web 这种业务多变的地方就应该独立做一套 API ）
4 、一个非 200 响应的 API 给浏览器统一成 200 响应再送回去你确定这样做合适？

@noli 请教缺点多于优点的缺点是啥

@noli
我觉得已经没必要讨论下去了。
你这么说法完全就是为了反对而反对了。

@noli
理性点看待问题，话不要说绝。
在 Web 场景下保持 200+JSON 响应消息这么设计是很合理的选择。
不要为了反对而反对，除非你能给出更优解。

套用知乎句式 “抛开场景谈设计就是耍流氓”

@noli
其实我想说的情况是公司内部自签发证书在网关拦截请求进行监控的情况下 HTTPS 是不可靠的。

考虑到运维以及可能出现的各种网络问题引起的状态码异常（客户端劫持）
我是认为 Web 环境中不适宜用 HTTP 状态码来代表业务状态，软件的 API 倒是可以用这种形式来实现。
但是为了明确区分应用层故障还是网络异常， HTTP 状态码保持 200 在某些时候是更合适的选择。

@noli HTTPS 也可以劫持，别忽略例外情况

@noli
当你遇上一个没法更改的机房设备的时候你就不会这么说了。。
HTTP 状态码来表示资源状态那当然是很好的做法
但是当网络路径中存在一些奇葩的设备带有奇葩规则的时候这就不是一个合适的选择了

这也是我在上文中强调“外网”的原因。

看上去像是 多路接入+策略路由+分销 N 次的城中村宽带

@noli
考虑到项目的规模才应该使用更通用的实现，即便这个实现在某些时候看上去并不“优雅”
为了“优雅”而对问题视而不见，这不是一个合格的工程师应有的态度