> 原文出处：http://www.infoq.com/cn/articles/effective-ops-part-06 > 作者：萧田国 ## 前言 关于Docker的文章铺天盖地，但精品文章往往翻译居多。都说Docker天生适合持续集成/持续部署，但同样，可落地、实际可操作性的文章也很罕见。 基于这些情况，虽然我们专栏定位为运维管理性文字，但本篇是个特例，实操性的案例讲解——JAVA项目如何通过Docker实现持续部署（只需简单四步），即： 开发同学通过git push上传代码，经Git和Jenkins配合，自动完成程序部署、发布，全程无需运维人员参与。 这是一种真正的容器级的实现，这个带来的好处，不仅仅是效率的提升，更是一种变革： 开发人员第一次真正为自己的代码负责——终于可以跳过运维和测试部门，自主维护运行环境（首先是测试/开发环境）。 难者不会，会者不难。通过简单的4个配置，即可优雅地实现持续部署。本文依惯例放上目录，请享用。 [TOC=3] 好吧，我们正式开始。 ## 1\. 持续部署的技术思路 在本例中，假设我们JAVA项目的名称为hello。简要的技术思路如下。  本案例中假设代码托管在git.oschina.com上，Jenkins和Docker Registry（类似于yum源）各运行在一个Docker容器中。JAVA项目自己也单独运行在一个叫hello的容器中。 本文采取的持续部署方案，是从私有的Docker Registry拉取代码。有些变通的方案，把代码放在宿主机上，让容器通过卷组映射来读取。这种方法不建议的原因是，将代码拆分出容器，这违背了Docker的集装箱原则： > 这也导致装卸复杂度增加。从货运工人角度考虑，整体才是最经济的。这样，也才能实现真正意义的容器级迁移。 或者说，容器时代，抛弃过去文件分发的思想，才是正途。本文最后的问答环节对此有更多阐述。 容器即进程。我们采用上述方案做Docker持续部署的原因和意义，也在于此。容器的生命周期，应该远远短于虚拟机，容器出现问题，应该是立即杀掉，而不是试图恢复。 ## 2\. 效果展示 本文最后实现的效果，究竟有多惊艳呢？且看如下的演示。 ### 2.1 程序代码更新前的效果 我们以时间戳来简洁、显式的表述程序更新情况。  ### 2.2 提交程序代码更新 本例中，我们把首页的时间戳从201506181750，修改为201506191410（见如下）。  ### 2.3 上传新代码到Git 顺序执行如下操作，输入正确的git账号密码。  然后呢？ 然后什么都不用做了。端杯茶（如果不喜欢咖啡的话），静静地等待自动部署的发生， 旁观一系列被自动触发的过程，机器人似的运转起来（请容稍候再加以描述）。 为什么需要3~5分钟？只是因为本案例中的JAVA项目，需要从国外download Maven程序包，以供Jenkins调用和编译JAVA。正式应用环境中，可以把Maven源放在国内或机房。如果仅仅需要对PHP项目做持续部署，那就更快捷了。 ### 2.4 查看代码更新后的效果 在静静地等待几分钟后，新的代码确实已经自动部署完毕。  那么，这一切怎么实现的呢？很复杂么？不然。只要按照如下几步，便可快速实现哦。 ## 3\. 配置Git和Jenkins联动 这个过程也是难者不会，会者不难。主要分为如下三步。 ### 3.1 Jenkins配置Git源 Jenkins中新建项目java-app，并配置从Git拉取程序代码。具体如下：  ### 3.2 Jenkins配置远程构建 Jenkins中配置token，以供git远程调用时使用。  ### 3.3 Git开启钩子 怎么让Git在接收到用户更新的代码后，把消息和任务传递给Jenkins呢？这借助于Git的hook功能，配置起来也非常简单，如下。  ## 4\. 配置Jenkins自动更新代码 Jenkins的主要工作是配置“远程构建”。在接收到Git传递过来的消息后，触发这个远程构建（到目标服务器），按照预定义的任务列表，执行一系列的工作，重建容器等。详见如下：  我们把其中最关键的Shell脚本内容摘抄出来。这些Docker相关操作，在第1部分“技术思路”已经提及，不再赘述。  ## 5\. 效果图文详解 在2.3这个章节中，我们当时的操作如下，这个目的是向Git提交更新代码。  当时并没有细说后续发生的事情，既然上面已经说清楚了原理，那我们就可以接下来说说实际发生的事情啦。 ### 5.1 上传代码到Git 这里貌似整个过程已经完成并顺利退出。其实，后台的工作才刚刚开始哦。  这时会触发Git服务器向相应的Jenkins服务器发出一个操作请求，此工作太过迅速，也没啥好说的，我们接下来看Jenkins都干啥子了。 ### 5.2 Jenkins进行的精彩互动 如下这个自动运转的过程，让我们有些许成就感，值得端杯咖啡（如果不喜欢茶的话），静静观赏。 1）Jenkins会自动"冒出来"一个构建任务。  2）我们点进来，看看具体操作日志。是的，正在接受来自Git的任务。  3）下载Maven相关的软件包（就是这个过程慢）。  4）下载完成后，就开始利用maven BUILD 新的hello项目包。  5）然后重建Maven容器，构建新的Image并Push到Docker私有库中。  6）最后，重新把Docker容器拉起来。这样，又新生了。呵呵  ## 6\. FAQ **问题1：**采用这么相对复杂的办法（而不是把更新代码放在宿主机然后卷组映射），是因为项目基于JAVA么；是否PHP项目就可以采用更新代码放在宿主机然后卷组映射这种方式？ > **回答1：**将代码拆分出容器，违背了集装箱原则。导致装卸复杂度增加。从货运工人角度考虑，整体才是最经济的。一切版本化。抛弃过去的文件分发。这是正途。至于文件大小，大的war包也就50M或100M，在现有网络下不成问题，性能问题最好优化。另外建议关注docker 2 docker，p2p传输。 **问题2：**如果整体代码超过500m或者1g以上，整体集装箱是否就不太好了？如果容器与代码分离，镜像就100m左右（2层，base+服务），然后代码的话，是放到共享存储里，每个代码有更新，比如svn的代码，可以直接在共享存储里进行svn update就可以控制版本 > **回答2：**如果你的代码500M，那只能说明业务开发该打板子了。 **问题3：**如果测试环境使用您提供的完整集装箱服务还行，但在生产环境，集群里运行docker做应用，如果每个容器都是有完整的代码，是否有点臃肿，不如每个集群节点里就运行基础服务镜像，通过卷组功能绑定共享存储里的代码，加上Crontab、Python和Shell脚本，这样每次代码更新就1次就行了。 > **回答3：**环境一致性，在过去从来没有解决好。10年前我们做paas时，和这个做法类似。不是说不好，时代变了，用脚本东拼西凑，终究难有好的系统。不能只考虑现在的方便，容器技术和vm如果类比，我觉得会让自己下决定时很纠结。 **补充3：**脚本一般是典型的运维工程师思维，quick & dirty。一般很难做成一个产品或者系统。整体考虑和扩展性考虑都比较少。现在做docker的难点在于到底怎么看待它。到底是拿它做调度的基本单位，还是部署的基本单位考虑清楚？再聊方案。 * * * * * **张春源，**目前任职cSphere。国内最早期的Docker实践者，在生产环境拥有一年多的Docker容器管理经历。深刻理解Docker对于开发、测试以及运维的价值。擅长利用Docker构建整个DevOps自动化平台。热爱专研Dockerfile这门艺术，并对CoreOS有深入研究。

