产品运维怎么搞

A. 如何做好第三方运维管理

不管是企事业单位自己聘请第三方来做运维管理，还是IT公司自己承接的第三方运维管理，如何做好作为第三方角色的运维管理呢？建议如下几个方面来考量：

1、重中之重，先上一个IT服务管理平台，引入服务台概念，将需求方和服务方有效连接，提供提交问题工单的入口和问题解决流程的透明化，让发出问题需求的人和解决问题的部门，都能对每一个问题的解决过程清晰、明了。当然，这里需要一个简便、周到的IT服务流程平台，个人推荐豪越的运维服务产品。

2、打好基础建设工作。信息化基础工作要是没做好，那永远是一团乱麻、问题不断、网络不畅通、问题频发。信息化基础工作很多，也不是一朝一夕就能搭建好，可以根据需求，分批次逐步落实，逐步建设。
3、引入运维管理平台。以网络性能数据采集和故障监控为主要功能点的运维管理平台，是现今各行各业信息化管理工作的必备工具。有个趁手的管理工具，相信运维工作效率、工作成果，都会和以前截然不同。
4、做好运维管理制度和运维工作流程建设。有据可依、有章可循，制度是每一个管理工作的基石。基于制度建设，再深化运维工作流程，梳理职责和分工，相信第三方运维工作也一样井井有条，起到很好的推进促进作用。

B. 运维项目管理流程

运维项目管理流程

导语：没有任何一个项目能轻而易举的成功。但是你却可以努力去争取更大的成功率，靠的便是精心设计、并且行之有效的流程管理。下面我为你整理的运维项目管理流程，希望对你有所帮助！

1、生命周期与方法论

这是项目的纪律，为项目开展划出了清晰的界限，以保证项目进程。生命周期主要是协调相关项目，而方法论为项目进程提供了持续稳定的方式方法。

生命周期通常由项目的阶段组成（包括：开始、规划、执行/控制、完成），或由工作的重复周期构成。项目生命周期的细节一般都会随具体业务、项目、客户要求而改变。因此即使在同一个项目中，周期也会有多种可能的变化。对工作细致度、文件管理、项目交付、项目沟通的要求体现在生命周期标准和考核的方方面面。大项目的阶段一般更多更长，而小项目的阶段少，考核点也少。

与生命周期类似，项目方法也因项目而易，细节关注程度高。产品开发项目的方法经常涉及使用何种工具或系统，以及如何使用。信息技术项目的方法包括版本控制标准、技术文档管理、系统开发的各个方面。

项目方法往往不是由项目团队自行确定，而由公司为所有项目设定。采用与否，其实项目团队没有太多选择。公司管理层设定的方法本身代表权威，也是你作为项目领导获得项目控制权的一个途径。考虑项目方法某方面的作用时，始终要把握其对项目人员管理的效率，即在可能出现问题的地方争取正面效应。

2、项目定义

清晰的项目描述决定了你的项目控制能力，因为接下来所有工作都在描述范畴之内。不管你如何并为何要进行描述，你要对你的项目进行书面定义，让项目各方和项目组随时参考。

项目定义的形式和名称各式各样，包括：项目章程、提案、项目数据表、工作报告书、项目细则。这些名称的共同点在于，项目主管方和其他相关各方面从上而下地传达了他们对项目的期待。清晰的项目定义还包括以下方面：

项目目标陈述 （一小段文字，对项目交付成果、工期、预期成本或人力进行高层次的描述）

项目回报（包括商业案例或投资分析的回报）

使用中的信息或客户需求

对项目范围进行定义，列出所有预期的项目成果

成本和时间预算目标

重大困难和假设

描述该项目对其他项目的依赖

高风险、所需的新技术、项目中的重大问题

努力将尽可能多的具体信息，囊括在项目描述或章程中，并使其在项目主管方和相关方面获得认可，进而生效。

3、合同与采购管理

不管你在你的组织内有多大的影响力和权力，你对受雇于其他公司的项目成员的影响会比较小。虽然不一定普遍适用，但你可以尽量不将项目工作外包，这是提高项目控制力的一个技巧。

在考虑启用合同商或外部顾问之前，对整体采购流程进行重检。寻找有服务合同起草经验并可以帮助你的人。

