如何接手新业务的运维？有些事情还是要提前说一下，以免前期不清楚，造成后期工作混乱。1、前期沟通首先要先和R&DLeader沟通，灌输运维理念，说脏话先说。我们不做保姆式运维。我们要致力于安全、稳定、低成本、快速迭代的在线服务。从运维角度提升产品力。开发机、测试环境、自行研发，我们可以协助提供专业的咨询服务，但我们不可能直接更改开发环境。2.业务概况了解业务相关人员：对应的R&D学生、R&DLeader、测试学生、测试负责人、产品经理，保存联系方式，建群，有的话找对应的人是个问题。了解服务的用途：它解决什么问题？有没有业界标杆的开源产品……方便我们快速了解这个产品。了解服务的上下游：哪些服务依赖，哪些服务依赖我，对应的接口人是谁……这里简单了解一下。了解业务部署情况：部署在哪个机房，用什么语言，基础网络，专线带宽，机房出口是否靠谱，是否出现过基础设施问题，目前主要痛点是什么.3.业务讲课要求研发同学（或者以前的运维同学）准备PPT，做一个业务讲课，解释一些研发同学想传达给运维同学的信息，同事也解释一些运维同学想传达的信息希望从研发中得到。.例如：详细的部署拓扑、整体服务架构、数据流向、测试和变更流程、监控方式、部署了哪些机器、机器登录方式、每台机器上有哪些模块、OS参数是否调优、需要考虑什么、使用使用了什么第三方软件，有什么注意事项，为什么使用Tomcat而不是Resin，相关wiki，故障处理方案，常见故障，目前线上问题...如果有单点业务，不接受它，让研发改造它。如果运维老大强行提出要求，丑的就是说：单点造成的问题，运维是不会怪罪的。4、资产整理在正式准备接手之前，首先要做的就是资产整理。比如使用了哪些域名，这些域名对应了哪些服务和虚拟IP，提供了哪些服务，部署了哪些机器，部署了哪些模块，业务使用了哪些机房，使用了多少带宽，总计bandwidth，是否有其他服务Sharedscramble等。机器需要获取更详细的信息，比如机器配置，机架位置，IP，管理卡IP等。公司应该有CMDB可以查询。如果没有，运维同学需要你来搭建这个CMDB。后期需要考虑机器是否需要备机备件，型号能否统一。5.基础监控一旦知道有哪些资产，就可以监控这些资产，比如域名连接监控/延迟监控、虚拟IP连接监控/延迟监控、机器宕机监控、机器硬件监控、sshd/crond等系统进程监控、系统运行进程总量监控、系统参数配置监控。6.服务整理一下之前串口给的架构图，数据流图，部署拓扑图。从运维的角度来说，最好知道公司的网络拓扑。了解各个模块的情况，部署在哪些机器上，部署在哪个目录下，用什么账号启动，日志发送到哪里，用什么语言写的，怎么上线，是否主要消耗CPU资源,memory,diskorIO,需要预留多少资源,平时的利用率是多少,应该配置什么阈值进行监控,watchdog是否需要自动激活,log中出现哪些关键字需要告警,以及其他需要注意的问题。7.业务监控后期会在API粒度上进行基础流程监控、端口存活性监控、机器利用率监控、日志关键字监控、日志非滚动监控、关联服务监控等，促进业务优化。8、标准化改造机器命名方式、操作系统发布版本、OS版本、第三方软件，如JDK、Tomcat、Nginx等，都要统一，实施标准化的解决方案。一键式服务扩容、变更、下线。您只需为每次升级提供一个版本号。这个时候研发运营还是和运维运营一样的效果，可以交给研发上线，解放运维人力，权限一定要控制好。重复的套路操作也要固化成脚本，一键完成。梳理故障自愈场景，看哪些故障通常是固定处理，抽象成脚本，告警后自动触发，无人值守处理。如果公司有一些基础设施，比如名称服务、MQ、日志平台等，推动研发和改造，对接新的服务。如果公司没有这些基础设施，作为运维的角色，可以开始搭建。9、SOP中故障预案的整理很重要。线路出现故障前，先想好服务可能出现什么故障；如果确实发生了，如何处理，并提前记录处理步骤。毕竟，当网上出现问题时，人们会更加紧张。直接看方案，会更实用，更不容易出错。10、故障演练没有演练的计划是不可靠的，没有验证的计划是不可靠的。所以，如果有防火演练，挂模块，挂机试试，肯定会提高在线稳定性。尤其是研发说这个模块宕机了，肯定不会影响可用性。好吧，我们先挂电话试试看，结果很可能是抽他的脸。一些情景排练可能是有害的。这种场景还需要练习吗？这个需要具体情况具体看。在大多数情况下，最好进行演习。毕竟，在人们盯着问题的时候出问题总比晚上睡着要好得多。当然大规模的基础网络故障演练还是忘掉吧，一般的业务是没有机房级容灾的。以上完成后，基本工作就完成了。上面很多事情都是一次性的，那么以后我们要花很多时间做什么呢？除了花一些时间在线解决问题外，我们应该把重点放在提升业务产品能力上。精细化运维，你还记得运维九字真言吗？“安全、稳定、高效、低成本”，这是我们的工作方向。下面给出了几个例子。11、再谈业务监控上面说的业务监控，主要是一些通用的监控指标。当我们对产品足够了解之后，我们应该做一些针对业务的监控，我们也可以推动研发，只要达到效果就可以了。比如你运维一个MQ，需要监控消息的堆积量；比如你运维一个RPC服务，它提供了三个接口，需要监控这三个接口的响应时间和成功率；维护一个S3服务后，需要监控每个bucket的短期带宽增量……你现在有这种感觉吗？12.API成功率和延迟统计流量入口的Nginx用于所有业务线的所有API成功率和延迟统计是非常必要的。找出成功率比较低的TopN，找出延迟比较大的TopN，让业务优化。老板会喜欢这个。13.在线问题整理所有在线问题，一一解决。能解决运维就解决运维，反映在每周报告中。14.成本优化通过服务整合或统一资源调度平台节省机器资源。一台便宜的机器要几万。这相对容易生产。15.容量规划容量规划和成本优化其实是密切相关的。产能规划的重点是根据自然增量和运营需求，提前规划和准备相应的产能。容量可能包括带宽、租用线路、网络设备、机器等。当业务量下降的时候，可以调配相关的资源去支持其他的业务线，让这些硬件尽可能的满负荷运行，这是物有所值的。业务精细化运维可以想出各种各样的事情来做。除了做这个，还有一个长期的投入就是搭建基础运维平台，比如监控系统、部署系统、产品库、资源利用平台、域名管理、四十七层接入配置平台、日志平台、Trace系统等等……嗯，其实运维还是挺忙的。16.关于沟通的最后一点。接手一个新业务的运维，难免和研发有各种沟通。每次沟通都要写会议纪要，发邮件，跟进人，时间点等等都要写清楚。邮件发到双方的team邮件群，抄送双方老板。然后，在关键节点进行检查。如果没有完成，请线下沟通。达成一致后，按照这个邮件进行总结，说明延迟的原因和新的时间点。如果沟通不顺畅，请老板协调。这基本上是我的意见。如果您有其他的看法或者更好的建议，欢迎在留言区分享。