> 原文出处：http://www.infoq.com/cn/articles/effective-ops-part-05 > 作者：萧田国 ## 前言 运维的今天，内忧外患。运维危机，已非盛世危言、或哗众取宠。 怎么办？暴风雨和奇点同时逼近，而运维的分化，或许只是时间的问题。 为此，我提出新观点：运维2.0——这也是运维最后的机会。 运维好比是池塘里的鱼，不管水域大小，都有一块自留地。但某天，突然来了一头鲸鱼，目标不是鱼而是水…… 所以运维的任务需随之而变——在水被吸干之前，提前上岸。 运维2.0，就是那个带我们跳出池塘投身大湖的武器。 本文根据我在2015 QCon北京大会的演讲提炼而成。本次大会的主题及期间的业内交流，给我极大的触动。因本文宗旨和专栏思想高度一致，故此发布。 挑战究竟何等凶猛？技术重要性不断下沉，新的核心竞争力何在？趋势不可逆转的话，怎么升级到运维2.0？且听本文分解。 本文不是很长，依惯例放上目录，请享用。 [TOC] 好吧，我们正式开始。 ## 1\. 什么是运维2.0？ 运维2.0是指可依赖、懂业务、服务化的专业运维（或称服务运维）。也是本专栏所推崇高效运维的抽象和概括，即“专业、热情、方便、快”。 需要引起注意的是，技术不代表专业。相反，技术往往是专业的最大障碍。  运维2.0要求，从技术运维升级为服务运维，向公司提供可依赖的专业服务。 运维2.0强调服务交付能力，而不是技术能力。这也要求我们完成角色转换，成为懂业务的运维。具体而言，需要完成如下两个转换。 1）转换工作重心：从关注工作产能（技术的自我修养），变成关注工作产出（我们为公司做出多大贡献）； 2）转换关注重心：从关注自我评价，变成关注外部评价。 ## 2\. 为什么需要运维2.0？ 伴随着Web 2.0的风潮，近年来，运维相关技术的发展也突飞猛进。 但同时，从内部来看，对运维的不满，日益突出；从外部来看，公有云来势凶猛，开源软件百花齐放，自动化运维降低了对人的依赖——众多运维人员，逐渐从技术的创造者（手艺人）沦为技术的使用者（装配员）。 ### 2.1 公司内部的各种不满 对运维而言，来自内部各种不满的声音，从来就没消停过，而且越演越烈。从调查来看，貌似很少有公司对运维是相对比较满意的。 公司内部的典型不满，包括如下图所示种种。不知其中是否有大家的影子？最终公司和业务部门就像图中间这只小猫，抓心挠肺却又无可奈何。  运维本来就是个尴尬的行当。公司默认，不出故障是正常的。甚至有公司将开发、测试和运维并列，起评分为零分，每出一次故障，扣几分。 运维觉得自己的苦憋有多少，业务部门对运维的不爽就同等的有多少。 公司内部的不满，是运维危机的主要根源之一。 公司和业务部门长期积累的负面情绪，已积累多年，迟早有一天会突然爆发。 曾经有公司老板，在某一次运维严重人为事故后，准备把整个运维部端掉；类似情况也发生在，另一家公司出现严重的安全事故时。 ### 2.2 公有云风起云涌 根据RightScale对国外930家公司在2015年第一季度的调查来看，目前93%的公司已经在使用云，其中公有云的使用者为88%。如果包括传统企业，国内使用云的比例可能低些，但整体趋势已经非常明显。  IaaS干掉了基础运维，公司不再需要人各地出差服务器上架了，机房值班更加不需要了。 PaaS部分干掉了应用运维，甚至技术含量高的DBA，需求量都将锐减。 SaaS甚至干掉连研发都干掉了，使得公有云的使用更加傻瓜化，像Office 365，谁不会呢？ 有人甚至提出OaaS——服务器运维的外包，也就是说，彻底不需要运维部门了。 ### 2.3 开源软件百花齐放 开源软件从来没有像今天这样生机勃勃。随之，运维人员从技术的创造者沦为技术的使用者——好比调制鸡尾酒，能力的高低，取决于勾兑水平，但还都能喝。 不仅国外新的开源技术层出不穷，国内互联网公司也发布了诸多令人惊艳的作品，甚至包括之前大家认为相关封闭的大公司，近来也改变姿势，主动推出自家各种得意之作。 国内新晋大公司甚至规定：能用开源软件，就不自主研发。并且乐于成为开源软件的committer，反馈并回报社区。 开源软件降低了相应系统运维的复杂度和技术要求，也即降低了对人的依赖。 前些年，精通Shell脚本编程的系统工程师，相比工资可能高出50%。但随着Puppet、SaltStack等开源软件的出现，使得各个系统组件偏于积木化，操作也更加简便高效。 ### 2.4 运维自动化 运维进化到今天，已非刀耕火种的时代。各种开源软件就好比武器和工具，使得运维自动化的实现，变得如此地得心应手、游刃有余。 只是，这会导致中级水平运维人员的需求锐减。 站在运维制高点的大公司，已经向我们传送阵阵凉意——山雨欲来风满楼。 某大型互联网公司，实现了游戏自动化运维的PaaS平台，通过简单的页面操作，可以完成新服、更新、合服、数据分析等几乎所有业务需求。这使得，在公司业务量增加50%的情况下，运维人员仅增加了5%。 另外，运维自动化已深入运维的各个细分工种中，而不仅限于应用运维和系统运维。 某大型互联网公司，持续改进IDC自动化平台，使得服务器交付时间缩短为不到6%，网络设备交付时间缩短为不到15%。  某大型互联网公司，基于多年技术积淀，基本实现了数据库自动化运维。这使得单个DBA能维护的数据库服务器，增加10倍，然后呢…… 或许不用太长时间，这股风潮将席卷盘踞山腰的中型公司，然后以暴风雨的形式，落在中小公司头上。 内忧外患！内外交困！新形势下，运维的价值何在？技术重要性不断下沉，还准备倚仗某些压箱底的技术活呢？ 迷失的运维，出路在何方？运维的前途会怎样？我们能平安上岸么？ ## 3\. 运维2.0的落地 运维2.0是一个理论+实践的体系，内容较多，本文仅择要提及。关于如何落地的具体细节，我会在本专栏的系列文章中分别阐述。 运维2.0不是忽视技术，而是强调技术得适度，把我们的关注点从技术本身，转移到贡献上来。技术服务业务，与此同时，再搭配各种理论及方法技巧。 诚如前文所言，运维2.0即高效运维，亦即：专业、热情、方便、快。也就是说，向公司交付一种可依赖的专业服务。 其中“专业”的意思，包括减少故障发生次数，缩短故障时长（有公司甚至进一步提出，“不以故障多为耻，以恢复快为荣”），少犯人为事故，个人技术进步服从业务要求（少搞自研、多用开源）等。 另外，“热情、方便、快”见之前专栏文章，本文不做赘述。 运维2.0的实现，基于产出/产能平衡原则，只有完成如下三大类产能的投入，才会最终获得心仪的产出——运维2.0。需要注意的是，这三大类投入，并非串行，相反，应同时修炼。  相信会有那一天，公司业务部门惊喜地说，“我们运维变化好大”。 ### 3.1 技术服务业务 我们的诸多行为背后都有动机（潜意识），这就是俗称的思维模式。我们不自知的是，往往不自觉地陷入各种思维模式（思维陷阱）中。在这些既定思维模式中，我们感觉到舒服，更难以体认到思维模式是可以改变的。 我们需要提升意识。就像这三个石匠的故事。  这个故事是如此的直白而又精准，我们仿佛看到管理学科创始人彼得ž德鲁克在讲述时，不无揶揄的表情。是啊，对公司业务而言，我们都是石匠，或者说凿石头的；而且，新的凿石神器已经在路上…… 为什么技术服务业务？ 运维不是销售，无法对公司产生直接价值（收入），我们的工作价值是通过外部门间接实现的。说得再直白些，我们本质上提供的是一种“服务”，仅此而已。 我们属于服务业（多么痛地领悟），需要深知技术只是我们的工具，仅此而已。 ### 3.2 开启能力双模式 这里的能力，包括业务能力和技术能力。 我们需要主动学习业务，主动、定期和业务部门沟通，业务部门感受到我们的诚意后，也会释放他们的诚意，这样便有了愉快的工作环境，业务能力也会提升地更快。 我们需要主动拥抱公有云及新兴的开源软件，乐于分享，而不是把某些技术当做压箱底、保命的资本。 ### 3.3 开放的技巧 技巧同样非常重要，除去在本专栏第01篇和第02篇讲述的那些之外，例如恰当的鼓励、及时的正向反馈，也往往能取得意料之外的效果。 不要再潜意识地觉得自家领导、外部门都是白痴，都无可救药。真诚地、平等的交流、倾听，改变迟早会来。 备注：因文章篇幅所限，运维2.0更多的各种细节，暂且不表。以后本专栏还会有多篇文章，详细阐述。 ## 4\. 拥抱变化 其实，我们有什么理由相信，自己就是那个独善其身的幸运者？——在我们看到互联网干掉一个又一个传统行业，而运维实际还处于初级阶段的时候。 同样，运维的进化，将导致中级运维人员的需求锐减，更多需要初级运维和高级运维（即工具的操作者和工具的建设者）。 这需要我们修炼新技能：从外部审视自己，懂业务，提升专业服务能力，树立公有云无法替代的优势。与此同时，加强技术能力，提升为高级运维人员，以实现提前上岸的目标。 因为运维的集约化，使得高端技术人才的需求更大。例如，像航天这种高度自动化的行业，飞机驾驶员就是一个高大上的岗位。 诸多开源软件需要二次开发，因此学些编程，成长为DevOPS或全栈工程师，也是一个好的选择。 **【问】我确实没怎感觉到运维危机？你怎么说服我着手实践运维2.0呢？** > 【答】运维危机不因你个人是否感觉到，而不存在嘛。至少，咱也得居安思危，对不？况且实施运维2.0，又不会让自己损失什么，早些总比晚些好。这就好比考驾照，觉得自己暂时不买车，就不去考。等有一天所在城市准备限号，那就哭都来不及了（驾照是排号的前提）。 **【问】我修炼了运维2.0，可公司不需要那么多人了，咋办？** > 【答】你的综合技能大大提升，都已内外兼修，还怕找不到更好的工作？ **【问】看完你的文章，整个人的心情都不好了。能否说说运维的机遇？** > 【答】抱歉，请相信我这些文字只是善意提醒。而且，我对运维感情很深，十多年一直奋斗在这个行当。机遇在于，很多公司开始减少成见，并越来越重视运维。现状越是糟糕，改善越是能获得更高评价。运维2.0可帮助大家快速地提升软实力，实现飞越。 ## 结语 暴风雨和奇点必将来临，区别只是时间上，早一些或晚一些。 运维2.0，将重新定义运维。要求公司内部运维部门，从侧重“技术运维”升级到“服务运维”。这也是在变革时代中，运维重生的最后机会。 运维2.0，要求运维从内而外的改造自己，这个过程痛苦，但也是我们唯一的机会，这甚至决定着我们是生存、还是死亡。 焦虑和恐慌不能解决问题，对事实和趋势的抗拒，顶多自欺欺人，对解决问题也没有任何帮助。认同趋势，顺应潮流，提前做好准备。 一起加油，百万运维兄弟们！！！ 当然咯，本专栏《高效运维最佳实践》也是运维2.0最佳实践，值得您的持续关注 。 本文得到腾讯赵建春先生（@coati）、新浪微博杨卫华老师（@Tim Yang）及老友董伟（@董伟）的斧正。谨表谢意。

