数据就是资源，就是财富，现如今，随着数据的激增，越来越的互联网企业意识到建设自己的数据中心对自身业务的发展是多么的重要，因此越来越多的企业建设数据中心。 京东在2017 年最大的一个变化就是，很多独立的业务部署了自己的数据中心，京东大规模数据中心就是监控之眼，监控着京东的“一举一动”。
网络，相当于是互联网服务的神经系统和循环系统。监控，是网络运维团队了解网络服务的眼睛。
随着网络规模的高速发展、运维技术与理念的演进，网络监控已不满足于简单地掌握网络设备的运行状态、流量、延时和丢包。
如何准确地表现出服务的可用性、快速发现问题和定位问题，提高手工运维和自动化运维效率是迫切的需求和挑战。
本文分四个部分介绍京东网络团队在监控方向的一些思考和实践：
京东网络现状。
监控设计思考。
京东监控实践。
网络监控展望。
我们可以从数据量表上来看京东的业务增长，下面是京东的一张覆盖了 2014 年 618 到 2017 年 618 所有的出口和专线的数据流量的图表。蓝色是专线 DCI，红色是互联网的公网流量。
从上图中，大家可以看到 2017 年 618 的 DCI 流量增长非常非常快；对比上一年，它已经翻了将近一倍，主要的原因是大数据和一些后台的日志分析等系统占了很大比例的流量。
2017 年最大的一个变化就是很多独立的业务部署了自己的数据中心，而以前京东的各个业务混杂到一起。
不同的业务出现了自己的数据中心，说明了不同的业务对网络的一些硬件和结构、性能和品质有了不同要求。
而以前（特指在 2013 年和 2014 年期间）京东是仅仅来解决基本的通讯问题，比如：带宽或者简单基础的硬件可靠性问题。
网络架构的持续优化
在网络架构的持续优化上实际有很多小的细节优化，但是抽象出来的只有四个方面进行了持续的投入。
全国骨干网结构升级
对于全国骨干网来说，京东在很长一段时间内是部署在北方地区也就是北京，而 CDN 却是部署在全国；中后期在广州也部署了一些核心的节点，以及部分海外节点。
但是，当时并没有形成一个整体全国性的传输网络。今年，我们完成了改造的最重要的第一阶段：启动了在北京、上海、广州三地双平面的全国 100G 传输网络平台，目前处于建设初期。
互联网接入层建设改造
互联网接入层主要是自建 BGP，解决的是互联网质量的业务体验问题，而我们没办法简单通过单线、第三方互联网解决。
在方案的设计过程中还发生了一些细节的变化，比如说：城域网从原来的四核心改为双核心结构，所有的数据中心都会双接到这两个核心上，这样结构简单、流量易于调度，在管理、自动化、可视等各个方面都有优势。
在未来我们想达到这样一个理想效果，当南北运营商网络出现大面积网络异常的时候，我们在纯粹路由的层面完成业务切换。
DCN 二层到三层的改造
我们最近一年半最痛苦的问题是网络规模太大了，现在一个网络里面至少 10 个 POD，有大量的服务器和 Docker，当前架构下设备的性能、稳定性达到了上限。
网络设备不能简单地关注端口密度、带宽容量、电源容量等，还要考虑 ARP、路由等各类表项资源，它们都是影响系统的重要因素。
在二层网络里我们做一次网络核心的故障处理，从故障状态到可用状态整个过程大概经历了五六个小时以上而且是两天完成，整个过程就像拆弹一样，操作复杂且有极高风险。
所以我们后来在运维、基础架构上列了几个规矩：
网络可以做到可以在 10 分钟内完成应急案处理。
部分网络损失不对网络造成致命伤害。
结构要非常简单，具备较好的可扩展性、可运维性。
提高网络割接的可靠性
网络主要有运维和建设两个方向。过去一年半里，京东网络团队有 60% 以上的精力消耗到建设上，因为发展太快了。已发生的夜间割接，2016 年 300 多次、2017 上半年超过 300 次。
为了确保网络操作的可靠性，我们建立了标准化的 SOP 操作文档、技术方案审核、双人操作等多种机制。并且，我们已在推动自动化工具逐步替代手工操作。
网络环境愈发严峻
除上述的问题外，如今的网络环境也愈发严峻。目前的网络规模越来越大，变更次数越来越高，业务场景越来越复杂。比如：上面我们提到过的为业务特别树立的一个独立的数据中心，就会出现特有的故障。
另外网络抖动问题会越发明显，通常这抖动网络上不易感知，而应用系统或用户对抖动问题却很敏感。
从做事情的角度，从提供良好服务的角度，我们应该分析到底原因是什么，该怎样解决、谁来解决。
运维工作量和效率也是非常大的挑战，例如：业务方提出 500 台服务器的从单网卡改为双网卡的 Bond，同期发生几起不易定位原因的故障需要分析排查，每件工作都是对运维力量的剧烈消耗。
当人员大量消耗在这些事务性工作上的时候就没办法做好架构优化、改进的工作了。从团队利用率上来说，我们的工作效率实际上是下降了的。
大家看上面这张图，这是 2016 年部分时期的可用性统计指标。图中有几个结果很差的互联网可用性，通常是有一些故障和问题导致的，这些问题大量的消耗了我们的运维资源，是我们最优先要去解决的问题。
业务要求日益增高
之前业务要求相对简单，带宽不够则尽量做成 1:1 收敛比，设备可靠性不够则增加冗余，容量不够则扩大规模。
现在业务对超大规模数据中心、超大路由表项、低延时、25G/40G 差异化接入都提出了更高的要求。
特别是网络的稳定性，网络团队需要更全面、精细的感知网络，快速发现和定位问题，减少重复问题的发生，制定有效的应急预案，确保高水准的网络可用性。
另外，业务希望获得更多的网络信息和数据，以帮助业务进行更好的部署、管理和调度。例如及时准确的主机 IP 网络接入位置信息、流量和网络质量信息等，需要网络团队开放更多的 API 和功能支持上层应用。
最后，网络排障和问题分析，是各个业务团队的常规需求，要么是网络运维团队协助排障，要么是开发出友好的工具提供给业务自助完成，显然后者是良性发展的必然选择。
监控设计思考
明确监控目标
明确监控目标的几个关键性步骤：
首先，“网络是不是好的”，核心是定义“好”的标准。
其次，要准确感知到网络异常，关键是做到对网络核心监控项准确监控。
最后，要快速定性问题并触发应对措施，核心是决策机制，确定严重程度、影响面。
定义网络“好”的标准
什么是网络“好”的标准？用户觉得好才是真的好。
网络工程师在面对问题时的本能是排查分析问题的原因、尝试修复故障，往往眼里只有网络设备、功能协议的运行情况，异常状态和现象，而忽视了网络服务的核心是满足业务的联通性需要。
当网络规模到了一定程度之后，一两条链路或几台设备的好与坏说明不了整体网络服务是不是好的问题。
网络团队要站在更高的层面，脱离只关注白盒、只关注网络设备的思维，从用户视角看网络服务情况。
找到感知网络的有效方法
知道什么是好网络，我们就要搞定感知网络，就要模拟用户的视角，做黑盒监控。
京东网络团队在 2016 年下半年开始在黑盒监控方向走的比较快，进行了大量的实践和尝试。黑盒监控本质上还是白盒，但需要改变思维方式。
例如：交换机板卡重启仅仅是导致网络抖动的原因之一，用户视角看到的是网络抖动，在处理逻辑上要先定性网络出现了抖动再定位是什么原因引起的。
另外，在做网络核心项监控时，要抓大放小，不要什么都想一步做好，把最常见的、最严重的故障优先识别出来，首先解决核心问题。
网络异常处理的预案与决策机制
网络异常主要有两类：
依靠网络自身的健壮性，可以自愈或承受的，往往这种仅降低网络的健康度、增加了不可用的风险；这类异常不是我们关注的重点。
明显影响了网络局部或全部服务的可用性，但又没有导致网络服务中断或完全不可用，只能通过人工干预来执行应急预案的异常事件；这种问题才是最关键的、需要及时处理的。
网络监控到底要做什么
这是一个简单的总结，网络监控要干什么？随着监控的深入，我们发现想象的网络质量跟我们主观实际测到的确实不一样。
监控要看啥呢？故障可用性、健康度、交付质量，就是一个新的网络建设完以后，这部署立刻部署上、完成验收、操作的影响。我们做一个专线切换真的就是平滑的吗？我们下线板卡没有影响吗？
但是因为没有数据我们以为是好的、还有运行状态。做好以上这些才是网络监控要做的事情。
（原标题：京东大规模数据中心网络运维监控之眼）
