运维在程序员的眼中是什么

1. 计算机行业开发与运维的区别是什么

开发就是做程序员。这个很容易理解吧，工作就是写代码，写程序。程序员开发的项目，最终发布之后，上线交工之后。就需要运维来部署和监控，相当于项目的售后服务人员。

2. 运维和黑马程序员的其他学科相比，有什么优势

1、与编程学科相比，我们不需要编程思维，运维问题的解决方案相对固定，更重要的是运维不会被年龄所淘汰，是一个越老越吃香的专业，类似日常生活的老中医。
2、与设计学科相比，不需要美术功能，没有设计灵感一样可以成为专业运维工程师。
3、与产品经理相比，我们不需要协调各部门关系。
4、与电子商务相比，我们不需要文案功能。
5、与测试相比，我们的薪资更高，发展更稳定，未来更有“钱”途。

3. 为什么开发人员都看不起运维工程师

首先到底做运维还是研发，这个一方面是看个人能力，更重要的是兴趣。有些研发以为运维很简单，没有技术含量，不愿意做运维工作；而更多的运维工程师看不起自己，自认为低人一等。这些观念本身就有偏颇。

然后再说运维这个岗位。可以说包罗万象，很杂。就跟研发似的，语言很多，但也只能精通其一，要说同时精通c/c++和java什么的，估计内行人看了就笑了。为啥笑？这个道理大家都明白，人的精力是有限的，很少有人能够同时精通多重技能。反过来看运维也是一样的，不可能什么都精通，但需要什么都懂。除去个人因素，就是市场因素。就业市场上，大部分公司的运维人员配比其实很少，就跟财务、人事、行政差不多，甚至更少。这样就要求运维工程师一人身兼多职。办公室内部小到电话网线，出了公司能够给客户解决问题等等。而大公司可能分的细化一些，同样都是“运维”类岗位，有些人专职对内部，有些人专职对某项目，这样比较有利于运维工程师向更深层次发展。
最后就是关于这个职位将来要如何走下去，这就是个人职业生涯规划的问题。不管是转研发，还是继续做运维，都是个人的选择。永远不要去看别人如何如何，先要问自己想要什么，想做什么。运维到了高级就不单单是运维，更多的是架构设计，也包括研发（devops）。而研发到了高级，也必须懂运维。这些都是相辅相成的。

4. 运维在程序员眼里是个什么东西

在大多数程序员严重，管理层、运维、市场、客服等都是没有技术含量的，因为程序员的逻辑思维能力很强，在以往的人生道路上也都是比较优秀的群体，所以往往对自身评价很高。但同时，大多数程序员心里其实也清楚，有些事情他们也做不来，比如做市场，天天跟人打交道，往往就是绝大多数程序员最不愿意做的事情。
其实，每个行业分工既然存在，就必然有其存在的价值。

5. 运维工程师是青春饭吗

不是啊。运维工程师需求很多知识面。

网络基础+操作系统（核心学linux）网页链接+数据库（待遇高便于提升深造）；系统运维的工作越来越有经验，软件工程师就是吃青春饭。做系统运维，以后可以转向管理，职业很有前景。建议你先学一个基础，然后工作1年再深化培训。 可以学RHCE+CCNP+OCP,WINDOWS的我想你每天自学也没问题可以不学，系统运维就是比较细 杂 广 系统运维要求什么都懂一点，主要是基于Linux、UNIX有前途，shell 网络 数据库都需要懂一些。越老越吃香 知识不需要太多创造性的东西 了解基本规律 然后去部署排错 以后转管理。

6. 运维的资深运维工程师眼中的运维

