【干货分享】360网络运维的最佳实践

原创
运维 系统运维 开发工具
李洪亮,奇虎360网络运维负责人。2007年加入360公司,目前已有11年的网络与网络安全工作经验,拥有CISSP和CCNP证书,带领团队实现了奇虎360网络架构从1000台服务器到10万台服务器的跨越式发展。本文按照360公司服务器发展的不同阶段,分享在网络建设和运维过程中遇到的哪些挑战、陷阱、经验和收获。

  嘉宾介绍

  李洪亮,奇虎360网络运维负责人。2007年加入360公司,目前已有11年的网络与网络安全工作经验,拥有CISSP和CCNP证书,带领团队实现了奇虎360网络架构从1000台服务器到10万台服务器的跨越式发展。

  在我2007年加入360公司的时候,360公司的服务器数量是1000台,经过不同阶段的发展,现在已经达到了10万台服务器的规模。下面,我按照公司服务器发展的不同阶段,分享在网络建设和运维过程中遇到的哪些挑战、陷阱、经验和收获。

[[147570]]

  阶段一、1-1000台服务器规模

  1.需求:奇虎前期做的是社区搜索,规模不大。业务部门的需求是网络能够通畅运行就可以。

  2.人员:没有专职的网络工程师

  3.架构:核心与接入的二层结构,我们采用的是星型结构。

  4.挑战:工作量大,各方面的工作都要接触。

  5.陷阱:有缺陷的网络设备,不靠谱的机房。

  • 如果你买到有缺陷的网络设备,就会对网络造成很大的运行压力。
  • 如果碰到不靠谱的机房,从我的经验来看,机房泡水出现的大概频次是3年左右。大家特别需要注意空调的冷凝水漏水,它造成的损害很大。

  6.经验:绑定一家有实力的设备厂商,特别是对于体量不大的小型公司。

  阶段二、1000-5000台服务器规模

  1.需求:高可靠

  2.人员:专职网络工程师(CCIE) 大于2位

  3.架构:简单二层结构/多数据中心,其中数据中心通过光纤来互联。

  4.挑战:工作量大,因为业务部门的需求增加,工作压力加大。

  5.陷阱:

  • 业务复杂度挑战网络设备,比如业务部门根据业务发展的实际对于网络提出特殊要求。
  • 经常中断的光纤,需要选择靠谱的供应商。比如某年7月份断了22次光纤,这种状况如出现,会让网络运维人员崩溃。
  • 网络断了竟然不知道,这是很大的挑战。网络运维部门需要早于业务部门发现网络问题。

  6.经验:

  • 与厂商沟通业务场景, 一定要选择有余量的网络设备。

     千万不要把网络设备的数据指标范围卡的过于严格。

  • 选择靠谱的传输和光纤供应商
  • 搭建网络监控和报警平台

  阶段三、5000-10000台服务器规模

  1.需求:高可靠/不丢包

  2.人员:网络工程师/网络架构师大于5人,这个阶段就要融入至少一个网络架构师的角色。

  3.架构:大规模数据中心/异地多数据中心。这里提到的大规模数据中心的一个数据中心要有2-3千台服务器规模。

  4.挑战:

  • 工作量巨大,压力山大。这个阶段单人的工作量压力***,如通过这个阶段,你就会成为部门精英了。
  • 人员误操作增多。

     随着业务需求增多,网络运维人员相对也是增多,必然增加人员误操作发生的几率,一旦出现情况,网络运维人员可能没法向业务部门交代。

  • 网络设备故障增多

  5.陷阱:业务冲击网络设备极限,公司上线搜索,Hadoop集群,存在很大概率出现丢包现象。

  一个搜索需求的提出,会在一个集群的几百台服务器上进行request,产生结果会同时到达端口,远远超过10毫秒1.25MByte的端口处理上限。在这种情况下,如果交换机buffer下的话,肯定会出现丢包现象,这个情况就是我们遇到的一个“坑”。

  6.经验:

  • 扩充人员规模。

     随着异地业务的开展,你的人员需要频繁地出差。可是出差的工作效果不高,时间浪费在路上,还造成沟通成本增加。这个问题的解决办法就是扩大人员规模。

  • 找经验丰富的网络架构师

     网络架构师建议从5万台服务器规模以上公司来物色,可以节省很多试错成本和快速找到合适资源,你懂得!

  • 明确日常操作规范,避免误操作发生的几率。
  • 专业的网管软件。

     特别关注日常几百台网络设备的状态情况,比如电源、风扇和温度,***能够时刻关注这些数据的状态,出现情况可以及时报警。

  • 整理准确的设备登记列表,这是上市审计的必要工作,要求详细记录每个设备的机器号、场地和设备的运转信息等。

     如果前期不做好这个工作,当网络设备的规模达到1万台时,后期再做设备登记的工作将非常繁重,我们就经历了大概有小半年的时间来理清这些列表。如果有上市需求的公司,一定注意提前把这个工作做好。