建立成功的外包关系需要时间和精力，这些工作要及早着手。为了不误项目工期，你要及时做到所有细节到位，所有合同及时签订。你打算外包哪部分项目交付成果，对这部分工作的细化就是你实施项目控制的着手点。记录这些细化内容、评估和接收标准、所有相关要求、必要时间规划。项目定义信息一定要包括在合同之内，相关责任及早确定。和所有你考虑到的供应商讨论这些要求，这样你的项目期望才会在各方之间明晰。

4、项目规划、执行、跟踪

作为项目领导，通过制定有力的规划、跟踪、执行流程，你可以建立项目控制的基础。争取各方面的.支持，进而在项目内全面推广。

让项目组成员参与规划和跟踪活动，这可以争取大家的支持并提高积极性。睿智的项目领导往往大范围地鼓励参与，并通过流程汇聚大家的力量。当大家看到自己的努力以及对项目的贡献被肯定的时候，项目很快就从“他们的项目”变成“我们的项目”。当项目成员视项目工作为己任的时候，项目控制就会简单得多。较之于漠不关心的团队，此时的项目管理成功几率更大。运用项目管理流程也会鼓励项目成员的合作，这也让你的项目控制工作更加轻松。

5、变化管理

技术性项目中问题最集中的方面就是缺少对具体变化的管理控制。要解决这个问题，需要在项目的各方面启用有效的变化管理流程。

解决方法可以很简单，例如被项目团队、项目主办方、相关方认可的流程图。这提醒了项目人员，变化在被接受之前会进行细致地考察，并且提高了变化提案的门槛。

审查变化提案的时候，要注意该提案是否对变化有清晰到位的描述。如果变化提案的动因描述得不清不楚，该提案就要打回去，并且要求对变化所带来的益处进行定量评估。对于那些仅局限于技术解决方案的变化提案，要多打几个问号，因为提案人也许不能全面地判断问题。如果变化提案过多地关注问题的解决，而不注重实际问题，打回去并要求关注具体的业务形势。

最后，如果不接受某变化提案，一定要做到有理有据。而且，对项目时间、成本、精力等其他相关因素所受的影响，进行合理的估计。

6、风险管理

风险管理的流程能让你制定出全面的规划，找出潜在的麻烦，就风险问题的解决方法达成一致，根除严重的问题。

风险管理要做到事半功倍，就要与项目规划同时进行。进行项目工作分解安排时，注意对项目活动的不恰当理解；分配项目任务和开展评估时，寻找风险；资源匮乏或项目资源不足，或项目工作依赖于某一个人时，要知道风险的存在。分析项目工作将遇到的困难，鼓励所有参与规划的人在规划过程中，设想最坏的情况和潜在困难。

7、质量管理

质量管理提供了另一套搭建项目结构的流程，保证项目领导提出的工作要求一个不落地执行到位。项目质量的标准分两类：行业内实行的全球质量标准，公司或项目独有的质量标准。

如果你的公司实行或接受了质量标准，要注意该标准对你和你的团队有何要求。具体而言，这些标准会包括ISO 9000标准或六西格玛。进而确定质检清单、质控流程及相关要求，并将其与你的项目规划进行整合。项目必须遵守的书面步骤、报告、评估，对团队成员是强有力的推动，让大家步调一致。标准比你的临时要求更有效。

质量管理流程还能将项目要求与客户心声联系起来。不管你说什么，只要是在传递客户或用户的要求，你都要加以强调。市场调查、标杆分析、客户访谈都是评估和记录用户需求并确定项目要求价值的好工具。

8、问题管理

项目开展过程中问题的出现不可避免。在项目初期，在资源、工期、优先事项等其他方面为项目的问题管理确定流程。争取让团队支持及时发现、跟踪、解决问题的流程规定。建立跟踪流程，记录当前问题。问题记录信息包括：问题描述、问题特征或表现（用于沟通）、开始时间、责任人、目前状态、预计结束时间。

处理待解决问题的流程很简单，包括列出新问题的流程、定期复查待解决的问题、处理老问题的方法。对于没有太多组织管理权的项目领导而言，问题跟踪流程的力量在于让其把握了问题状态和进度的实时信息。一旦问题责任人承诺了问题解决的时限，你可以任意公布问题解决过程中的变数。不管问题责任人是本项目成员，还是其他项目或部门的成员，谁都不乐意随时将自己的大名置于人们质疑的目光中。问题清单的公开使得掌握该清单的人获得一定的影响力和控制力。