以下是中国互联网业界部分资深运维工程师对运维的看法（涉及隐私，相关人名采用首字母缩写）：
CXY:
运维是一个非常广泛的定义，在不同的公司不同的阶段有着不同的职责与定位，如果以operation字面的含义去理解，认为就是敲几行操作命令的工作，那就错了。 对于初创公司，运维工程师的工作可能需要从申请域名开始，购买/租用服务器,上架，调整网络设备的设置，部署操作系统和运行环境，部署代码，设计和部署监控，防止漏洞和攻击等等。对于大型的公司，对于运维工作的要求越来越高，也催生了更细化的运维分工：从大的方向，可以分为网站运维，系统运维，网络运维，数据库运维，IT运维，运维开发，运维安全等方向。
很多非从业人员对运维的看法一般属于IT运维的一个非常小的职责：装系统^^。 一些研发工程师对运维的看法也只局限运维工作的几个点：部署, 变更, 监控，响应。
无论做什么运维，最基本的职责都是保证业务能够稳定运行。所以必须成为业务稳定性的owner。有些人通常认为运维工程师像消防员，7*24小时响应异常，救火。但是稳定性的运维工程师和医生的职业更接近。医生也分各种科室，也有急症室，需要先判断病人的问题，对症下药。
业务有着各种各样的需求，如果运维工程师能够满足业务需求，或者主动挖掘业务的痛点和改进方法，就能为业务实现更多的价值。
在满足业务需求时，应该分清主次，优先面对业务快速发展非常重要的需求，例如稳定性，部署和变更效率，容量管理。稳定性不用多说，如果用户没法稳定使用你的业务，什么产品特性都没有价值。对于网络这样极速发展的互联网公司，每天都有大量的升级更新需要提供给用户，如何在异地的大集群上最快的满足产品的升级需求，同时让用户对升级过程无感知，这是我们的追求。当用户会用网络来测量网络是否可以上网时，就是对运维质量的褒奖。
其次，可以横向看看不同业务的需求。如果能够把多个业务的需求抽象出来，把一些有通用价值的工作平台化（例如数据库，cdn，监控，流量接入和调度，大数据的存储和计算），也能在这个方向进行深入的发展。在网络这样的巨大的流量和服务器规模下，你不仅有巨大的空间和挑战，也有着充足的资源和支持，可以开发和应用业界最前沿的技术。
有一定的积累后，可以进入到宏观和微观的两个层面，从整个公司层面考虑业务的智能部署和调度（涉及网络，硬件，系统，应用开发方式等各个要点），进一步提升效率和节省成本。
如果能够懂业务，理解业务的模式，紧密结合业务进行优化和创新，也是运维工程师体现价值的另外一种方式。有很多产品上的创新，专利的申请，论文的发表，业务指标的提升，直接或者以合作的方式由运维工程师贡献。
YBX:
运维工程师相对研发人员来讲，可以全局观察所维护的计算机系统，特别是高阶运维工程师，不存在模块界限，这种独特的位置带来很多价值： 知道准确的系统瓶颈点，进而知道系统准确的容量；在系统出现瓶颈前，知道如何快速提供容量。 知道系统的风险点，可以协调风险点上下相关关联模块，做出冗余策略；相比集中解决单点模块稳定性，更合理。 长期从事相关工作，积累较多的架构设计经验，可以指导新架构设计和审核。 从公司不同业务角度看，运维可以从中抽象相同的模块，统一管理，形成有效的平台和自动化管理方法 同样从公司不同业务角度看，可以统一调配资源，进而节省资源。
KZ: 设计并实现可以提高公司服务可用性，可扩展性，延迟和效率的软件。 处理日常紧急事故，修正，替换问题组件。并设计规避问题方法。 设计和实现新的超大规模分布式系统架构和标准。 参与服务扩容计划和预测服务增长趋势，对软件和系统性能进行调优。 提供在线咨询服务和现场解决问题服务。 构建自动运维平台，解决日常问题。 构建知识库，预测可能的问题。 XX:
运维即生产环境以及和生产环境相关的资源、服务的维护的整个过程，包括了相关的技术、流程手段，确保生产环境稳定、高效、低成本的运行。
运维一方面为对业务功能最终负责，其价值的体现为最大化助力产品价值的发挥。这通常是通过将产品功能的运行表现提升到极致来达成的。例如搜索引擎的运维重点要保障用户在搜索时候的极致体验：稳、快、准、新、全。而一个在线聊天系统的运维应该是确保用户聊天过程的实时与顺畅。另一方面为对在线业务的成本最终负责。其价值的体现为降低服务运行成本
运维工作的开展方式一般取决于所维护的业务特点需求，形成所需的多个主题方向进行开展。通常的解决方案中包括如下的一些主题方向：事件管理、配置管理、变更管理、容量管理等。
运维工程师的要求特别严苛，因为运维工程师针对不同的问题，需要不断的补充扩大自己的知识和研究范畴。
在初级阶段，优秀运维工程师会体现出格外出众的主动性和责任心，面对陌生的业务会主动学习和拓展自己对业务对认识和相应的知识范畴，以能够足够的胜任业务的独立维护。
在逐步的发展阶段中，注重总结反省的工程师会逐渐成长为高阶运维工程师，通常他们会有比较体系化的服务运维理解。也有一部分工程师由于出色的项目管理规划能力，逐渐成为项目经理
再进一步的发展，高阶的运维工程师对于产品的理解将非常的透彻，因而在这种情况下，高阶运维工程师甚至可以成为产品的产品经理、产品研发的咨询顾问，在产品功能的设计与开发中起到至关重要的角色。
SJY:
一个运维工程师所需的技术体系以其专业方向而异。但基本的计算机系统架构，操作系统，网络技术的掌握是基本要求。例如你可能需要熟练掌握linux操作系统的使用，熟练使用各种脚本工具来处理日常工作任务，精通TCP/IP协议栈以排查一个大规模网络系统中的流量异常问题等。更进一步的你需要形成一套软件可运维性方面的经验积累，以此作为后续工作的指导。
一个运维工程师在初期阶段目的是掌握维护一套系统所需的所有软硬件知识和经验。进阶阶段是需要能够设计开发一套基础的体系软件，以支撑业务系统的稳定可靠运行，即开发服务于软件的软件，以支持更大规模的业务系统，提高运维生产力。最高阶段是反作用于软件系统的构建和运行阶段，使得系统从诞生阶段起即具有天然的可运维性，以最大化系统的生产力，同时最小化对外部支撑资源的依赖。
ZM：
运维工程师首先应该是软件工程师（Software Engineer），只是责任和侧重有所不同。
运维工程师不是系统管理员。和系统管理员最大的差别是，运维工程师的工作不仅仅是配置和管理系统，而且可以运用软件开发的方法来增强系统的功能、或者对数据进行分析。
运维工程师应该是软件工程师、系统工程师等角色的综合体，和一般软件工程师相比、应该具有更加广博的知识背景
运维的职责在于： 保证服务的稳定运行； 考虑服务的可扩展性； 从系统的稳定性和可运维性的角度，提出开发需求； 定位系统的问题，甚至可以直接修正bug； 对突然出现的问题做到快速响应和处理； 运维的日常工作： 需要对系统的需求和设计方案进行分析，思考在保证稳定性方面有哪些可以加强的地方，并和系统的研发人员进行有效沟通； 使用工具、或者写程序，对运营数据进行分析； 写程序以建立工具或平台，去加强系统的稳定性； 运维工程师最重要的是会运用编程和软件的方法来解决问题。发展的道路应该和软件工程师没有很大的区别，差异只是关注点和领域方向的不同

