网络自动化

如何与 NetOps 团队沟通自动化问题

相关内容

Puppet DevOps 状态报告 ›

深入了解将安全集成到软件交付生命周期中的相关数据。

阅读报告 ›


应用服务现状报告 ›

我们邀请了全球 近2,000 位受访者,让他们各自谈谈应用服务在数据化转型中的作用。

阅读报告 ›

一个网络团队当中会有您的同事同行,有时还会有您的好友。他们应对当今技术领域中达成的一项共识有所了解,即自动化将以一种积极的方式改变多数传统 NetOps 工作内容,而您应该成为这场对话的主导者。

有关开发、测试、部署、运营和维护企业应用的决策制定并不能只考虑单一方面。回首过去,网络运营人员的确扮演着掌控大局的角色,每项关键工作的推进均需要获得他们的首肯。坦白来说,多数网络运营人员颇为享受这种工作方式。

不过,今非昔比。一些喜欢自主开展工作的 DevOps 人员正在瓦解 NetOps 人员这种“控制权”,并且这些工作还涉及 NetOps 不愿让他人经手的内容(比如为了新版应用而绕开安全协议,或是为了更新应用而扰乱负载平衡设置)。

从目前的情况来看,DevOps 人员也只是为了让工作更顺利的推进,加强自身的机动性和管理能力,并降低微观管理程度,使得工作的开展更具灵活敏捷性。

然而,就目前的企业环境而言,DevOps 团队如果希望一直保持这种灵活敏捷的工作方式,则离不开 NetOps 团队的协助。单枪匹马,DevOps 终究无法成事,毕竟所有应用均运行于底层基础结构。DevOps 更不能寄希望于让 NetOps 退居幕后,放弃自身长久以来的职责,并且从企业层面而言,这种想法也不切实际。对于 DevOps 团队打造的所有应用,NetOps 团队在维护其安全性和性能方面发挥着重要作用,在 CI/CD 工作流程中,也需要他们贡献自己的技术经验并发挥所长。

自动化是顺利开展工作的利器

如果您是 DevOps 团队的一员,并在试图使 NetOps 同事能够更深入地参与到 CI/CD 工作流程中,首先您需要让他们自发参与其中,让他们意识到改变现状的价值。实现这一点其实非常简单,原因在于自动化可以轻松解决所有琐碎又耗时且须反复处理的常规任务中最底层的工作,所有人都会乐于让机器人接管这类工作任务。

更改订单就是最佳力证。设想下这个场景:您在一堆订单中挑挑拣拣,手动输入每项更改,然后仔细检查是否有纰漏,毕竟这是您今早处理的第九张订单了,它们已经有些难以区分了。此时您会不会对自己当初为何要从事这份工作心生怀疑?难道只是为了日复一日地填写订单变更?其实不然。

您完全可以将这些重复性的冗余工作交给自动化,采用一种更为明智的工作方式,成就一种充满趣味和效率的工作日常。 

据 F5 的应用服务现状报告显示,42% 的企业已经使应用服务部署自动化。

应用会因自动化得到进一步优化

公司的领导让我们来负责这项工作,反正都跟产品有关,没什么区别吧?毕竟没人在乎员工是不是真的喜欢自己的工作,不是吗?这种想法其实大错特错!

尽管如此,让应用具备强大的性能和安全性其实可以为您的工作带来附加益处,减少冗余机械式的工作任务。

自动化的绝妙之处在于,如果首次运行顺利,则这种状态将一直持续,不会出现丝毫差错。

将服务自动化可以令应用更为安全可靠,如此一来,您不但可以有时间用于处理更富意义的低重复频次项目,还可以改善这些服务的质量,因为精心设计的自动化工作流程并不会自发产生,而是需要 NetOps 工程师充分发挥自己的职责,创建各自动化工作流程运行的最佳模型,转而不断重复生成最佳结果。

自动化的绝妙之处在于,如果首次运行顺利,则这种状态将一直持续,不会出现丝毫差错。

