本帖最后由 adminlily 于 2018-10-19 14:45 编辑
前言
云计算从2006年 AWS 推出 EC2开始，至今已经10年，从最开始多数人不清楚云计算为何物，到如今，大到 BAT等互联网公司,传统金融、证券、制造业企业，小到初创企业，都在积极推进云计算战略，以此加快业务交付效率，降低成本、提升竞争力。云计算的首要目的是将底层硬件抽象化，向上提供计算资源，存储资源，网络资源。
其关键核心是提高了IT业务交付效率，使企业花费更少的钱，办更多的事情，同时满足质量，安全的需求。在云计算大潮下，企业内IT部门，需结合自身的业务特点，思考提供怎样的云计算基础设施服务（IaaS）,以及基于 IaaS又提供怎样的 PaaS ，才能满足企业对于质量，效率，成本，安全四元组合的最佳要求，是摆在每一个运维从业者面前的问题。
YY 互娱基于 DevOps 理念，并结合 ITIL 最佳实践理念，从13年开始推出自己的IaaS，基于自身条件，推出一套符合企业内部要求的私有 PaaS 运维平台，并在实践中不断的改进完善IaaS，PaaS。本文将系统的从4个方面，分享YY互娱运维团队对于 PaaS 运维平台实践经验及未来展望，希望对大家有一些参考意义。
一、 运维价值体系
说到运维，还得从运维的价值体系说起。运维的价值体系，从四个维度来概括，即质量，效率，成本，安全。这体现的是一个经济问题，是运维部门总结工作时，公司高层能听得懂的语言。我们从事一切运维工作，大到公司运维平台体系构建，小到某项具体运维工作，最终将从这4个维度的数据来衡量，因此，运维工作应该以提高业务的质量，效率为出发点，在成本和安全中寻求最佳平衡点。在云计算的形式下，应当以自动化，服务化等技术手段为依托，数据化，可视化体现运维的价值输出。
二、 运维平台化方式
纵观整个运维技术的发展历程，运维平台化体系建设，我们认为主要有以下3种形式。
1. 面向流程
提供独立的工具子系统，再将工具 API 化，向上提供整合能力。
上面这种运维平台模式，是典型的以 ITIL 最佳实践为参考的运维体系建设。我们从一个常见的业务上线场景说起，来看看这种模式的特点。
假如一个 Web 业务需要上线，需要服务器资源，需求人（开发或者业务运维）需要到 CMDB 查看是否有空闲资源，若有，则到“服务器申请”流程里面提一个工单，经过一个审批流程（至少3个审批节点），拿到服务器。
同样，业务上线还需要数据库，需要缓存，需要 DNS 解析，需要开通权限，需要添加监控等等，需求人都必须到相应的系统提单，
才能完成需求。这样的流程体系下，对于需求的管理方是比较好的，各类需求，资源都可以较好的记录以及控制。
但对于核心的业务上线，变更、即面向用户的价值交付，效率很低，业务上线周期长，人力成本高。
ITIL 最佳实践中总共包括六大操作流程五大服务支持流程，流程都包括五大要点：流程目标、基本概念、主要活动、好处与风险，以及关键绩效指标与报表。以流程为导向建设运维体系，在互联网时代本身变化极快，不断试错，追求敏捷高效的目标冲突越来越大。
ITIL 面向流程的运维体系亟需改进，而改进的方向，即面向业务的服务化方向改进。
2. 面向服务
基础组件API 化（IaaS化），向上提供整合能力,再做面向运维的集中信息管理,配置管理，变更管理等。
如上图所示，我们仍旧以一个 Web 业务上线的场景，来进行说明。
面向服务的运维平台，首先需要构建底层资源的 IaaS 化，API 化。有了 IaaS化，我们就具备了提供一个一站式的运维平台的基础能力。在这样的运维平台上，业务上线需要数据库资源，平台提供对应的实例配置套餐，一键创建并返回给用户。
同样，制定一套标准的发布规范，实现自动化部署，业务在发布的时候，从 IaaS 资源池自动分配服务器。其他的资源，如 CDN，域名解析等，同样可以在平台上自助完成。
这样，业务上线的流程，全部以自动化，自助的方式完成。再往前，平台与持续集成，自动化测试平台进行对接，即可完成自动化测试，并根据自动化测试结果来决定是否进行发布。
这里面主要是以 DevOps 的理念来构建运维平台，这个方式也是我们的实践方式，后续内容将详细描述。
3. “拿来主义”
1.公有云平台公有云平台提供了完备的基础资源和强大的功能特性，且具体完善的 API，一般创业公司完全可以基于公有云平台进行运维平台化管理，无需自己再去开发一套运维管理平台，也没有能力去开发。不过一旦公司做大，考虑到单一供应商的风险，势必考虑至少两家云平台的资源，甚至可能还存在自有数据中心，这样就面临着混合云管理需求。
2.ITSM 商业软件
在云计算和 DevOps 驱动下，当前也有商业的ITSM 管理软件，提供一站式运维管理平台软件或者服务，而不是提供离散的 ITSM 管理套件。这类软件，在互联网+的时代，对于传统行业的 IT 部门转型升级会非常有帮助。
三、 YY互娱 - PaaS 运维平台理念和实践业务场景
YY 互娱在这几年处于高速发展的过程，即要稳固拓展 PC 端的市场，又需要在移动端寻求突破，业务场景：
1. 快速试错
互联网时代竞争激烈，特别是移动互联网时代，谁能快速推出产品，快速迭代，谁就能在市场上占得先机。快速试错是一种常见的竞争手段。PaaS 平台的业务交付运行模式，最大特点就是效率高，成本低，可以很好的满足快速试错的业务需求。
2. 人力不足
长期以来，互联网企业在运维方面的人力投入是不够的，很多时候是扮演的救火员的角色，PaaS 在平台层面提供一站式运维服务，高可用架构质量保障，减少业务上线对运维人员的依赖，在不需要运维人员介入，开发人员自己就可以上线业务，并持续迭代。 基于 IaaS 的 PaaS 平台，将硬件环境与软件环境进行了解耦，也降低了硬件故障对线上业务的影响，释放了运维自身的压力。
3. 成本压力
业务上线需求多，如果按传统的方式提供物理资源，对资源的需求量极大，而业务的访问量，生命周期不可预测，造成硬件资源利用率低。很多时候通过混合部署业务，提高硬件资源利用率，造成后期维护成本非常高。
平台理念
基于上面的业务场景，以及云计算的大背景，YY 互娱技术团队基于 OpenStack ，推出自己的 IaaS平台，主要面向游戏业务的云计算平台。基于 IaaS能力，逐步构建自己的PaaS平台。
我们的平台理念是：运维技术服务化，转化为生产力。平台提供高可用高性能高质量的基础架构服务，满足业务的快速交付。平台提供一系列的工具，组件，来支撑开发人员自助式运维。
开发人员只要使用平台，无需找到运维人员，就能应用运维的能力，如高可用，弹性伸缩，配置管理，容灾备份等能力，达到 NoOps 的目的，减少开发、运维不必要的沟通成本，使开发人员专注于业务开发。
执行 DeoOps 理念，平台将开发、测试，运维流程自动化打通，将持续集成，自动化测试的能力以服务化的方式输出到平台。最终，将业务价值交付涉及的各种能力，通过平台输出到业务，达到技术服务转化为生产力的目标。
实践历程
1. 整体架构
PaaS运维平台的整体架构：
两种颜色代表两个视图，蓝色部分代表从业务维度的视图，即从PaaS平台用户的维度看到的架构。灰色部分代表从运维自身的视图，即运维全局的视图。
从业务维度的视图，大概分为4层，从下而上，面向服务，包括硬件层，IaaS，PaaS和业务层。
从运维自身的视图，包括全局资源中心，监控中心，数据源中心，报表中心，安全体系等。
接下来的篇幅，主要把面向业务的各个核心组件及实践做介绍。
2. 标准化
标准化是运维自动化的基础，PaaS 平台的标准将以系统化，自动化的方式落地。
标准化主要包括这些规范：
以上规范，全部落地到PaaS 平台的各个子系统，由子系统自动化完成。比如对VM 环境的标准化，通过 VM 镜像方式交付。
3. IaaS
我们的 IaaS 层提供了以下服务，来满足我们的应用上线。
计算虚拟化
计算虚拟化部分，我们这里使用 VM，将 VM 作为我们容器计算的最小单元。当前使用 OpenStack 开源实现方案，使用 KVM 做 hypervisor。提供各类 VM 套餐满足不同业务场景。计算能力扩展我们采取的 VM 的横向扩展，即 ScalingOut，后面章节会介绍。
存储虚拟化
考虑到性能问题，我们VM使用了本地存储。没有使用 Ceph分布式存储。
对象存储上，对接了公司提供的基础服务。
网络虚拟化
网络部分，采用了Neutron Provider Network，未实现 VPC 网络隔离。
数据源
数据源我们提供了3类数据源，Mysql，Redis，Memcached。这3类资源是平台上使用最频繁的组件。我们以单物理机多实例的方式运行，未主动采用 cgroup 进行资源隔离。这些插件在被创建的时候会自动添加监控，用户可以在平台查看相关监控状态信息。
插件平台。上述基础组件以插件方式与平台整合，类似于 Heroku 的 Addons服务。
具体业务流程描述如下：
- 容器访问插件：业务容器从环境变量中获取到的插件信息，直接请求具体的插件。
- 插件平台的引入，增强了PaaS平台的开放性和灵活性，项目所需的所有基础组件，不需要 PaaS 平台自己提供，可以由公司其他开发同事提供。插件平台面向公司内部所有开发人员，设置了一定的运营策略，如贡献率,引用量，收获赞等，并与公司的绩效积分，技术职级评定做一定关联。
其他资源
其他基础服务，我们同时提供了 CDN，消息队列等。
CDN 是使用第三方厂商基础服务，通过 API对接，实现一键创建 CDN 服务。消息队列服务底层采用了 RabbitMQ集群。
同样，这些资源也以插件方式整合到平台。
4. 持续交付
基于上面的 IaaS 层，我们有了构建 PaaS 的基础能力，来解决持续交付的问题。我们从以下几个方面来描述
交付模型，指在我们的 PaaS 平台上的业务，构建一个业务的模型。这个模型也是基于我们的应用程序打包规范来做的。这里再简单描述下：
项目对应的是一个业务，一个项目又分多个模块，每个模块就是一个独立的部署单元；模块一般是按功能进行划分，比如最常见，一个项目有 admin 模块，user 模块。我们的PaaS平台的部署操作最小单元是项目的模块。以 Java 应用为例，模块的类型有 War和Jar。不同类型对应不同的部署动作。
项目的管理包括项目的新建，以及用户权限管理，属性管理。需要的基础信息包括：项目 代码库地址，项目成员等等。
项目管理中涉及的信息
持续集成
大部分项目都是小型项目，不涉及多人协同开发，这样的场景下不涉及到复杂的持续集成场景。
小步快跑。本身项目的迭代速度比较快，集成频率比较高，一般不会出现持续集成不通过导致需要花费大量精力解决集成失败的问题。
以Java 项目为列，我们约定在 pom.xml 根据模块名称打包成对应类型的包。并自动创建对应的项目模块，打好的程序包上传到分布式文件系统（DFS）。实现只要将代码提交到版本库，即可一键打包发布。在我们的现实情况中，并没有对每一个项目要求持续集成，而是选择性的，其中的原因是：
持续测试
PaaS 平台与自动化测试平台进行对接，在基础信息上同步共享，包括项目名称，项目成员，版本库地址等。持续测试的实践经验是：
业务分级。对核心项目进行严格的持续测试，包括单元测试，QA 自动化测试。对非核心项目，默认不进行测试。是否测试的权限交给项目管理员，项目管理员一般都是开发团队的 Leader。
风险控制。在实际的运作中，测试能发现的问题是有限的，需要考虑一旦出现问题的补救措施。因此，对于核心的业务系统，引入风险监控，降低 bug 的影响范围。
持续部署
持续部署中，涉及到如下几个问题，我们的解决方案是：
数据源。项目所需的数据源（Mysql，Redis）实例，用户在平台上一键创建，然后通过环境变量的方式注入到业务容器。具体流程见前面章节“插件平台”所描述。
配置管理。包括运行环境的管理，JVM 参数定制，Nginx 参数定制，域名配置，证书配置等，这类配置全部在平台，由用户自助或系统自动化完成。
发布。涉及“包版本”发布审批，服务器资源自动分配，“配置管理“中涉及的各项配置应用到相关组件。
回滚。平台支持包版本快速回滚。
持续反馈
基础资源监控及监控数据展示
运行维护
业务可用性监控和数据展示
上述三点在后面的章节详细说明
5. 高可用架构
平台架构高可用设计，从最上层的攻击防御，到数据持久化层，全部提供高可用方案。业务只要接入平台，就具备全部的能力。
云防DDOS，接入公司层安全中心的DDOS 防火墙，保障业务安全。
GSLB，平台提供多机房，多链路接入的能力。项目域名自动解析到多个机房，提供就近接入的能力。
OSPF-LVS，四层负载均衡采用OSPF-LVS 架构，具备平滑的水平扩展的能力。
AppRouter 应用路由层，Nginx提供七层的路由转发，同样具备平滑的水平扩展能力。
Container，应用逻辑层。这一层是项目级别的配置。提供 Nginx+容器（Tomcat，Resin,PHP-FPM）环境。这一层引入 Nginx，是考虑到部分七层业务逻辑控制，交由项目级别的控制，不至于每次项目级别的变更，而影响上一层AppRouter 全局层面的变更。这一层具备弹性伸缩的能力，后续章节具体讲解弹性能力实现方式。
Cache 层，提供纯 Cache 和数据型 Cache。这一层我们主要是使用的 Redis，以域名和端口的方式对外 ，通过域名切换，具备故障切换的能力。
DB数据持久化.这一层目前对于所有业务实例，默认提供带主从的实例对，业务发生故障时，需要根据业务场景对数据一致性要求情况，进行故障切换。这一层当前未引入开源类似 MHA,MMM 等架构，而是通过域名切换的方式来实现，这里面参考了 AWS 的实现方法。
我们的架构一般都是 MM 架构，当主节点发生 Down 机后，域名切换到从实例，Master 恢复后，只要修复主从关系即可。对于高并发访问量的业务，需要一主多从，或者 Mysql 环形复制场景，这些需要根据业务特性做一些人工介入。
6. 弹性扩展
弹性
高性能：在业务访问规模上去时，服务器自动增加，保证性能
经济性：在业务规模降低时，自动收缩服务器，节省成本
高可用：如果有服务器宕机，自动进行故障隔离
平滑部署：实现热部署，不影响现有业务运行
弹性伸缩提供包括动态伸缩，热部署，故障隔离三层含义。弹性示意（图十四）
弹性是 PaaS 平台的基本能力，弹性技术的好处有：
我们的弹性技术是由CloudRouter 和 CloudMonitor，资源池3个部分组成。架构：
CloudRouter是核心组件，是弹性调度的大脑，在用户的任务，资源分配中间起核心的调度协调的作用。
CloudMonitor 负责项目服务器的状态数据收集，并提供接口供 CloudRouter 查询状态。
资源池是基于预创建的可用资源缓冲池。这里主要是指 VM 资源。VM 资源又分为多种配置，对于每种配置的资源，可在后台配置预先创建一定的数量。一旦服务需要资源，可立刻从池里获取。
弹性的策略. 当前我们的弹性策略是模块的所有 VM 的负载平均值。当负载平均值大于我们们指定的弹性阀值，则进行扩展，可设置每次扩展的服务器数量。同样，当平均值小于我们指定的阀值，则进行缩减。
在实际的业务场景中，可能有些业务是内部小型项目，不需要进行弹性，是否弹性是一个可选项。另外，还有一些项目，可能无法满足无状态的设计要求，不希望每次部署都更换服务器，我们也提供了在部署的时候，选择“就地部署”，就地部署的意思就是每次部署都使用同样的服务器。弹性调度策略配置：
7. NoOps
平台提供一系列日常运维管理工具，包括常见的服务器性能查询，日志查询，应用分析工具，数据源相关信息查询。大多数场景下，开发人员无需登录服务器。
日志管理
文本日志。我们在每台vm上通过 Rsyslog 进程收集业务进程日志发到集中日志服务器。在集中日志服务器端，我们按项目名称存储，一个项目一个日志目录。日志目录权限管理，我们使用Linux 用户组权限设置，只有具备PaaS 平台项目管理权限的用户，才能查看该项目下的日志。
Web 日志分析。PaaS 平台对接了公司级的 Web 日志分析系统，能够实时展示项目域名的日志访问量，带宽流量，请求状态等情况。
日志管理方面，我们提供了两种方式
监控
平台监控主要是基于 Zabbix 做了一些 API 层面的定制开发，我们内部称之的为“CloudMonitor“。主要包括以下三个方面功能：
基础监控
VM:基础监控包括 CPU,内存，磁盘 IOUtils，磁盘空间使用率，网络流量，TCP链接数,进程数等。监控信息如图：
数据源：对 Mysql，Redis，Memcached 常规指标做了监控。
自定义监控。支持 TCP,DNS,PING,HTTP,支持自定义告警条件和策略。如图：
告警。平台告警由 CloudMonitor 组件负责，支持多种方式告警。CloudMonitor 组件是在Zabbix 的事件接口上，定期获取事件，按业务维度进行汇总分析发送给业务开发负责人和运维负责人。
做了一定程度的事件聚合，比如宿主机 Down 机，宿主机上的 vm 相关信息关联起来，从业务开发负责人看：某 vm Down 机是由于某宿主机引起；从运维层面看，某宿主机 Down，影响了这些 vm，这些 vm 运行了这些业务。
工具组件
在自助运维场景中，开发人员需要对项目 ，域名，IP 信息进行查询，平台提供相应的工具。
可用性反馈
平台的可用性反馈，主要是对平台各个层面的服务可用性，进行系统化，自动化评估。这里主要介绍下我们的业务的可用性度量实践方法。
我们称为“Monitor.X监控规范”具体描述如下：
X代表语言。(注：若是 PHP 项目，文件后缀为 monitor.php；若为 node.js，则文件名为，monitor.js）。
路径要求：url规则为http://项目域名/monitor/monitor.X）项目域名取配置管理里面，设置域名框中，去掉 包括 test 字符串后的第一个域名。
输入参数：接口不用输入参数。
输出说明：接口输出只分为两种，正常和不正常。
正常：状态码为200，且输出包括字符串“200”
非正常：状态码200或者非200，且输出字符串不包括200。 (可以用作错误提示内容)。
对于状态码200，同时信息也包括200字符串，但是实际是服务不可用的情况，需要程序员特殊处理返回信息。
接口内部实现要求：要覆盖系统的核心业务逻辑(业务自身把握)；有多个业务逻辑时，也是统一在一个接口返回(调用顺序由业务控制)。
- 业务在PaaS 平台发布，平台将自动加上项目的 Monitor.X 监控，根据 Monitor.X 的状态，来衡量业务是否可用。可用性反馈如图：
8. 安全审计
所有操作包括打包，配置，部署，日常运维等操作全部收拢在PaaS平台上,每一个用户在平台的的所有操作都有记录，可追踪。 对于核心项目的数据变更类的操作，引入运维审批。
9. 平台运营
双向反馈
构建平台用户反馈沟通群组，第一时间接受响应用户的需求，重视“客户满意度”，并将客户反馈的问题，由专人进行收集汇总，每周发出平台质量问题周报，并组织开发运维力量，集中有效解决用户反馈的问题。这些问题，有技术性的，流程性的和体验性的，用户每一个问题的交互过程，通过沟通群传达给平台每一个用户。
体验优化
长期以来，在面向技术人员的系统 UI设计，用户体验是不好的，内部技术平台首要解决的是可用性问题。PaaS 平台需重视用户的体验，体验好也才能实现我们的 NoOps 的理念。试想一下，如果我们做了一个自己觉得很厉害的功能，而用户觉得不好用而弃用，那做的可能就是无用功。
也许有种担心，我们已经把所有的用户放在一个群里面，任何一个细节问题，体验问题，都会让所有用户知晓，平台维护者比较被动。我们的经验是，在 DevOps 文化下，平台的建设者（运维团队），平台的使用者（开发团队），都有面向业务最终用户价值交付的共同目标，都将以合作，包容的心态，共同推动平台的进步。
平台收益
平台收益情况，从四个方面表述，如图所示
质量
基础组件平台保障高可用，故障自动隔离。应用容器弹性伸缩，确保在业务变化中得到稳定的服务质量。平台提供自动化可用性管理方案，对业务质量形成有效反馈。
效率
执行 DevOps 理念，将研发，测试，运维全流程以自动化的方式整合，实现业务的快速交付。提供丰富的自助运维工具，系统，满足开发自助式运维需求，提高日常维护的效率。
安全
在网络安全和系统安全上，接入公司级安全体系，包括云防 DDOS,主机基线安全，主机漏洞检测，应用层引入公司的 WAF模块。在数据安全和 D/O 权限分离上，平台隔离开发人员登陆生产环境和生产数据库的权限，所有权限全部收拢在平台上，变更类操作自动引入工单，由运维介入审批。所有操作记录可跟踪。
成本
通过 IaaS 层的计算虚拟化，资源池，弹性伸缩等技术手段，提高系统资源利用率，减少硬件资源采购。通过自动化的技术手段，减少人力资源的投入一站式的运维管理服务平台，大大减少人员流动导致项目的交接成本，降低人力成本。
平台风险
PaaS 平台的风险，如图所示
1. 容量管理
PaaS 平台的资源交付是完全自助的，不需要运维人员介入审批，IaaS 层的资源容量是有限的，因此，从接入层，应用层，IaaS 层，构建全面的自动化容量评估系统，显得尤为重要。需要关注几个点：
资源调度
IaaS 层的资源调度器，一般都是静态的调度策略，是基于资源创建时间点来选取一台最优的节点进行资源新增。一般来说，我们的调度策略都会有一定的超额比例。但随着业务的发展，某些节点的负载会比较高，甚至出现资源不足导致系统宕机。
对于计算节点，我们有弹性扩展来保证业务可用性。但对于数据库如 Mysql，如果出现宕机，对业务影响非常大，一个 Mysql 宿主机，可能运行10个以上的实例，一次宕机影响几十个业务。
容量预警
对各类资源设置一个预警阀值是非常重要的。比如对于 Mysql 数据源，我们主要关注的是内存的分配，那么预警阀值=(已经分配内存)/总的可分配内存*100%，这个阀值随着资源池越大，可以调得越大。
容量预测
定期发布容量预测报告。如对计算资源来说，定期自动预测不同类型的套餐可创建的数量。同时，还需构建基于一段时间的趋势预测，以便及时发现平台资源容量突变情况。
2. 隔离性
资源隔离
私有 PaaS平台，对 IaaS层资源，一般都是没有做资源隔离的。比如，像 Mysql 这种多线程的应用，单机跑多个实例，可能一个业务异常 SQL，就会耗尽宿主机的所有CPU资源而影响其他业务。因此，对于业务实例的质量分析，主动发现实例的质量变化，并及早介入优化，显得尤为中重要。
从我们的经验看，大部分的 SQL，只需简单的索引即可得到明显优化。而这些 SQL 优化，只要能及时让开发人员知道，他们就有能力去优化，或者更近一步，质量分析平台能自动生成优化的 SQL，自动推送给开发人员进行优化，或者再近一步，把优化的 SQL 应用到数据实例，并通知用户执行结果。
网络隔离
当前我们的IaaS 层未实现 VPC 网络，网络上不具备隔离性。这是我们当前正在改进的方面。
YY互娱- PaaS 运维平台未来规化
1. 面向业务/运维的一站式平台
增强平台的一站式运维管理的能力，包括容量评估，管理，预测，质量分析，成本分析，容灾切换等。如图所示
2. 多语言支持
支持 Task，Node.JS，Python等语言。
支持资源编排。
3. 自动化、数据化、可视化、产品化
进一步提升自动化，包括IT运营分析，容量评估预测，容灾备份切换等。
将运维的各项能力数据化，并进一步可视化出来。
产品化，提升用户体验。
如图所示：
4. 业务运行于VDC
YY 互娱技术团队当前推出自主研发实现 SDN，SDC，SDS 的云计算平台， 初步具备了SDDC 的能力，我们把 SDDC，称之为 VDC(Vistual Data Center)。
在 SDN上采取软硬结合的方案，在硬件交换机上实现了基于 VxLAN技术的VPC网络数据包的封装和解封。下一步，我们将构建基于VPC的 PaaS 运维平台。
原创：刘亚丹 转自高效运维社区。
| 
转播
分享
淘帖
()