怎样构建基于SDN网络的自动化运维系统？

1、网络技术演进

1.1 历史回顾

网络已经发展了几十年，我们进行简单梳理，可以分为如下三个阶段。

• 第一阶段，是从七几年到八几年，这个阶段网络正在做什么？1974年开始，TCP/IP 协议的发布，开始了如何让网络更大范围连接的工作。
• 第二阶段，从1995年开始做快速以太网标准，1997年IETF成立MPLS工作组。在第二阶段中，2005年对于中国网络是很关键的一年，这一年中国电信 CN2 开始一期建设。在这一年出现电信级以太网概念，对大部分人可能不太熟悉这个名词，但它确实是里程碑式的概念提出。2005年左右，全球骨干网络基础建设大规模兴起。
• 第三阶段，2006年 SDN 诞生，2006年至今，SDN 的概念提出已有11年时间，在中国商用落地的项目并不多。2009年的时候，Openflow1.0 正式发布，在全球掀起了一阵风潮，大家好像看到一丝希望，网络开始改变了。Openflow1.0 发布后，接着几年没有任何动作。2011年开始 ONF 的成立带动了一把新的浪潮，2012年谷歌B4全面运行，2013年 OpenDaylight 发布，2014年 ONOS 发布。各行各业的玩家开始进入SDN领域。

1.2 SDN的兴起

左侧 Linux 基金会、ONF、ON.LAB，是国际知名的三个 SDN 相关的组织。中间部分是开源项目，包括 ONOS、ODL、OPNFV，现在 ONAP 正在进行 OPEN-O 和 ECOMP 两个项目的代码合并。

右侧是相关厂商，包括 Barefoot、bigswitch等，这些都是做SDN芯和盒子的硬件厂商。这几年，这些国际部分SDN发展都很快，最右侧是近几年的初创公司，包括Viptela、velocloud，最后两个是做CX、IX、DX业务。

在国际上，不管是开源组织、开源项目、初创公司还是与SDN相关的项目，在国内发展确实比较缓慢，我没有列出国内SDN相关的公司，能商用落地的少之又少。

2、传统网络运维现状

SDN 运维到底涉及什么？传统网络运维，满墙的运维规章制度只是给人看的，能真正落实执行多少，大家比较清楚。贴了再多的制度，而网络运维人员在做什么呢？

针对不同厂商的硬件设备敲不同的命令行，从 Cisco、juniper、到华为、华三，变化的只是换一种命令show / display 、no/undo。网络运维在整个运维体系里背锅背得最严重，上层业务出现问题，会时不时的把这个锅扔到网络运维，网络运维没地方扔，要么自己背，要么挖掘机来背。

运维部门每天在制定不同的规章制度，有些规模的会有自己的开发人员对开源软件和开源产品做二次开发。这些年，我一直参与大型网络的运维，几年前接触过一个典型的网络运维部门，开始他们团队只有十几人，当四五年后，业务系统变得更复杂，网络设备涉及的种类越来越多，运维人员也越来越多，基本翻了两倍。他们在做的就是 7*24 小时值班监控，告警不断的响。不停的写各种故障报告，编出各种各样的故障报告模板。这是我们正常网络运维在做的事情，这也是传统运维的现状。

3、SDN网络运维

3.1 DCN网络架构变迁

网络在发生什么样的变化？我们只能看到网络的变化，才能看到网络运维需要对应做什么变化。

这是 DCN 网络架构变迁，也是典型传统的三层组网拓扑，相信大部分网络运维人员现在维护的网络基本上都是这种网络。

这是基于 FABIC 设计的虚拟网络架构，接触 SDN 比较多的人应该知道这张图，这是 Facebook 前几年提出的DCN架构图，现在 Facebook 已经实现了基于 FABIC 的架构设计。为什么采用这种方式，原因是现在 CLOUD、NFV 等虚拟化技术发展太快。

普通的三层组网架构无法满足现有的虚拟化业务发展。本来云就是一个很复杂的虚拟化架构，无法用传统网络架构支撑它，于是慢慢衍生出基于FABIC这样的软硬结合的虚拟网络架构。

3.2 骨干网络架构发展

骨干网络技术演进，我们今天主要说的是区域骨干网络架构系统。

这是中国某张骨干网架构图，大概是二期的。本图发展将近10年，有变化吗？有，增加了点和线，看上去更像一张蜘蛛网。

这是基于 SDN 设计的网络架构图，也可以在 internet 上找到，这是 Google 前几年的设计图。底层是转发网元，分为不同的 Site，中间是控制面。在中间层的时候，controller 使用不同的功能模块实现对底层网元的控制。流量的调度和优化在最上层的 TE server 上做。

