@mengzhuo

1. Go crypto arm64 今年四月份才有补丁使用 AES 硬件指令，八月底随 Go 1.11 发布。

2. Go arm64 的短板在于 Go 编译器没有 auto vectorization 特性，非特殊优化的计算任务极大概率没有用到 SIMD 相关指令。

3. NEON FP 是非标准的 IEEE 浮点实现，可能会损失精度，包括 gcc aarch64 在内，启用 NEON 都是 opt in 行为。ARM 官方库 Ne10 并没有 Go 版本。

4. 特定处理器优化可参考 gcc 针对 ThunderX 的修正，调整寄存器使用和缓存对齐等等涉及硬件实现的参数，能够带来超过 10% 的性能影响。绝大多数 arm soc 都是在其商业寿命周期结束之后才获得开源软件支持的。

5. 好好说话。

@tempdban 主要是 arm 平台 IO 外设缺少统一的接口，IO 设备要么用不上，能用上的情况下 DPDK 软件支持还是到位的。

@mengzhuo 这里说的优化是从 go 编译到 arm 二进制的过程，相比 gcc/clang 的优化不到位，当然近一年来的进步很明显了，但是考虑到 arm 平台的多样性，有没有针对特定处理器的优化会导致结果差别很大。优化的重点是 SIMD 方面，arm 和 x86 在内存模型上有先天差异，缓存读取 x86 只要一条指令，而 arm 需要几条，所以针对 arm 特定架构利用 SIMD 的优势会成倍影响运行效率。

简单说，计算密集型的应用场景，在软件配套跟得上的情况下，用 arm 比 x86 要更合适，网络 DPDK 相关的也可以考虑，IO 密集型还是 x86 更好。

所谓的软件配套一方面是指 arm64 二进制源，这方面最近一两年进步非常大，不是大问题。重点在于 arm 架构是弱一致的内存模型，有指令集支持的计算效能非常高，基于 c 的编译代码优化也尚可，但依赖 jit 或者是优化尚不到位的 golang 等效率就很低，虚拟化涉及内存模型所以效率也很低。

现阶段 arm/x86 的主要区分并非指令集和效能，而是平台和生命周期。关于 arm/x86 的细节对比我会再开帖子详细说明。

@xud6

不是说三副本没有可能，我也觉得 ec 宣传成三副本不是很理智，只是当初普遍猜测可能三副本不存在才导致数据不能恢复。现在两份公告都出来，如果认为公告全部属实的话（我现在认为都是真的），假设最少的推测应该是仓库 II 硬盘有静默 bug，复制过去的时候发生了写入错误，切换指向导致新读取的数据有误，造成 VM IO 异常。

本身公有云的存储定价就已经比硬盘本身采购价便宜了，盈利模型是基于多年成本平摊和 IO 及带宽额外收费。行业里 aws 的税前利润率在 50% 左右，国内这些可能在 30% 附近，在这种情况下，三副本留给盈利的空间还是不少的，至于八个九的可靠性？我觉得这个价钱蛮难做的。



关于你提到的校验的问题：

第一层是硬盘硬件层面的，逻辑 512K 扇区实际是 520K，多出来 8K 用作硬件校验。但这次事故中因为 bug 导致失效。

正常情况下，如果读取的数据与校验信息不匹配，那硬盘应该向操作系统反馈读取失败，有 bug 的情况下即使校验不通过，也被当作了正常数据。

第二层是存储后端层面的，以前 ceph 底层存储是建立在某种文件系统上的，这几年 bluestore 已经成熟，可以将硬盘本身作为块存储对待了，少了一层文件系统。由于替代了文件系统的作用，bluestore 默认是有写入校验信息的。但用户可以通过手工设定参数，在配置存储池的时候取消对应的校验。我说的禁用校验是说的这一层。

在这一层上 ceph 模拟了一个 fsck 行为，scrub 就是 fsck，可以是 metadata 层面的也可以是 object 层面的。我从来没有尝试过禁用校验，但极大概率禁用之后 fsck 将无法运作。

