《运维之下》——第六章：系统运维概述

提到系统运维大家可能较多想到的是和OS（Operating System）类相关的工作，但在这里我们延伸并扩展了它的范围。我们把运维里整个基础资源和基础服务的建设，都涵盖进来，比如数据中心建设、网络规划、CDN服务。
如果能把运维比喻成一栋大厦，每个楼层入驻的是不同业务，系统运维就是大厦的根基和供水供电系统。满足海量业务的资源需求和确保服务的稳定运行是系统运维的核心价值。
 数据中心和网络建设
移动互联网爆发，快速地占据入口是制胜根本，而一个平台的建成和完善至少需要2～3年的时间。
回顾一些成功的互联网公司的业务发展多数是典型的从无到有，直接到爆发，从业务曲线看，几乎是无平滑的过程。因此系统建设面临了巨大的挑战，这其中最凸显的是数据中心和网络建设。
初创公司前期是不会自建数据中心的，一般租用ISP数据中心，然而中国的ISP是大欺小的垄断状态，根本没有平等对接；政策把控得严，互通只能在骨干做。
推进技术前进的永远是需求，在骨干城市出现SP通过单一IP代播静态实现的BGP链路，在一定程度上曲折地改善了中国的互联互通质量。静态BGP资源满足了业务自身没有用户调度能力的场景。
创业初期，业务功能和未来增长规划不明确，很难做到资源的预估，在数据中心选择上，往往发展不到一年就出现瓶颈，预留又会有过多的成本支出。
有一段时间，我们数据中心的发展一直处于“蜕壳式”成长，通过不断建设新的、更大的数据中心来满足业务。但业务搬迁耗时耗力，服务中断影响用户体验；网络中核心设备不易选型，核心设备如果不投入高端型号，后续扩容升级难度大，替换下来的设备无法再利用。在那段时间里，系统运维的工作是非常痛苦的。
为了解决数据中心和网络建设“蜕壳式”的不足，规划和建设进入了第二阶段。我们把数据中心和网络建设划分成 核心数据中心、节点数据中心、传输网三部分。

核心数据中心全部采用“双中心”+异地备份规划，用来承载最主要的业务逻辑单元，关键的数据和内容都放在这里。加强了SmartDNS的建设，通过View支持、HTTP支持、EDNS扩展多种能力，提升浏览器访问质量，同时在客户端层面，通过HTTPDNS来提升稳定性和访问质量。系统运维和应用运维、研发一起把业务做到具有多站点部署的能力，实现业务“双活中心”的架构。
一个新数据中心从选择到可以上线业务需要4～6个月的时间。所以选择的数据中心一定要有能支持规划内和应对突发事件能力的机柜容量，数据中心供应商最好是有二期、三期的建设计划。
规划需要充分调研各业务线的业务增长，我们每年的Q3会把业务线的技术负责人召集到一起，收集至少未来一年的增长计划，突发增长部分的支撑，需要根据历史突发概率的评估来确认，通过商务手段做一些预留。核心网络的规划遵循了一个原则：核心网络设备要适当地超前投入。
双中心间数据要实现同步，逻辑上业务自己解决，物理上要依赖传输网（传输网：数据中心互联网络，也称为DCI（Data Center Interconnection））来打通。
我们规划建设了两个链路汇聚点，汇聚的物理节点位置都是自有的或长期租赁并有物业管理权的，能自由进出光纤。通过光纤把汇聚点和数据中心进行互联，每两个点之间至少链路双路由互备。传输网建设完成后同时也解绑了链路和机柜的关系，更为建设自己的BGP、带宽临时调度做好了铺垫。
另外，还把我们国内的其他几个节点数据中心连接起来。海外业务发展得也很快，在中国香港地区建设了两个汇聚点，国内的核心和所有海外的数据中心专线都和香港地区的连接起来。
成本虽然会比较高，但是完美地解决了全球的联通性问题。之前没有专线的时候，尝试过走广域网、加密和非加密的VPN，服务可用性基本没法保证，各种链路差、被拦截、被丢弃、解包。长途部分因为距离长，光纤断的几率自然会高很多，所以长途专线尽量选择有保护的链路。
节点数据中心 的应用场景是CDN Cache类，业务结构就是分布式的，有冗余的能力。地域选择主要在东部沿海地区，华中、东北、西北、西南少量覆盖节点。这和中国的网民用户分布有直接关系。
节点数据中心的选型过程一般是先分析用户分布，然后预选几个点，通过自开发的用户访问质量系统（UAQ），真实用户抽样测试选出两个点做互备。因为节点数据中心会受到自身容量、骨干拥塞的影响，所以质量是动态的，建设完成后会通过在用户访问的接入主机做TCP连接和传输速度的分析，通过数据来周期性地调度优化，也会新建优质节点和撤离质量变差的节点，进而形成了一个持续优化的闭环流程。
数据中心内部的选择也尤为重要，硬件条件主要考量建筑、电器、机械3个部分，都要做到T3标准以上。其他部分考量Internet接入、网络攻击防御能力、扩容能力和空间预留、外接专线能力、现场服务支撑能力几个方面。一般也是预选一批，然后采用分规格和权重打分的模式综合评比。

