这么多运维，有几个开心？我们那么努力，为什么总是那么委屈，那么压抑呢？这么多事情要做，为什么业务部门、直属领导、公司显得如此忘恩负义？你怎样才能让自己更快乐？本栏目的主线其实是一个运维人员十年的成长史，从菜鸟到运维总监。但不是基础技术教学，也不会太深入地涉及运维技术的某一方面。更多的应用技巧、实践经验和案例分析。专栏系列文章包括作者在运维各个细分领域的技术经历和个人成长。因此，也可以成为广大运维朋友的参考书，陪伴大家从初级运维成长为高级技术运维管理人才。技术专栏有必要这么乖吗？我们的栏目尽量用更轻松活泼的文字，慢慢的，像老朋友一样，轻松愉快，希望能给你带来收获和启发。前段时间，一个IT大亨在网上说，我这么有钱，为什么不开心？诚然，有钱是幸福最重要的条件之一，但是有钱就一定要幸福吗？它真的是充分必要条件吗？当然更悲惨的是运维行业。技术好是被认可（幸福）最重要的条件，但技术再好，只要外界不说我们的“坏话”，就已经很好了。1、什么是高效运维我们从外部部门收集了一些运维（su）的感想（tou），如下图。其中，你觉得有没有你自己的影子？你常常自认为很漂亮，但从外表看，缺陷多到无可抱怨。首先，事情不专业，人为事故多（多为低级人为事故）；很多时候，我们业务部门告诉运维，运维知道出现了故障，解决故障的时间太长了；做一个调试，总是超过调试时间，什么时候超时我就不说了。不知道完成没有；部门总是踢球，提出要求，总是让我一个一个找人；申请服务器，太费劲了，给我一个吧。我怎样才能理解申请表？或者扔给我一份技术文档？专业、热情、方便、快捷。这是为了治疗上述疑难杂症。经过多年的自我处理和综合经验，高效运维的七字诀。我们使用一个简单的公式来建立高效和专业的关系。专业是高效率的基石，否则谈不上高效率，而技术是专业的基石。但这恰恰是运维人员的误区所在。他们错误地认为技术更强就够了，因此忽略了其他重要方面。其实对于外部部门来说，运维是一个黑盒子，是一种输入输出关系：外部部门提出需求，运维给出结果：完成或未完成。本质上，外部部门并不关心（也不可能关心）我们用什么技术来实现，只关心是否如期完成。合理的流程规范，就像血液一样，可以让部门稳定高效地运行，让大家心情愉快，这也是敬业精神的重要组成部分。但是想要实现高效的运维，良好的客户界面和合适的方法技巧也是非常必要的。这就像一个网站的用户界面。当人们感到舒适时，许多事情就可以轻松、愉快、顺理成章地进行。2、为什么难以实现高效运维？如果不能做到高效运维，公司和业务部门不满意，上级领导不满意，我也不满意。原因有很多，我们从管理者和员工的角度来谈谈。●分工不当，连锁反应在中小企业的困境中，悲剧的旅程往往是从分工不明确开始的。有些游戏创业公司，一开始只有2、3个运维人员，基本上每个人都要会运维各种工种，比如游戏运维、网站运维（Nginx/PHP等），数据库运维（MySQL等），系统运维（Linux/Windows等），服务器上架，故障报修，甚至网线。公司业务扩大很多之后，如果运维组织架构不相应改变，分工不明确，就会发现大家都累死了，什么都知道的结果就是自己不擅长一切。在运维技术如此复杂的今天，简直就是要把人活活烧死。这就导致多米诺骨牌效应：分工不明确—>职责不明确—>考核不量化—>流程不合理—>缺乏规范和文件。●doingvstalking困难运维人员一般不善于沟通（至少表面上是这样，虽然大家一般都有一颗火热的心，呵呵）。在微信和QQ普及的今天，这个问题不是变小了，而是变大了。这也与工作性质有关。想一想，你整天和服务员聊天的时间比和人聊天的时间还多。另外，从人脑的结构来看，做与说的两难选择也在情理之中。控制计算和推理能力的是左脑，而控制表达能力的是右脑。如果你强求，你会做，会说，说不定会导致混乱、崩溃甚至“脑裂”，呵呵（当然，这个问题是有解决办法的）。更严重的是，很多同学没有意识到自己的沟通表达存在问题。一个字能把人噎死，又不知如何有效地表达出来。那不再是一种激情。●资源配置不当管理者和员工都可能存在资源配置不当的问题。对于管理者来说，包括人员不匹配和时间不匹配，员工主要是时间不匹配。如果一个管理者把错误的人放在错误的位置上，就注定要犯错误。比如有同学喜欢钻研技术，不喜欢表达，就必须把他当做对外部门的接口。自然吃力不讨好，大家都不高兴。管理者的时间错配包括三种情况。1）痴迷于解决技术问题。这通常发生在你刚从技术职位升任经理时，忘记了你是经理。解决复杂的技术问题可以带来快乐，否则就是挫折。于是遇到技术问题，我只好硬拼到底，然后一个星期就过去了，而系里的其他同学都在放羊一周。2）集中管理。这是另一个极端，忘记了你的技术身份。把自己变成项目经理，整天只关心时间节点，不理会技术人员的小感受，不帮助他们解决具体的技术问题。3）执着于单一的业务模块。这是另一个特例。通常发生在内部晋升时。比如一个曾经是DBA组组长的同学，升职成了运维部经理，但还是习惯于去抓自己擅长的数据库工作。不应该这样，否则就没有宣传的必要了。员工资源错配主要体现在时间安排上。事情太多，轻重缓急不明确，没有合理的排序原则和指导思想；技术进步与岗位要求混淆（有时过分追求技术进步），简单的问题复杂化，客户满意度降低。#p#3。如何实现高效运维高效运维从来都不是一件简单的事情，需要多方共同努力才能实现。本文先选取要点进行简要说明，在以后的专栏系列中会有更深入的讲解。●分工明确美国著名管理学者斯蒂芬·柯维在其畅销书《高效能人士的七个习惯》中提出产出/能力平衡原则。如果你想生产更多，你必须首先扩大你的生产能力。要想金鸡多下蛋，杀鸡取蛋是不行的。那么什么是高效运维的产能呢？它包括三个部分：1）框架，即合理的分工/职责/KPI，不好意思我提到了KPI，多么让人又爱又恨的词；2）血液，即专业流程/标准；3）接口，即良好的服务意识/技能。这些投资足以获得预期的产出——高效的运维。这些执行一段时间后，外部部门会觉得奇怪：哎呀，运维怎么变化这么大。虽然他们不知道原因，但我们可以微微一笑，呵呵。就运维部门来说，我们的分工和内网IT部门是不一样的。一是服务外部客户，二是服务内部客户。差别还是挺大的。根据部门分工，将??各组的分工拆解，落实到每位员工。有规则，大家都觉得舒服。运维是支撑部门，是成本中心，很难产生利润。因此，重要的考核指标其实是客户满意度。请相关业务部门对运维学员进行评分。内部运维也可以根据分工互相打分，对应外部满意度和内部满意度。KPI虽然让人不舒服，但总的来说，还是有其存在的合理性的。●技术专业化技术专业化运维也涉及面广。以下只是几个例子。1）优化监控系统谁来监控监控系统？如何保证问题早于业务部门发现？是否需要添加业务监控？URL监听是否返回状态码200一切正常？是否需要文件监控？短信报警和邮件报警就够了吗？需要自动语音报警和垂直升级功能？监控是一门科学，是专业运维的入口。展开能占很大篇幅，先抛砖引玉，提出这些问题。其实，对于资深、聪明的运维同学来说，看到题目就已经有了自己的答案。2）减少人为事故人为事故是运维中最麻烦、最不专业的事情之一。比如在网站运维中，如果每次更新都需要登录服务器，svnupdate/gitpull难免出错。所以你可以使用Jenkins之类的工具来实现web更新，这样除非有重大更新（包括数据库更新），你只需要点点鼠标就可以了。甚至，网站更新可以外包回开发部门，这样也可以减少运维操作带来的沟通成本和时间成本。3）运维自动化运维自动化是一个很大的话题，网上也有很多讨论。建议选择适合自己的方法和方法。ansible等轻量级工具不需要在托管服务器上安装客户端程序，这在对多台服务器进行分布式管理时具有很大的优势（尤其是管理只有临时账户权限的服务器时）。另一个吸引人的特点是操作结果和操作日志集中存储。4）合理优化架构。近年来，国内优秀的开源软件层出不穷。设计和优化架构通常不必从头开始。例如，Redis以其高效率和稳定性成为缓存系统的最佳选择之一。但是Redis单实例的支持能力是有限的。目前Redis集群大多是使用Twemproxy实现的，但是使用起来总感觉有点美中不足。那么，有没有替代品呢？Codis就是其中之一。Codis由Peapod开源，在自己的业务系统中广泛使用。Codis恰好击中了Twemproxy的两个痛点（无法分片，运维不友好）。Codis可以平滑扩容/缩容，随时增减Redis服务器；并提供友好的运维界面，不仅可以看到Codis系统的运行状态，还可以进行数据迁移、主备切换等操作。此外，Codis还提供了平滑迁移Redis的工具依赖Twemproxy转Codis的集群（太爽了，画面太美了，不忍直视）。在性能方面，根据我们的实测，在正常值长度下，Codis的get/set性能要优于Twemproxy。#p#5)代码持续部署在线系统程序代码能否自动打包持续部署？新版本的测试环境能否由开发者自己发布，甚至自己测试？这些无疑会大大提高运维和开发效率。Docker高可用集群，加上Jenkins的发布，可以将这些需求变为现实。Centos7的systemd用于底层支持Docker的高可用，etcd实现了配置文件的集中存储，而不是分散在各个服务器本地。fleet作为etcd和systemd之间的桥梁，通过systemd控制集群服务器。Jenkins从svn服务器获取到新的代码版本后，通过shell脚本打包成镜像，放入Docker私有库中，供Docker集群服务器更新使用。●专业化管理管理上的专业化运维，甚至包括调试通知、故障通知，都是众所周知的。系统运行一段时间后趋于稳定，调试/更新成为主要故障源之一。如何使调试少人为事故，如期顺利完成？这是一项技术任务。1)345运维规则报错是认真排查故障的唯一途径。一个长期的故障往往有很多细节可以推敲。我们总结了运维的345条规则。3是指故障时长分为三部分，4是指对应的四个故障时间点，5是指在这个过程中我们可以做的五件事。这样，我们就可以有针对性地优化解决方案。2）不要让过程吞下责任。工艺规范很好，缺一不可，好处大家都知道。只是过程有时会成为挡箭牌，让人以自我为中心，不愿承担责任，不愿从事个人责任以外的事情。这其实是错误的、短视的，是“损人害己”。如果出现非常严重的故障，个人能否“出泥而不染”？决不。如果是顶层故障，老大甚至想着接管整个运维部。没有皮了，毛怎么长出来的？●良好的客户界面不会让任何人发笑。恰当的言语表达可以化大事为小事，反之亦然。只是对于技术运维的同学来说，这并不容易。有些人甚至更喜欢加班而不是与他人交流。但是，工作要求有时需要很好的表达。其实我们也可以换个角度思考，如何把好的沟通当作一种技术来看待？1）面对面交流，QQ、微信等即时通讯工具实际上增加了交流成本。每个人都变得更加依赖它。面对面或电话沟通几分钟就能解释清楚的事情，来来去去几十分钟，更有什者还会吵架，玩得开心不起来。据国外调查，在一次有效的交流中，单词和句子的内容只占很小的一部分。我们一般会请素未谋面的朋友先面对面聊天。举个真实的例子，之前有个同学一直在QQ和邮件上跟一个运营同学交流。有一次实在说不清楚，就当面聊了一下，发现对方居然是个美女，所以后来的合作很愉快（虽然美中不足的是女人有男朋友）。2）过来的都是做运维的客户，所以应该放下尊严，做事不一定非得卑微，但至少心知肚明。在运维的沟通中，也适配了心理学的投射原理：你越是觉得别人霸道，服务不到位，其实你往往就是这样。来者皆是客。如果你真的很忙，回复会很慢。礼貌用语总是可以的，对不起，对不起，对不起，谢谢。4.小结说了这么多，不知道大家有没有看腻。运维很郁闷，让郁闷的人更加郁闷。不过不管怎么说，也是一门技术。这年头，有一门手艺，虽然需要很好的发展机会，但至少生存无忧。话虽如此，两条线都不容易。自己做运维这么多年，结合各种失败与成功，酸甜苦辣，终于领悟到高效运维的七字公式：专业、热情、便捷、快捷。不一定完全适合你，但毕竟是多年的修真，形成了自己的一个小体系。如果喜欢，以后我会一一讲解。如果能让大家受益，那我就幸运了。