> 原文出处：http://www.infoq.com/cn/articles/effective-ops-part-04 > 作者：萧田国 ## 前言 运维的今天，内忧外患。运维危机，已非盛世危言、或哗众取宠。 怎么办？暴风雨和奇点同时逼近，而运维的分化，或许只是时间的问题。 为此，我提出新观点：运维2.0——这也是运维最后的机会。 运维好比是池塘里的鱼，不管水域大小，都有一块自留地。但某天，突然来了一头鲸鱼，目标不是鱼而是水…… 所以运维的任务需随之而变——在水被吸干之前，提前上岸。 运维2.0，就是那个带我们跳出池塘投身大湖的武器。 本文根据我在2015 QCon北京大会的演讲提炼而成。本次大会的主题及期间的业内交流，给我极大的触动。因本文宗旨和专栏思想高度一致，故此发布。 挑战究竟何等凶猛？技术重要性不断下沉，新的核心竞争力何在？趋势不可逆转的话，怎么升级到运维2.0？且听本文分解。 本文不是很长，依惯例放上目录，请享用。 [TOC] 好吧，我们正式开始。 ## 1\. 什么是运维2.0？ 运维2.0是指可依赖、懂业务、服务化的专业运维（或称服务运维）。也是本专栏所推崇高效运维的抽象和概括，即“专业、热情、方便、快”。 需要引起注意的是，技术不代表专业。相反，技术往往是专业的最大障碍。  运维2.0要求，从技术运维升级为服务运维，向公司提供可依赖的专业服务。 运维2.0强调服务交付能力，而不是技术能力。这也要求我们完成角色转换，成为懂业务的运维。具体而言，需要完成如下两个转换。 1）转换工作重心：从关注工作产能（技术的自我修养），变成关注工作产出（我们为公司做出多大贡献）； 2）转换关注重心：从关注自我评价，变成关注外部评价。 ## 2\. 为什么需要运维2.0？ 伴随着Web 2.0的风潮，近年来，运维相关技术的发展也突飞猛进。 但同时，从内部来看，对运维的不满，日益突出；从外部来看，公有云来势凶猛，开源软件百花齐放，自动化运维降低了对人的依赖——众多运维人员，逐渐从技术的创造者（手艺人）沦为技术的使用者（装配员）。 ### 2.1 公司内部的各种不满 对运维而言，来自内部各种不满的声音，从来就没消停过，而且越演越烈。从调查来看，貌似很少有公司对运维是相对比较满意的。 公司内部的典型不满，包括如下图所示种种。不知其中是否有大家的影子？最终公司和业务部门就像图中间这只小猫，抓心挠肺却又无可奈何。  运维本来就是个尴尬的行当。公司默认，不出故障是正常的。甚至有公司将开发、测试和运维并列，起评分为零分，每出一次故障，扣几分。 运维觉得自己的苦憋有多少，业务部门对运维的不爽就同等的有多少。 公司内部的不满，是运维危机的主要根源之一。 公司和业务部门长期积累的负面情绪，已积累多年，迟早有一天会突然爆发。 曾经有公司老板，在某一次运维严重人为事故后，准备把整个运维部端掉；类似情况也发生在，另一家公司出现严重的安全事故时。 ### 2.2 公有云风起云涌 根据RightScale对国外930家公司在2015年第一季度的调查来看，目前93%的公司已经在使用云，其中公有云的使用者为88%。如果包括传统企业，国内使用云的比例可能低些，但整体趋势已经非常明显。  IaaS干掉了基础运维，公司不再需要人各地出差服务器上架了，机房值班更加不需要了。 PaaS部分干掉了应用运维，甚至技术含量高的DBA，需求量都将锐减。 SaaS甚至干掉连研发都干掉了，使得公有云的使用更加傻瓜化，像Office 365，谁不会呢？ 有人甚至提出OaaS——服务器运维的外包，也就是说，彻底不需要运维部门了。 ### 2.3 开源软件百花齐放 开源软件从来没有像今天这样生机勃勃。随之，运维人员从技术的创造者沦为技术的使用者——好比调制鸡尾酒，能力的高低，取决于勾兑水平，但还都能喝。 不仅国外新的开源技术层出不穷，国内互联网公司也发布了诸多令人惊艳的作品，甚至包括之前大家认为相关封闭的大公司，近来也改变姿势，主动推出自家各种得意之作。 国内新晋大公司甚至规定：能用开源软件，就不自主研发。并且乐于成为开源软件的committer，反馈并回报社区。 开源软件降低了相应系统运维的复杂度和技术要求，也即降低了对人的依赖。 前些年，精通Shell脚本编程的系统工程师，相比工资可能高出50%。但随着Puppet、SaltStack等开源软件的出现，使得各个系统组件偏于积木化，操作也更加简便高效。 ### 2.4 运维自动化 运维进化到今天，已非刀耕火种的时代。各种开源软件就好比武器和工具，使得运维自动化的实现，变得如此地得心应手、游刃有余。 只是，这会导致中级水平运维人员的需求锐减。 站在运维制高点的大公司，已经向我们传送阵阵凉意——山雨欲来风满楼。 某大型互联网公司，实现了游戏自动化运维的PaaS平台，通过简单的页面操作，可以完成新服、更新、合服、数据分析等几乎所有业务需求。这使得，在公司业务量增加50%的情况下，运维人员仅增加了5%。 另外，运维自动化已深入运维的各个细分工种中，而不仅限于应用运维和系统运维。 某大型互联网公司，持续改进IDC自动化平台，使得服务器交付时间缩短为不到6%，网络设备交付时间缩短为不到15%。  某大型互联网公司，基于多年技术积淀，基本实现了数据库自动化运维。这使得单个DBA能维护的数据库服务器，增加10倍，然后呢…… 或许不用太长时间，这股风潮将席卷盘踞山腰的中型公司，然后以暴风雨的形式，落在中小公司头上。 内忧外患！内外交困！新形势下，运维的价值何在？技术重要性不断下沉，还准备倚仗某些压箱底的技术活呢？ 迷失的运维，出路在何方？运维的前途会怎样？我们能平安上岸么？ ## 3\. 运维2.0的落地 运维2.0是一个理论+实践的体系，内容较多，本文仅择要提及。关于如何落地的具体细节，我会在本专栏的系列文章中分别阐述。 运维2.0不是忽视技术，而是强调技术得适度，把我们的关注点从技术本身，转移到贡献上来。技术服务业务，与此同时，再搭配各种理论及方法技巧。 诚如前文所言，运维2.0即高效运维，亦即：专业、热情、方便、快。也就是说，向公司交付一种可依赖的专业服务。 其中“专业”的意思，包括减少故障发生次数，缩短故障时长（有公司甚至进一步提出，“不以故障多为耻，以恢复快为荣”），少犯人为事故，个人技术进步服从业务要求（少搞自研、多用开源）等。 另外，“热情、方便、快”见之前专栏文章，本文不做赘述。 运维2.0的实现，基于产出/产能平衡原则，只有完成如下三大类产能的投入，才会最终获得心仪的产出——运维2.0。需要注意的是，这三大类投入，并非串行，相反，应同时修炼。  相信会有那一天，公司业务部门惊喜地说，“我们运维变化好大”。 ### 3.1 技术服务业务 我们的诸多行为背后都有动机（潜意识），这就是俗称的思维模式。我们不自知的是，往往不自觉地陷入各种思维模式（思维陷阱）中。在这些既定思维模式中，我们感觉到舒服，更难以体认到思维模式是可以改变的。 我们需要提升意识。就像这三个石匠的故事。  这个故事是如此的直白而又精准，我们仿佛看到管理学科创始人彼得ž德鲁克在讲述时，不无揶揄的表情。是啊，对公司业务而言，我们都是石匠，或者说凿石头的；而且，新的凿石神器已经在路上…… 为什么技术服务业务？ 运维不是销售，无法对公司产生直接价值（收入），我们的工作价值是通过外部门间接实现的。说得再直白些，我们本质上提供的是一种“服务”，仅此而已。 我们属于服务业（多么痛地领悟），需要深知技术只是我们的工具，仅此而已。 ### 3.2 开启能力双模式 这里的能力，包括业务能力和技术能力。 我们需要主动学习业务，主动、定期和业务部门沟通，业务部门感受到我们的诚意后，也会释放他们的诚意，这样便有了愉快的工作环境，业务能力也会提升地更快。 我们需要主动拥抱公有云及新兴的开源软件，乐于分享，而不是把某些技术当做压箱底、保命的资本。 ### 3.3 开放的技巧 技巧同样非常重要，除去在本专栏第01篇和第02篇讲述的那些之外，例如恰当的鼓励、及时的正向反馈，也往往能取得意料之外的效果。 不要再潜意识地觉得自家领导、外部门都是白痴，都无可救药。真诚地、平等的交流、倾听，改变迟早会来。 备注：因文章篇幅所限，运维2.0更多的各种细节，暂且不表。以后本专栏还会有多篇文章，详细阐述。 ## 4\. 拥抱变化 其实，我们有什么理由相信，自己就是那个独善其身的幸运者？——在我们看到互联网干掉一个又一个传统行业，而运维实际还处于初级阶段的时候。 同样，运维的进化，将导致中级运维人员的需求锐减，更多需要初级运维和高级运维（即工具的操作者和工具的建设者）。 这需要我们修炼新技能：从外部审视自己，懂业务，提升专业服务能力，树立公有云无法替代的优势。与此同时，加强技术能力，提升为高级运维人员，以实现提前上岸的目标。 因为运维的集约化，使得高端技术人才的需求更大。例如，像航天这种高度自动化的行业，飞机驾驶员就是一个高大上的岗位。 诸多开源软件需要二次开发，因此学些编程，成长为DevOPS或全栈工程师，也是一个好的选择。 **【问】我确实没怎感觉到运维危机？你怎么说服我着手实践运维2.0呢？** > 【答】运维危机不因你个人是否感觉到，而不存在嘛。至少，咱也得居安思危，对不？况且实施运维2.0，又不会让自己损失什么，早些总比晚些好。这就好比考驾照，觉得自己暂时不买车，就不去考。等有一天所在城市准备限号，那就哭都来不及了（驾照是排号的前提）。 **【问】我修炼了运维2.0，可公司不需要那么多人了，咋办？** > 【答】你的综合技能大大提升，都已内外兼修，还怕找不到更好的工作？ **【问】看完你的文章，整个人的心情都不好了。能否说说运维的机遇？** > 【答】抱歉，请相信我这些文字只是善意提醒。而且，我对运维感情很深，十多年一直奋斗在这个行当。机遇在于，很多公司开始减少成见，并越来越重视运维。现状越是糟糕，改善越是能获得更高评价。运维2.0可帮助大家快速地提升软实力，实现飞越。 ## 结语 暴风雨和奇点必将来临，区别只是时间上，早一些或晚一些。 运维2.0，将重新定义运维。要求公司内部运维部门，从侧重“技术运维”升级到“服务运维”。这也是在变革时代中，运维重生的最后机会。 运维2.0，要求运维从内而外的改造自己，这个过程痛苦，但也是我们唯一的机会，这甚至决定着我们是生存、还是死亡。 焦虑和恐慌不能解决问题，对事实和趋势的抗拒，顶多自欺欺人，对解决问题也没有任何帮助。认同趋势，顺应潮流，提前做好准备。 一起加油，百万运维兄弟们！！！ 当然咯，本专栏《高效运维最佳实践》也是运维2.0最佳实践，值得您的持续关注 。 本文得到腾讯赵建春先生（@coati）、新浪微博杨卫华老师（@Tim Yang）及老友董伟（@董伟）的斧正。谨表谢意。

