运维视角 -- 献给开发兼做运维的童鞋

作者：刘煦萍

近期在团队中发现一些有意思的现象，讲之前先描述一下背景：此项目是属于存储类项目，由于项目还不够稳定，会经常有一些小改动，所以线上操作的频率基本一月至少两次，同时由于前专职运维人员离职，一时招不到合适人员，决定开发接手运维工作。下面是上线过程中出现的三组现象（图一紫色部分是不同之处）：

A：上线前的流程/过程是：开发完成，自测、单测达标 --> 功能QA测试通过 --> 性能QA测试通过 --> 上线步骤评审通过 --> 演练通过 --> 领导审批  --> 上线

结果：上线过程出现问题，由于处理不够迅速，整个恢复过程花费了将近2小时，结果是：上线失败，领导对整个处理过程不太满意（因为我们期望是15分钟内完成整个的回滚操作）。

B：与A过程基本一致，不同点：

在上线时多了一位经验丰富的运维人员（此人也是这个team新上任的负责人）

结果：上线过程中出现问题，但处理迅速且第一时间反馈领导，虽然最终上线结果仍是未成功，但领导对处理的结果还算满意；

C：与A过程基本一致，不同点：

1.  在上线步骤评审时邀请了一位‘位高权重’的领导一起参与；

2.  在上线时多了一位经验丰富的运维人员（此人也是这个team新上任的负责人）；

       结果：上线顺利成功！

图一

不禁想到难道领导的力量这么伟大？还是说偶然？还是说前面上线运气不好、前面上线的复杂度高…

不过具体问题是要case by case的分析，而且领导人在其中的作用也是毋庸置疑的，但他们是真正的原因吗？笔者领悟到更多的是：态度，对此事的重视、谨慎、细心的程度，或者说是‘上线精神’！为什么这么说？

 他们不是神，如果程序有潜在的坑，现场他们也未必能解决，即使能解决也不会直接当场修改上线；

那么简单分析一下后面成功的可能原因：

1.  位高权重的领导来了，意识上告诉大家：哎呀，领导都这么关注，此事看来很重要！上线步骤、测试、演练等各个环节大家都非常小心谨慎，尽可能的发现问题，不漏过任何可能的潜在问题，发现、定位并解决他们！

2.  有经验的运维人员在场，突发情况能处理的很好（这里讲的不是bug问题），其实是说处理线上突发事件的顺序、流程；

我们不能保证每次上线都不出问题，但是我们要保证的是出了问题能用正确的方式和思维快速的处理问题！

为什么说此文是献给那些开发做运维的童鞋，因为开发和运维看问题侧重点不同，开发会比较注重写代码、查问题、找root cause，而且开发可能也应该是尽量自信的：只要你能想得到，我就能用键盘给你敲出来！我能的！我开发的东西肯定赞！…而上线时需要切换角色 — 运维：运维会站在客户的角度看问题，尽可能的减少对客户的影响，会质疑每一步、确认每一个操作都是正确并且敲下去后是没有问题的！有任何蛛丝马迹都不会放过！如有问题立马停止和上报！因为他会意识到，我做的每一步都是在线上操作，就好比医生在手术台上给病人动刀子，一有闪失，后果不堪设想。

所以让开发做运维，一定要让他们培养和建立一种意识：上线精神！而且这种‘软性’的东西，不是一两下功夫就能植入大脑的。

那这里所说的精神到底是什么呢？我的理解为：

1.  原则的事情不能触碰！

流量最低时间点上线原则。此时用户量最小意味着会受影响的用户范围也就越小！越是风险系数较高的上线更是要选择最低谷的时间点来操作，而这往往也是半夜的时候，我们项目的最低点是半夜2点钟，为尽量减少影响范围，我们通常会选择用辛勤付出来降低风险；

一次上线不允许软硬件一起升，并且不允许太多模块一起升，一次上线内容太多风险就会越大，出问题时的定位、回滚也会越复杂；

上线过程中出现问题及时上报！一方面，领导需要第一时间知道，如果领导在不知情的情况下，接到上级或者合作方投诉电话，会比较难处理；另一方面，有问题及时上报，让领导来决定怎么做，出了问题他来背黑锅更合适！我们这里不是推卸责任，而是让更合适的人来做决定！

节假日前不要做上线操作！一方面，马上要放假了，大家的心已经飞走了，质量难保障；另一方面，放假前后也是各产品搞活动的好时期，更要确保稳定！此外，万一放假期间出了问题，值班人员有限，定位问题和解决速度都会大打折扣。

2.  万事谨慎，线上操作无小事！打有准备的仗！

有数据统计表明通常有60%的问题是事后发现的，也就是说我们有60%的提升空间（图二），而这些问题的成本会因所处的阶段不同（设计阶段、开发阶段、测试阶段、线上）成指数级增长，图三是曾经所在一个软件项目的问题成本分布情况。

图二

图三

所以开发过程中的各个环节我们都需要认真把关，特别是上线前的这道关。

上线的每一个操作都要确认批准后才能执行，这里的操作是指会引起改动的，当然那些cat查看类不会引起改动的命令就排除在外了；

审批流程也需要明确出来，具体的流程这里就不详说了，需要确认的是这个审批流程一定是清晰明确的，而且责任到人！如果形同虚设，责任不到位，那么就很难起到效果，也就无法保证上线质量！

而所有上线操作，请提前一天准备好就绪工作，不要有临时抱佛脚的心态！准备好需要的脚本，测试通过，演练通过，回滚方案/脚本也准备好并经过验证。

应急预案，因为在上线过程中难免会遇到突发情况，如果不幸遇到问题，可能会大脑缺氧、冒冷汗、紧张，正常思考的能力或许都暂时失去了，此时让你临时想解决方案，一个字：难！但如果是提前准备好的，顺手拈来，在关键时刻露一手，那才是展示咱能力的时刻！到时候不要偷着笑噢~ 

3.  还想提一小点：重视上线前的演练！

往往很多人对演练不重视，这当然也跟现实情况有关，因为演练环境毕竟不是线上环境，有时候没那么真实！而且他不是必选项（因为有些情况没法在演练环境中操作），并且有人甚至可能怀有这种心态：前面单测、功能、性能QA都验证没有问题，而且上线步骤大家都评审过，都这么步步到位了，不会有啥问题的…，然后就草草演练，没有很慎重的把演练当成上线前的实战！

而事实是，在碰到的为数不多的上线问题中，就有因演练不够仔细而将问题漏到上线时才发现的情况，所以在既定的情况下，在演练环境满足的情况下，应该提高重视度，把演练就当做是在真的上线，认真check每一步！

当然项目类型不同，前面说到的这些点也会千差万别，每个项目还是要结合自己的实际情况进行定制化，但对上线的态度应该是明确的！俗话说台上一分钟台下十年功！上线精神其实要从头到尾的贯彻，才能确保这一分钟的成功，也只有这一分钟的成功，前面的努力才没有白费！而这一分钟的成本不光是前面那么多环节的步步到位，还有各路人马大冬天半夜两点温暖被窝爬起来的勇气啊！

网易云大礼包：https://www.163yun.com/gift

本文来自网易实践者社区，经作者刘煦萍授权发布