大型系统的运维要从哪些方面抓起——从被动到主动

一个大型的互联网系统，意味着大用户量、业务模块多、服务器多、各类资源占用多，在拿到一个大型的互联网应用，运维保障工做应该从哪些方面抓起呢？

首先仍是先看运维的目标，追求更高的SLA、更低的成本。全部事情都是以这个目标为出发点，SLA指更高的服务质量，落实到数据上就是线上服务的可用性和性能，可用性是3个9的时候能不能达到4个9？能不能持续保持4个9？平均响应时间是100ms的时候能不能优化到80ms？更低的成本指的是在一样的SLA下，能不能用更少的服务器、更精简的架构跑起来？全部的制度和自动化工具，都是为完成这一目标。

再看SLA和成本，二者并非独立的，通常而言高SLA意味着高成本，例如用10台服务器跑的服务改用100台服务器跑，服务性能和质量的SLA确定是有提高的，因此这两个指标实际上是一个对立与统一的平衡，两个之间此消彼长，共同进步。当SLA和成本产生冲突时，为了服务的稳定性，咱们通常的作法也是先稳住服务质量，再考虑优化成本，也能够说用成本先稳定住质量，再慢慢找出用这么多服务器、这么多资源的缘由，毕竟若是服务质量没有了、用户流失了，一切都是零。

更高的SLA其实意味着更少的线上故障，若是咱们以此为出发点去梳理运维的工做的全貌，其实要抓的工做阶段就变成了故障前、故障中、故障后，咱们要尽可能加大故障前的工做投入，减小流入故障中的问题数量，一旦流入故障中，咱们要想办法快速止损，止损完在故障后作好故障复盘，造成改进措施避免同类问题再次发生，继而流转到故障前，循环往复.........为了更形象的理解，画了一张图来展示。

上图将运维的工做从故障生的角度分红了8大块，每一块可能对应了不少个系统和制度做为支撑，所有造成了整个运维服务体系，咱们平常作的工具和制度就是为了每一个业务环节执行的更高效，PS 对于大型系统运维的一个关键在于各类标准化，标准化意味着批量操做意味着整齐划一，如今拆开了说一下这8块工做。

一、故障前—目标：减小问题流入“故障中”

①抓-变动

故障不是平白无故的就生发了，不少发生在于变化，变化当中很大的一个又是迭代上线，从每一年故障的历史数据看，有很大一部分故障都是因为上线变动形成的，因此要严管变动，控制好质量后再上线。

管理变动主要是控制线上的“马路杀手”，要作好单元测试、集成测试、线上灰度，而后再全量上线，保障万无一失，从成本的角度看，上线后再回滚也是成本最大的一种方式，影响了用户，而后还要从新返工。

有些变动类故障不是上线后立刻能发现的，好比java程序的full gc，可能上线一天后才能发生，因此这个时候要一些制度做为辅助，好比说重大节日前几天就不容许上线了，下班时间要找老板审批后走紧急上线等等，加大非正常时间上线的变动成本，让开发和运维对线上服务慢慢培养起敬畏之心。

②抓-容量

容量的管理关乎到质量和成本，不少时候对于容量是模糊和缺失的，具体表现就是发生了容量故障、看到了cpu和内存报警了才想到扩容，公司要优化成本抓机器使用达标率才知道缩容，基本是被动的，并且没有量化数据。没有量化的容量管理就像中国厨师作饭一下，根据经验多加点盐、少加点醋，这个多和少凭的是感受，基本是不可主动管理的，对某我的的经验依赖性很大。

再提成本，容量的管理对成本是相当重要的，有了容量数据，再结合目前的用户就知道目前的服务器数量合理不合理，有多少浪费的，又或是须要扩容了，有了容量数据也能够暴露不少性能问题，好比一台32核128G的机器才跑10个QPS，这显然是不合理和须要重点优化的。

根据实际经验，容量的指标必定要用业务指标不要用机器指标，举个例子，不少时候若是代码质量差，好比前面说的10QPS，机器的CPU、内存等跑的反而挺高的，这个时候应该扩容么？业务指标通常指像QPS、在线用户数、长连接数量等这些，理论状况下，先有了不一样配置的单机容量数据，再计算出集群的容量，继而算出模块的容量，再继而算出整个产品的容量，在作容量测量用的最多的工具是压测和全链路压测，这个根据不一样的情景使用。

