关注公众号：“DevOps实战派”，获取更多DevOps和运维的精彩内容。
标题是近期在知乎上看到的一个问题，提问者本人从事着运维工作，所在的运维部门这几年也一直都保持着较少的生产事故。但是近期却从公司层面了解到，后面打算减少在运维方面的投入。对此，他感到很委屈。
看了问题下面的回答，发现不少运维的同学也有相关感触，所以我也谈谈自己的看法。
我想起一句关于运维工作的吐槽语，说是如果系统经常出现问题的话 ，老板会觉得系统这么不稳定，那要运维有啥用？而当系统很稳定时，老板也会觉得系统都这么稳定了，那还要运维干啥？
这虽是一句自嘲的话，但也揭示了非业务部门自身的一个难题：需要努力证明存在的意义。
而像运维这类支撑部门，则往往会通过降本的方式来证明自己为公司节省了多少费用。但是，降本自身是把双刃剑，过份降本的后果往往会在某个时间点爆发出来并造成损失，最终演变成“降本增笑”。
对于前面的这个难题，我的建议是做为支撑部门，运维部门不能只是在背后默默无闻的工作，而要更多地让大家关注到，增加自己部门的存在感。
举个简单的例子，比如系统优化、升级、故障处理这些工作，可以在允许范围内尽量让公司的同事和领导知道。这样做的好处是让大家知道系统能持续稳定的原因，是背后有一群人在不断地默默付出，负重前行，而不是理所当然的事情。
同时，技术人要注意对于语言的表达能力，不少人经常不注意这方面的技巧，如总是从自己的角度出发，导致用户不理解。
以平时常见的系统升级通告为例，下面两个关于这个事件的文案，哪个更能突出工作的价值，相信大家看得出来。
文案一
本周五晚上19：00-20：00 运维部门将对 xxx 系统进行升级工作，期间系统无法正常使用，请大家提前安排好工作。如有问题，请联系xxxx。
文案二
运维部门一直专注于提升公司基础架构的安全性和性能，我们计划于本周五晚上19：00-20：00对 xxx 系统进行升级工作。本次升级将带来一些重要的改进和优化，以确保我们的系统更安全、更高效地运行。
升级内容：
安全性增强： 新版本将带来更多的安全功能，提升数据和资源的保护。
性能优化：升级完成后，系统性能将得到提升，加速访问 。
3. Bug 修复 ：本次升级将修复xxx、xxx问题。
升级计划：
。。。。。。。
在不同的企业中，运维工作的重要性也不相同。如对于传统行业的企业，由于企业的主要业务还是在线下，运维团队往往是负责内部系统的支撑。在这种情况下，虽然当系统出现问题时也会影响企业的运作，但对于收入的影响并不好量化。并且，对于企业而言并不会有业务中断这种实实在在的影响，所以重要性相对会比较低。
而在互联网企业中，由于企业自身的业务就是在线上，线上系统的稳定性与公司业绩息息相关，相应地运维部门的重要性也会更高。所以，如果希望有更高的地位，那么选择一个合适的行业也很重要。
另外，除了做好维护工作外，运维团队可以更多往前靠，离业务端更近一些。如通过转型DevOps工程师，构建企业整体的CI/CD流水线，这样可以影响整个软件的开发流程。同时，除了运维能力，也要具备数据运营的能力，利用好数据来提供价值。举个例子，我目前所在的团队有一项工作，就是基于Prometheus的监控数据，开发资源成本报表，给到管理层了解各个项目的成本情况。
当你强大到一定程度后，你甚至还可以对外输出能力，由支撑部门变为业务部门。类似国内的几大云商，就是在基础架构满足内部的需求后，再把这部分能力对外销售。
以上就是我对于这个问题的看法，希望能对大家有所启发。
最后再多说一句，其实每个部门都有每个部门的难处，不能只见到业务部门吃肉，也要看到人家挨的打。归根到底，还是要摆正心态，做好自己才是最重要的。
公众号好文推荐：
760
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