> 原文出处：http://www.infoq.com/cn/articles/effective-ops-part-03 > 作者：萧田国 ## 前言 诚如开篇文章所言，高效运维包括管理的专业化和技术的专业化。前两篇我们主要在说些管理相关的内容，本篇说一下技术专业化。希望读者朋友们能适应这个转换，谢谢。 互联网早在几年前就已进入Web 2.0时代，对后台支撑能力的要求，提高了几十倍甚至几百倍。在这个演化过程中，缓存系统扮演了举足轻重的角色。 运维进化到今天，已经不是重复造轮子的时代。所以，我们在架构优化和自动化运维中，可以尽可能地选用优秀的开源产品，而不是自己完全从头再来（各种技术geek除外）。 本文主要讨论Redis集群相关技术及新发展，关于Redis运维等内容，以后另开主题讨论。 本文重点推荐Codis——豌豆荚开源的Redis分布式中间件（该项目于4个月前在GitHub开源，目前star已超过2100）。其和Twemproxy相比，有诸多激动人心的新特性，并支持从Twemproxy无缝迁移至Codis。 本文主要目录如下，对Redis比较了解的朋友，可跳过前两部分，直接欣赏Codis相关内容。 [TOC=3] 好吧我们正式开始。 ## 1\. Redis常见集群技术 长期以来，Redis本身仅支持单实例，内存一般最多10~20GB。这无法支撑大型线上业务系统的需求。而且也造成资源的利用率过低——毕竟现在服务器内存动辄100~200GB。 为解决单机承载能力不足的问题，各大互联网企业纷纷出手，“自助式”地实现了集群机制。在这些非官方集群解决方案中，物理上把数据“分片”（sharding）存储在多个Redis实例，一般情况下，每一“片”是一个Redis实例。 包括官方近期推出的Redis Cluster，Redis集群有三种实现机制，分别介绍如下，希望对大家选型有所帮助。 ### 1.1 客户端分片 这种方案将分片工作放在业务程序端，程序代码根据预先设置的路由规则，直接对多个Redis实例进行分布式访问。这样的好处是，不依赖于第三方分布式中间件，实现方法和代码都自己掌控，可随时调整，不用担心踩到坑。 这实际上是一种静态分片技术。Redis实例的增减，都得手工调整分片程序。基于此分片机制的开源产品，现在仍不多见。 这种分片机制的性能比代理式更好（少了一个中间分发环节）。但缺点是升级麻烦，对研发人员的个人依赖性强——需要有较强的程序开发能力做后盾。如果主力程序员离职，可能新的负责人，会选择重写一遍。 所以，这种方式下，可运维性较差。出现故障，定位和解决都得研发和运维配合着解决，故障时间变长。 这种方案，难以进行标准化运维，不太适合中小公司（除非有足够的DevOPS）。 ### 1.2 代理分片 这种方案，将分片工作交给专门的代理程序来做。代理程序接收到来自业务程序的数据请求，根据路由规则，将这些请求分发给正确的Redis实例并返回给业务程序。  这种机制下，一般会选用第三方代理程序（而不是自己研发），因为后端有多个Redis实例，所以这类程序又称为分布式中间件。 这样的好处是，业务程序不用关心后端Redis实例，运维起来也方便。虽然会因此带来些性能损耗，但对于Redis这种内存读写型应用，相对而言是能容忍的。 这是我们推荐的集群实现方案。像基于该机制的开源产品Twemproxy，便是其中代表之一，应用非常广泛。 ### 1.3 Redis Cluster 在这种机制下，没有中心节点（和代理模式的重要不同之处）。所以，一切开心和不开心的事情，都将基于此而展开。 Redis Cluster将所有Key映射到16384个Slot中，集群中每个Redis实例负责一部分，业务程序通过集成的Redis Cluster客户端进行操作。客户端可以向任一实例发出请求，如果所需数据不在该实例中，则该实例引导客户端自动去对应实例读写数据。 Redis Cluster的成员管理（节点名称、IP、端口、状态、角色）等，都通过节点之间两两通讯，定期交换并更新。 由此可见，这是一种非常“重”的方案。已经不是Redis单实例的“简单、可依赖”了。可能这也是延期多年之后，才近期发布的原因之一。 这令人想起一段历史。因为Memcache不支持持久化，所以有人写了一个Membase，后来改名叫Couchbase，说是支持Auto Rebalance，好几年了，至今都没多少家公司在使用。 这是个令人忧心忡忡的方案。为解决仲裁等集群管理的问题，Oracle RAC还会使用存储设备的一块空间。而Redis Cluster，是一种完全的去中心化…… 本方案目前不推荐使用，从了解的情况来看，线上业务的实际应用也并不多见。 ## 2\. Twemproxy及不足之处 Twemproxy是一种代理分片机制，由Twitter开源。Twemproxy作为代理，可接受来自多个程序的访问，按照路由规则，转发给后台的各个Redis服务器，再原路返回。 这个方案顺理成章地解决了单个Redis实例承载能力的问题。当然，Twemproxy本身也是单点，需要用Keepalived做高可用方案。 我想很多人都应该感谢Twemproxy，这么些年来，应用范围最广、稳定性最高、最久经考验的分布式中间件，应该就是它了。只是，他还有诸多不方便之处。 Twemproxy最大的痛点在于，无法平滑地扩容/缩容。 这样导致运维同学非常痛苦：业务量突增，需增加Redis服务器；业务量萎缩，需要减少Redis服务器。但对Twemproxy而言，基本上都很难操作（那是一种锥心的、纠结的痛……）。 或者说，Twemproxy更加像服务器端静态sharding。有时为了规避业务量突增导致的扩容需求，甚至被迫新开一个基于Twemproxy的Redis集群。 Twemproxy另一个痛点是，运维不友好，甚至没有控制面板。 Codis刚好击中Twemproxy的这两大痛点，并且提供诸多其他令人激赏的特性。 ## 3\. Codis实践 Codis由豌豆荚于2014年11月开源，基于Go和C开发，是近期涌现的、国人开发的优秀开源软件之一。现已广泛用于豌豆荚的各种Redis业务场景（已得到豌豆荚@刘奇同学的确认，呵呵）。 从3个月的各种压力测试来看，稳定性符合高效运维的要求。性能更是改善很多，最初比Twemproxy慢20%；现在比Twemproxy快近100%（条件：多实例，一般Value长度）。 ### 3.1 体系架构 Codis引入了Group的概念，每个Group包括1个Redis Master及至少1个Redis Slave，这是和Twemproxy的区别之一。这样做的好处是，如果当前Master有问题，则运维人员可通过Dashboard“自助式”切换到Slave，而不需要小心翼翼地修改程序配置文件。 为支持数据热迁移（Auto Rebalance），出品方修改了Redis Server源码，并称之为Codis Server。 Codis采用预先分片（Pre-Sharding）机制，事先规定好了，分成1024个slots（也就是说，最多能支持后端1024个Codis Server），这些路由信息保存在ZooKeeper中。  ZooKeeper还维护Codis Server Group信息，并提供分布式锁等服务。 ### 3.2 性能对比测试 Codis目前仍被精益求精地改进中。其性能，从最初的比Twemproxy慢20%（虽然这对于内存型应用而言，并不明显），到现在远远超过Twemproxy性能（一定条件下）。 我们进行了长达3个月的测试。测试基于redis-benchmark，分别针对Codis和Twemproxy，测试Value长度从16B~10MB时的性能和稳定性，并进行多轮测试。 一共有4台物理服务器参与测试，其中一台分别部署codis和twemproxy，另外三台分别部署codis server和redis server，以形成两个集群。 从测试结果来看，就Set操作而言，在Value长度<888B时，Codis性能优越优于Twemproxy（这在一般业务的Value长度范围之内）。  就Get操作而言，Codis性能一直优于Twemproxy。  ### 3.3 使用技巧、注意事项 Codis还有很多好玩的东东，从实际使用来看，有些地方也值得注意。 #### 1）无缝迁移Twemproxy 出品方贴心地准备了Codis-port工具。通过它，可以实时地同步 Twemproxy 底下的 Redis 数据到你的 Codis 集群。同步完成后，只需修改一下程序配置文件，将 Twemproxy 的地址改成 Codis 的地址即可。是的，只需要做这么多。 #### 2）支持Java程序的HA Codis提供一个Java客户端，并称之为Jodis（名字很酷，是吧？）。这样，如果单个Codis Proxy宕掉，Jodis自动发现，并自动规避之，使得业务不受影响（真的很酷！）。 #### 3）支持Pipeline Pipeline使得客户端可以发出一批请求，并一次性获得这批请求的返回结果。这提升了Codis的想象空间。 从实际测试来看，在Value长度小于888B字节时，Set性能迅猛提升；  Get性能亦复如是。  #### 4）Codis不负责主从同步 也就是说， Codis仅负责维护当前Redis Server列表，由运维人员自己去保证主从数据的一致性。 这是我最赞赏的地方之一。这样的好处是，没把Codis搞得那么重。也是我们敢于放手在线上环境中上线的原因之一。 #### 5）对Codis的后续期待？ 好吧，粗浅地说两个。希望Codis不要变得太重。另外，加pipeline参数后，Value长度如果较大，性能反而比Twemproxy要低一些，希望能有改善（我们多轮压测结果都如此）。 因篇幅有限，源码分析不在此展开。另外Codis源码、体系结构及FAQ，参见如下链接：[https://github.com/wandoulabs/codis](https://github.com/wandoulabs/codis) PS：线上文档的可读性，也是相当值得称赞的地方。一句话：很走心，赞！ 最后，Redis初学者请参考这个链接：[http://www.gamecbg.com/bc/db/redis/13852.html](http://www.gamecbg.com/bc/db/redis/13852.html)，文字浅显易懂，而且比较全面。 本文得到Codis开发团队刘奇和黄东旭同学的大力协助，并得到Tim Yang老师等朋友们在内容把控方面的指导。本文共同作者为赵文华同学，他主要负责Codis及Twemproxy的对比测试。在此一并谢过。

