本文是互联网专栏《高效运维最佳实践》的第08篇文字，由萧田国原创并授权“高效运维服务中心”公众号转发。本文未经作者授权，谢绝转载。 引言
在运维还被普遍认为是一个技术工种的今天，大家对“人”本身及提高运维人员综合素质的关注度和重视度，究竟如何？从我们了解的情况来看，不容乐观:
高效运维最佳实践专栏的系列文章，一直关注“人”在运维中的价值，各种观点散见其中；本文汇聚起来，并做提炼和升华，请大家欣赏。 以人为本的高效运维体系高效运维体系包括主要分为三层，从下往上为框架、血液和界面（框架可以理解为骨架，这既是个金字塔形，也是一个“人”的雏形）。 ITIL将运维分解为PPT，即 People，Process 和 Technology，这个分法很好，可惜的是纵览全书，也很少讲述关于“人”的内容。 也有人将运维分解为组织、制度和手段；这个和高效运维体系是有吻合的地方：“框架”即组织，“血液”包括制度和手段。但高效运维体系特有的是“界面”，即特别强调的服务意识和技巧，这也是以人为本的重要体现。 什么是以人为本？所谓以人为本，我总结为5点，供大家参考，即：理解人；尊重人；扬长避短；鼓励、培养；根本出发点。 人天性爱自由，有时比较懒；有时也会有意无意地扯皮、推卸责任；希望得到尊重，希望被认可；难以看到自己的缺点，潜意识认为自己是完美无缺的（特别是女性朋友）；有时急于求成，希望“多快好省”的完成目标，赢得赞赏，然后阳光沙滩美女晒太阳去了。 但需要注意的是，不要试图站在道德的制高点上，对上述这些，批判或指责。因为，他们只是内置的人类需求的外延和扩展。 运维人员虽然普遍比较内向，不愿意表达和沟通，但并不妨碍遵循马斯洛需求的五个层次。内心深处都是普遍渴望爱和关怀，虽然受了怎样的委屈，也都是再苦再累自己默默地扛。 所谓以人为本，首先是对人的理解和尊重，并针对人员特点，扬长避短。但这只是第一个层次。更重要的是，在涉及运维的方方面面，都遵循这点，并作为一切工作的“根本出发点”。 作为根本出发点，知易行难，需要我们在设置组织，设计流程，制定规章制度和实施运维自动化时都秉承之。例如：
把“以人为本”作为根本出发点，还要求我们着重培养人员的综合能力，改变那些愿意被改变的人（可燃性的人）。日本著名企业家稻盛和夫有一个著名的燃性理论，这里所谓的“燃性”，是指对事物的热情：
为什么要以人为本？必须坚持以人为本的根本原因在于，运维人员基本都是知识工作者（一般至少大专毕业），能否充分发挥其主观能动性，决定了生产效率高低：
运维行当出现也就十多年，很多人开始做运维，都是对比着搜索出来的文章，依葫芦画瓢，部署LAMP等（即使运维自动化，也往往仅适用于特定场景）。这种情况下，需要不断发挥运维人员的聪明才智和主观能动性。 运维要解决两大问题总的来说，运维要解决两大问题，即人和人的问题，以及人和机器的问题。运维伴随着计算机和网络而出现，向来是野蛮生长，所以一开始投入大量精力到解决人和机器的问题（包括运维自动化），也是合情合理的：
运维终归要解决人和人的问题，例如学会怎么让自己的工作卓有成效、产生更大价值，辅助和影响运营决策，甚至通过减少成本来间接创造利润。简而言之，让自己更多的被认可。 而且，解决人和机器的问题，也是为了更好地解决人和人的问题，你说不是么？ 另外，运维自动化再流弊，也需要人来操作。就像飞机造得再好，仍然需要人来驾驶。而且，运维自动化越充分的情况下，如果操作人员的水平不提高，往往风险更大，毕竟，让开拖拉机的来开飞机的话，后果可想而知。 怎么做到以人为本？运维可以分为组织、制度和技术，下面我们分别从这几方面，通过案例来阐述“以人为本”的落地。 以人为本的流程制度流程在规范公司行为的同时，也经常变成壁垒和阻碍业务的绊脚石之一。怎么合理地优化流程，也能体现运维的价值。 例如，服务器申请流程是运维部门和业务部门主要交互的环节之一。因为涉及到费用的产生，对于中小企业而言，这个流程可能需要多个部门联合审批（包括采购和财务），甚至包括公司高管和CEO等。 如果业务部门有着急的服务器需求，运维人员可以流程为理由，说：“你看，不是卡在我这里，我也无能为力”。但其实也可以更进一步做些事情。 例如可以建议优化流程，对于申请服务器数量少或总金额不高时，仅运维负责人审批即可（跳过图例中的“8高管审核”和“9CEO审核”）：
另外，对于CDN申请流程，也有可以优化的地方。 无论申请下载CDN或网站CDN，都必须配备一个加速域名。考虑到域名也是重要资产，这样一来，CDN 申请流程就需要完成一个前置流程，域名申请。 其实，为了提高业务部门和运维部门的工作效率，可以简化CDN 申请流程，使得业务部门不需要去提交域名申请流程，而是内置的在平台中实现。毕竟，一则CDN 用的域名都是对内使用，不需要严格的域名管控；二则不可能不给配备域名。所以，还不如顺水推舟。 以人为本的技术以人为本，可以做为基本出发点，影响和改变运维管理者及技术人员的时间分配，将更多的时间投入到抵消“人性的弱点”的工作中来。 因篇幅有限，我们在此略举两例，即监控的语音报警和Docker 持续部署。 现在大部分公司都基于 Nagios 或 Zabbix 实现了邮件报警和短信报警。但如果据此要求，运维人员时时刻刻盯着手机短信，半夜三更睡觉也不安稳，终日生活在焦虑和隐隐的恐惧中，那无疑就是不合适，“反人性”的了。 正确的姿势是，Zabbix 结合 Nexmo 等实现电话语音报警，并加以垂直升级功能。当报警出现时，由Zabbix 服务器推送到语音报警平台，后者再通过Nexmo 等语音接口，自动拨出电话：
语音报警平台需要自己开发（即图中白底流程。这是时间和人力主要投入的地方，但相信我，投入产出相当划得来），一般基于Python 即可。 语音报警平台还应实现垂直升级功能，即设定多级报警响应人，电话自动拨出给第一级，如3次未接通，则自动拨出给第二级。 语音报警平台的日志有时能发挥“神奇”的功效，曾经有一线响应人员说没接到报警电话，结果登录平台一查，根本无从赖账。 上图为一次测试，可见尾号*1991的手机被多次反复拨打。 另外，持续集成和持续部署和可以极大地降低对人员操作能力的依赖，融洽人员关系，较大程度地消除分工带来的效率低下。 “常在河边走，哪能不湿鞋”。让身为知识工作者的技术人员日复一日、年复一年的进行重复性、日常操作性工作，既容易出各种人为事故，也是对操作人员生命价值的不负责任。 瀑布式开发流程，将开发、测试和运维割裂开来，这种分工是造成效率低下的根本原因。这不仅仅影响开发人员的效率，往往也容易被开发当做“犯懒”的借口。例如：
持续集成对“人性”的最大好处是提前暴露问题，而不是像以前，一到大版本发布，就如临大敌，几十上百人如临大敌、彻夜通宵。持续部署使得开发人员可以自己发布代码，第一时间对自己的软件bug 负责（而不是揪心地等待测试、运维）。 上图是基于Docker 持续部署的实现，只就持续部署而言，再怎么赞赏Docker 的丰功伟绩都不为过。Docker 实现了天然的环境和代码托管。 本例中，开发人员修改完代码，敲入 git push，略等几分钟，无须人为干预，代码即可自动部署。关于实现的更多细节，可以参考旧文： 声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系 [邮箱地址] 删除 |
注册
登录
