运维可能是IT技术岗位的一个尴尬位置。第一，很多应届毕业生从来没有接触过，工作职能的定义非常模糊；第二，很多其他技术岗位的前同学会觉得，“卧槽，我好low，只会重启推送配置发布”；第三，往届学员从事运维岗位，KPI难以在公司体现。在运维工作的前两年，我一直在问自己：卧槽，我存在的意义是什么？WTF运维不是校园里就能培养出来的职业，需要从实践中积累经验。当然，我今天写这篇文章，并不是要告诉大家我这两年所经历的所谓运维的意义，而是要和大家谈谈产线应该具备的运维意识最近工作中发生了一件小事。一件小事和引起它的思想是如此的红色。看到工作组有个小A说要重启服务器，重做raid。原话大概是：“127.0.0.1重做raid，忽略报警@朋友B@朋友C』本来这件事好像没什么问题，鉴于公司经历了多次最近因为生产故障造成的资金损失，单独跟他聊过。看似平静的事情，其实是波涛汹涌的！运维需要搞清楚【改变需求的背景】这时候A同学可以回答，但是接到任务后不假思索的去做是很可怕的，因为你不知道做的意义。每一次改变都和平行行驶一样，每一次都增加了车祸的风险。必须清楚衡量变革的意义和价值，权衡风险和价值，然后再有效评估变革。BTW，我们要问问自己：这个变革有必要吗？是否值得挑战需求方？车祸一样凶猛老虎的变化因此，有必要确认最佳更换时间。有几个原则：a．避开本产品线的业务高峰期和关键期；b.与同一产品线的其他变化互斥；C。与相关产品线的其他变化互斥。对此，A同学由于信息渠道狭窄，没有收到业务部门的产品演示通知，违反了原则a。如何规避这种风险？就是把变革当作一个项目来推进。每个环节的进展需要同时通知利益相关者，利益相关者负责风险评估。运维需要成为【转项目经理】。例如，当消防员冲入火场时，需要确认是否还有可能的爆炸源。否则，因公殉职是他们自己的责任。运维在职能上类似于消防员。当发生故障（火灾）时，需要排除故障源（火源）。故障处理也是紧急变更）。任何变革都必须作为一个项目来运作，明确利益相关者，控制风险，并制定合理的步骤和时间节点。我们必须把它看成一个持续几天的项目，这意味着变革实际上是在接受需求开始的那一刻。运维就像消防员的运维需求【遵循变更流程】变更的大致流程是：需求确认->相关业务/人员确定->方案讨论->方案立项&时间立项->立项变更单->变更单审核->审批备案->变更通知->计划实施->反馈计划效果（->回滚计划），步骤可酌情删除。遵循变更流程的主要好处在于，首先，您可以在梳理变更步骤时仔细考虑每个风险点。多次修改后，可以固化一个风险相对较低的标准化文档，然后可以将重复的操作自动化。其次，风险分担和最小化，方案经讨论确定，时间经讨论确定，过程经批准上报。真的，如果实施类似的流程，因变更而失败的概率会大大降低。现在成熟的公司运维团队已经将类似的流程固化到运维平台中，但是有多少组长是真正在跟着他们走的，而不是只是批复的？不要跟我说商业压力有多大，别跟我说人手不足，原则是不能吓倒的，不然捡芝麻丢了西瓜。我们可以从这么小的变化事件中总结出如此多的经验作为一个道理。可见，运维是全局操盘手，真的不可能大意。之前在阿里有一句话我一直牢记在心，双手奉上给所有同事：敬畏生产环境。