采用自动化工作流程,NetOps 团队不仅可以在其专业领域(让应用运行速度更快且更加安全可靠)维持自己的控制权,还可以生成易于使用的自动化进程;DevOps 团队也不再会考虑越俎代庖(同样是为了让应用运行速度更快且更加安全可靠)。

合作才能使自动化蓬勃发展

无论是 DevOps 还是 NetOps 团队,往往都无法凭借一己之力确定维护企业关键应用和数据相关的所有解决方案;若要达成这一目标,势必需要两个团队携手合作。借助当前的自动化功能,可以大幅减少团队沟通互动期间产生的矛盾和摩擦。

在 DevOps、NetOps、SecOps 等团队中,运维绝不是团队内部工作。在现代的 CI/CD工作流程中,成功与否取决于是否制定有明确定义且经过验证的方法,可以在整个复杂系统中快速便捷(即自动化)复制。若要为这些自动化工作流程奠定坚实的基础,就需要 DevOps、NetOps 与 SecOps 团队间建立一种稳固的合作关系,形成一种互帮互助、各自发挥所长的工作氛围。

无论应用运行于哪种环境(云、容器等),均离不开底层应用服务、网络服务和安全服务。NetOps 团队可以负责数据在网络中传输的持续性,确保应用能够实现扩展和快速响应,并在需要时保证数据的可用性,让数据一直处于安全状态。每个运维团队则负责有关风险缓解的工作,无论风险是应用无法正常运行、网络压力过大或是资产受到外部威胁攻击等。根据 Puppet 发布的“2019 年 DevOps 现状报告”,有一点值得关注:推动软件开发取得良好成果的 DevOps 原则“素养、自动化、测量和共享”与推动良好安全成果的原则如出一辙。

两种不同的运维团队间需要频繁的进行此类沟通互动。进入互联网时代以来,IT 一直以这种方式运行,但金无赤足,比如出现敏捷软件开发流程时,使得应用开发和部署达到了前所未有的速度。DevOps 也是在当时发生了翻天覆地的变化,逐步迈向敏捷开发之路,采用一种更快速的方式“将代码交付客户”。

速度的提升驱动了这场 DevOps 变革,让 DevOps 呈现出今日这般发展。这场变革带来的结果好坏参半,好的一面是 DevOps 团队由此变得更为高效,掌握了更多的主动权;而坏的一面则是如果其他部门的流程设置并未采用同样的方式,就会引发矛盾分歧。

轻易忽略这些其他部门或是放弃那些还未跟上节奏,采用新方式处理工作的同事并非明智之举。如果 DevOps 团队试图单枪匹马完成工作,必将导致效率低下且不如预期的成果。进程也会因此出现中断(无论是否出于无心),而中断的进程就会引发一连串的故障。其中不仅会牵扯到 DevOps 团队本身,还会波及方方面面,包括您的客户;而客户却是您最不愿意惊动的对象。

对于 DevOps 团队而言,如果希望工作顺利开展,则需与 NetOps 团队站在同一战线而非对立面。而对于所有的稳固合作关系而言,沟通互动一直处于核心地位;因此 DevOps 团队需要与网络团队多加沟通,了解如何获得支持应用所需的服务。

DevOps 团队通常擅长自动化、整体框架和基础结构即代码等领域;而网络团队则是了解需要调配哪些实际架构资源和相应调配工具的专家。借助一种开诚布公且彼此尊重的工作方式,DevOps 和 NetOps 团队一定可以确定需要自动化的环节以及如何以最优方式部署自动化。

DevOps 团队不会因此受到任何影响,相反还会通过帮助 NetOps 同行在整个 CI/CD 工作流程中强化自动化的运用而受益匪浅。最为关键的一点是,您要认识到您自己可能是开发代码领域的专家,您的某位或某几位同事可能是设置网络和安全服务的行家,请把握每一次契机,帮助彼此在各自的领域中不断精进,成为行业中的佼佼者。