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