【必看】谈谈变更过程中的运维意识
运维，或许是一个在 IT 技术岗中很尴尬的职位。其一，许多应届生都未曾接触过，对工作的职能界定非常模糊；其二，很多其他技术岗的往届生会觉得，“卧槽，这么 low 逼，只会重启推配置做发布”；其三，正在从事运维岗的往届生会觉得自己在公司的 KPI 很难体现。我在从事运维工作的前 2 年，也总是问自己：WTF，到底我的存在有啥意义？
运维并不是一个可以从校园里可以培养出来的职业，它完全需要从实践中去体会。当然，今天写这篇不是为了想告诉大家这两年我体会到的所谓运维存在的意义，而是就一件最近工作上的一件小事和大家谈谈生产线应该具备的运维意识。
一件小事以及引发的思考
事情呢是酱紫的，看到工作群有一个小伙A说需要重启服务器重做 raid，原话大概是：
127.0.0.1 重做raid，告警忽略@同事B @同事C
本来这个事情貌似没啥问题，鉴于近期公司出现了多次因生产故障产生的资损事件，我就单独找他聊了下，看似风平浪静的事情其实是波涛汹涌啊！
运维需要清楚“变更的需求背景”
我：A，你了解变更背景吗？
A：因为X哥告诉我需要重做 raid。
我：为什么需要重做 raid？
A：因为需要给线上生产环境部署一套 FTP，做 raid5，而原来是 none-raid。
这一点上，A同学是可以回答的上来的，但是对于接到任务之后，就不假思索的去做，是很可怕的，因为你并不知道做这件事情的意义。每一次变更就和开车并道一样，并一次就多一分产生车祸的风险，需要清楚衡量变更的意义和价值，权衡风险和价值的轻重，才可以对此次变更进行有效的精力投入评估。BTW，我们必须要问自己一句：这个变更一定要做吗，是否值得对需求方提出挑战？
车祸猛如虎变更也一样
运维需要清楚“变更的合适时间”
我：你决定什么时候去做？
A：接到任务就直接想去做了。
我：下午 2 ~ 3 点有方案演示，万一你产生了误操作，导致演示失败，客户会如何？
A：我没有想到这一点。假设每次变更都有产生故障的可能性，那么就必须要确认清楚最佳变更时间。有几个原则：
a. 避开本产品线业务高峰期、关键期；
b. 和同产品线的其他变更互斥；
c. 和相关产品线的其他变更互斥。
这一点上，同学A由于信息渠道窄，并没有接到业务部门对产品演示的通告，违反了原则a。怎么规避掉这个风险呢？就是把变更看成一个项目进行推进，每个环节的进展需要同步告知干系人，干系人负责进行风险评估。
运维需要成为“变更的项目经理”
我：你有清楚了解这台服务器之前的情况吗？
A：没有，我没有想到。
我：你知道如果之前这台服务器上有运行核心服务的进程没有下线，会造成什么后果吗？
A：X哥说这台机器是新装机之前没有服务的。
我：运维需要做最后一道防线，要具备质疑的精神，X哥说的不一定是『真』的，你需要再确认下。
打个比方，消防员在冲进火场的时候，需要确认是否仍有可能的爆炸源，否则被炸因公殉职也是自己的责任。运维在职能上和消防员类似，出现故障（火灾）的时候去歼灭故障源（火源），在执行变更的时候也需要多留一个心眼，反复确认上下游干系业务，才能进行变更规划（其实故障处理也是一次紧急变更）。任何一次变更都要当做一个项目进行运作，清楚干系人，把控风险，制定合理的步骤和时间节点，我们要把他看成一个持续若干天的项目推进，也就是说变更其实在接到需求的那一刻就开始了。
运维需要“遵循变更流程”
我：为什么要先做 raid 再告诉同事忽略报警？
A：这样也没什么问题吗，不就是骚扰大家一下，我也提醒了。
我：为什么不走流程，先关报警再变更？
A：没必要吧，SA每天这么多操作都需要这样？
我：不关注细节，终会酿成大错，当年我因为没有关注流程出现过600个节点同时宕机的误操作。假设你的报警淹没了当时的其他重要报警，我们晚发现核心业务故障5分钟，你知道损失是多少吗？
A：……（惭愧）运维，或许是一个在 IT 技术岗中很尴尬的职位。其一，许多应届生都未曾接触过，对工作的职能界定非常模糊；其二，很多其他技术岗的往届生会觉得，“卧槽，这么 low 逼，只会重启推配置做发布”；其三，正在从事运维岗的往届生会觉得自己在公司的 KPI 很难体现。我在从事运维工作的前 2 年，也总是问自己：WTF，到底我的存在有啥意义？
运维并不是一个可以从校园里可以培养出来的职业，它完全需要从实践中去体会。当然，今天写这篇不是为了想告诉大家这两年我体会到的所谓运维存在的意义，而是就一件最近工作上的一件小事和大家谈谈生产线应该具备的运维意识。
一件小事以及引发的思考
事情呢是酱紫的，看到工作群有一个小伙A说需要重启服务器重做 raid，原话大概是：
127.0.0.1 重做raid，告警忽略@同事B @同事C
本来这个事情貌似没啥问题，鉴于近期公司出现了多次因生产故障产生的资损事件，我就单独找他聊了下，看似风平浪静的事情其实是波涛汹涌啊！
运维需要清楚“变更的需求背景”
我：A，你了解变更背景吗？
A：因为X哥告诉我需要重做 raid。
我：为什么需要重做 raid？
A：因为需要给线上生产环境部署一套 FTP，做 raid5，而原来是 none-raid。这一点上，A同学是可以回答的上来的，但是对于接到任务之后，就不假思索的去做，是很可怕的，因为你并不知道做这件事情的意义。每一次变更就和开车并道一样，并一次就多一分产生车祸的风险，需要清楚衡量变更的意义和价值，权衡风险和价值的轻重，才可以对此次变更进行有效的精力投入评估。BTW，我们必须要问自己一句：这个变更一定要做吗，是否值得对需求方提出挑战？
车祸猛如虎变更也一样
运维需要清楚“变更的合适时间”
我：你决定什么时候去做？
A：接到任务就直接想去做了。
我：下午 2 ~ 3 点有方案演示，万一你产生了误操作，导致演示失败，客户会如何？
A：我没有想到这一点。假设每次变更都有产生故障的可能性，那么就必须要确认清楚最佳变更时间。有几个原则：
a. 避开本产品线业务高峰期、关键期；
b. 和同产品线的其他变更互斥；
c. 和相关产品线的其他变更互斥。
这一点上，同学A由于信息渠道窄，并没有接到业务部门对产品演示的通告，违反了原则a。怎么规避掉这个风险呢？就是把变更看成一个项目进行推进，每个环节的进展需要同步告知干系人，干系人负责进行风险评估。
运维需要成为“变更的项目经理”
我：你有清楚了解这台服务器之前的情况吗？
A：没有，我没有想到。
我：你知道如果之前这台服务器上有运行核心服务的进程没有下线，会造成什么后果吗？
A：X哥说这台机器是新装机之前没有服务的。
我：运维需要做最后一道防线，要具备质疑的精神，X哥说的不一定是『真』的，你需要再确认下。打个比方，消防员在冲进火场的时候，需要确认是否仍有可能的爆炸源，否则被炸因公殉职也是自己的责任。运维在职能上和消防员类似，出现故障（火灾）的时候去歼灭故障源（火源），在执行变更的时候也需要多留一个心眼，反复确认上下游干系业务，才能进行变更规划（其实故障处理也是一次紧急变更）。任何一次变更都要当做一个项目进行运作，清楚干系人，把控风险，制定合理的步骤和时间节点，我们要把他看成一个持续若干天的项目推进，也就是说变更其实在接到需求的那一刻就开始了。
运维需要“遵循变更流程”
我：为什么要先做 raid 再告诉同事忽略报警？
A：这样也没什么问题吗，不就是骚扰大家一下，我也提醒了。
我：为什么不走流程，先关报警再变更？
A：没必要吧，SA每天这么多操作都需要这样？
我：不关注细节，终会酿成大错，当年我因为没有关注流程出现过600个节点同时宕机的误操作。假设你的报警淹没了当时的其他重要报警，我们晚发现核心业务故障5分钟，你知道损失是多少吗？
A：……（惭愧）变更的大致流程是：需求确认 -> 干系业务/人确定 -> 方案探讨 -> 方案确立&时间确立 -> 变更单撰写 -> 变更单 review -> 审批报备 -> 变更通告 -> 方案实施 -> 方案效果反馈 (-> 回滚方案)，可酌情进行步骤删减。遵循变更流程的主要好处是，首先，你可以在整理变更步骤的时候仔细思考每一处风险点，多次变更之后可以固化下来风险相对较小的标准化文档，后续可以把重复操作自动化。其次，风险均摊及最小化，方案是大家探讨后确定的，时间是大家商量后认可的，流程是经过审批报备的。真的，如果把类似的流程贯彻下去，因为变更产生故障的概率会大大降低。现在成熟的公司运维团队，都已经把类似的流程固化到运维平台里了，但是又有多少团队的负责人真正在遵循，而不是随便审批了事呢？不要和我谈业务压力有多大，不要和我谈缺人手，原则是不能却步的，否则捡了芝麻丢了西瓜。
一句真理
这么小的一个变更事件，我们可从中总结出那么多的经验，可见运维是一个全局操盘手，心不细真的不行。有一句话是之前我在阿里一直铭记在心的，双手奉上给各位同行：对生产环境要有敬畏之心。下图是我们以前做关键变更之前必须要朝拜的一张：
变更的大致流程是：需求确认 -> 干系业务/人确定 -> 方案探讨 -> 方案确立&时间确立 -> 变更单撰写 -> 变更单 review -> 审批报备 -> 变更通告 -> 方案实施 -> 方案效果反馈 (-> 回滚方案)，可酌情进行步骤删减。遵循变更流程的主要好处是，首先，你可以在整理变更步骤的时候仔细思考每一处风险点，多次变更之后可以固化下来风险相对较小的标准化文档，后续可以把重复操作自动化。其次，风险均摊及最小化，方案是大家探讨后确定的，时间是大家商量后认可的，流程是经过审批报备的。真的，如果把类似的流程贯彻下去，因为变更产生故障的概率会大大降低。现在成熟的公司运维团队，都已经把类似的流程固化到运维平台里了，但是又有多少团队的负责人真正在遵循，而不是随便审批了事呢？不要和我谈业务压力有多大，不要和我谈缺人手，原则是不能却步的，否则捡了芝麻丢了西瓜。
一句真理
这么小的一个变更事件，我们可从中总结出那么多的经验，可见运维是一个全局操盘手，心不细真的不行。有一句话是之前我在阿里一直铭记在心的，双手奉上给各位同行：对生产环境要有敬畏之心。下图是我们以前做关键变更之前必须要朝拜的一张：
【必看】谈谈变更过程中的运维意识相关推荐
- IT运维人员必看！超全信息化建设之运维资料
随着IT建设的不断深入和完善,计算机硬软件系统的运行维护已经成为了各行各业各单位领导和信息服务部门普遍关注和不堪重负的问题,据统计,IT运维服务占到IT部门工作量的80%左右.IT运维普遍存在以下现象 ...
- 【必看】做了3年运维却不涨薪？那是你还没get这个技能
做了多年运维工作的你是否有以下问题: N久不涨的薪资,无法突破15k+的薪资瓶颈 有多年运维经验,却对后续拓展广度 or 深度迷茫 新人不断涌入,不懂如何提升自身竞争力? 而且在你的工作中还总是会出现 ...
- 织云 Metis：看腾讯怎么做智能运维
欢迎大家前往腾讯云+社区,获取更多腾讯海量技术实践干货哦~ 作为企业智能运维门户,业界早已关注织云的智能运维体系.我们很荣幸地宣布织云 Metis 智能运维体系正式发布.自此,织云家族已发布:织云企业 ...
- 魔爪稳定器服务器连不上怎么办,新手必看！说不定你也中招的稳定器常见错误操作...
原标题:新手必看!说不定你也中招的稳定器常见错误操作 最近宇哥在后台收到很多新入手稳定器的同学提出的各种使用疑惑,比如刚收到一条:"稳定器一开机就抖个不停,装手机的时候还被打了一下.&quo ...
- 计算机中文件访问时间是什么情况,【反计算机取证必看】Windows系统中文件时间属性的变化及影响因素.pdf...
[反计算机取证必看]Windows系统中文件时间属性的变化及影响因素.pdf ·技术交流· Windows系统中文件时间属性的变化及影响因素 滕冲1,方靖然2,张国臣3(1．中国人民公安大学,北京 3 ...
- 一款新游戏上线流程中，运维需要注意的事项
一款新游戏上线流程中,运维需要做的事情往大了讲,其实没有多少,无非就是前期和开发讨论合适的架构,准备测试环境和正式环境各种资源等,后期为游戏的稳定运行保驾护航.但是往小了看,事情其实复杂繁多,这里做一 ...
- 工作中涉及运维知识点的汇总
对工作中常见运维知识点的一个简单汇总 0)设置阿里云pip源,加速pip更新速度 mkdir ~/.pip #创建文件夹 vi ~/.pip/pip.conf #添加如下内容 [global] ind ...
- acm新手小白必看系列之（1）——二维数组及结构体精讲附带例题
*acm新手小白必看系列之(1)--二维数组及结构体 ** c++准备工作** (可能小白像我一样也是学习的c语言) 万能头文件,放在第一行 #include<bits/stdc++.h> ...
- 深圳云计算学习：运维工程师中桌面运维需要会哪些技能？
深圳云计算学习:运维工程师中桌面运维需要会哪些技能? 桌面运维岗位职责: 1.公司计算机网络合理规划和配置,负责计算机网络.信息管理及应用系统.数据库以及办公设备的管理,保证办公设施和服务器正常工作: ...
最新文章
- Kubuntu 9.10设置支持文件分级的方法
- 京东受冤但不屈，售后服务隐现断崖危机
- Silverlight C# 游戏开发：Flyer09扇动翅膀的蝴蝶
- arcgis 圈选获取图层下点位_ArcGIS小技巧——提取面要素的质心点
- delphi 最全日期格式_DateUtils时间单元说明
- linux添加svn分支,TortoiseSVN 分支创建与合并
- Python标准库shutil中rmtree()使用回调函数
- asp 图片上传源码 【亲测】
- linux系统安装klocwork,linux下klocwork的使用
- STM32从设置IO输入上下拉到寄存器GPIOx_BSRR、GPIOx_BRR
- duilib加载xml以及资源文件的路径问题
- android 谷歌地图离线访问,谷歌升级Android版地图应用 支持离线使用
- SoundPool详解
- 解除网页复制限制的Chrome插件-SuperCopy
- ardupilot rover ardurover 电机相关源码 PreArm servo function 33 unassigned
- 机器学习学习笔记（3）——量纲与无量纲，标准化、归一化、正则化
- 一文读懂css的相对定位【relative position】以及相对定位为什么要设置偏移量？
- Linux(centos7) 安装配置gitlab-runner
- 文盘Rust——领域交互模式如何实现
- tim工具包-MyMath 计算工具