如何與NetOps 團隊溝通自動化問題
一個網路團隊當中會有您的同事同行，有時還會有您的好友。他們應對當今技術領域中達成的一項共識有所了解，即自動化將以一種積極的方式改變多數傳統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 團隊可以負責數據在網路中傳輸的持續性，確保應用能夠實現擴展和快速響應，並在需要時保證數據的可用性，讓數據一直處於安全狀態。每個運維團隊則負責有關風險緩解的工作，無論風險是應用無法正常運行、網絡壓力過大或是資產受到外部威脅攻擊等。根據兩種不同的運維團隊間需要頻繁的進行此類溝通互動。進入互聯網時代以來，IT 一直以這種方式運行，但金無赤足，比如出現敏捷軟件開發流程時，使得應用開發和部署達到了前所未有的速度。DevOps 也是在當時發生了翻天覆地的變化，逐步邁向敏捷開發之路，採用一種更快速的方式“將代碼交付客戶”。
速度的提升驅動了這場DevOps 變革，讓DevOps 呈現出今日這般發展。這場變革帶來的結果好壞參半，好的一面是DevOps 團隊由此變得更為高效，掌握了更多的主動權；而壞的一面則是如果其他部門的流程設置並未採用同樣的方式，就會引發矛盾分歧。
輕易忽略這些其他部門或是放棄那些還未跟上節奏，採用新方式處理工作的同事並非明智之舉。如果DevOps 團隊試圖單槍匹馬完成工作，必將導致效率低下且不如預期的成果。進程也會因此出現中斷（無論是否出於無心），而中斷的進程就會引發一連串的故障。其中不僅會牽扯到DevOps 團隊本身，還會波及方方面面，包括您的客戶；而客戶卻是您最不願意驚動的對象。
對於DevOps 團隊而言，如果希望工作順利開展，則需與NetOps 團隊站在同一戰線而非對立面。而對於所有的穩固合作關係而言，溝通互動一直處於核心地位；因此DevOps 團隊需要與網絡團隊多加溝通，了解如何獲得支持應用所需的服務。
DevOps 團隊通常擅長自動化、整體框架和基礎結構即代碼等領域；而網絡團隊則是了解需要調配哪些實際架構資源和相應調配工具的專家。借助一種開誠佈公且彼此尊重的工作方式，DevOps 和NetOps 團隊一定可以確定
DevOps 團隊不會因此受到任何影響，相反還會通過幫助NetOps 同行在整個CI/CD 工作流程中強化自動化的運用而受益匪淺。最為關鍵的一點是，您要認識到您自己可能是開發代碼領域的專家，您的某位或某幾位同事可能是設置網路和安全服務的行家，請把握每一次契機，幫助彼此在各自的領域中不斷精進，成為行業中的佼佼者。