7. 做it运维，和做程序员的区别

运维：系统运维、主机运维、系统维护，编程相对程序员少，对技术的广度、心理素质要求较高；
程序员：使用某种编程语言或者几种编程语言进行产品研发，或者做项目，编程较多。

8. 程序员面试，为什么感觉很多都和运维有关

不会运维的程序员不是好程序员。 这个信条要时刻谨记，不管是面试还是自己平时在工作中都要坚持这个准则，因为这对你以后的发展大有裨益。

一直以来，很多圈外人对我们程序员的观念就是永远的一本正经，着装单一，了无生趣，聪明绝顶，其实这是他们对程序员的误解，因为多才多艺，多姿多彩的程序员比比皆是，但是传统的观念或者说以偏概全的观念蒙蔽了他们的双眼，而他们自己又没有尝试去了解，所以导致人云亦云，给程序员披上了一层灰。

同样的，我们大部分程序员的观念也跟他们差不多，认为程序员就只是搬砖撸码的，至于各种部署服务器相关的工作应该是运维做的，其实非也，如果真的这样认为的话，那就真的太不把自己当程序员了。为什么这么说呢？因为我们程序员是实实在在撸码开发产品的群体，可是如果我们开发出来的东西只能自个在本地玩耍，却不能众乐乐，那还有什么意义，此时，你可能会说，交给运维啊，那么如果没有运维呢，就没法玩了，所以我们不能总是将希望寄托在别人身上，当自己有能力能够将系统进行部署的时候，那就该学会部署。

