摘要：前言最近部门变动，负责接手电商业务的运维工作，但是电商原来运维人员人，我只有人，因此这个交接工作还是挺有难度和压力的，已经交接完毕，我想这些经验对于新工作新环境新业务都有所帮助，也是自己的运维足迹，记录一二跟产品运营了解业务由于以前没有接触
前言:
最近部门变动，负责接手电商业务的运维工作，但是电商原来运维人员6人，我只有1人，因此这个交接工作还是挺有难度和压力的，已经交接完毕，我想这些经验对于新工作、新环境、新业务都有所帮助，也是自己的运维足迹，记录一二
由于以前没有接触过电商的运维，因此首先了解电商业务，梳理为以下
电商产品详情
电商功能模块
电商节假日活动
用户登录、浏览、下单、支付流程
是否有抢购秒杀类业务
优惠券红包积分等业务
会员业务
以上业务最好跟产品、运营去了解，他们是比较清楚的，对这些清楚了之后才能开展之后的运维工作
跟研发了解系统架构跟开发聊聊业务架构，了解所使用的技术，为什么使用，以及好处。最好让其准备PPT能演讲下，如果不行让其发发文档看看也是好的，梳理以下几点
了解各项目业务架构设计，及拓扑图
大流量场景业务
目前存在的业务瓶颈
有无历史遗留落后设计
有无应用最新技术及为什么这样选择
在这里只是了解，运维跟研发是会一直合作的，因此后面可以带着问题再找到相关负责人
运维相关这里就涉及到我们的主要工作了，了解运维的方式，技术栈等等，列了如下
了解阅读运维文档，一般有wiki，因此可以先看看大致了解，但不是所有wiki都有章有法，多数还是很乱
了解当前运维资产，服务器、网络、数据库等相关运维资源情况
了解当前运维方式，如人肉、脚本、自动化等等，看看当前处于哪个阶段
了解当前运维技术栈，毕竟运维技术、工具更新快，且多又杂，不一定都接触过
了解线下线上发布流程，是否自动化
了解各业务部署的运维架构
了解目前运维安全方面的防护
了解和开发测试运营等合作方式
减少踩坑风险相信很多人如果接手其他人的工作时，前面都是比较痛苦的，因为其他人的工作方式、理念等都跟自己或多或少都有出入，就运维而言，自己当前的技术能力如果与接手的运维工作阶段(如自动化程度较高)有出入，则很难快速着手，比如工作中没有一定的标准、规范会导致很混乱，或者即使有标准规范，但执行得不理想。又或者工作中都靠口头相传，没有很好的文档记录，因此想要快速，首先自身的技术需要有一定的基础，其次就是努力熟悉了，这里我主要是提出几点减少踩坑坑的方法
1.做好记录
如果跟人交接，则一定要做好记录，这点非常重要，因为人在短时间内接收一大堆东西是非常容易忘记的，俗话说的好，好记性不如烂笔头，最重要的是自己记录的过程也会形成一种记忆，可以回想当时为什么这样记录帮助回忆，另外很多wiki上找不到的考运维间口头相传的更要记录
2.标准与非标准
现在运维DEVOPS理念很火，但其实好些团队做得并不完全，有些地方做了标准化，有些地方又保留了老的，导致运维过程中，有些自动化了有些还是人肉，这些需要好好区分开来，否则很容易出故障，当然后续是一定优化这样的不良运维
3.熟悉各业务所在服务器
首先运维自己也要熟悉产品相关的业务，当我们业务出问题时，才能第一时间处理，比如某个页面打不开，那么是什么域名，什么业务，可能在哪些地方出故障，我们也要第一时间知道这些业务在哪些服务器上面，这样才能方面运维排查问题，所以要熟悉业务和服务器间的拓扑图
4.熟悉各个服务进程的启动停止方法
在运维里面流行一句话，没有什么是重启解决不了的，虽然不那么准确，但是运维工作中，的确有很多时候的故障是可以通过重启来快速恢复业务的，那么我们不同的服务进程如何重启一定要优先了解熟悉并记录，才能做到更快速的管理进程
5.熟悉各个服务的文件配置路径、日志路径
运维工作中总会有变动，故障等，当需要修改配置文件，以及查看日志时，如果我们不熟悉则会查询许久，因此在交接过程中这些也一定要记录下来，才能快速处理运维需求及故障
6.熟悉了解各个服务器的开机启动项
开机启动或者有哪些还没有加入开机启动的进程一定要注意，有时候服务器宕机了进程没有启动，就影响了业务，因此要去了解如chkconfig、/etc/rc.local里面的内容及未添加的
7.熟悉好发布流程
跟运维及其他部门了解代码发布平台、流程等，这是经常用到的，问问有无哪些需要运维经常配合的，还有一些历史遇到的一些问题
8.了解以往故障
对以前运维中发生的故障如果有记录那就最好去了解，看看当时的故障表现及处理方法，如果没有记录，也可以询问同事了解
9.对不熟悉的技术栈先浅尝
运维技术工具众多，我们一般不会每一种都了解，如果接手的刚好有较多自己不熟悉的，可以先了解，然后知道怎么重启管理进程以及查看日志排查问题即可，等有富余时间了再逐渐深入学习，这样才不会消耗大量的时间在一些不熟悉的事情上面
10.优先深入理解核心业务
要跟运维开发测试运营产品等了解哪些是非常核心的业务，是不可容忍停机停服的，这些是我们重点关注并且需要非常熟悉的，需要很仔细的对待交接，千万不能马虎
11.搞好关系
没错啦，无论是交接还是去了解学习，一定要跟同事们打好关系，可以适当的请客吃饭几次，这点非常重要，因为在交接的时候，有些坑如果对方不说，你不一定看得到。所谓害人之心不可有，防人之心不可无，大家相处融洽，其乐融融，相信在交接的时候也更愿意将经验之谈奉上，说不定还能多学习些运维知识，提升自己技术水平，还交个朋友，何乐而不为
在防止踩坑哪里都基本总结了，在新工作新环境或者交接工作中一定要放稳心态，戒躁戒急，要自信些，有难度有挑战有压力才能看到自身的不足，遇事冷静则事半功倍，工作加油!!!
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/8098.html
摘要：最近看源码发现跟之前理解有点出入，目前代码实现上跟白皮书上也有所出入，该文章需要更新修正前言作为的代表，他的设计是比较超前的，也是目前最被看好的项目之一本文从传统互联网码农思维，尝试讲述下的性能方面的设计本文只是涵盖了基础主链部分，暂不包括 最近看3.0源码发现跟之前理解有点出入，目前代码实现上跟白皮书上也有所出入，该文章需要更新修正 前言 EOS作为blockchain 3.0的代表...
摘要：架构设计实体化单元测试敏捷开发讲究要快速的修改代码，我们往往会发现，代码修改的越频繁，越多，这似乎是一个无法解决的矛盾。 本文由云+社区发表，作者：韩伟 互联网开发的核心问题 当我1999年进入互联网行业工作的时候，华为刚刚通过了著名的CMM认证。当时作为一个小程序员，非常向往业界经典的软件开发模式。因为看上去，如果企业实行了CMM，我们程序员就不用再天天为了老板一个拍脑袋的主意而加班...
摘要：架构设计实体化单元测试敏捷开发讲究要快速的修改代码，我们往往会发现，代码修改的越频繁，越多，这似乎是一个无法解决的矛盾。 本文由云+社区发表，作者：韩伟 互联网开发的核心问题 当我1999年进入互联网行业工作的时候，华为刚刚通过了著名的CMM认证。当时作为一个小程序员，非常向往业界经典的软件开发模式。因为看上去，如果企业实行了CMM，我们程序员就不用再天天为了老板一个拍脑袋的主意而加班...
摘要：架构设计实体化单元测试敏捷开发讲究要快速的修改代码，我们往往会发现，代码修改的越频繁，越多，这似乎是一个无法解决的矛盾。 本文由云+社区发表，作者：韩伟 互联网开发的核心问题 当我1999年进入互联网行业工作的时候，华为刚刚通过了著名的CMM认证。当时作为一个小程序员，非常向往业界经典的软件开发模式。因为看上去，如果企业实行了CMM，我们程序员就不用再天天为了老板一个拍脑袋的主意而加班...
摘要：公司规模人以上全国强。从总部刚交接过来的代码。由于没有交接，没有任何相关文档，花了一天确定代码丢失。删掉这两个文件上线总计花了天时间。公司规模 3000人以上 全国500强。 从总部刚交接过来的代码。 1、找不到代码。代码部分丢失。（由于没有交接，没有任何相关文档，花了一天确定代码丢失。从总部找到部分代码） 2、查找测试库，发现测试库不行了，寻求服务器运维组帮忙，，首先开通了 外网访问的安全...
阅读 1770·2021-11-24 09:39
阅读 2560·2021-07-29 13:49
阅读 2118·2019-08-29 14:15
阅读 2109·2019-08-29 12:40
阅读 1750·2019-08-28 17:46
阅读 3202·2019-08-26 13:42
阅读 490·2019-08-26 12:13
阅读 1899·2019-08-26 11:41
