我们那么努力，为什么总感觉过得那么憋屈、苦闷？做的事情那么多，为什么业务部门、直接领导和公司貌似都那么不领情？怎么做才能自己更加开心些？前段时间 有位IT大佬在网络上发声，我这么有钱，为什么不幸福？诚然，有钱是幸福的最重要条件之一，但有钱就一定幸福么？真的是充分必要条件？当然更悲催的是运维 行当，技术好是被认可（幸福）的最重要条件，但技术再好，外部门不说咱们“坏话”，已经是很不错的了。
什么是高效运维
我们收集了一些来自外部门对运维的印（tou）象（su），如下图所示。其中，大家看是否也多少有自己的影子？
往往看自己都很美，但从外部门来看，槽点多到乃至无力吐槽。首先，做事情不专业，人为事故多（更多是低级的人为事故）；很多时候，都是我们业务部门告诉运 维，运维才知道发生故障了，而且故障解决时间过长；做个调试，老超出调试时间，超时也不说，是不是完成了也不知会一声；部门内老玩踢皮球的游戏，做 个需求，老让我挨个找人；申请个服务器，老费劲了，扔我一个申请表，当自己是衙门呢？或者扔我一个技术文档，我哪看得懂？
专业、热情、方便、快，这是为根治上述各种疑难杂症，经多年经验，得出的高效运维七字诀。用一个简单的公式来表示高效和专业的关系：专业是高效的基石，否则无从谈起高效与否，而技术是专业的基石。但这恰恰也是运维技术人员的误区所在，误以为，技术比较强，就足够了，并因此而忽视其他重要方面。
实际上，对外部门而言，运维是个黑盒子，是一个输入输出的关系：外部门提出需求，运维给出结果：完成、或未完成。本质上而言，外部门不关心（也无法关心）我们采用什么技术来实现的，只关心是否如期完成。
合理的流程规范，就像血液，能让部门稳定而高效的运转，大家都觉得开心，这也是专业与否的重要组成部分。但如果希望做到高效运维，良好的客户界面、合适的方法技巧，也非常有必要。这就像网站的UI，给人感觉舒服了，后面很多事情也能轻松愉快、顺理成章地进行。
为什么难以做到高效运维
做不到高效运维，公司和业务部门不满意，上级领导不满意，自己也不满意，原因很多，主要有：糟糕的分工及连环反应；做vs说的困境；资源错配。
如何做到高效运维
明确分工/职责
美国著名管理学者史蒂芬·柯维在畅销书《高效能人士的七个习惯》中提出了产出/产能平衡原则。想多产出，先得扩大产能。想金鸡多下蛋，就不能杀鸡取卵。那么对于高效运维而言，产能是什么呢？包括三部分：1）框架，即合理的分工/职责/KPI，抱歉我提到了KPI，多么让人如此爱恨交织的词语；2）血液，即专业的流程/规范；3）界面，即良好的服务意识/技巧。这些投入足够多，才会得到心仪的产出——高效运维。在贯彻实施这些一段时间后，外部门会诧异的感觉：哟，怎么运维变化这么大。虽然他们不知道原因，但我们可以微微一笑，呵呵。
具体到运维部门而言，我们的分工，区别于内网IT部。一个是服务外部客户，一个是服务内部客户，差别还是蛮大的。根据部门分工，拆解出各个小组的分工，再落实到每个员工头上。有章法，大家也觉得舒心。
运维是支持部门，成本中心，难以产生利润。所以其中重要的考核指标其实是客户满意度，请相关业务部门给运维同学打分，运维内部根据分工，也可以相互打分，这对应着外部满意度和内部满意度。KPI虽然令人不舒服，但总的来说，还是有存在的合理性。
技术的专业化
优化监控系统；减少人为事故；运维自动化；合理优化架构；代码持续部署。管理的专业化
管理上的专业化运维，甚至包括调试通报和故障通报，都很有说法。系统运行一段时间后趋于稳定，调试/更新就变成了故障的主要来源之一，怎么让调试少出人为事故，顺利如期的完成？这是个技术活。运维345法则：故障通报是细究故障的不二法门，一次长时间的故障，往往有很多细节可以推敲，我们总结出运维345法则。3是指故障时长被分成三部分，4是指对应的四个故障时刻点，5是指在这个过程中我们可以做的五件事。这样，我们就可以有的放矢地进行优化解决了。不要让流程吞噬责任：流程规范是很好，不可或缺，好处谁都晓得。只是，流程有时会成为挡箭牌，会让人变得本位，不愿担当，也不愿从事个人职责之外的事情。这其实是错误的、短视的，“害人害己”的。如果真的出了一个非常严重的故障，个人就能“出污泥而不染”么？没戏。如果是顶级故障，老板想的甚至是把整个运维部门端掉，皮之不存、毛将焉附？
良好的客户界面
伸手不打笑脸人。合适的言语表达，可以大事化小、小事化了，反之亦然。只是对做技术的运维同学而言，这是很不容易的事情，甚至有人宁愿多加班，也不去和人沟通。但，工作的要求有时往往需要善于表达，其实也可以换个角度想，把良好的沟通当做一门技术来攻克，如何？
运维很苦闷，让苦闷的人变得更苦闷。但不管怎样，也是一门技术。这年头，有门手艺，虽然发达需良机，但至少生存无忧。话说回来，哪行都不容易。
扫描二维码
关注昊云订阅号
