一个大规模的互联网系统，意味着大量的用户，很多的业务模块，很多的服务器，很多的资源被占用。要想获得大规模的互联网应用，运维支撑工作应该从哪些方面入手？
首先看运维目标，以最快的效率追求更高的SLA和更低的成本。一切都是基于这个目标。SLA指的是更高的服务质量，数据是在线服务的可用性和性能。当可用性为三个9时，我们能否实现四个9？你能保留四个9吗？当平均响应时间为100ms时，能否优化到80ms？更低的成本意味着在相同的SLA下，您可以使用更少的服务器和更精简的体系结构运行吗？所有的系统和自动化工具都是为实现这一目标而设计的。
再看看SLA和成本，他们不是独立的。一般来说，高SLA意味着高成本。比如用10台服务器运行的服务切换到100台服务器，服务性能和质量的SLA肯定会提高，所以这两个指标实际上是对立统一的平衡，两个指标是互惠互利，共同进步的。当SLA与成本发生冲突时，为了稳定服务，我们一般的做法是先稳定服务质量，再考虑优化成本。也可以说，先用成本稳住质量，再慢慢找出使用这么多服务器和资源的原因。毕竟如果服务质量没了，用户流失了，一切都是零。
更高的SLA实际上意味着更少的在线故障。如果以此为出发点，梳理运维工作的全貌，其实需要把握的工作阶段会变成故障前、故障中、故障后。我们应该尽最大努力增加失败前的工作投入，减少流入失败的问题数量。一旦故障流入，就要想办法快速止损，并在故障形成后再进行故障恢复，形成改进措施，避免类似问题再次发生。然后，在失败之前，循环往复。当这个圆的旋转速度越来越慢，说明质量越来越好……………..
上图从故障角度将运维工作分为8大块。每个区块可能对应多个系统和系统作为支撑，它们共同构成了整个运维服务体系。我们每天做的工具和系统都是为了让每个业务环节更高效地执行。大型系统运维PS的关键在于各种标准化。标准化意味着批量操作意味着一致性。现在让我们分别谈谈这8个工作模块。
1.失败前-目标：减少问题流入“失败”
(1)抓——变
错误不会无缘无故发生。其中许多发生在变化中，其中之一是在线迭代。从每年的故障历史数据来看，很大一部分故障都是由在线变更引起的，所以上线前要严格控制变更，控制质量。
管理主要是控制线上的“马路杀手”。单元测试、集成测试、在线灰度都要做好，然后所有产品都要在线，确保万无一失。从成本上看，上线后回滚也是最贵的方式，影响用户后再返工。
有些变更失败上线后无法立即发现，比如java程序的全gc，可能要上线一天后才会发生，所以这次需要一些系统作为辅助，比如重大节日前几天上线，下班后得到老板批准后紧急上线等。从而增加非正常时间上线的变更成本，让开发运维逐渐培养对线上服务的敬畏。
把握能力
产能管理与质量、成本相关，产能往往模糊、缺失。具体表现为出现容量故障，看到cpu和内存报警，就想到扩容，公司只有优化成本，注重用机成功率，才知道容量减少，基本是被动的，没有量化数据。没有量化的产能管理就像中国厨师做饭。根据经验，多加盐少加醋。这或多或少是基于感觉，基本上是无法主动管理的。它高度依赖于so
再次，成本、产能管理对成本非常重要。有了容量数据，结合当前用户，就能知道当前服务器数量合理不合理，浪费了多少，或者需要扩容。有了容量数据，许多性能问题也会暴露出来。比如一台32核的128G机器只运行10 QPS，明显不合理，需要优化。
根据实践经验，容量指标必须是业务指标，而不是机器指标。比如代码质量差，比如前面提到的10QPS，机器的CPU和内存会运行得相当高。此时是否应该扩大容量？商业指标一般指QPS、在线用户数、长链接数等。理论上，我们先有单机不同配置的容量数据，然后计算集群的容量，再计算模块的容量，再计算整个产品的容量。最常用的容量测量工具是压力测试和全链路压力测试，根据不同的场景使用。
对于容量数据，首先保证可用，然后争取越来越准确，再根据代码、架构、模型的变化动态更新。
备灾
灾难恢复和成本也是矛盾的一对。多个机房的容灾成本一定要高，因为机房要留有共同用户的余量，不做多个机房的容灾成本一定要低。但是，如果一个机房崩溃，无法服务，业务就无处可砍，真的会崩溃，要根据业务水平进行合理的容灾。
灾难恢复意味着冗余，合理的灾难恢复可以在故障发生时确保快速的服务切换和用户可用性。一般来说，容灾分为热备用和冷备用。冷待机是指资源在平时随时可以放在一边，只有出现故障时才使用，造成资源的极大浪费。所以能做热备用的一般不做冷备用。
热备用的方法有很多。现在很多服务都是面向服务的。最常见的热备用方案之一是通过心跳健康检查服务进行负载平衡和自动调度。另一种是如果中国移动、中国联通和中国电信的一条链路出现故障，通过域名解析进行切换。
最经典的
型的冷备方案就是keepalived，通过vip漂移的方式对某个服务进行冷备，原理就不说了。
灾备做好了，可以大大降低故障出现时的业务压力，先把服务切了再查故障，心态要轻松很多，加之如果能够自动切换（好像可以叫故障自愈）那就更好了。
④抓-巡检
巡检的意义在于发现潜在的问题，将尚未形成故障的问题提前暴露，提前解决。在方法上，可以人工巡检也可以通过系统实现，巡检完后发送巡检报告，将一些核心指标的变化情况根据业务的属性进行标记通知。
无论是手动还是系统巡检，都要对每个模块的核心指标进行梳理，形成每个模块的核心指标的鸟瞰screen，一来每天到办公室首先要巡检一下业务情况，二来在遇到故障的时候要迅速看一下各个指标的变化做故障定位。
各模块的巡检screen一般要包括QPS、错误、时延、外部依赖错误、机器指标这几个大项，便于一眼发现问题所在，快速找到根因，定位故障影响范围。
2、故障中—目标：快速发现问题、快速止损
如果前面的工作都保质保量的做了，故障依然出现，那就考虑怎么应对处理吧，故障的处理关键有3个环节。
⑤抓-告警
不说告警没配等特殊情况，告警应该是故障的第一事件，当oncall人员收到告警，判断影响后，分发给相应的同学处理，直到故障恢复。
所以在告警一定要管理好，告警要根据事件的影响程度分级，告警短信和邮件里尽可能携带更多的判断信息，做的好的甚至可以做一下故障参考预判。
告警的建设上一定要围绕3个点准、少、快，准是告警的信息准，少是告警的数量少都是收敛后的有效告警，快指的是告警的实效性高速度快。
⑥抓-定位
oncall同学收到告警简单的判断后，会把告警分发给处理人，这个时候就到了故障定位环节。
故障定位依赖于对业务架构细致的了解、依赖于线上的经验，一般会借助监控进行排查，这时候在巡检阶段建的核心指标screen就派上用场了，通过screen和核心指标基本可以做个预判，然后再通过日志分析或登录服务器查看详细日志进行根因排障。
定位也是有轻重缓急的，首先要找到故障模块和故障范围，找到后先根据预案将业务切掉再去排查原因，减少线上用户的影响。
⑦抓-预案
预案是指在定位到故障模块和故障范围后为了保障业务的稳定，及时止损所进行的操作，
为了故障发生后尽快止损减少影响，在平时要考虑好各种故障发生的肯能性，并做好预案是非常重要的，预案也分为容灾预案和降级预案，容灾预案基本无损，降级预案可能会影响一些用户体验了，但是不影响主体功能，如果什么预案都没有只能生抗了。
3、故障后—目标：消灭同类故障
⑧故障管理
故障管理是整个故障的善后工作，追责任的部分除外，那他的意义就是防止同类故障再次发生。一般会以故障复盘会的方式约所有相关方进行全过程复盘，最后形成的文档叫“故障报告”，我认为里面最重要的两个内容一个是故障原因（到底是天灾还是人祸？根因找到了没有），一个是后续的改进措施。
管理中有句话叫“再好的制度如果不执行等于没有“，在改进措施的执行上，很多好了伤疤忘了痛的做法屡见不鲜，改进措施改着改着就没了，造成了同类故障重复出现，这个过程中一定要确保形成的改进措施保质保量的完成。