> 原文出处：http://www.infoq.com/cn/articles/effective-ops-part-02 > 作者：萧田国 ## 前言 本专栏的第一篇文章获得诸多同行赞许，也被多位技术大佬转发、点赞，确属始料未及。兴奋之余，诚惶诚恐，思来想去，唯有继续码字，方能聊表谢意。也预祝大家在羊年里幸福快乐，心情愉悦。 春节刚过，广大运维朋友又面临着新的工作压力。让大家苦恼的是，我能力这么好，为什么不幸福？怎么能让工作不那么累心，怎么能多些成就感？甚至，还有机会幸福吗？ 通常，幸福感很大程度来自于外部的认同（以及基于此的自我认同），例如外部门、领导或同事的赞赏。应该只有极少数的人，能在不被外部认同的情况下，还能自我陶醉（那该是何等强大的内心啊）。 导致技术人员不幸福的原因不胜枚举，本文主要针对个人自我管理上容易出现的四大问题，分析其根源，并试图给出些许改进建议。因篇幅有限，至于技术、流程规范等方面的问题，以后单开专题深入分析。 PS： 文末有彩蛋哦（但…不建议直接翻页到最后，谢谢！） 本文略长，主要目录结构如下： [TOC=3] 好吧，我们开始。 ## 1\. 过于追求技术进步及改进建议 技术人员有时会过于追求个人技术进步，有意无意的混淆个人成长和公司要求之间的差别。这样的结果，往往会降低客户满意度，即需求方对我们工作的不认同。这种不认同，又会以各种形式表现出来，并反作用到我们自己身上。 例如，新来一个业务需求，经分析，嗯，有两种方案：1）采用新技术，大概1周完成。可用上自己关注了很久的某新开源软件，看上去一举两得：个人技术有机会进步了，而且是服务于公司的项目；2）采用老套路，3天完成。但没啥技术含量，一堆shell脚本拼凑，对个人而言是重复劳动，而且实现起来很不优雅。 我们会选择哪个方案？实际中往往采用新技术的居多。技术人员（特别是技术能力强的同学），难免对个人能力有所自负，潜意识认为，自己很棒，任何问题基本上都能解决。于是自信满满地和需求部门拍胸脯，然后结果就是……（你懂的，又延期了呗。） 新技术可能导致时间不可控，开源产品可能bug不断，中途遇到问题就麻烦了：社区不完善（发帖半天没人回），网上搜索不到管用的解决方案。反之，老套路时间可控，甚至闭着眼睛都能交活。有差不多现成的脚本，东改改西改改，出了问题也好解决，如果业务实在催得紧，多买几灌某牛加加班，保证按期交付。 其实，需求部门根本不在乎我们用什么技术来实现（而且他们也没必要在乎）。对他们而言，运维是个黑盒子，他们知道的输出结果只有两种：搞定了，没搞定。需求部门最无奈的是，技术人员没搞定，然后拿一堆听不懂的技术分析反复解说，而且自己还得在旁边赔笑脸、假装略懂。 正确的作法是怎样？ 首先，主观上，需要遏制自己的那股技术冲动；其次，提前预估到各种风险，觉得难度有些大，就选用老办法。先按时交付业务需求，然后可以利用空闲时间，搞搞新技术的实现。 这样一来，皆大欢喜。虽然没业务压力的情况下，新技术的完成时间会延长很多。但不管怎样，这时，事情的性质转变了——由公司需求变成了个人问题。 ## 2\. 分不清轻重缓急及改进建议 运维人员其实有相当多的时间，都在用于处理日常业务需求。或者说，一天到晚都在处理故障的情况，并不多见。所以，同比例的，外界对我们的认可程度，较大程度上取决于我们日常工作的交付能力。 分不清轻重缓急是个普遍存在的问题，例如：1）新员工，刚参加工作几年，每个业务人员都说自己的需求重要紧急，可时间就那么多，又想好好表现，于是手忙脚乱；2）老员工，多个需求、问题一涌而来，这时也难免手忙脚乱。 仅仅手忙脚乱还好说，如果因此导致人为事故，业务中断，系统不稳定，大客户流失，重要内部客户不满意，影响公司决策支持，那么就更加麻烦了，而且会严重损害自己的自信心和信誉值。 那么，如何避免此类事情发生呢？可以从以下几个方面改进。 ### 2.1 给事情正确地分类 当手头要处理的工作超过5个，就需要分类了。按照时间紧迫性和重要程度的不同，可分为紧急、不紧急，重要、不重要。手头的各种工作，可以自己搞个白板，按四个象限，分颜色贴上便利贴。  这个图相信不少人都了解过。现在大家可以闭目几分钟，回忆下，想想过去的一周，自己完成的事情，都可以放入哪几个象限，相信结果定会让你大吃一惊。 往往不重要、紧急的事情，占用了我们大量的时间，每个业务人员，都看上去火急火燎，甚至愿意站在办公位旁等结果。另外，不重要、不紧急的事情，有时也会占用我们大量时间。 那么，问题来了，我们允许大量时间被自己低效地消耗掉，对自己有什么好处？好处是：逃避现实（有时也用于逃避重要不紧急事情），寻求一个心理安慰——你看，我也好忙的（备注：这些文字可能会刺痛某些同学，但这类情况还比较普遍，权当共勉！）。 ### 2.2 要事第一的关键所在 要事第一的关键所在，是将更多时间和注意力，放在重要、不紧急的事情上，而不是重要、紧急的事情（这意味着我们能实现卓越、还是止步于优秀）。我们建议至少留出20%的时间，来做重要不紧急的事情。这符合2/8原则，而且，往往也能产生80%的效能。 这样的好处是：可以减少重要紧急、不重要紧急的事情。例如，给某大型游戏导入用户的banner广告出现重大Bug，该广告虽由投放系统动态生成，但需运维同学紧急更新相应CSS文件才能在线上环境生效，这属于重要紧急范畴；正常情况下，这属于举手之劳的小操作，但运维人员在地铁上，不能稳定连入服务器。多悲催？！如果之前持续投入时间，利用Jenkins等实现了Web更新，那就可放权给需求部门自己更新，运维人员甚至不用参与。 纠结之处在于，因为事情重要但不紧急，所以容易被一拖再拖。如果各种痛心疾首后，还是仍然经常忘记重要、不紧急的事情，怎么办？收藏本文章，时不时的阅读一下，如此甚好。 ### 2.3 做事原则、排序原则 各种原则很多，说多了大家也都容易忘掉，这里仅列举3个简洁实用的。 #### 2.3.1 一次只做一件事 技术工作的特性，决定了得有整段时间（一般至少15~30分钟），才能沉下心来、分析解决问题，才有效率。一般来说，一次只做一件事。我们看下最高指导（新华网发布于2015年1月13日）。  有些时候，甚至可以戴上耳机，关掉QQ，忽略非重要邮件。不要把自己搞得有三头六臂似的，貌似很忙，实则瞎忙。 #### 2.3.2 故障是第一位的 故障是最重要紧急的，也应该优先处理。这个貌似很简单的事实，有时都会被忽略。这发生在： 1. 该类故障，并未明确规定第一责任人，大家相互扯皮； 2. 故障第一责任人，沉浸在其他问题的解决中； 3. 故障第一责任人，心急火燎地在想办法，其他人主观感觉和自己没关系，没主动跟进、群策群力去反向推动和解决。 例如公司官网无法访问，这个情况可能是DNS有问题、Nginix挂掉了，PHP出问题了，MySQL出故障了，网络堵塞了。各种情况都可能有，除非有智能监控，故障自愈系统，或者责任人有丰富的处理经验，否则运维部门所有工种，都应该主动去排查自己负责的部分是否有异常，并协助相关同学分析解决。 #### 2.3.3 部门内部工作靠后 如果手头有多个重要紧急的业务需求，应及时向上级请示，将部门内部工作排序靠后，先做部门外的业务需求。 部门内部工作，一般由运维负责人提出，如迁移Zabbix数据库、PHP性能调优、新技术测试等。这类事情，实际上，交付日期是可协商的，往往并非重要紧急。 但也正因为是自己领导的需求，所以，往往被同学们分配更多的时间和更高的优先级，以博得领导赞赏——毕竟，给外部门做得再多，考核自己的，主要还是上级。 这是潜意识指导下的、一种合乎理性的行为，我们不能简单的否定。所以，这方面需要运维负责人的配合：需要主动、周期性的告知部门同学这个观点，并且鼓励这种插队行为（当然，前提是和上级沟通了）。 ### 2.4 怎么更好地接单？ 为了更好地接单，窃以为关键点是，对自己狠一点：接到业务需求时，需主动问询时间节点要求。从经验教训来看，事前商量好，总比事后被人催要好（虽然会有些痛苦）。有些业务需求的回答往往是：越快越好（晕）。这时就得帮助他们设定一个时间节点，而且得具体，不能模糊——如下周或元旦后。一旦达成一致，就是一个契约。 如果完不成，请提前预警。客客气气地说几句好话、打个电话，真诚道歉一把。最怕的情况是，设定的交付日期早过了，需求方来问进展，然后呆萌呆萌地说：我忘了，还没开始做…… ### 2.5 勇于说不，合理拒绝 有办法礼貌地拒绝某些需求吗？还真有办法。拒绝别人得有理有据、不卑不亢。例如，在工作量非常饱和的情况下，业务方（甚至自己领导）来加塞，说又有一个非常重要、紧急的需求，需要立刻、马上开始，而且耗时还较长。这时怎么办？ 这时可以拿出自己的工时分配表来。就说，您看，这是我最近两周的工作安排，都有这些事情，都是给这些部门做的。如果您的事情确实需要我来完成，您可以和这些事情的需求方谈一谈，看是否能做个调配，或者我们也可以一起去找我的上级，看是否能做个乾坤小挪移，等等。 另外，重要紧急往往是对别人而言，要关注那种每个需求都号称重要紧急、恨不得就给他一个人服务的同学。所以，对需求方，我们也可以甄别下，区别对待。 ## 3\. 不善表达及改进建议 不善表达更多是性格使然，关于这部分的原因分析及建议方法，在上一篇[“高效运维最佳实践（01）：七字诀，不再憋屈的运维”](http://www.infoq.com/cn/articles/effective-ops-part-01)中已有重点表述，大家可以参阅一下。本文再次提及，只是因为这个问题，情况普遍、杀伤力大，而且容易改善，效果显著。 喜欢钻研技术，并能寻找到乐趣和认同感，这是运维人员的普遍情况。有些同学和别人讨论技术问题，也能头头是道，在QQ/微信上也话多、幽默。只是一遇到当面交流，就分分钟变成了“沉默的羔羊”。 如果需求方也是个不善表达的同学，相互多少有些“宿怨”，在日常沟通中再夹杂着情绪，那可能就更加不好。有例为证。  这种情况并非少见，是求虐、求投诉么？多说几个字，用些客气的字句、来些语气助词，真的那么难？必须得惜字如金么？又不是从身上割肉，不用舍不得…… 改善客户界面，首先从意识层面反省，是否存在客户界面不友好的问题。解决方法包括，尽量当面沟通，真诚道歉。 ## 4\. 爱抱怨及改进建议 我们是公司的一份子，小公司问题很多，大公司更有各种通病。在一家公司呆个一年半载后，往往发现不如当初期望的那么美好，心情不畅，再加上还得面对生活的各种压力，难免各种坏情绪纷至沓来。 其中，抱怨是我们最常见的情绪之一，甚至是一种背景式的存在。观察下我们脑海里不时冒出的自言自语，十有八九是抱怨。牢骚太多防断肠，抱怨可能会集结成怨恨、甚至怨气，严重损害自己身体。 ### 4.1 抱怨及其本质 抱怨隐含的意思是：我是对的，并将自己放在一个幻想中的道德优越感上。抱怨是一种低调的攻击，常被用于自我保护，捍卫自我。抱怨的，都是过去的事情，会白白的消耗自己的能量。（话语可能有些刺耳，请大家尽量看完下面的文字。） 建议轻度抱怨，勿沉迷，别走心。如果把抱怨当做朋友间的一个话题，也无伤大雅，当然，希望在这些时候，你知道自己是在抱怨（观察到抱怨的过程，很有意义，但也很难，不信你试试）。 事情不会因为我们抱怨，就变少。反而因我们抱怨，可能变得更加繁杂。 抱怨越多的人，往往是被抱怨越多的。其结果往往是，消极被动。所以好消息是，积极主动，专治抱怨。 另外，我正在策划一个情绪管理的专题“我的战争”，里面有对抱怨、焦虑、恐惧等常见情绪的更多剖析，敬请期待。 ### 4.2 积极主动的真正含义 美国管理学大师史蒂芬·柯维在资深畅销书《高效能人士的七个习惯》中，给积极主动下的定义很有意思：当我们的行为，将影响圈扩大（借此蚕食关注圈——萧田国注），则被称为积极主动，否则就是消极被动。 所谓影响圈，就是那些我们能掌控（直接控制）的事情；而只能间接控制、或无法掌控的事情，都属于关注圈。  那么，我们能掌控的事情，都有哪些？思来想去，其实也就是自己的行为。如果我们管理着一个团队，可以指挥同学们做这个、做那个，这属于间接控制的事情。天气，则属于无法控制。 我们往往将注意力放在关注圈，这是导致抱怨、并且被抱怨的重要原因。 举个例子，业务推广因为网站不堪重负而失败，老板开骂。这时： > 网站运营说，我早就告诉运维负责网站的哥们了，他就是不给我好好搞； > > 网站运维说，我早就告诉系统组的同事了，他就是不及时给机器； > > 系统运维说，我早就告诉采购部门了，他们一直没给我机器； > > 采购部门说，我早就告诉供应商了，他们说缺1TB的硬盘，没法发货。 大家都对，但也都不对。例如，对网站运维而言，没法把控系统运维的服务器交付日期，但自己能做的事情，真的到此为止了么？这个情况，你是否及时向自己的上级和业务部门汇报？是否真的没办法，从自己负责的业务中，临时调拨下？ 对系统运维而言，是否真的不能从别的业务借用几台服务器先扛着？对采购部门而言，是否真的不能从服务器供应商借几台服务器先用着？ > 【问】我周遭的环境这么糟糕，我都苦不堪言了，你还让我积极主动，你不是在往我伤口上撒盐吗？ > > 【答】真的抱歉啊，朋友们。大家都是苦水里泡大的，个中滋味，我感同身受。只是，除了改变自己，我们真的不能再做什么了啊。权当良药苦口了呗？一起共勉之。 ### 4.3 通力合作 如果出现重大故障，不要先假设自己负责的部分（如数据库）是没问题的，并带着主观倾向去分析问题，这样在言语表达上可能让人反感，而且也往往不正确。  另外，也不要觉得自己负责的这部分没问题，于是对发生的重大故障，就再也不管不问、隔岸观火。应该主动和大家一起分析讨论，群策群力，解决问题。如果下次你负责的这部分出现了严重故障，其他人都漠然坐上观，你是否也会寒心？ 还是那句话，大家是一条线上的蚱蜢。重大故障出现了、长时间未解决，公司和外部门会说，你运维部不行、不专业。这时候，即使能独善其身，又有什么用？ ## 彩蛋 实在搞不懂轻重缓急，怎么办？这个好办，问上级呗，千万别自己憋着。领导是干什么的？不就是帮属下分忧解难的么，呵呵。甚至，偷偷地说，如果有个需求，实在完成不了了，也不要老是自己去和外部门解释，可以请领导出面。自己领导和需求方领导聊一聊，可能大事变小事哦。 下一篇文章，我们谈技术，主题暂定“高效运维最佳实践（03）：Redis集群技术及Codis实战”，敬请期待。