9、决策

项目管理时时有决策，快速得当的决策对于项目控制至关重要。即使项目领导掌握了控制权，完善的集体决策流程仍然裨益颇多，因为共同决策能获得更多内部支持，效果自然会更好。

项目工作中的决策绝非易事，项目组内纷繁复杂的观点让决策更加困难。项目各方认同的问题解决流程可以简化决策的过程，照顾各方要求。

尽早和你的项目组一起设立决策流程，或采用现有流程，或对现有流程做适当的修改。好的决策流程能为你的项目控制提供强有力的支持。该流程应该包括以下步骤：

清楚地陈述必须解决的问题。

吸纳所有需要参与决策或将会受该决策影响的成员参与决策过程，这样可以争取团队支持。

与项目组一道重审项目陈述，必要时进行修正，让每位成员获得一致认识。

针对决策标准（如：成本、时间、有效性、完整性、可行性），开展头脑风暴或讨论。选择那些与计划目标关联的、可执行、可供项目各方参考供决策之用的标准。

与项目组一道确定各标准的权重（所有标准的权重总和为100个百分点）。

设定决策的时限，规定用于调查、分析、讨论、最终决策的时间。

开展头脑风暴，在规定时间内尽可能多地产生决策想法。多方发展整个项目组都能接受的想法。

通过集体投票的方法进行筛选，至多确定六个考虑项进行具体分析。分析其与决策标准的契合度。

理性对待讨论中出现的异议。有必要的话，可增加决策标准。

根据评估和权重标准，将这些选项进行排序。

考虑采用首位选项的结果。如果没有异议，则结束讨论并开始实施决策。

将决策写入文件，并与团队成员及项目相关方面沟通决策结果。

10、信息管理

这项是非常关键的资源，如何管理值得仔细思考。有的项目使用网站和网络服务器，或信息管理系统，进行项目重要信息的存储。有的项目则使用群件来维护项目文件，并提供电子邮件等服务。

不管你用何种方式存储项目数据，要保证所有项目成员能随时获得所需信息。将最新的项目文件存储在方便查找的位置，进行清楚地标记，及时删除过时信息。

C. 什么是运维运维工作具体要做什么

运维（Operation and maintenance）一般是指对大型组织已经建立好的网络软硬件的维护，其中传统的运维是指信息技术运维（IT运维）。
所谓IT运维管理，是指单位 IT 部门采用相关的方法、手段、技术、制度、流程和文档 等，对IT 运行环境（如软硬件环境、网络环境等）、IT 业务系统和 IT 运维人员进行的综合管理。
随着信息化进程的推进，运维管理将覆盖对整个组织运行，进行支持的管理信息系统涵盖的所有内容，除了传统的IT运维，还拓展了业务运维和日常管理运维。
其参与的对象也从IT部门和人员，拓展到组织的管理层和各部门，及其相关的业务骨干。运维的最终结果是对软件运行中各种性能的维护。
运维工程师从工作方式上分为几大类：
1，运维工程师/运维开发工程师：
负责具体的产品线运维工作，同时也需要掌握开发的能力，深入业务，最了解业务的痛点和问题，同时研发/优化针对产品业务需求的平台、工具和手段，能够接触到各类优秀的系统架构并有能力做出优劣对比，同时对业务的掌控决定了相应运维工程师在业务发展中的作用。长远发展是成为大型系统的架构师。
2，运维平台研发工程师：
专门研发运维相关通用平台和技术，需要有一定的产品线运维经验或从产品线中拿到运维需求。对研发能力有较高的要求，对系统的设计有较严格的标准，并且能够理解用户需求，做出适合服务运维和满足运维工程师使用体验的运维产品，长远的发展是成为各个技术纵向领域的技术专家。
3，数据库研发工程师/数据库工程师：
数据库方向是运维技术中较为特殊的一个方向，由于业务的重要性通常需要专设岗位，业界在该方向也有深厚的研究和积累。主要方向有数据库内核、云数据库等，长远发展是数据库领域的技术专家，数据库架构师。
4，运维经理：
运维同学做事情的过程中通常需要协调多个RD和QA同学，对协调和推进能力要求比较高，对一些技术深度还不错，协调和推进能力比较高的同学非常适合转型管理职位，长远的发展和技术部门的管理职位一样目标是CTO、CEO。

