vns9848威尼斯城

vns9848威尼斯城

028-85954568

运维职业的迷惘、现状与发展前景

运维岗位不像其它岗位,如研发工程师、测试工程师等,有非常明确的职责定位及职业规划,比较有职业认同感与成就感;而运维工作可能给人的感觉是哪方面都了 解一些,但又都比上专职工程师更精通、感觉平时被关注度比较低(除非线上出现故障),慢慢的大家就会迷惘,对职业发展产生困惑,为什么会有这种现象呢? 除了职业本身特点外,主要还是因为对运维了解不深入、做得不深入导致;其实这个问题其它岗位也会出现,但我发现运维更典型,更容易出现这个问题;
针对这个问题我谈一下网站运维的现状及发展前景(也在思考中,可能不太深入全面,也请大家斧正补充)
运维现状:
1、处于刚起步的初级阶段,各大企业有此专职,但重视或重要承度不高,可替代性强;小企业更多是由其它岗位来兼顾做这一块工作,没有专职,也不可能做得深入。
2、技术层次比较低;主要处于技术探索、积累阶段,没有型成体系化的理念、技术。
3、体力劳动偏大;这个问题主要与第二点有关系,很多事情还是依靠人力进行,没有完成好的提练,对于大规模集群没有成熟的自动化管理方法,在此说明一下,大规模集群与运维工作是息息相关的如果只是百十来台机器,那就没有运维太大的生存空间了。
4、优秀运维人才的极度缺乏;目前各大企业基本上都靠自已培养,这个现状导致行业内运维人才的流动性非常低,非常多好的技术都局限在各大企业内部,如 google 50万台机器科学的管理,或者国内互联企业top 10 的一些运维经验,这些经验是非常有价值的东西并决定了一个企业的核心竞争力;这些问题进而导致业内先进运维技术的流通、贯通、与借签,并最终将限制了运维 发展。
5、很多优秀的运维经验都掌握在大企业手中;这不在于企业的技术实力,而在于大企业的技术规模、海量PV、硬件规模足够大,如baidu可怕的流量、 51.com海量数据~~~~这些因素决定了他们遇到的问题都是其它中/小企业还没有遇到的,或即将遇到。但大企业可能已有很好的解决方案或系统。
发展前景:
1、从行业角度来看,随着中国互联网的高速发展(目前中国网民已跃升为全球第一)、网站规模越来越来大、架构越来越复杂;对专职网站运维工程师、网站架构 师的要求会越来越急迫,特别是对有经验的优秀运维人才需求量大,而且是越老越值钱;目前国内基本上都是选择毕业生培养(限于大企业),培养成本高,而且没 有经验人才加入会导致企业技术更新缓慢、影响企业的技术发展;当然,毕业生也有好处:白纸一张,可塑性强,比较认同并容易融入企业学问。
2、从个人角度,运维工程师技术含量及要求会越来越高,同时也是对企业应用、架构最了解最熟悉的人、越来越得到重视。
3、网站运维将成为一个融合多学科(网络、系统、开发、安全、应用架构、存储等)的综合性技术岗位,给大家提供一个很好的个人能力与技术广度的发展空间。
4、运维工作的相关经验将会变得非常重要,而且也将成为个人的核心竞争力,具备很好的各层面问题的解决能力及方案提供、全局思考能力等。
5、特长发控和兴趣的培养;由于运维岗位所接触的常识面非常广阔,更容易培养或发挥出个人某些方面的特长或爱好,如内核、网络、开发、数据库等方面,可以做得非常深入精通、成为这方面的专家。
6、如果真要以后不想做运维了,转到其它岗位也比较容易,不会有太大的局限性。当然了,你得真正用心去做。
7、技术发展方向、网站/系统架构师。
五、运维关键技术点剖解
1、 大规模集群管理问题
首先大家先要明确集群的概念,集群不是泛指各功能服务器的总合,而是指为了达到某一目的或功能的服务器、硬盘资源的整合(机器数大于两台),对于应用来说 它就是一个整体,目前常规集群可分为:高可用性集群(HA),负载均衡集群(如lvs),分布式储、计算存储集群(DFS,如google gfs ,yahoo hadoop),特定应用集群(某一特定功能服务器组合、如db、cache层等),目前互联网行业主要基于这四种类型;对于前两种类似,如果业务简单、 应用上post操作比较少,可以简单的采用四层交换机解决(如f5),达到服务高可用/负责均衡的作用,对于资源紧张的企业也有一些开源解决办法如 lvs+ha,非常灵活;对于后两种,那就考验企业技术实力及应用特点了,第三种DFS主要应用于海量数据应用上,如邮件、搜索等应用,特别是搜索要求就 更高了,除了简单海量存储,还包括数据挖掘、用户行为分析;如google、yahoo就能保存分析近一年的用户记录数据,而baidu应该少于30天、 soguo就更少了。。。这些对于搜索准备性、及用户体验是至关重要的。
接下来,大家再谈谈如何科学的管理集群,有以下关键几点:
I、监控
主要包括故障监控和性能、流量、负载等状态监控,这些监控关系到集群的健康运行,及潜在问题的及时发现与干预;
a、服务故障、状态监控:主要是对服务器自身、上层应用、关联服务数据交互监控;例如针对前端web server,大家就可以有很多种类型的监控,包括应用端口状态监控,便于及时发现服务器或应用本身是否crash、通过icmp包探测服务器健康状态, 更上层可能还包括应用各频道业务的监控,常用方法是采用面业特征码进行判断,或对重点页面进行签名,以网站被黑篡改(报警、并自动恢复被篡改数据)等等, 这些只是一部份,还有N多监控方式,依应用特点而定,还有一些问题需解决,如集群过大,如何高性能的进行监控也是一个现实问题。
b、其它就是集群状态类的监控或统计,为大家合理管理调优集群提供数据参考、包括服务瓶颈、性能问题、异常流量、攻击等问题。
II、故障管理
a、硬件故障问题;对于成百上千或上万机器的N多集群,服务器死机、硬件故障概率是非常大的,几乎每时每刻都有服务硬件问题,死机、硬盘损坏、电源、内 存、交换机。针对这种情况,大家在设计网站架构时需要充分考虑到这些问题,并将其视为常态;更多的依靠应用的冗余机制来规避这种风险,但给系统工程师足够 宽裕的处理时间。(如google不是号称同时死800台机器,服务不会受到任何影响吗);这就是考验运维工程师及网站架构师功能的地方了,好的设计能达 到google所描述自恢复能力,如gfs,糟糕的设计那就是一台服务器的死机可能会造成大面积服务的连锁故障反映,直接对用户拒绝响应。
b、应用故障问题;可能是某一bug被触发、或某一性能阀值被超越、攻击等情况不一而定,但重要的一点,是要有对这些问题的预防性措施,不能想当然,它不 会出问题,如真出问题了,如何应对? 这需要运维工程师平时做足功夫,包括应急响应速度、故障处理的科学性、备用方案的有效等。
优优科技版权所有,未经允许不得转载
XML 地图 | Sitemap 地图