假如第二层的校验没有被禁用，那么静默错误是能够被定时 scrub 检测到的。

但为什么运维人员会自信地认为校验可以关闭，猜测是在迁移到 bluestore 之前，下面还有一层文件系统，出错会被发现。但由于 bluestore 替代了文件系统的作用，这个时候再关闭校验就不明智了。这里关闭校验确实可以加快迁移速度，符合公告中的说法。

第三层是对象或者说文件层面的了，这里可以简化为 VM 镜像文件。

更高层就是 VM 内虚拟硬盘上的文件系统了，比如 ext4 等等。

这里每一层的校验信息都是由当前一层处理的，异常就向更高一层反馈错误，并抛弃数据，正常的情况下，返回的是不包含当前层校验信息的纯数据。所以不存在什么校验信息已经存在，不需要再计算一次。默认情况下，仓库 II 读取到文件准备写入的时候，传递给 osd 的数据，会被 bluestore (libRADOS) 加上当前层的 crc32c 校验写入，osd 所在主机的 cpu 负责 crc32c 的重新计算，这个校验行为对于上层是透明的。

如果复盘事故，说发现错误的是腾讯就没意思了，腾讯的虚拟机三分钟就检测到了 VM 的异常，那是因为 VM 的 IO 请求由于 metadata 出错映射到了不该读写的位置上因而报错，真正感知到或者说校验层面上没通过是 VM 虚拟硬盘的文件系统发现的。此时 ceph 还认为 VM 镜像的块存储是正常的呢。

如果仓库 II 是按照合理的方式构建的（比如三副本所在硬盘来自三个不同批次），目前的推理也不需要更多假设。镜像迁移的过程中，复制读取出来的数据是正常的，但写入的第一个主副本恰好发生在了存在静默错误的硬盘上。按照 ceph 的架构，客户端只负责一次写入，由一个主副本复制出三个的过程是 ceph osd 内部完成的，一份错误扩散到了三份。这样就能解释为什么三副本会失效了。



腾讯这次事故给我的启示是，bit 级的错误比如 BitRot/SilentCorrupt 已经是个很严峻的问题了，目前硬盘自身的 BER 大概是 10^14~10^15 上下，差不多 12TB 的水平，这个数据量在今天不过是一块硬盘而已。虽然常用指标叫做 URE (Unrecoverable Read Error)，但实际错误的发生是写入的过程，或者是写入后发生了 bit 翻转等等，原因是错误只有被读取到的时候才会被发现。

这一次的问题就出在写入出错上，但即使硬盘没有问题，还是有可能因为宇宙射线等等原因造成写入错误，这才是问题的关键。但目前看腾讯无论是设计还是运维，都没有对这个问题有足够的重视。

至于八个九的可靠性，那就更不用说了，都是建立在软件万无一失，从来不会发生 BitRot/SilentCorrupt 这种事的基础上的，模型是有问题的，不然出了事情总不能都怨用户是那宇宙唯一吧。目前来说，大概真实的六个九就足够了，达到这个水平的意思是该去别的地方做工作了，比如完善运维机制，修订空间释放策略等等。

@songxinyingpg

主要的问题还是公告的内容不够细致，很难做完整的判断。


先说发生静默错误的硬盘在哪里的问题。

从公告来看，仓库迁移完成三分钟内即报错，说明 VM 一直在线且有 IO 行为。如果主副本是在有静默错误的硬盘上，为什么迁移之前没有发生错误呢？假如主副本出错，理论上 VM 早就有感知了。

我觉得理论上有一种可能，就是（在基于 ceph 方案的前提下）腾讯基于 libRADOS 重写了 RBD 的实现，启用了并行读取的功能。客户端发出读取请求的时候，同时向三个 osd 发送请求，非主副本每次响应都比主副本更快，使得 VM 可以从两个正常副本获得正确数据，然后 ceph 内部再将非主副本的数据同步到主副本上。在执行仓库迁移的时候，又单独从主副本复制了错误的数据。