D. 运维是做什么的

运维，一般专指互联网运维，是互联网企业的技术部门之一；对网络、服务器、服务的生命周期各个阶段进行运营和维护，使公司在成本、稳定性、效率上达到一定的平衡状态。

互联网运维工作，以服务为中心，以稳定、安全、高效为三个基本点，确保公司的互联网业务能够 7×24 小时为用户提供高质量的服务。运维人员对公司互联网业务所依赖的基础设施、基础服务、线上业务进行稳定性加强，进行日常巡检发现服务可能存在的隐患，对整体架构进行优化以屏蔽常见的运行故障，多数据中接入提高业务的容灾能力。通过监控、日志分析等技术手段，及时发现和响应服务故障，减少服务中断的时间，使公司的互联网业务符合预期的可用性要求，持续稳定地为用户提供服务。在安全方面，运维人员需要关注业务运行所涉及的各个层面，确保用户能够安全、完整地访问在线业务。

想了解更多有关运维的详情，推荐选择【达内教育】。该机构具有丰厚的师资力量，优秀的教学体系，教学质量突出，实战讲师，经验丰富，理论知识+学习思维+实战操作，打造完整学习闭环。该机构独创TTS8.0教学系统，并设有企业双选会。达内的OMO教学模式，全新升级，线上线下交互学习，直播学，随时学，随时问，反复学，学习安排更便捷。→感兴趣的话点击此处，免费学习一下

E. 做运维都干些什么

运维的核心工作其实就是为了维护IT设备和系统的稳定，甭管硬件、网络、安全什么的，无论黑猫白猫抓到老鼠就是好猫。

云计算时代下的运维和传统运维在工作内容还是有差距的，从过去的机房、交换机、存储、带宽等实体设施，到云服务上的虚拟产品，从实到虚的变化，更多的工作其实在操作端，云主机资源的模板化，为不同业务团队配置性能合适的主机模板。

简介

以及主机资源申请、创建、交付、运维以及最终的释放销毁的全生命周期管理，还有应用程序和支持软件的安装部署／交付和升级，集群性能负载均衡调配、服务器的批量脚本操作、数据库维护、主机的监控、运维日常工作的审计等等，当然了，多云情况下，各云使用的费用情况也需要统计和分析。

而这其中，如何及时发现问题，并在问题造成事故之前就解决了才是最难的，这就需要我们拥有事前监控、事中处置的运维能力，当然了，好的运维工具就必不可少。

F. 运维是做什么的

不同类型的运维，具体的工作也是不一样的，例举部分如下：

1、运维工程师/运维开发工程师：负责具体的产品线运维工作，同时也需要掌握开发的能力，深入业务，最了解业务的痛点和问题，同时研发/优化针对产品业务需求的平台、工具和手段，能够接触到各类优秀的系统架构并有能力做出优劣对比。

同时对业务的掌控决定了相应运维工程师在业务发展中的作用。长远发展是成为大型系统的架构师。

2、运维平台研发工程师：专门研发运维相关通用平台和技术，需要有一定的产品线运维经验或从产品线中拿到运维需求。对研发能力有较高的要求，对系统的设计有较严格的标准，并且能够理解用户需求。

做出适合服务运维和满足运维工程师使用体验的运维产品，长远的发展是成为各个技术纵向领域的技术专家。

3、数据库研发工程师/数据库工程师：数据库方向是运维技术中较为特殊的一个方向，由于业务的重要性通常需要专设岗位，业界在该方向也有深厚的研究和积累。主要方向有数据库内核、云数据库等，长远发展是数据库领域的技术专家，数据库架构师。

4、运维经理：运维同学做事情的过程中通常需要协调多个RD和QA同学，对协调和推进能力要求比较高，对一些技术深度还不错，协调和推进能力比较高的同学非常适合转型管理职位，长远的发展和技术部门的管理职位一样目标是CTO、CEO。

5、业务运维工程师：主要负责监控线上的服务质量，响应异常/处理突发故障，在线发布/升级产品。和相应产品线的研发和测试协调处理产品问题，基于工作中的问题和数据分析进行抽取，将运维经验理念落地沉淀为方法论/工具/系统/平台。

