如今IT发展风起云涌如火如荼，各领域技术百花齐放，各山头厂商占地为王。纵观整个IT江湖，虽拥有众多的昙花一现和太多的不确定性，但以应用为王体验至上的演进方向却未曾改变。毕竟人类的发展史就是聪明人的偷懒史，IT领域自然也逃脱不了这一规律。概括一下当前的IT发展状况：快速服务是目的、自动化是手段、DEVOPS是方法。DEVOPS是一种思路一套方法论，也是IT界游戏规则的改变者，它打破了传统IT各领域的边界，以一种贯通的视角来实现整个IT的自动化 。如今网络和IT运维人员已经开始广泛寻求和部署自动化的解决方案，并借此来节约资金和提升使用体验——提升服务质量、提高运营效率、应用快速上线等。
DEVOPS落到网络领域被称作NETDEVOPS或NETOPS。NETDEVOPS的本旨同样也是追求新型服务对应网络部分的自动化和智能化，期冀借助NETDEVOPS来简化工作内容、提高干活效率，提升业务准确性。无论是日常业务的工单部署，还是故障问题的Trouble-shooting，每天事情还是那些事情，活也还是那些活。但如果有个一种工作方式，或者有一个可按需定制化的工具，能够让网工每天降低工作量和压缩工作时间（活可没少干），从而能为自己腾出更多的时间来折腾自己喜欢的事情，这应该是一种较为美妙的工作体验！ 这是一种变被动为主动的工作方式，理想（想象力）还是要有的，可能一不小心实现了呢！ 另一方面，DEVOPS还能给网工提供了一个“个性化艺术创作”的平台，让您以一种“玩出花儿”方式来完成自己的日常工作，让您的工程师精神（工匠精神一个分支）得以展现。
提到DEVOPS，网工通常第一反应就是编程，会觉得头疼。确实，如果让您由零开始学习编程再来DEVOPS的话一定会让人很头疼，毕竟不是科班出生，再怎么折腾也干不过码农。但如果这里的DEVOPS只是让您依葫芦画瓢，是不是感觉就好多了。 比方，如果只是需要大家掌握的编程能力就是以下这两种方式，是不是就简单多了。
如果（条件一），我要（结果一） （IF语句）；
当（条件二）时， 我要（结果二） （While/For 循环语句）；
实际上，由零开始的DEVOPS并不建议从写代码开始，而是应该从掌握一些现成的工具开始。DEVOPS是否简单易行，关键还得看工具所提供的功能是否足够强大。如果条件语句和动作语句都有现成的葫芦可以来参考的话，画个瓢应该不算太困难。这样一来问题的关键变成了两点：一是需要描述清楚条件，二是需要描述清楚想要实现的结果。其实DEVOPS起步阶段大概也就是这样，也许最终你会发现这两种语句已经能够覆盖了日程工作中绝大部分的DEVOPS开发需求。
如果已经能够清晰的描述清楚“我的条件”和“我要的结果”，接下来的问题就是如何将这两点转换为机器能够识别和执行的语言或脚本。想要简单顺利的完成这一转换，最关键的就是DEVOPS编程开发所基于的平台， 也就是所谓的“站在地上和站在肩膀上”的区别。 即平台所能提供的API库（也有称作原型），当然这个库里面有针对条件描述的功能库，也有针对结果执行的功能库。如果您的条件和您要的结果，平台库里面基本都囊括了，编程就不会是大问题。 不要怕程序编写得不好，再烂的程序只要没写错，其效率和准确性也会远远高于手工操作。就算程序有写错，在正式上线前还有若干的机会可以去试错。
二、JUNOS 提供了丰富的DEVOPS接口
JUNOS Automation/DEVOPS STACK架构图
JUNOS是Juniper所有网络设备（路由器/交换机/防火墙）内置的操作系统，JUNOS天生具备可编程的特质，大概也是目前业界提供最广泛编程（DEVOPS）接口的网络设备系统。在通过设备管理进程（Daemon）作为DEVOPS交互窗口时，得益于系统内自身基于XML的配置存储和命令交换格式，JUNOS提供了清晰的层次化结构和自我描述性，能让程序快速高效的筛选和获取到相关数据信息 。JUNOS还提供了丰富的API接口并预定义了很多程序模板库（PYEZ / RubyEZ），能让程序员更加简单方便的开发出与其生产相关的自动化程序。大多时候只要能熟悉XPATH表达式，就能轻松提取到设备相关状态信息参数，并可以动手写出想要的自动化DEVOPS程序。
JUNOS 基于XML的信息展示（层次化的自我描述，轻松定位和获取所需信息）
有多种方法可以将网络集成到IT自动化方案中，有些是厂商定制的，有些是第三方开发的。它们可以是独立运行的服务平台，也可以是运行在设备上的客户端，比如CHEF、PUPPET、ANSIBLE等。除此以外， Juniper还提供了最新的自动化工具包JET，JET让JUNOS能够更加轻松的参与到编程中，并具备相当的弹性和扩展性。JET甚至可以不用通过设备管理Daemon与设备进行交互，而直接与设备诸如路由和接口等其他Daemon进行交互， 能够让第三方开发者轻松接入并实现定制化的网络控制 。（是不是感觉似曾相识啊？对了！SDN控制器说到底也就是这个套路）
除了对Python天然良好支持外（目前JUNOS已经支持设备在线PYEZ编程），JUNOS也已经支持JSON格式的数据格式。众所周知因为其简单和轻量级的数据交换（应用和设备之间）的益处，JSON已经变成当下较为流行的一种可编程数据格式。为了丰富自身支持的编程语言，JUNOS操作模式下已经能够吐出JSON格式的数据，并且也接受JSON格式的程序命令输入。
另外，JUNOS内部超低延时的编程数据库，给DEVOPS和自动化编程带来了极大的便捷性。借助于此快速数据库，JUNOS能够处理每秒1000次的配置变更（配置验证交由外部系统完成）。目前，SDN控制器和应用程序都受益于这个快速数据库，可以对JUNOS设备的控制平面和数据平面进行迅速的配置下发。
JET工具包提供了一系列API接口， 还提供了多语言诊断功能，能够让任何编程语言来调用JET。使用JET API开发的应用程序也是兼容二进制的，可以在支持JET的任何JUNOS平台上运行，这种跨平台的一致性API支持已经在内部使用。JET基于Apache Thrift，任何集成开发IDE平台 都可以用此来开发外部应用程序。 现在，在JUNOS系统上快速简便的自动化脚本是通过安装JUNOS PYEZ来实现的，PYEZ已经定义好了许多常用的程序库（connect设备、get设备信息、set配置下发），后面的几个DEVOPS案例都是通过PYEZ来轻松实现的。
三、JUNOS DEVOPS简单应用落地
NETDEVOPS的应用落地有多种形式，仅在管理运维领域就可以有多种方式。ZTP是目前比较常见的一种应用落地，业界各个厂商都推出了相应解决方案，这块在此就不累述。除去快速自动化部署ZTP外，当前DEVOPS的实现还集中在这么几块：数据信息自定义格式展现、配合应用的设备配置迅速变更、Trouble-shooting以及元素信息的快速查找等。 接下来列举几个我们做过的有代表性也较有意思案例 。
DEVOPS 案例一（信息自定义格式的展现 ）
在新型的园区网中，除了对原有网络设备的管理维护外，也出现了许多针对接入用户的管理维护需求。目前比较典型的应用是高校园区网的用户精细化管理，能够让网络管理人员清晰的了解网络辖区内的接入用户情况。在现有的高校校园网中，用户的接入方式多种多样，有线用户有传统静态的、动态DHCP+的，也有宿舍区运营商共建PPPoE方式的；而无线常见的为DHCP方式和802.1X方式。而在接入用户的区域分布上，运维部门也有相关需求，希望能清晰的看到各个区域不同时间段的用户分布信息。
基于以上客户需求，我们结合JUNOS PYEZ进行了相关程序开发，在工具里面除了抓取了BRAS设备的常见信息外，针对BRAS上面用户进行了接入种类、用户接口（区域）分布、数据库可达性监控等内容。其实思路方法也较为简单，就是先通过XML RPC命令抓取所有在线用户的信息，然后按照接入方式、接入地点（接口+VLAN），经XML自我描述关键字进行筛选和循环统计，最终就获得了一份符合运维人员阅读风格的信息展示。
在程序后期的功能开发上，又引入了厂商识别功能，能够让Python程序先进行厂商自动识别，再读取和分析相关用户数据信息。同时又增加了Trouble-shooting工具功能，能够让运维人员在输入用户相关信息后（账号/IP/MAC等），快速查看到此用户对应的关键状态信息，便于问题分析和跟踪处理。
注：以上所有NETDEVOPS都是基于抓取的设备信息进行二次编辑完成的，并未对设备执行任何配置变更的操作。个人感觉可以先进行此类DEVOPS的尝试，因为不会对在线设备造成任何业务影响。
DEVOPS 案例二（应用下发配置变更）：
在BRAS用户接入的方案中，用户的接入控制由BRAS路由器执行，用户的账户信息则由后台数据库（Radius/AD/LDAP）进行认证和记账。在实际部署中某些特定情况下，可能会出现 前端BRAS和后台数据库用户信息不同步的状况。原因有多种，有些是链路质量造成的认证记账报文丢失，有些是服务器性能瓶颈导致的。比如BRAS侧已经创建了用户session并递交用户认证信息给到Radius数据库，但数据库侧还没来得及创建用户表项，这种情况下用户后续认证流程无法完成，会出现“吊死”的状态。这时最简单最迅速的解决办法就是让用户自己“清空”自己，重新来过就可以。基于此思路构架，后台软件厂商在用户Portal页面上设计了“清空”按钮，而“清空”按钮对应的程序就是基于PYEZ的CLEAR清空命令操作。
我们提供给应用（Portal）的程序非常简单，只有短短的7行。能够让Portal Server自行登录到BRAS设备上完成相应异常用户的清空操作。 试想一下，通过这个简单的DEVOPS程序，网管运维人员能够省去多少此类异常用户的报障。有问题就会有处理办法，虽然不一定都是能正面解决问题的办法，能够规避问题的办法也未尝不是一个好主意。
DEVOPS 案例三（信息二次算法后排错）：
防火墙是以策略为核心的安全防护工具，策略的好坏决定了防火墙的防护能力。随着防火墙部署时间的增长，一方面其策略数目的增长是不可避免的，过多的防火墙策略会造成防火墙处理性能的下降。另一方面，防火墙策略的冗余无效甚至冲突也是很难避免的，单纯依靠人力去辨别和判断是异常困难的。
以某银行为例，其信息科技部门经常需要做业务变更和对应网络割接，每次针对业务的变更需要做相应防火墙的策略调整。 在原有业务流程下，业务部门需要提交工单到网络部门。很多时候业务部门其实是不清楚防火墙现有策略情况的，另一方面，网络部门收到工单后往往也只是一味的增加策略，新增策略与原有策略的兼容情况其实是很难整理清楚的。因此往往会出现这头网络部门策略增加了，那头业务部门还在投诉业务不通的状况，从而造成割接时间延后、业务上线缓慢。
面对此类问题和需求，我们基于JUNOS PYEZ和算法《Modeling and Management of Firewall Policies》开发了“SRX防火墙策略分析工具”。基于此算法能够对防火墙策略进行地址段分析判断和结果自动提醒（shadowed/redundant/general/correlated）。 为了提升用户使用体验，这块我们玩出了一些“花儿“，把策略信息转到WEB页面来进行展示。
后台采用netconf方式登录防火墙读取所有策略信息，经工具程序运行后将策略及分析结果自动展现在WEB页面，便于维护人员进行策略查看。由于此工具是做成了“外置”式APP，可以让网络维护人员进行现有策略的整理，也可以让业务部门人员进行新增应用策略的模糊匹配和查询，在业务正式上线之前模拟应用策略互通 。当然，根据客户自身需求和流程，可以进一步定制直接由业务部门ADD策略的工具。
以上的案例都是个人基于现有PYEZ内置命令开发的，如果有更为深入的需求可以让开发人员基于JET工具来开发与自身生产业务相关的自动化程序。
注:（1）策略算法参考《Modeling and Management of Firewall Policies》 Ehab S. Al-Shaer and Hazem H. Hamed, DePaul University;
（2）案例三程序由Juniper上海李学平 xpli@juniper.net 开发;
