高效运维 CU技术社区
|转载自：高效运维 引子 扁鹊见蔡桓公是一个家喻户晓的故事，出自韩非子·喻老。看过故事，我们都会敬服名医扁鹊的高超医术。如果将这个故事场景放在运维背景下，故事又变成另一番景象，成为一个风险管理失败的故事： 一个工程师向公司汇报，系统存在风险，目前依赖这个点的业务还不多，应及时处理。公司不予理睬。过了段时间，工程师继续向公司汇报，依赖的业务越来越多，必须立刻解决风险，公司不置可否。 又过了段时间，工程师对同事说，大厦的基石存在问题，而楼越盖越高，一旦出现问题无法处理，不想背锅于是离职了，随后公司系统崩溃。 如果你担心某种情况发生，那么它就更有可能发生。 100% 只存在于理想世界里，现实世界永远都只能逼近而无法达到。按照墨菲定律，会出错的事总会出错。设备会坏，线路会断，人会糊涂会有盲区。运维的工作就是每天都在与这些即将出现的错误打交道。 保障系统可用性是运维的职责。故障出现时的快速处理固然提现工程师的专业水平，但是从业务角度来看，不论处理的多快，业务都已然受到影响。 所以只在故障的快速处理环节加强力量是无法达到企业赋予运维的目标的。 扁鹊故事续篇 我们再来看一则扁鹊的故事。 魏文王问名医扁鹊说：你们家兄弟三人，都精于医术，到底哪一位医术最好呢？ 扁鹊回答说：大哥最好，二哥次之，我最差。 我二哥治病，是治病于病情刚刚发作之时。一般人以为他只能治轻微的小病，所以他只在我们的村子里才小有名气。 而我治病，是治病于病情严重之时。一般人看见的都是我在经脉上穿针管来放血、在皮肤上敷药等大手术，所以他们以为我的医术最高明，因此名气响遍全国。 文王连连点头称道：你说得好极了。 上医治未病 在运维领域，事后控制不如事中控制，事中控制不如事前控制。控制的就是风险。故障处理就是事后控制，架构设计、流程设计就是事中控制，而在公司政策、原则层的控制才能达到事前控制。事后控制、事中控制、事前控制三者是不能相互替代的，否则就会走到另外的误区。 来看几个风险控制的案例 案例一：风险控制的维度和阶段 在高端存储的设计当中，会在设备当中保留一部分磁盘作为备盘。这些磁盘正常情况下是热备状态，不存储数据的。当系统出现坏盘时，设备能自动用热备盘替代坏盘。 这种设计就是从技术、架构层解决风险。因为如果更换不及时，会出现硬盘继续损坏，造成数据丢失。某机构在规划存储时，设置了7块热备盘，通过这种方式防止坏盘对业务的影响。这是在技术层进行风险控制。 但是这家机构由于运维流程松弛，坏盘无人处理，最终7块热备盘全部用尽，最后依然发生了严重业务中断。这个案例告诉我们的是，风险控制的各个维度和阶段是不能相互替代的。 案例二：有效的事前控制 IaaS公有云领域，复用比是一个很敏感的话题。企业需要权衡成本与收益，复用比是一个重要的指标。因此在IaaS公有云领域，超卖是一个比较常见的现象。 从运维角度，如果平台负载过高，在出现性能高峰时，客户的业务和调度就都会出现问题。在最终用户的视角就是服务器卡顿。这类故障不论从事中控制和事后控制都无法有效的解决。这需要在公司原则与政策层进行解决。 首都在线运营公有云伊始就在政策层定下了不超卖的原则，因此在多年的公有云运行中，基本不出性能不足的故障。这是进行的事前控制的案例。 案例三：风险控制也需要考虑隐性成本 企业在进行设备选型的时候，价格是一个重要的指标。但是如果唯价格论，会出现一个现象就是企业的设备厂商、型号种类繁多。 尽管兼容理念已经存在很多年，但是各家厂商的产品依然存在细微的兼容性问题。这类问题会非常隐蔽，当出现时工程师往往束手无策，厂商相互推脱，对业务运行造成严重影响。 但这个问题如果不能进行事前控制，也无法有效地解决。不仅如此，也会对技术人员的储备，设备维保，运维自动化等方面增加巨大的隐性成本。 总结 风险管理主要包括：风险识别，风险控制，风险应对三个部分。最难的部分是风险控制。 回到扁鹊见蔡桓公的故事，蔡桓公对于扁鹊的提议，桓侯的态度是：“寡人无疾，医之好治不病以为功。” 翻译成运维常听到的语言就是：小概率事件，事儿B等等。所以一家企业最高层对于运维的认识和理解，决定着这家公司能走多远。
文王再问：那么为什么你最出名呢？
扁鹊答说：
我大哥治病，是治病于病情发作之前。由于一般人不知道他事先能铲除病因，所以他的名气无法传出去，只有我们家里的人才知道。
