这篇文章想跟大家聊一聊运维工程师如何去体现运维工作的价值，或者说运维的绩效能够从哪些方面进行思考。
前几天在一个技术探讨群里，一位兄弟发动了一个话题：运维要怎么更好地展现本人的业绩，让绩效更好看？🤔
这个话题引发了一番探讨，在这里，我想依据探讨的内容以及本人的想法进行总结，分享一下运维工作能够从哪些方面寻找亮点。🔍
与泛滥互联网相干岗位相比，运维的工作内容堪称是多又杂，还难以被人关注到，往往只有在零碎呈现问题的时候，运维才有可能被人关注到。但运维的首要任务，不就是保障系统的稳定性，让零碎继续可用嘛，天然不可能为了失去关注而盼着零碎出故障，零碎总是呈现故障也会让别人质疑运维工程师的能力。
那么，运维该如何从日常工作中寻找有价值的工作，以此来体现运维的外围能力呢？我感觉能够从以下几个各方面思考。
一、公司倒退策略
每个公司在不同的倒退阶段，都会有不同的倒退策略和指标，而公司里的业务，无论外围与否，都或多或少跟公司的倒退指标相干。
运维是一门技术活，很多干技术的，都会给人一种印象就是埋头苦干，两耳不闻窗外事。但我感觉运维相比之下，具备更强的灵活性，每一个运维人员都应该具备 owner 意识，而不是只会看需要和工单做事。
作为运维人员，应该多理解公司的倒退策略和指标，并思考本身的运维工作有什么中央能够贴合公司的布局。
举个理论的例子，咱们晓得，以前公司开发了一个利用或者网站之后，就会购买一批服务器来部署网站对外提供服务，但这种形式的毛病在于扩展性差、资源利用率低、老本高。所以起初，规模较大的公司就会自建云资源池，而小公司则会向阿里云、腾讯云这样的云服务提供商购买云主机来部署利用，以此来进步资源利用率，降低成本。
假如公司将来的趋势就是应用云资源池，那么，作为运维人员，就能够及早提出将本人保护的利用往资源池迁徙，这不就是一项运维工作的绩效所在吗？
二、零碎稳定性晋升
所谓零碎稳定性，指的是零碎在外界环境变动的状况下是否放弃零碎的稳固和继续可用。晋升零碎的稳定性，不是说谋求零碎不要呈现问题或故障，要晓得，没有一个零碎是不出问题的。
那么，在零碎稳定性晋升方面，咱们能够做什么呢？
制订可用性指标
可用性指标应该大家平时听得比拟多，也就是咱们平时常说的 4 个 9、5 个 9，即服务可用时长占比。运维应该给本人所保护的零碎定一个可用性指标，之后运维所做的大部分工作都是为了去实现这个指标。
制订标准
标准文档能够对开发、测试、运维的工作起到束缚作用，通知相干人员什么该做、什么倡议做、什么要防止做，这样能够避免出现一些常见谬误，以此来升高零碎出问题的概率，晋升零碎的稳定性。
运维能够依据以后的工作环境、技术体系、历史教训，去扫视整个软件生命周期中每个阶段，是否有一些能够预知的问题，并将此制订成各类工作标准，包含：上线标准、测试标准、编码标准、数据库应用标准、各类中间件应用标准、我的项目构造标准等等。
高可用性晋升
这点是最重要的，后面提到，没有一个零碎是永远不会出问题的，所以作为运维，就要去思考，当零碎呈现问题的时候，零碎要怎么应答，不同的问题，应答措施是不同的，但至多要保障，外围服务的高可用。
高可用要求服务节点不是单点的，并且在繁多节点不可用时，可及时切换到可用节点。
高可用大抵能够分为以下级别：
1、单机房高可用
利用部署在一个机房内，应该保障外围服务是多节点的，能够是主备（冷备、热备）、主从、集群等，目标是为了应答服务单点危险，当服务主节点不可用时，能够迅速切换到备用节点，从而缩小服务不可用的时长。
2、同城双活
尽管在单机房中实现了高可用，但如果整个机房不可用，又该如何保障业务的连续性呢？常见的做法是同城双活，在同一个城市的两个机房里部署同一套应用程序，并通过高速专线实现双核心数据的近实时同步。
3、异地容灾
如果你感觉一个城市两个机房还是不保险，可能会呈现大面积停电的状况，那么就能够在不同城市建设容灾核心。
因为两个城市相隔较远，不可能像同城双活一样做到近实时的数据同步，所以容灾核心平时是用不到的，只有在主核心故障时，才会切换容灾核心，并且在切换容灾核心的时候，可能会呈现局部数据失落。
4、两地三核心
因为异地容灾的数据同步提早会比拟大，所以个别会采纳两地三核心的架构计划。
两地三核心指的是同城双活 + 异地灾备核心，同城双活能够实现底层数据的近实时同步和双活，而异地灾备核心能够在同城双核心同时故障时利用备份数据进行业务复原。
对于高可用架构的建设计划，将来能够通过专门的文章进行分享，这里就不开展细讲了。
架构优化
除了以上提到的形式，运维还能够主导零碎架构优化，比方，零碎是否有超时和重试机制？是否有熔断伎俩？是否有备份机制？这些也是晋升零碎稳定性的罕用伎俩。
应急 / 切换演练
当零碎有了高可用伎俩之后，还应该定期通过应急演练和切换演练来验证高可用伎俩的有效性。
此外，还能够思考引入混沌演练，对系统进行危险点检测，进而推动系统优化。
三、性能晋升
运维能够对系统的各个环节、各个局部进行性能评估，并推动开发、DBA 等相干共事进行优化，以此来晋升零碎的整体性能。
构想一下，咱们关上一个网页，如果这个网页要加载 1 分钟能力加载完，你还会等上来吗？
所以，零碎的解决性能越高，能够给使用者带来更好的用户体验。
四、现网问题危险预警和疾速解决
运维还能够思考如何提前预警系统危险以及如何疾速解决现网问题。
预警系统危险，须要运维被动联结研发、产品的共事欠缺监控体系、丰盛监控告警指标，并对历史监控数据进行长久化存储和统计分析。
而要疾速解决现网问题，要求运维对排障工具的纯熟应用。那么，是否能够思考，对历史呈现过的故障进行整顿，输入故障解决手册。还有是不是能够思考，依据零碎理论状况，输入罕用排障工具的使用手册，防止每个人应用工具的形式不一。
五、降本增效
我始终感觉，运维工作的翻新和亮点大多数体现在降本增效上。运维应该多去思考，日常工作中有什么中央能够提高效率和降低成本的。
上面列几点这方面的一些做法：
进步资源使用率
在软件生命周期中，软件的运行保护是继续最长的一个阶段，而软件一旦上线，产生的最间接的老本就是服务器。在零碎刚上线的时候，须要购买服务器来部署零碎利用，而在零碎继续运行的过程中，服务器也会继续产生电费等各种老本，并且服务器还须要定期替换。
服务器应用的越多，产生的老本越高。然而在大多数理论状况下，服务器本身的 CPU、内存等资源的使用率可能并不高。
所以，运维须要思考，如何进步资源的使用率，进而缩小服务器数量，升高服务器所带来的老本。
自动化 / 智能化
运维所要负责的工作是很多的，所以运维要时刻想着通过自动化的伎俩去进步工作效率。如上文提到的疾速解决现网问题，运维除了纯熟排障工具的应用之外，如果能将多个工具的优化性能整合成一个工具，实现一键排障，那么就会大大提高故障排查的效率。
当效率进步之后，运维就有更多的工夫和精力去做更多有价值的工作。但要留神，自动化工具肯定要依据本身理论状况去建设，如果最终实现的自动化工具不实用本身工作环境，并且稳定性还很差，那么就会变成多了一项保护工作，这就是升高工作效率了。
而智能化所要解决的问题是，人力难以去实现的工作，比方故障预警，但智能化的根底是自动化，也就是说，要做好智能化的前提是先做好自动化，因为智能化所实现的是决策方面的事，最终的执行还是依附自动化去实现的。
进步版本公布效率
版本的公布上线应该属于开发和运维日常工作中的常事了，而一个新版本在公布上线之前，是要通过一系列的测试、安全检查等环节的，而这些工作是须要占用工程师大量工夫的，那么，进步版本的公布效率，就势在必行了。
一般来说，进步版本公布效率是通过 CI/CD 来实现的，搭建一套开发平台，研发编写完代码之后，提交到 Git 仓库，再一键启动代码审计、自动化测试、安全检查等性能，对要公布的程序包进行各项查看，再主动地将利用部署到生产环境，从而进步各环节的效率，不必手工实现这些工作。
降本增效的工作还有很多，须要大家在日常工作中多去思考和落地。
六、建设欠缺的监控体系
后面有很多工作内容，都须要依赖欠缺的监控体系，比方：危险预警、性能优化，构想一下，没有监控数据，你怎么做性能优化，总不能每次想起来要做的时候，手动去获取性能指标数据吧？那这样的效率是不是就太低了。还有，没有监控数据，如果对历史的资源应用状况做剖析，来达成危险预警的指标？
所以，我感觉建设欠缺的监控体系，是每一个运维都应该去做的事件，有了丰盛的监控指标和监控数据，你就能反推研发对系统进行优化，能在零碎危险暴发之前提前应答，能在零碎呈现故障时疾速定位。
这里说的欠缺的监控体系，不仅仅只是说监控一下服务器的 CPU 和内存使用率是多少就完事了，而是最好能做到，服务器上每个利用过程所占用的 CPU 和内存是多少，这样，运维能力晓得，应该优化哪些服务，让谁去优化。
再比方，是否能够减少一些业务监控指标，比方用户数、日活数、页面关上速度等等，这样能够分明晓得，零碎用户是在减少还是缩小，有没有可能因为用户体验差导致用户散失？这样才能够针对性地去进行优化和晋升。
总结
这篇文章分享了运维如何从日常工作中寻找亮点，次要从以下几个方面进行思考：
- 公司倒退策略
- 零碎稳定性晋升
- 性能晋升
- 现网问题危险预警和疾速解决
- 降本增效
- 建设欠缺的监控体系
其实能够做的工作还有很多，要求运维要多反思本人的工作，去寻找能够优化的中央。
并且，还须要留神一点就是，在做这些工作的时候，要多思考可推广性。比方，在造成标准文档和开发自动化工具的时候，多思考其余零碎是否能够借鉴应用，这样不仅仅只是实现繁多零碎的降本增效，能够在公司层面实现更大的优化。
大家如果有什么好的想法，欢送在评论里独特探讨。