架构师在运维这一块工作的考量(1-基本运维)

2014 年 12 月 17 日4950

本站主要内容均为原创,转帖需注明出处www.alexclouds.net

        从我的工作经验看,架构师在运维技术管理这一块需要关注的内容还是相当多的,在运维团队的管理上也是要注意技术管理和团队管理并重:

        一、技术管理方面,比如设计管理和监控系统就要考量。

        两点:a、必须确定运维业务功能需求,提升项目质量同时研究项目的可扩展性,为后续运维需求的增加打下基础。在项目的不同发展阶段提供不同技术解决方案并执行;b、研究并评估新技术或者新工具带来的收益,进行内部项目培训和推广;后期根据项目实际发展可预测性的进行项目扩展以及重构设计。

        以上内容在实际工作中需要特别考虑几点:1、兼顾现状,理想设计与现实情况的平衡;2、收益与改造成本兼顾,改造不能太复杂;3、不要忽视简单问题,实际需要调整很多基础设施架构、开发模式等等。

 

       二、管理运维有什么必须的系统?

        运维分两块,一是技术,一是管理。技术是发现、处理,保障运行;管理则时如何分配资源和人力,优化流程,尽快恢复以及未雨绸缪。 而管理上比较流行的是ITTL和ITSM。

         现在流行的系统如CMDB、基础设施服务IAAS管理、文件传输、工作流执行、业务关系管理。

         我们可以简单计为三个系统(下面部分文字也是网上的):

 

         a、设备管理系统CMDB

         供录入机房服务器和网络设备的各种信息,比如机器型号,硬盘大小,OS类型,所属应用,运行状态,机房名称,所在房间,机架,位置等等各种信息,这是一个最基础的数据库,最主要的目的是给每个机器从多个维度统一打上各种标签,方便其他系统的使用。提供各种查询API接口,并做好权限控制。目的是能够被上层的各种系统调用,一般是rest接口,xml接口。然后基于各种语言做相应的封装库。

 

         b、应用性能监控系统:Application Performance Monitor

          统一的数据采集模块,用于采集设备运行信息,包括磁盘IO,网络流量,CPU利用率,网络设备的Session数,PPS。这个采集模块在网络设备上一般可以通过snmp来实现,在服务器上一般通过一个定制化的Agent来实现,这个Agent最基础的能力是采集服务器运行数据,最重要的是能执行各种脚本语言并通过脚本语言实现对服务器的各种操作(如更改配置,分析应用日志并输出结果)。

          监控数据存储与可视化,数据采集模块采集到各种数据会很多,但对事务性没啥要求,可以用各种NoSQL数据库如Hbase,Cassandra等来实现。数据的可视化是一个可以做的很深且偏应用层面的东西,一般在监控系统上只实现最基本的曲线图展示,提供按时段选择和对比的功能,其他复杂的可视化操作通过各种API来实现。

          监控项添加和报警通知,监控项是一种层次结构,而不是列表结构。上层节点的配置能够被下层节点的配置覆盖掉。对网络设备来说监控项就是一些不同的oid。借助于底层的数据采集模块,对服务器来说监控项基本上就是一个脚本。可以分为标准监控项和自定义监控项,标准监控项最大化的通用,实现cpu,内存,磁盘,网络等信息的监控。自定义监控项可以用多种系统管理脚本语言(shell,python,perl)等实现,脚本的输出符合一定规范即可,一般采用行结构或json串。每个监控项设定warn,crit报警阈值和若干报警联系人,阈值一般是数值型,特殊的可以是字符串。超过阈值的监控项会发送报警给联系人,报警可以通过短信,邮件,IM软件发出。报警发送要支持合并报警,频率控制,关闭报警。要不然可能一次小故障就能发出成千上万条报警,报警就失去效果了。
         

         监控Api接口,并做好权限控制。做法和目的与CMDB一样。开放监控数据获取,报警消息发送,配置推送的接口。主要目的是让监控系统里面的数据能够被外界利用,可以在这些数据基础上做更加绚丽复杂的数据可视化工作,或者做一些更加个性化的监控和报警。次要目的是支持对服务器的统一操作,比如公司所有机器统一升级系统软件的版本。建议统一操作的API接口仅对少数几个人开放,并且权限严格控制。

 

        c、发布和线上配置管理系统(ReleaseManager)

         应用发布和依赖库版本管理,应用发布是运维与开发对接的重要环节,一般发布系统会和svn系统紧密结合,svn系统里面会有线上应用的列表,EMDB里面会有各个机器所属的应用。发布系统会用到这些数据,将svn系统里面生成的应用包及其依赖包发布到线上,并且自身对这些应用包和依赖包进行版本管理和控制,在应用发布出现问题时可以回滚到上一个版本。

          线上配置管理,类似于linux下puppet的功能,主要用于应用服务器上关键配置文件的版本控制,分发,一致性维护工作。大应用一般是若干台服务器组成集群提供服务,要求这若干台服务器的应用配置是一致的,但有时候又存在应用的灰度发布操作,或者某人误更改配置。线上配置管理系统要求提供统一的配置修改入口,对灰度发布提供支持,同时对于误更改配置情况进行纠正。执行操作可以借助于Appmonitor的接口。

           以这三个系统为基础也可以做更多的自动化工作,比如说财务人员可以用CMDB里面的数据准确的计算Capex&Opex,机房管理人员可以用EMDB通过OOB远程执行各种关机,重装系统,网络设备维护等工作,不在现场也能管理机器,现场工作可以外包完成。应用开发人员可以通过svn系统调用Releasemanager自主打包,发布,回滚应用。应用维护人员可以调用监控系统获取数据和报警信息,通过编写相关脚本,实现一些简单报警的自动化处理工作,提升效率。

 

         再比如下面简单的要求以供参考,你就能明白基础运维大概做什么:

  • Asset management (where's server with serial number XXXXX?)
  • OS provision
    • PXE installation
    • disk partition
  • monitoring
    • hardware status monitoring (harddisk, RAID card battery etc.)
    • system level monitoring (load, disk IO, disk ops/s, memory usage, packet loss/error)
    • application status monitoring (depend on your application)
  • configuration management
    • system level configuration (hostname, DNS servers, domain name)
    • software deployment (JDK for JVM based applications, Apache installation etc.)
  • Automatic application deployment (allow for auto release and easy rollback)

     

           三、需要运维团队成员的具体的素质

                 

               a、技术能力组成

                     1、code能力,这点非常重要,因为运维工具都需要自已开发,开发语言:c/c++(必备其中之一)、perl、python、php(其中之一)、shell(awk,sed,expect….等),需要有过实际开发经验,否则工作会非常痛苦。

                    2、应用方面需要了解:操作系统(主要是centos、Ubuntu等), webserver相关(nginx,apahe,php,lighttpd)、数据库(mysql,oralce),还有类似系统优化,集群方面的东西。

     
                    3、系统、网络、安全,存储,CDN,DB等需要相当了解,知道其相关原理。

     

              b、社会能力组成:

                    1、沟通和协调能力;ITIL管理每个流程都是需要沟通和协调。比如变更管,产品上线最后一个工序就是要进入到PROD部署。那么如何协调研发和测试资源? 怎样做到合理的安排及变更过程中的井然有序? 这个完全是架构师来驱动各个部门,比如OPS或者说运营工程师加研发生产,这也会影响变更的成败。所以,如果每次变更总是有问题就要找找自己的问题,沟通和协调资源的能力更重要。

                   2、突发故障应急处理能力;具备一定的突发故障的应急处理能力。这个要求比较高,其实,这个能力主要有两个体现:要有一定的技术能力;要有生产线运营经验。而PROD的运维经验是靠血的教训得来,所有的事故或者事件类型的都不重复最好,或者相关类型不重复是最好。

                  3、很好的认知能力;

           好的OPS以客户为导向,要做的事情就是快速恢复服务,后续排查问题。这个看得简单,其实很难做到尽善尽美。

     

  • 0 0