运维架构，什么是运维

大家好，如果您还对运维架构不太了解，没有关系，今天就由本站为大家分享运维架构的知识，包括什么是运维的问题都会给大家分析到，还望可以解决大家的问题，下面我们就开始吧！

运维构架是程序员还是什么

运维架构是程序员。

运维工程师的工作强度是不是比开发工程师的工作强度低一些?

工作强度低不低是看各个公司的，在A公司运维的强度非常高，基本都是晚上回去还要加班做一些事情，主要原因是人比较少；而B公司的运维强度和人均的负荷成正比，这个我虽然为B服务过（以前我在一家B的供应商呆过，去过B做过一段时间），但是现在B怎么样我不太清楚；

2.运维工程师工作的技术含量会不会低一些?所以压力小一些?

–运维的工作性质主要还是维持运行的平稳和高效，工作主要有安装调试软硬件，根据不同开发项目配置服务器软件，监控等事情；相对开发来说更加偏向操作系统或数据库（这是两个方向，一般是分开招人的）；而开发的偏向于开发软件和一些中间件，数据库和系统一般就由运维的人把关；

a.DBA偏向软件，而OS管理员和network（比如cisco）管理员偏向软硬件结合，还有一种人就是纯粹玩硬件的（安装服务器硬件、机柜什么的）；

b.至于说技术含量，我个人认为越集成的东西管理的人操心就越少，而每个不同岗位的技术没有什么可比性，关键看你个人的性格；

c.相对开发，运维的经验学习成本是比较高的，就是说你不在一定的实用环境下是没法学会真本事的，而开发你坐在家里就可以摸索一个大概出来；而运维的知识更新的速度相对慢，10年前的DBA知识更新可能只有50%，而他本人会非常值钱，而2年前java的一些内容可能都没有发明出来；除非你在开发做到管理职位，否则纯技术开发学习更新的代价会非常高；反过来说：技术开发适合比较喜欢新鲜、喜欢创新的人，而运维适合循规蹈矩比较踏实的人；

3.在B,运维工程师的薪水只有开发的2/3左右.你们公司也是一样吗?

–我个人认为：公司给不同position的薪水肯定是和他预估这个职位重要性和工作强度成正比的，但和未来发展是否正比就不得而知了，这在B内部是有可比性的，至于A如何，我不太清楚，应该相差不大，毕竟A的运维已经是全球领先的，而且人数非常少；

4.运维工程师的发展前景怎么样,会不会以后的发展空间比较小?

–所谓发展空间是要结合你个人的性格，资深DBA之类的人在地球上还是很稀缺的，我知道ebay china operating center的DBA有开宝马上班的，而且运维不是吃青春饭，越老越吃香，可以说是个平滑的上升直线，而开发如果你只是一个执行者和coder，恐怕就是一个开始猛涨后面猛跌的曲线，毕竟开发知识代谢成本太高，过了30可能就会走下坡路。

如何进行面向运维的架构设计

优秀的架构对于运维具有十分积极的作用，因此，应该促进二者的融合。

方法/步骤

优秀的架构对于业务的重要性体现在方方面面，包括产品、开发、测试、客服、运维、用户，处处有感知。

面向运维的架构设计需要考虑容错容灾方面的内容，包括负载均衡，可调度性，异地多活，主从切换，柔性可用。

面向运维的架构设计需要考虑质量监控的内容，包括指标度量，基础监控，组件监控，业务监控，全链路监控，质量考核。

面向运维的架构设计需要考虑架构独立的内容，包括独立部署，独立测试，组件规范和技术解耦。

面向运维的架构设计需要考虑部署友好性，包括CMDB配置，环境配置，依赖管理，部署方式，发布自测，灰度上线。

面向运维的架构设计需要考虑可运维性，包括配置管理，版本管理，标准操作，进程管理，空间管理，日志管理和集中管控。

面向运维的架构设计需要考虑性能成本方面的内容，包括吞吐性能，容量规划，运营成本等。

如何做好运维工作

一、运维方法

技术层面：

随着信息技术的发展以及企业业务的不断扩张，运维人员所面临的系统架构越发的复杂，关联度越发紧密。对运维人员的要求也会越来越高，打造个个都是高手，对业务系统了如指掌。

1、需要运维人员快速转变观念，学会通过主动运维的方式应对复杂多变的 IT问题，保证业务系统的稳定。

2、更多的站在客户的层面思考问题，解决问题。

3、使用集成的运维平台，在业务系统没有感知的情况下实现了业务的变更、升级。

运维文档层面：

一个好的系统或者项目，必定有很多的文档进行支撑。