并制定相关的改进计划，在各个技术方向上落地实现，最终反馈回运维工作中，提高运维本身的效率和产品的价值。

G. 如何接手一个新业务的运维工作

丑话说前头

先跟研发leader沟通，灌输运维理念，丑话说在前头，我们不做保姆式运维，我们会致力于线上服务安全、稳定、低成本、快速迭代，从运维视角提高产品力。开发机、测试环境，研发自己搞，我们可以协助帮忙，做专业的咨询服务，想让我们直接操刀开发环境的变更，免谈！

业务概要了解

了解业务相关的人，对应的研发同学、研发leader、测试同学、测试leader、产品经理分别是谁，联系方式存下来，拉个群，出了问题可以找到对应的人。

了解服务是干啥的，解决了什么问题，业界有对标的开源产品吗，方便我们快速认识这个产品。

了解服务的上下游，依赖哪些服务，哪些服务依赖我，对应的接口人是谁，这里先简单了解一下即可。

了解服务部署情况，部署在哪些机房，用什么语言编写的，基础网络、专线带宽、机房出口是否靠谱，是否曾因基础设施导致过问题，当前主要痛点是什么。

业务串讲

要求研发同学（或者上一任运维同学）准备PPT，做一个业务串讲，讲解一些研发同学希望传达给运维同学的信息，讲解一些运维同学希望从研发这得到的信息。比如：详细部署拓扑、服务整体架构、数据流、提测变更流程、监控方式、部署到了哪些机器、机器登录方式、每个机器上是什么模块、OS参数是否有调优，考量是什么、用到了哪些第三方软件，考量是什么，比如为啥用了tomcat而不是resin、相关wiki、故障处理预案、常见故障、当前线上问题……等等

如果业务有单点，不接，让研发改造。如果运维的老板的老板强制要求，丑话说前头：因单点导致的问题，运维不背锅。

资产梳理

正式准备接手，第一步，梳理资产。比如用到了哪些域名，这些域名对应哪些业务、哪些虚IP，分别是提供了什么服务、哪些机器，分别部署了什么模块、业务在哪些机房、用了多少带宽、总带宽情况、是否有其他业务共用争抢。

机器需要拿到更详尽的信息，比如机器配置、机架位、IP、管理卡IP等等，公司应该有个CMDB供查询。如果没有，运维同学，需要你去构建这个CMDB。

后面要考虑机器是否需要有备机、备件，机型是否可以统一。

基础监控

知道有哪些资产了，就可以对这些资产做监控了，比如域名连通性监控/延迟监控、虚IP的连通性监控/延迟监控、机器宕机监控、机器硬件监控、sshd/crond等系统进程监控、系统运行的进程总数监控、系统参数配置监控，可以参看我之前的文章《 完备的监控应覆盖什么 》

服务梳理

吃透之前串讲时给的架构图、数据流图、部署拓扑图。从运维层面，最好还要知道公司网络拓扑图。

了解每个模块的情况，部署在哪些机器上，部署在哪个目录，用什么账号启动的，日志打到哪里了，用什么语言编写的，怎么上线的，主要吃CPU资源还是内存还是磁盘还是IO，需要预留多少资源，平时利用率是多少，应该配置多大的阈值做监控，是否需要watchdog自动拉起，日志里出现哪些关键字需要报警，以及其他各种需要注意的问题。

业务监控

基本的进程、端口存活性监控，机器利用率监控、日志关键字监控、日志不滚动监控、关联的服务的监控等等，后面会做API粒度的监控，来推动业务优化。

标准化改造

机器命名方式、操作系统发行版、OS版本、第三方软件，比如jdk、tomcat、nginx，都要统一，做标准化方案。

服务扩容、变更、下线做一键化，每次升级只需要给个版本号即可，此时研发操作还是运维操作效果一样，故而可以交给研发上线，释放运维人力，权限要控制好。

重复的常规操作也要固化成脚本，一键完成。

梳理故障自愈场景，看平时有哪些故障的处理方式是固定的，抽象为脚本，报警之后自动触发，无人值守处理。

公司如果有一些基础设施，比如名字服务、MQ、日志平台，推动研发改造，将新服务接入。如果公司还没有这些基础设施，作为运维这个角色，可以着手搞起。

