如何做好一个运维预案？

bbzsxjj

获奖名单已公布：http://bbs.chinaunix.net/thread-4192127-1-1.html   

话题背景

现在各大网站，各大电商系统都在准备各种活动，典型的比如：淘宝的双11，京东的618，在这些活动中，虽然有很多的新技术在支撑，但是要保障业务的稳定和性能，运维预案是必不可少的环节，运维预案涉及到各方面的东西，比如：网络的高可用，突发事件处理，应急处理流程等，从基础到应用，从技术到管理都是一个挑战，一个好的运维预案是大促或者大型推广活动必不可少的。本次想就以下方面，大家一起讨论下如何做好一个运维预案：

讨论话题
1、多机房运行情况下，如何做到快速引流？
2、如何保障在突发流量下，业务的高可用？
3、如何保障在业务出现故障后，快速响应处理？
4、对一个新的大促（大规模推广）活动，怎样预估流量才算合理？
5、数据库方面，如何做应急预案（比如：数据库宕机了，怎么快速恢复处理，数据如何做到不丢失等）？
希望大家一起就此问题讨论，讨论的方面不限以上所述的几点，可以畅所欲言，主要是让我们在以后的此类活动中提前做好运维预案，避免因运维不到位，被黑锅砸到，嘿嘿。。。。。。



讨论时间
2015-09-30至2015-10-31



活动奖励
活动结束后将选取4名讨论精彩的童鞋，每人赠送一本《自动化运维软件设计实战》图书+互动出版网购书券一张，面值20元以作为奖励。
活动效果好会额外增加十名参与奖，每人奖励互动出版网购书券一张，面值10元。

购书券使用说明：购书券为互动出版网的直减通用券，使用无限制，在支付的时候选择代金券支付即可。有效期到2015年12月31日
购书券使用链接：http://www.china-pub.com/


奖品简介

作者： 吴文豪   
出版社：电子工业出版社
出版日期：2015 年7月
开本：16开
页码：279
版次：1-1


内容简介：
《自动化运维软件设计实战》主要讲解采用OSGi技术来设计一款可插拔式的运维软件的方法与思想，为读者提供一种不一样的运维软件设计与自动化运维解决方案。
《自动化运维软件设计实战》分三部分，第一部分讲解开源社区中比较流行的三款集中化运维软件，第二部分与读者一起分享为什么要采用OSGi的技术来设计集中化运维软件，第三部分介绍设计这款运维软件所涉及的技术和一些设计思想。

niao5929

1、多机房运行情况下，如何做到快速引流？
前期设计需要进行很好的负载均衡设计，多机房下机房间高带宽是必须的，要不没有性能，一切都是妄谈
2、如何保障在突发流量下，业务的高可用？
需要进行很好的QOS设计和规划，让重要业务数据不至于因为突发流量产生中断
3、如何保障在业务出现故障后，快速响应处理？
自动化运维模式首先应该考虑了业务故障的自动切换。
4、对一个新的大促（大规模推广）活动，怎样预估流量才算合理？
5、数据库方面，如何做应急预案（比如：数据库宕机了，怎么快速恢复处理，数据如何做到不丢失等）？
数据库应该使用前期的好的规划策略，比如HA或者采用网格模式进行部署。应该避免数据库宕机，数据中心模式下，多活数据库应该是不会有这些问题发生的

594008

1、多机房运行情况下，如何做到快速引流？
     我们公司是做互联网支付收单的，三机房收单，一直在做双点保障，但是呢，一个机房出了问题，或者网络不通，还是有这样那样的问题
     业务错综复杂，怎么分流，其实还是需要业务开发部门的配合，坚决避免跨机房访问
     域名的负载均衡，一般都是DNS，可以使用智能DNS，或者使用腾讯出的一款DNSpod 软件，能实现检测服务宕机，可以智能暂停、切换域名IP

2、如何保障在突发流量下，业务的高可用？
     业务的功能一定要有降级的方案，要不然，都玩完了，我是深有体会

3、如何保障在业务出现故障后，快速响应处理？
    监控，首先得知道出了问题，然后才能说到解决，如果没在电脑旁边，还得打开电脑，拨VPN ，那半个小时过去了


    能自动切换最好。比如web服务宕机，那么负载均衡就自动踢出集群
    数据库异常，有问题，程序能自动把这台数据库切掉，我们公司就是自己开发了一套这样的检测程序，实现数据库异常的自动切换

4、对一个新的大促（大规模推广）活动，怎样预估流量才算合理？
     永远不要相信，业务人员提出的流量预估，有的时候说的很大，其实很小。有的时候说的很小，但是瞬间搞死，深有体会
     大促前，需要算出现在机器的承载量，预估一个量，然后事先扩容，但是，还是需要预留一些资源，能快速扩容响应

5、数据库方面，如何做应急预案（比如：数据库宕机了，怎么快速恢复处理，数据如何做到不丢失等）？
    我们是用的oracle  经常在ggs同步问题上搞死人
    任何应急的预案，其实都是预案，真出了问题的时候。说实话没有几个人是按照预案做到。都是为了快速的恢复业务
    数据库有问题，几分钟解决不了的话，只能切换，这样是最快的
    数据库数据丢失的问题，我们又自己写了一套检测程序去监控，数据同步问题，是不是有数据不一致的情况

运维还是挺苦逼的，出了问题，不管谁的问题，都跑不掉

我个人觉的一点，人是不可信的，只要能用程序完成的工作，尽量不要叫人去弄，自动化的处理才是王道

个人的一点小见解

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的情况发生并配备移动办公设备；

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

zero-B

一？没人沙发？我抢一个。

好久没关注技术了，正好这个问题我也比较有兴趣，坐等牛人解答。

wenhq

先坐sf。。。。。

第一最寂寞i

这种高大上的问题，我不会啊，为什么没有晓明结婚的议题呢

shang2010

理论很多，实际操作的时候，大家一阵乱来，最后也顶过去了

wsysx

多机房的热备、负载均衡是个好东西，但是在建设多机房的时候呢，也挺折磨人的

demilich

本质都是提前做好预案，预留好资源 ...

niao5929

其实所有的演练都是瞎扯蛋。最重要的是培养一只心底有数的工程师队伍。这需要信任的环境和足够的银子。

bbzsxjj

我个人觉的必要的预案和演练还是很需要的，特别是压力测试，所有的东西用数据说话才是关键！