背景

当运维深陷困境，该固步自封 or  破旧立新？让我们先来看下小伙伴们遇到的几种境遇：

❝

1. 投产变更，流程流于形式
2. 投产步骤特别复杂，几百套系统几百种投产方式，公司的测试环境流于形式，经常会有投产文档和真实操作不一致的情况
3. 几百套系统，几十种操作系统，几十种数据库，没有人推动统一化，标准化
4. 安全管控不到位
5. 上层从管理视角来看待问题

❞

对于问题作为运维从来是认真的，来看下来自四面八方的建言献策：

• 基础架构情况好难啊，标准化程度低，做什么运维工具特别是自动化都「事倍功半」；
• 标准化流程得依靠系统，在系统上体现，比如你要变更 在系统提交，有评审审批；
• 管理混乱，标准化混乱，但是单靠运维来推不行的；；
• 监管形势：“金融行业强监管态势持续，监管部门日前表示，将紧绷全面加强金融监管之弦，坚决做到“长牙带刺”，对重大违法违规问题坚决零容忍”；
• 没有第一条直接导致了后面的2345条；
• 归根到底还是标准化做的不够；
• 先把变更做好就行了，cmdb先不用考虑，自动化也不用考虑；
• 按这情况，变更流程大概率也推不动；
• 每家公司都有他的槽点，维持现状就好了；
• 你就按照领导要求，尽量做到一天巡检完所有系统就行了，往这个目标靠近，听大哥的没错；
• 应用运维干好自己的活，执行好变更脚本，遵守好变更制度就行；
• 谁提问题谁解决，这是给自己戴紧箍咒；

预则立，不预则废

其实提出问题很简单，但解决问题才难！当我们提出问题的时候，是否也做好了解决问题的思想准备？从大家的建言献策中，我们先找几个关键词：

• 运维自动化
• 标准化流程
• CMDB
• 运维巡检
• 规范制度
• 行业规则

看着这些关键词，脑海中突然有一个疑问：“妈呀！这是运维自己一人就能完成的？”，既然涉及到跨部门、跨行业、跨级别的事情，我们应该首先弄清楚“边界”，做自己力所能及的工作、顺势而为。

当然，还需要明白的一点是，以上对运维如此有价值的事情，为什么就是没人做呢？因为投入时间长、见效时间慢，立竿见影是不存在的。没有个1~2年时间的脚踏实地、悉心梳理以及团队的上下齐利，是不可能有这条运维康庄大道的。况且2年对于运维职业生涯也是一个窗口期，做的顺心才可能更长情的投入，如果不顺心的话就可能另谋高就了。

“预则立，不预则废”，强调的就是不打无准备之仗，不要以为“狭路相逢勇者胜”考验的只有魄力，其实还有功夫在平日的持之以恒！

破则立，从则平

如果你不知道“边界”从何做起的话，我觉着以下这条自媒体新闻可能会对你有帮助。

❝

《字节跳动基础架构SRE-Copilot获得2023 CCF国际AIOps挑战赛冠军》，基于大语言模型运维场景：

• 运维计划：解析用户运维需求，生成自然语言的工作流，并从系统可调用的组件中选择合适组件，动态生成可执行的工作流；
• 运维可视化：通过自然语言交互，自动执行简易的数据查询/分析，对故障数据进行可视化；
• 异常检测：支持多模态数据类型，灵活拓展，通过多Agent协同编排，整合不同平台数据，极大缩短MTTR；
• 根因定位：无监督，支持专家经验、历史故障输入，对已知故障准确率高，对于未知故障可推理；
• 故障分类：根据专家经验和历史故障所属类别，以及本次故障表现，对故障进行分类，有助于后续按组织或改进措施推进复盘与优化；
• 故障自愈：在推理得到故障根因和故障分类后，可以推荐合适的自愈措施，流程自动化，让运维人员集中精力，无需频繁切换上下文，确保响应和处理的及时性和准确性；
• 代码生成：基于用户的提示生成代码，将复杂脚本的调试开发时间从几小时缩短到几分钟；
• 故障报告：利用LLM自动生成故障诊断报告，以自然语言方式表述5W问题：When-Where-Who-What-Why，显著提升故障诊断报告的效率与质量，方便团队积累经验和知识库；
• 知识库问答：基于本地知识库进行私域知识问答，提升应答准确率，减少Oncall系统人力投入；

❞

大语言模型现在可谓是如沐春风，相信基于大语言模型的运维场景肯定要比资深的运维专家更有说服力，因此运维的边界也就呼之欲出。

• 首先，我们不求以上几方面做的多么全面与完美，但它是一定能为现状所服务的，这样才会有驱动力。
• 其次，由于运维的开发精力实在有限，基于场景的成熟解决方案也很多，因此要懂得如何取舍，自研+外采要量力而行。
• 最后，一定要做好资产管理+监控+配置管理的基本盘，做好“咬定青山不放松”的思想准备，以不变应万变。

总结

当运维深陷困境，该固步自封 or  破旧立新？这不仅要取决于当前企业管理文化，还取决于团队，但无论如何运维知道方向可能比知道如何去做更重要！