【51CTO原创稿件】任何计算机系统都有出现故障的时候，小到一个终端的软件无法使用，大到整个系统瘫痪，所有业务不能办理。这也是系统管理员或者运维工作者最担心的事情。如何做到快速定位故障问题，合理分析故障成因，找出排查方案是管理者们需要了解的事情。在阿里巴巴集团主办的ADC·阿里技术嘉年华大会上，51CTO记者有幸采访到了从事阿里集团云计算平台的一线运维刘毅（@毅毅），看看他是怎么做到的吧。
以下是采访实录：
不同平台运维工作的对比
51CTO：刘毅你好，首先请大概介绍一下你自己的经历和现在的工作职责。
刘毅：我之前在eBay COC负责UNIX系统运维，离开COC之后，2010年加入阿里集团，其实最开始招我进来的是阿里云，集团的云计算平台也是刚刚开始，差不多三年，我就伴随着云计算平台逐步成长，在一线参与了集团云计算平台一线运维工作。
51CTO：所以你主要关注的一些领域就是云计算相关的？两家公司的工作模式和工作职责相差大吗？
刘毅：区别还是比较大的，在eBay负责运维的是成熟的应用，整个应用架构是全冗余的，高可用性，并且较多的使用商用解决方案，而且他们在商用解决方面的预算是不菲的，相对来说，运维对底层的稳定性会依赖于厂商支持，商用负载均衡设备的广泛使用也不会因为单台的服务器不可用而给我们运维造成困扰。
***次接触到云计算平台运维的时候，我感觉一下回到了石器时代。大概意思是运维环境非常恶劣，每天有个两三台服务器宕机是再正常不过的事情。没有存储，没有带库，数据都是存放在本地硬盘，每块硬盘上的数据随时都可能丢失，数据的冗余全靠云平台自身解决。这就苦逼我们运维了，我们要帮助云平台去解决各式各样的问题，它解决数据冗余的问题，并不意味着机器不用恢复，硬盘不用替换，紧急情况不用处理了。前3个月，最的最多的就是重复劳动，感觉没有价值，简直是劳动密集型产业。怎么办？我们需要工具，自动化工具来帮助我们摆脱重复劳动，shell、perl、python，只要能提高效率的，我们不区分工具语言，不过还是Python使用的最广泛。渐渐的从命令行自动化做到web自动化，点点鼠标完成5000台服务集群的停起，升级、查看状态信息等工作。感觉很***了？还没有，这些仅仅是表面的改善，我们现在期望从运维着的这些上十万台服务器，每天产生的硬件日志、系统日志、应用日志之间，在这些庞大的数据里，就像挖金矿一样，挖掘出能够改善我们运维、应用的方法，今天的我演讲的主题就是一个数据化运维的例子。
51CTO：目前你们团队的规模大概是什么样的情况？
刘毅：我所处的团队目前人数20人不到，也是从4-5个人发展起来的。他们有负责离线平台运维，在线平台运维，还有负责相关运维自动化。基本上每个人都会了提高运维效率而写代码，看代码。花费大半的精力来维护优化自己的运维工具。工具写的越多越感觉到需要用数据的分析来帮助我们判断怎么样做才是高效的，借助我们身后平台的力量。
51CTO：你们的客户相当于就是为阿里云提供？
刘毅：我们主要是服务内部的开发客户，但是我们的运维业务呢也有服务外部客户的。比如药品监管码。通过监管码，可以追踪药品从生产、仓储、销售的全过程，这些数据就存储在我们运维的服务上。但是呢这些还是少数，我们目前主要是支持集团内部的业务和开发客户。#p#
阿里巴巴云平台运维故障排查
51CTO：你们平台平时出现故障频繁吗？
刘毅：平台建设的初期，因为不稳定，故障比较多，当时挺累的。随着平台稳定，自动化工具的成熟，局势已经扭转过来了。
举个最最简单的例子：过去做运维，因为底层硬件可用性、冗余度高，宕机率都是按年来计算。而现在这些廉价的PC服务器，几乎每天都会有宕机，这对同样是处于初期的云计算平台的冲击还是有的，所以一台服务器，或者一块硬盘都可能会影响到整个服务集群的稳定性。而现在有了这些经验的积累，不管是平台自身还是运维手段都有办法来规避底层硬件不稳定的问题。
再举个更细节的例子：过去运维不需要关心硬盘的维修，我们都知道甄别坏盘是存储设备的基本功能，而且往往能贴心的亮起指示灯，可以说整个过程除了主动向厂商报修，运维不需要做任何事情。但是在我们云计算平台初期不行，开始运维就像保姆一样要跟踪整个过程，我们要主动发现，要及时修复，发现晚了，可能就是一个故障、修复不及时可能空间就紧张了，听起来好像很夸张，如果你看了我分享的几个运维数据，真是那么一回事儿了。这些事情很重要，重复度又很高，特别是在大规模服务器下，我们不能每天去重复劳动，对运维价值的提升不大、对平台稳定性也毫无益处，我们就用自动化解决，把这些廉价服务所不能做的带来的问题，用我们的自动化工具变得像之前昂贵的存储设备那样的智能。这很有意思，你会感觉你和云平台一起在成长，停不下来，比如说，仅仅是发现还不够，我们还要做预测，硬盘作为机械设备，随着时间增长，肯定会老化，老化会带来各种各样的问题，比如性能慢，不响应。那么我们通过研究磁盘参数，做到磁盘健康的预测。首先这些参数都是厂商定义的，偏理论，但能不能用 ，好不好用，但是我们拥有庞大且真实的实际数据，把这些数据采集并且在云平台下做数据分析挖掘，提炼适合我们不同业务场景下的磁盘监控度的预测，最关键的是取到好的效果和反馈，特别是在关键战役，双11之前，做到预测结果不好的硬盘提前下线，避免关键时刻掉链子。
举了2个例子，平台不稳定、故障多不会是常态，通过运维自身的演变，可以让那些紧急的、危害大的运维异常变成可控的、影响小的运维事件。
51CTO：除了你刚刚提到的硬盘，其他的还有哪些比较容易导致故障？
刘毅：硬盘只是一个例子，我们把它归结为硬件故障，除此之外呢，还有就是软件bug。再者就是人为的疏忽造成的。
51CTO：你刚刚说运维分了很多种。出现什么故障的时候是不是流程也会复杂？
刘毅：复杂是相对的吧，如果公司人少，再复杂也不复杂到哪里去，想阿里这么大的公司，相对来说肯定要复杂一些，但是我们集团内部有团队会负责和改进流程，不管是故障流程，还是日常的各种流程。
51CTO：是说出现哪个方面的故障，然后是有人判断，然后确定是哪个组负责的，然后就派那组去解决？
刘毅：对的，会有一个责任人或者责任部门，但是原因和改进措施需要大家一起来配合做。
51CTO：你们这边工作的效果是怎么考核的？因为这几天也是听了阿里其他团队的人来讲，比如说像是做云的，他可以说我提供这个服务给你们。或者是提高软件性能的，他也可以说我作为业务，我提供给你们，帮助你们的服务做的更好。对于你们来说，客户已经固定了，成了一个保障部门。那你们这边的具体考核方法是什么？
刘毅：考核并不是恒定不变的，个人的考核办法一定是保障团队目标的前提，而团队一定是保障公司目标的，具体来说，作为运维，至少要有东西运维，才能说有价值吧，这时候又不能挑业务，不能说这个业务容易出彩，运维风险又小，我就要去运维，凭啥让给你？对吧，开始只能有什么运维就运维什么，主要考核就是你有没有运维好，有没有故障，有没有提高效率这些硬性的运维指标吧。随着业务的壮大，运维的场景变多，招人也算是考核指标吧，一个是业务扩大、一个是团队成长，都需要新鲜的血液。还有就是资源利用率、怎么用好手上的服务器，这非常考验我们运维。还有双11，这也是个重要的考核指标吧。
51CTO：***谈谈你个人的未来发展问题吧，你自己是怎么规划的？是一直做运维？还是转开发，或者别的？
刘毅：我想我不会转开发，我觉得运维不错，一直做下去。因为我觉得现阶段运维很有趣，也很有挑战。想想怎么把各种系统数据、应用数据收集起来，用云平台帮我们分析，提炼出有帮助、有价值的内容，真是太有意思了。因为***、很多方面我们没接触过，比如数据挖掘，需要我们不断的充电，第二、经常有被颠覆的感觉，不是这样的感觉，比如我们预测硬盘健康的时候，并不是说我们拿一个值，越大越好或者越小越好，真实数据告诉我们是有临界区间的，而且找到这个临界区间。这很有意思、很有挑战，把日常无序、杂乱的运维数据变得有用的，很有成就感。在云计算时代，真真切切的感觉到数据的强大，我想我会沿着数据化运维的方向走下去，把那些运维异常变成可控的运维事件。
51CTO：变成一个可控的。
刘毅：是的，这很有意义，做到可控就很有意义，但是很难，以前我们会说凭经验，凭感觉，世界变化这么快，怎么知道经验是可靠的？如果还靠一次次故障堆积经验，是否还合算呢？业务千变万化，适应客户要求，我们运维怎么办？很多事情，可以这么做，可以那么做，我怎么说服你呢？其实***这些的答案就是数据，现在感觉所有自动化都是为了数据运维而准备的，在数据化运维我还不知道我有没有找到大门，我不知道在哪儿，我刚才举的介个例子，可能是对的，可能是数据样本不够，还不够准确，这就是又有趣又有挑战的地方，我想我暂时还痴迷着这些，呵呵。
好的，本次采访到这里就结束了，非常感谢刘毅的分享！如果您还有其它的问题或者建议，欢迎留言讨论。
【编辑推荐】
【责任编辑：黄丹 TEL：（010）68476606】