如果出错硬盘在扩容后的仓库中，这个问题就不需要什么假设了。复制来源是正常的，写入的时候已经出错，再次读取的时候发现错误。



关于三副本的问题，物理三副本完全说得过去。考虑有可能是逻辑三副本的实现是因为最初没有公布复盘，只说硬盘固件 bug，因而对于三副本的说法产生了怀疑。

另外 EC 在 RBD 这种应用环境，如果 cpu 不是瓶颈的话，相对副本池的性能还要好一点。但是要牺牲一点延迟，从实际应用来看，VM 到 RGW 的延迟是大头，ceph 延迟不是很关键。副本池是不支持并行读取的，高 io 队列很影响性能。用 EC 池不一定单纯为了省成本。



@mhycy

这里一并回复关于 scrubbing 的问题。

Scrub 有两种，light/deep，前者只校验 metadata，后者还校验文件本身。Scrubbing 的过程就是延迟的写入验证，把硬盘上的文件读一遍，验证一下，以便提前发现问题。

因为它不仅占用 IO 还要消耗 cpu 资源，所以配置的参数重点在多长时间进行一次，什么时间进行，一次进行允许操作多少数据块。可以理解成某种计划任务。

关闭这个校验对仓库迁移这个时间段来说一点意义都没有。真正有意义的就是我之前提到的，写入时禁用 crc32c 校验。

@akira

我前面解释过，如果是 ceph 方案，逻辑上的满了和物理上满了是两回事。迁移完成后多久删除源数据是个策略问题，这里确实不妥。

举个例子，EC (7+2) 编码 12 盘方案，可以容忍两盘失效。实际上安全存储空间只占存储池的 10/12，这是因为一旦发生 2 盘损坏的情形，ceph 会将重建的部分写入剩下的 10 盘。另外由于分布式存储 deterministic 的分配算法，总共 9 分块写入 12 块硬盘中，各个硬盘的写入量可能并不均衡。从我的经验来看，要么根据一个警戒标准提前进行扩容，要么根据实际的增长速率来预期扩容。

第二个问题是，手工操作是不是意味着运维水平低？

从运维的角度上说，区别是不是手工仅仅从一两行描述是看不出来的。这个例子里，扩容是一个引入新设施的过程，从具体的硬件搭配到软件参数的调试都离不开人类决策，敢于线上迁移（相对离线迁移）很大程度上说明对于运维的水平有自信。（如果一切真如公告所说的话）

我的看法是取决于这样的迁移行为是不是频发，如果是，有没有固定的工作流程，这样的工作流程是否能纳入日常审计范围，异常处置又是什么模式。理想情况，这个运维行为可以无人值守双向可逆，但事实情况能够人工介入回滚已经是非常好了。

对于整个事件，如果要我表个态，我会认为腾讯的软件系统存在设计上的不足，没有对 BitRot/SilentCorruption 做应对。但运维水平方面不好判断，一方面能看到自信到爆表的线上迁移行为，另一方面又是激进到难以置信的回收策略……我觉得更大的可能是公告不可信吧。

@mhycy

我的观点基础还是一样的，不存在物理上的三副本，只存在逻辑上的三副本，所以关于“哪一个副本失效”的描述都是不准确的。

读取时逻辑上存在的三副本或者说 (X+2) 块数据是正常的，这是因为从 VM 三分钟就能发现 IO 异常来看，VM 还是在线且正常工作的。假如仓库 I 的数据已经异常了，那么早在迁移之前就会出现问题。

因为没有人能保证，存储介质中的数据在读取时还是正确的，所以验证行为都是在读取时发生的，写入的时候是盲目信任的。

