“变更三板斧”¶

在阿里体系内，很喜欢”三板斧”这类简短容易传递意图的概念。在内部运维体系中，有一个常提的概念是”变更三板斧”:

你若是问阿里的SRE能否做一个生产变更，对方首先就会用上述”三板斧”来评估你的变更方案。

道理虽然没有大错，不过，我觉得仔细思考起来，上述三点并不是一件容易的事情。甚至，很多时候，大家过于依赖简单化的概念，进而有些自我催眠，而没有真正从技术上去做到全面的评估、演练、优化、试错。

备注

可监控¶

监控的深度和广度完全是天差地别。从表面上来看，很多系统号称有监控，但其实这是简单而基础的主机负载、网络流量、磁盘IO这样粗放型的监控。不能说没有监控，但是远不是能够通过监控自动发现问题和依赖监控能够快速定位故障的程度。

现代化的监控平台，确实能够绘灵活组合，通过简单定制就能够用通用组件搭建出一个非常美观并且形象生动的”监控大盘”。但是，这些展示的数据真的能够帮助SRE找出故障源头而不需要苦苦翻阅日志，ssh登陆系统使用复杂的命令组合来判断么？

越是底层的基础平台，越是难以分析和定性:

网络流量 - 你一眼看不出在网络设备、链路中流动的电子数据到底是什么数据，即使通过复杂的SDN技术获取的监控数据也只是表达底层的丢包、拥塞以及非常基础的电气信号波动
磁盘IO - 最近的一次故障让我明白我们现有的监控手段如何简陋：你无法精确分析读写存储的来源、数据的损坏的原因。监控只反映出数据被异常删除，但是数据中心复杂的网络拓扑(负载均衡提供了强大的扩展能力但同时却屏蔽了客户端请求的真实情况)，数以百万计的存储读写增删改查，没有自动化分析的能力，仅仅依靠运维人员的经验去检查可能的入口日志定位故障，几乎是一种赌博。
计算异常 - 云计算面向的是完全不会依据合理方案来使用基础设施的客户，千差万别的应用和使用方法，会触发操作系统、硬件以及基础设施难以排查的抖动。这在定位故障、止血和彻底修复上，带来极大的挑战。因为云计算的基础设施难以监控和分析上层应用的部署和变化，很多基础监控是无法透彻反映实际的系统故障原因。

我在想，到底有什么方法能够改变基础设施的运维，而不是仅仅维持设备”正常”工作，不出现宕机就算维护结束。

网络设备是通道，数据存储是起始和终点，所以在网络设备和存储设备上，需要部署业务性的监控，要通过 “元数据” 分析出业务动向，并且通过自动分析来完成 “业务跟踪” ( Machine Learning Atlas )。

备注

说到监控，我想到的是第四公民中提到美国政府强大的监控：并非对每个数据进行完整扫描，而是通过对 “元数据” 的分析来掌握公民的活动。

说来容易做来难，我现在对监控和数据分析掌握较少，后续学习和实践过程再来总结…