海外业务的支撑主要选用了相对成熟的AWS云服务。应用较多的是S3存储、EC2、CDN加速几个产品。

资产管理的演进
主机和网络的交付是资产管理中主要的内容；系统管理平台的建设要跟上不同量级下的需求。
运维的最早期，采购需求是没有计划的，多是业务增长了就零散地购买。购买完成后设备上架，逐台装机，然后将权限交付给应用运维，资产靠Excel记录。随着采购量的提升，逐渐变成了每周有采购、每天有采购，到货批次混乱、无序，原始的手段已经逐渐不能满足发展的需求。
为了改变这种状态，和业务部门做了深度沟通，把零散采购归纳为预算梳理，按月度采购。再后来通过设备Buffer池的建设，改为按季度采购，但仍不能避免有一些紧急采购。
虚拟化主机推广范围扩大，对业务自身的隔离、成本的优化都有显著成果。主要在预发布、测试、接入层、中间层的场景大量使用。
在物理机方面，根据业务类型差异对机型进行了定制，这里讲的只是基于成熟的品牌型号进行电源、CPU、内存、存储的定制。还需要结合接入交换机的端口数来布置。我们通过使用高密度机型，最高做出过一个机架45个计算节点、13A电、1台48口交换机的标准，但也存在搬迁节点困难的弊端，并非所有场景都适合。
提供资产管理平台，对物理资产信息进行管理记录，对上层平台提供数据信息。按季度采购的主机需要在短时间内集中化交付，所以开发了高并发的自动装机系统。逐渐把系统运维的工作服务化交付，提供给应用运维主机重启、系统重装、Console查看等基础功能。和应用运维管理平台定义交互接口，实现资产管理系统和运维管理系统的对接。比如初始化完成的主机自动Push到运维管理平台的服务树节点中，应用运维可以进行后续环节的操作。
当设备数量上规模后，硬件、软件故障会成为一种常态，故障的响应处理需要分级别，并制定服务响应等级（SLA）。目前我们的系统管理平台将所有的故障报修服务化起来，对其他平台开放API，实现报障自动化。每周、每月会评估故障总量、平均故障处理时长，从而挖掘出不合理的环节并优化。

网络设备的配置实现了标准化版本管理，每台设备的配置可以在系统中查看、复制等。
重新设计了设备申请和交付流程，实现不同资源申请对用户同一接口输入/输出。把使用到的公有云、主机租赁、自购主机多种资源的申请，都封装到统一入口，把现有设备使用率监控系统加入到审批环节，并把交付进度可视化，真正服务化运作起来。
临时性、有突发增长的业务优先使用公有云或私有云。随着公有云和开源私有云系统OpenStack的快速发展，公有云计算、存储服务都已成熟，自建私有云交付能力也大大增强，很多场景完全可以使用云化的资源。
强IO需求的DB、Hadoop服务，仍然跑在自建数据中心。物理主机+混合云的多构成资源模式，将是接下来要重点探索和实践的方向。

基础服务
在服务方面，提供稳定的DNS域名解析、LVS负载均衡、SNAT集群出口、CDN加速以及各种基础保障服务（YUM、NTP、SYSLOG）等，并开发对应的管理系统，如LVS配置的Portal和对自动部署提供API接口、DNS调度管理系统等。
同时，系统运维需要配合业务进行服务优化、硬件优化、内核优化来满足不同的业务场景（CDN大小文件、域名解析、LVS）。像DNS、LVS都是上层业务强依赖的服务，服务短时间的中断都会造成大面积故障，服务可用性都需要定义到99.99%以上。要达到高可用性，在架构方面需要设计高可用的集群方案。通过对网络设备以及主机的带外、带内监控及时发现异常。
除了基础设施的建设，安全在系统运维工作中也同等重要。比如网络的公网区域是所有用户访问的第一入口，需要在边界做黑白名单机制，如对22等端口做第一防线的防护。
站点知名度提升后，各种攻击就会成为常态，需要在网络方面做DDoS防护，特殊的业务入口有流量清洗服务，LVS做半连接攻击等防护。内部特殊安全区的业务需要各种ACL，对ACL的管理是非常痛苦的事情，我们把这部分功能都流程化审批和管理，将来希望能够做到自动化线上配置。
我们定义了一个第三方CDN和自建CDN共存的生态环境，选择市场上2～3家成熟的CDN供应商，细致分析自身业务的特性，比如分析总内容量、大小、曲线规律等，让业务能使用到最适合它的资源。同时做到一个源站对应多个前端CDN，当一家的服务出现异常时可以快速实现切换。
在业务CDN使用量95%值达到30Gbps的时候，选择了自建CDN。出发点主要有两个：一是追求质量可控；二是整体成本优化。

在本章中，我们把系统运维涵盖的内容整体串讲了一遍，对系统运维有了一个整体的认识。