如何才能高效做运维？

很多公司整天研究，如何才能提高运维效率，达到高效运维呢？与人打交道远没有与机器打交道高效。每一个人都有每一个人的理由，运维事件难以推进！今天优秀的运维管理系统云雀运维就和里聊聊如何高效运维的话题！
01、什么是高效运维
我们收集了一些来自外部门对运维的印(tou)象(su)，如下图所示。其中，大家看是否也多少有自己的影子？

往往看自己都很美，但从外部门来看，槽点多到乃至无力吐槽。首先，做事情不专业，人为事故多(更多是低级的人为事故)；很多时候，都是我们业务部门告诉运维，运维才知道发生故障了，而且故障解决时间过长；做个调试，老超出调试时间，超时也不说，是不是完成了也不知会一声；部门内老玩踢皮球的游戏，做个需求，要挨个找人；申请个服务器，更费劲了，扔一个申请表，或者扔一个技术文档，哪看得懂？

实际上，对外部门而言，运维是个黑盒子，是一个输入输出的关系：外部门提出需求，运维给出结果：完成、或未完成。本质上而言，外部门不关心(也无法关心)采用什么技术来实现的，只关心是否如期完成。合理的流程规范，就像血液，能让部门稳定而高效的运转，大家都觉得开心，这也是专业与否的重要组成部分。但如果希望做到高效运维，良好的客户界面、合适的方法技巧，也非常有必要。这就像网站的UI，给人感觉舒服了，后面很多事情也能轻松愉快、顺理成章地进行。
02、为什么难以做到高效运维
做不到高效运维，公司和业务部门不满意，上级领导不满意，自己也不满意。原因很多，从管理者和员工角度分别来讲。
糟糕的分工及连环反应
发生在中小公司的糟糕情况，往往从不明确的分工，开始悲剧之旅。公司业务扩大很多后，如果运维组织结构不随之而变，分工不明确，就会发现大家都在疲于奔命，什么都会的结果就是什么都不精。在运维技术如此庞杂的今天，就是把人活活的架在火上烤。这样引发的是多米诺骨牌效应：分工不明确—>职责不清楚—>考核不量化—>流程不合理—>缺规范、少文档。

03、如何做到高效运维
高效运维从来不是一个简单的事情，需要多方面共同努力来实现，本文先择其要点简述之，以后专栏系列文章会有更多深入阐述。
明确分工/职责
具体到运维部门而言，我们的分工，区别于内网IT部。一个是服务外部客户，一个是服务内部客户，差别还是蛮大的。根据部门分工，拆解出各个小组的分工，再落实到每个员工头上。有章法，大家也觉得舒心。运维是支持部门，成本中心，难以产生利润。所以其中重要的考核指标其实是客户满意度，请相关业务部门给运维同学打分，运维内部根据分工，也可以相互打分，这对应着外部满意度和内部满意度。KPI虽然令人不舒服，但总的来说，还是有存在的合理性。

技术的专业化
1：优化监控系统
谁来监控监控系统？怎么保证比业务部门先发现问题？是否需要添加业务监控？是否需要文件监控？短信报警、邮件报警是否足够？……监控是门学问，是专业运维的入口。展开说可以很大篇幅，先抛砖引玉，提出这些问题。实际上，对于资深、聪明的运维朋友，看到问题，就已经有了自己的答案。
2：减少人为事故
人为事故是运维最头疼、最不专业的事情之一。例如网站运维中，如果每次更新都需要登录服务器……所以可以用类似Jenkins的工具，实现Web更新，这样，除非重大更新(包括数据库更新)，否则都只需要点点鼠标即可。甚至，可以把网站更新外包回开发部门，这样还能减少运维操作带来的沟通成本、时间成本。
3：运维自动化
运维自动化是个大课题，网络上的讨论也很多。建议选择合适自己的方式、方法。
4：合理优化架构
近几年国内优秀的开源软件层出不穷，设计和优化架构，很多时候并不是非得自己从零起步来搞。例如Redis，以其高效、稳定，已成为缓存系统的最好选择之一，但Redis单实例的支撑能力有限，目前Redis集群的实现，大多采用Twemproxy，但使用起来老感觉有些美中不足，那么，有没有一个取而代之的产品？
管理的专业化
管理上的专业化运维，甚至包括调试通报和故障通报，都很有说法。系统运行一段时间后趋于稳定，调试/更新就变成了故障的主要来源之一，怎么让调试少出人为事故，顺利如期的完成？这是个技术活。