1.3 网络运维自动化实践之路在网络运维自动化工具体系的状况得到明确以后, 网络工程师就能够开始进行网络运维自动化有关知识的学习工作, 同时还会把这些所学习到的内容带到具体的操作当中去加以应用, 在进行实际操作期间的过程当中, 网络工程师还需要按照特定的方式来处理相关的各项任务, 以此来实现用较少的精力获取更大成果的目标。1.3.1 循序渐进地学习与实践在进行网络运维自动化的学习和实践的时候, 一定要遵循循序渐进这一原则, 切记不可急功近利。在阅读的阶段当中, 读者朋友需要把这本书里面的相关内容, 按照从头到尾的顺序去进行非常仔细的阅读动作。这份书的内容, 实际上就是作者经过十年的时间所积累起来的实战方面的经验总结。同时, 这些内容里还凝结了大量的价值, 这部分价值来源于作者在解决来自于不同行业领域中的网络工程师们所提出的那些问题时所收获的宝贵经验。在进入实践阶段的时候, 必须要把脚本好好地测试一遍, 然后再将其应用到实际的网络运维生产活动里面去。特别是涉及到对网络设备进行的配置修改这项事情, 更应当先在测试环境或者是模拟器环境中进行充分的测试, 确定没有问题之后, 才可以把它投入到生产环境里去进行操作。许多讲关于网络运维自动化知识以及做相关分享的内容文章, 都会把大量的篇幅和笔墨耗费在配置下发这个具体的环节上, 然而实际上来说, 这正是一个风险非常高的重要环节啊。刚开始接触网络运维自动生成化的新手人员对那些技术工具的具体细节了解得不够透彻, 对其中存在的安全性问题的警觉性也还不够高, 这种情况必然会导致整体风险水平上升。所以作者觉得在这个阶段里, 相关的技术人员最好把注意力放在配置数据的整理以及信息的收集工作上, 主要原因在于这一做法具备更高的投资回报率且发生负面事件的概率更小。在这个过程中, 大家先可以做配置文本的收集这件事, 去执行相关的命令, 然后把这些命令的回显内容写进以一定格式命名的文本文件里面, 再借助正则表达式去做结构化数据的提取和保存, 一步一步地去培养自己的数据意识。通过这种进行数据收集的方式, 网络工程师的网络运维自动化水平也会一点点地提高起来。随着网络运维自动化水平的不断提高, 网络工程师可以尝试使用YAML格式或者表格数据类型, 并且结合模板来生成符合规范的标准化配置内容。这些配置在最初阶段可以选择依靠人工的方式进行推送操作。随后随着在网络配置变更这一块业务的逐渐成熟与稳定情况出现, 再加上工程师自身技术开发能力持续得到增强, 网络工程师就可以尝试把部分高频发生且风险较低的配置任务通过自动化流程来进行下发工作。在以后的实践过程当中, 网络工程师还能够去借助那个工具或者是技术手段, 再把自动化脚本给进一步地整合起来, 以此来建立起属于自己的那种网络运维管理方面的一个工具体系, 这样的话呢, 就可以把网络运维这个工作领域的自动化水平也给提升上去。1.3.2 有意识地培养数据意识在网络自动化运维这一领域里面, 不同的平台、不同的程序以及不同的脚本彼此之间要进行通信的话, 那么就必须用到规定的数据格式, 这就等于是要把结构化的数据按照指定的那种数据格式, 去在网络或者是本地的文件之中进行传输, 而结构化的数据需要用户对网络运维场景里面所涉及的那些对象进行抽象化的操作。抽象化的这个流程, 说白了就是去做建模这件事儿, 这意思就是你得为那些正在被维护的对象, 或者说是具体的运维场景, 专门去造出一个模型来, 然后你再用那种格式特别整齐、结构特别清楚的数据, 去把那个运维对象或者那个运维场景给描述清楚才行, 在用户开始搞事儿之前, 他首先得用上各种各样的法子, 从网络设备那边拿过来的相关配置文本里, 把那些结构化的数据给提炼出来, 再把它们映射到刚刚说的那个模型上面去, 最后再去做一些相关的处理操作。对于刚入门的新手而言, 这个模型可能并不具备明确的定义界限, 它往往是按照习惯来确定的, 比如可以试着运用各种不同的基础数据去描述网络设备、网络配置项以及网络运维场景这些内容, 但随着在网络运维自动化领域不断地学习和实践, 网络工程师必须要把这个模型用规范化的方式描述出来, 例如可以用类的方式去定义网络模型, 或者利用网络的建模语言也就是YANG来定义模型, 又或者干脆就直接采用现成的网络模型。在当今, 数字化转型的时代来了结构化的数据这回事儿, 它是一笔非常宝贵的财富, 在网络运维里, 发挥着重要的作用。网络的数据模型它不仅能够描述网络这个事儿, 同时, 它还经常被用来去驱动网络的配置变化这件事儿的发生。网络工程师现在还可以使用结构化的数据来描述网络的配置情况, 这种做发是让运维人员把他们的注意力集中在对网络配置参数进行的调整工作上面, 让他们不用去直接接触那些原始的、比较混乱的配置文本材料, 通过这样的一种方式, 能够切实有效地提高整个网络环境的确定性水平, 并且能够显著地减少那些因为人工在进行操作时出现失误而引起的网络连续性被中断的情况发生。在涉及网络运维活动的无数个环节过程之中, 每一位网络工程师必须都要尝试着去有意地、刻意地去培养一种关于数据的意识状态, 从而能够真正地去使用数据所拥有的那个特定视角, 来对待和观察网络运维这一整体工作。1.3.3 以场景为导向的实践落地网络运维方面存在的难点, 全部是依据运维场景来定的, 所以归根结底, 要把网络运维自动化真正落到日常运维的场景中去, 而且要以解决实际工作中遇到的困境为方向。在工作的时候, 网络工程师第一件事情是要把手头的工作整理清楚, 要明白哪些场合具备那种机械式重复的特征, 接着就要把这些场合下的工作安排给自动化程序去处理。网络工程师还需要主动地去锻炼自己的“自动化意识”, 在日常工作之中要时常问自己这两个问题: 第一, 眼前的这种场景, 究竟能不能够被实现自动化操作? 第二, 如果要让当前的场景跑在自动化的流程上面, 具体该采用怎样的方式来落地实施呢?这一套主动发出的自我质问手段, 可以帮助网络工程师有效提高自身对运维场景中哪些环节值得自动化的整体识别能力以及掌控力, 从而把有限的资源尽量多地倾斜到真正的运维实务上面去, 通过技术手段解决真实的痛点问题, 而绝不是把力气花在实现那些看起来光鲜亮丽但实际上没有多大实际用处的功能需求上面。作为网络运维工作人员, 他们在把精力投放到关于网络运维自动化领域之中的时间状况是属于有限的这种性质存在的, 我们方面必须是要以最大程度的努力水平去把这些宝贵的时间段给充分利用好, 以此来达到能够产生出巨大作用力效果的目标。在开发的过程当中, 网络工程师也要把精力集中到那个场景的实现上面去, 不要在那些技术细节上花费过多的时间。这还是关于一个时间成本的问题。我们究竟应该花费更多的时间, 去把一个场景里面的某一个技术细节进行优化呢? 还是在时间成本和功能效果相对保持平衡的前提之下, 去实现更多比较有用的场景?不用怀疑了, 后面那种情况就是我们一直在追求的一个方向。在网络运维自动化刚刚起步的那个时候, 网络工程师的开发本事其实不是特别高, 所以暂时还没办法去实现那种比较好的批量自动化操作。在这个时候, 大家可以使用那些比较简单的循环逻辑, 再加上轮询设备这些手段, 来完成自动化操作, 这样的话, 就可以先实现功能需求, 然后再去解决某一个具体场景下面的运维难题。等到了技术水平慢慢精进以后的阶段, 网络工程师就可以使用一些并发技术, 或者是网络运维自动化框架之类的东西, 来进一步优化程序代码了。要是我们在起初就把过多的时间和精力花在了并发技术的学习以及使用上面, 那肯定会阻碍场景需求的落地工作, 若是长期去关注那些技术细节的话, 就没法及时把有效的工具给输出来, 这样一来就会导致场景里的难题没法得到解决, 这种情况同时也可能影响我们去开展网络运维自动化工作的信心。在网络运维自动化这块儿的学习还有实践的整个过程里面, 咱们的程序代码非得把具体的场景当作是主要的导向来搞不可, 只有这么办了, 才可以让网络运维自动化的学习与实践顺顺当当、稳稳当当地推进下去。