网站业务开发工程师眼中的运维管理

时间 : 15-10-13 栏目 : 提升软实力 作者 : 老薛 评论 : 0 点击 : 717 次

1. 运维是什么?
        运维不是打杂的,运维不是客服,运维也不是服务开发的,但要做好合作。运维服务于整个产品,保证架构合理,系统稳定。运维只对业务稳定负责,所有的工作都是奔着这个去的。程序是为了完成特定的功能。为了完成特定的功能,程序需要申请资源、使用资源、管理资源,功能完成后,还要释放资源。说到底,就是跟资源打交道,和资源打交道的工具是“编程语言”。资源包括什么?内存、CPU、磁盘、网络、文件描述符、外部API、缓存、数据库等,编程语言是如何管理资源的、合理的算法/架构保证了资源的合理使用,malloc/free分配内存、connec、close使用网络等等。

2. 如何写出好程序?
     什么样的程序不出错?代码少的程序错误少,逻辑简单的程序错误少,需要管理的资源少的程序错误少。要复用代码,减少代码的数量。要抽象,分层,内聚,解藕,简化逻辑,隔离资源,才能简化逻辑,隔离资源,限制错误。没有持久状态的程序好扩展,没有持久状态意味着上下线机器不需要迁移数据。没有状态的程序也很容易做HA方案。配置简单,日志丰富,能提供程序状态查询的程序好运维。但程序不可能没有数据,通过集中管理数据库,让数据尽量只读,预加载数据等手段隔离逻辑和数据,也能让扩展变的容易。

3. 系统是什么?

    系统是我们运维的目标,不了解系统是什么,就不知道如何运维。

    系统是网络,是机器,是程序。是把网络,机器,程序组织起来的架构。
    机器角色应该是尽量单一的,架构应该是数据流简单的,基础业务服务化的。
    系统是动态的,运维系统首先考虑的不是当下成本,而是系统变更(扩容,上下线机器)的成本。
    运维必需是简单的,要考虑的一个新手,如何能尽快上手工作,而不是冗长的文档和复杂的培训。
    写程序和做运维是类似的,甚至一样的!程序提供单一功能,而运维搭建,维护的系统提供全部的功能,开发人员开发的程序只是整个  系统的一个部分。    
    从某个角度说,开发人员做的事情越少,系统越容易稳定,因为开源的总是更靠谱。这是减少代码,也是复用。
    但运维却理应比开发更不容易犯错,因为运维只需要管理资源,而不需要应对复杂的业务逻辑。
    这是个矛盾,因为开发负责的复杂业务逻辑,是运维负责的系统的一部分,前者不稳定,后者也别想消停。

   
所以运维不懂开发,至少要懂如何控制复杂度,如何隔离故障,如何服务降级。出色的运维人员,只要精通一门语言,必然也是出色的开发(反之亦然)。但什么是
出色的运维呢?

    大部 分运维人员,只是一个熟练的操作工人。出色的运维必然更了解系统(原理),这要读很多书,做很多思考,有很多实践。

    只看这个cat bigfile.txt | parallel --pipe wc -l | awk '{s+=$1} END {print s}'你能不能想出parallel加速的原理是什么?

 
4. 你是否了解你运维的资源?
     CPU高意味着什么?你是不是应该先问问是sys,user,iowait这三个的哪个高?是单个CPU高,还是整体都搞?你是否了解有的程序CPU使用率90%就有问题了,而有的350%了还没问题?load高意味着cpu高吗?内存耗尽导致load高的原理是什么?内存耗尽回导致IO高吗?

5. 资源是否一定对应硬件?

    CPU,内存,磁盘,带宽都有对应的硬件,那些没有硬件对应的资源呢?文件描述符,端口数,进程数是不是资源?
    路由表,iptables,cron是不是资源?MySQL主从,第三方REST接口是不是资源?

6. 运维原则:
     线上变更必需走配置管理。线上系统对任何人应该是只读的,只有配置管理程序有权写。这样保证了,变更是可重复的,可复制的。手工加路由,手工修改文件权限,
手工配置ip,手工配置nfs,手工起虚拟机等等。一切在线上手工做的操作,于团队都是无益的,因为团队失去了一次改进配置管理的机会。任何操作不是想我就这一台机器,而是想我有1000台机器怎么办。
    上线业务必需先问,如何保证HA,如何扩展,如何运维/监控。这三个问题不解决,谨慎上线,当然上线必需使用配置管理上线。隔离复杂度,要简化,抽象。抽象指角色抽象。运维眼中没有计数用的mc,和缓存用的mc,运维眼中只有mc,于是所有的mc都来自mc池,mc池通过puppet配置,创建mc的过程编程了简单的puppet配置。一旦把自己管理的所有业务抽象/分拆为几种有限的“业
务”,缓存、mysql、httpd等,一切就简单了。例如我们有缓存池、数据库池、redis池、httpd池。先解决问题,然后是以后如何避免此类问
题,后者更重要。
     不犯第三次错误(重复的问题不出现第三次)。第一次算不知道,第二次算不小心,第三次特么是故意的吧。如果每个问题都能彻底有效解决(最终落实到配置变更和监控),问题就会越来越少。时刻思考如何“偷懒”,运维越清闲,系统越稳定。
    ITSM在运维服务方面积累了丰富的行业经验,成熟ITSM工具平台。系统可以配合运维管理让掌握不同专业技能的工程师充分发挥各自的技能特长,各尽其责,CMDB可把资产从“横向,纵向”的深入精细化管理...最终在KPI报表中展现统计运维工程师的工作量,统计运维服务及时率、分析用户满意度
等。

本文标签

除非注明,文章均为( 老薛 )原创,转载请保留链接: http://www.bdkyr.com/softpower/1047.html

网站业务开发工程师眼中的运维管理:等您坐沙发呢!

发表评论

1 + 7 = ?


博主微信号,很高兴为您提供帮助

随便看看

0