网络管理离不开拓朴图的构建

   新浪微博：@wandering

10余年的易县网站建设经验，针对设计、前端、开发、售后、文案、推广等六对一服务，响应快，48小时及时工作处理。营销型网站建设的优势是能够根据用户设备显示端的尺寸不同，自动调整易县建站的显示方式，使网站能够适用不同显示终端，在浏览器中调整网站的宽度，无论在任何一种浏览器上浏览网站，都能展现优雅布局与设计，从而大程度地提升浏览体验。创新互联建站从事“易县网站设计”,“易县网站推广”以来，每个客户项目都认真落实执行。

    博客地址：  dayong.info

   全职做网络工作的时间，差不多快五年了，正好与女儿的年纪相仿，而恰恰这二者又都是自己生命中最重要的经历。女儿刚出生时，还完全没有意识到自己角色的变化，随着女儿不断成长才越发感受到作为父亲的自己身心发生的变化。同样，经历了几乎从零开始的痛苦职业转型后，通过几年网络历练，终于让自己找到了一种脚踏实地的信心和喜悦。

   进入正题，就像在前一篇文章《网管的三个重要服务：AAA、NTP和SYSLOG》所讲，在网络工作初期遇到了大量的困难和挑战，其中最紧急、最重要的是故障处理。

   为什么说故障处理是重中之重呢？

   无论是新人或是老人，无论是学习还是交流，无论是优化网络还是架构设计，一旦发生故障，特别是重大故障，那就必须调动足够的资源优先处理，尽量降低服务所受影响，缩短故障处理时间。而故障处理，特别考验一个网络工程师的综合能力，对网络架构的了解、对各种设备的熟悉、对相关技术的掌握、对问题的分析和把控、对产品应用的了解以及面对突发事件的心理承受能力等等。

   因此，提高自己的故障处理水平，成为了首要发展目标。

   为了达到这个目标，采取了一些措施，包括：

   1）将全网所有IDC的网管服务器、核心设备、边界设备、×××设备、重要汇聚交换机，全部登录若干遍，首先保证发生问题时自己可以登录到故障相关设备，并对设备对一定印象和了解。

   2）熟悉不同厂商设备的基础操作命令，并制定一些任务或场景，例如查看CPU确定影响CPU的常见因素和解决方法，例如可能发生的各类故障相关的信息收集、状态检测和操作处理，例如关键二三层协议的状态检测和常用操作方法（STP、OSPF等），例如如何快速上线替换设备，例如如何快速定位故障位置等等。

   3）熟悉不同IDC的关键设备的物理、逻辑连接关系，IP/网段，功能作用，关键配置，特殊之处等等。

   4）大量阅读线上设备相关文档，与工作相关的经典技术书籍中的相关内容，与老同事大量沟通，在处理故障时第一时间咨询了解对方的做法以及自己的处理方法是否得当。

   5）重新学习和理解一些网络原理，例如什么是以太网，例如GE接口到底能跑到多大带宽、为什么？例如为什么光接口会出现CRC错误？

   6）开始使用文本记录一些关键网络信息，后来发展成为个人的CMDB。

   *注1：为什么使用文本？跨平台、高效检索、可以被外部程序调用。

   *注2：为什么不做在线CMDB？精力能力有限，公司已有CMDB，另如果已有CMDB好用的话……

   上述措施让自己迅速进入了工作状态，更重要的是身处良好的技术团队。

   接下来，发现越来越多的事务和故障，需要熟悉和了解IDC间的连接关系及其角色功能。

   IDC南北向流量靠得是ISP提供的互联网出口带宽，而东西向流量依赖大量的专线和×××，当可以解决一些个体、局部问题后，就自然而然地关注到一些结构性、与互联相关的问题了。

   因此，为自己定下了另一个目标，绘制出公司全网的专线和路由连接拓朴。

   而促使自己这样做的另一个原因是，当时网络团队内并没有全网的物理或逻辑结构拓朴。这样会带来一些问题，例如团队新成员需要花费大量时间熟悉网络，虽然这是必须经历的过程。例如并不是所有人都对整体网络架构十分清楚，每个人心中的网络结构都各不相同，这给沟通和协作带来不便甚至是障碍等等。

   下面六张拓朴，就是几年来不同时期所绘制的网络拓朴，这些版本基本上是延续发展的。从拓朴图的变化，能够反映出自己对网络的理解、认识、态度的变化，也能反映出公司网络的变迁。

   阶段一

   拓朴涵盖的仅仅是自己所关注的几个重要IDC，及它们之间的重要专线等连接关系，比较简陋。类似的拓朴，很多同事都画过，这似乎是网络工程师必经的成长之路。但这个拓朴给我帮助很大，它的存在使自己能够把每一次思考的收获都累积起来，并不断完善和改进。

   阶段二

   内容有所丰富，重要的变化是增加了互联接口和地址信息。当时网络内是OSPF与静态路由混用，路由调整非常复杂。经常因某链路发生拥塞而需要找到流量大户并通过静态路由拆分流量的情况，稍有不慎就会导致路由错误。而当个别链路故障中断时，流量分析、重新选路都是全手工操作，非常恐怖。

   当一次一次在深夜里被叫起，需要在最快的时间内判断链路故障、制定临时解决方案、进行大量静态路调整时，下定决心改变现状，那种经历真的真的是一种折磨。

   阶段三

   于是有了阶段三，此时全网主要链路都已经被OSPF覆盖，虽然在一些窄带链路上还有静态路由存在，但基本上绝大部分手工切路由的情况没有了。所关注的范围扩大到全网所有路由节点，并在拓朴中加入更丰富的信息，期望可以从拓朴中找到故障处理和日常变更的最关键信息。例如route-id，例如cost值，例如互联接口和互联地址。

   另外，在绘制拓朴时，尽量做到：将图缩小看全局时结构清晰、关系直观明确，将图放大看局部时信息丰富、易于与外部关联，尽量在有限空间内把所有路由节点展示清楚。很快，这份网络拓朴图成为团队同事人手一份参考文件，并由自己来定期更新和维护。

   当整个团队面向同一个拓朴时，大家就从在脑海里构建网络结构的事件中解脱，在相同的信息基础上对各种问题进行分析和探讨，哪些节点没有冗余，哪些链路流量走向不合理，哪里需要扩容等等，事情变得越来越好。

   阶段四

   此时，网络团队的关注重点变成了如何让自己从被动扩容和链路冗错处理的事务中解脱出来。

   首先，将不重要的节点从拓朴中清除掉，改变以住的三角型IDC承现关系，尝试利用现有的链路，参考位于不同ISP的核心节点，从所有IDC中选出一组环型节点，创建出一个逻辑上的骨干网，其它节点全部降级为连接到骨干网的接入节点。

   为了满足两个主要ISP间的占整网流量多数的传输需要，每ISP选择2个骨干节点，分别在两对不同ISP节点间建立2条逻辑链路，以达到两个ISP间共4条逻辑链路的效果。为了达到这个目标，将全网OSPF链路cost值全部改为手工指定，严格地按照设计的传输层次设定。

   另外，为了达到骨干传输效果，甚至放弃了几条大容量专线，就是因为这些专线一旦使用，会导致结构性的破坏。为了使整个团队接受类似的观点，花费了大量时间用于沟通、技术交流、基于拓朴模型的故障模拟，经过多次改进和完善。

   最终，从阶段四的设计和规划阶段，发展到阶段五。

   阶段五

   至此，骨干传输网络概念终于确立，之后的IDC选型、专线扩容、网络规划等一系列工作，都变成了有理可依、有据可查的局面。而网络工作，也慢慢离开了救火队的角色，尽管网络变得更复杂、更庞大，但一切井然有序，可以清楚地知道有哪些问题存在以及解决问题的优先顺序。高度可靠、稳定的网络结构，保证了在发生故障时最大程度地减少了服务中断情况发生，使网络团队从巨大的业务影响压力中解脱，发生故障时可以安心解决故障。

   接下来，新的挑战不期而遇，大量的IDC间数据调用，导致传输网容量迅速出现不足的情况。正是因为前期解决了结构上的根本不足，所以扩容问题带给网络团队的只是选择哪种扩容方式而己，可以把主要精力用于研究当前和未来需要关注的事情上。

   阶段六

   公司网络的近期情况，最终选择通过波分技术将现有专线扩容，其扩容能力至少可以满足未来3年的发展需要。除了传输骨干网容量的提升，还在减少设备和链路单点故障、减少传输网与交换网相互干扰、流量分析、网络监控等方面投入了更大的精力。

   不久前，网络拓朴维护工作正式交接给进入部门一年多的一位新同事手中，感觉就像把自己精心呵护长大的孩子交给别人一样。目前，公司在网络互联上，已经走上正轨，只要不是为了改变而改变、为了业绩而改变，而是站在网络发展和业务发展的实际需求上客观分析问题，寻求解决方法，一定会发展的越来越好。

   以上就是自己所在公司网络的发展过程，希望对网络同仁有所帮助。仍然没有涉及过多细节，因地制宜、因人而异，重要的是想法和思路。

   *注：文中拓朴，已尽力缩小和对关键信息处理，力求即不泄露公司机密，又能展示拓朴要素，如有不详还请见谅。