其实不仅仅是程序员，优秀的运维工程师也是需要会开发撸码的，因为有时候他们也需要开发一些小工具来进行验证，或者开发网页来进行服务的管理，所以说程序员和运维都是相辅相成的。

像我们现在很多的公司都没有明确的人员分工，特别是小公司连运维都没有，所以就谈不上让运维去部署了，那么怎么办呢？肯定就是开发人员自己去部署了，如果不会部署的话就可以去网上查找资料，其实总体来说不会很难，因为我看过很多运维其实也是在网上找资料按步聚进行操作。

另外公司之所以这么要求，一方面是基于人员成本的考虑，毕竟如果一个人能干好的事为啥非得招两个人；另一方面可能基于公司的发展问题，像一般的小公司确实没必要专门招一个运维，不过随着公司的发展，后期肯定会招专业运维，毕竟专人做专事，事半功倍。

永远记住“不会运维的程序员不是好程序员”，其实作为程序员不能总是把自己陷在撸码的深渊，除了撸码，我们还要学会产品需求分析、简单的UI画图、数据库分表分库及性能优化、运维服务器部署、单元及系统测试等等，总的来说，要想成为优秀的程序员，我们有必要把产品线上的每一个环节都略知一二，这是经验收获，一定会成为我们日后发展的资本。

技术迭代是需要时间的，而且公司预算不多的话，会选择现有系统继续使用。有的企业也会选择维稳，不会轻易开发新系统代替现有系统。

这是一个非常好的问题，作为一名IT从业者，我来回答一下。

首先，在当前的大数据、云计算时代，程序员在面试的过程中，经常会遇到与运维相关的问题，尤其是有自身产品（平台类）的企业，往往对于程序员的运维类知识有比较多的要求，所以当前的程序员，尤其是Java程序员，要想获得较强的岗位竞争力，一定要重视运维类知识的学习。

在当前的大数据时代背景下，很多程序员在日常开发过程中，需要与运维人员进行配合，所以程序员在面试过程中，经常会被问及与运维相关的问题，通过这样的问题，也能够全面了解程序员是否面对过大用户的并发问题，这对于判断程序员是否适合当前的招聘岗位也有一定的参考价值。

以大数据开发岗位为例，程序员在进行大数据任务开发的过程中，不可避免地需要与运维人员打交道，其中大数据平台的搭建就是比较繁琐的过程，另外还有一系列产品的安装和部署，这些通常都需要运维人员来完成。对于一款平台类产品来说，运维人员的技术能力能够在很大程度上决定软件平台的性能，而且运维人员与开发人员的配合也非常关键。

当然，对于程序员来说，如果能够自己掌握一定的运维知识，对于开发任务的开展还是很有帮助的，如果什么问题都需要运维人员来完成，不仅需要更多的运维人员，同时也会影响项目的整体开发进度。从这个角度来看，随着未来大数据技术的逐渐落地，程序员掌握一定的运维类知识，对于提升自身的工作效率，还是很有帮助的。

在程序员面试过程当中，通过一些运维知识也能够更加直观地了解到程序员的技术栈，相对于比较复杂的开发问题来说，运维知识的脉络还是比较清晰的，通过运维知识能够在一定程度上挤出一些“技术水分”，这也是很多面试官比较愿意问运维问题的主要原因。另外，对于一些创业型公司来说，程序员掌握一定的运维类知识，也会节省一些投入，尤其在产品研发的初期。

从技术体系结构来看，要想解决大用户的并发问题和系统扩展性问题，通常需要从两个角度出发，一个角度是技术选型，比如采用扩展性比较强的大数据平台，另一个角度就是硬件扩充，但是硬件扩充的前提是要有一个可扩充的平台体系，而通过运维知识，程序员的交流会更明确，技术方案也比较直观。

从岗位任务划分的角度来看，程序员的工作任务与运维人员的工作任务有比较明确的边界，但是在云计算技术的推动下，程序员接触运维场景的情况也在不断增加，比如通过云计算平台的支撑，很多传统的运维类任务，程序员也会比较方便地完成，比如安全配置等等。