> 原文出处：http://www.infoq.com/cn/articles/effective-ops-part-01 > 作者：萧田国 ## 前言 做运维的那么多，快乐的能有几个？ 我们那么努力，为什么总感觉过得那么憋屈、苦闷？做的事情那么多，为什么业务部门、直接领导和公司貌似都那么不领情？怎么做才能自己更加开心些？ 本专栏的主线实际是一个运维人员的十年成长史，从菜鸟到运维总监。但不是基础技术教学，也不会在运维技术的某一方面过深涉及。更多的是应用技巧、实践经验及案例剖析。专栏中的系列文章，包含作者在运维各个细分领域的技术和个人成才的心得体会。因此也可以成为广大运维朋友的工具书，伴随大家从初级运维成长为高级技术型运维管理人才。 技术专栏就非得那么中规中矩么？咱这个专栏试图以更轻松活泼的文字，徐徐道来，就当是个老朋友，轻松愉快中，希望能给大家带来收获和启发。 * * * 前段时间有位IT大佬在网络上发声，我这么有钱，为什么不幸福？诚然，有钱是幸福的最重要条件之一，但有钱就一定幸福么？真的是充分必要条件？当然更悲催的是运维行当，技术好是被认可（幸福）的最重要条件，但技术再好，外部门不说咱们“坏话”，已经是很不错的了。 补充一句：本文实际上既是本专栏的开篇，也是综述。后续专栏文章，会就各个部分，进行详细阐述，敬请期待 。 本文略长，主要目录结构如下： [TOC=3] 好吧，我们正式开始。 ## 1. 什么是高效运维 我们收集了一些来自外部门对运维的印（tou）象（su），如下图所示。其中，大家看是否也多少有自己的影子？  往往看自己都很美，但从外部门来看，槽点多到乃至无力吐槽。首先，做事情不专业，人为事故多（更多是低级的人为事故）；很多时候，都是我们业务部门告诉运维，运维才知道发生故障了，而且故障解决时间过长；做个调试，老超出调试时间，超时也不说，是不是完成了也不知会一声；部门内老玩踢皮球的游戏，做个需求，老让我挨个找人；申请个服务器，老费劲了，扔我一个申请表，当自己是衙门呢？或者扔我一个技术文档，我哪看得懂？ **专业、热情、方便、快**，这是为根治上述各种疑难杂症，经多年自我治疗并综合各方经验，得出的高效运维七字诀。我们用一个简单的公式来表示高效和专业的关系。专业是高效的基石，否则无从谈起高效与否，而技术是专业的基石。但这恰恰也是运维技术人员的误区所在，误以为，技术比较强，就足够了，并因此而忽视其他重要方面。  实际上，对外部门而言，运维是个黑盒子，是一个输入输出的关系：外部门提出需求，运维给出结果：完成、或未完成。本质上而言，外部门不关心（也无法关心）我们采用什么技术来实现的，只关心是否如期完成。 合理的流程规范，就像血液，能让部门稳定而高效的运转，大家都觉得开心，这也是专业与否的重要组成部分。但如果希望做到高效运维，良好的客户界面、合适的方法技巧，也非常有必要。这就像网站的UI，给人感觉舒服了，后面很多事情也能轻松愉快、顺理成章地进行。 ## 2. 为什么难以做到高效运维 做不到高效运维，公司和业务部门不满意，上级领导不满意，自己也不满意。原因很多，我们从管理者和员工角度分别来讲。 ### 2.1 糟糕的分工及连环反应 发生在中小公司的糟糕情况，往往从不明确的分工，开始悲剧之旅。有些游戏创业公司，刚开始时运维人员也就2、3个，基本每人都得会运维的各个工种，游戏运维、网站运维（Nginx/PHP等）、数据库运维（MySQL等）、系统运维（Linux/Windows等）、服务器上架、故障报修、甚至做网线。 公司业务扩大很多后，如果运维组织结构不随之而变，分工不明确，就会发现大家都在疲于奔命，什么都会的结果就是什么都不精。在运维技术如此庞杂的今天，就是把人活活的架在火上烤。这样引发的是多米诺骨牌效应：分工不明确 —> 职责不清楚 —> 考核不量化—> 流程不合理—> 缺规范 、少文档。 ### 2.2 做vs说的困境 一般运维技术人员都不善于沟通（至少表面上，虽然大家都普遍有火热的心，呵呵）。在微信、QQ大行其道的今天，这个问题变得更严重，而不是减轻。这也和工作性质有关，想想，一天到晚和服务器说话的时间，比和人说话时间都多。 另外，从人脑结构来看，做和说两难全，也是合理的。控制计算、推理能力的是左脑，而表现力等由右脑控制。如果强行要求会做还会说，说不定会导致紊乱、崩溃甚至“脑裂”呢，呵呵（当然，这个问题也是有解决方法的）。 更严重的是，很多同学没意识到自己的沟通表达是有问题的，说句话能把人呛死，也不知道如何有效表达。这样就谈不上热情了。 ### 2.3 资源错配 管理者和员工都可能存在资源错配的问题。对管理者而言，包括人员错配和时间错配，员工主要是时间错配。 管理者如果把错误的人安排在错误的岗位，那么注定是个错误。例如，某位同学喜欢钻研技术，不喜表达，非得让他作为和外部门的接口人，那自然费力不讨好，大家都不开心。 管理者的时间错配包括三种情况。 1）**沉迷解决技术问题**。这一般发生在刚从技术岗位提拔为管理者的时候，忘记自己是管理者了。解决复杂技术问题，能带来愉悦感，否则就是挫折感。于是遇到技术问题时，非得死磕到底，然后一周过去了，而部门其他同学却放羊一周。 2）**一心扑在管理上**。这又是一个极端了，忘记自己的技术身份。把自己变成一个项目经理，整天只关心时间节点，不关注技术人员的小情怀，不协助他们解决具体的技术问题。 3）**沉迷单个业务模块**。这是另一个特例。一般发生在内部提拔时。例如某位同学，之前是DBA组的负责人，提拔为运维部经理后，还是习惯于抓其擅长的数据库工作，这也是不应该的，否则就没必要提拔了嘛。 员工的资源错配主要体现在时间安排上。事情多了，分不清轻重缓急，没有一个合理的排序原则、指导思想；混淆技术进步和工作要求（有时过分追求技术进步），简单的问题复杂化，降低客户满意度。 ## 3. 如何做到高效运维 高效运维从来不是一个简单的事情，需要多方面共同努力来实现，本文先择其要点简述之，以后专栏系列文章会有更多深入阐述。 ### 3.1 明确分工/职责 美国著名管理学者史蒂芬·柯维在畅销书《高效能人士的七个习惯》中提出了产出/产能平衡原则。想多产出，先得扩大产能。想金鸡多下蛋，就不能杀鸡取卵。那么对于高效运维而言，产能是什么呢？ 包括三部分：1）**框架**，即合理的分工/职责/KPI，抱歉我提到了KPI，多么让人如此爱恨交织的词语；2）**血液**，即专业的流程/规范；3）**界面**，即良好的服务意识/技巧。这些投入足够多，才会得到心仪的产出——高效运维。在贯彻实施这些一段时间后，外部门会诧异的感觉：哟，怎么运维变化这么大。虽然他们不知道原因，但我们可以微微一笑，呵呵。  具体到运维部门而言，我们的分工，区别于内网IT部。一个是服务外部客户，一个是服务内部客户，差别还是蛮大的。根据部门分工，拆解出各个小组的分工，再落实到每个员工头上。有章法，大家也觉得舒心。 运维是支持部门，成本中心，难以产生利润。所以其中重要的考核指标其实是客户满意度，请相关业务部门给运维同学打分，运维内部根据分工，也可以相互打分，这对应着外部满意度和内部满意度。KPI虽然令人不舒服，但总的来说，还是有存在的合理性。  ### 3.2 技术的专业化 技术上的专业化运维，涉及面也很广，下面仅列举几例。 #### 3.2.1 优化监控系统 谁来监控监控系统？怎么保证比业务部门先发现问题？是否需要添加业务监控？URL监控是否返回状态码200即万事大吉？是否需要文件监控？短信报警、邮件报警是否足够？是否需要自动语音报警及垂直升级功能？ 监控是门学问，是专业运维的入口。展开说可以很大篇幅，先抛砖引玉，提出这些问题。实际上，对于资深、聪明的运维同学，看到问题，就已经有了自己的答案。 #### 3.2.2 减少人为事故 人为事故是运维最头疼、最不专业的事情之一。例如网站运维中，如果每次更新都需要登录服务器，svn update/git pull，难免会出差错。所以可以用类似Jenkins的工具，实现Web更新，这样，除非重大更新（包括数据库更新），否则都只需要点点鼠标即可。甚至，可以把网站更新外包回开发部门，这样还能减少运维操作带来的沟通成本、时间成本。 #### 3.2.3 运维自动化 运维自动化是个大课题，网络上的讨论也很多。建议选择合适自己的方式、方法。轻量级工具如ansible，无需在被管理服务器安装客户端程序，这在针对多台服务器进行分发管理（特别是管理仅有临时账号权限的服务器时），具有较大优势。另一个吸引人的地方是，操作结果和操作日志集中存储。 #### 3.2.4 合理优化架构 近几年国内优秀的开源软件层出不穷，设计和优化架构，很多时候并不是非得自己从零起步来搞。例如Redis，以其高效、稳定，已成为缓存系统的最好选择之一，但Redis单实例的支撑能力有限，目前Redis集群的实现，大多采用Twemproxy，但使用起来老感觉有些美中不足，那么，有没有一个取而代之的产品？ Codis就是其一，Codis由豌豆荚开源，并广泛用于其自身的业务系统。Codis刚好击中Twemproxy两大痛点（无法sharding，运维不友好）。Codis可以平滑的扩容/缩容，随时增减Redis服务器；并提供友好的运维界面，不仅能看到Codis系统运行情况，还能进行数据迁移、主备切换等操作。  另外，Codis还提供工具，将依赖于Twemproxy的Redis集群，平滑的迁移至Codis（太酷了，那画面太美，我简直不忍看）。性能方面，经我们实测，在正常Value长度下，Codis的get/set性能，优于Twemproxy。 #### 3.2.5 代码持续部署 线上系统程序代码可否自动打包、持续部署？ 测试环境的新版本发布可否由开发人员自己来做，甚至自己来做测试？ 这些无疑可以很大提升运维和开发效率。 Docker高可用集群，加上Jenkins发布，可以把这些需求变成现实。Centos 7的systemd用来底层支持Docker高可用，etcd实现了配置文件的集中存储，而不是分散在各台服务器的本地。fleet作为etcd和systemd之间的桥梁，并通过systemd来控制集群服务器。 Jenkins从svn服务器获取到新代码版本后，通过shell脚本，打包成image，放入Docker私有库，从而被Docker集群服务器update并使用。  ### 3.3 管理的专业化 管理上的专业化运维，甚至包括调试通报和故障通报，都很有说法。系统运行一段时间后趋于稳定，调试/更新就变成了故障的主要来源之一，怎么让调试少出人为事故，顺利如期的完成？这是个技术活。 #### 3.3.1 运维345法则 故障通报是细究故障的不二法门，一次长时间的故障，往往有很多细节可以推敲，我们总结出运维345法则。3是指故障时长被分成三部分，4是指对应的四个故障时刻点，5是指在这个过程中我们可以做的五件事。这样，我们就可以有的放矢地进行优化解决了。  #### 3.3.2 不要让流程吞噬责任 流程规范是很好，不可或缺，好处谁都晓得。只是，流程有时会成为挡箭牌，会让人变得本位，不愿担当，也不愿从事个人职责之外的事情。  这其实是错误的、短视的，“害人害己”的。如果真的出了一个非常严重的故障，个人就能“出污泥而不染”么？没戏。如果是顶级故障，老板想的甚至是把整个运维部门端掉，皮之不存、毛将焉附？ ### 3.4 良好的客户界面 伸手不打笑脸人。合适的言语表达，可以大事化小、小事化了，反之亦然。只是对做技术的运维同学而言，这是很不容易的事情，甚至有人宁愿多加班，也不去和人沟通。但，工作的要求有时往往需要善于表达，其实也可以换个角度想，把良好的沟通当做一门技术来攻克，如何？ #### 3.4.1 当面沟通 即时聊天工具如QQ、微信实际上是加剧了沟通成本。大家变得更加依赖与此，本来当面沟通或电话沟通，几分钟就能说明白的事情，来来去去几十分钟，更有甚者，还能吵起来，没法愉快的玩耍了。根据国外一项调查，一次有效沟通中，词句内容仅占据一小部分。  我们一般都会要求素未谋面的小伙伴，先当面聊一下。举个真实的例子，有位同学之前和某位运营同学一直QQ、邮件沟通，某次实在说不清楚，于是面聊，发现对方居然是个美女，于是之后合作很愉快（虽然美中不足的是，该女士已有男友）。 #### 3.4.2 来的都是客 做运维的，应该放下身段，不一定非得低三下气地做事情，但至少意识得到位。运维的沟通中，也适应心理学的投射原理：越是觉得别人盛气凌人、服务不到位，其实自己也往往是这样的。 来的都是客。如果自己实在忙不开，响应慢。礼貌用语总是可以的嘛，不好意思，对不起，抱歉，谢谢。 ## 4. 小结 絮絮叨叨说了这多，也不知大家看烦木有。运维很苦闷，让苦闷的人变得更苦闷。但不管怎样，也是一门技术。这年头，有门手艺，虽然发达需良机，但至少生存无忧。话说回来，哪行都不容易。 本人做运维这么些年，结合各种失败与成功、痛苦与苦痛的经验，终于悟出高效运维的七字诀：专业、热情、方便、快。不一定完全适合您，但终归是多年的领悟，自成一个小体系，如各位盆友喜欢，以后逐一阐述，如能对大家有所裨益，幸莫大焉。 对了，下一篇文章的主题类似《我技术能力这么好，为什么不幸福（员工篇）》，如您愿意，可以持续关注。

## 专栏介绍 > “**高效运维最佳实践**”是InfoQ在2015年推出的精品专栏，由触控科技运维总监萧田国撰写，InfoQ总编辑崔康策划。 ## 关于作者   **萧田国**，男，硕士毕业于北京科技大学，目前为触控科技运维负责人。拥有十多年运维及团队管理经验。先后就职于联想集团（Oracle数据库主管）、搜狐畅游（数据库主管）、智明星通及世纪互联等。从1999年开始，折腾各种数据库如Oracle/MySQL/MS SQL Server/NoSQL等，兼任数据库培训讲师若干年。 曾经的云计算行业从业者，现在喜欢琢磨云计算及评测、云端数据库，及新技术在运维中的应用。主张管理学科和运维体系的融合、人性化运维管理，打造高效、专业运维团队。