1、系统建设前期，一定要做好系统的需求文档、设计文档、实施文档。在系统建设中要依据前期的文档进行实施和设计，并生成系统相关的问题总结文档和更新实施文档。

2、系统建设完成后，要基于系统的业务能力和使用对象编写操作手册和运维手册等。

3、业务在交付一定要文档同行。否则系统上线后问题层出不穷，导致运维人员手忙脚乱，不知道从何下手处理，往往会让运维人员绕很多的弯路，错失良机。

4、文档归类保存：文档也分好多种，比如配置文档、实施文档、设计文档、系统规范性文档、项目管理文档等等。做到一式两份，运维部门一份，档案室一份。

5、要求运维人员一定要具备相应的文档编写能力和整理能力。同时一定要严格按照之前的文档进行实施，有问题要学会及时沟通，并把修正后的问题更新到文档中。

6、建立知识库：把运维过程中出现的问题及解决办法和思路，另外最重要的是运维事件的总结，记录在案。

运维流程层面：

1、建立运维流程。要求运维人员一定要基于一个既定的规则来干活。

2、通过流程确定事件责任。业务人员专注点与运维人员的专注点不同，责任也不同。

3、使用ITIL了（即 IT基础架构库(Information Technology Infrastructure Library，ITIL，信息技术基础架构库)。ITIL为企业的 IT服务管理实践提供了一个客观、严谨、可量化的标准和规范。

二、运维人员技术

正所谓工欲善其事，必先利其器。很多的企业都在强化以用户服务为中心，专业技术为驱动的理念，可见拥有过硬的技术是多么的重要。

1、运维人员必须掌握的技能：

运维对技术的要求是很高的，首先运维人员要对自己所负责的系统有较深的理解，全程参与系统的设计、实施与运维。一定要具备相关领域的技术积累，有较丰富的设计或者排错经验

同时运维人员具备以下软实力：如沟通能力、合作心态和文档编写能力。

2、运维人员一定要对现在的主流技术有一定的涉猎（云计算、边缘计算、大数据、AIOps、人工智能、深度学习等等），要与时俱进。

3、经常参与线上或者线下的相关讨论和交流学习。了解目前流行的 IT技术，并学习它，思考如何将其用于企业的业务中，为企业创造价值，提升运维效率。所以具备主流技术的捕捉能力，也是运维人员的必修课之一。

三、运维现场监控层面

监控的目的就是防患于未然。通过监控，运维人员能够及时了解到企业网络的运行状态。

一旦出现安全隐患，可以及时预警或者是以其他方式通知运维人员，让运维监控人员有时间处理和解决，避免影响业务系统的正常使用，将一切问题的根源扼杀在摇篮当中。现在的监控工具可以在监控指标触发时，自动修复一些故障，但是它最多帮你做些简单的自动化任务，更高阶的自动化任务需要运维人员具备较深的脚本和系统知识。

什么是运维

运维是运维从业人员，负责维护并确保整个服务的高可用性，同时不断优化系统架构提升部署效率、优化资源利用率提高整体的ROI。

无论做什么运维，运维工程师最基本的职责都是负责服务的稳定性，确保服务可以7*24H不间断地为用户提供服务。在此之上运维工程师的主要工作职责如下：

1、质量：保障并不断提升服务的可用性，确保用户数据安全，提升用户体验。

2、效率：用自动化的工具/平台提升软件在研发生命周期中的工程效率。

3、成本：通过技术手段优化服务架构、性能调优；通过资源优化组合降低成本、提升ROI。

扩展资料

运维人员的要求特别严苛，因为运维人员针对不同的问题，需要不断的补充扩大自己的知识和研究范畴。

在初级阶段，优秀运维人员会体现出格外出众的主动性和责任心，面对陌生的业务会主动学习和拓展自己对业务对认识和相应的知识范畴，以能够足够的胜任业务的独立维护。

在逐步的发展阶段中，注重总结反省的工程师会逐渐成长为高阶运维人员，通常他们会有比较体系化的服务运维理解。也有一部分工程师由于出色的项目管理规划能力，逐渐成为项目经理。

再进一步的发展，高阶的运维人员对于产品的理解将非常的透彻，因而在这种情况下，高阶运维人员甚至可以成为产品的产品经理、产品研发的咨询顾问，在产品功能的设计与开发中起到至关重要的角色。

感谢您花时间阅读本文！我们希望通过对运维架构的问题进行探讨，为您提供了一些有用的见解和解决方案。如果您需要更多帮助或者有其他疑问，请不要犹豫与我们联系。