资产管理平台是记录和管理企业IT架构中各种设备配置的信息平台。
在系统工作中，它与所有服务支持和服务交付流程都紧密相关，最大价值是支撑流程的运转。同时又依靠流程关联来保证数据的准确性。对上层服务管理平台，能通过API提供数据查询能力，如设备的硬件配置、机架位等信息；同时也提供服务器的重启、报修和系统重装等接口。
系统运维的早期阶段，主要是用Excel记录各种信息，用邮件来做各种流程审批。
随着业务的快速发展，设备数量爆发式增长，系统工作中的配置变更越来越频繁，信息遗漏变得非常严重，不断产生脏数据，已经不具备准确性和可用性。
同时对上层系统的查询需求也无法响应，这种靠Excel维护信息的方式已经不再适用。
我们开始在资产管理平台研发上投入专门的人力，并和工作流程强关联起来，通过流程保证资产平台数据的准确性。资产管理数据的准确性和功能完备性决定了整个系统运维的自动化程度。因此，要支撑公司不断增长的服务器运营，首先需要建立和维护一套基础架构的资产管理平台。
资产管理平台主要规划了配置管理、预算系统、故障管理和自助系统四大部分，如图7-1所示。
图7-1 资产管理平台规划的四大部分
业务通过预算系统提交服务器申请，系统工程师通过配置管理平台录入服务器信息，再通过API的形式将服务器信息同步给服务管理平台。
业务运维工程师可以通过调用自助系统对服务器进行重启、重装等操作。当服务器发生故障时，服务管理平台将服务器标记为故障节点，通过API的形式将服务器故障信息同步到故障管理平台进行维修，维修完成后故障管理平台也通过API将信息同步给服务管理平台。
当服务器要归还时，服务管理平台清除相关信息，通过API的形式将服务器同步给资产管理平台。
“
配置管理
”配置管理一直被认为是ITIL服务管理的核心，因此在系统运维中也是核心部分，它在结构上处于最底层。
为什么说配置管理的作用是核心的？举个例子。某服务器已经到了报废期，我们需要下架这台服务器，需要有系统记录这台服务器的数据中心、机架等属性，也需要记录这台服务器的硬件信息，依靠这些信息才能找到这台服务器。
但仅有这些信息还不够，仍需要知道这台服务器的使用者（即业务归属），通知其业务方将业务下线，确认下线后，需要再通知数据中心现场人员下架服务器，同时还需要释放服务器相关的其他资源，比如IP地址、ACL配置、LVS配置等，这一系列信息都需要由配置管理系统来维护和保存。因此可以看到，配置管理是一项非常重要又多信息关联的系统工作。
早期我们同样是用Excel记录数据中心、服务器（资产编号、参数、采购时间、供应商）、配件、网络设备、IP地址、ACL等信息。
随着设备数量的增加，配置变更频繁，又没有统一上线和变更流程，经常出现记录和实际有差别。比如服务器机架信息核对不上，设备实际用途和记录不符，甚至服务器下架了IP地址却没有释放，导致IP地址占用和冲突等问题。
通过配置管理系统的研发，强化了这些资产和配置信息的管理，准确度有显著提高，系统工作以及与外部系统的自动化联动开始向前发展。
在配置管理系统中，我们将各类信息管理定义成小的功能模块，通过API接口串联起来，实现灵活有序的方式管理各类资源。在机柜管理上开发机柜视图功能，把服务器的机架信息、位置占用等录入系统，在系统中可以非常直观地了解服务器的摆放情况、整体机柜使用率。
设备上线前由系统自动分配摆放位置，设备下线后自动释放资源，从而减少了手动分配的工作量。机柜管理还有一些高级功能，在网络规划中按照安全级别划分出了基础服务、普通业务和安全隔离三个区域，系统会按照设定的分配规则给不同的服务器分配不同区域的机柜。
比如，Hadoop等分布式业务对机架摆放有特殊要求，太分散不利于数据节点间的数据同步，太集中冗余度又不够，这些特别的需求都有特殊的分配策略。
通过定期扫描机柜使用率，可以及时调整和关闭空闲机柜，从而避免浪费。开发的iHealth具有运行功率实时监控功能，可以从服务器监控中采集电流信息，能统计出整个机柜的电量使用，进行机柜的超电预警。
在IP管理系统中，把内网、公网、VIP、管理卡都分别设定了不同的IP池，根据类型、机柜、业务的不同，通过管理接口分配和回收IP地址，从而减少了工程师手动分配和回收IP资源的烦琐工作，进一步保证了IP资源管理的准确性。IP管理和ACL管理等模块都有关联功能，在IP地址释放前都会查询并释放相应的ACL记录。
为每台设备设定一个唯一序号，作为主键使用，确保设备的唯一性标识。服务器在记录中的占比最大，网络设备其次。
在虚拟化部分中虚拟机也有唯一性标识，并和底层的物理服务器有关联记录，可以快速地查询物理服务器上承载了哪些虚拟机。和虚拟化部分有API关联，虚拟机的飘移会实时地更新记录。
为每台设备粘贴了对应的序号二维码标签。在收货、上下架、资产管理、设备报修等环节，通过扫描二维码的方式进行信息的变更和查询，极大地提高了设备管理的效率和准确性。二维码系统设有权限管理，比如现场的维修人员和系统管理员获取的信息量是不同的，主要是出于安全考虑。
经常会遇到IP地址随着服务器下线释放，但ACL没有及时清理的问题，久而久之，积累的ACL记录很容易达到设备的上限，存在一定的安全隐患。
我们遇到过一个真实的安全案例，两个区域隔离的交换机由于设备BUG的问题，在ACL条目达到上限后并没有任何错误提示，还可以添加ACL记录，但原有的ACL记录完全失效，导致两个区域的隔离失效，带来了安全问题。
随后我们上线了ACL管理功能，业务通过系统发起ACL申请，完成审批后由工程师进行变更操作；ACL和IP资源联动，及时清理无效的ACL记录；对ACL记录匹配次数进行监控，对于长期未使用的记录进行人工检查和清理。同时，我们提供API接口，安全人员通过接口获取ACL记录信息，扫描验证ACL记录的有效性。
“
预算系统
”在早期运维中，设备采购数量少，申请采购主要依赖邮件审批的模式。系统组负责整理汇总各个需求邮件，再进行统一采购上架，流程非常烦琐，而且容易有遗漏的地方。采购的进度也不透明，业务线无法及时获知进度。
为了简化和规范设备采购的方式，我们上线了预算系统，该系统作为设备资源的唯一入口，包括服务器、网络设备、配件等。
对于服务器资源，支持实体机、基于OpenStack的私有云、公有云以及整机租赁等多种资源的申请。私有云和公有云等通过调用API创建虚拟机，同步录入管理系统；对于租赁的实体服务器通过API下单；自购的服务器先从资产管理系统查询是否有满足需求的备机资源，如果没有再发起采购。
预算系统和监控系统的资源利用率对接，为业务申请采购服务器提供数据说明。当业务运维在采购管理系统发申请之后，审批人根据已有的资源使用情况来审核申请的合理性。
“
故障管理系统
”随着服务器数量的增多，每天发生故障的服务器的数量也呈线性增长。早期系统工程师需要逐台定位服务器故障原因，和业务部门沟通停机时间以及跟进供应商的报修，效率非常低下，业务部门也常常因为故障服务器维修周期长而增加烦恼。为了改善故障持续增长造成的维修效率低下，开发了故障管理系统。
通过监控插件来上报故障信息，并完善插件使输出的故障信息详细、准确，能直接将信息发给数据中心现场或供应商来解决，比如磁盘故障会定位到槽位等。
通过服务管理平台将收集到的监控插件上报的数据信息展示在页面中，相应的负责人可以查询到自己的服务器故障信息，在负责人确认服务停止之后直接点报修。
故障管理系统通过API和服务管理平台同步故障信息， 系统汇总整理后通过邮件或对接的API分别发送给供应商和数据中心现场。由于邮件中有供应商和数据中心维修需要的各类信息，所以基本上普通故障在两个工作日内就能修复，修复好后也无须人工确认，监控上报信息中自然会消除相应的故障信息。
如有需要手工干预的操作，也会通过监控系统体现出来，比如磁盘需要重新挂载和格式化等。故障都消失后，更改设备状态，即可交付给业务。故障管理系统大大提高了报修的效率，也提高了硬件监控的准确性和有效性，为线上服务的稳定运行提供了底层支持。
故障管理系统建设的上下游是应用运维和供应商，需要大家一起来协调工作，为了配合默契，一起约定梳理了一些标准。
① 故障信息的描述 早期报障需要应用运维人员填写描述信息，不统一、不标准，对诊断和定位故障影响较大。后来约定的方案是先将常见故障分类，实现自动化采集并分类。开发了监控和识别的程序，自动发现和告警给应用运维，由他们判断是否需要报障维修。针对常见故障以外的案例，通过人工分析和识别重新定义到故障类型中。
② 维修前是否要和应用运维确认 早期在维修服务器前要和业务沟通好时间，业务停止服务后再修，花在沟通和跟进进度上的时间非常多。维修前需要确认停服的根本原因是维修的周期较长，很多时候故障服务器仅仅是在排队维修，而这类服务器依然可以正常工作，所以业务方希望仅仅是在维修的时候再暂停服务。
后来达成共识，应用运维要停完服务后提交报障，系统组承诺在一定时间内修复完毕，若是无法完成，需要提供备机。当然，由于承诺了对不同故障类型的响应和维修时间，也就无须反馈维修进度，应用运维也不会再询问，大大减少了沟通时间。
③ 和供应商定义诊断方式和处理机制 早期对于服务器故障定位都是系统组人员和供应商的工程师一起完成的，无法自动化，后来和供应商沟通，让其提供各类故障定位工具，并将相应的日志作为更换配件的标准，也和供应商对不同级别的故障响应和处理时间达成一致，方便批量报修。
“
自助系统
”为了更方便地对服务器进行操作，开发建设了一些自助系统，主要有以下功能。
① 自助查询功能 当交换机发生故障或有计划割接时，可以通过交换机维度查询到同一接入交换机的所有服务器列表，从而达到快速的通告效果。业务线可以通过自助查询页面批量输入主机名查询服务器在数据中心中的分布情况，为业务的冗余性部署做准备。还可以通过源IP地址和目的IP地址查询ACL规则等。
② 自助重装、重启功能 在系统运维平台中开发了自动重装和重启功能，逐步地开放给了应用运维，应用运维在工作平台中可以直接调用API完成OS重装工作。发生故障时可以自助地重启、停机，提高了应用运维对故障的响应时间，也避免了系统工程师的重复性机械工作。
③ 屏幕截图功能 程序异常时可能导致kernel panic，在这种情况下一般需要系统运维登录管理卡查看服务器屏幕状态并截图给业务定位故障。后来开发了屏幕截图功能，并通过API给服务管理平台使用，业务运维只要在网页中点击按钮就能看到服务器的屏幕截图，如图7-2所示。
图7-2 自助服务器屏幕截图功能
通过资产管理系统的建设，资产和配置的准确性得到了有效保障，系统运维的效率大幅提升，系统日常运维走出了依靠人工信息维护的初级阶段。