对于容量数据首先保证有，再争取愈来愈准，而后根据代码、架构、机型改动状况动态更新。

③抓-灾备

灾备和成本也是相互矛盾的一对，作多机房灾备成本必定高，由于机房之间要保有相互承载用户的余量，不作多机房灾备成本确定是要低的，但若是某个机房垮了没法服务，业务就无处可切，就真的垮了，因此咱们要根据业务的级别作合理的灾备。

灾备意味着作冗余，合理的灾备能够保障在故障出现时，快速进行业务切换，保障用户的可用性。通常而言灾备分为热备和冷备，冷备是指准备好资源平时空放，只有故障时才用一下，形成很大的资源浪费，因此通常能作热备的就不作冷备。

作热备的方法有不少，如今不少业务都是面向服务的，最多见的热备方案其一是搭载负载均衡，经过心跳健康检查服务自动调度，其二若是是移动、联通、电信某条链路出现故障就经过域名解析进行切换。

最典型的冷备方案就是keepalived，经过vip漂移的方式对某个服务进行冷备，原理就不说了。

灾备作好了，能够大大下降故障出现时的业务压力，先把服务切了再查故障，心态要轻松不少，加之若是可以自动切换（好像能够叫故障自愈）那就更好了。

④抓-巡检

巡检的意义在于发现潜在的问题，将还没有造成故障的问题提早暴露，提早解决。在方法上，能够人工巡检也能够经过系统实现，巡检完后发送巡检报告，将一些核心指标的变化状况根据业务的属性进行标记通知。

不管是手动仍是系统巡检，都要对每一个模块的核心指标进行梳理，造成每一个模块的核心指标的鸟瞰screen，一来天天到办公室首先要巡检一下业务状况，二来在遇到故障的时候要迅速看一下各个指标的变化作故障定位。

各模块的巡检screen通常要包括QPS、错误、时延、外部依赖错误、机器指标这几个大项，便于一眼发现问题所在，快速找到根因，定位故障影响范围。

二、故障中—目标：快速发现问题、快速止损

若是前面的工做都保质保量的作了，故障依然出现，那就考虑怎么应对处理吧，故障的处理关键有3个环节。

⑤抓-告警

不说告警没配等特殊状况，告警应该是故障的第一事件，当oncall人员收到告警，判断影响后，分发给相应的同窗处理，直到故障恢复。

因此在告警必定要管理好，告警要根据事件的影响程度分级，告警短信和邮件里尽量携带更多的判断信息，作的好的甚至能够作一下故障参考预判。

告警的建设上必定要围绕3个点准、少、快，准是告警的信息准，少是告警的数量少都是收敛后的有效告警，快指的是告警的实效性高速度快。

⑥抓-定位

oncall同窗收到告警简单的判断后，会把告警分发给处理人，这个时候就到了故障定位环节。

故障定位依赖于对业务架构细致的了解、依赖于线上的经验，通常会借助监控进行排查，这时候在巡检阶段建的核心指标screen就派上用场了，经过screen和核心指标基本能够作个预判，而后再经过日志分析或登陆服务器查看详细日志进行根因排障。

定位也是有轻重缓急的，首先要找到故障模块和故障范围，找到后先根据预案将业务切掉再去排查缘由，减小线上用户的影响。

⑦抓-预案

预案是指在定位到故障模块和故障范围后为了保障业务的稳定，及时止损所进行的操做，

为了故障发生后尽快止损减小影响，在平时要考虑好各类故障发生的肯能性，并作好预案是很是重要的，预案也分为容灾预案和降级预案，容灾预案基本无损，降级预案可能会影响一些用户体验了，可是不影响主体功能，若是什么预案都没有只能生抗了。

三、故障后—目标：消灭同类故障

⑧故障管理

故障管理是整个故障的善后工做，追责任的部分除外，那他的意义就是防止同类故障再次发生。通常会以故障复盘会的方式约全部相关方进行全过程复盘，最后造成的文档叫“故障报告”，我认为里面最重要的两个内容一个是故障缘由（究竟是天灾仍是人祸？根因找到了没有），一个是后续的改进措施。

管理中有句话叫“再好的制度若是不执行等于没有“，在改进措施的执行上，不少好了伤疤忘了痛的作法家常便饭，改进措施改着改着就没了，形成了同类故障重复出现，这个过程当中必定要确保造成的改进措施保质保量的完成。