SOP梳理

故障预案是一个非常重要的事情，线上没出故障之前，就应该提前去想，服务可能会出什么故障，如果真出了，应该如何处理，把处理步骤提前记录下来。毕竟，线上出故障的时候，人都比较紧张，直接看着预案处理，就踏实不少，不容易出错。

故障演练

光有预案没有演练，是不靠谱的，没有经过验证的预案是不可信任的。所以，搞个放火演习，把模块搞挂试一把，把机器搞挂试一把，对线上稳定性绝对会有提升。

特别是研发说这个模块挂掉，可用性肯定没影响，OK，搞挂试试先。很可能会打他脸，-_-||

有些场景演练是会有损的。这种场景还要不要演练？这个需要case by case的看，大部分情况都是要做演练会更好，毕竟，人在这盯着的时候出问题，比晚上睡着了出了问题要强太多。当然， 大规模基础网络故障这种演练，还是算了吧，通常的业务都是不具备机房级容灾的，呵呵

上面做完了，基本工作就完成了。上面很多事情都是一次性的，那未来的大把时间运维做啥？

除了再花费部分时间做线上问题处理，我们应该把主要精力来提升业务产品力。做精细化运维，还记得运维九字真言么？“安全稳定高效低成本”，这就是我们的工作方向。下面举几个例子。

再谈业务监控

上面谈到过一次业务监控，主要是一些通用的监控指标。我们对产品了解足够之后，应该做一些业务特有的监控，推动研发去做也可以，达到效果就好。

比如你运维了一个MQ，消息堆积量是需要监控滴；比如你运维了一个RPC服务，提供了三个接口，这三个接口的响应时长、成功率是需要监控滴；比如你运维了一个S3服务，每个桶的短期带宽增量你是需要监控滴；有那么点感觉了么？ :)

API成功率、延迟统计

在流量入口的nginx做所有业务线的所有API的成功率和延迟统计，是非常有必要的。把成功率比较低的TopN找出来，把延迟比较大的TopN找出来，让业务去优化。老板会喜欢这个的。

线上问题梳理

整理线上所有问题，挨个解决，运维可以搞定的运维搞定，运维搞不定的找研发要排期，每周解决了多少问题，还有多少问题待解决，用周报的方式体现出来。

成本优化

通过服务混部、或者统一的资源调度平台来节省机器资源，一台机器便宜的也好几万呢，这个事是比较容易有产出的。

容量规划

容量规划和成本优化实际是紧密相关的，容量规划的重点是根据自然增量和运营需求，提前规划准备相应的容量，容量可能包括带宽、专线、网络设备、机器等等；当业务量下来的时候，可以腾挪相关资源支持其他业务线，让这些硬件尽量满负荷运转，物有所值。

业务精细化运维可以想出各种事情来搞，除了做这事，另一个需要长期投入的是构建运维基础平台，像什么监控系统、部署系统、产品库、资源利用率平台、域名管理、四七层接入配置平台、日志平台、Trace系统等等等等，嗯，其实运维还是挺忙的。

关于沟通

最后说一点，接手一个新业务运维，势必与研发有各种沟通，每次沟通都要写会议纪要，发邮件出来，跟进人是谁，时间点是啥时候都要写明白，邮件发送双方团队邮件组，cc各方老大。事后关键节点做check，如未完成，线下沟通，达成一致后追此邮件给结论，说明延期原因以及新的时间点。如果沟通不畅，让老大去协调。

H. 运维，这东西具体怎么做

运维一般是指对大型组织已经建立好的网络软硬件的维护，其中传统的运维是指信息技术运维（IT运维）。所谓IT运维管理，是指单位IT 部门采用相关的方法、手段、技术、制度、流程和文档等，对IT运行环境（如软硬件环境、网络环境等）、IT业务系统和IT运维人员进行的综合管理。随着信息化进程的推进，运维管理会覆盖对整个组织运行，进行支持的管理信息系统涵盖的所有内容，除了传统的IT运维，还拓展了业务运维和日常管理运维。业务运维面向整个组织提供各业务系统的问题受理、响应、处理和转交等方面的服务；日常管理运维面向整个组织提供针对各业务系统的运行状态和需求变化和不同的记录、跟踪、保存、分析方面的管理