编者著：井老板是我11年入行加入百度时的团队大老板，骨灰级老炮，逮着这个机会不容易，把业内常见问题都问了个遍，以飨读者。井老板生性洒脱，嬉笑怒骂皆成文章，道理自在其中。这里是接地气、有高度的《运维百家讲坛》第 1 期，开讲！
嘉宾介绍
井源，左一，前百度运维架构师，前小米运维负责人，前美菜CIO
有些运维人员反映公司对运维的价值所知甚少，您当年是怎么给公司讲清楚运维的价值的呢？
首先需要和公司讲清楚运维的岗位职责（运维是干什么、产出什么）和关键指标（度量产出成果），比如工作围绕稳定、安全、高效等方向展开，开展了哪些运维项目，如何主动推进关键指标的达成。
关键指标，不仅仅包含服务可用性，还有比如服务器资源达标率、服务故障数据（故障分类、故障响应时间、平均故障恢复时间、故障告警覆盖率）、服务安全指标、服务资源到位时长等等。
比如搭建一套完善的监控系统：
监控服务器资源使用率，找出使用率不达标的服务器进行回收或资源重新分配，通过虚拟化、容器化等手段提升资源使用率梳理告警阈值，规范P0、P1、P2、P3告警级别；监控系统提供告警合并、智能定位建议，提供活跃告警聚合，提供时间纬度的告警分析。方便更快的告警响应和故障定位，提升故障响应时间、故障恢复时间等服务的告警和预案梳理，缩短平均故障恢复时间，提升故障告警覆盖率
业内有观点认为云和Kubernetes这样的基础设施的崛起会让运维岗位逐渐消亡，您是怎么看待这样的观点呢？
很多年前我们运维团队的口号是NO Ops，博客是noops.me。
很早就说过，运维岗位会逐渐消亡，或者部分工作职责会消亡。拿系统运维来举例，以前管理的团队需要服务器工程师、内核工程师、网络工程师、CDN工程师、机房运维工程师等小20人的团队。后来通过引入公有云，团队只有4个人，云资源管理员1人、CDN调度工程师1人、网络工程师1人、内核工程师1人，他们只需要管理和调度好第三方公司提供的资源和服务即可。
随着K8s和云的普及，以及研发代码工程化的不断成熟，运维在这个过程中的参与度会越来越少。在部署框架成熟的情况下，为了节省运维人力，提升部署效率，二、三级服务的部署已经交给研发自助完成。
随着科技的发展，时代的变化，一个岗位的消亡是很正常的事情，及时做好调整和规划才是思考的重心。
在企业大范围上云的当下大环境里，您觉得运维人员应该做出哪些调整才能更适合当下的人才需求？
在上云的大环境下，运维工程师更应该面向业务、面向架构，拓展自己的业务范围，成为保障业务稳定的关键人才。如果还是和以前一样，仅仅只关注监控报警，只负责服务部署变更，那么势必会被淘汰。
另一方面，可以往专精的方向走，成为某个领域的专家（监控、大数据、K8s、数据库等等），走运维研发专家的方向。
人生的建议，多寻找一些副业，运维工作只是生活的一小部分。
AIOps热炒了几年，但是最近明显声量变小了，您觉得企业现阶段应该落地AIOps么？应该注意哪些问题？
就拿智能监控为例，看到了很多文案说要通过AI预测故障、智能定位。到现在没有看到任何靠谱的案例。在一个服务变更快、依赖关系复杂、故障影响因素多的互联网业务系统中，如果真能通过历史数据，实现故障预测。那还不如去做地震预测，有几千年的地震数据积累，能够产生很大的社会价值。
做AIOps的前提，是真的懂AI，清楚机器学习和神经网络的原理。有多少人工才有多少智能，AIOps才能不是一个口号。
chatGPT这样的AI能力您觉得未来是否有可能解决运维行业的问题？
比如在故障管理中，根据故障的设备、数据、描述，通过知识库、历史故障库等等，给出故障可能的辅助建议(suggestbot)
BTW，如果你已经可以玩转chatGPT了，把这个技术投入到其他更能产生价值的领域吧，别老在运维这个领域耗着……
業務程序的部署，到底該交給研發來做還是應該交給維運來做，在很多公司爭論不休，您是怎麼看待這個問題呢？
之前提到過，我們二、三級的服務是完全由研發去做，一級服務是運維和研發輪流去做，主要目的主要是讓運維清楚當前服務的變化情況而已。維運人員在公司一開始做部署，更多是規範線上環境，規範服務部署方式，進而更好的研發部署系統，掌控所負責的服務架構。
安全性問題、流程問題，完全可以透過部署系統去解決。運維就不要守著這個沒任何價值，沒任何沉澱的工作不放了。
您最想對（維運）產業說的一句話是？為什麼？
「物理學沒有不存在，只是我們認為的物理學，可能不存在。」維運產業可能也不存在了，多少維人的夢想是AIOps、NOOps，要嘛自己去幹掉這個行業，要嘛在這個行業被幹掉。
工具選型這塊，到底是自研，還是使用開源，還是使用商業產品，是如何抉擇的？
有能力有時間就使用開源，能力一般時間有限就使用商業產品。有錢有閒還很自負的話，可以嘗試下自研。
您所在的公司也是多雲架構？您覺得多雲場景下哪些能力應該依托雲廠商哪些能力該自建？
我們是多雲架構。專線或資料傳輸的能力，這個需要自建。基於多雲之上的公共能力也可以自建，例如監控系統、資料備份系統、部署系統、微服務核心組件等，其他的交給雲端廠商就好了。
您印象最深刻的一次故障是什麼？對您有何啟示？
維運這麼多年，遇到的詭異故障太多了，root cause讓你根本想像不到。只能說，故障很難避免，只能設法減少故障的頻率、影響面和影響時間。
所以你的績效不是故障次數和故障級別，而是故障影響面、故障回應、恢復時間等。
面對當下快速發展的基礎技術，您對給剛入行和入行已久的維運人員，分別有什麼職涯規劃的建議嗎？
比較偏激哈~剛入行的，建議盡快轉行！入行已久的，轉行技術相對困難，已經打上了深深的運維烙印。我看過太多維運人員轉行其他技術，多數都是維運研發、維運產品經理的崗位，還是找一下副業吧。
您覺得傳統維運和SRE的差別是什麼？您的團隊做出這樣的轉型，背後的思考是？
這都2023年了，聊這個話題就跟網路運維弄個NOC監控值班一樣，開倒車。
如果現在還在考慮要不要轉型SRE、怎麼轉型SRE、SRE的變化這些問題，就跟5g時代，還在考慮用2g，還是3g……都會被時代所淘汰。
是否有種戛然而止的感覺？哈哈，這是《維運百家講壇》第1期，我們會持續邀請業內大佬前來分享，越是有不同的觀點才越有意思，越是能夠引發思考，咱們一起，抱著開放的心態，聆聽百家之言。下一期，再見！
以上是井源：運維幾何的詳細內容。更多資訊請關注PHP中文網其他相關文章！