#p#

  阶段四、10000-50000台服务器规模

  公司推出了搜索,业务蒸蒸日上。

  1.需求:稳定/灵活

  2.人员:明确团队分工,包括建设、架构和运维三方面。

  3.架构:超大规模数据中心,实现多地多点大带宽互联。

  4.挑战:

  • 业务对网络的稳定提出更高的要求,网络不能老断,不能出现丢包的情况。

     因基数增加导致设备故障频发,2014年360损坏了十几台网络设备,这种情况还是很严重。缩短网络设备的故障修复时间对网络运维工程师是一个挑战。

  • 上市审计

  5.陷阱:厂商激烈竞争会给网络运维工程师带来压力。

  6.经验:

  • 明确网络设备测试标准

     各家厂商的竞争白热化,出现设备间的对比,***的解决办法是明确网络设备的测试标准,所有的设备需要通过我们的测试标准才可以进入采购环节。

  • 在架构设计时消除单点故障,包括设备的故障,甚至光纤和路由的故障。

     多个路由经过一条光纤,如遇到野蛮施工,会出现多点中断,造成的影响较大,所以网络工程师要通过技术保障避免这种情况的发生。

  • 制定备品备件库和应急预案,把可能存在故障风险的设备进行列表,逐一排查,或者用其他设备进行替代,放置到备件库。
  • 网络建设运维自动化提上日程。

  阶段五、50000-100000台服务器规模

  公司完成上市,有充足的资金来进行网络的基础建设,也有更多的业务去发展。

  1.需求:弹性/前瞻/可视

  (1)弹性业务部门出现对网络的要求不明确现象。网络运维人员需要自发考虑网络弹性,更好适应业务的发展,或者根据不同部门业务发展情况的不同,进行内部设备的部署调整。

  (2)前瞻作为网络架构师或者网络运维负责人,需要预知业务的发展方向,并提前进行网络准备,安排好工作的顺序。

  (3)可视业务部门对于网络的运行情况实现实时可见,比如某业务的日常流量分布情况等。

  2.人员:团队分工/梯队建设

  团队分工更加明确,需要进行人员的梯队建设。

  3.架构:

  • 超大规模的云数据中心

     一个云数据中心定位在1万台以上的服务器规模。

  • 多地多点光传输网络
  • 自有BGP业务

  4.挑战:

  • 对业务和行业的发展方向有前瞻能力
  • 业务弹性的支持

  5.陷阱:SDN(服务定义网络)

  SDN的概念很火,个人认为有误导的嫌疑;厂商为了做SDN而做SDN,没有明确的目的性。这块建议其他公司在做SDN的时候,提前考虑清楚业务对于网络的真正需求是什么,然后现有的网络有哪些是满足不了业务的需求。可以明确看到云,网络虚拟化的需求,传统的网络是满足不了的,需要通过某种技术放到SDN下面去满足,这才是一个比较好的发展方向。

  6.经验:

  • 通过自动化工具提高人员工作效率
  • 提供网络可视化接口,提前打好基础,更好地看到网络运营的情况。
  • 更细粒度的故障监控,考量是否做到精细化运维的一个点。
  • BGP路由优化

     当你的路由在国内的运营商(中国移动、中国电信和中国联通)网络上跑起来以后,通过测试看起来网络是通的,但是国外运营商的网络接口可能存在问题,导致国外的用户访问不了360的BGP网络资源。这里有两个工具推荐使用,一个是Looking glass,大的运营商可以通过这个工具从他的AP网络查看你的BGP的路由收取情况,如果没有获得这块服务,需要跟运营商进行沟通。比如我们跟美国Sprint就出现过这个问题,业务运营一段,有用户反映我们的网络有问题。另一个工具是RADb,需要根据IP地址进行登记,欧洲的小运营商比较认可这个工具,费用大概一年400美元。

  总结与讨论

  1.老板是否重视网络团队?

  开玩笑的说,老板会在网络出问题时,重视网络。其实,老板本来就应该更关注公司业务,因为网络是为了满足公司业务的发展规模而生的,网络运维工程师的责任就是要提供一个优质的网络。

  2.把网络做好是否很难?

  领导对网络的重视程度是一个方面,抛开网络基础来说,把网络做好不是很难,只要做好两件事就好,一个是找到靠谱的人,一个是找到靠谱的设备。相对其他事情都简单一些。

责任编辑:火凤凰 来源: 51CTO
相关推荐

2013-06-09 10:38:54

IT运维管理运维管理ITIL管理

2012-09-03 10:39:13

Hadoop管理员

2015-02-04 11:45:52

高效运维

2015-08-29 13:03:24

运维技术沙龙MDSA

2017-07-25 10:53:27

2014-01-21 09:55:21

运维人员日志实践

2015-07-23 08:48:29

运维

2015-08-12 16:41:25

运维服务公共化

2015-08-05 22:34:33

运维技术

2015-08-05 09:53:34

运维自动化

2015-11-03 16:03:09

AppDeploy运维工具

2015-12-01 14:51:43

2012-06-28 11:35:27

BSM北塔软件

2012-02-23 10:26:55

新疆生产建设兵团运维实践

2011-06-30 13:41:52

系统运维

2011-03-11 11:47:48

IT运维

2016-01-12 11:38:19

智能化运维运维业务

2011-09-02 15:53:38

2016-05-12 17:23:43

用友iUAP

2017-10-09 09:12:35

携程运维架构
点赞
收藏

51CTO技术栈公众号