由仓库 I 向仓库 II 的迁移，读取过程必然伴随校验行为，也就是说，仓库 II 在写入之前已经确认了，文件系统级别上的数据是正确的。之后切换仓库指向，发生 IO 错误，说明仓库 II 的数据是异常的。那么极大概率错误是发生在向仓库 II 的写入过程中的。

我猜测仓库 II 的硬盘存在静默错误，错误表现为读取的时候，硬盘固件对读取到的内容做 CRC 校验，如果不一致应当丢弃并向操作系统报错，但固件 bug 使得所有校验都能通过，操作系统按照对待正确数据的方法进行处理，因而导致 IO 异常。

实际写入错误可能非常少，但是按照上一次公告的内容，错误出在了文件系统 metadata 的部分，因而导致数据写乱了。

至于公告怎么写的，那是另外一回事，当然我是就个人经验做出的推断，可能和事实不符。



Ceph 的架构是这样的：VM<--->RADOS GW<--->Storage，VM 发出的 IO 请求要先经过 GW，GW 可以在 Storage 切换的过程中推迟对 IO 请求的处理，也可以临时返回失败等待 VM 下一次重试。

迁移的过程是，GW 暂停对相关 BD IO 的处理，确认镜像的状态为一致，切换指向，恢复 IO 处理。对于 VM 来说，除了短暂的 IO 延迟上升以外，没有其他影响。

确认镜像状态一致是个逻辑层面的行为，写入了就认为是正确的。如果给出足够的时间，等待一次完整的 scrubbing （通过读取来验证数据状态）完成，还是有机会发现差异的。

三分钟删除源这是策略层面的问题，可能是过于自信了吧。

云存储行业相关，我就经验做下推测，不代表我在腾讯这次事故上的立场。



首先是一些基础判断：

1. 所谓”三副本“除了高 iops 用途的，都不是三份完全副本，不管是 aws 也好还是国内厂商也好，都没有这个可能。三分完全副本会导致基础硬盘成本变成三倍。目前云服务的定价机制是靠低存储价格吸引用户，盈利点在针对读写行为的收费上，用得越多费用越高。如果把云存储费用和硬盘成本做对比，收费较高的 aws 大概是 1.5 倍基准，所以理论上没有可能这样设计。

2. 逻辑上的三副本，字面意义上会有暗示，损失两份副本还可以恢复。实际的存储模式可能是 (X+2) 的 EC 编码，意思是原始文件分 (X+2) 份，其中 X 份数据，2 份校验信息，分散写入到 (X+2) 份介质当中，可以容忍同时有 2 份介质损坏还可以重建。存储效率上 X=7 的时候，额外存储占用约为 30%，理论上已经有盈利可能了。当然实际上根据厂商的设计，(9+2)/(17+3) 都很常见，取决于对存储效率和安全系数的平衡。厂家宣称的可靠性 (Reliability) 就是由此通过某种模型推导出来的。



从腾讯的宣传来看，云存储用的是 SDS (Software defined storage) 方案。在这种方案下，具体的硬件不重要，因为 SDS 本身要解决的问题就是摆脱对特定硬件的依赖。根据其用途和支持的特性，我猜测它是类似 ceph 的分布式存储方案。分布式存储和传统（包括 zfs ）在内，有着本质的不同，不能拿来类比或者套用理解。

我这里假定腾讯使用的是类 ceph 方案，仅仅是因为 ceph 恰好可以支持故障复盘中的操作行为，也有可能是自研方案，后面会以 ceph 做例子来解释。



Ceph 方案用作云硬盘存储后端，是靠 RADOS 协议，在原生对象存储之上，抽象出块存储支持的。这种情况下对存储池做在线扩容迁移，有两种方案，一种是标准的 RBD 镜像操作，另一种是将目标存储池作为原存储池的缓存层，做对象级别的复制。考虑到复盘描述中运维人员可以选择部分云硬盘作为迁移对象而不是全部复制迁移，缓存层迁移又不需要回收过程，我倾向于实际的操作是第一种也就是 RBD 镜像的方式。

