更多相关内容
传统运维的转型，企业网络中如何应用可编程网络NetOps？
传统网络运维的问题
- 过于依赖人工。网络运维大多数是依靠网络团队在部署和维护交换机，而不是自动化；
- 惧怕网络变更。运维人员认为在当前环境下做的变更会对整体网络环境造成极大运行风险；
- 过于被动。大部分网络人员的精力都用于处理问题，而不是推进战略计划，而这些问题往往是手动更改配置时出错造成的。
传统网络运营实践的目标是最大限度地减少网络服务中断。因为从这些环境中发展出来的网络过于脆弱，无法适应服务的快速发展。经常进行变更就意味着会出现故障，这就导致了冗长的变更管理审查流程，网络团队对网络变化的普遍厌恶及日常存在大量补救性的被动工作。而NetOps 的主要目标就是解决这些长期存在的问题。
可编程网络NetOps 如何优化网络运维方式
理想情况下，它能帮助 NetOps 团队更成功地实现以下目标：
- 使运营更加自动化；
- 高度的敏捷迭代能力，而不是一味惧怕变化；
- 具有预见性，而不是仅做被动反应；
- 使网络具有弹性，脆弱。
NetOps 致力于在网络管理中使用更多维度自动化。比如临时的自动化脚本，通过代码管理、设置工具和实践标准，编写出可靠的脚本在网络中运行。另一些情况中则采用基于平台的自动化，如基于意图的网络（IBN）。
与传统的运维不同，NetOps下的网络团队反而是希望环境经常发生变化，不断将新服务投入生产并实现功能迭代，与其厌恶变化，这类团队会将注意力集中在尽量减少变化可能带来的副作用上。他们希望在测试部署中不断完善自动化后，在生产中使用自动化地启动新服务，并继续使用自动化工具快速纠正之前未遇到的问题，使环境的部署和更新变得更加顺畅和正确，使网络更加灵活弹性。
可编程网络NetOps与网络运维中心：非此即彼还是兼而有之？
NetOps 会取代现有的网络运营中心并使其过时，还是会重塑网络运营中心，使其更好地满足当前和新出现的需求？
当然是后者。尽管变化正在形成，但有两点是肯定的：网络运维中心是各个方面的核心。网络紧急事件仍会发生。如果没有网络团队的服务，大多数组织的业务都会迅速停止。设备和服务仍然会出现故障，外部不法分子仍然会发动攻击，不可预见的新问题仍然会出现。但是，随着 NetOps 的引入，传统的网络运维中心也将发生演变，主要是变得更加自动化。NetOps理念下的网络运维团队将随时准备好详细的自动化的指令编排手册。这些指令让团队以经过测试的并且可重复的方式尽快实施变更，而不会出现让事情变得更糟的错误。
最终，一个理想的自动化运维越来越有可能实现：针对检测到的问题，网络监控工具只需通过执行自动响应处理问题，同时向员工发出警报。虽然大多数企业的网络团队离全自动响应方案还有很长的路要走，但 NetOps 的迅速崛起正在使其成为一种趋势。
星融元的云化园区网络架构天然地支持NetDevOps。基于云化园区交换机所搭载的AsterNOS及其SDK、REST API，我们以下面一个安全运维场景来说明。
如上图所示，出于对安全的考虑，网络运维人员往往需要对重要的应用系统进行访问情况的审计与分析；针对这些应用系统，如果发生了访问控制的缺失、访问状况的异常，管理员希望第一时间得到通知，以便采取相应的动作。这些审计与分析的内容可能包括：网络对重要应用系统的访问是否进行了控制（以便判定该应用系统是否被保护）、对这些重要应用的访问情况是否发生了突然的变化（以便判定该应用系统是否处于可能的攻击中）等。
下面，我们就来看看通过AsterNOS SDK如何便捷、高效地实现这一需求。在网络中，访问控制一般是通过ACL（Access Control List，访问控制列表）实现的
AsterNOS支持ACL功能，并且能够提供所有ACL被命中过的统计数据；AsterNOS SDK所提供的REST API中，包含对ACL各个字段和统计数据的访问接口，通过调用这些接口，即可直接获得ACL的这些信息用以分析。具体思路如下：
- 重要的应用系统可以用IP地址来标识（如果需要更精确地定义，还可以增加该应用所使用的TCP/UDP端口信息）；
- 通过调用REST API，获得AsterNOS中当前配置的所有ACL的“目的IP地址”字段，以便判断所定义的重要应用系统是否被ACL进行访问控制；
- 通过调用REST API，获得对这些重要应用系统的访问量的统计信息，以便判断是否出现异常状况；
- 对于出现的访问控制缺失或访问异常状况，该程序自动通知管理员进行干预。
假设运行着AsterNOS的网络设备的管理接口IP地址和端口为192.168.1.200:4430，则上述思路的示意性伪代码可以如下：
| DEFINE Key_App = [(DstIP1,T1), …, (DstIPn,Tn)] | //定义所有关键应用DstIPx及其访问量阈值Tx |
| GET https://192.168.1.200:4430/rest/v3/acl/ | //获取该系统中所有的ACL TABLE |
| GET https://192.168.1.200:4430/rest/v3/acl/TABLE_y | //获取每一个ACL TABLE中的所有ACL信息 |
| IF( DstIPx = TABLE_y:RULEz:"dst_ip" ) { | //检查每一个关键应用是否被某一条ACL所防护 |
| "log: DstIPx is protected." | //如果被防护，则可进行访问情况分析 |
| IF( TABLE_y:RULEz:"stats" <= Tx ) | //如果访问量未超所设阈值，则认为正常 |
| { "log: DstIPx is normal." } | //记录日志 |
| ELSE { "warning: DstIPx is ABNORMAL." } } | //否则，认为异常，告警 |
| ELSE { "warning: DstIPx is NOT protected."} | //如果未被防护，则告警 |
这段伪代码仅用于示意，并未严格地写出循环、边界条件判断、具体日志与告警实现等。其中，“GET https://192.168.1.200:4430/rest/v3/acl/…”即AsterNOS SDK中获取ACL及其具体信息的REST API，“TABLE_y:RULEz:”dst_ip””和“TABLE_y:RULEz:“stats””即一条ACL的“目的IP地址字段”和“该ACL的命中数量统计”。需要强调的是，编程者通过AsterNOS SDK的REST API获得的已经是ACL的每一个具体字段及其值，无需再使用复杂的文本解析程序进行处理。
将这段非常简单的程序用Docker进行容器化封装，部署在AsterNOS中，并且自动化地定时运行，即可实现前文所述的运维需求，并且，通过对更多ACL字段与值的调用，即可实现更高级的运维功能。
更多有关星融元云化园区网络相关咨询，请参考：https://asterfusion.com/campus/