3.3 SDN NetDevOps

网络工程师对 DevOps 的理解不如做系统开发的工程师，这里就需要不同工种的协同工作。上面是 DevOps 能力环，从规划、代码到测试、发布完成一个全流程闭环，另外一个是 DevOps 关联的的研发、测试和运维三个部门工作关联图，交集的地方就是 DevOps。

重点谈谈 Network，这是针对后续几年，相信在国内是很大的空缺。DevOps 面向的人群更多的是系统开发、系统运维，原有的网络系统是属于传统网工做的。

现在国内传统网工会脚本的都不多，能否让传统网络和 DevOps 结合起来？答案是可以，现有的传统网络可以和 DevOps 结合，形成 NetDevOps。在 SDN 出现后，NetDevOps 可以发挥更大的优势。

在 SDN 系统里，有独立的中央控制器和上层应用层，转发层只是作为最底层的数据转发，业务编排在控制器做，控制器是纯软件系统，这套系统可以实现对外API对接，这时候 DevOps 可以真正体现出价值。

传统网络如何和 DevOps 结合？现有的传统网络设备是闭环系统，目前大部分的网络设备还是基于 CLI 命令行，新的硬件 OS 系统支持 PCEP、NETCONF 等协议，DevOps 和 Network 只能结合到这里，无法跟业务层做关联和适配。

3.4 SDN的运维工作

SDN 运维工作，主要包括两方面，一是日常运维工作，二是工程项目。日常运维工作和现在传统网络的运维相似，包括值班监控、一二线故障处理、各种会议、各种报告以及跨部门沟通。

重点是跨部门沟通，如果你现在从事传统网络运维，你打交道的部门是有限的，这是一个相对封闭的部门。它跟上层、应用部门的关联度很低，SDN化后会涉及很多部门，因为 SDN 的运维要参与测试、研发。这时候你的运维要提高一个层面，要更多的跟系统开发、软件开发做互动，DevOps运维恰好也涵盖了这三个方面。

运维里还有一个重要的部分，引入工程项目。这里的工程项目指的不是网络运维、网络设计的项目，指的是与软件开发、软件架构设计以及架构优化相关的，统称为工程项目。

新的功能开发包括已有功能开发优化，这部分是网络运维在做的。这个部门是由网工和软工组成的SDN运维部门，也可以是一个虚拟团队，这样的工种搭配在SDN运维里非常常见。

在去年以前，谷歌 SRE 很出名，SRE 的书翻译成中文，至今非常火。建议做网络运维的人可以看看这本书。这本书提到这两部分，里面有一段话说得特别好“任何一个运维工程师要有50%的时间用来开发、写代码”。

在SDN里，不仅仅是网络设备，不需要你直接敲命令、登陆设备，他的操作、运维、管理很多要靠系统完成，系统是需要开发的。如果你的大部分时间被日常运维占用，牺牲的是你的经验。

3.5 SDN运维工具

SDN 运维的常用工具，在传统运维和系统运维也会使用，包括 Cacti、Smokeping、Nagios、Zabbix，我们更倾向于开源，传统网络更倾向于闭源，需要网络工程师学习更多的开源软件，自己做二次开发，做出适合自己日常运维的工具。

4、SDN自动化运维

运维包括告警监控、统计分析、运维自动化和运维系统的建设。SDN自动化运维系统，这个系统并不是一个平台、一个工具，而是一个体系、一个方法。平台是运维系统的一部分，运维自动化完全跟开发相关，它不在平台内，平台内更多的是监控告警、统计分析，做到运维系统的建设。运维自动化更多的与 DevOps 相关。

4.1 运维服务质量设计

运维服务质量，在传统的网络运维里，网络工程师经常提出 SLA。作为运维人员没必要关心 SLA，SLA 是服务质量协议。运维人员需要关注的是 SLI 和 SLO，我们需要找到服务质量的指标是什么，根据指标制定目标。

至于SLA，这是和用户之间承诺遵守的协议，我们在传统网络里更多的关心网络时延和网络丢包率，我们需要考量更多的服务指标，很多跟上层应用做关联。

网络时延、丢包率以及端到端都可以作为衡量的指标，我们根据这个指标制定SLO，例如，你的时延要少于50毫秒，可用性要大于99.9%，这是运维人员需要关注的部分。

4.2 监控告警设计

运维平台、运维系统里涉及的内容，一是监控告警设计，通常从最底层的采集、存储、功能模块开发、上层告警通道、用户侧。从采集来讲，如果运维只是IDC或者城域网，这时候你需要集中采集、集中存储。