有关“加速迁移”的问题，我认为确实有可能存在 cpu 瓶颈。原理上，客户端（数据读取端，ceph client 的含义和一般意义上的客户端不同）独立连接各个存储介质，读取到分块后本地重组校验，这个过程是消耗 cpu 的。所谓瓶颈比较大的原因可能在于目标存储池也在提供服务，为避免复制过程中的高 cpu 占用和 IO 占用对在线系统造成冲击，人为限制的结果。

源数据被目标存储池读出的过程是不可能被”加速“的，任何一个存储系统都会把校验做在读取时，基本的逻辑是系统可以读不出数据，但读出的数据一定要保证是正确的。反过来，写入过程是有可能被”加速“的。这是因为在写入之后立即读取做写入验证的意义不大，没有人能保证下次读取的时候这些数据还是正确的。但这一点正在逐渐改变，随着存储量数量级的增长，曾经被认为小概率的 BitRot/SilentCorruption 成了常规事件，正在越来越多地影响存储系统。（注：这里的校验是文件系统级别的。）

对于 ceph 来说，写入目标存储池的”加速“手段，只有不写入校验信息一个手段，不仅减少了校验运算，还省去了部分空间占用。以目前 BlueStore 做存储后端（可以理解为 raw 文件系统），可以由 bluestore_csum_type 来控制是否同时写入 checksum 校验信息，可选参数有 none/crc32c/crc32c_16/crc32c_8/xxhash32/xxhash64，默认 crc32c。如果要关闭数据校验，就是将该参数由 crc32c 修改为 none。（注：这里的校验是 raw 级别的。）

事故的成因很清楚了：硬盘自身的校验由于 bug 固件失效，raw 存储级别的校验又被人为禁用了，写入的过程因为某些意外（宇宙射线等等）导致写入错误，但由于缺少强制的写入验证，待到读取时才从文件系统级别的校验发现错误，为时已晚。



我个人认为，问题最严重的地方不在于取消校验导致此次事故，而是整个扩容后的目标存储池都是没有写入校验信息的（按推理来说扩容前的存储池设置也是一样没有校验的），潜在受影响的其实是所有的存储数据，虽然出事故的只有小部分。换句话说，腾讯的存储方案可能自设计之初就没有对 BitRot/SilentCorruption 做针对性应对。



PS
我不是很赞同关于存储超售的说法，即使有超售行为，通常也是建立在对客户存储占用率建模基础之上的，只要配合适当的迁移方案，不是什么大问题。再有 ceph 的分布式设计会有一些不灵活的地方，一方面要预留足够的空余存储来保证存储节点意外失效后的自修复，另一方面随着硬件的更替，原有的设计参数比如 pg 等等可能不适合新的存储设计了，需要迁移或者重新平衡来更新节点的存储布局。

至于疑问三，在线迁移结束之前，io 还是指向仓库 I 的。指向仓库 II 之后三分钟就发现异常了。

回答楼主的提问，目前备份 APFS 的方式依旧是 Time Machine 到 HFS+ 设备上。

关于 TM 不支持 APFS 的原因，我认为小部分是技术问题，大概率是决策问题。

APFS 的核心改变在于 Copy on Write 的写入模式，单一副本多重增量。对于人类用户而言的备份，更侧重于多重副本的意义，这和 CoW 类文件系统的快照概念是相冲突的。所谓决策上的问题，综合安全性、成本和易用性，CoW 类文件系统是否适合作为备份用途。存储设备本身的特性也可能是考量因素，比如机械硬盘适合多重副本，非易失性闪存适合快照等等。

技术上的问题在于，CoW 快照备份到非 CoW 设备上，需要将多重增量还原成多份不同的副本； CoW 快照在不同设备之间备份和恢复，需要文件系统本身支持（ ZFS 的对应功能叫 send/recv ）。目前 APFS 只是以内部 API 的方式来工作，可能官方认为对应的功能还不够完善。