最后，程序员在进行面试的过程中，如果遇到的运维类问题并不清楚，一定要如实回答，因为运维类知识需要一个积累的过程，而且经验往往非常重要，所以很多运维类知识，在短期内是无法掌握的，如果盲目扩展自己的知识面，会为后续的工作带来很多麻烦。

如果有互联网、大数据、人工智能等方面的问题，或者是考研方面的问题，都可以在评论区留言，或者私信我！

一、提问之前的准备

首先，最重要的是，你自己一开始就应该想清楚：

只有明确这些根本性的问题，才能正确高效地完成面试。

二、提问的原则

假定你对上一节的三个问题，已经有了清晰的想法，那么接下来就可以设计如何提问了。

有一些提问的原则，是你应该遵循的：

三、考察专业能力

为了确认面试者是胜任的，你可以问一些与职位相关的专业方面的问题。（不过通常来说，一次面试不足以看出一个人的专业能力。）

比如，你的招聘职位是系统管理员，你可以问"如何快速地在50台机器上部署Linux？"（提示：正确答案不是刻录50张安装光盘。）

另外，你还应该向面试者了解他的过去，因为过去是未来的最好预测依据。不过，提问的重点不要仅仅是他过去的成果，更要关注在当时的环境中，他是如何决策和实施的。

四、考察综合素质

因为人是会发展的，所以某种程度上，面试者的综合素质要比他的专业能力更重要。

所以，具体的技术问题（如何调用API、什么是设计模式、编程语言的语法等等）可以少问一些，更应该关注面试者的事业心、对工作的热情、进取心、自律能力、毅力等方面。

下面是一些典型问题：

五、考察理性思维

某些情况下，你可能需要了解面试者的分析判断能力，看他能否全面地思考问题、客观地评价自己。

那么，你可以依次提出这样三个问题：

这里的重点是，让面试者从正反两方面评价一件自己熟悉的东西，看看他的思维是否片面。答案无所谓对错，只要面试者有一个明确的立场，能够从正反两方面说出令人信服的理由，就可以了。比如，某个软件的口碑不好，但是面试者说他很喜欢，而且说得出一大堆理由，清楚地解释了这种软件的优点和缺点在哪里，这样就很好。

不邀自来。众所周知，越大型的公司，分工越明确。在BAT里面，有专门的前端，后端，ops，dba等等。他们专研一方面，所以有深度，有沉淀。遇到问题了，找到相应的人，能够快速解决问题。

但绝大多数中小公司，更偏爱样样都会的全栈，恨不得你一个人把所有活儿做完。并不一定需要有多大深度，能干活儿就行了。

再说，现在提倡devops，开发懂点运维，能够更好地定位问题，部署和架构项目，这是需求，也是趋势。

对小公司而言基本没有专门的运维，所以需要研发具备一些运维的知识，比如数据库的搭建、nginx、jdk部署，其它开源中间件，比如Kafka、es等等

其实这个目前真正大规模用的少，炒概念的多，很多公司根本没机会用. 但是他会问

我觉得很自然的事，为什么总有人说得高大上？装个软件，调个参数，做个逻辑卷，调一调网络，配置一下分布式组件，搞个文件系统程序员就应该不会？

这些工作，我们公司一般运维人员搞不定的。所以用啥，自己整。

个人观点，计算机知识就必须全面，才能做好一个程序员吧？

而且看大家回复，我有8成猜对，有8成以上的架构师，不懂底层，知识面也没传说中那么广。

现在devops在流行，说白了企业为了省成本，研发要干一部分运维的活。运维只负责硬件网络和k8s维护，其他什么部署啦，服务编排啦，通通交给程序员做。

不过这样倒也合理，运维只负责全公司通用的设施建设，至于cicd，服务编排，熔断限流等等，都和业务强相关，交给开发做比较贴近实际业务

9. 运维、测试、程序员，这些技术岗位哪个更有前景

在一个初具规模的互联网公司，从业务方面出发，有很多岗位类型，比如运营、客服、市场、产品、设计、技术等等。

在这些大类下面，还要细分各种小类，以技术为例，可分为前端（客户端）、后端、测试、运维、DBA等等，这些都是技术类岗位。