如果你维护的是全国性乃至全球性的网络，你需要分布式采集。现在大河云联的SDN控制器管理着分布在全球将近100个转发节点，对于这种规模，无法采用集中式，需要根据自己的业务分布点，制定不同区域性的分布采集，包括存储。部署中央存储和分布式存储，分布采集后实时同步到中央存储，同时需要在本地存储后做备份。

功能模块方面，只提到数据分析，为什么监控告警和告警通道之间增加了一层分析，你在底层做采集的时候，采集的是原始数据，规则是通过原有系统的规则，从监控告警到告警通道，做一个中间层，这是根据自己网络情况做的自定义的规则。

4.3 监控告警分析

告警统计分析，拿到告警原始数据后，如何更好的展现出来，如何把有用的信息实时同步。实时告警不像传统网络只有底层转发，这涉及业务系统的实时监控和网元实时监控，包括操作系统稳定性的监控，都会统一的在一个监控平台做。

告警统计，需要对所有告警信息做分类管理，只有把有用的信息分类后，才能进行第二步分析。报表管理，很多 SLI 和 SLO 的来自于报表，不管是设备、链路、系统的可用性从何而来，这是通过告警统计分析报表功能输出，你可以定月、定周对设备、链路做SLA需要的统计。

4.4 日志统计分析

日志统计分析，（左图）引用了没有做二次开发的图，很多公司都在用ELK，这是ELK的分析功能，可以针对自己的业务系统做不同的定制开发，可以制定住不同的统计分析模块。

日志包括全套SDN系统，从上层控制系统，中层操作系统、存储、业务编排，底层转发网元，这里的网元包括多种类型，最后是底层传输。这是传统网络不会涉及的，传统网络的网络运维人员只会关注网络设备，在 SDN 系统里，日志采集以及运维管理包含底层传输和上层应用。

4.5 流量统计分析

流量统计分析，现在网管系统和运维人员关注设备流量、端口流量，SDN 需要关注整条链路端口，更重要的是业务流量，SDN 最大的特点是能够跟业务系统做到关联，能够通过运维系统查看所有业务相关的流量信息。

4.6 系统分析

系统分析，对于大部分运维人员来说比较容易理解，这是物理服务器资源和操作系统资源。

这几个片子重点是 DevOps，控制器的开发和上线，用了这几年比较热的精益管理、敏捷开发，相信在座了解很多。

持续交付，指的是 SDN 控制器系统的持续交付，做到版本的快速迭代和实时响应，利用流程管理来打破研发、测试、运维之间的隔离墙。与运维相关的是自动化部署、自动化测试和集成测试。

自动化部署，可以集成到自动化运维平台里，可以作为一个模块集成到运维系统里，从发布、部署到交付运行，可以采用轻量简洁的工具，例如目前比较流行的 ansible。

自动化测试，测试分为两部分，一是自动化测试，二是集成测试。自动化测试主要对控制器开发、代码的逻辑性，更多的是与研发部门的沟通。

集成测试，这比 DevOps 提到的多一个集成测试，因为 SDN 运行场景更多的转发面的设计。自动化测试是验证代码的逻辑性，对部分场景需要用集成测试完成，包括功能性测试、异常测试和场景回归。

5、SDN运维体系架构

自动化运维架构体系，前面已经提到了很多内容了在这里做以架构概览做下总结。

目前从SDN系统来讲从最底层的资源，网络设备、转发网元、设备、服务器，采集部分开始，主要涵盖 SNMP 的采集，对传统设备 Netconf 命令下发，对新设备 Openflow 的协议，对CLI的管理。

中间的存储是独立分开的，中间有日志、配置库、知识库，在存储部分独立分开。功能方面包括监控告警和数据采集，数据分析和统计，流程管理和项目管理，有很大一部分是资源管理，资源管理包括文档配置，这部分主要基于CMDB，功能非常强大，如何结合SDN系统用起来，要根据自己网络底层和控制器开发做制定。

故障自愈和关联分析，如何让告警信息形成关联，出现10个告警时，能否在你的手机或者邮件上看到10个告警，真正有用的只有1个。故障自愈系统是在关联分析后实现的，当出现10个故障，如何让故障自动消失，不需要人为干预管理，这是自愈的功能。另外需要有安全策略贯通底层和上层。告警渠道可以包括邮件、WBE、微信、Call Center等。最上层为不同的权限用户入口。

故障处理流程，在大部分的网络运维里只有第一项，运维中心在做的是受理用户故障申告以及接收监控系统告警，自动化运维平台流程里会增加故障自愈系统，根据场景开发定制，输出处理建议。

当你今天收到用户和系统的申告，如何让告警下一次不再出现，这需要我们工程师制定这样的场景，根据处理逻辑形成闭环，逐步的完善自动化运维系统。