长远来看，技术问题可能不是问题，但策略问题更可能影响现有 TM 类软硬件的发展。

@paolongtao
你说的这一点我在别处提到过，只是这里着重谈指纹识别所以仅仅用交互不足略过了。

“面部识别还是有先天缺陷的，用作认证毫无压力，但用作授权就有交互逻辑的问题。原因在于机器无法区分 attention/intention，指纹授权不存在这个问题，意图是人决定的，面部识别大概需要增加一个步骤，比如做出表情或者点头动作，或者手指点选确认，略微不够自然。”

楼主的提问还是比较笼统的，具体方案选型还要看业务类型和长远发展规划。稍微有一点要注意的是，随着公司的发展，公有和私有方案之间的转换几乎等价于调整技术路线，对整个公司上下都是很大的考验。

我最近一两年的工作重心基本在无人值守运维的层面，楼上各种观点我大致都可以看得出出发点，不同的经验和视角带来不同的结论是很正常的，我也稍微分享下我的理解好了。




目前的虚拟化技术从原理上来说还是存在缺陷的，CPU/MEM 的虚拟化非常成熟，但 IO/Network 虚拟化效率一直不高。尽管 x86 领域 Intel 做了大量努力，但无论是公有还是私有方案，想用上最新技术都面临成本问题，新技术的效果如何还有待实践检验。

对于公有云来说，高 IOPS 的方案永远是售价最贵的。通常来说，CPU/Network 加钱都好买，但高 IOPS 方案需要云服务商采用独立的实现，并不完全是共享转独享就能解决的。对于客户来说，对 IOPS 性能的需求很可能会左右公有还是私有方案的选择。

再稍微解释一下为什么高 IOPS 非常重要。一般意义上评价云服务稳定性（ availability ）的指标是 uptime/downtime，99.9% SLA 一个月只允许 40 分钟的停机。但现在这个指标逐渐被更有意义的 RTO （ Recovery Time Objective ）所代替了，uptime SLA 只是个统计平均值，而一旦出现故障的话，几乎没有可能在 40 分钟内恢复。即使一流的服务商，99.9% uptime 对应的 RTO 指标通常要降低一个数量级，而且这个指标通常与数据量正相关。

以云服务为依托的灾难恢复，即使通过高带宽内网恢复，也会受限于 IOPS 性能，毕竟数据备份绝大多数情况下是加密存储，传输需要时间，解密又需要时间，就目前国内的服务水平来说，想用高 IOPS 存储节点做恢复，然后挂在到低 IOPS 生产主机上也是不现实的。

这里还有一个衍生问题，就是业务上能够容忍多大程度的数据损失，如果 RPO （ Recovery Point Objective ）是 8 小时，那就意味着每 8 个小时就要做一次备份。要求越高，对于存储系统和网络带宽的需求就越高。




关于成本，创业公司老板理解的投资意义上的成本、项目经理预算控制意义上的成本是差别很大的。

公司意义上采购的硬件会算作固定资产，成本核算的时候考虑的是折旧。通常服务器类硬件前三年会加速贬值，之后趋于稳定。采购二手硬件很多时候是降低成本的有效手段，而且考虑到长远的融资估值等等规划，私有方案并非不可接受。

值得一提的是，服务器硬件淘汰的高峰大概在第五、六年。小部分原因是老旧硬件的技术支持和特性落后了，大部分原因是老硬件的能效比和性能密度过低，在满足情况下，需要机柜数量增加，加上电能开支经济上不如换新硬件了。某些 IDC 对于托管设备的功率消耗限制比较严，采购二手设备自建服务器需要注意。通常购买三年左右的硬件性价比比较高。

长期运维的成本更多地取决于规模。我个人不是很赞同超售是公有云主要利润来源的观点，就我个人经验来说，公有云的规模给了云服务商足够的采购议价权，所以才能以相对低廉的价格提供入门级的服务。至于说服务质量差，大概是因为这个行业的门槛还是够高，竞争不激烈的结果，摆烂都有人用，哪有动力去提高。