那么如果想从事这些技术岗位，该如何选择，哪一个更有前途呢？

这五个岗位，可以做一个分类，前端和后端、运维和DBA、测试

前端和后端属程序类，也就是通常大家知道的程序员，主要是根据产品的需求开发出软件，属于公司的技术核心，非常重要。没有程序员的软件公司，也不好意思称为软件公司。

运维和DBA，这两个岗位的主要工作是管理服务器程序运行的环境和依赖的数据。运维可以看成是服务器管理员，所有跟服务器相关工作都是由他处理，比如服务器程序运行环境CPU、内存、磁盘资源监控、网络是否稳定监控，服务器程序依赖的软件安装等等。DBA就是数据库管理员，专门管理生产环境的数据库如MySQL、Redis。这两个岗位的工资不一定比程序员低，但是市场需求没有程序员旺盛。一家软件公司可以没有运维和DBA，但是不能没有程序。运维和DBA一般只有上规模的企业配备，小公司都由程序员兼任，毕竟如果公司只有个位数的服务器，完全没有必要专门配备一个运维，老板也不愿意花这个钱。

测试，虽然也是技术岗位，但是我个人感觉他们的工作不和技术挂钩，他们的工作就是不断使用程序员开发出来的软件，找出其中的BUG和漏洞。与此同时，他们的另一项工作就是督促程序员干活，修BUG。

论这些岗位的技术含量，我觉得测试是最低的，低端的测试几乎没有技术门槛，只要有软件使用经验，基本上都能干干测试的活，毕竟只是用用软件找找BUG嘛，而程序和运维则不行，必须掌握基础的技术技能才能上岗。当然高端的测试另当别论，他们也可以牛逼到天上。

其次是运维，当然并不是说运维这个岗位没有技术含量，同样运维的技术含量也很高，只是通常情况下，程序员都会点运维的工作，装装环境，监控下服务器运行情况，都没什么问题。反过来，运维却不一定会程序员的工作。我觉得运维应该是脱胎与程序员，然后随着行业的发展，独立成为一个岗位，本质上还是依附与程序员。

最后则是程序，一个合格的程序员，不但要掌握程序员本职的技术，还需要会服务器运维的技术，比如自己搭建一个测试环境，这样的技能是必须的，所以对服务器必然要有较为深入的了解。同时需要会DBA的技术，通常DBA是在数据量巨大的情况下才会配备，大多数时候一家公司不需要DBA，DBA的工作的都由运维或者程序员兼职的。与此同时，程序员还需要测试技能，当程序员写出来一个程序时，免不了要进行自测，写测试用例等等，只有经过自己测试，才可以将功能提交给专门的测试人员进一步测试。

所以，对于这三类岗位，我觉得程序员的技术含量是最高的。

我们再来说说这些岗位的发展前景。

对于一个大公司来说，会有专门的研发部门、运维部门、测试部门，然后设有研发总监、运维总监、测试总监，这些领导在公司的身价不相上下，不存在谁压谁一头的情况。但是在小公司通常只有一个技术部，这个部门管辖所有技术类员工，包括程序、运维、测试，甚至有的公司还会包含设计人员。而技术部门的领导十有八九是程序员出身，几乎不太会是运维或测试出身。因为一个软件公司的技术部门，没有运维和测试，照样可以运转，虽然有可能转的不顺溜，但是一定可以转，但是没有程序员，即便运维和测试配备的多么强大，这个部门也转不起来。其次一个技术部门程序员的数量绝对是压制运维和测试人员数量的。因此在程序员中出技术部门领导的概率远大于在运维和测试中出领导，除非真的遇到难得一见的人才。

所以，如果你想从事互联网软件行业的技术岗位，要想选其中比较有前途的技术类岗位，那么首选程序员，当然，更多的机会也意味着有更大的竞争，同时也有更大的难度，你选择程序员不见得一定会成为技术部门的领导，选择测试和运维也不意味着职业生涯会默默无闻，只是相对来说程序员的情景更加明朗。

与此同时，关于35岁程序员会被淘汰的观点，其实运维和测试的危险性更大，仔细想想难道不是吗，运维和测试并没有比程序员更有优势，反而劣势一大堆，那么肯定比程序员先一步面对淘汰，这是市场规则。