第三章 | 运维平台
服务可管理的前提是运维数据的准确性，而标准化和流程化是保证数据准确性的前提。只有提供准确的运维数据，才能进一步实现服务的运维自动化。所以，一个能够准确记录和管理服务信息的运维平台，对于运维的发展至关重要。
在运维团队组建初期，运维平台建设一直属于运维团队的工作重点。通过标准和流程的约束，保证信息准确地录入到平台，以便能够准确提供运维所需要的各种维度信息，帮助运维人员开发更上层的系统，获取运行状态、资源占用等信息，与部署系统联动进行服务的动态调度部署和故障容错。
一个真实案例中，早期的运维平台有服务器管理、IDC管理、监控（Zabbix）、密码管理、故障记录等这几个模块，更多的是信息记录，更像一个网页版的Excel。没有流程的引入，信息录入完全依赖于人。这个时候的信息仅仅用来对账，滞后不准确的数据无法作为运维工具的基础依据，更谈不上自动化。平台各个功能模块之间没有信息关联，所有信息如一个个孤岛，对于运维的价值非常低。
随着需求场景的进一步明确，平台在不断建设。形成了两个大的运维平台，即：资产管理平台和服务管理平台。
资产管理平台
负责记录基础的物理信息，如：IDC、服务器（资产编号、参数、采购时间、供应商）、配件、网络设备、IP地址、ACL等。提供了多个子功能，如：预算管理、自助装机、故障报修、IP地址管理、ACL管理、LVS管理等。资产管理平台作为所有物理资源的唯一出入口，通过流程将预算管理、故障管理这些可能导致资产信息变更的环节打通。新采购的服务器录入到资产管理平台，服务器报废也必须经过它。通过资产管理平台，可以很方便地查询各种物理资源的使用情况。比如，一共有多少服务器、有哪些机房、机房的机柜分布情况、每个机柜摆放的服务器位置等信息。
服务管理平台
记录了业务运维所需的逻辑信息，提供一个基于树状结构（注：后续简称“服务树”）和权限绑定的管理模型。基于服务树和权限管理，实现域名管理、监控系统、部署自动化、环境初始化等子功能。服务管理平台记录了多个维度的服务信息，比如，产品线内有多少台服务器；谁具备这些服务器的登录权限；产品线对外使用了哪些域名；服务器上部署了什么服务；服务运行的状态、版本、路径；服务都添加了哪些监控等各维度信息。
可以认为资产管理平台和服务管理平台的信息集合就是ITIL里的CMDB（ConfigurationManagement Database）。由于每个运维子团队的分工不同，平台定位和用户场景不同，出于敏捷建设的考虑，我们将它拆分成了两个平台。资产管理平台的主要用户是系统运维工程师，他们关注设备的出入、维修等管理工作，交付资源给上层业务；服务管理平台的主要用户是应用运维工程师、研发工程师和测试工程师，他们关注服务运行的相关数据。虽然是分开的两个平台，但平台之间通过流程和API接口，实现了数据的相互关联。
资产管理平台负责底层的物理信息管理，提供API供服务管理平台查询和同步。服务管理平台通过API获取新交付的服务器列表及其详细信息，将它们归属到服务树产品线节点，分配对应的权限。应用运维工程师在服务树上领取空闲服务器，进行一系列的环境初始化、服务部署、监控添加等工作。应用运维工程师在服务管理平台提交报修申请、服务器归还等操作，通过API将信息推送到资产管理平台，由系统运维工程师进行相应处理。
两个平台负责所提供信息的准确性，对外提供API接口，可以供更上层的业务使用。基于这些信息，我们可以做更多智能化、自动化的工具开发。下面分享几个实际案例中的应用场景。
场景1：Hadoop数据存储管理 我们有大量的数据存储在Hadoop集群上，出于节省成本的考虑，我们将以前的3副本变更为1.5副本，降低一倍存储量。为了避免相同数据存储在同一个机柜的服务器内，降低由于单机柜断电或者同机柜服务器多块磁盘故障导致数据丢失的可能性，我们通过平台提供的API，获取Hadoop集群所有服务器的机房、机柜分布和机架位置信息，在存储数据的时候进行合理的动态调配。
场景2 ：智能报警合并当服务器死机、机柜断电或接入交换机故障、机房断电或核心网络故障时，往往会收到大量的报警信息。我们可以通过平台提供的信息，对报警信息进行最大程度的聚合，减少报警发送的条目，而且能更好地帮助运维人员快速定位故障。当一台服务器死机的时候，通过监控项与服务器的关联信息，将这台服务器相关的SSHD监控、Nginx监控等报警信息进行聚合，合并成一条服务器宕机报警；当一个机柜断电后，我们可以将该机柜下接入交换机交换机和每台服务器的报警进行聚合，合并成一条机柜或接入交换机故障报警。
场景3 ：磁盘故障自动报修 在互联网业务中大数据应用已经很广泛，Hadoop服务器数量占比很大，大量的数据计算导致磁盘故障率比较高，每天都有大量的故障磁盘需要更换维修。以前都是通过硬件监控或应用监控发现问题，然后由应用运维工程师登录服务器确认磁盘故障，尝试工具修复。如果修复失败摘掉磁盘，再发起故障报修申请。现在我们研发了磁盘故障自动维修系统，通过平台提供的API接口和监控系统联动，当监控系统发现磁盘故障后，通过回调接口启动磁盘工具进行软修复，修复失败后摘掉磁盘，并在服务管理平台进行记录，自动发起故障报修工单。服务器供应商收到维修工单通知后，根据所提供的机房、机柜、磁盘位置，进行集中更换。更换完成后进行通知，再由系统将磁盘分区格式化挂载，开始提供数据存储服务。
在运维平台建设的过程中，我们借鉴ITIL的思想，但没有完全照搬。ITIL能够帮助IT部门提高用户的满意度和运行效率，但它的实施难度比较大，不能满足互联网运维的敏捷要求。我们希望贴近DevOps的理念，管理和提供准确的运维数据，封装各种灵活的运维工具，让运维工作前置到产品研发阶段，帮助研发、测试人员快速完成产品的发布、测试、上线工作，让运维工具在产品的整个生命周期中联动起来。
平台化不等于自动化，我们的平台更多的是通过流程和标准的保证，提供运维数据的可视化，还算不上真正意义的自动化。我们希望研发和运维人员不再需要关心服务具体部署在哪台服务器、哪个IDC中，由调度系统负责服务运行状态的监控，对资源进行合理的调度、伸缩，对一定范围内的故障进行自动处理，实现真正的运维自动化。
本文转自 tianya1993 51CTO博客，原文链接：http://blog.51cto.com/dreamlinux/1859995，如需转载请自行联系原作者