如果仅仅考虑前期投入加后期运营预算的话，也许云服务稍微有那么一些成本优势。但现在国内的现实是，带宽成本高昂，使得云服务商在定价的时候考虑的是更高效的带宽分配，各种虚拟主机的方案很少有合理的搭配，这才给了二手服务器硬件足够的生存空间。

最后还有一个常常被忽略的成本，那就是风险成本。有很大一部分私有方案选型的理由是出于风险考量的，包括但不限于数据泄露、服务降级，甚至是过度依赖丧失议价权等等。



关于人力，现在市场上几乎招不到靠谱的运维，高效的运维团队往往是开发等等的内部转型。所以总体来说，指望招人来解决运维问题不是很现实，初创团队这一点尤为明显。不过这也不代表云服务就是唯一出路。

在谈及云服务不需要运维的时候，往往都会忽略一点，就是运行在云服务上的业务系统通常在设计之初就做了针对云服务的优化，比如采用微服务架构、API 分流和数据库切分等等。如果创业公司在初期选型的时候就决定私有方案，那么主要的开发任务就变成了自动部署、连续集成之类的。单纯说维护设备硬件，技术上不是难度很大的事情，维护不好硬件设备的基础系统，云服务的动态管理也肯定是一团糟。

即使是从初始就使用云服务，也会面临更换运营商的可能。软件配置是否能迁移，网络拓扑如何修改，这些都是要考虑的运维问题。而自建方案也要考虑性能瓶颈，架构层面的优化同样分不开。当然我相信能够胜任一种方案的开发团队，换一种方案也能完成得很好。前面说两种方案的迁移成本高，主要是不同的技术路线带来的技术积累和人才培养是不同的，转换总归是种挑战。




最后随便吐槽一句，在追求公有或者私有方案高可用性之前，还是先把自身技术实力练过关吧，不然瓶颈还是在自身，那真是选啥都一样了。

@fool 这个事情实践大于理论，我写的东西主要是理论。如果你要考别人，可以分两个层次，一个是基础层面的，基本的版本控制工作流程，二是经验方面的，大规模部署技术。

个人层面可以从常见问题开始，比如是否遇到过开发机正常，测试通过然而上线出错的情况，进而如何排查，如何改进降低出错可能等等。

技术层面我也不是专家，毕竟工作在一线有大规模运维经验的很少。可以侧重问控制侧重点是什么，策略流程中自动化的程度等等。

我就是二楼那副，镜腿还要更细一点。相比重量，重心位置也许更重要，比如图片里镜腿后方下沉的配重设计，主要是为了降低鼻梁处的压力。

镜片方面早两年不推荐 1.74 的，除非度数太高，原因是色散问题比较大，镀膜涂层的可选比较少，这两年是不是有进步了不清楚。

镜片尺寸主要是看是否美观，小镜片并不能减轻太多重量，日常使用需要经常转头而不是动眼球。

我之前也遇到过类似的问题，第二块 4k 比第一块卡，不过当时的系统版本低，第二块 4k 现在换掉了，不清楚现在是什么情况。

能排查的地方有几个，一是接显示器的 dp 口共享带宽的另一个口不要接外设，二是浏览器换 chrome 试试，而 chrome 硬件加速一直有问题，我记得 youtube 高码率的视频普遍改 vp9 了， chrome 并不能正常播放，要在高级选项里禁用硬件加速。

这就是骗子，做这种卡的公司，都骗不下去了。

有个基辛格做媒的笑话，虽然是编撰的，说的都是同一个意思。

先吹嘘说我的卡可以支持所有结算渠道，这样骗来用户的大量预订；然后拿着用户量跟投资人说，我很有潜力，赶紧投资我；拿到投资之后，再去跟 visa 谈，你看 mastercard/amex 都同意了，你们还不快点加入。

结果 visa 根本不理它……