互联网时代运维价值的重塑(2)

单服务器采购这一块涉及到的东西又很多,供应商管理、资源评估与规划、成本管理等.生产这一块可理解为把金属物体变成对业务可用的OS资源,服务器从出厂到上架到灌OS再到软环境的标准初始化等等,这一块在海量业务需求下对产能、资源供应效率的要求很高,传统的手动安装方式当然满足不了,于是IDC的同学要考虑批量快速生产的方案如kickstart,本人接触最高产能的部署系统是每小时部署5000台物理服务器OS,当然随着虚拟化云技术的应用,彻底改变了传统的基础架构资源生产和配置方式.调配这一块也是需要IDC同学去考虑的重点,如何管理业务需求,如何分配服务器资源,如何管理信息,服务器资源的调度等,站在更高的层面来说这一块就是如何灵活调度资源来满足业务需求,且能合理利用与控制成本,以下措施可以一试：

??? 维护这块是基本工作,其中涉及的处理流程、技术细节与硬件设备本身关系很大,本人接触到的dell/hp/ibm/Lenovo/华赛等各厂商的在用主流型号服务器达100多款,日常维护这块的工作量很大,作为IDC的同学当然也要从思路、平台等方面去优化,比如建立带外网络集中维护和管理、基于日志的自动分析和报障、事件与问题管理等等.资源回收与资源分配是同等重要的环节,宗旨是能做到有需求时放、无需求时收,这块要考虑的是如何对资源利用状态的监管,如何快速回收,弹性伸缩.以上只是大概说了服务器资源管理这条链的内部闭环流程.实际上在职能团队内部,类似的业务支撑流程很多很多.这些流程内部往往需要运维人员去考虑管理思路、实施技术、综合解决方案等多方面.外部闭环体现在多团队之间的工作协作上了,拿一个例子来说：某游戏产品需求在国内搭建一个大区,这个就需要运维多个团队来协作了,简化的流程如下：

• 业务运维团队进行环境的设计,依据网络覆盖质量数据和用户分布数据,选址服务端该放到哪个地区、哪个运营商.依据性能测试数据和用户量预估数据来确定需要多少机器资源和带宽资源；资源需求提交给基础架构团队.
• IDC资源团队根据提交的需求进行资源的匹配,或调度或采购或其他方式来保障资源的按时到位.
• SA团队进行资源的生产,可能是利用工具平台完成指定OS的部署,深度加工并配置,最后进行标准的初始化操作,交付给业务运维团队.
• 业务运维团队分发并部署应用,当然其中设计到的部署方案、实施技术、性能评估等每个环节均需要细致考量.
• 监控团队部署监控环境,完成对OS层面、业务层面各项指标的实时监控展现.
• 安全团队需要规范OS层面、软件应用层面的安全基线,并实时监测线上应用的安全状况.

流程的整合,需要看每个企业内部运维的职能团队、工作界面划分以及承载的业务逻辑,尤其对于全业务运维的团队,流程的制定很重要.一个好的流程,既要合理又要尽量简单,较大的运维团队要明确的一点是：保障一切正常运转的是规范的流程,而不是个人.

3.?? 自动化实施

老话题了,对于业务量稍微上来、网络与服务器规模稍大一些的企业,都已经意识到这点的重要性.运维不做自动化,生活不会幸福.关键是怎么做,如何整体规划并大方向布局,见过很多运维自动化的实施方案,涉及运维工作中的各类场景.自动化实现方面大概有三个层次：

• 一是脚本阶段,依靠运维自行编写shell、bat、perl等各种脚本去完成自动任务执行,批量处理,功能封装的好的话,用起来也挺省心省力.这种方式在管理规模较小的环境时没太多问题,但对于成千上万机器规模,或处理逻辑较复杂的情况时,显得鸡肋了.
• 二是依托ITIL理论建立起来的适应运维各种业务逻辑的自动化系统和工具,这也许是当前绝大多数互联网企业采用的方式.整个基础架构和业务运维这块盘子,从IT管理的角度来做运维,并结合实际状况寻找最佳实践,如做信息管理我们需要CMDB,CMDB主要用来管理线上线下信息的对称性和准确性,在此基础上给其他各类业务系统提供一致的数据输入；做事件管理我们需要事件管理系统；还有需求管理这块,给内部和外部提供统一的需求入口；还可能有作业平台,帮忙业务运维团队自动化完成相关运维任务,此外安全、监控等等众多的垂直型功能系统.这些自动化的系统确实能很好的帮忙运维去掉重复单调的工作、减轻日常工作负担,并能量化工作和为优化质量指标提供数据支撑.但多数企业在实施这些自动化系统中,往往是缺什么补什么,整个自动化的实现分散在多个独立的系统中,且可能没有接口,数据不能互通,需要运维人员人工对接多个系统来完成某个运维场景的自动化实施.如一个发布任务,可能需要先到需求系统打开电子流,根据里面的信息去仓库系统拉取版本,然后去分发系统分发版本,去监控系统屏蔽告警,然后去发布系统做相应的操作等等.这类垂直功能的相互独立的自动化系统确实能帮助运维人员解决很大一部分问题,在效率上有很大提升,使得运维的工作基本全部实现线上化.但这够吗?可以想象拥有百万机器,数万款线上应用的规模,这种方式还有待优化.
• 三是智能化的整合平台,这类运维自动化的平台目前接触到的只有腾讯蓝鲸了,它是一个横向的PAAS平台,为游戏运维领域提供了整套统一的解决方案,基于平台,运维可以自由定制需要的工具,可按各种运维场景实现一键式作业,前端几乎可适应任何业务,后端支持的自动化操作几乎涵盖所有,运维人员需要做的不是运维,而是任务设计.

自动化的建设水平在行业内差异化还是明显的,如果处于运维自动化刚起步的阶段,那么本人的建议是：从整体上规划,基于ESB思想尽量让平台与业务逻辑解耦.

如上所示,我们先抛开基础架构侧的自动化不论,对于业务运维而言,整个工作面无非就是对业务运营环境的各种操作、配置,已经对业务应用程序的管理,简单来说就是OS层和应用层,要做自动化实施首先得有准确对称的数据,然后需要一个统一的管控平台,能并发的控制和操作远程大量主机,这解决了OS层面的操作问题,但需要管理应用层面的东西及需要与应用的研发人员确认相应的接口,对于开源组件而言一般不会有什么问题.因此如果是从零开始做自动化,个人认为CMDB、管控平台、业务管理工具这三部分是地基.在此基础之上,可以针对运维各类场景和业务逻辑去做相应的垂直功能系统,再上一层,可以使用流程引擎之类的组件来实现业务运维流程的纵向整合,最终实现运维场景化一键式作业.

运维自动化的宗旨是把运维人员的专业经验和技术知识转化为工具,让工具去做事情,让人去享受生活.

4.?? 标准交付

（编辑：ASP站长网）