如何做好一个运维预案？

hunter_search

1、多机房运行情况下，如何做到快速引流？
     前端有负载均衡集群的情况下，调整负载均衡的配置比例即可【一般情况下，都会有的】， 或者说，模块在设计的时候，就要求能够提供这样的配置接口， 更改配置即可引流.（智能DNS的方案有一定时间延时，不能快速引流）
2、如何保障在突发流量下，业务的高可用？
     每个模块设计的时候增加过载保护，保证突发流量的情况业务能够正常使用,  
3、如何保障在业务出现故障后，快速响应处理？
     更改配置，服务降级【前提是模块支持这些配置】
4、对一个新的大促（大规模推广）活动，怎样预估流量才算合理？
     需要估算最大同时在线用户数，有2个比较重要的因数 ： 1.导入的用户总数   2.用户忍受等待请求的最长时间 , 可以计算出qps 流量也可以估算出来。
5、数据库方面，如何做应急预案（比如：数据库宕机了，怎么快速恢复处理，数据如何做到不丢失等）？
    数据库方面，需要做集群，一主多从， 一旦异常，迅速激活从库为主库, vip同时绑定到从库 【此处细节太多】

hunter_search

发重复了
。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。

chenxing2

1、多机房运行情况下，如何做到快速引流？

    做多机房的负载均衡及机房内部的负载均衡，对各个机房做轮询，故障转移、性能分配、弹性扩容
       
        出现问题时，可及时处理切换。

2、如何保障在突发流量下，业务的高可用？
     
   负载均衡的性能分配能最大化的利用硬件资源。但流量真的很大了，则必须做限流处理，以保证服务的正常。
   
   如：在吞吐量和响应时间之间找到一个平衡点，即最佳并发数，差不多是限流的阀值。
         

3、如何保障在业务出现故障后，快速响应处理？
   
        现在一些负载均衡都可提供故障切换的功能
        如varnish、lvs、haproxy等跟 keepalive或Corosync搭配使用，可实现故障快速切换
       
        从而打造一个高可用的系统

4、对一个新的大促（大规模推广）活动，怎样预估流量才算合理？
     
         一般要搞一个大促，只能根据以往的经验来推测，历次大促的并发量、PV等
         如果第一次搞，就根据最近一段时间的最高PV及并发量做推断。
         
         当然最好最好做防备，可以去其他云上租一个月期限的多个机器临时用
         

5、数据库方面，如何做应急预案（比如：数据库宕机了，怎么快速恢复处理，数据如何做到不丢失等）？

        现在数据都会做集群，根据实际业务情况，做多主、主备等数据集群，其中几台挂掉通常不会有太大问题。
        更何况现在数据库集群前再加一个缓存的集群，DB要挂掉就更难了，除非机器挂了。

ge_johnny

大概10年前，在一家500强的咨询公司做data center的管理，当时公司正在通过BS7799认证，该标准现在已经被ISO吸纳，叫ISO27001.在准备该认证的时候，有类似楼主要求的流程，叫BCP - Business Continuity Plan，即业务持续性计划。该计划要考虑的维度同楼主要求的不一样，但如果满足该计划的要求则可以满足楼主的所有要求，而且考虑的要比要求的5方面多，牵涉的部门也不仅仅是内部的IT。

由于公司的主要业务是为银行金融保险等各行业的TOP公司做外包项目，所以当时公司的BCP要求要考虑的情况是在以下三种情况发生后，公司的业务中断到恢复的时间（甚至24*7的不中断服务）是否满足SLA（服务级别合同）的要求。客户敢不敢把新项目拿到我们公司实施，各个相关部门需要证明我们对任何情况都有所准备，所以该计划涵盖无死角是能不能争取到客户的一个关键，也是项目能够顺利实施直至按时交付使用的重要保证之一。

1. Building Outage：公司所在的几个大楼完全不可用，如何保证业务持续性？用什么办法能够保证有最小的人力和资源，最快在多长时间恢复业务？基于此设想设计相关流程并周期性的演练；
2. City Outage：在城市不可用的情况下，满足1的要求；
3.Country Outage：整个国家陷入混乱，如何处理？

整个计划是由公司的安全部门牵头设计实施的，由于需要各个部门协调准备，该部门直接向公司的大老板负责以保证各部门配合。
最终该计划涉及资源太多，并且根据我们能拿到的项目的需求，我们也只是勉强达到了City Outage的要求。

这个计划看起来很大，让人感觉有点无从下手，但仔细分析，抽丝剥茧，却也不是无计可从。简单从人力物力两方面简单介绍一下，做个参考。

人力：

1. 谁来判断是否达到以上几个级别的outage？对于building outage，主要是IT部门的负责人和内勤部门的负责人，由于我公司是知识密集型企业，生产设备主要是服务器pc机，没有笨重的生产设备，所以发生building outage无非两种情况，要么机房被破坏，要么大楼变危楼。而对于city outage则由公司大老板拍板是否需要执行这一级别的响应；
2. 各个项目部门提需求，以项目组为单位各自根据自己项目的SLA所规定的业务恢复时间提需求，需要什么后备资源，基本都是IT基础设施，及交通比如机票什么的，再加上各个项目的联络人，甚至是必要的生产人员，情况发生时需要转移到备份站点；
3.备份站点需要准备必要的维护人员；

物力：

1. 在本城市内以及其他城市寻找备份站点，配备必要的备份设施；
2. 数据的备份磁带，主要是源代码及其他的生产系统的备份，存留若干份 - 每周的备份放银行保险柜以应对building outage的情况发生；每月的备份发一份到其他城市的某个分公司（备份站点），以应对City Outage的情况发生；
3. 各个需要转移的关键人员，需要准备日期可更改的机票以应对city outage的情况发生并配备移动办公设备；

相关流程很多，三言两语说不完，只是提供了一个另外的角度考虑灾备的计划。该计划的高度是公司运营层面的，不是楼主的单个运维部门的计划，但是由于高度不同，所以考虑要更全面一些，当然耗费资源也更多一些。

bbzsxjj

回复 24# ge_johnny


    不错

shenlanyouyu

1、多机房运行情况下，如何做到快速引流？
负载均衡
2、如何保障在突发流量下，业务的高可用？
高可用系统主要手段是数据和服务的冗余备份及失效转移。
3、如何保障在业务出现故障后，快速响应处理？
自动化运维。
4、对一个新的大促（大规模推广）活动，怎样预估流量才算合理？
参考历史数据。历史峰值流量。
5、数据库方面，如何做应急预案（比如：数据库宕机了，怎么快速恢复处理，数据如何做到不丢失等）？
前期未上线时多模拟各种突发事件，测试应急预案是否可行，有什么问题。