上週五馬馳和來煒關於“運維崗位真的不能幹了麼？”的話題，老師們給了終結：

❝

現在這個階段，平臺體系還沒有那麼完備，使用自助Platform+COE+BP（Business Partner）的架構來搭建運維體系看起來是靠譜可落地的。未來Platform足夠好的的時候，可以縮減BP人力（BP也慢慢具備了COE的能力），Platform繼續完備，可以繼續縮減COE，再之後，嗯，運維和研發可能就都不需要了吧。

❞

其中有幾個概念我們需要搞清楚：

• 自助Platform，由企業不同團隊根據自身業務需求搭建的功能性平臺；
• COE領域專家，不同的平臺團隊需要相應的領域專家來進行指導，來應用最佳實踐；
• BP業務夥伴，專業的外部供應商，通常提供更專業的SaaS服務，為平臺或公司賦能；

沒想到”自助Platform+COE+BP（Business Partner）“這個看似簡潔的結論卻一下子將我敲醒，此時“運維崗位真的不能幹了”才下眉頭，而”如何成為COE領域專家“的想法卻上心頭。為什麼會有這個想法呢？可以將”自助Platform+COE+BP（Business Partner）“的理念結合企業監控平臺建設來分析下。

自助Platform

相信有點技術的企業一般都會選擇自建監控平臺，可使用的主流開源方案有：

• Zabbix
• Prometheus
• ELKStack
• Open-Falcon
• 夜鶯
• Grafana
• 等等

透過以上工具的結合使用，基本上可以實現多維度+圖形化的監控，如：

• 硬體級別監控
• 作業系統級監控
• 中介軟體級監控
• 資料庫級監控
• 鏈路追蹤級監控
• 容器級監控
• 日誌級監控
• 業務流程級監控
• 安全級監控
• 等等

但是由於存在多種監控工具，產生資料孤島的情況就無法避免，這是自助Platform的一個痛點。除非團隊中有一個COE領域專家，能夠知道開源方案的痛點，並帶領大家跨越這個鴻溝，向指標、日誌和分散式追蹤的可觀測性建設邁進，更好的為系統容量評估提供資料分析。

COE領域專家

多維度的監控覆蓋的範圍比較廣，涉及的領域及相關崗位有：

• 基礎運維：IDC基礎設施，物理機、網路裝置、安全裝置、儲存裝置等；
• 應用運維：應用系統，SpringCloud、健康檢查、ELKStack、Skywalking等；
• 中介軟體運維：中介軟體，ZK、Redis、Kafka、Rabbitmq、Rocketmq等；
• 資料庫運維：關係/非關係型/時序型資料庫，Oracle、MySQL、MongoDB、InfluxDB等；
• 容器運維：雲原生系統，Pod、Deployment、PV/PVC、SVC等；
• 業務運維：各業務條線流程；
• 安全運維：站點流量、滲透、高防CDN、全流量等；

綜上，多維度監控的覆蓋範圍和精確度離不開各個COE領域專家的指導與交流。但人的精力是有限的，團隊要想做好各自領域的監控，也是要付出一定的努力的。

SaaS

相較於BP（Business Partner），我更希望將此部分為SaaS，畢竟外部廠商提供的專業化的服務才是我們處理痛點的解藥。雖然我們透過自助Platform+COE領域專家，在一定程度上解決了業務連續性問題，保障了業務系統的SLA。但是我們仍不可避免的會遇到以下的某個問題：

• 監控平臺的多資料來源形成的資料孤島；
• 網路抖動、叢集異常產生的多資料來源告警氾濫；
• 缺少對歷史告警資料的根因分析，以形成更好的故障自愈方案；
• 透過告警如何更精準的定位故障，進一步減少MTTR時間；

當我們無法做到十全十美，但是我們可以藉助外部廠商的能力來幫助我們將平臺建設的盡善盡美。專業化的SaaS服務能給我們更好的賦能，讓雙方的都能實現最終的雙贏。

運維的發力點

經過以上對監控平臺建設過程的分析，我們可能會對”自助Platform+COE+BP（Business Partner）“的思想有了進一步的理解，那麼運維的發力點在哪？

1. 如果你初入職場，你可以透過監控平臺的建設來構建自己的知識體系；
2. 如果你是職場中生代，你可以結合監控來深耕某個或多個領域，畢竟監控面向的就是各個維度的痛點；
3. 如果你是職場老鳥，你可以結合監控去建立一套自動化運維體系，以便和監控對接更好的實現故障資源，這也意味你們的自動化能力將達到L3-高階（全自動化），是一種自我價值的體現；

當走過監控平臺建設之路後，回首望去，作為運維我們可能已經具備了”知識體系+解決方案+自我價值“的COE領域專家的能力，這不僅是一份自信，更是一份能讓你從被淘汰大軍中的分母走向不可替代的分子中的真實實力。