当前位置:首页 > 运维
  • 千人千面的运维,表里如一的体验——华为智能运维服务,用能力定义场景化运维

    一台计算机:装进大机箱里的叫台式机;扩展性好,性能高。放在小机壳里叫笔记本;更具便携性,满足多种场景。放在加固手提箱里叫三防电脑;能够适应恶劣工况,皮实耐用。面对同一种事物的形态变换,人们总会半开玩笑的说“科技以换壳为本”。的确,为了让设备适应不同的应用场景,人们总在不断的改变产品的形态;同样的本质,加一个模块或变一种外形,适用场景就完全不一样。从应用角度来说,这种形态的变换是技术为人和场景服务的具体展现。IT架构多变幻,运维更是通过“换壳”来提升技术的适应性是一种常见的现象,而伴随企业级硬件产品开始强调应用体验和贴近业务,类似的产品变化思路也开始在企业级市场大行其道。不过运维类产品的发展节奏却始终遵循着以设备为核心的思路。换句话说,多数运维类产品看上去并没有本质变化;任你东南西北风,我自岿然不动。造成这一结果,并非是厂商技术不行或思想滑坡,也绝非IT运维没有场景化需求。恰恰相反,相对于已经充分细分的IT硬件,运维管理与业务的相关度其实更大,更需进行场景化革新。但也正是由于运维与业务相关度太高,以至于每个行业,甚至每个企业都有着对运维系统的独特要求。以机场的IT运维需求为例:机场不仅有容纳各类计算、存储、网络设备的数据中心和机房,更有遍布机场当中的各类显示屏和终端;这些设备不仅要实时显示航班动态和各类指引信息,更需要具备与客票及其他系统对接,实现各类交互功能。再比如,相对于企业的办公室或园区网环境而言,机场的网络情况更为复杂;不仅要对旅客和办公需求提供有线、无线网络,更要为各种显示终端、交互终端、语音通讯、物联网设备提供不同协议、不同覆盖范围、不同安全级别的网络支持,涉及上网、物流、地面管理、起降管理等众多完全不同的业务类型。如果按照运维类产品的通常逻辑,为机场这样的多系统、海量设备、高级别运维定制解决方案不仅需要庞杂的模块整合和接口对接,更需要极高的开发及部署成本,很多企业运维就会使用庞大的运维团队,这样更具“性价比”且风险更低的方式太过庞杂的需求使得IT厂商无法针对多种场景推出针对性运维方案,很多运维方案也因此一直停留在“上个时代”。那么,IT运维就真的与场景化无缘了吗?非也!为深圳宝安国际机场定义运维新基线深圳宝安国际机场是全国排名前三的超大规模客货混用机场,年吞客运吞吐量超4000万人次,拥有三条跑道、四座航站楼。而在IT层面,深圳机场则拥有200 间机房、11张不同功能的网络,25000台各类终端设备,运行着40多种不同的IT设备和140多种业务应用。面对航空客货运对业务可靠性的高标准、庞大的设备数量、繁杂的业务应用、新老交错的各类技术架构;运维压力可想而知。深圳机场采用基于华为神农统一运维平台IMOC的华为智能运维服务,能有效进行业务海量设备和复杂业务的管理。华为智能运维服务包含了由监管、配置及资产管理、运维操作自动化、运维分析可视化、运维流程管理等五大功能,而每种功能又细化成为N种不同的管理工具。无论是大的功能模块还是功能之下的子模块全部采用松耦合架构设计,可根据用户的实际需求随意选取组合。同时,携手伙伴,也对各主流行业应用做到了预集成和接口预留;由此,在面对综合应用的海量业务时,华为IMOC也能方便的实现网管/平台预集成、网管/平台对接收编、第三方框架集成、主动拨测/预制探针等对接工作,大幅降低了用户的部署周期和部署成本。而对于深圳机场在运维需求、运维逻辑上的不同侧重,华为及海量生态伙伴则通过IMOC平台预制的各种模板实现了对业务逻辑的快速构建、部署。同时,华为还在运维流程优化的基础上提供了多种智能化的运维工具,并为深圳机场的运维团队提供了各类专业培训,以便他们能够高效、正确的使用工具,做到更高标准的运维和更快速的事件响应。在IMOC运维平台、业务流程优化、高水平运维团队、专家远程支持等的加持下,华为、生态伙伴及深圳机场共同定义了机场ICT系统运维的四级保障体系,并为每个级别定义了不同的工作内容和运维标准。深圳机场不仅可以避免了ICT系统出现重大故障、降低了一般性故障的发生概率,更实现了对关键运维事件的“5分钟处置”。懂行才能好用参与深圳宝安国际机场运维升级改造这样的大型工程,是华为及其生态的荣誉,更是对华为智能运维服务的一种肯定。而能够最终满足用户的高标准运维需求,华为及生态靠的则是模块化的先进理念和对机场运维需求的深刻理解。简单来说,就是“懂行”。坐过飞机的人不少,但懂得机场ICT运维的人却不多。要做到对机场和千行百业的运维需求认知,单靠华为自己显然是力所不能及的。因此,华为的“懂行”更多是来自海量合作伙伴的经验和对伙伴价值的重视。而伴随华为生态圈层和数量的持续快速增加,华为也才能够实现以ICT产品技术服务千行百业、万种业务。其实,亟待运维升级的远不止机场或交通行业,但有了懂行的华为及生态、和以模块化构建千变万化的智能运维服务,更多行业便能够通过运维升级实现更高标准的业务和更具效率的运营。

    时间:2021-07-07 关键词: 华为 运维

  • 助力能源行业IT运维,向日葵携手壳牌能源集团打造IT远程运维方案

    石油有“黑金”的美誉,在现代社会生活,石油制品几乎可以说无处不在,其中最为重要的,恐怕就数汽油、柴油这类的能源产品了。 而作为销售这类能源产品的最小机构单位,加油站目前已经是一项重要的城市基础设施了。而由于加油站往往内分布广泛,对于加油站所属的能源企业来说,如何通过有效的管理与运维手段保障分支加油站能够持续稳定的运营就成为了关键,这之中IT运维是重要的因素之一。 毕竟在这个信息时代,没有企业和机构能放弃信息化带来的高效与便利,加油站也一样。 大型能源企业也有IT烦恼 作为石化能源行业的知名企业,“壳牌能源集团”在这方面具有相当大的发言权。在实际的业务运营中,该企业的相关人员发现,实现高效的IT运维,有效串联企业内部机房服务器,企业总部的办公设备以及外延加油站点的收银机这类IT设备并非易事,传统的运维方式主要存在下列瓶颈: 第一,运维时效性要求难以满足。下属加油站地理位置分散,不可能为每个站点派驻运维人员,当运维需求发生后,需要等待工程师前往具体的站点实施运维,短则数小时长则一两天,运维的时效性要求得不到满足,容易影响日常的经营。 第二,运维工作缺乏统一协调的管理手段。传统的运维方式缺乏有效协调的管理手段,管理层掌握运维工作的进行情况依赖于层层上报,并且对于一线的设备也缺乏直接的监控手段。 携手国产方案打造远程运维体系 为了解决上述两点问题,壳牌能源集团决定携手贝锐旗下国产专业远程控制品牌“向日葵”,引入远程IT运维解决方案作为传统运维手段的补充,通过优化IT运维环节实现“降本增效”,为其基本业务流转提供数字化保障。 在具体的方案实施层面,壳牌能源集团选择了向日葵针对企业IT运维场景所推出的“掌控”方案,选择了其中的“掌控·行业版”级别服务,并且部署了多通道用于满足并发的远程IT运维需求。 针对性功能配置强化远程运维赋能效应 在方案落地后,该企业总部IT运维人员在面对运维需求时可以通过向日葵远程控制远程连接前方设备实施运维,大大提升了IT运维的时效性,同时避免了事无巨细都需要派出工程师现场处理所造成的资源浪费。 除了用于远程运维部署在加油站的IT设备,该方案同样也被运用在企业内部的机房服务器运维、办公设备运维等方面,可以说是向日葵掌控方案为壳牌能源集团搭建了一个整体性的远程IT运维解决方案框架。 此外,针对不同的运维人员负责不同种类设备,具有相对差异化的远程需求的情况,壳牌能源集团使用了向日葵掌控方案的软件定制功能,针对不同的需求为一线运维人员定制了定制包,用于维护各自的设备,实现了更加精细化的远程运维。 上图为向日葵后台软件定制界面,针对不同的运维需求可支持多系统平台软件定制 而在IT运维管理层面,壳牌能源集团作为一家规模庞大的企业,在这方面拥有强烈的需求,而“向日葵掌控”方案搭载的包括可统一管理的帐号体系、IT资产管理等功能有效的满足了他们的管理需求,从IT运维的层面实现了进一步为整体主线业务赋能。 写在最后 在探访这个远程运维典型案例的最后,该企业的相关人员告诉笔者,他们内部对于向日葵方案的实际表现十分满意。原先进行运维工作时也会使用一些远程手段,但之前所采用的外国远程软件并不如“向日葵掌控”方案针对性的设计,而且随着国产软件厂商实力的提升,他们也更加愿意采购功能搭载完善,对具体的运维场景有一些针对性设计,同时性价比也更高国产的解决方案,这也是壳牌能源集团选择引入向日葵的其中一个考量因素。 随着我国信息化技术的不断提升,我们有理由相信会有越来越多类似“向日葵掌控”这样优质的国产方案活跃在各个领域,在整个社会逐渐实现信息化的大潮中,类似的软件解决方案作为“软基建”,势必会发挥重大的作用。

    时间:2021-06-15 关键词: 远程控制 IT 运维

  • 华为智能运维服务,用能力定义场景化运维

    一台计算机: 装进大机箱里的叫台式机;扩展性好,性能高。 放在小机壳里叫笔记本;更具便携性,满足多种场景。 放在加固手提箱里叫三防电脑;能够适应恶劣工况,皮实耐用。 面对同一种事物的形态变换,人们总会半开玩笑的说“科技以换壳为本”。的确,为了让设备适应不同的应用场景,人们总在不断的改变产品的形态;同样的本质,加一个模块或变一种外形,适用场景就完全不一样。 从应用角度来说,这种形态的变换是技术为人和场景服务的具体展现。 IT架构多变幻,运维更是 通过“换壳”来提升技术的适应性是一种常见的现象,而伴随企业级硬件产品开始强调应用体验和贴近业务,类似的产品变化思路也开始在企业级市场大行其道。不过运维类产品的发展节奏却始终遵循着以设备为核心的思路。换句话说,多数运维类产品看上去并没有本质变化;任你东南西北风,我自岿然不动。 造成这一结果,并非是厂商技术不行或思想滑坡,也绝非IT运维没有场景化需求。恰恰相反,相对于已经充分细分的IT硬件,运维管理与业务的相关度其实更大,更需进行场景化革新。但也正是由于运维与业务相关度太高,以至于每个行业,甚至每个企业都有着对运维系统的独特要求。 以机场的IT运维需求为例: 机场不仅有容纳各类计算、存储、网络设备的数据中心和机房,更有遍布机场当中的各类显示屏和终端;这些设备不仅要实时显示航班动态和各类指引信息,更需要具备与客票及其他系统对接,实现各类交互功能。 再比如,相对于企业的办公室或园区网环境而言,机场的网络情况更为复杂;不仅要对旅客和办公需求提供有线、无线网络,更要为各种显示终端、交互终端、语音通讯、物联网设备提供不同协议、不同覆盖范围、不同安全级别的网络支持,涉及上网、物流、地面管理、起降管理等众多完全不同的业务类型。 如果按照运维类产品的通常逻辑,为机场这样的多系统、海量设备、高级别运维定制解决方案不仅需要庞杂的模块整合和接口对接,更需要极高的开发及部署成本,很多企业运维就会使用庞大的运维团队,这样更具“性价比”且风险更低的方式 太过庞杂的需求使得IT厂商无法针对多种场景推出针对性运维方案,很多运维方案也因此一直停留在“上个时代”。那么,IT运维就真的与场景化无缘了吗? 非也! 为深圳宝安国际机场定义运维新基线 深圳宝安国际机场是全国排名前三的超大规模客货混用机场,年吞客运吞吐量超4000万人次,拥有三条跑道、四座航站楼。而在IT层面,深圳机场则拥有200+间机房、11张不同功能的网络,25000台各类终端设备,运行着40多种不同的IT设备和140多种业务应用。面对航空客货运对业务可靠性的高标准、庞大的设备数量、繁杂的业务应用、新老交错的各类技术架构;运维压力可想而知。 深圳机场采用基于华为神农统一运维平台IMOC的华为智能运维服务,能有效进行业务海量设备和复杂业务的管理。 华为智能运维服务包含了由监管、配置及资产管理、运维操作自动化、运维分析可视化、运维流程管理等五大功能,而每种功能又细化成为N种不同的管理工具。无论是大的功能模块还是功能之下的子模块全部采用松耦合架构设计,可根据用户的实际需求随意选取组合。 同时,携手伙伴,也对各主流行业应用做到了预集成和接口预留;由此,在面对综合应用的海量业务时,华为IMOC也能方便的实现网管/平台预集成、网管/平台对接收编、第三方框架集成、主动拨测/预制探针等对接工作,大幅降低了用户的部署周期和部署成本。 而对于深圳机场在运维需求、运维逻辑上的不同侧重,华为及海量生态伙伴则通过IMOC平台预制的各种模板实现了对业务逻辑的快速构建、部署。同时,华为还在运维流程优化的基础上提供了多种智能化的运维工具,并为深圳机场的运维团队提供了各类专业培训,以便他们能够高效、正确的使用工具,做到更高标准的运维和更快速的事件响应。 在IMOC运维平台、业务流程优化、高水平运维团队、专家远程支持等的加持下,华为、生态伙伴及深圳机场共同定义了机场ICT系统运维的四级保障体系,并为每个级别定义了不同的工作内容和运维标准。深圳机场不仅可以避免了ICT系统出现重大故障、降低了一般性故障的发生概率,更实现了对关键运维事件的“5分钟处置”。 懂行才能好用 参与深圳宝安国际机场运维升级改造这样的大型工程,是华为及其生态的荣誉,更是对华为智能运维服务的一种肯定。而能够最终满足用户的高标准运维需求,华为及生态靠的则是模块化的先进理念和对机场运维需求的深刻理解。简单来说,就是“懂行”。 坐过飞机的人不少,但懂得机场ICT运维的人却不多。要做到对机场和千行百业的运维需求认知,单靠华为自己显然是力所不能及的。因此,华为的“懂行”更多是来自海量合作伙伴的经验和对伙伴价值的重视。而伴随华为生态圈层和数量的持续快速增加,华为也才能够实现以ICT产品技术服务千行百业、万种业务。 其实,亟待运维升级的远不止机场或交通行业,但有了懂行的华为及生态、和以模块化构建千变万化的智能运维服务,更多行业便能够通过运维升级实现更高标准的业务和更具效率的运营。 免责声明:本文内容由21ic获得授权后发布,版权归原作者所有,本平台仅提供信息存储服务。文章仅代表作者个人观点,不代表本平台立场,如有问题,请联系我们,谢谢!

    时间:2021-04-13 关键词: 华为 运维

  • 风电智慧运维,一切尽在掌握

    风电作为可再生能源领域中颇为成熟,且具备规模开发条件的绿色能源,已经受到来自世界各国的高度关注和重视,伴随着风电相关技术逐步成熟、设备不断升级,风力发电行业高速发展。 为了追求更高风能利用率,风力发电站总是远离人烟,同时,恶劣环境也为风电机组运维带来更多的挑战,导致风机运维的需求量日益增加。面对巨大的市场需求,如何做好风电资产全生命周期的风险把控,提高叶片维护质量,快速响应业主需求,成为风电后运维时代的重要课题。 2020年11月5日,第二届中国风电叶片运维技术专题研讨会(CWPM 2020)在江苏盐城成功召开。来自风电开发商、整机制造商、专业运维企业、检测认证及科研机构的300余名代表齐聚一堂,重点围绕“安全运维、完美修护、提技增功”等主题展开深入探讨和交流。 在研讨会主旨报告环节,魏德米勒电联接(上海)有限公司风电业务经理王琦峰就《魏德米勒叶片状态监测系统BLADEcontrol®》主题报告展开精彩演讲,现场分享了魏德米勒领先的风电运维技术解决方案——风机叶片状态监测系统BLADEcontrol®,引发观众极大兴趣。 魏德米勒电联接(上海)有限公司风电业务经理王琦峰 王琦峰指出,叶片是风机感受风能的“触角”,工作寿命一般为20年,运行维护周期较长,一旦损坏,维修和更换费用非常之高,由此带来的停机损失更加不可估量。为了实时监控叶片运行状态,魏德米勒风机叶片状态监测系统BLADEcontrol®应用而生,通过智能化监测系统,用户可充分掌握叶片运行中可能存在的各种风险,并通过预防性维护保养,将风险扼杀于“摇篮”中,以确保风电装置可靠地运行和高电能的输出。 “借助魏德米勒的BLADEcontrol®叶片状态监测系统,用户可以全年365天、全天24小时不间断实地监测每支叶片的状态,如实记录每一次雷击产生的微小变化,并立刻将相关数据传输到监测中心,专家在监测中心内评估相关数据,为操作人员提供具体行动建议清单。”王琦峰进一步补充道。 眼下,数字化、智能化技术正悄然改变着风电行业的开发、建设和运维模式,并成为提升风电场运营效率和收益水平的重要因素。未来的发展趋势是以状态监控系统为主的数据分析等数据驱动的业务模式。在自动化和数字化领域,魏德米勒BLADEcontrol®叶片状态监测系统解决方案,可有效减少停机时间并提升风电产能。 凭借在风电运维服务领域深耕多年所形成的技术优势和信息化优势,魏德米勒将不断提升运维服务能力,与行业用户一起持续为风电产业安全、高效、稳定发展保驾护航,共同助力风电平价时代的到来。

    时间:2020-11-13 关键词: 魏德米勒 叶片 运维

  • 科普贴:关于网站SEO

    前言 什么是SEO呢?SEO是Search Engine Optimization,意为“搜索引擎优化”,一般简称为搜索优化。对于SEO的主要工作就是通过了解各类搜索引擎如何抓取互联网页面,如何进行索引以及如何确定其对某一个特定关键词的搜索结果排名等技术,来对网页进行相关的优化,来提供搜索引擎排名,提高网站访问量。 如果能够很好的使用SEO技术,就能够改善您的网站排名并增加其在相关搜索中的可见程度,让你的网页在用户搜索过程中的可见度越来越高,这样您的网站就可能吸引更多的注意力和影响力,并吸引潜在的客户和现有客户加入您的业务当中。 总结一句:SEO代表搜索引擎优化,它是通过自然搜索引擎结果增加访问您网站的流量的数量和质量的一种做法。 SEO本质 那么SEO是如何工作的呢?例如一些浏览器的搜索引擎使用漫游器来获取web页面,从一个站点到另一个站点,收集有关页面的信息并讲其放入索引中。然后,通过算法会分析索引中的页面,并考虑数百种排名因素或信号等,来确定应该在给定查询的搜索结果中显示的页面顺序。 搜索排名因素可以被视为用户体验方面的代理。内容质量和关键字研究是内容优化的关键因素,搜索算法旨在显示相关的权威页面,并为用户提供有效的搜索体验,如果考虑到这些因素可以优化您的网站和内容可以帮助您的页面在搜索结果中排名更高。 seo主要还是用于商业目的来查找有关产品和服务的信息,搜索通常是品牌数字流量的主要来源,并补充了其他营销渠道,来获取更高的知名度和更高的搜索结果排名,让您的利润不断提升的过程。 seo运作 搜索关键字访问您所访问的网站,但是你是否思考过那神奇的链接列表后面的内容呢? 是这样的,Google有个搜索器,会收集在internet上找到的所有内容信息,然后将所有这些1和0带回到搜索引擎以建立索引。当你使用Google进行搜索时,实际上您不是在搜索网页,而是在搜索Google的网页索引,至少是在搜索尽可能多的,可找到的索引;会用一些名为“蜘蛛”的软件程序搜索,“蜘蛛”程序先抓取少量网页,然后跟踪这些网页上的链接,接着抓取这些链接指向的网页,再跟踪这些网页上的所有链接,并抓取它们链接到的网页,以此类推。 现在,假设我想知道某动物的奔跑速度,我在搜索框中输入该动物奔跑速度,然后按回车键,我们的软件就会在这些索引中搜索查找所有包含这些搜索字词的网页。 在这种情况下,系统会显示成数万条可能的结果,Google如何确定我的搜索意图呢?答案是通过提问来确定,问题数量超过200个,例如,您的关键字在此网页上出现了多少次? 这些关键字显示在标题中,网址中还是直接相邻?此网页是否包含这些关键字的同义词?此网页来自于优质网站还是劣质网址甚至垃圾网站? 此网页的PageRank是什么呢? PageRank它是叫网页排名,又称网页级别,是一种由根据网页之间相互的超链接计算的技术。Google用它来体现网页的相关性和重要性,在搜索引擎优化操作中经常被用来评估网页优化的成效因素之一。PageRank是谷歌的镇店之宝,一种用来对网络中节点的重要性排序的算法。 PageRank通过网络浩瀚的超链接关系来确定一个页面的等级。Google把从A页面到B页面的链接解释为A页面给B页面投票,Google根据投票来源(甚至来源的来源,即链接到A页面的页面)和投票目标的等级来决定新的等级。 简单的说,一个高等级的页面可以使其他低等级页面的等级提升。 假设一个由4个页面组成的小团体:A,B,C和D。如果所有页面都链向A,那么A的PR(PageRank)值将是B,C及D的Pagerank总和。诸如此类的公式小伙伴们有兴趣的可以去学习了解一下,这里不做过多说明了。 该公式会通过查找指向网页的外部链接数量以及这些链接的重要性来评价网页的重要性。最后,我们会结合以上所有因素,为每个网页打出总的评分。并在您提交搜索请求半秒钟后,返回搜索结果。 频繁更新网站或提高网站排名,每条结果都包含一个标题,一个网址以及一段有助于确定此网页是否是我所查找内容的文字。还看到一些类似网页的链接,该网页在Google上最近保存的版本,以及可能尝试的相关搜索。 直到我们将大部分网页编入索引,这是存储再数千台电脑中的数十亿网页。 各个因子的权重如图: 如果是我,我觉得可以使用如下几个步骤进行seo: 抓取辅助功能,以便引擎可以阅读您的网站 引人入胜的内容可以回答搜索者的查询 优化关键字以吸引搜索者和引擎 出色的用户体验,包括快递的加载速度和引入注目的UI 共享连接,引文和放大内容的有价值的内容 标题,url和说明吸引较高的点击率 摘要/模式标记在 SERP(搜索引擎结果页面)中脱颖而出 批注:搜索引擎结果页面,英文缩写SERP(Search Engine Results Page),指的是在搜索引擎领域中,搜索引擎返回的满足查询要求的页面。 SEO指南 内容和关键字是搜索引擎关键的因素,在你考虑SEO的时候,内容质量应该是您的首要任务,内容优质是您如何吸引用户,取悦观众的方式,创建高质量,有价值的内容对于搜索引擎的可见性也是至关重要的,所以其第一要素是内容质量。 对于您,比如写博客文章,产品页面,关于页面,推荐书,视频等还是您为受众群体创建的如何其他内容,正确安排内容质量,意味着您有基础来支持所有其他seo的工作。 内容质量的提供,向用户输出,提供实质性,有用和独特的内容是迫使他们留在您页面上,建立熟悉度和信任度,优质的内容却决于您的内容类型和行业,以及深度技术等而有所不同。 那么如何输出高质量内容呢,高质量内容的特点有如下几点: 信息内容的准确性,全面性,专业性 原创性,传达出很高的技巧,引用充分等 网址搜寻,索引和排名 首先面对搜索引擎,我们要了解其三个重要功能: 抓取:搜寻 internet上的内容,查看他们找到的每个 url的代码/内容 索引:存储和组织在获取过程中找到的内容,一旦页面进入索引,就会在运行中显示相关的查询结果 等级:提供最能回答搜索者查询的内容,这就意味着搜索结果的排序方式从最相关到最不相关 这里请记住搜索是个发现的过程,通过搜寻器(蜘蛛)来查找和更新的内容,这里的内容(可以是网页,图像,视频,PDF等)都是通过链接发现的。 一直说搜索引擎索引?那么是什么意思呢? 搜索引擎处理并存储他们在索引中找到的信息,索引是他们发现并认为足以为搜索者服务的所有内容的庞大数据库。 如果您现在没有在搜索结果中查找您想要显示的内容,可能有如下原因 可能您的网站时全新的,尚未进行对其获取 可能您的网站未从任何外部网站链接到 可能您的网站使机器人很难有效地对其获取内容 可能您的网站包含一些称为搜寻器指令的基本代码,这些基本代码会阻止搜索引擎 可能您的网站已因 Google的垃圾内容手段而受到惩罚 关键字的研究 什么是关键字呢? 当你搜索的时候,在输入框所输入的那些内容就是关键字,对于网站来说,能对你网站的内容进行最相关最简洁描述的字词就是关键字。 了解关键字(搜索词),首先要了解谁去搜索它们,或者你想要哪些关键词语,比如输入“婚礼”和“花店”,您可能发现相关性强,搜索量大的相关字词,如:婚礼花束,新娘花,婚礼花店等。 需要建立给定的关键字或关键字短语的搜索量越高,就需要更多的工作来获得更高的排名,同时某些大品牌通常会在高流量关键字中排名前十位的位置,所以,如果您一开始就从这些追求相同的关键字,那么排名的艰辛可想而知,需要花费很多年的时间。 针对搜索量大的,获得的自然排名成功所需要的竞争和努力就越大,不过在某些情况下,可以竞争程度较低的搜索字词可能是最有利的,在seo中,称为长尾关键词。 请不要小看一些不起眼的不受欢迎的关键字,搜索量较低的长尾关键字通常可以带来更好的效益,因为搜索者的搜索变得更加具体了,如搜索“前端”的人可能只是为了浏览,可是搜索“达达前端”的人就只是对这关键词有了很明确的指向。 通过搜索量指定策略 当您要对您的网站进行排名时,找到与其相关的搜索词,并查看竞争对手的排名,向其学习,弄清楚前因后果使您更具有战略意义。 观察竞争对手的关键词,也会你想要对很多关键字进行排名,那么您怎么知道先做哪一个呢?我觉得吧!咱们首先考虑的是查看竞争对手列表中哪些关键字的排名以及对其进行了优先排序。 优先考虑竞争对手当前末尾排名的高质量关键字可能是一个好主意,其实也可以查看竞争对手列表中哪些关键字以及在排名中的关键字。 可以先了解搜索者意图,进行搜索页面 要了解搜索者意图,我们就要进行研究: 信息查询,了解搜索者需要的信息; 导航查询,搜索者想转到 internet上的特定位置 交易查询,了解搜索者想要做的事情 商业调查,了解搜索者希望比较产品并找到满足其特定需求的最佳产品 本地查询,了解搜索者希望在本地找到的一些东西 现在您找到了目标市场的搜索方式,进行搜索页面(可回答搜索者问题的网页的实践),所以页面内容需要进行优化,如:标头标签,内部链接,锚文字(锚文本是用于链接到页面的文本),它将有关目标页面内容的信号发送给搜索引擎。 链接量 在Google的《一般网站管理员指南》中,将页面上的链接数量限制为合理的数量(最多几千个)。如果拥有太多内部链接本身是不会使您受到惩罚的,但这确实会影响Google查找和评估页面的方式。页面上的链接链接越多,每个链接分到的权益就越少。 您的标题标签是搜索者对您的网站的第一印象中起着很大的作用,那么如何让你的的网站拥有有效的标题标签呢? 关键字用,标题中包含目标关键字可以帮助用户和搜索引擎了解您的网站内容 长度,一般而言,搜索引擎会搜索结果中显示标题标签的前50-60个字符 元描述,像标题标签一样,元描述也是html元素,用于描述其所在页面的内容,它们也嵌套在head标签中: url结构,命名和组织页面 url代表统一资源定位器,url是网络上各个内容的位置或地址,与标题标签和元描述一样,搜索引擎会在serp(搜索引擎结果页面)上显示url,因此url的命名和格式会影响点击率,搜索者不仅使用它们来决定要单击哪些网页,而且搜索引擎还使用url来评估和排名页面。 最后总结一下,今天我们介绍了如下三方面内容: 网站如何运作 搜索引擎如何理解 用户如何与网站互动 关于网站SEO的知识,我就介绍到这里,大家对这方面感兴趣的话,欢迎查阅相关资料进一步深入学习。 点关注,不迷路 好了各位,以上就是这篇文章的全部内容,能看到这里的人都是人才。我后面会不断更新技术相关的文章,如果觉得文章对你有用,欢迎给个“在看”,也欢迎分享,感谢大家 !! —————END————— 喜欢本文的朋友,欢迎关注公众号 程序员小灰,收看更多精彩内容 点个[在看],是对小灰最大的支持! 免责声明:本文内容由21ic获得授权后发布,版权归原作者所有,本平台仅提供信息存储服务。文章仅代表作者个人观点,不代表本平台立场,如有问题,请联系我们,谢谢!

    时间:2020-09-30 关键词: 互联网 运维

  • Redis越来越慢?这些方法超级有效!

    Redis作为内存数据库,拥有非常高的性能,单个实例的QPS能够达到10W左右。但我们在使用Redis时,经常时不时会出现访问延迟很大的情况,如果你不知道Redis的内部实现原理,在排查问题时就会一头雾水。 很多时候,Redis出现访问延迟变大,都与我们的使用不当或运维不合理导致的。 这篇文章我们就来分析一下Redis在使用过程中,经常会遇到的延迟问题以及如何定位和分析。 使用复杂度高的命令 如果在使用Redis时,发现访问延迟突然增大,如何进行排查? 首先,第一步,建议你去查看一下Redis的慢日志。Redis提供了慢日志命令的统计功能,我们通过以下设置,就可以查看有哪些命令在执行时延迟比较大。 首先设置Redis的慢日志阈值,只有超过阈值的命令才会被记录,这里的单位是微秒,例如设置慢日志的阈值为5毫秒,同时设置只保留最近1000条慢日志记录: # 命令执行超过5毫秒记录慢日志CONFIG SET slowlog-log-slower-than 5000# 只保留最近1000条慢日志CONFIG SET slowlog-max-len 1000 设置完成之后,所有执行的命令如果延迟大于5毫秒,都会被Redis记录下来,我们执行 SLOWLOG get 5 查询最近5条慢日志 127.0.0.1:6379> SLOWLOG get51)1)(integer)32693# 慢日志ID2)(integer)1593763337# 执行时间3)(integer)5299# 执行耗时(微秒)4)1)"LRANGE"# 具体执行的命令和参数2)"user_list_2000"3)"0"4)"-1"2)1)(integer)326922)(integer)15937633373)(integer)50444)1)"GET"2)"book_price_1000"... 通过查看慢日志记录,我们就可以知道在什么时间执行哪些命令比较耗时,如果你的业务经常使用 O(n) 以上复杂度的命令,例如sort、sunion、zunionstore,或者在执行O(n)命令时操作的数据量比较大,这些情况下Redis处理数据时就会很耗时。 如果你的服务请求量并不大,但Redis实例的CPU使用率很高,很有可能是使用了复杂度高的命令导致的。 解决方案就是,不使用这些复杂度较高的命令,并且一次不要获取太多的数据,每次尽量操作少量的数据,让Redis可以及时处理返回。 存储大key 如果查询慢日志发现,并不是复杂度较高的命令导致的,例如都是SET、DELETE操作出现在慢日志记录中,那么你就要怀疑是否存在Redis写入了大key的情况。 Redis在写入数据时,需要为新的数据分配内存,当从Redis中删除数据时,它会释放对应的内存空间。 如果一个key写入的数据非常大,Redis在 分配内存时也会比较耗时 。同样的,当删除这个key的数据时, 释放内存也会耗时比较久 。 你需要检查你的业务代码,是否存在写入大key的情况,需要评估写入数据量的大小,业务层应该避免一个key存入过大的数据量。 那么有没有什么办法可以扫描现在Redis中是否存在大key的数据吗? Redis也提供了扫描大key的方法: redis-cli -h $host -p $port --bigkeys -i 0.01 使用上面的命令就可以扫描出整个实例key大小的分布情况,它是以类型维度来展示的。 需要注意的是当我们在线上实例进行大key扫描时,Redis的QPS会突增,为了降低扫描过程中对Redis的影响,我们需要控制扫描的频率,使用 -i 参数控制即可,它表示扫描过程中每次扫描的时间间隔,单位是秒。 使用这个命令的原理,其实就是Redis在内部执行 scan 命令,遍历所有key,然后针对不同类型的key执行strlen、llen、hlen、scard、zcard来获取字符串的长度以及容器类型(list/dict/set/zset)的元素个数。 而对于容器类型的key,只能扫描出元素最多的key,但元素最多的key不一定占用内存最多,这一点需要我们注意下。不过使用这个命令一般我们是可以对整个实例中key的分布情况有比较清晰的了解。 针对大key的问题,Redis官方在4.0版本推出了lazy-free的机制,用于异步释放大key的内存,降低对Redis性能的影响。即使这样,我们也不建议使用大key,大key在集群的迁移过程中,也会影响到迁移的性能,这个后面在介绍集群相关的文章时,会再详细介绍到。 集中过期 有时你会发现,平时在使用Redis时没有延时比较大的情况,但在某个时间点突然出现一波延时,而且报慢的时间点很有规律,例如某个整点,或者间隔多久就会发生一次。 如果出现这种情况,就需要考虑是否存在大量key集中过期的情况。 如果有大量的key在某个固定时间点集中过期,在这个时间点访问Redis时,就有可能导致延迟增加。 Redis的过期策略采用主动过期+懒惰过期两种策略: •主动过期:Redis内部维护一个定时任务,默认每隔100毫秒会从过期字典中随机取出20个key,删除过期的key,如果过期key的比例超过了25%,则继续获取20个key,删除过期的key,循环往复,直到过期key的比例下降到25%或者这次任务的执行耗时超过了25毫秒,才会退出循环 •懒惰过期:只有当访问某个key时,才判断这个key是否已过期,如果已经过期,则从实例中删除 注意, Redis的主动过期的定时任务,也是在Redis主线程中执行的 ,也就是说如果在执行主动过期的过程中,出现了需要大量删除过期key的情况,那么在业务访问时,必须等这个过期任务执行结束,才可以处理业务请求。此时就会出现,业务访问延时增大的问题,最大延迟为25毫秒。 而且这个访问延迟的情况,不会记录在慢日志里。慢日志中 只记录真正执行某个命令的耗时 ,Redis主动过期策略执行在操作命令之前,如果操作命令耗时达不到慢日志阈值,它是不会计算在慢日志统计中的,但我们的业务却感到了延迟增大。 此时你需要检查你的业务,是否真的存在集中过期的代码,一般集中过期使用的命令是 expireat 或 pexpireat 命令,在代码中搜索这个关键字就可以了。 如果你的业务确实需要集中过期掉某些key,又不想导致Redis发生抖动,有什么优化方案? 解决方案是, 在集中过期时增加一个 随机时间 ,把这些需要过期的key的时间打散即可 。 伪代码可以这么写: # 在过期时间点之后的5分钟内随机过期掉redis.expireat(key, expire_time + random(300)) 这样Redis在处理过期时,不会因为集中删除key导致压力过大,阻塞主线程。 另外,除了业务使用需要注意此问题之外,还可以通过运维手段来及时发现这种情况。 做法是我们需要把Redis的各项运行数据监控起来,执行 info 可以拿到所有的运行数据,在这里我们需要重点关注expired_keys这一项,它代表整个实例到目前为止,累计删除过期key的数量。 我们需要对这个指标监控,当在 很短时间内这个指标出现突增 时,需要及时报警出来,然后与业务报慢的时间点对比分析,确认时间是否一致,如果一致,则可以认为确实是因为这个原因导致的延迟增大。 实例内存达到上限 有时我们把Redis当做纯缓存使用,就会给实例设置一个内存上限 maxmemory ,然后开启LRU淘汰策略。 当实例的内存达到了 maxmemory 后,你会发现之后的每次写入新的数据,有可能变慢了。 导致变慢的原因是,当Redis内存达到 maxmemory 后,每次写入新的数据之前,必须先踢出一部分数据,让内存维持在maxmemory之下。 这个踢出旧数据的逻辑也是需要消耗时间的,而具体耗时的长短,要取决于配置的淘汰策略: •allkeys-lru:不管key是否设置了过期,淘汰最近最少访问的key •volatile-lru:只淘汰最近最少访问并设置过期的key •allkeys-random:不管key是否设置了过期,随机淘汰 •volatile-random:只随机淘汰有设置过期的key •allkeys-ttl:不管key是否设置了过期,淘汰即将过期的key •noeviction:不淘汰任何key,满容后再写入直接报错 •allkeys-lfu:不管key是否设置了过期,淘汰访问频率最低的key(4.0+支持) •volatile-lfu:只淘汰访问频率最低的过期key(4.0+支持) 备注:allkeys-xxx表示从所有的键值中淘汰数据,而volatile-xxx表示从设置了过期键的键值中淘汰数据。 具体使用哪种策略,需要根据业务场景来决定。 我们最常使用的一般是 allkeys-lru 或 volatile-lru 策略,它们的处理逻辑是,每次从实例中随机取出一批key(可配置),然后淘汰一个最少访问的key,之后把剩下的key暂存到一个池子中,继续随机取出一批key,并与之前池子中的key比较,再淘汰一个最少访问的key。以此循环,直到内存降到maxmemory之下。 如果使用的是 allkeys-random 或 volatile-random 策略,那么就会快很多,因为是随机淘汰,那么就少了比较key访问频率时间的消耗了,随机拿出一批key后直接淘汰即可,因此这个策略要比上面的LRU策略执行快一些。 但以上这些逻辑都是在访问Redis时, 真正命令执行之前执行的 ,也就是它会影响我们访问Redis时执行的命令。 另外,如果此时Redis实例中有存储大key,那么在淘汰大key释放内存时,这个耗时会更加久,延迟更大,这需要我们格外注意。 如果你的业务访问量非常大,并且必须设置maxmemory限制实例的内存上限,同时面临淘汰key导致延迟增大的的情况,要想缓解这种情况,除了上面说的避免存储大key、使用随机淘汰策略之外,也可以考虑拆分实例的方法来缓解,拆分实例可以把一个实例淘汰key的压力 分摊到多个实例 上,可以在一定程度降低延迟。 fork耗时严重 如果你的Redis开启了自动生成RDB和AOF重写功能,那么有可能在后台生成RDB和AOF重写时导致Redis的访问延迟增大,而等这些任务执行完毕后,延迟情况消失。 遇到这种情况,一般就是执行生成RDB和AOF重写任务导致的。 生成RDB和AOF都需要父进程 fork 出一个子进程进行数据的持久化, 在fork执行过程中,父进程需要拷贝内存页表给子进程,如果整个实例内存占用很大,那么需要拷贝的内存页表会比较耗时,此过程会消耗大量的CPU资源,在完成fork之前,整个实例会被阻塞住,无法处理任何请求,如果此时CPU资源紧张,那么fork的时间会更长,甚至达到秒级。这会严重影响Redis的性能 。 我们可以执行info命令,查看最后一次fork执行的耗时latest_fork_usec,单位微秒。这个时间就是整个实例阻塞无法处理请求的时间。 除了因为备份的原因生成RDB之外, 在主从节点第一次建立数据同步时 ,主节点也会生成RDB文件给从节点进行一次全量同步,这时也会对Redis产生性能影响。 要想避免这种情况,我们需要规划好数据备份的周期,建议在从节点 上执行备份,而且最好放在低峰期执行 。如果对于丢失数据不敏感的业务,那么不建议开启AOF和AOF重写功能。 另外,fork的耗时也与系统有关,如果把Redis部署在虚拟机上,那么这个时间也会增大。所以使用Redis时建议部署在物理机上,降低fork的影响。 绑定CPU 很多时候,我们在部署服务时,为了提高性能,降低程序在使用多个CPU时上下文切换的性能损耗,一般会采用进程绑定CPU的操作。 但在使用Redis时,我们不建议这么干,原因如下: 绑定CPU的Redis,在进行数据持久化时,fork出的子进程,子进程会继承父进程的CPU使用偏好,而此时子进程会消耗大量的CPU资源进行数据持久化,子进程会与主进程发生CPU争抢,这也会导致主进程的CPU资源不足访问延迟增大。 所以在部署Redis进程时, 如果需要开启RDB和AOF重写机制,一定不能进行CPU绑定操作! 开启AOF   上面提到了,当执行AOF文件重写时会因为fork执行耗时导致Redis延迟增大,除了这个之外,如果开启AOF机制,设置的策略不合理,也会导致性能问题。 开启AOF后,Redis会把写入的命令实时写入到文件中,但写入文件的过程是先写入内存,等内存中的数据超过一定阈值或达到一定时间后,内存中的内容才会被真正写入到磁盘中。 AOF为了保证文件写入磁盘的安全性,提供了3种刷盘机制: •appendfsync always:每次写入都刷盘,对性能影响最大,占用磁盘IO比较高,数据安全性最高 •appendfsync everysec:1秒刷一次盘,对性能影响相对较小,节点宕机时最多丢失1秒的数据 •appendfsync no:按照操作系统的机制刷盘,对性能影响最小,数据安全性低,节点宕机丢失数据取决于操作系统刷盘机制 当使用第一种机制appendfsync always时,Redis每处理一次写命令,都会把这个命令写入磁盘,而且 这个操作是在主线程中执行的 。 内存中的的数据写入磁盘,这个会加重磁盘的IO负担,操作磁盘成本要比操作内存的代价大得多。如果写入量很大,那么每次更新都会写入磁盘,此时机器的磁盘IO就会非常高,拖慢Redis的性能,因此我们不建议使用这种机制。 与第一种机制对比,appendfsync everysec会每隔1秒刷盘,而appendfsync no取决于操作系统的刷盘时间,安全性不高。因此我们推荐使用appendfsync everysec这种方式,在最坏的情况下,只会丢失1秒的数据,但它能保持较好的访问性能。 当然,对于有些业务场景,对丢失数据并不敏感,也可以不开启AOF。 使用Swap 如果你发现Redis突然变得非常慢,每次访问的耗时都达到了几百毫秒甚至秒级,那此时就检查Redis是否使用到了Swap,这种情况下Redis基本上已经无法提供高性能的服务。 我们知道,操作系统提供了Swap机制,目的是为了当内存不足时,可以把一部分内存中的数据换到磁盘上,以达到对内存使用的缓冲。 但当内存中的数据被换到磁盘上后,访问这些数据就需要从磁盘中读取,这个速度要比内存慢太多! 尤其是针对Redis这种高性能的内存数据库来说,如果Redis中的内存被换到磁盘上,对于Redis这种性能极其敏感的数据库,这个操作时间是无法接受的。 我们需要检查机器的内存使用情况,确认是否确实是因为内存不足导致使用到了Swap。 如果确实使用到了Swap,要及时整理内存空间,释放出足够的内存供Redis使用,然后释放Redis的Swap,让Redis重新使用内存。 释放Redis的Swap过程通常要重启实例,为了避免重启实例对业务的影响,一般先进行主从切换,然后释放旧主节点的Swap,重新启动服务,待数据同步完成后,再切换回主节点即可。 可见,当Redis使用到Swap后,此时的Redis的高性能基本被废掉,所以我们需要提前预防这种情况。 我们需要对Redis机器的内存和Swap使用情况进行监控,在内存不足和使用到Swap时及时报警出来,及时进行相应的处理。 网卡负载过高   如果以上产生性能问题的场景,你都规避掉了,而且Redis也稳定运行了很长时间,但在某个时间点之后开始,访问Redis开始变慢了,而且一直持续到现在,这种情况是什么原因导致的? 之前我们就遇到这种问题,特点就是从某个时间点之后就开始变慢,并且一直持续。这时你需要检查一下机器的网卡流量,是否存在网卡流量被跑满的情况。 网卡负载过高,在网络层和TCP层就会出现数据发送延迟、数据丢包等情况。Redis的高性能除了内存之外,就在于网络IO,请求量突增会导致网卡负载变高。 如果出现这种情况,你需要排查这个机器上的哪个Redis实例的流量过大占满了网络带宽,然后确认流量突增是否属于业务正常情况,如果属于那就需要及时扩容或迁移实例,避免这个机器的其他实例受到影响。 运维层面,我们需要对机器的各项指标增加监控,包括网络流量,在达到阈值时提前报警,及时与业务确认并扩容。 总结   以上我们总结了Redis中常见的可能导致延迟增大甚至阻塞的场景,这其中既涉及到了业务的使用问题,也涉及到Redis的运维问题。 可见,要想保证Redis高性能的运行,其中涉及到CPU、内存、网络,甚至磁盘的方方面面,其中还包括操作系统的相关特性的使用。 作为开发人员,我们需要了解Redis的运行机制,例如各个命令的执行时间复杂度、数据过期策略、数据淘汰策略等,使用合理的命令,并结合业务场景进行优化。 作为DBA运维人员,需要了解数据持久化、操作系统fork原理、Swap机制等,并对Redis的容量进行合理规划,预留足够的机器资源,对机器做好完善的监控,才能保证Redis的稳定运行。 END 免责声明:本文系网络转载,版权归原作者所有。如有问题,请联系我们,谢谢! 免责声明:本文内容由21ic获得授权后发布,版权归原作者所有,本平台仅提供信息存储服务。文章仅代表作者个人观点,不代表本平台立场,如有问题,请联系我们,谢谢!

    时间:2020-09-28 关键词: 嵌入式 运维

  • 一篇文章搞定大规模容器平台生产落地十大实践

    Kubernetes已经成为企业容器平台的标配,在大部分企业,小规模容器平台已经试用了一段时间,然而当容器平台规模大了之后,尤其是用于生产,可能会遇到各种各样的问题,这里我们总结十大问题。 第零节,Kubernetes的架构优势 在讲述生产落地实践之前,我们先概述一下Kubernetes的设计原理,因为后面的很多实践,都是基于对于这些原理的理解。 为什么在众多容器平台中,Kubernetes能够脱颖而出,我个人认为有以下几点。 0.1 Kubernetes的接口和概念设计是完全站在应用角度而非运维角度的 如果站在传统运维人员的角度看 Kubernetes,会觉得他是个奇葩所在,容器还没创建出来,概念先来一大堆,文档先读一大把,编排文件也复杂,组件也多,让很多人望而却步。 但是如果开发人员的角度,尤其是从微服务应用的架构的角度来看Kubernetes,则会发现,他对于微服务的运行生命周期和相应的资源管控,做了非常好的抽象。 如图中所示,和虚拟机运行传统应用,只需要创建出资源来,并且保证网络畅通即可的方式不同,微服务的运行,需要完成左面的一系列工具链。 为什么要使用这些工具链,以及如何使用这些工具链,请参考我的另外两篇文章以业务为核心的云原生体系建设和从1到2000个微服务,史上最落地的实践云原生25个步骤。 你会发现,Kubernetes都有相应的工具链可以匹配。 微服务设计重要的一点就是区分无状态和有状态,在 K8S 中,无状态对应 deployment,有状态对应 StatefulSet。 deployment 主要通过副本数,解决横向扩展的问题。 而 StatefulSet 通过一致的网络 ID,一致的存储,顺序的升级,扩展,回滚等机制,保证有状态应用,很好地利用自己的高可用机制。因为大多数集群的高可用机制,都是可以容忍一个节点暂时挂掉的,但是不能容忍大多数节点同时挂掉。而且高可用机制虽然可以保证一个节点挂掉后回来,有一定的修复机制,但是需要知道刚才挂掉的到底是哪个节点,StatefulSet 的机制可以让容器里面的脚本有足够的信息,处理这些情况,实现哪怕是有状态,也能尽快修复。 微服务少不了服务发现,除了应用层可以使用 SpringCloud 或者 Dubbo 进行服务发现,在容器平台层当然是用 Service了,可以实现负载均衡,自修复,自动关联。 对于配置中心,K8S 提供了 configMap,可以在容器启动的时候,将配置注入到环境变量或者 Volume 里面。但是唯一的缺点是,注入到环境变量中的配置不能动态改变了,好在 Volume 里面的可以,只要容器中的进程有 reload 机制,就可以实现配置的动态下发了。 Kubernetes本身能力比较弱的就是服务的治理能力,这一点 Service Mesh,可以实现更加精细化的服务治理,进行熔断,路由,降级等策略。Service Mesh 的实现往往通过 sidecar 的方式,拦截服务的流量,进行治理。这也得力于  Pod 的理念,一个 Pod 可以有多个容器,如果当初的设计没有 Pod,直接启动的就是容器,会非常的不方便。 0.2 Kubernete本身的架构就是微服务架构,使其易管理和易定制 Kubernetes 本身就是微服务的架构,虽然看起来复杂,但是容易定制化,容易横向扩展。 Kubernetes 的 API Server 更像网关,提供统一的鉴权和访问接口。 在 Kubernetes 中几乎所有的组件都是无状态化的,状态都保存在统一的 etcd 里面,这使得扩展性非常好,组件之间异步完成自己的任务,将结果放在 etcd 里面,互相不耦合。 有了 API Server 做 API 网关,所有其他服务的协作都是基于事件的,因而对于其他服务进行定制化,对于 client 和 kubelet 是透明的。 Kubernetes提供了插件化和组件,例如网络,存储,负载均衡等,可以灵活配置。 例如下图展示了创建一个Pod的时候,各个组件的协作情况。 (0)所有的Kubernetes组件Controller, Scheduler, Kubelet都使用Watch机制来监听API Server,来获取对象变化的事件 (1)用户通过Kubectl提交Pod Spec给API Server; (2)API Server将Pod对象的信息存入Etcd中 (3)Pod的创建会生成一个事件,返回给API Server (4)Controller监听到这个事件 (5)Controller知道这个Pod要mount一个盘,于是查看是否有能够满足条件的PV (6)假设有满足条件的PV,就将Pod和PV绑定在一起,将绑定关系告知API Server (7)API Server将绑定信息写入Etcd中 (8)生成一个Pod Update事件 (9)Scheduler监听到了这个事件 (10)Scheduler需要为Pod选择一个Node (11)假设有满足条件的Node,就讲Pod和Node绑定在一起,将绑定关系告知API Server (12)API Server将绑定信息写入Etcd中 (13)生成一个Pod Update事件 (14)Kubelet监听到了这个事件,开始创建Pod (15)Kubelet告知CRI去下载镜像 (16)Kubelet告知CRI去运行容器 (17)CRI调用Docker运行容器 (18)Kubelet告知Volume Manager,将盘挂在到Node上,然后mount到Pod中 (19)CRI调用CNI给容器配置网络 好了,基本原理解释清楚了,接下来我们看十大实践。 第一节,历史兼容性设计:将应用程序平滑迁移到容器 构建容器平台要考虑的第一件事情就是应用如何迁移到容器中,这是很多公司往往忽略的问题,这会造成容器平台虽然建设了,但是应用不愿意改造,或者改造成本过大,从而不愿意迁移到容器上来。 影响到容器迁移的一个最重要的问题就是网络连通性问题,因为原来很多的应用之间都是相互调用,关系复杂,难以理清,有的通过注册发现机制才能找到对方,但是应用迁移的时候,往往不敢贸然一次全量迁移,而是部分迁移,一旦出现部分迁移,就会出现容器内应用和容器外应用如何通信,如何发现的问题,因为容器会有自己的私有网络,和原来机房和云的网络模式不同,如果通信需要代理或者NAT,问题就会变得比较的复杂。 1.1 容器网络基本原理介绍 在解决问题之前,我们先看一下主流的容器网络的基本原理,目前大部分公司部署的容器都是使用Calico作为网络方案,他的网络模式如下图所示。 Calico网络的大概思路,即不走Overlay网络,不引入另外的网络性能损耗,而是将转发全部用三层网络的路由转发来实现。 其实现细节如下: 容器A1的IP地址为172.17.8.2/32,这里注意,不是/24,而是/32,将容器A1作为一个单点的局域网了。 容器A1里面的默认路由,Calico配置得比较有技巧。 default via 169.254.1.1 dev eth0169.254.1.1 dev eth0 scope link 这个IP地址169.254.1.1是默认的网关,但是整个拓扑图中没有一张网卡是这个地址。那如何到达这个地址呢? 因为当一台机器要访问网关的时候,首先会通过ARP获得网关的MAC地址,然后将目标MAC变为网关的MAC,而网关的IP地址不会在任何网络包头里面出现,也就是说,没有人在乎这个地址具体是什么,只要能找到对应的MAC,响应ARP就可以了。 ARP本地有缓存,通过ip neigh命令可以查看。 169.254.1.1 dev eth0 lladdr ee:ee:ee:ee:ee:ee STALE   这个MAC地址是Calico硬塞进去的,但是没有关系,它能响应ARP,于是发出的包的目标MAC就是这个MAC地址。 在物理机A上查看所有网卡的MAC地址的时候,我们会发现veth1就是这个MAC地址。所以容器A1里发出的网络包,第一跳就是这个veth1这个网卡,也就到达了物理机A这个路由器。 在物理机A上有多条路由规则,分别是去两个本机的容器的路由,以及去172.17.9.0/24下一跳为物理机B,去172.17.10.0/24下一跳为物理机C。 172.17.8.2 dev veth1 scope link172.17.8.3 dev veth2 scope link172.17.9.0/24 via 192.168.100.101 dev eth0 proto bird onlink172.17.10.0/24 via 192.168.100.102 dev eth0 proto bird onlink 同理,物理机B上也有多条路由规则,分别是去两个本机的容器的路由,以及去172.17.8.0/24的下一跳为物理机A,去172.17.10.0/24下一跳为物理机C。 172.17.9.2 dev veth1 scope link172.17.9.3 dev veth2 scope link172.17.8.0/24 via 192.168.100.100 dev eth0 proto bird onlink172.17.10.0/24 via 192.168.100.102 dev eth0 proto bird onlink 在这里,物理机化身为路由器,通过路由器上的路由规则,将包转发到目的地。在这个过程中,没有隧道封装解封装,仅仅是单纯的路由转发,性能会好很多。 当机器数目比较多的时候,这些路由不能手动配置,需要每台物理机上有一个agent,当创建和删除容器的时候,自动做这件事情,这个agent在Calico中称为Felix。 当Felix配置了路由之后,接下来的问题就是,如何将路由信息广播出去。在Calico中,每个Node上运行一个软件BIRD,作为BGP的客户端,或者叫作BGP Speaker,将路由信息广播出去。所有Node上的BGP Speaker 都互相建立连接,就形成了全互连的情况,这样每当路由有所变化的时候,所有节点就都能够收到了。 Calico模式要求底层网络必须能够支持BGP,另外就是跨网段问题,也即接入Calico网络的物理机必须在同一个网段下面,中间不能再跨路由器,否则中间的路由器如果不配合将Calico的BGP网络信息进行转发,则网络就会割裂。 但是往往中间的路由器不在Kubernetes和Calico的控制之下,一种折中的办法是物理机A和物理机B之间打一个隧道,这个隧道有两个端点,在端点上进行封装,将容器的IP作为乘客协议放在隧道里面,而物理主机的IP放在外面作为承载协议。这样不管外层的IP通过传统的物理网络,走多少跳到达目标物理机,从隧道两端看起来,物理机A的下一跳就是物理机B,这样前面的逻辑才能成立。这就是Calico的IPIP模式。由此可见,Calico的IPIP模式也是Overlay的,也是存在性能损耗的。 1.2. 模式一,构建统一的SDN网络 最理想的方式就是整个数据中心的规划构建了统一的SDN网络,不管是硬件的SDN还是软件的SDN,都可以让不同的运行环境接入这个统一的SDN网络,从而可以通过管控统一下发网络策略,实现不同运行环境的统一互通,而对应用层透明。 这一点在以业务为核心的云原生体系建设中有这样的图。 在这里面,你会发现OpenStack将所有的Vmware虚拟化,KVM虚拟化,以及物理机统一管理起来的时候,旁边有一个竖条就是SDN,这在上层Kubernetes将Vmware虚拟机,KVM虚拟机,物理机统一编排的时候,起到了这个作用。 我们先从OpenStack网络模型说起。 OpenStack分管控面和数据面,Nova负责创建虚拟机,Neutron可以有L2和L3的插件下发管控网络策略。 在计算节点和网络节点上,nova-compute负责和nova管控交互,启动虚拟机,L2 Agent和L3 Agent负责和neutron插件交互来下发网络策略,从而实现了简单的软件SDN。 对于每一个节点,虚拟网络设备分为两层,一层是桥接网络,用于区分相同物理机上不同租户的虚拟机,基于VLAN,另一层是VXLAN的VTEP,也即VXLAN的封包和解封包的虚拟网络设备。 这在仅有OpenStack的时候,没有任何问题。 如果有Vmware需要纳入OpenStack的管理怎么办呢?管控端好说,Nova对接Vcenter就可以了。网络层面就比较难打通了。 如果用Vmware NSX,Vmware有自己的虚拟交换机的实现,和OpenStack用的Openvswitch完全两回事儿,因而Neutron根本无法纳管。 那怎么办呢?我们可以将OpenStack的两层虚拟网络设备分开来看,上层的VLAN是统一的,无论是OpenStack还是Vmware,相同的租户使用相同的VLAN即可,下层的VXLAN VTEP是Vmware虚拟交换机和Openvswitch没办法互通的,可以通过硬件SDN下沉到出物理机后的TOR交换机上做VXLAN的终结。 我们以某硬件厂商的SDN为例子,如下图。 与标准的Openstack对接:采用在Neutron Server中安装SDN Controller插件的方式,接管Openstack网络控制。Openstack定义的插件如下表所示: 可对接Neutron插件举例 可对接对象举例 ml2 network subnet port l3 router floatingip vpnaas Vpnservice/ikepolicy fwaas Firewall/firewall_policy lbaas memberpool Openstack插件类似于一个硬件driver,以网络组件Neutron为例,Neutron本身实现抽象的虚拟网络功能,Neutron先调用插件把虚拟网络下发到SDN Controller,然后由SDN Controller下发到具体的设备上。插件可以是核心组件也可以是一项服务:核心插件实现“核心”的Neutron API——二层网络和IP地址管理。服务插件提供“额外”的服务,例如三层路由、负载均衡、VPN、防火墙和计费等。 SDN Controller实现了上述插件,在插件里通过REST API把Nuetron的配置传递给SDN Controller,SDN Controller进行网络业务编排通过Openflow流表等手段下发到硬件交换机、NFV以及vSwitch上,以实现相应的网络和服务功能。 有了统一的SDN的能力,当有了容器平台的时候,接入就容易的多,而且下层的VXLAN对于容器内的应用不可见,对于容器来讲,他就像和Vmware虚拟机里面的应用以及KVM里面的应用在同一个二层网络里面一样,十分平滑。 如果我们有了容器平台,无论是物理机部署,还是虚拟机部署,都可以通过桥接的方式,连接到外面的网络中,不同的租户可以使用不同的VLAN,通过硬件SDN的VXLAN封装实现互通。 如果没有VMware,或者选择Vmware不统一纳管,还可以实现基于Openvwitch的统一软件SDN方案,统一管理容器网络,虚拟机网络。 当然,使用统一的软件或者硬件SDN,需要对于整个运维部和机房有统一的规划,这在很多企业是没有做到的,从而环境被割裂称为了一块一块的,接下来我们就来讨论一下这些场景。 1.3. 模式二:原来的应用部署在Vmware或者物理机上,直接使用机房网络,需要和K8S中的容器互通。 如图所示,使用Vmware可以不用虚拟交换机,而是直接用桥接方式使用机房网,这也是很多传统企业的使用模式,使用物理机,更是使用机房网。 这个时候,我们可以划分出一部分物理机来,分配一个网段给K8S集群,使用Calico网络,由于基于物理网络,Calico网络可以使用BGP模式,这样没有虚拟化,性能也比较好。 接下来就是如何通过机房网络和传统应用互通的问题,由于传统应用也使用机房网络,并且也有规划的网段,因而只要传统物理网络的路由器和容器所在的物理网络的路由器做一个路由配置就可以,也即在图中右面的Gateway上配置到达Calico每一个节点的路由,同时告知Calico的每一个节点,要想访问传统应用的网段,应该经过右面的GW,转发给左面的GW,然后在左面的Gateway上配置,如果要访问容器网络,应该经过左面的GW,转发给右面的GW,其实相当于做了一个peering。 1.4. 模式三:原来已经采购云平台,传统应用使用云平台的VPC网络,而云平台本身提供托管的K8S集群,K8S里面的容器也能够直接使用VPC网络。 这就是Fargate模式,也即完全托管的容器平台,这个时候容器平台的网络被云完全托管,大部分托管的容器平台会直接使用云的VPC网络,而不会在VPC网络之上再虚拟化一层容器网络,这种模式和我们上面提到的软件SDN的方式一样,这样两面的互通是十分平滑的。 1.5. 模式四:原来已有云平台,传统应用使用云平台的VPC网络,新建的K8S部署在物理机上。 这也是常规的建设方式,云是云,容器是容器,互不干扰。 在云平台的VPC里面,有一个重要的概念就是网关,网关可以在不同的VPC之间,以及VPC和物理网络之间建立VPN,或者对等连接VPC peering。使得无论是VPC内的网络,还是云外的网络,都可以感觉是可以无缝通信的。 方式如下图所示。 同理,对于Calico,有一个网关可以将流量转发到Calico的BGP网络中,然后这个GW和云内VPC的GW做对等连接,即可。 1.6. 模式五:在云平台内部自行搭建K8S集群 很多企业担心被云厂商绑定,因而要跨云进行部署,并且不愿意使用云平台提供的托管K8S,而是通过类似多容器部署管理平台,自行在多个云上搭建K8S集群。 这就面临一个问题,就是云内的VPC是不支持BGP网络的,因而在云内搭建K8S集群,就需要使用Calico的IPIP模式,也即在云的网络虚拟化之上,又多了一层虚拟化,这样使得性能有所损耗。 另一个问题就是,Calico的IPIP模式的网络是Overlay网络,和其他虚拟机上的应用天然不通,必须要经过代理或者NAT才能通信,要求业务做一定的适配,影响比较大。 这个时候,有两种替代方案。 第一,在大多数的云平台上,一个虚拟机是可以创建多个网卡的,我们可以将一个网卡用于管控通信,其他的网卡在创建容器的时候,用命令行将其中一个虚拟机网卡塞到容器网络的namespace里面,这样容器就能够使用VPC网络和其他虚拟机上的应用进行平滑通信了,而且没有了二次虚拟化。 当然云平台对于一个虚拟机上的网卡数目有限制,这就要求我们创建的虚拟机规格不能太大,因为上面能够跑的容器的数量受到网卡数目限制。 另外我们在调度容器的时候,需要考虑一个节点还有没有剩余的网卡。Kubernetes有一个概念叫Extended Resources,官方文档举了这样一个例子。 curl --header "Content-Type: application/json-patch+json" \--request PATCH \--data '[{"op": "add", "path": "/status/capacity/example.com~1dongle", "value": "4"}]' \http://localhost:8001/api/v1/nodes//status 同理可以将网卡作为Extended Resources放到每个Node上,然后创建Pod的时候,指定网卡资源。 apiVersion: v1kind: Podmetadata: name: extended-resource-demospec: containers: - name: extended-resource-demo-ctr image: nginx resources: requests: example.com/dongle: 3 limits: example.com/dongle: 3 同时要配合开发CNI插件,通过nsenter,ip netns等命令将网卡放入namespace中。 第二,就是使用hostnetwork,也即容器共享虚拟机网络,这样使得每个容器没有单独的网络命名空间,因而端口会冲突,需要随机分配应用的端口,由于应用的端口事先不可知,需要通过服务发现机制,给注册中心注册随机的端口。 1.7. 模式六:乖乖使用Cailco网络,使用Ingress进行容器内外的访问 第二节,容器运行时与隔离性设计 好了,上一节,容器迁移的兼容性问题解决了,接下来是常遇到的问题是,容器的隔离性不好,如何提升容器的隔离性的问题。 2.1. 容器隔离性设计 我们应该增强哪些容器运行的隔离性呢? 我们都知道容器是通过cgroup技术来限制资源的使用的,cgroup定义了很多的子系统,常用的用于限制资源的有以下的几个: cpu子系统,主要限制进程的CPU使用率。 cpuset 子系统,可以为 cgroup 中的进程分配单独的CPU节点或者内存节点。 memory 子系统,可以限制进程的 Memory 使用量。 blkio 子系统,可以限制进程的块设备IO。 net_cls 子系统,可以标记 cgroup 中进程的网络数据包,然后可以使用 TC模块(Traffic Control)对数据包进行控制。 其中对于CPU和内存的cgroup的限制可通过下面的图对应。 对于需要高性能运行的程序,我们常会设置CPU Set,也即绑核的参数,减少程序运行过程中的上下文切换。 在内核中,对于CPU Cgroup的配置会影响一个进程的task_struct作为调度单元的scheduled_entity,并影响在CPU上的调度。 对于内存的限制,除了上面限制内存使用总量之外,Intel CPU还有MBA(memory bandwidth available)和MBM(memory bandwidth monitoring)可以限制CPU对于内存的访问带宽。 在内核中,对于内存 Cgroup的配置起作用在进程申请内存的时候,也即当出现缺页,调用handle_pte_fault进而调用do_anonymous_page的时候,会查看是否超过了配置,超过了就分配失败,OOM。 对于网络带宽QoS的限制,需要TC和cgroup联合起来使用。 TC可以构建一个HTB(Hierarchical Token Bucket)分层令牌桶规则树。 使用TC可以为某个网卡eth0创建一个HTB的排队规则,需要付给它一个句柄(1:)。 这是整棵树的根节点,接下来会有分支。例如图中有三个分支,句柄分别为(:10)、(:11)、(:12)。最后的参数default 12表示默认发送给1:12,也即发送给第三个分支。 通过下面的命令,可以创建HTB树的根节点。 tc qdisc add dev eth0 root handle 1: htb default 12   对于这个网卡,需要规定发送的速度。一般有两个速度可以配置,一个是rate,表示一般情况下的速度;一个是ceil,表示最高的速度。对于根节点来讲,这两个速度是一样的,于是创建一个root class,速度为(rate=100kbps,ceil=100kbps)。 通过下面的命令,创建HTB根节点下面的root class,并限制速度为100kbps。 tc class add dev eth0 parent 1: classid 1:1 htb rate 100kbps ceil 100kbps   接下来要创建分支,也即创建几个child class。每个child class统一有两个速度。三个分支分别为(rate=30kbps,ceil=100kbps)、(rate=10kbps,ceil=100kbps)和(rate=60kbps,ceil=100kbps)。 通过下面的命令,在root class下面创建了三个child class,并给每个child class限制了速度。 tc class add dev eth0 parent 1:1 classid 1:10 htb rate 30kbps ceil 100kbpstc class add dev eth0 parent 1:1 classid 1:11 htb rate 10kbps ceil 100kbpstc class add dev eth0 parent 1:1 classid 1:12 htb rate 60kbps ceil 100kbps 你会发现三个child class的rate加起来,是整个网卡允许的最大速度。 HTB有个很好的特性,同一个root class下的child class可以相互借流量,如果直接不在排队规则下面创建一个root class,而是直接创建三个class,它们之间是不能相互借流量的。借流量的策略,可以使得当前不使用这个分支的流量的时候,可以借给另一个分支,从而不浪费带宽,使带宽发挥最大的作用。 最后,创建叶子排队规则,分别为fifo和sfq,代码如下所示。 tc qdisc add dev eth0 parent 1:10 handle 20: pfifo limit 5tc qdisc add dev eth0 parent 1:11 handle 30: pfifo limit 5tc qdisc add dev eth0 parent 1:12 handle 40: sfq perturb 10 基于这个排队规则,我们还可以通过TC设定发送规则:从1.2.3.4来的、发送给port 80的包,从第一个分支1:10走;其他从1.2.3.4发送来的包从第二个分支1:11走;剩余的包走默认分支。代码如下所示。 tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip src 1.2.3.4 match ip dport 80 0xffff flowid 1:10tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip src 1.2.3.4 flowid 1:11 有了cgroup,我们按照cgroup再来设定规则。代码如下所示。 tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 1: cgroup 假设我们有两个用户a和b,要对它们进行带宽限制。 首先,我们要创建两个net_cls,代码如下所示。 mkdir /sys/fs/cgroup/net_cls/amkdir /sys/fs/cgroup/net_cls/b 假设用户a启动的进程ID为12345,把它放在net_cls/a/tasks文件中。同样假设用户b启动的进程ID为12346,把它放在net_cls/b/tasks文件中。 net_cls/a目录下面,还有一个文件net_cls.classid,放flowid 1:10。net_cls/b目录下面,也创建一个文件net_cls.classid,放flowid 1:11。 这个数字怎么放呢?要转换成一个0×AAAABBBB的值,AAAA对应class中冒号前面的数字,BBBB对应后面的数字。代码如下所示。 echo 0x00010010 > /sys/fs/cgroup/net_cls/a/net_cls.classidecho 0x00010011 > /sys/fs/cgroup/net_cls/b/net_cls.classid 这样用户a的进程发的包,会打上1:10这个标签;用户b的进程发的包,会打上1:11这个标签。然后tc根据这两个标签,让用户a的进程的包走左边的分支,用户b的进程的包走右边的分支。 Docker本身对于proc的隔离性做的不够,在容器内部proc文件系统中可以看到Host宿主机上的proc信息(如:meminfo, cpuinfo,stat, uptime等)。 lxcfs是一个开源的FUSE(用户态文件系统)实现来支持LXC容器。 LXCFS通过用户态文件系统,在容器中提供下列 procfs 的文件: /proc/cpuinfo /proc/diskstats /proc/meminfo /proc/stat /proc/swaps /proc/uptime 比如,把宿主机的 /var/lib/lxcfs/proc/memoinfo 文件挂载到Docker容器的/proc/meminfo位置后。容器中进程读取相应文件内容时,LXCFS的FUSE实现会从容器对应的Cgroup中 读取正确的内存限制。从而使得应用获得正确的资源约束设定,增强容器的隔离性。 接下来我们看对于硬盘的资源隔离。 其中对于磁盘资源配额,通过xfs_quota实现: 使用者、群组、目录 :XFS文件系统的quota限制中,主要是针对群组、个人或单独的目录进行磁盘使用率的限制。 容量、数量 :限制inode或block用量。 柔性、硬性 :限制soft和hard,通常hard的限制值比soft的限制值要高。 其中对于I/O的限制,对于直接I/O的限制,可以通过下面的参数控制: --device-read-bps:磁盘每秒最多可以读多少比特(bytes) --device-write-bps:磁盘每秒最多可以写多少比特(bytes) --device-read-iops:磁盘每秒最多可以执行多少 IO 读操作 --device-write-iops:磁盘每秒最多可以执行多少 IO 写操作 比较困难的是对于Buffered-IO带宽的限制。cgroup v1不支持buffer write io 限制,cgroup v2由于采用unified 层级设计,mem子系统和blk子系统联动,可以准确追踪buffer write时page 的cgroup属主,因而可以实现buffer write io 限制。如果目前使用cgroup v1,就需要内核团队进行定制化了。 2.2. 容器运行时原理及设计 CRI(Container Runtime Interface)是 Kubernetes 定义的与 contianer runtime 进行交互的接口,将 Kubernetes 与特定的容器解耦。 CRI实现了两个GRPC协议的API,提供两种服务ImageService和RuntimeService。 // grpcServices are all the grpc services provided by cri containerd.type grpcServices interface { runtime.RuntimeServiceServer runtime.ImageServiceServer} // CRIService is the interface implement CRI remote service server.type CRIService interface { Run() error // io.Closer is used by containerd to gracefully stop cri service. io.Closer plugin.Service grpcServices} 这两个GRPC负责和kubelet进行通信。 CRI的实现CRIService中包含了很多重要的组件: // criService implements CRIService.type criService struct { // config contains all configurations. config criconfig.Config // imageFSPath is the path to image filesystem. imageFSPath string // os is an interface for all required os operations. os osinterface.OS // sandboxStore stores all resources associated with sandboxes. sandboxStore *sandboxstore.Store // sandboxNameIndex stores all sandbox names and make sure each name // is unique. sandboxNameIndex *registrar.Registrar // containerStore stores all resources associated with containers. containerStore *containerstore.Store // containerNameIndex stores all container names and make sure each // name is unique. containerNameIndex *registrar.Registrar // imageStore stores all resources associated with images. imageStore *imagestore.Store // snapshotStore stores information of all snapshots. snapshotStore *snapshotstore.Store // netPlugin is used to setup and teardown network when run/stop pod sandbox. netPlugin cni.CNI // client is an instance of the containerd client client *containerd.Client......} 其中最重要的是cni.CNI,用于配置容器网络。还有containerd.Client,用于连接containerd来创建容器。 我们这里画了一个图列举一下CRI插件的代码工作逻辑。 如果你觉得默认的CRI不足以满足需求,可以实现自己的CRI插件。 另外,很多企业觉得容器没有内核,隔离性不好,因而可以是要轻量级虚拟化程序HyperContainer。 HyperContainer是一款基于虚拟化技术的容器方案,它允许大家利用现有标准虚拟化管理程序(包括KVM与Xen等)来启动Docker镜像。作为开源项目,HyperContainer由一套名为runV的OCI标准容器运行时和一个名为hyperd的守护程序共同构成。(https://github.com/hyperhq/hyperd) 因而有一个特殊的CRI叫做frakti,他可以使用runV通过轻量级的虚拟化方式运行Pod,他可以调用hyperd来运行HyperContainer。(https://github.com/kubernetes/frakti) 第三节,Kubernetes控制面设计与集群规模限制 接下来,我们讨论控制面,当容器集群规模比较小的时候,控制面压力不大,随着集群规模越大,控制面开始感受到压力,因而需要进行一定的优化。 控制面的三大组件分别是API Server,Controller Manager,Scheduler,我们一一解析他们的原理,可能遭遇到的瓶颈和优化方式。 3.1. API Server的原理及优化设计 API Server是Kubernetes的对外入口,他的主要功能是请求的路由和处理,简单说就是监听一个端口,把接收到的请求正确地转到相应的处理逻辑上。 API Server使用了go-restful框架,按照go-restful的原理,包含以下的组件 Container: 一个Container包含多个WebService WebService: 一个WebService包含多条route Route: 一条route包含一个method(GET、POST、DELETE, WATCHLIST等),一条具体的path以及一个响应的handler 在API Server中会通过InstallAPIs 和 InstallLegacyAPI来注册API接口,并关联到相应的处理对象RESTStorage。 例如在InstallLegacyAPI中,最重要的两个操作是NewLegacyRESTStorage和InstallLegacyAPIGroup。 其中NewLegacyRESTStorage就是生成处理对象RESTStorage,它里面有如下重要的逻辑。 restStorage := LegacyRESTStorage{}......podTemplateStorage, err := podtemplatestore.NewREST(restOptionsGetter)......nodeStorage, err := nodestore.NewStorage(restOptionsGetter, c.KubeletClientConfig, c.ProxyTransport)......podStorage, err := podstore.NewStorage( restOptionsGetter, nodeStorage.KubeletConnectionInfo, c.ProxyTransport, podDisruptionClient, )......restStorageMap := map[string]rest.Storage{ "pods": podStorage.Pod,...... "podTemplates": podTemplateStorage,...... "services": serviceRest,...... "endpoints": endpointsStorage,...... "nodes": nodeStorage.Node,......} 可以看出,这就是API路径和对应的处理对象RESTStorage的对应关系。 接下来InstallLegacyAPIGroup调用installAPIResources主要也是通过go-restful将API暴露。 installAPIResources遍历安装每个资源的API,对于每个API,调用InstallREST将自定义资源的API处理器注册到restful容器中。 注册处理器的操作在函数registerResourceHandlers中完成,包含不同的操作类型:POST、PUT、DELETE,WATCHLIST等。 对于其他的操作,处理对象会直接写入RawStorage,也即背后的ETCD集群,这里唯一比较特殊的是WATCHLIST,从第一节的原理我们可以看出,Kubernetes组件之间的协作是严重依赖WATCHLIST的,也即当ETCD中对象发生变化的时候,需要及时通知其他组件,并且让其他组件得到变化,这对ETCD的压力非常大。 API Server采取的方式就是在RawStorage之上,封装了一层CacherStorage,CacherStorage有一个成员是watchCache *watchCache,它应该是实现了一个资源对象信息的缓存。将通过和 etcd 通信而获取到的资源对象的信息缓存在内存中。当资源对象长时间未发生变化的时候,如果再有 List 或者 Watch 请求该资源对象的信息,可以直接返回给它缓存中的内容,而不再去和 etcd 通信,从而减轻etcd的压力。 CacherStorage还有一个成员是reflector *cache.Reflector,他会监听并处理ETCD发来的事件,交给CacherStorage,CacherStorage的dispatchEvents 函数会读取这个事件,分发给Watcher,Watcher为每一个请求启动一个 goroutine 不断的监听资源对象信息的变化,如果有新的消息过来就返回给客户端,从而实现了从ETCD层层通知,层层缓存,到达客户端的作用。 通过这里的原理解析我们知道,ETCD作为Kubernetes唯一的持久化存储组件,不但承载了对象的存储功能,还有对象的变化通知功能,压力是非常大的。 因而这里对于ETCD的配置,一定要用SSD盘,这对整个集群的响应时延非常关键,另外ETCD对于存储量有限制,可以配置quota-backend-bytes。 目前存储在ETCD里面的数据比较多,除了主流的Pod,Service这些,event和ConfigMap也会占用很大的量,Event主要用来保存各个组件的运行状态,可以通过他发现异常,Event数据写入比较频繁,带来压力比较大,又不是特别关键的数据,可以分ETCD集群存储。按照官方文档,可以如下配置。 --etcd-servers-overrides=/events#https://0.example.com:2381;https://1.example.com:2381;https://2.example.com:2381 另外ConfigMap如果存储的配置项比较多,也会比较大,建议使用Apollo配置中心,而不要直接使用容器的配置中心。 很多大规模容器平台到了后期,会对ETCD做类似分库分表的操作,以减轻压力,增加扩展性,例如如果一个Kubernetes集群给多个租户使用,可以讲不通租户的数据存放在不同的ETCD分片中,按照上面的原理分析,可以通过修改RawStorage这一层的方式实现。 不过由于Kubernetes本身社区更新速度较快,不建议自己修改Kubernetes核心代码,因为一旦修改了,再合并到社区就很难做到,因而宁可采取多Kubernetes集群的方式,也不太建议做ETCD的分库分表。 3.2. Controller Manager的原理及优化设计 controller-manager作为集群的管理控制中心,维护集群中的所有控制器,对维持集群的稳定和自我修复,实现高可用,副本控制等起关键作用。 controller-manager里面集成了多种多样的控制器,在 NewControllerInitializers中是这样定义的 func NewControllerInitializers(loopMode ControllerLoopMode) map[string]InitFunc { controllers := map[string]InitFunc{} controllers["endpoint"] = startEndpointController controllers["replicationcontroller"] = startReplicationController...... controllers["daemonset"] = startDaemonSetController...... controllers["deployment"] = startDeploymentController controllers["replicaset"] = startReplicaSetController controllers["horizontalpodautoscaling"] = startHPAController...... controllers["statefulset"] = startStatefulSetController...... controllers["service"] = startServiceController...... return controllers} 这里面对每一个Controller都设置了启动函数,每个Controller的架构如图所示: 例如对于replicaset,启动controller的时候调用的就是startReplicaSetController。 在startReplicaSetController中,会调用 NewReplicaSetController创建控制器 go replicaset.NewReplicaSetController( ctx.InformerFactory.Apps().V1().ReplicaSets(), ctx.InformerFactory.Core().V1().Pods(), ctx.ClientBuilder.ClientOrDie("replicaset-controller"), replicaset.BurstReplicas, ).Run(int(ctx.ComponentConfig.ReplicaSetController.ConcurrentRSSyncs), ctx.Stop) 在这里InformerFactory会生成Informer,对于ReplicaSet来讲,需要监听自己和Pod的变化,因而又这两个Informer就够了。 Informer 是 Client-go 中的一个核心工具包。如需要 List/Get Kubernetes 中的 Object(包括pod,service等等),可以直接使用 Informer 实例中的 Lister()方法(包含 Get 和 List 方法)。Informer 最基本的功能就是 List/Get Kubernetes 中的 Object,还可以监听事件并触发回调函数等。 Informer 的 Lister() 方法(List/Get)不会去请求 API Server,而是查找缓存在Informer本地内存中的数据,可以减少对 API Server的压力。 Informer 会调用 API Server的List 和 Watch 的 API。Informer 在初始化的时,先调用 List API 获得资源的全部 ,缓存在内存中,然后调用 Watch API 去 watch 这种 resource,维护这份缓存保持一致性。 Informer 还可以自定义回调函数ResourceEventHandler,可以实现 OnAdd,OnUpdate,OnDelete 方法,分别对应 informer 监听创建、更新和删除事件类型。 我们重点看Pod的Informer,他的定义和创建过程如下 type PodInformer interface { Informer() cache.SharedIndexInformer Lister() v1.PodLister} func (f *podInformer) Informer() cache.SharedIndexInformer { return f.factory.InformerFor(&corev1.Pod{}, f.defaultInformer)} func (f *podInformer) defaultInformer(client kubernetes.Interface, resyncPeriod time.Duration) cache.SharedIndexInformer { return NewFilteredPodInformer(client, f.namespace, resyncPeriod, cache.Indexers{cache.NamespaceIndex: cache.MetaNamespaceIndexFunc}, f.tweakListOptions)} func NewFilteredPodInformer(client kubernetes.Interface, namespace string, resyncPeriod time.Duration, indexers cache.Indexers, tweakListOptions internalinterfaces.TweakListOptionsFunc) cache.SharedIndexInformer { return cache.NewSharedIndexInformer( &cache.ListWatch{ ListFunc: func(options metav1.ListOptions) (runtime.Object, error) { return client.CoreV1().Pods(namespace).List(context.TODO(), options) }, WatchFunc: func(options metav1.ListOptions) (watch.Interface, error) { return client.CoreV1().Pods(namespace).Watch(context.TODO(), options) }, }, &corev1.Pod{}, resyncPeriod, indexers, )} func NewSharedIndexInformer(lw ListerWatcher, exampleObject runtime.Object, defaultEventHandlerResyncPeriod time.Duration, indexers Indexers) SharedIndexInformer { realClock := &clock.RealClock{} sharedIndexInformer := &sharedIndexInformer{ processor: &sharedProcessor{clock: realClock}, indexer: NewIndexer(DeletionHandlingMetaNamespaceKeyFunc, indexers), listerWatcher: lw, objectType: exampleObject, resyncCheckPeriod: defaultEventHandlerResyncPeriod, defaultEventHandlerResyncPeriod: defaultEventHandlerResyncPeriod, cacheMutationDetector: NewCacheMutationDetector(fmt.Sprintf("%T", exampleObject)), clock: realClock, } return sharedIndexInformer} 创建的是sharedIndexInformer,他有几个个重要的成员: ListerWatcher:定义了两个函数List和Watch,通过API Server的客户端发现对象的变化 Indexer:是本地的缓存,被索引方便查找 Controller:从ListerWatcher监听到对象的变化,然后放入DeltaFIFO队列中 有了Informer之后,我们回到NewReplicaSetController,他会创建ReplicaSetController rsc := &ReplicaSetController{ GroupVersionKind: gvk, kubeClient: kubeClient, podControl: podControl, burstReplicas: burstReplicas, expectations: controller.NewUIDTrackingControllerExpectations(controller.NewControllerExpectations()), queue: workqueue.NewNamedRateLimitingQueue(workqueue.DefaultControllerRateLimiter(), queueName),} rsInformer.Informer().AddEventHandler(cache.ResourceEventHandlerFuncs{ AddFunc: rsc.addRS, UpdateFunc: rsc.updateRS, DeleteFunc: rsc.deleteRS,}) podInformer.Informer().AddEventHandler(cache.ResourceEventHandlerFuncs{ AddFunc: rsc.addPod, // This invokes the ReplicaSet for every pod change, eg: host assignment. Though this might seem like // overkill the most frequent pod update is status, and the associated ReplicaSet will only list from // local storage, so it should be ok. UpdateFunc: rsc.updatePod, DeleteFunc: rsc.deletePod,}) rsc.syncHandler = rsc.syncReplicaSet 这里面定义了workqueue,以及podInformer当监听到事件后的处理函数,还有syncHandler,这个函数后面会用。 例如当一个Pod被删除的时候,rsc.deletePod会被调用。 // When a pod is deleted, enqueue the replica set that manages the pod and update its expectations.// obj could be an *v1.Pod, or a DeletionFinalStateUnknown marker item.func (rsc *ReplicaSetController) deletePod(obj interface{}) { pod, ok := obj.(*v1.Pod)...... controllerRef := metav1.GetControllerOf(pod)...... rs := rsc.resolveControllerRef(pod.Namespace, controllerRef)...... rsKey, err := controller.KeyFunc(rs)...... rsc.expectations.DeletionObserved(rsKey, controller.PodKey(pod)) rsc.queue.Add(rsKey)} 在rsc.deletePod中,找到这个pod属于的ReplicaSet,然后放到workqueue中等待处理。 我们再回到NewReplicaSetController,在创建了ReplicaSetController之后,会调用他的Run函数。 // Run begins watching and syncing.func (rsc *ReplicaSetController) Run(workers int, stopCh 第四节,Kubernetes CNI原理与网络设计 控制面看完了,我们接着看数据面,先来看网络数据面。 数据面的解析分为两个部分,一个是CNI,一个是ingress 4.1. CNI原理与定制化设计 就像上面兼容性那一节讲的一样,如果你不想用默认的网络组建,可以自己开发CNI来对接公司的SDN。 我们这里就来解析一下CNI的原理。 CNI是Container Network Interface的是一个标准的,通用的接口,用于连接容器管理系统和网络插件。 CNI插件是可执行文件,会被kubelet调用。启动kubelet --network-plugin=cni,--cni-conf-dir 指定networkconfig配置,默认路径是:/etc/cni/net.d,并且,--cni-bin-dir 指定plugin可执行文件路径,默认路径是:/opt/cni/bin。 CNI plugin 只需要通过 CNI 库实现两类方法, 分别是创建容器时调用, 以及删除容器时调用. 三种类型的插件:main,meta和ipam: main插件:提供某种网络功能,比如使用的brdige,以及loopback,ipvlan,macvlan等等 meta插件:不能作为独立的插件使用,需要调用其他插件,例如flannel,或者配合其他插件使用,例如portmap ipam插件:对所有CNI插件共有的IP管理部分的抽象,从而减少插件编写过程中的重复工作,官方提供的有dhcp和host-local两种类型 在这里面有一些CNI插件的实现: (https://github.com/containernetworking/plugins) 每一种K8S网络方案也要有自己的CNI插件,例如上面我们讲的Calico,我们这里解析一下他的插件实现。 (https://github.com/projectcalico/cni-plugin) calico 解决不同物理机上容器之间的通信,而 calico-plugin 是在 k8s 创建 Pod 时为 Pod 设置虚拟网卡(容器中的 eth0和 lo 网卡),calico-plugin 是由两个静态的二进制文件组成,由 kubelet 以命令行的形式调用,这两个二进制的作用如下: calico-ipam:分配维护IP,依赖etcd calico:系统调用API来修改namespace中的网卡信息 在Calico插件里面,会注册两个函数cmdAdd和cmdDel,用于对应添加网卡和删除网卡两个操作。 我们这里重点分析cmdAdd。 第一,获取Calico的配置,节点的名称,Calico客户端,是为了生成这个Pod唯一的WEP(Workload Endpoint)名称,也即网卡的名称。 // Unmarshal the network config, and perform validationconf := types.NetConf{}// Determine which node name to use.nodename := utils.DetermineNodename(conf)// Extract WEP identifiers such as pod name, pod namespace (for k8s), containerID, IfName.wepIDs, err := utils.GetIdentifiers(args, nodename)calicoClient, err := utils.CreateClient(conf)// Calculate the workload name prefix from the WEP specific identifiers// for the given orchestrator.wepPrefix, err := wepIDs.CalculateWorkloadEndpointName(true) // Check if there's an existing endpoint by listing the existing endpoints based on the WEP name prefix.endpoints, err := calicoClient.WorkloadEndpoints().List(ctx, options.ListOptions{Name: wepPrefix, Namespace: wepIDs.Namespace, Prefix: true})var endpoint *api.WorkloadEndpointfor _, ep := range endpoints.Items { match, err := wepIDs.WorkloadEndpointIdentifiers.NameMatches(ep.Name) if match { endpoint = &ep // Assign the WEP name to wepIDs' WEPName field. wepIDs.WEPName = endpoint.Name // Put the endpoint name from the matched WEP in the identifiers. wepIDs.Endpoint = ep.Spec.Endpoint break }}// If we don't find a match from the existing WorkloadEndpoints then we calculate// the WEP name with the IfName passed in so we can create the WorkloadEndpoint later in the process.if endpoint == nil { wepIDs.Endpoint = args.IfName wepIDs.WEPName, err = wepIDs.CalculateWorkloadEndpointName(false)} 第二,就是将这个网卡和Pod关联起来 先是调用IPAM插件,获得一个IP地址 // 1) Run the IPAM plugin and make sure there's an IP address returned.ipamResult, err := ipam.ExecAdd(conf.IPAM.Type, args.StdinData) 然后是创建endpoint对象 // 2) Create the endpoint objectendpoint = api.NewWorkloadEndpoint()endpoint.Name = wepIDs.WEPNameendpoint.Namespace = wepIDs.Namespaceendpoint.Spec.Endpoint = wepIDs.Endpointendpoint.Spec.Node = wepIDs.Nodeendpoint.Spec.Orchestrator = wepIDs.Orchestratorendpoint.Spec.ContainerID = wepIDs.ContainerIDendpoint.Labels = labelsendpoint.Spec.Profiles = []string{profileID} 然后是对于网络的配置 // 3) Set up the vethd, err := dataplane.GetDataplane(conf, logger)// Select the first 11 characters of the containerID for the host veth.desiredVethName := "cali" + args.ContainerID[:utils.Min(11, len(args.ContainerID))]hostVethName, contVethMac, err := d.DoNetworking(args, result, desiredVethName, utils.DefaultRoutes, endpoint, map[string]string{})endpoint.Spec.MAC = contVethMacendpoint.Spec.InterfaceName = hostVethName 在DoNetworking里面,我们看到的是对于网络的配置命令。 先是建立veth pair,一边是contVethName,将来是容器内的,另一边是hostVethName,将来是容器外的。 veth := &netlink.Veth{ LinkAttrs: netlink.LinkAttrs{ Name: contVethName, Flags: net.FlagUp, MTU: d.mtu, }, PeerName: hostVethName, } netlink.LinkAdd(veth) 然后给容器外的网卡设置MAC地址,状态设置为UP hostVeth, err := netlink.LinkByName(hostVethName) netlink.LinkSetHardwareAddr(hostVeth, mac)netlink.LinkSetUp(hostVeth) 然后给容器内的网卡设置MAC地址,IP地址,路由等 // Fetch the MAC from the container Veth. This is needed by Calico.contVethMAC = contVeth.Attrs().HardwareAddr.String()// Add a connected route to a dummy next hop so that a default route can be setgw := net.IPv4(169, 254, 1, 1)gwNet := &net.IPNet{IP: gw, Mask: net.CIDRMask(32, 32)}err := netlink.RouteAdd( &netlink.Route{ LinkIndex: contVeth.Attrs().Index, Scope:     netlink.SCOPE_LINK, Dst:       gwNet, },)for _, r := range routes { ip.AddRoute(r, gw, contVeth)} // Now add the IPs to the container side of the veth.for _, addr := range result.IPs { netlink.AddrAdd(contVeth, &netlink.Addr{IPNet: &addr.Address})}d.configureContainerSysctls(hasIPv4, hasIPv6) 然后将host端的网卡从容器移出去,配置路由 // Now that the everything has been successfully set up in the container, move the "host" end of the// veth into the host namespace.netlink.LinkSetNsFd(hostVeth, int(hostNS.Fd()))d.configureSysctls(hostVethName, hasIPv4, hasIPv6)// Moving a veth between namespaces always leaves it in the "DOWN" state. Set it back to "UP" now that we're// back in the host namespace.hostVeth, err := netlink.LinkByName(hostVethName)netlink.LinkSetUp(hostVeth)// Now that the host side of the veth is moved, state set to UP, and configured with sysctls, we can add the routes to it in the host namespace.SetupRoutes(hostVeth, result) 理解了CNI的工作原理,我们也可以开发自己的插件,和自己原来的网络环境相融合。 拓扑约束依赖于节点标签来标识每个节点所在的拓扑域。 假设拥有一个具有以下标签的 4 节点集群: NAME STATUS ROLES AGE VERSION LABELSnode1 Ready 4m26s v1.16.0 node=node1,zone=zoneAnode2 Ready 3m58s v1.16.0 node=node2,zone=zoneAnode3 Ready 3m17s v1.16.0 node=node3,zone=zoneBnode4 Ready 2m43s v1.16.0 node=node4,zone=zoneB 可以定义一个或多个 topologySpreadConstraint 来指示 kube-scheduler 如何将每个传入的 Pod 根据与现有的 Pod 的关联关系在集群中部署。字段包括: maxSkew 描述 pod 分布不均的程度。这是给定拓扑类型中任意两个拓扑域中匹配的 pod 之间的最大允许差值。它必须大于零。 topologyKey 是节点标签的键。如果两个节点使用此键标记并且具有相同的标签值,则调度器会将这两个节点视为处于同一拓扑中。调度器试图在每个拓扑域中放置数量均衡的 pod。 whenUnsatisfiable 指示如果 pod 不满足扩展约束时如何处理: DoNotSchedule(默认)告诉调度器不用进行调度。 ScheduleAnyway 告诉调度器在对最小化倾斜的节点进行优先级排序时仍对其进行调度。 labelSelector 用于查找匹配的 pod。匹配此标签的 pod 将被统计,以确定相应拓扑域中 pod 的数量。

    时间:2020-09-18 关键词: 架构师 运维

  • Linux系统网站运维

    美国服务器Linux系统网站的运维管理知识已经与您共享,运维管理当然需要运维工具和维护的支持。 以下编辑器发布了用于操作和维护美国服务器Linux系统网站的工具。 美国服务器Linux系统网站运维配置类工具:Capistrano、Chef、 puppet func、 salstack Ansible、 rundeck 美国服务器Linux系统网站运维监控类工具: Cacti、基于时间监控前端Grafana、 Mtop、 MRT(网络流量监控图形工具、Monit 美国服务器Linux系统网站运维性能监控工具:sar性能监控和瓶颈检查、dstat多类型资源统计、slabtop内核slab缓存信息、nmon类Unix系统性能监控、iperf网络性能工具、sysdig系统进程高级视图、tcpdump网络抓包、、collect性能监控工具iftop类似top的网络连接工具、smem高级内存报表 美国服务器Linux系统网站运维免费APMI具: mmtrix全面的分析工具、alibench 美国服务器Linux系统网站运维进程监控: mmonit、Supervisor 美国服务器Linux系统网站运维日志系统: Logstash、Scribe 美国服务器Linux系统网站运维绘图工具: RRDtool、Gnuplot 美国服务器Linux系统网站运维流控系统: Panabit.在线数据包分析工具、Pcap Analyzer 美国服务器Linux系统网站运维安全检查: chrootkit、Rkhunter 美国服务器Linux系统网站运维持续集成: Go、Jenkins、 Gitlab 美国服务器Linux系统网站运维磁盘压测: fio、iozone 美国服务器Linux系统网站运维MySQL监控: mytop、orzdba、SQL级监控mysqlpcap、拓扑可视化工具 美国服务器Linux系统网站运维MySQL基准测试: mysqlsla. sql-bench. Super Smack. Percona's TPCC-MYSQL Tool. Sysbench 美国服务器Linux系统网站运维MySQL Proxy: SOHU-DBProxy. Altas、 cobra 美国服务器Linux系统网站运维MySQL逻辑备份工具: mysqldump、 mysqlhotcopy. mydumper. MySQLDumper 、mk-parallel-dump/mk parallel-restore 美国服务器Linux系统网站运维MySQL物理备份工具: Xtrabackup. LVM Snapshot 美国服务器Linux系统网站运维MongoDB压测:ibench&sysbench 以上就是美国服务器Linux系统网站运维工具的分享,希望能帮助到有需要的美国服务器用户。

    时间:2020-09-14 关键词: Linux 服务器 运维

  • 话说学习linux改变人生

    无论您学习什么,兴趣和持久性都是两个最重要的方面,因为兴趣可以使您更容易入门,持久性可以帮助您成功,学习Linux也不例外! 大学毕业的两年时间里,我干过销售,做过文员,当过前台,适合女生的工作换了一次又一次,并不是吃不了苦,只是我每次的工作都是迫于生计,都不是我所喜欢的。而Linux技术行业不一样,可以这样说,虽然它并不是最轻松的,但确是最理想的,最喜欢的。 我喜欢计算机!看着电视剧与电影中,黑客主角们,手在键盘上打出的悦耳节奏,与扫一眼就能看懂没有任何中文的代码,别提心中有多么崇拜与羡慕了。但空有一肚子的喜欢,根本无用,而一年前的我,也不会想象得到自己会从事这份工作,一直以为这个埋藏在心底的计算机梦想,终究只会是想想而已,并没有得到很大的重视。 好在毕业后人生迷茫聊以度日的日子里,有个朋友指点我转行,也是他的无私教导让我真正开始鼓起勇气,打破原定的安稳却不喜欢的生活,开始追逐那个埋藏在心底,不敢与人说的梦想。 记得他曾经告诉过我,市面上有许多可以学习linux的书,但是大多数都只有生硬的知识概念,枯燥乏味不说,还不易懂,根本不适合什么都不懂的菜鸟!但是他推荐我《linux就该这样学》,容易上手,它从准备工具,到如何安装linux软件直到如何部署动态网络环境,都十分详细的记录在了书本上,其中还有大多数的图片,可以帮助菜鸟更好的理解linux,不会因为乏味枯燥看不懂而放弃学习linux。 可以这样说,这本书他就是为了新手们量身定做的,它可以让你了解linux,垫上入门的砖,即使是毫无基础的新人,毕竟古话说得好,兴趣才是最好的老师。 我会学习并且从事运维技术行业,自然与我对计算机的崇拜和喜欢,有这密不可分的缘故,自小起,我就喜欢看与黑客有关的电视剧与电影,比如说前不久红极一时的《微微一笑很倾城》,里面肖奈与ko的编码较量就看得我热血沸腾,还有小时候美国的电影《黑客帝国》《骇客追缉令》之类的,都是我的最爱。 而凡事都贵在坚持,难在坚持。刚学习linux的前三个月,放弃的念头可以说是经常在我的脑海中徘徊,虽说学习linux与英语的好坏并没有特别大的关系,但是它的编码还是由26个字母组成,对于我这种看见字母就发怵的人,还是会有些畏惧,特别是每次看见复杂难懂的命令和脚本,总会让我感到抓狂。 好在我的身边有朋友。一本好书,详尽的讲解可以帮助我很好的理解那些生硬难懂的命令与脚本,再加上朋友的督促指导,半途而废的念头从时有时无到彻底消失。 当然实验才是检验真理的唯一标准,所以书中的理论知识再生动形象,也没有亲自实验获得的知识多,所以这本书,就是从一开始便教你如何在实验之中理解有关于linux的专业知识。 如今想想,好在我坚持下来了,如果当初真的放弃了,现在一时富足的美好生活怎么样不说,我的梦想肯定会再次石沉大海,而生活也会恢复到之前那种没有梦想,日日为了没有目标混日子而发愁的生活。 有了兴趣与坚持,我想这个世界上,不会有你学不会的事。而同时,学习linux,也可以成为人生的一个新的机遇,即使之前对于计算机行业无感的人,也可以去试着接触一下linux。 而且自我从事这个行业之后,也认识了好多半路出家,靠着极大的魄力转行学习linux,从而改变了自己的一生。 不论是本就喜欢计算机行业还是想要改变人生,选择linux运维技术行业,都是不错的选择,但最重要的是,入门之后,不要轻言放弃,毕竟半途而废放在任何事物上,都会落上一事无成的结果。 如果你喜欢这个行业,那就请你相信你自己,不要害怕,不要轻言放弃,不要觉得自己不是对口专业毕业,而不敢从事这个行业,毕竟现在毕业的大学生研究生,有多少出了校园后,干这之前未涉及过得行业?不用说别人,我自己原本就只是学艺术的,与计算机完全没有任何关系,现在也依旧干的很好! 更不要害怕linux运维技术行业的前景不好,恰恰相反,linux运维技术行业,可以说是近几年来,飞快兴起的行业,而面对现在科技高速发展的互联网时代,linux完全顺潮流发展,当然是不会落伍!只会是最富有潜力的行业。 请不要害怕身边没有朋友涉足或者自己未曾涉足过这个行业,而不敢尝试,我记得我在一本励志散文书中,看到过一句话,概意是‘想要成功只有俩种选择,一是,将别人都会做的事情做到极致,方能成功,二是,去做别人不敢做的事情!’ 敢踏入linux行业,你就会比哪些不敢尝试新事物的人,成功了一步,书是最好的朋友,兴趣是最好的老师,只要你想要,会有水滴石穿,铁杵磨成针的那天。

    时间:2020-07-11 关键词: Linux 编码 运维

  • 安防运维市场正逐步转向智能运维,市场仍需行业共同培育

    随着视频监控系统规模的扩大,城市进一步朝监控全覆盖进行,以“百万”为单位的监控摄像头开始被交付使用,一个问题被摆上了面前:谁来对这些动辄上万个监控设备进行维修、管理,以保证监控设备的正常运行?不同型号、不同厂家的摄像头能否进行统一维修管理?从维护城市长治久安的角度看,完备的安防运维服务必不可少,专业的安防运维团队必不可少。 俗话说得好,好的项目,三分靠建设,七分靠保养。安防运维服务,相当于产品的售后服务,是安防体系建设的“最后一公里”。对安防企业来说,“最后一公里”意义重大,对用户的满意度起着决定性作用,一定程度上影响着安防企业的成败,是品牌建设的重要一环,更是安防行业不可或缺的组成部分。 近年来,激增的安防设备以及原有监控改造需求,对安防运维服务提出了新要求。此外,《关于加强公共安全视频监控建设联网应用工作的若干意见》等相关文件也对安防运维建设给予了一定的支持。市场、政策的双重推动下,建立专业化、市场化的运维服务团队是大势所趋,根据当下安防行业发展,专家认为未来运维服务业务范围将向以下几个方面发展,包括安防培训服务。系统故障处理,工程的升级、改造、扩容服务,运维服务外延---安防服务外包。 目前,虽然一大批安防运维团队和企业如雨后春笋般涌现,但安防市场上运维服务还没有形成系统化、产业化、更多的企业是以“以租代建,商业运营”的方式解决目前运维需求。此外,新时代下,运维服务业面临新的挑战,包括标准不统一,产品通讯协议还未完全打动,产品也是天差地别,难以集中管理;联网、智能化分析需求增加,要求安防运维做到及时性、准确性、可追溯性,考验运维服务的技术实力; 根据挑战可见,安防行业运维服务不能再同以前一样,仅停留在故障检修,设备维护,还需要安防企业引进先进科学的运维流程和闭环机制,整合运维资源,提高团队专业素质和技术,完善故障发现、修护、日常管理等流程,形成统一高效的一体化运维服务,保障安防工程安全、搞笑、稳定、持续运行。以下几个方面的值得重视:企业在加强运维服务的同时,还要开发创造增值业务,形成差异化发展;有条件的话,为用户提供定制化服务。安防企业应该制定阶梯化收费标准,将项目运维收费标准化;安防企业一方面要提高运维人员专业素质,另一方面还要大数据等技术与运维服务的融合。 结语:运维不易,市场仍需行业共同培育。安防运维市场正在从传统的运维模式走向全新的智能运维,在这过程中,需要行业一起行动,各家企业有必要加强交流、合作,共同完善安防运维服务。 一件技术性产品不仅需要它质量的过硬,更需要它后期的服务保障,安防产品也是一样如此。设备的技术升级、故障维修、保养维护都是维护客户群体和企业形象的最佳手段。安全省心才是客户需要的!

    时间:2020-07-08 关键词: 安防 运维

  • 云计算的冲击:传统运维,你还有多久会消失?

    “虚拟化”,“公有云”,“混合云”,“容器”,“云原生”,这些技术词汇正诠释着我们当下所处的云时代现有的样子。 上图来自Gartner官网 。2019年11月13日,Gartner,Inc预测,到2020年,全球公共云服务市场将从2019年的2278亿美元增长到2664亿美元,增长17%。(这里指的公有云服务包括:BPaaS =业务流程即服务;IaaS =基础架构即服务;PaaS =平台即服务;SaaS =软件即服务;CMSS=云管理和安全服务)。同时预测到2022年,公共云服务市场将达到3546亿美元。暂且不去推敲Gartner预测的数值是否正确,但从另一个角度,看近几年主流公有云的财报可以发现营收全部都在增长(亚马逊发布的2020财年第一季度财报显示,一季度亚马逊云计算业务营收102亿美元,同比增长33%;2020财年,阿里云财年收入破400亿元人民币,比上一年度增长62%)。 前有Gartner的预测,后有主流公有云的财报,这已经说明了一个事实,云时代确实到了,云运维的时代确实到了。 好了,到这里,可以引出这次的主题了。传统运维,你还有多久会消失?这绝对不是危言耸听,这一切正在一步步的向我们走来。 云时代之前,运维是什么样子。 公司要上线一个业务,大概的步骤是这样的:首先需要找数据中心,找网络(网络还分电信/联通/移动/BGP),还要测试网络质量,然后租机柜,买/租服务器,然后装系统,配交换机,配防火墙,配负载均衡,配安全防护设备,安装环境,部署业务,添加监控,进行安全合规扫描,进行渗透测试确保没有漏洞等等。 上面的各个环节在大公司里面都有专门的人负责: 负责找数据中心,租机柜,买/租服务器,然后装系统的叫IDC系统运维; 负责找网络测试网络质量,配交换机,配网络的叫网络工程师;负责配防火墙,配负载均衡,配安全防护设备,安全合规扫描的叫安全运维; 负责安装环境,部署业务的叫应用运维SRE; 负责添加监控的叫监控运维; 也许看到这里你会对号入座,如果你在里面找到了自己的位置,那么这里的传统运维说的就是你了。 最早的公有云AWS是2006年出现的,那时也只是买云主机,但到现在2020年,AWS提供的服务早已突破了100个,从计算、数据库、大数据、到机器学习、物联网、区块链,甚至卫星、量子技术、机器人都可以作为服务提供给所有人。AWS是行业的先驱,不过我们国内的阿里云、华为云、腾讯云也不弱,也提供了50+的服务,所有人都可以按需购买使用。试想一下,这么多技术,这么多服务,如果都自己搞的话,技术团队需要多少人,不说别的就计算资源这块,自建私有云,怎么着也得1-2个人吧,而且还得特别牛逼的那种;而现在你可以一个都不需要。 这么看来大家如果都用云了,是不是传统运维都要失业了? 非也,首先,大家都用云就是一个伪命题,总有人不用或者不愿意用的,美其名曰为了安全(拿来忽悠可以,真实原因可能远不止安全),那他们就需要传统运维;第二,就是去公有云服务商,像AWS、阿里云、华为云、腾讯云等公有云厂商,他们把传统运维要干的事情都集中起来了,即使自动化做的再好,系统、网络、安全、还是要人的,当然他们的要求非常高。 说到这里,似乎传统运维转型对于大多数传统运维来说是唯一的选择了,其实这个观点一点也不新,因为DevOps已经提了好几年了,什么是DevOps呢? 用我的理解,就是让运维也去写代码,写平台,慢慢融入研发,给研发打打下手,写写工具啥的,和纯开发还是有区别的。那么,DevOps是传统运维最好的转型方向吗? 我的答案是NO。 现在最火的技术是什么?容器,Kubernetes,它正在成为运维的标配技能。就像几年前的虚拟化一样。 大家有没有想过为什么,容器会那么火,表面上容器主要是解决业务和环境一致性的问题,再往深里想,容器是带着替代传统运维的使命来的,没有了环境一致性的问题,放在哪里都运行,那要运维做什么,只要研发写好代码,写好Dockerfile,给个主机就是跑起来了,出问题了也不用修复,直接干掉老容器,起一个新的就可以了,在加上Kubernetes,连这些帮你做了,那传统运维该怎么办,学写Dockerfile吗?太简单的东西,根本不需要专门的人写,研发写代码时顺便写写就行了。 这么看,转容器也不是最好的选择 ,那到底什么是传统运维转型最好的选择?三个字“云运维”。 为什么说云运维是传统运维转型的最佳选择? 首先 ,公有云的服务越来越多,用哪些服务,怎么用,每个服务都有什么特性,哪些参数可以配置,都有哪些限制。 这些往往是很细的,在使用之前如果没搞清楚,上线之后就可能出现各种问题,所以传统运维可能会倾向于只选择云主机,然后剩下的东西都自己部署: 1、可能是为了体验自己的价值; 2、可能是对云服务不了解,不会用; 3、可能好忽悠老板,云服务贵等等,但是他肯定不会说,人力其实也挺贵; 但是对于如何用好云,却是云运维最擅长的。熟悉公有云的脾气,合理的设计架构,业务稳定性绝对比自己搭建服务要高;除非你觉得你的技术比AWS、阿里云里面的架构师更强。 第二,因为公有云上提供的服务都属于标准服务,在不同行业业务中使用的时候,未必都那么顺手,不少需要进行适配,大到业务架构,小到配置参数。既然上云趋势摆在那里,那么如何协调现有业务和云服务之间的适配问题,就是云运维必须解决的,有时需要研发改代码,有时需要调整一点架构,但其中的主导者应该是云运维。 最后,还有一些存量系统,对于老公司这是一个绕不开的问题,硬件老化,逼得老系统上云,这也是需要云运维才能搞定的。 既然云运维是传统运维转型的最佳选择,那么传统运维要怎么转云运维呢?笔者想了几点,但可能不全,大家可以各持己见。 第一,多去了解公有云上都有哪些服务,这些服务都怎么使用,尽可能在工作中尝试使用,或者引导研发来使用。 第二,尝试将传统运维中的一些工作,在云上实现,比如传统的CI/CD, 堡垒机,在云上应该怎么弄;这里推荐一个云上编排工具Terraform,如果想试试云运维,Terraform 你值得拥有。 第三,入职一家CloudMSP服务商,因为他们的工作就是帮助用户选云、上云、用云,在工作中学习,进步是最快的。新钛运维就是一家国内主流的CloudMSP,可以在招聘网站上搜一搜,也许它会成为你职业生涯的转折点。 写在最后,运维存在的价值就是维护业务的稳定,不管是传统运维,还是运维云 ,我们的使命和存在的意义没有变过,只是时代在变,所以我们也需要改变。

    时间:2020-07-03 关键词: 云计算 云原生 运维

  • 利用6 个 Linux 运维典型问题来分析处理问题的思路

    作为一名合格的 Linux 运维工程师,一定要有一套清晰、明确的解决故障思路,当问题出现时,才能迅速定位、解决问题,这里给出一个处理问题的一般思路: 重视报错提示信息:每个错误的出现,都是给出错误提示信息,一般情况下这个提示基本定位了问题的所在,因此一定要重视这个报错信息,如果对这些错误信息视而不见,问题永远得不到解决。 查阅日志文件:有时候报错信息只是给出了问题的表面现象,要想更深入的了解问题,必须查看相应的日志文件,而日志文件又分为系统日志文件(/var/log)和应用的日志文件,结合这两个日志文件,一般就能定位问题所在。 分析、定位问题:这个过程是比较复杂的,根据报错信息,结合日志文件,同时还要考虑其它相关情况,最终找到引起问题的原因。 解决问题:找到了问题出现的原因,解决问题就是很简单的事情了。 从这个流程可以看出,解决问题的过程就是分析、查找问题的过程,一旦确定问题产生的原因,故障也就随之解决了。 结合上面介绍的 Linux 运维问题的解决思路后,下面我们挑选了6个比较典型的 Linux 运维问题,来看看是如何分析和解决的:   问题 1:文件系统破坏导致系统无法启动 Checking root filesystem /dev/sda6 contains a file system with errors, check forced An error occurred during the file system check 这个错误可以看出,操作系统 / dev/sda6 分区文件系统出现了问题,这个问题发生的机率很高,通常引起这个问题的原因主要是系统突然断电,引起文件系统结构不一致,一般情况下,解决此问题的方法是采用 fsck 命令,进行强制修复。 # umount /dev/sda6 # fsck.ext3 -y /dev/sda6 问题 2:“Argument list too long” 错误与解决方法 # crontab -e 编辑完后保存退出后,报错 no space left on device 根据上面的报错了解到是磁盘空间满了,那么首先是检查磁盘空间, # df -h 查看到是 / var 磁盘分区空间已经达到 100%,至此定位了问题所在。是 / var 磁盘空间饱满导致,因为 crontab 会在保存时将文件信息写到 / var 目录下面,然而这个磁盘没有空间了,所以报错。 接着通过命令 du –sh * 命令检查 / var 目录下面的所有文件或者目录的大小,发现 / var/spool/clientmqueue 目录占用了 / var 整个分区大小的 90%,那么 / var/spool/clientmqueue 目录下的文件都是怎么产生的,能否删除,基本上都是邮件信息,可以删除 # rm * /bin/rm :argument list too long 当在 linux 系统中试图传递太多参数给一个命令时,就会出现 “argument list too long” 错误,这是 linux 系统一直以来都有的限制,查看这个限制可以通过命令 “getconf ARG_MAX” 来实现, # getconf ARG_MAX # more /etc/issue 查看版本 解决方法:1、 # rm [a-n]* -rf # rm [o-z]* -rf 2、使用 find 命令来删除 # find /var/spool/clientmqueue –type f –print –exec rm –f {} ; 3、通过 shell 脚本 #/bin/bash RM_DIR=’/var/spool/clientmqueue’ cd $RM_DIR for I in `ls` do rm –f $i done 4、重新编译内核 需要手动增加内核中分配给命令行参数的页数,打开 kernel source 下面的 include/linux/binfmts.h 文件,找到如下行: #denfine MAX_ARG_PAGES 32 将 32 改为更大的值,例如 64 或者 128,然后重新编译内核 问题 3:inode 耗尽导致应用故障 客户的一台 Oracle 数据库如武器在关机重启后,Oracle 监听无法启动,提示报错 Linux error : No space left on device 从输出信息看出来是因为磁盘耗尽导致监听无法启动,因为 Oracle 在启动监听时需要创建监听日志文件,于是首先查看磁盘空间使用情况 # df -h 从磁盘输出信息可知,所有的分区磁盘空间都还有剩余不少,而 Oracle 监听写日志的路径在 / var 分区下,/var 下分区空间足够。 解决思路: 既然错误提示语磁盘空间有关,那就深入研究关于磁盘空间的问题,在 linux 系统中对磁盘空间的占用分为三个部分:第一个是物理磁盘空间,第二个是 inode 节点所占用的磁盘空间,第三个是 linux 用来存放信号量的空间,而平时接触较多的是物理磁盘空间。既然不是物理磁盘空间的问题,接着就检查是否是 inode 节点耗尽的问题,通过执行命令 “df -i” 查看可用的 inode 节点。由输出结果看出确实是因为 inode 耗尽导致无法写入文件。 可以通过下面的命令查看某个磁盘分区 inode 的总数 # dumpe2fs -h /dev/sda3 |grep ‘Inode count’ 每个 inode 都有一个号码,操作系统用 inode 号码来区分不同的文件,通过‘ls -i’命令可以查看文件名对应的 inode 号 如果要查看这个文件更详细的 inode 信息,可以通过 stat 命令来实现 # stat install.log 解决问题 # find /var/spool/clientmqueue/ -name “*” -exec rm -rf {} ; 问题 4:文件已经删除,但是空间没有释放的原因 运维监控系统发来通知,报告一台服务器空间满了,登陆服务器查看,根分区确实满了,这里先说一下服务器的一些删除策略,由于 linux 没有回收站功能,所以线上服务器上所有要删除的文件都会先移到系统 / tmp 目录下,然后定期清除 / tmp 目录下的数据。这个策略本身没有什么问题,但是通过检查发现这台服务器的系统分区中并没有单独划分 / tmp 分区,这样 / tmp 下的数据其实占用根分区的空间,既然找到了问题,那么删除 / tmp 目录下一些占用空间较大的数据文件即可。[!--empirenews.page--] # du -sh /tmp/* | sort -nr |head -3 通过命令发现在 / tmp 目录下有个 66G 大小的文件 access_log,这个文件应该是 apache 产生的访问日志文件,从日志大小来看,应该是很久没有清理的 apache 日志文件了,基本判定是这个文件导致的根空间爆满,在确认此文件可以删除后,执行如下删除命令, # rm /tmp/access_Iog # df -h 从输出来看,根分区空间仍然没有释放,这是怎么回事 一般来说不会出现删除文件后空间不释放的情况,但是也存在例外,比如文件进程锁定,或者有进程一直在向这个文件写数据,要理解这个问题,就需要知道 linux 下文件的存储机制和存储结构。 一个文件在文件系统中存放分为两个部分:数据部分和指针部分,指针位于文件系统的 meta-data 中,在将数据删除后,这个指针就从 meta-data 中清除了,而数据部分存储在磁盘中。在将数据对应的指针从 meta-data 中清除后,文件数据部分占用的空间就可以被覆盖并写入新的内容,之所以出现删除 access_log 文件后,空间还没有释放,就是因为 httpd 进程还在一直向这个文件写入内容,导致虽然删除了 access_Ilog 文件,但是由于进程锁定,文件对应的指针部分并未从 meta-data 中清除,而由于指针并未删除,系统内核就认为文件并未被删除,因此通过 df 命令查询空间并未释放。 问题排查: 既然有了解决思路,那么接下来看看是否有进程一直在向 access_log 文件中写入数据,这里需要用到 linux 下的 losf 命令,通过这个命令可以获取一个仍然被应用程序占用的已删除文件列表 # lsof | grep delete 从输出可以看出,/tmp/access_log 文件被进程 httpd 锁定,而 httpd 进程还一直向这个文件写入日志数据,最后一列的‘deleted’状态说明这个日志文件已经被删除,但是由于进程还在一直向此文件写入数据,因此空间并未释放。 解决问题: 到这里问题就基本排查清楚了,解决这一类问题的方法有很多,最简单的方法就是关闭或者重启 httpd 进程,当然重启操作系统也可以。不过这些并不是最好的办法,对待这种进程不停对文件写日志的操作,要释放文件占用的磁盘空间,最好的方法是在线清空这个文件,具体可以通过如下命令完成: # echo “”>/tmp/access_log 通过这种方法,磁盘空间不但可以马上释放,也可以保障进城继续向文件写入日志,这种方法经常用于在线清理 apache /tomcat/nginx 等 web 服务产生的日志文件。 问题 5:"too many open files" 错误与解决方法 问题现象:这是一个基于 java 的 web 应用系统,在后台添加数据时提示无法添加,于是登陆服务器查看 tomcat 日志,发现如下异常信息,java.io.IOException: Too many open files 通过这个报错信息,基本判断是系统可以用的文件描述符不够了,由于 tomcat 服务室系统 www 用户启动的,于是以 www 用户登陆系统,通过 ulimit –n 命令查看系统可以打开最大文件描述符的数量,输出如下: $ ulimit -n 65535 可以看到这台服务器设置的最大可以打开的文件描述符已经是 65535 了,这么大的值应该够用了,但是为什么提示这样的错误呢 解决思路,这个案例涉及 ulimit 命令的使用 在使用 ulimit 时,有以下几种使用方法: 1、 在用户环境变量中加入 如果用户使用的是 bash,那么可以在用户目录的环境变量文件. bashrc 或者. bash_profile 中加入 “ulimit –u128” 来限制用户最多可以使用 128 个进程 2、 在应用程序的启动脚本中加入 如果应用程序是 tomcat,那么可以再 tomcat 的启动脚本 startup.sh 中加入‘ulimit -n 65535’来限制用户最多可以使用 65535 个文件描述符 3、 直接在 shell 命令终端执行 ulimit 命令 这种方法的资源限制仅仅在执行命令的终端生效,在退出或者和关闭终端后,设置失效,并且这个设置不影响其他 shell 终端 解决问题: 在了解 ulimit 知识后,接着上面的案例,既然 ulimit 设置没有问题,那么一定是设置没有生效导致的,接下来检查下启动 tomcat 的 www 用户环境变量是否添加 ulimit 限制,检查后发现,www 用户并无 ulimit 限制。于是继续检查 tomcat 启动脚本 startup.sh 文件是否添加了 ulimit 限制,检查后发现也没有添加。最后考略是否将限制加到了 limits.conf 文件中,于是检查 limits.conf 文件,操作如下 # cat /etc/security/limits.conf | grep www www soft nofile 65535 www hard nofile 65535 从输出可知,ulimit 限制加在 limits.conf 文件中,既然限制已经添加了,配置也没有什么错,为何还会报错,经过思考,判断只有一种可能,那就是 tomcat 的启动时间早于 ulimit 资源限制的添加时间,于是首先查看下 tomcat 启动时间,操作如下 # uptime Up 283 days # pgrep -f tomcat 4667 # ps -eo pid,lstart,etime|grep 4667 4667 Sat Jul 6 09;33:39 2013 77-05:26:02 从输出可以看出,这台服务器已经有 283 没有重启了,而 tomcat 是在 2013 年 7 月 6 日 9 点启动的,启动了将近 77 天,接着继续看看 limits.conf 文件的修改时间, # stat /etc/security/limits.conf 通过 stat 命令清除的看到,limits.conf 文件最后的修改时间是 2013 年 7 月 12,晚于 tomcat 启动时间,清楚问题后,解决问题的方法很简单,重启一下 tomcat 就可以了。 问题 6:Read-only file system 错误与解决方法 解析:出现这个问题的原因有很多种,可能是文件系统数据块出现不一致导致的,也可能是磁盘故障造成的,主流 ext3/ext4 文件系统都有很强的自我修复机制,对于简单的错误,文件系统一般都可以自行修复,当遇到致命错误无法修复的时候,文件系统为了保证数据一致性和安全,会暂时屏蔽文件系统的写操作,讲文件系统 变为只读,今儿出现了上面的 “read-only file system” 现象。[!--empirenews.page--] 手工修复文件系统错误的命令式 fsck,在修复文件系统前,最好卸载文件系统所在的磁盘分区 # umount /www/data Umount : /www/data: device is busy 提示无法卸载,可能是这个磁盘中还有文件对应的进程在运行,检查如下: # fuser -m /dev/sdb1 /dev/sdb1: 8800 接着检查一下 8800 端口对应的什么进程, # ps -ef |grep 8800 检查后发现时 apache 没有关闭,停止 apache # /usr/local/apache2/bin/apachectl stop # umount /www/data # fsck -V -a /dev/sdb1 # mount /dev/sdb1 /www/data

    时间:2018-01-19 关键词: Linux 处理 运维

  • 变革运维 运营商网络运维转型进行时

     流量经营时代,建立以用户感知为中心的网络运维体系已经成为全球运营商的诉求。 “中国联通正在推动从以网络为中心到以业务质量和用户感知为中心的转型。”中国联通网络分公司运行维护部副总经理崔荣春在公开演讲中表示。 无独有偶。据记者了解,中国电信和中国移动都将建立用户感知为中心的运维体系作为2014年的一项重点工作,有序展开。反观国外,沃达丰、德国电信等知名运营商早在前两年就开始注重提升用户感知,进入流量经营时代。 在运维体系的变革中,加快形成集中化网络维护管理和属地化维护支撑相结合的运维模式,实现集中监控成为运营商的另外一个主要目标。 在这两个目标的牵引下,运营商网络运维转型的大幕已经拉开。 运维体系亟待转型 过去10年,电信业成本下降主要依赖设备的成本降低,而随着摩尔定律的逐渐失效,近几年网络设备中与摩尔定律相关的部分已经低于30%,依赖设备成本下降已经不可持续。与此同时,运营商的OPEX比重越来越大。 “这种背景下,电信业传统的网络运维模式已经无法适应技术发展潮流。”中国联通研究院王光全向记者表示:“因此,运营商的运维体系亟待转型。” 事实上,运营商面临的挑战不仅这些。 LTE时代,为了提供更高的带宽,单个基站的覆盖越小。为了满足用户的覆盖需求,运营商部署的基站越来越多,越来越密集。网元数量几倍乃至几十倍的增量为运营商的运维工作带来了巨大的挑战。 LTE时代带来的不仅仅是网络架构的变化,更是业务形态的变化。2G/3G时代,运营商提供的业务以语音、短信和低带宽数据业务为主,到了4G时代,业务更等同于互联网业务。互联网业务复杂多样化,而且更新速度非常快。 “4G业务的互联网化特征对传统的维护方式提出的第一个挑战就是故障定位困难。”贵州移动网络部工程师、网络运行分析专家刚周伟在接受《通信产业报》(网)采访时表示,传统电信业务运营商全程管控,业务故障点定位简单,但互联网业务由于运营商无法全程管控,业务质量难以保证。同时互联网网络庞大而复杂,导致影响业务和感知的故障点增多,难以迅速响应和处理。 除此之外,维护标准无法统一和维护制度更新较慢都将成为运营商开展4G业务维护的挑战。 崔荣春表示,面对网络及业务、内部和外部对运维工作带来的新挑战,全球主流运营商都在探索集中化维护和贴近用户感知的运维转型。 例如,德国运营商T-Mobile借助终端侧CEM工具,进行用户感知侦测和反馈:一是,通过网络状况测试,了解网络的时延、速率等情况;二是,开展业务与服务感知反馈评价,使得用户可以主动对业务和服务类体验进行评价;三是,对用户感知和满意度进行问卷调查。 与此同时,国内运营商运维转型的步伐也在加快。 面对LTE时代的挑战,四川联通2013年提出“大运维”战略,构建集中化的大运维系统,降低运维成本并提升用户感知。“四川联通的大运维平台化战略,以实现‘降低运维成本、以用户感知与用户需要为使命’为目标,为用户提供更优质的服务。”四川联通副总经理廖建文在接受《通信产业报》(网)采访时表示。 而石家庄联通运行维护部以“夯实基础管理”为目标,重点聚焦网络质量提升、客户感知提升和基层管理提升三个领域,实现运维管理转型。来自石家庄联通的运维人员向记者表示,运行维护部一方面完善综合网管功能,实现统一故障集中管控;另一方面强化网络数据分析和移动网基础数据的稽查和评估。 网络KPI落伍了 运营商传统的运维体系以网络为中心而建立,讲究各种网络KPI参数。 以中国移动2013年网络KPI指标构成举例说明。网络运行质量10分,包含GSM网络语音4分、TD网络覆盖率3分和TD手机用户下载速率3分;客户满意度25分,包含整体客户满意度8分、重点客户群体满意度和客户感知要素满意度12分和端到端网络质量客户满意度5分;手机流量分流比例4分,扣减分则不超过10分。 为了交出一份漂亮的网络KPI答卷,运维人员唯KPI至上,针对网络不停地进行调整、优化和改良,一些地市的KPI可能达到6个9乃至7个9。一旦达不到达不到这个级别,排名非常靠后。例如一个地市运营商的语音质量97.59%,对比全国排名仅仅位列第27名。 而有趣的现象是,在6个9的KPI分值看似繁华的背后是用户的频繁投诉,数据网络的卡顿或者连接不上。如此一来,用户体验的日益下降,而运营商收到的投诉电话也日益增多。 为什么会出现这种现象呢?中兴通讯服务业务部副总经理周勇向记者进行了阐释:随着数据业务的爆发性增长,网络的KPI度量已经无法真正反映出用户使用网络的体验。其实运营商也非常困惑,如何得到用户体验的真实数据。这就要求运营商重新审视用户体验,其由什么要素构成,围绕这些要素重新搭建一个以用户感知为中心的运维评价体系。 目前,北京电信已经改变了传统的网络KPI模式。从用户的角度出发,从单纯优化网络KPI指标向优化网络速率和时延转变,从而更贴近用户的实际体验。 不过需要清醒的认识到,从以网络为中心向以业务质量和用户感知为中心转变,不可能一蹴而就。 在崔荣春看来,以业务质量和用户感知为中心的运维体系建立是一个系统工程。需要在组织与流程优化、评估体系优化、支撑系统完善、人员结构优化等方面协同推进才能真正落地,并以此推动集约化维护体系和端到端服务体系的建立。 针对体制、组织和手段的变革,刚周伟则给出了具体的建议:“体制要求从网元向业务感知转变,向互联网先使用再完善的思路靠拢;组织是改变传统以网元为维护单位,成立以维护方式为维护单位,淡化网元维护的概念,提升业务感知的重要程度;手段方面就是跟随互联网的变化,加速手段建设,利用云计算和大数据的先进技术提升运维手段完善。” 提升用户感知,最重要的是保证用户的业务体验。因此,用户的实际感受将能够最真实的反映运营商网络质量的好坏。基于这一点,来自北京电信网络运行维护部的杨西光建议,提升用户感知,运营商可以采用全民运维报告的模式。 “用户通过移动终端的APP,主动上报移动网的各项参数和坐标,运营商根据用户实际现场的情况判断网络隐患,能更直观的反映用户的感知,进行主动优化。用户投诉前就进行优化和调整,满足未来网络中环境变化快,用户现场不易到达的问题。”他说。 运维体系的变化对维护人员也提出了新的要求。以往维护人员需要同时关注网络层、操作系统主机层、业务应用层。每套业务系统相对独立,设备采购、建设、调试上线周期长,不能适应移动互联网技术快速发展的需要。 对此,浙江电信网络运行中心的章波焕向记者表示,维护人员的观念也要改变,从而适应移动互联网发展的需要。而云计算较好得解决了上述问题,使得维护人员能够专注于业务层面,而网络、主机层面统一由云平台统一管理维护。 集约化,提升效率 在四川联通的大运维战略中,可以看到,四川联通提出了集中管控、集中维护和集中管理三个集中的新运维工作体制。廖建文向记者表示,集中化可以缩短故障响应时间,大大提升用户体验。 目前,集约化已经成为运营商网络运维转型的一个重点方向。近两年,国内三大运营商一直致力于集中化OSS系统的建设,实现OSS自上到下的集中化管理,提升OSS系统的效率。 杨西光告诉记者,运营商未来的运维体系需要朝着集约化的方向演进。这是因为,随着移动互联网的发展,网络种类和网络规模不断扩大,集约化的维护不仅可以节省人力,还可以最大限度地满足跨专业网络的维护需求。 来看一位做接入网DX的一线运维工作人员的真实感受:“我所做的单位正在进行运维系统的集约化工作,虽然目前处于过渡期,效果并不明显,但我看好集约化的前景。” 由于一些历史遗留问题,导致运营商的接入网DX设备五花八门,管理非常复杂。而随着集约化的发展,一些老旧设备得以拆除,而核心网设备向来比较先进,讲究统一性。因此运维人员可以轻松的实现对设备的统一操作和管理。 与此同时,故障发现和管控交由省公司集中管理后,技术人员力量比地市雄厚,因而解决问题也更加容易。 当然,他也提出一些担心,由于分工没有那么细致,反而有可能会出现“扯皮”的现象,这是运营商运维集约化转型道路上需要注意的问题。 襄阳电信网络操作维护中心的王理在接受《通信产业报》(网)采访时则提出了另外一种思路:“运营商下一代网络运维体系可考虑取消省级集中,由集团公司直接与地市维护对接,集团进行运维市场管理,地市公司则更加快捷地响应集团运维需求,提高资源利用率和服务响应率。” “即使道路不同,但集约化转型已经成为运营商维护人员的共识。”中兴通讯的专家向记者表示:“集约化是一条帮助运营商降低TCO成本的最重要的道路,同时也能大幅度提升企业运作效率。” 引入大数据 如今,运营商面临的竞争者越来越多。大批虚拟运营商的进入势必会使得运营商现有存量用户流失。 有专家提出,运营商可以通过发展新用户来弥补。但是根据美国市场营销学会顾客满意手册的统计数据表明,留住一个用户所需要的成本是争取一个新用户成本的1/5。 “因此,对于增量客户越来越少的移动通信市场,减少用户流失就意味着用更少的成本减少利润的损失,这使得运营商不得不关注用户流失,盘活存量已经成为运营商的主题。”来自中兴通讯的专家向记者表示。 如何盘活存量,上述中兴专家告诉记者,这就需要运营商管理人员了解哪些用户可能流失,什么时候会发生流失。通过建立流失预测模型,分析历史数据和当前数据,提取辅助决策的关键性数据,并从中发现隐藏关系和模式,进而预测未来可能发生的行为,从而提前做好防范工作。 2G/3G时代,运营商建立了强大的CRM系统和经分系统来防范用户流失,也曾经起到非常积极的作用。不过,由于此前的系统大部分是以结构化数据来分析,而4G时代,用户个性化需求凸显,非结构化的用户数据占据主流。因此,传统的CRM系统和经分系统已经无法满足运营商的需求。 而更为重要的一点,4G时代,OSS系统的各项参数更能反映出用户的真实行为,因此,运营商更要善于利用OSS系统的数据来建立用户流失预测模型。当然,OSS包含的数据量更是CRM系统无法比拟的。 这时,大数据的优势显现出来。“在运营商的运营维护系统引入大数据,有利于运营商建立更加准确的用户流失预测模型,成为运营商未来的一个提升方向。”来自中兴的专家向记者表示。(本报记者徐姗姗对本文亦有贡献) 链接 德国T-Mobile:享受运维转型的商业价值 用户感知 T-Moble借助终端侧CEM工具,进行用户感知侦测和反馈:一是,通过网络状况测试,了解网络的时延、速率等情况;二是,开展业务与服务感知反馈评价,使得用户可以主动对业务和服务类体验进行评价;三是,对用户感知和满意度进行问卷调查。 大数据 T-Mobile在多个IT系统中整合了大数据应用,通过整合用户历史海量数据,对用户交易和互动数据进行综合分析,提炼出已流失用户在流失前具有的特征,从而更准确地预测了用户流失率。在2011年首季度,T-Mobile在美国区域将客户流失率成功减少了一半。

    时间:2014-07-17 关键词: 网络 运营商 运维

  • 网络运维服务迈上创新发展之路

     伴随着移动通信网络从3G迈向4G,伴随着通信业务从话音转向数据,伴随着移动互联网、云计算、智慧城市等技术和应用的兴起,通信网络运维服务正在呈现出新的发展趋势。在日前召开的“2014年中国通信网络运维服务高级研讨会”上,来自产业界各方的代表汇聚一堂,共同畅谈通信网络运维发展。通信运维的集约化管理、通信运维更加以用户感知为中心、LTE时代的通信运维等都成为热点话题。 通信业正在加快转型升级的步伐。当前,包括4G、宽带中国、移动互联网、智慧城市在内的技术和应用蓬勃发展,同时,在政策的推动下虚拟运营商作为新生事物也开始进入市场。这些不仅为通信网络的建设和发展指明了新的方向,同时也为通信网络运维服务发展提供了新的机遇。在“2014年中国通信网络运维服务高级研讨会”上,新形势下网络运维服务的发展成为关注焦点,业界各方认为,在网络演进和业务发展的推动下,通信网络运维服务正在迈上一条创新发展的道路。 网络运维面临重要机遇 “通信网络运维服务的发展正在面临重要机遇。”中国通信企业协会通信网络运营专委会主任靳东滨在会上作出了这一判断。他指出,当前无论是4G的全面商用,“宽带中国”战略的稳步推进,还是移动互联网的蓬勃发展,以及虚拟运营商的兴起,都是通信网络运维服务面临的机遇。 2013年年底工信部向三大运营商发放了4G商用牌照,这无疑给整个移动通信产业的各个领域带来巨大的投资拉动效益。对于通信运维而言,这也意味着网络资源的整合,移动通信网络增加了新的网络制式和频段,原有的技术储备需要进行一些新的调整。因此,通信运维企业需要针对未来的TD-LTE和FDD LTE混合组网进行相应的技术和人才储备。 “宽带中国”战略的实施,推进了我国宽带网络建设的发展,同时,宽带驻地网的共建共享也被提出。“继续深化共建共享、促进设施集约发展”成为“宽带中国2014专项行动”的一大目标。在这一形势下,通信运维行业,尤其是通信运维企业需要根据宽带共建共享的要求和目标,帮助运营商优化网络、提升服务。 移动互联网显然是近几年的发展热点。虽然移动互联网应用的发展看起来和通信运维行业的关系并不密切,但是事实上,移动互联网应用和技术正在加速与传统通信产业融合,甚至向通信运维企业的日常经营渗透。比如一些通信运维企业正在探索将移动互联网应用融入日常的维护体系建设中,通过建立企业和企业之间以及企业内部的微信圈,提升沟通效率和故障反应速度,实现流程的进一步整合。 智慧城市建设的推进给通信运维带来了新的空间。智慧城市的建设不仅涉及通信基础设施的建设,同时智慧城市的顶层设计也包含了通信技术。对于通信运维行业而言,未来智慧城市基础设施的网络外包无疑是一大新方向,通信运维企业可以向智慧城市通信基础设施的区域性外包探索。 虚拟运营商入市正在影响着通信业的发展。一方面,虚拟运营商的进入,将会加剧通信市场的竞争;另一方面,虚拟运营商业务的开展也给运营商的管理和服务带来了挑战。但是长远来看,虚拟运营商的出现将给整个产业链带来新的活力和机会,有利于产业链资源的整合。对于通信运维行业而言,虚拟运营商的兴起也将带来一些新的机遇,通信运维企业有望在这种市场变化中找到新的位置。 通信运维服务转型升级 通信业正在经历一个转型升级的新阶段,通信网络和通信业务都在发生转变。当前,无论是移动通信网络还是固定宽带网络,都在技术的推动下不断演进。以中国移动为例,十几年前还是一张单一的2G网络,而今天不仅拥有了成熟的3G网络,更在大力发展4G网络,网络的规模和复杂度都大大增加。与此同时,通信业务也正在从传统的话音、短信、彩信向更加丰富的多媒体和OTT等业务转变,并且新业务推出的周期也越来越短,新业务的种类和数量在不断增多。 可以看到,随着网络向着复杂化、移动化、宽带化、IT化演进,随着通信业务从话音业务向数据业务演进,随着运营商越来越多关注用户感知和用户体验提升,基础网络正在面临越来越大的挑战,网络的质量和保障能力的要求越来越高。“通信运维工作正在面临越来越大的挑战,需要根据网络演进和业务转变提升相应的能力。”中国移动通信集团河南有限公司网络部总经理赵继红表示,新形势下通信运维不仅要根据网络和业务开展的需要打造相应的技术能力,同时也需要提升运维管理能力以及运维服务的合作能力。 通信运维正在顺应通信业的转型升级而创新发展。华为技术服务有限公司中国地区部服务Marketing部总工张楠认为,随着运维外包需求的增加,运维外包正在从网络外包扩展到IT外包,衡量标准也上升到了业务质量管理和客户体验。同时,随着大数据的广泛应用,通信运维服务正在从支撑型向价值创造型转变。总结而言,当前通信运维正在向着四个方向发展:一是从以网络为中心向以用户为中心转变;二是从被动响应向主动关怀转变;三是从成本中心向创新中心转变;四是从分布模式向集中模式转变。 集中化运维已经成为一种趋势。面对运营商提升运维效率、提升网络质量以及提升全网管理控制能力的要求,集中化运维能够有效减少管理流程,提升工作效率,并清晰定位各层之间的责任。目前,中国的运营商都已经开始积极探索集中化运维体系的建设,并更加注重用户感知,以期为新业务的开展提供更加有力的支撑。

    时间:2014-05-04 关键词: 网络 通信 运维

  • 国内外分析师共议下一代运维:改变贯穿所有环节

     下一代移动通信技术、下一步业务转型、下一种商业模式……在全球电信运营商热切讨论的新的发展趋势背后,改变是贯穿企业上上下下、所有环节的。 无论是“智能管道”还是“流量经营”,一张高质量、高性能的稳定网络是业务经营的基础。然而近年来,接入终端的多样化、新业务新应用的涌现,使传统的用来衡量网络关键性能的KPI无法真实、全面反映业务质量和用户体验了。 毫无疑问,运营商需要下一代运维体系,为此,C114采访了工业和信息化部电信研究院泰尔管理研究所高级项目经理王力、Ovum电信业务分析师Adaora Okeleke,结合国内和国际两位专业人士的视角,探讨运营商运维体系面临的挑战,下一代运维需要具备哪些特征。 移动互联网带来的挑战 王力认为,运营商网络的运维管理的确需要进行大的调整。以前用户的需求主要是打电话、发短信,运营商对电信网络的感知是可控的。但是现在,随着移动互联网的兴起,社交应用、游戏、理财、购物等各种新应用涌现,用户感知开始受到各种复杂因素的影响。换句话说,运营商过去做到的是对“管道”的感知,而现在要做到“端到端”的感知。 另外,运营商对网络容量的增长变化也变得不可预知,以往的话音业务容量是可预测的,但数据业务流量不可预知,看不到上限,并且还是热点状的。 总结下来,王力认为挑战主要体现在:端到端的维护,从集中化向本地化的转变,加强快速响应和处理能力。 Okeleke称,移动网络的流量激增,使运营商在做好传统的语音、短消息业务把控和计费外,还要做好流量经营。电信业务支持系统(BSS)需要准确追踪所有数据——短信、彩信、电话、邮件、互联网接入等等。后续还要把追踪到的流量进行分门别类的计费。由此带来的业务压力还包括,如何为消费者提供更灵活的套餐以供选择。而且,运营商还要让用户理解他们购买了什么,使用了什么,计费机制如果变得模糊不清,会对客户体验带来负面影响。 此外、运营商还要为新开发出来的业务设计新的计费套餐,而且这些新业务、新信令数据会越来越多,它带来了数据的爆炸式增长,甚至使网络堵塞,损害既有服务的传输质量。因此,运营商需要管理好这些大量涌入的数据,业界很多设备商都开发了相应的解决方案,试图定位这些信令数据来自哪些基站,力图让BTS变得更加智能,同时为移动流量提供本地化服务器的响应。 Okeleke补充说,运营支撑系统(OSS)也需要支持网络流量的增长,对流量实施实时监控,主动且提前识别可能发生的网络故障。OSS子系统,如网络规划和设计系统需要重新定义,以提供主动的网络监控 ,为用户需求留出适当的库存资源,支持用户的移动数据需求。其他的系统包括服务保障、配置系统、激活等,都要适应和管理这些数据业务。 立足管道的智能化运营 王力表示,现在业内热切讨论的流量经营,也可以理解为管道的智能化运营,提升网络的管道价值。他说,运营商说到底还是网络运营商,管道是其核心能力。目前,很多业务层的东西已逐渐被OTT业务替代,运营商更需要做好管道。 他提到,今年初,美国发生了一件很有影响力的事情,联邦法院推翻了“网络中立指令”,这意味着运营商可以向OTT企业收取一定费用,保证网络投资,用户在使用OTT业务时体验到更快的速率、更好的感知。 王力认为,这一事件的意义深远,它表明运营商可以控制每个用户访问每个网站使用每个应用时的网速,并且可以差异化定价,国外已经有运营商推出了差异化的业务套餐。用户要用更快速的网络,需要多交费。企业要保证自己提供的OTT业务不被运营商限速,也要多交费。 他说:“这就是管道的智能化运营,针对不同价值的用户和业务,提供不同的网络感知。现在国内的运营商已经开始做了,比如中国联通的微信沃卡,中国电信和中国移动的后向流量。网络运维要做的事情,能在网路上辨别每个用户的流量都是走向哪些企业的哪些业务上,并且加以控制。 很多运营商已经意识到了这一点,将运维关注的重点从以往“以网络为中心”转向了“以用户感知为中心”,那这样的转型要求对运维工作人员提出了哪些新的要求?Okeleke表示,对电信运营商来,以用户感知为中心,也就意味着要以“服务质量”为中心,这是因为客户对服务的感知与运营商提供的服务质量之间有着密切的关系,运营商需要把监测、管理好客户投诉这件事与监控服务的质量配合起来管理。 Okeleke同时强调,运营商对所有服务模式的监控都不应该独立进行,这是因为任何一个环节存在短板,客户投诉率都有可能上升,在提供令客户满意的服务中,所有环节都是相互依赖的。此外,对问题的监控以及根本原因分析,都应该受到服务指标的驱动,而不是单独对网络质量的指标进行分析,后者并不能提示用户感知问题的答案。 当然,有一些指标对分析用户感知是有帮助的,比如服务激活时间、响应时间、解决故障的时间、同一问题反复出现的次数、净推荐值、在激活过程中的自动化水平,客户投诉量,因自助服务选项配置转到呼叫中心的呼叫量,可用自助服务的选项等等。 大数据为拓展业务打下基础 在管道智能化运营的基础上,运营商就有条件去开发迎合客户需求的新业务了。王力表示,运营商手里已经拥有用户的很多数据,未来的潜力巨大,但运营商目前欠缺足够的资源管理能力,数据挖掘和处理能力。 大数据分析提供业务机会的潜力非常大。比如说,运营商通过已经掌握的手机号码,知道这些用户的身份(通过实名制)、行为特征(花多少钱、打多少电话、上多少流量、用什么应用)、消费能力(月资费)、位置、社交圈(通讯录和通话记录)等等,能够与企业合作进行精准营销。 Okeleke表示认可,称运营商需要对大数据进行投资,大数据和大数据分析领域的很多企业开发了面向运营商业务的应用,Ovum近期发布的报告也总结了大数据分析应用的领域:网络、运营、客户、市场。具体来说,在网络层面,大数据的应用包括网络容量规划、监控、优化以及商业化,故障定位及保护;在运营层面,改善客户体验、计费和收入系统,为欺诈侦测、管理提供支持,对SLA管理的支持等等;在客户体验方面,运营商需要收集跟客户行为、动机相关的所有信息。这些信息在分析以后,可以使运营商提供高度个性化的业务,无论对客户体验还是自身转型都是有助益的。但是,要做到这些,运营商需要部署分析工具,从计费、CRM以及网络运营中提取数据,以立体描绘客户体验模型。 从这一点来看,Ovum认为,下一代网络运维管理会更专注于提升用户体验,正如运营商现在在做的业务转型模式一样,这两大因素会相互配合,支持运营商提高业务收入的核心需求。 电信管理服务外包成为必然 讨论到这里,下一个方向如何发展就呈现在眼前了,王力表示,运营商的现在网络运维很大一部分都是外包的,当然也分不同的专业网,由专门的运维公司、设备商、设计院的人去维护,运营商的运维人员承担的角色更像包工头。运营商因为体制和编制限制,没有那么多的人力去维护这么庞大的网络基础设施,外包是必然的选择。 Okeleke表示,Ovum看到,越来越多的运营商将电信网络、IT基础设施的管理外包,这一趋势除了出于削减成本的考虑,还有四个形成因素: 一、由于软件和IT平台与电信基础设施的相连是根深蒂固的,这一趋势造成的复杂问题,使得运营商内部的IT部门无法提供全面的技术支持。因此,就要求IT管理服务提供商提供简化的、产业化运营,以支持网络发生的变化。 二、电信网络基础设施正在向全IP化演进,LTE网络正在加快这个趋势,这意味着电信运营商必须有能力提供更创新的服务。而且,新服务需要运营商具备一些新的运营技能,比如支持系统、管理服务,这些是目前运营商还不具备的。仅靠运营商内部的运维人员去学习发展这些技能,将额外增加很多成本。因此,已拥有娴熟技能和经验的管理服务商,就有了更多机会,去支持运营商的新服务。 三、在电信运营领域的竞争日益激烈,运营商需要转变运营模式,这就要求运营商要对消费者需求更加敏感、响应更敏捷。那么外包非核心的网络运维,可以使运营商更专注发展创新业务的开发。 四、要在一个竞争激烈的环境下健康成长,电信运营商需要专注服务质量,而不是网络管理。服务质量管理涉及到网络基础设施,以及系统、服务提供流程。这些需求能为电信管理供应商提供更多的机会,让他们承担起担负运营商网络与IT基础设施的建设与运维重任,支持运营商实现“提供优质客户体验”的愿景。 王力表示,虽然国内有些运营商,出于成本控制,一直都希望在自己人力的许可范围内尽可能的把核心网元的运维收回来自己做,但网络运维需要很专业的技能,运营商自己也明白,节省成本只是手段,最终的目的是增加营收。

    时间:2014-04-30 关键词: 通信 射频 运维

发布文章

技术子站