主编
黄丹
封面制作
苍旭
审阅
《趋势》评审团
出版方
51CTO系统频道
（https://www.doczj.com/doc/708817948.html,）
出版日期
每个月的最后一个星期五（理想状态）
邮件订阅
h t t p://o s.51c t o.c o m/ art/201011/233915.htm RSS订阅（最早发布）https://www.doczj.com/doc/708817948.html,/ php/rss.php?typeid=777
iPad订阅
《读览天下》客户端
联系电话
010-********-8136
投稿邮箱
huangdan@https://www.doczj.com/doc/708817948.html, 主编的话
七月，是烂漫的季节，是多雨的季节，七月的北京更是如此。可能南方部分地区还处于高温难耐的状态，北京城里却有偶阵雨。给这炎热的夏天增添一丝丝凉意。
上一期打算将本期主题定为OpenStack，后来临时决定改为阿里巴巴的几篇专访，在2013阿里技术嘉年华大会上，小编有幸采访到此次大会的几位讲师，在这里和大家分享一下，希望能给大家带来一些感触。如果对专访内容有疑问或建议的话，非常欢迎大家留言讨论。
对于下一期内容，你们有什么好的主意呢？欢迎您投稿、反馈！我们将竭诚为您服务！■
——黄丹
《Linux运维趋势》是由51CTO系统频道策划、针对Linux/Unix系统运维人员制作的一份开放的电子杂志，内容从基础的技巧心得、实际操作案例到中、高端的运维技术趋势与理念等均有覆盖。我们的所有内容均收集整理自国内外互联网，每篇文章都会严格标注出处与作者，同时编辑也会尽力联系每一篇文章的原作者进行确认。如果您认为本杂志的内容侵犯到了您的版权，可发信至huangdan@https://www.doczj.com/doc/708817948.html,进行投诉。
目录
技巧&经验18 下厨房6月26日数据丢失事故总结文/xiachufang 20 Fedora 19 劲爆来袭：安装体验手记文/曹江华24 专访刘宇：解密新浪CDN服务器监控机制采访/杨赛 讲述者/刘宇 整理/黄丹26 四大顶级开源网络管理工具详解文/Susan Perschke 编译/核子可乐30 家庭网络管理中的十大常见错误及解决方案文/oschina 编译/姜鹏飞, LegendHero等33 Linux服务器中高负载现象故障排查指南文/cPanelJeff 编译/核子可乐
专题
04 专访刘毅：阿里巴巴云计算平台运维故障分析与排查
讲述/阿里巴巴刘毅 采访/黄丹
07 专访阿里巴巴胜通：“双十一”备战
及去IOE这条路讲述/阿里巴巴胜通 采访/黄丹
10 专访阿里巴巴和仲：实时计算的部署与应用
讲述/阿里巴巴和仲 采访/黄丹
观察
12 IT企业数据中心管理者如何应对自然灾害？
文/Arielle Emmett 编译/核子可乐
14 十款最常见的Linux发行版及目标用户
文/Avishek Kumar 编译/布加迪
专题
任何计算机系统都有出现故障的时候，小到一个终端的软件无法使用，大到整个系统瘫痪，所有业务不能办理。这也是系统管理员或者运维工作者最担心的事情。如何做到快速定位故障问题，合理分析故障成因，找出排查方案是管理者们需要了解的事情。在阿里巴巴集团主办的ADC·阿里技术嘉年华大会上，51CTO记者有幸采访到了从事阿里集团云计算平台的一线运维刘毅（@毅毅），看看他是怎么做到的吧。
以下是采访实录：
不同平台运维工作的对比
51CTO：刘毅你好，首先请大概介绍一下你自己的经历和现在的工作职责。
刘毅：我之前在eBay COC负责UNIX系统运维，离开COC之后，2010年加入阿里集团，其实最开始招我进来的是阿里云，集团的云计算平台也是刚刚开始，差不多三年，我就伴随着云计算平台逐步成长，在一线参与了集团云计算平台一线运维工作。
51CTO：所以你主要关注的一些领域就是云计算相关的？两家公司的工作模式和工作职责相差大吗？
刘毅：区别还是比较大的，在eBay负责运维的是成熟的应用，整个应用架构是全冗余的，高可用性，并且较多的使用商用解决方案，而且他们在商用解决方面的预算是不菲的，相对来说，运维对底层的稳定性会依赖于厂商支持，商用负载均衡设备的广泛使用也不会因为单台的服务器不可用而给我们运维造成困扰。
第一次接触到云计算平台运维的时候，我感觉一下回到了石器时代。大概意思是运维环境非常恶劣，每天有个两三台服务器宕机是再正常不过的事情。没有存储，没有带库，数据都是存放在本地硬盘，每块硬盘上的数据随时都可能丢失，数据的冗余全靠云平台自身解决。这就苦逼我们运维了，我们要帮助云平台去解决各式各样的问题，它解决数据冗余的问题，并不意味着机器不用恢复，硬盘不用替换，紧急情况不用处理了。前3个月，最的最多的就是重复劳动，感觉没有价值，简直是劳动密集型产业。怎么办？我们需要工具，自动化工具来帮助我们摆脱重复劳动，shell、perl、python，只要能提高效率的，我们不区分工具语言，不过还是Python使用的最广泛。渐渐的从命令行自动化做到web自动化，点点鼠标完成5000台服务集群的停起，升级、查看状态信息等工作。感觉很完美了？还没有，这些仅仅是表面的改善，我们现在期望从运维着的这些上十万台服务器，每天产生的硬件日志、系统日志、应用日志之间，在这些庞大的数据里，就像挖金矿一样，挖掘出能够改善我们运维、应用的方法，今天的我演讲的主题就是一个数据化运维的例子。
51CTO：目前你们团队的规模大概是什么样的情况？
刘毅：我所处的团队目前人数20人不到，也是从4-5个人发展起来的。他们有负责离线平台运维，在线平台运维，还有负责相关运维自动化。基本上每个人都会了提高运维效率而写代码，看代码。
专访刘毅：阿里巴巴云计算
平台运维故障分析与排查
讲述/阿里巴巴刘毅 采访/黄丹
04 专题专栏Linux运维趋势 2013年7月号 总第29期
观察思考Linux运维趋势 2012年12月号 总第24期
05投稿信箱：yangsai@https://www.doczj.com/doc/708817948.html,
花费大半的精力来维护优化自己的运维工具。工具写的越多越感觉到需要用数据的分析来帮助我们判断怎么样做才是高效的，借助我们身后平台的力量。
51CTO：你们的客户相当于就是为阿里云提供？
刘毅：我们主要是服务内部的开发客户，但是我们的运维业务呢也有服务外部客户的。比如药品监管码。通过监管码，可以追踪药品从生产、仓储、销售的全过程，这些数据就存储在我们运维的服务上。但是呢这些还是少数，我们目前主要是支持集团内部的业务和开发客户。
阿里巴巴云平台运维故障排查
51CTO：你们平台平时出现故障频繁吗？
刘毅：平台建设的初期，因为不稳定，故障比较多，当时挺累的。随着平台稳定，自动化工具的成熟，局势已经扭转过来了。
举个最最简单的例子：过去做运维，因为底层硬件可用性、冗余度高，宕机率都是按年来计算。而现在这些廉价的PC服务器，几乎每天都会有宕机，这对同样是处于初期的云计算平台的冲击还是有的，所以一台服务器，或者一块硬盘都可能会影响到整个服务集群的稳定性。而现在有了这些经验的积累，不管是平台自身还是运维手段都有办法来规避底层硬件不稳定的问题。
再举个更细节的例子：过去运维不需要关心硬盘的维修，我们都知道甄别坏盘是存储设备的基本功能，而且往往能贴心的亮起指示灯，可以说整个过程除了主动向厂商报修，运维不需要做任何事情。但是在我们云计算平台初期不行，开始运维就像保姆一样要跟踪整个过程，我们要主动发现，要及时修复，发现晚了，可能就是一个故障、修复不及时可能空间就紧张了，听起来好像很夸张，如果你看了我分享的几个运维数据，真是那么一回事儿了。这些事情很重要，重复度又很高，特别是在大规模服务器下，我们不能每天去重复劳动，对运维价值的提升不大、对平台稳定性也毫无益处，我们就用自动化解决，把这些廉价服务所不能做的带来的问题，用我们的自动化工具变得像之前昂贵的存储设备那样的智能。这很有意思，你会感觉你和云平台一起在成长，停不下来，比如说，仅仅是发现还不够，我们还要做预测，硬盘作为机械设备，随着时间增长，肯定会老化，老化会带来各种各样的问题，比如性能慢，不响应。那么我们通过研究磁盘参数，做到磁盘健康的预测。首先这些参数都是厂商定义的，偏理论，但能不能用 ，好不好用，但是我们拥有庞大且真实的实际数据，把这些数据采集并且在云平台下做数据分析挖掘，提炼适合我们不同业务场景下的磁盘监控度的预测，最关键的是取到好的效果和反馈，特别是在关键战役，双11之前，做到预测结果不好的硬盘提前下线，避免关键时刻掉链子。举了2个例子，平台不稳定、故障多不会是常态，通过运维自身的演变，可以让那些紧急的、危害大的运维异常变成可控的、影响小的运维事件。51CTO：除了你刚刚提到的硬盘，其他的还有哪些比较容易导致故障？刘毅：硬盘只是一个例子，我们把它归结为硬件故障，除此之外呢，还有就是软件bug。再者就是人为的疏忽造成的。51CTO：你刚刚说运维分了很多种。出现什么故障的时候是不是流程也会复杂？刘毅：复杂是相对的吧，如果公司人少，再复杂也不复杂到哪里去，想阿里这么大的公司，相对来说肯定要复杂一些，但是我们集团内部有团队会负责和改进流程，不管是故障流程，还是日常的各种流程。51CTO：是说出现哪个方面的故障，然后是有人判断，然后确定是哪个组负责的，然后就派那组去解决？刘毅：对的，会有一个责任人或者责任部门，但是原因和改进措施需要大家一起来配合做。
“平台不稳定、故障多不会是常态，通过运维自身的演变，可以让那些紧急的、危害大的运维异常变成可控的、影响小的运维事件。”
05投稿信箱：huangdan@https://www.doczj.com/doc/708817948.html,
Linux运维趋势 2013年7月号 总第29期
“我想我不会转开发，我觉得运维不错，一直做下去。因为我觉得现阶段运维很有趣，也很有挑战。”
06 专题专栏51CTO：你们这边工作的效果是怎么考核的？因为这几天也是听了阿里其他团队的人来讲，比如说像是做云的，他可以说我提供这个服务给你们。或者是提高软件性能的，他也可以说我作为业务，我提供给你们，帮助你们的服务做的更好。对于你们来说，客户已经固定了，成了一个保障部门。那你们这边的具体考核方法是什么？
刘毅：考核并不是恒定不变的，个人的考核办法一定是保障团队目标的前提，而团队一定是保障公司目标的，具体来说，作为运维，至少要有东西运维，才能说有价值吧，这时候又不能挑业务，不能说这个业务容易出彩，运维风险又小，我就要去运维，凭啥让给你？对吧，开始只能有什么运维就运维什么，主要考核就是你有没有运维好，有没有故障，有没有提高效率这些硬性的运维指标吧。随着业务的壮大，运维的场景变多，招人也算是考核指标吧，一个是业务扩大、一个是团队成长，都需要新鲜的血液。还有就是资源利用率、怎么用好手上的服务器，这非常考验我们运维。还有双11，这也是个重要的考核指标吧。
51CTO：最后谈谈你个人的未来发展问题吧，你自己是怎么规划的？是一直做运维？还是转开发，或者别的？
刘毅：我想我不会转开发，我觉得运维不错，一直做下去。因为我觉得现阶段运维很有趣，也很有挑战。想想怎么把各种系统数据、应用数据收集起来，用云平台帮我们分析，提炼出有帮助、有价值的内容，真是太有意思了。因为第一、很多方面我们没接触过，比如数据挖掘，需要我们不断的充电，第二、经常有被颠覆的感觉，不是这样的感觉，比如我们预测硬盘健康的时候，并不是说我们拿一个值，越大越好或者越小越好，真实数据告诉我们是有临界区间的，而且找到这个临界区间。这很有意思、很有挑战，把日常无序、杂乱的运维数据变得有用的，很有成就感。在云计算时代，真真切切的感觉到数据的强大，我想我会沿着数据化运维的方向走下去，把那些运维异常变成可控的运维事件。
51CTO：变成一个可控的。
刘毅：是的，这很有意义，做到可控就很有意义，但是很难，以前我们会说凭经验，凭感觉，世界变化这么快，怎么知道经验是可靠的？如果还靠一次次故障堆积经验，是否还合算呢？业务千变万化，适应客户要求，我们运维怎么办？很多事情，可以这么做，可以那么做，我怎么说服你呢？其实最后这些的答案就是数据，现在感觉所有自动化都是为了数据运维而准备的，在数据化运维我还不知道我有没有找到大门，我不知道在哪儿，我刚才举的介个例子，可能是对的，可能是数据样本不够，还不够准确，这就是又有趣又有挑战的地方，我想我暂时还痴迷着这些，呵呵。
好的，本次采访到这里就结束了，非常感谢刘毅的分享！如果您还有其它的问题或者建议，欢迎留言讨论。■
相关文章推荐：
原文链接：https://www.doczj.com/doc/708817948.html,/art/201308/406033.htm
2013年7月13日， 由阿里巴巴集团主办的ADC·阿里技术嘉年华将在杭州海外海国际会展中心隆重开幕。51CTO记者很荣幸受邀参与了本次技术峰会，并采访到了阿里巴巴的DBA陈昭尚（花名：胜通），就淘宝“双十一”促销活动相关技术和 去IOE 相关问题进行交流与探讨。对比感兴趣的朋友，不妨看看本文的采访实录。以下是采访实录：“双十一”的前奏和预热51CTO：胜通您好，首先请做一下自我介绍。胜通：我是陈招尚，花名胜通。零七年加入阿里巴巴，负责过淘宝的所有的核心系统数据库，经历和参与了淘宝几乎所有核心数据库的改造升级过程，淘宝第一个分布式系统、第一个核心系统分布式改造、历年双十一的数据库主要负责人。51CTO：那您在阿里巴巴目前主要职责是什么？胜通：阿里巴巴这个团队分了很多方向，有的是更专注基础的，有的是专注产品应用的。产品应用就是我们数据库系统应用在具体的产品里面，最大事件这种。有的是专注集团核心的层面的，还有是专注一些类似的核心产品研发。比方说我们的数据流技术，这方面的新产品研发。我个人是在产品的应用，就是将数据库应用到最佳的应用的状态，就是使用上面。
51CTO：阿里巴巴每天数据量那么大，作为一个DBA而言，是不是会感觉比一般企业的DBA 更有压力？胜通：说实话压力确实有，在阿里来说的确得到很大的磨炼，有的时候，很多问题都是别人追着你来解决，那你就必须顶着这个压力去做。我认为这样有压力其实就有锻炼的机会，我们不能够逃避。
51CTO：在去年淘宝“双十一”促销活动中，淘宝技术支撑受到了很多网民的追捧和认可，请问阿里在购物高峰的时候，怎么样才能保证网站能够正常的运行？你们利用了哪些相关的技术？
胜通：像“双十一”这种非常重要的促销活动，我们为它准备了很多。不是说我用了一个技术，就可以解决这些事情，包括很多方面。我可以简单讲一下我们做了一些主要的准备的事情。这个事情做完过后才能保证在“双十一”当天不会出大篓子。
首先我们对业务要非常熟悉，核心流程的数据量化是第一步。
第二步我们系统的，根据业务仔细研究，然后再根据业务的指标，我评估它的压力会有多少，对系统有一个评估。接下来对它进行升级。
51CTO：是不是把升级做好就OK了？
胜通：从去年经历的“双十一”的经验来讲，不是把系统升级就OK的。首先想各种预案，有些预案数据库就可以直接解决的，出了问题数据库解决。另外数据库解决不了，再想办法解决。这种全部弄下来以后，我们需要不停地去演练。
第二点就是我们的容量非常准确地预估出来。我们预案估不是拍拍脑袋预估出来，而是有很多数据作为依据，一次交易会有多少个系统去访问，会带来什么东西？如果中间一步断了，它又会去访问哪里？最后量化，最后一位到个位数。投稿信箱：huangdan@https://www.doczj.com/doc/708817948.html,
07
专访阿里巴巴胜通：“双十一”
备战及去IOE这条路
讲述/阿里巴巴胜通 采访/黄丹
观察思考Linux运维趋势 2012年12月号 总第24期胜通：去年“双十一”过后也遇到很多问题，年后就开始改进。今年正式启动“双十一”，我们已经开始着手做各方面的准备了。去年的部分问题我们都进行修复了。今年为了解决去年一些比较核心的问题也做了很大的改进，甚至成立专门的团队来做这些事。但是有些东西可能还不太方便说。但是我想说的是，今年我们要做的比去年好。去年大家感觉不爽的地方，今年一定不让大家感觉到不爽，这是我们的目标。如果真的还会有，比方说新的业务的变化，有的一些新的东西，问题进来了，我不知道会不会有，但是我们肯定要对这种情况去分析，去做准备。51CTO：您刚刚提到的规模化运维。规模化运维与自动化运维的关系是？淘宝的规模化运维大概是什么样？胜通：规模化运维是从面对人的角度来说，自动化运维把我们的系统往自动化运维方向去做。就是用技术的手段来解决规模化问题，是这样的一个结果，它们俩就是这样的关系。提到淘宝的规模化运维，其实之前还没到这么大的规模。我们之前可能只有十几道库，不能算是规模化。但是现在三千套了，一旦达到规模以后，从机器的采购到交付到上架，再到上系统，再到投入使用。每一个环节都要相互衔接好，因为都是不同的人来做。每个环节单独的一方面，包括程序对系统的应用，我们需要做到非常一体化的这种，天衣无缝，人介入其中肯定是越来越少了，就是让系统来实现这样子的。阿里 去IOE 这条路51CTO：阿里走上 去IOE 这条路，主要是出于什么原因考虑的？胜通：我觉得是三个方面的因素推动的：第一方面是直接的因素，我们不会回避，直接的因素是钱的问题。如果再次做一遍成本有点高，这是第一点。我们老板讲过一句话，IT这个行业存在的原因就是为了给大家省钱，效率提高，钱就省下来了，这是最直接的原因。现在说我我的个位数肯定不准，这个系统会有多少，一天会有多大的数据量，这个容量评估，评估后就是升级。然后再基于所有的各种产品进行演练。容灾这个事情，如果在“双十一”真的遇到这种情况，平时没有演练的话，就会手忙脚乱。只有不停地锻炼才会这样子的结果，因为“双十一”是阿里非常重要的一个活动，我们对它准备要非常地充分。基本上“双十一”搞定了，全年的活动就搞定了一大半。
51CTO：淘宝强大的技术使命会让很多人联想起12306购票，就是一票难求。很多网友就将二者对比，12306能不能应用阿里“双十一”的技术应对抢票的问题，您对这个事情是怎么看待的？
胜通：淘宝也有有压力的时候，在过去并不是说从来就没有出过篓子，不是这样的情况，它也是一步一步锻炼出来。我们看12306在刚出来，在后来一段时间，个人认为是有很大改进的。但这个改进，用这样的技术，用淘宝这种思想去做。我认为假如真的投入这样进去，肯定是能够有很大的缓解。其实12306有的时候可能真的不是技术的问题，客运量就只能拉这么拉这么多人，如果超出了这个范围，真的是没办法。这不是我们计算技术能解决的。
51CTO：可能也是客观的因素，技术不是主要的因素？
胜通：12306怎么说呢？在我们的政府网站中还算是走的比较远的，走的比较快的，政府的其他东西好像还没有它的步伐迈的快是不是？技术上我是觉得，虽然说外面有批评。但是他们后期做了很多改进，我们不能总看到人家一个缺点，看不到他们的改进。其实淘宝也正是因为一次一次的问题，一次次地改进，才有了今天这样的比较完善的架构和技术体系。
51CTO：今年的“双十一”你们有做哪些准备？是阶段性的么？还是说从年初就开始着手做这件事了？Linux运维趋势 2013年3月号 总第25期08 专题专栏Linux运维趋势 2013年7月号 总第29期
“规模化运维是从面对人的角度来说，自动化运维把我们的系统往自动化运维方向去做。就是用技术的手段来解决规模化问题。”
投稿信箱：yangsai@https://www.doczj.com/doc/708817948.html, 如果一个粗放性的公司，你说我一开始就走现在这条路可不可以？其实是可以的，但是商业市场是否允许你这样去做，这是自己本身的一个决断。这件事情本身是有很大风险的。中间任何地方出了问题，都可能会产生很大的影响。看你是不是有这个决心去做这件事了，而且做这件事情必须要有个非常强的组织保障，必须要把其它阻力划界，然后来做这样一件事情。另外一点，从技术上来说，往开放的方向走肯定是正确的。第二要架构上灵活。你往这两个方向上走肯定是正确的，其实 去IOE 并不等于是去掉 IBM 、去掉 Oracle 、去掉 EMC 。它只是技术架构本身的一个革新，我们在走这样一条路而已。整体上来说，我是认为，从环境、从时势上来看，各公司都有各种不同的策略，还是得根据自己公司的实际情况来衡量一下。公司很小的时候，船小好掉头，如果你有这个精力。
51CTO：在 去IOE 整个过程中，你们遇到的最大的困难是什么？或者是遇到了哪些挑战？胜通：我大致讲一点，第一点可能很多人不理解是业务重要还是技术重要？你为什么要做这件事情？毕竟你现在完全满足我一两年以后的市场。这个事情其实你去说服他也很困难，这个首先组织上要有这个意识，你上层领导对你做这个事情的态度很重要。还会有一些的想法，比方说有的人会说，你说只有合适的最佳时间对不对？我这个地方到底去不去按照你这条路来走？其实应该根据我来判断对不对？一些东西都是很多的应用，这个时候我是，最后总结多做事，你把事情做出来以后，有的事情不是说当时就能够证明你是正确的。可能是两年以后、三年以后才会发现这些。如果当时不走这条路，其实在去年的“双十一”就非常的困难。好的，访谈就到这里，非常感谢胜通的分享！各位网友如有相关问题，欢迎您留言讨论。■
但是它不是唯一的原因，它的占比也不是非常高。
第二方面是本身的资源的问题。比方说，在当时的那套系统环境下，可能预计一年后无法满足业务需求，业务的高速发展绝对会突破当时所能够达到的最高线，所以我们在整体架构上必须要做这样一个转变。把这个比喻为土地的话，可能更好理解。当土地不够用了，必须得要挖更多的土地出来。第三个方面是人的因素，也是最重要的一个原因。当时技术把控，掌控力这块，像 Oracle 这么大， IBM 这么大，其实他们的很多技术无法满足我们在推动产品方面的需求。而且他们是一个边缘的市场，再加上我们的技术能力来说，双方都无法满足了。在这种状态下，就促使我们走上了 去IOE 这条路。51CTO：阿里 去IOE 这条路也适用于其它企业么？
胜通：首先一点，我们这个方向是正确的。但是并不代表所有的企业都得往这个方向走，假设你的技术没有那么强，而且你还没有那么到必须走这条路的时候，提前做这件事情，其实不太好的。我不是给那些商业公司打广告，他们的确在某些方面做的很好， Oracle 的监控其实做的很好。以前看到他们的报表，我就知道到底是什么问题了。我觉得其实很好，最后走了这条路，我们实在是因为到了那个时候，没有办法才走这条路的。所以千万要保持头脑冷静一点，不要一股脑跟风。因为业界上也有一些比较牛逼的、出名的公司，结果因为技术改造改挂了，也有这种出现过。所以一定要谨慎，但是整体方向上，个人认为是不会错的，如果你有那个实力的时候。
个人感觉其实永远没有一个万能的技术，只有一个最合适的技术。淘宝早期的时候，业务目标是第一的，那么可能需要我们以最快的方式满足业务，因为它是一个粗放性的公司。
“其实 去IOE 并不等于是去掉 IBM 、去掉 Oracle 、去掉 EMC 。它只是技术架构本身的一个革新，我们在走这样一条路而已。”
09
投稿信箱：huangdan@https://www.doczj.com/doc/708817948.html, 原文链接：https://www.doczj.com/doc/708817948.html,/art/201308/406030.htm
观察思考Linux运维趋势 2012年12月号 总第24期
和仲：是，肯定是要分的很细。但是太细就会带来组织的效率问题（这是另一个话题），搜索本质上是业务性，而目前的部门是平台性，当然仍然会关注广告搜索，但目前全集团的业务我们都需要支持，它是一个横向支持的部门。比如阿里金融现在业务做的很好，这些业务的数据部分其实都是跑在我们这个事业部，比如计算信用度等等。它使用数据的深度和广度是一般人想象不到的，它怎么去评估？就在我们的平台上。业务用数据的程度决定了我们提供数据服务的广度和深度。用户的需求，业务的需求，需要我们把技术场景不断的细分，通过细分来获取细分场景的技术指标的不断加强。我们的系统，平台需要精细化，所以人的分工也需要精细化，但是我们每个人也需要横向去了解其它系统和平台。
51CTO：你们那边都有实时的数据出来？
和仲：实时的有，但现在不多。其实要看业务的本质要求，比如信用是个长期的累积，很难因为一个瞬时的事件来剧烈影响信用。本身这个业务是不是个实时，那是要业务来看，不是我们来看。我们是一个被别人用的平台，我们去服务业务的。不是说业务都上实时吧，没法做那件事情。你的业务本身就是长期稳定的业务，稳定的态势，就不需要实时数据的特性。如果业务上对数据的实时性有要求，那我们就会服务，就会支撑。当然，实时分为计算的实时和数据的实时。
51CTO：提到实时计算，它产生的背景是什么？和仲：业务、市场、用户对互联网产品需求越来越广泛，需要你越来越个性化，越来越实时化。比如说广告，现在我们广告客户想要看刚刚前一分钟的投放效果，如果效果没有达到预期，我们就可以根据实时计算，对后面的营销策略做出及时地调整。比如说“双十一”的促销活动，它就一天。如果当天的营销策略错了，那么前期所有的准备就白费了，一年就玩进去了。Linux运维趋势 2013年3月号 总第25期专访阿里巴巴和仲：实时
计算的部署与应用
讲述/阿里巴巴和仲 采访/黄丹
“实时计算的今天，业界都没有一个准确的定义，什么叫实时计算？什么不是？这个概念没必要去纠结。”阿里巴巴资深专家强琦（花名：和仲）对51CTO记者如是说。我们更应该关心的是实时计算的应用场景和未来发展状况。本文中，和仲从实时计算的背景、部署及应用及等方面做了详尽的介绍，关注实时计算的朋友们有福啦！一起来看看本文的采访实录吧。以下为采访实录：
51CTO：和仲您好！首先请您做一下自我介绍。
和仲：我是零八年加入阿里巴巴的，之前一直在网易，也是做搜索引擎和分布式系统。到了阿里以后，主要从事搜索，广告，分布式系统方面工作。目前致力于数据交换平台建设，专注实时计算，流计算服务化平台。
51CTO：您是一年前从广告搜索转岗了，现在主要是流计算服务平台的。你们这个平台每个人的职责都分的比较细吗？10 专题专栏Linux运维趋势 2013年7月号 总第29期
投稿信箱：yangsai@https://www.doczj.com/doc/708817948.html, 51CTO：您目前比较专注于实时计算这个领域，实时计算和离线计算区别是什么呢？和仲：他们有不同的维度。离线计算偏数据的准备过程，为了在线服务而准备数据的，不是adhoc的。它更侧重的是成本，吞吐量。离线加工好的数据是需要加载到在线系统里面去服务用户的，今天你去淘宝访问，你接触到的系统是在线系统，但是在线系统的数据是由离线加工来的。51CTO：离线数据里的存储？和仲：对，是离线来加工的，大概是这么去分的。离线系统又分为批量计算、增量计算和流计算。如果一次就把所有的数据全计算完，那么它就是一个全量计算，批量计算指的是增量计算，流计算就是我今天专门讲的，它对数据计算粒度更小，是一批数据，可能是几条，有可能是几百条，也有可能几千条。它其实也是在离线计算的不同维度、不同技术的切入点去做这个东西。因为你刚刚说到的，离线计算，如果你都用全量计算的话，或批量计算的话，它会有些问题。但是它好处是因为吞吐高，所以成本比较低。但问题就是说，你现在看到的数据是老数据。很简单，我给你举一个例子，当然不一定是那么准确的，但是你可以去理解这件事情。如果今天卖家在淘宝上上了新的宝贝，你不能立刻看到，而是它上架一天以后你才能看到。这个对公司来说，影响就很大了，对于卖家来说影响到他的销售，对于用户来说体验不好。所以你就需要更及时加工的手段，它秒级就能加工好。实时计算的今天，业界都没有一个准确的定义，什么叫实时计算？什么不是？这个概念没必要去纠结。其实你光看概念，会觉得很乱，其实如果你知道它本身的技术，就会明白它其实是很清楚的一件事情。只是说计算是相对，数据的新鲜度是比较高的、比较快速的。在线的和离线的，其实是不同维度。■（未完……更多精彩内容请查看原文。）
对于这种要看到分钟级的营销策略，比如说我看到用户，今天喜欢买紫色的，赶紧把我的宝贝调整，紫色的图做的更突出。所以它的营销一定是个闭环，营销分析做出决策。之前的决策链条是慢的，当然他希望快了好，现在需要它去做出更实时的数据来，做出更快的市场反应。而业务也是一样的，比如说你是我的好友，你刚刚在淘宝上买了一个东西，我登录后推荐给我这个东西，可能我的点击率就高了。这些东西都是因为业务，而业务又因为用户，其实为了满足客户。客户如果有这种业务上的实时需求，数据更新鲜的话，必然会刺激到，最终我们的技术会延伸出这样细分的场景来。这些都是因为用户有这样的需求。
但从另一个侧面看，技术驱动。比如说手机，原来摄像头，其他的功能都是附属产品，而现在这些app已经是手机的必要功能了。其实还是这样子，还是由用户、业务、产品、系统、技术体系，一层一层下来，只不过是因为有互联网的诞生，导致整个传导过程会比较快。你想不到的，真的想不到。我们十年前上大学的时候，谁知道互联网会如此，原来想要网上购物不可能的事情，就像马云说的，淘宝的伟大在于，你把你的钱交到一个不认识的人手上，并且他也会承诺发货给一个不认识的人，他通过一个不认识的人，送到你家里。这在以前是不可能的，不可想象的一件事情。但就这几年的工夫，相信未来这种技术变革，周期会越来越快。
因为链条变化的非常快，影响受众也特别多。以前的蒸汽机时代，从最开始有火车，到普通人能坐上火车，需要花好几年的功夫。互联网的受众，今天有个什么东西，可能明天大家，普通的屌丝都用到。一个是链条快了，第二个受众接受成本低了，受众传播的广，所以力量才比较庞大。
必然导致技术的变革也非常快，包括这些年的迭代计算，实时计算，这些全都出来。相信未来业务变革，产品变革的速度加快，技术的迭代，细分也会不断加快。
“实时计算的今天，业界都没有一个准确的定义，什么叫实时计算？什么不是？这个概念没必要去纠结。”
11
投稿信箱：huangdan@https://www.doczj.com/doc/708817948.html, 原文链接：https://www.doczj.com/doc/708817948.html,/art/201308/406031.htm
在这场风暴中燃油泵出现故障，英特奈普的员工们不得不将巨大的1200加仑燃油桶运送至楼上，从而保证服务器的电力供应。“没人准确预测到桑迪竟会带来如此巨大的灾难，”英特奈普公司开发与运营部门高级副总裁Steve Orchard表示。通过飓风桑迪与2011年的飓风艾琳，“这种趋势已经给我们敲响了警钟，”他补充称。
该公司已经宣布将在新泽西州的斯考克斯市建立新的数据中心--远离冲积平原。“我们非常重视气候变化因素，并以此指导自己对新设施的位置选择，”Orchard解释道。
背景情况
2005年的飓风卡特里娜与丽塔给我们留下深刻印象，紧随其后的是2008年的古斯塔夫与艾克，接着是2012年的艾萨克。一波又一波的灾难在墨西哥湾沿岸给Entergy公司的IT管理者带来了巨大压力。这家市值100亿美元、拥有15000名员工的企业最终放弃了在新奥尔良地区建立数据中心的打算。在卡特里娜出现之前，向280万客户提供核能与矿物燃料电能供应的Entergy公司将总部设在新奥尔良，并在路易斯安那州的格雷特纳建立起一家数据中心--位于密西西比河与新奥尔良市区之间。“我们当时获悉数据中心正好处在风暴前进路线之上，巨大的压力让我们在灾难结束后旋即做出决定--对数据中心进行迁移，"Entergy公司CIO Jill Israel回忆道。"我们数据中心周边的区域并未直接受到洪水侵袭，但电力供应已然中断，外部线路损坏使我们不得不使用备用发电机并关闭了大部分设施。”2006年冬季，该公司决定在密西西比州的杰克逊市与阿肯色州的小石城建立两家镜像数据中心。
Linux运维趋势 2013年7月号 总第29期
IT企业数据中心管理者
如何应对自然灾害？
文/Arielle Emmett 编译/核子可乐
关于气候剧变的各种征兆接踵而至，并迫使很多企业领导者及IT专业人士思考这样一个问题：数据中心管理者要如何应对气象学家们口中所谓百年一遇甚至五百年一遇的风暴、洪水以及沿岸地区的其它自然灾害？一些专家建议关键任务数据中心的管理者们只需简单对现有设施进行加固，但另一些观察家们认为数据中心需要被转移至高地位置，第三种意见则劝说数据中心管理者综合以上两种方案。
不过专家们在这一结论上达成了一致：几乎没有几家IT机构有能力在风暴侵袭下全身而退或者仅略受影响--即使是那些长久以来一直筹备应对之策的机构也做不到。大多数IT领导者都希望以成本最低、工作量最少的方式构建灾难应对机制。
举例来说，就东海岸的情况看，各数据中心在对抗飓风桑迪时并未能拿出任何特别有效的措施，PTS数据中心解决方案公司创始人兼总裁Peter Sacco指出--这是一家位于新泽西州富兰克林湖的数据中心设计及管理咨询企业。从另一个角度看，他认为目前大部分计算机都已经成为网络体系中的一部分，而不再强调单一数据中心的重要性。
作为IT基础设施托管企业，英特奈普公司对风暴过后危险性最高的多套设施进行了加固，包括位于曼哈顿下城区百老汇街75号的建筑。12 观察思考
观察
他表示大部分欧洲及美国客户都乐于进行长期风险评估并采取前瞻性评估机制，至少在理论层面是如此。
即使是在飓风桑迪刚刚过去数个月的今天，大部分东海岸企业仍然没有组织数据中心迁移的计划。“他们不仅没有考虑迁移事项，甚至希望在原有基础上进一步扩大数据中心规模，”希恩合作公司数据中心架构负责人Neil Sheehan指出--这是一家位于芝加哥的架构企业。
他认为，事实上“我们正在为客户在新泽西周边海岸地区制定扩展方案。”Sheehan表示，根据对五百年一遇洪水的水位调查，数据中心架构师可以设计出理想的一层高度从而在灾害发生时依靠多层停车场容纳积水。
也有不少企业在口头承诺之外对可能出现的灾难做出进一步准备。在曼哈顿下城区西街140号，一家Verizon交换中心也彻底感受了一回飓风桑迪的真正威力。洪水一口气淹没了五层地下设施，包括Verizon电缆室。技术人员不得不努力在电梯井处安装应急发电机与抽水泵。
自灾难发生以来，Verizon公司已经从曼哈顿下城区的基础设施、中央办公室、总部以及客户现场中撤出150吨受损铜缆，并利用防水光缆作为替代。“如果大家使用的是光缆，那么即使将其铺设在浴缸里也不会影响正常使用；光纤材质并不怕水，”Verizon企业解决方案部门全球客户保障副总裁Chris Kimm表示。
通过更换电力基础设施并将其提升至较高楼层，这家运营商最终得在一周之后恢复了中央办公区的正常运作。
不少客户开始纷纷仿效Verizon的应对之策--将关键性基础设施迁移至封闭化可租用办公位置。根据Kimm的见闻，有些客户还会部署一系列新服务，包括移动无线、无线IP以及云计算方案等，借以帮助员工以远程方式处理日常工作。■
（未完……更多精彩内容请查看原文。）在小石城方面，该公司对一家历史悠久的图书馆进行了结构改造，并于2008年陆续将来自新奥尔良的硬件及关键性应用迁至这套备份设施当中。直到2010年，Entergy才最终完成了这套耗资3000万美元的杰克逊数据中心。该公司需要对两套设施进行负载平衡，尤其是电子邮件系统。根据Israel的说法，"将应用程序由新奥尔良迁出需要制定一套周密的规划方案。继卡特里娜之后，我们已经遭遇过多次严重风暴灾害，包括小石城遭遇的冰风暴。不过我不希望再被自然之力吓得心神不宁，"她告诉我们。该公司每年都会针对飓风及其它类型风暴灾害进行演练，从而获得更出色的应急响应能力。Israel不无自豪地声称，“我们很快意识到如何高效将劳动力进行分散非常重要。我们的员工现在能够以远程方式处理大量工作，而且其实际效果相当出色。”不过并非每位管理者都对自然灾害保持密切关注。位于欧洲及美国东北部的众多IT机构似乎坚持认为，超级风暴只是自然界难得一遇的小概率事件。在某些情况下，即使已经受到灾害的实际影响，IT管理者仍然表现出严重的健忘症、拒绝对状况做出积极回应。无知者无畏“从传统角度看堪称高枕无忧的方案如今很可能面临威胁，”Gartner公司数据中心及基础设施分析师Rakesh Kumar指出。他列举了发生在欧洲地区的冻结温度、沿岸洪水及其它一些无法预测的气象变化，并强调了亚洲地区对于海啸活动的漠视。“直到真正遭遇大规模数据停机事件之前，大部分客户对于自然灾害引发的风险并不关心；他们甚至有点选择性无视的意味，”Kumar 解释道。他表示大部分欧洲及美国客户都乐于进行长期风险评估并采取前瞻性评估机制，至少在理论层面是如此。
“不过并非每位管理者都对自然灾害保持密切关注。位于欧洲及美国东北部的众多IT机构似乎坚持认为，超级风暴只是自然界难得一遇的小概率事件。”
投稿信箱：huangdan@https://www.doczj.com/doc/708817948.html, 13
译文链接：https://www.doczj.com/doc/708817948.html,/art/201307/403538.htm
原文链接：https://www.doczj.com/doc/708817948.html,/article/2044401/some-data-center-operators-take-their-chances-with-floods.html
观察思考Linux运维趋势 2012年12月号 总第24期
2. Gentoo
与Debian一样，Gentoo这款操作系统也包含数量众多的软件包。Gentoo并非以预编译的形式出现，而是每次需要针对每个系统进行编译。连Gentoo社区都觉得Gentoo安装和使用起来很困难；不过它被认为是最佳学习对象，可以进而了解Linux操作系统的内部运作原理。提到Gentoo 总有人这么说：”如果你要学用Linux发行版，那就学用该发行版吧；如果你学会了Gentoo，也就学会了Linux。”Gentoo使用portage来安装和更新软件。Gentoo这款操作系统适合对Linux已经完全驾轻就熟的那些用户。下载和安装Gentoo：https://www.doczj.com/doc/708817948.html,/main/en/where.xml
Gentoo Linux
3. Ubuntu
Ubuntu是Debian的一款衍生版，也是当今最受欢迎的免费操作系统。Ubuntu侧重于它在这个市场的应用，在服务器、云计算、甚至一些运行Ubuntu Linux的移动设备上很常见。作为Debian Gnu Linux的一款衍生版，Ubuntu的进程、外观和感觉大多数仍然与Debian一样。它使用apt软件管理工具来安装和更新软件。它也是如今市面上用起来最容易的发行版之一。Ubuntu使用基于apt 的程序包管理器。Linux运维趋势 2013年3月号 总第25期你可曾知道Linux的魅力或威力来自哪里？那就是，由于众多发行版百花齐放，Linux的阵营日益壮大，每一款发行版都拥有一大批用户，开发者自愿为相关项目投入精力。Linux发行版可谓是形形色色，它们旨在满足每一种能想得到的需求。本文就是为了简述某一款发行版为何存在、该发行版的目标用户是哪些，以及它与其他发行版相比有什么样的特殊功能。
1. Debian
Debian运行起来极其稳定，这使得它非常适合用于服务器。Debian平时维护三套正式的软件库和一套非免费软件库，这给另外几款发行版（比如Ubuntu和Kali等）带来了灵感。Debian这款操作系统派生出了多个Linux发行版。它有37500多个软件包，这方面唯一胜过Debian的其他发行版只有Gentoo。Debian使用apt或aptitude来安装和更新软件。
Debian这款操作系统无疑并不适合新手用户，而是适合系统管理员和高级用户。Debian支持如今的大多数架构（处理器）。
下载Debian ISO映像文件：
https://www.doczj.com/doc/708817948.html,/distrib/
附有屏幕截图的Debian安装：
《Debian 7.0”Wheezy”安装指南》Debian Linux
14 专题专栏Linux运维趋势 2013年7月号 总第29期
十款最常见的Linux发行版及目标用户
文/Avishek Kumar 编译/布加迪
投稿信箱：yangsai@https://www.doczj.com/doc/708817948.html, Damn Vulnerable Linux
5. 红帽企业级Linux
这是第一款面向商业市场的Linux发行版。它有服务器版本，支持众多处理器架构，包括x86和x86_64。红帽公司通过课程红帽认证系统管理员/红帽认证工程师（RHCSA/RHCE），对系统管理员进行培训和认证。就全球市场而言，总利润中80%来自支持，另外20%来自培训和认证，不过在印度不是这样。
在印度，红帽的利润中80%来自认证和培训，只有20%来自支持。而Fedora是个平台，而不是开发新产品或新应用程序的测试环境；一旦成为稳定版，就与红帽企业级Linux捆绑在一起，包括支持。红帽提供了非常多的稳定版应用程序，但是众所周知的缺点是，把太多旧程序包打包起来，支持成本确实相当高。不过，如果安全是关注的首要问题，那么红帽企业级Linux的确是款完美的发行版，它使用YUM程序包管理器。
红帽企业级Linux是系统管理员的第一选择，它有众多的程序包，还有非常到位的支持。
由于该发行版是商业化产品，所以不是免费的。不过，你可以下载用于教学用途的测试版。
附有屏幕截图的RHEL 6安装：
《RHEL 6安装指南》Ubuntu是新手用户肯定爱不释手的一款操作系统。
下载Ubuntu ISO映像文件：
https://www.doczj.com/doc/708817948.html,/download
附有屏幕截图的Ubuntu安装：
《Ubuntu 13.04”Raring Ringtail”安装指南》
Ubuntu Linux 4. Damn Vulnerable Linux 当然，大多数人可能对这款发行版前所未闻，不过该发行版在本文中还是占有一席之地。那么，它有何过人之处呢？ Damn Vulnerable Linux恰如其名：其字面意思就是”该死的易受攻击的Linux”。Vulnerable Linux（DVL）根本不是一般意义上的优秀的Linux发行版。它有意捆绑了坏的、配置不当的、过时的、很容易被不法分子攻击的软件。它的目的在于借机训练Linux管理员。还有什么比给Linux管理员一款坏的发行版去排解问题来得更管用的吗？面对Apache、MySQL、PHP、FTP和SSH等比较旧或破的版本，接受训练的管理员够有得忙了。Damn Vulnerable Linux堪称旨在训练管理员的实验室。下载Damn Vulnerable Linux（DVL）ISO映像
文件：DVL_1.5_Infectious_Disease.iso。
“红帽企业级Linux是系统管理员的第一选择，它有众多的程序包，还有非常到位的支持。”
15
投稿信箱：huangdan@https://www.doczj.com/doc/708817948.html,
观察思考Linux运维趋势 2012年12月号 总第24期CentOS Linux
7. Fedora
小巧的Fedora适合那些人：想尝试最先进的技术，等不及程序的稳定版出来。其实，Fedora就是红帽公司的一个测试平台；产品在成为企业级
发行版之前，在该平台上进行开发和测
试。Fedora是一款非常好的发行版，有庞大的用
户论坛，软件库中还有为数不少的软件包。Fedora同样使用YUM来管理软件包。下载Fedora 18（Spherical Cow）DVD ISO映像文件：https://www.doczj.com/doc/708817948.html,/en/get-fedora 附有屏幕截图的Fedora 18（Spherical Cow）安装：《Fedora 18（Spherical Cow）安装指南》
Linux运维趋势 2013年3月号 总第25期补充说明：通常认为，开发了该发行版的Marc Ewin将该产品命名为红帽，因为他丢失了似乎很心爱的那顶红色帽子，帽子是他爷爷在他过生日时送的礼物。
红帽企业级Linux
6. CentOS
CentOS是一款企业级Linux发行版，它使用红帽企业级Linux中的免费源代码重新构建而成。这款重构版完全去掉了注册商标以及Binary程序包方面一个非常细微的变化。有些人不想支付一大笔钱，又能领略红帽企业级Linux；对他们来说，CentOS值得一试。此外，CentOS的外观和行为似乎与母发行版红帽企业级Linux如出一辙。 CentOS使用YUM来管理软件包。
非常稳定的程序包；谁要是想在桌面端测试一下服务器的运作原理，都应该试试这款操作系统。
下载CentOS 6.4 DVD ISO映像文件：
https://www.doczj.com/doc/708817948.html,/Download
附有屏幕截图的CentOS 6.4安装：
《CentOS 6.4安装指南》
【专题推荐】
CentOS 社区企业操作系统16 专题专栏Linux运维趋势 2013年7月号 总第29期
“CentOS是一款企业级Linux发行版，它使用红帽企业级Linux中的免费源代码重新构建而成。这款重构版完全去掉了注册商标以及Binary程序包方面一个非常细微的变化。”
投稿信箱：yangsai@https://www.doczj.com/doc/708817948.html, 下载Arch Linux ISO映像文件：https://https://www.doczj.com/doc/708817948.html,/download/Arch Linux 10. OpenSuse
OpenSuse这款Linux发行版是免费的，并不供商业用途使用，仍然供个人使用。OpenSuse的真正竞争对手是红帽企业级Linux。它使用Yast来管理软件包。有了Yast，使用和管理服务器应用程序就非常容易。此外，Yast安装向导程序可以配置电子邮件服务器、LDAP服务器、文件服务器或Web服务器，没有任何不必要的麻烦。它随带snapper快照管理工具，因而可以恢复或使用旧版的文件、更新和配置。由于让滚动发行版本成为可能的Tumbleweed，可将已安装的操作系统更新到最新版本，不需要任何的新发行版。
SUSE在管理员当中的名气更大，因为它有Yast以及让系统管理员能够自动管理任务的其他此类应用程序，同样水准的其他发行版没有这项功能。下载OpenSuse 12.3 DVD ISO映像文件：https://www.doczj.com/doc/708817948.html,/123/en 附有屏幕截图的OpenSuse 12.3安装：《OpenSuse 12.3安装指南》本文不是什么大盘点。市面上有好几百款发行版，每款发行版在某个方面都与众不同。■
8. Kali Linux
Kali Linux是Debian的一款衍生版。Kali旨在用于渗透测试。它大概在三个月前才发行。Kali的前身是Backtrack。用于Debian的所有Binary软件包都可以安装到Kali Linux上，而Kali的魅力或威力就来自于此。此外，支持Debian的用户论坛为Kali加分不少。Kali随带许多的渗透测试工具，无论是Wifi、数据库还是其他任何工具，都设计成立马可以使用。Kali使用APT来管理软件包。
毫无疑问，Kali Linux是一款渗透测试工具，或者是文明黑客（我不想谈论恶意黑客）青睐的操作系统。
下载Kali Linux DVD ISO映像文件：
Kali Linux 6Kali Linux
9. Arch Linux
Arch是一款采用滚动发行方式的操作系统：只要安装一次就够了；每当发行了某个新版本，就可以升级发行版，不需要重新安装。Pacman是Arch Linux的软件包管理器。Arch Linux既支持X86处理器架构，又支持X86_64架构，安装程序可以从光盘或U盘来运行。Arch旨在从开发者的角度而不是从用户的角度做到力求简单。Arch配置和安装起来超容易。它真是一款面向高手的发行版，让你可以了解Linux系统的每一个细枝末节。
“SUSE在管理员当中的名气更大，因为它有Yast以及让系统管理员能够自动管理任务的其他
此类应用程序，同样水准的其他发行版没有这项功能。”
17
投稿信箱：huangdan@https://www.doczj.com/doc/708817948.html, 译文链接：https://www.doczj.com/doc/708817948.html,/art/201307/404309.htm
原文链接：https://www.doczj.com/doc/708817948.html,/10-linux-distributions-and-their-targeted-users/
在6月26日凌晨12点左右，我们在做线上数据库的备库时，误将线上数据库分区上的所有文件删除。丢失的数据时间段为4月23日至6月25日两个月，在经过7天的努力后，恢复了99%以上的数据。（具体见下面的统计）。
下面把整个事故过程记录下来，令关心本次技术事故的人们知晓。
一. 事故隐患
现在回顾，事故隐患在4月23日之后就已经存在。
我们线上数据库使用的是MySQL，在4月23日之前，我们对线上数据库主节点有三类备份。一是有一个独立的数据库从节点来备份，与线上服务器保持数据的实时同步，需要时可切换作线上使用。二是会定期把整个数据库dump成sql文件来备份，一天保存一次，备份的来源是数据库从节点。三是主节点开启有binlog，默认是保存十天的日志，十天内有任何事故可以从日志里完整恢复全部数据。这三个备份分别存放在两台不同的物理机，三个不同的分区上，是当时想到的最安全的方式。
4月23日，我们把数据库主节点迁移到一台新的物理机上，并把版本升级到5.5。由于版本和配置的问题，原来的从节点并不能直接使用。而一天一次的备份来源是从节点（备份主节点会令网站和手机app有1小时左右的卡顿），这个备份方式也就停止了更新。只有最后一个binlog还在运行。数据库迁移之后应用服务器存在一些性能问题需要投入时间，包括修复MySQL5.5版本和原代码的兼容，以及把应用服务器从gunicorn换成uwsgi，之后又陆续有一些开发任务，以致重新启用备份节点的工作一再拖延。
我们对数据库迁移工作的管理存在失误，是造成事故的根本原因。Linux运维趋势 2013年7月号 总第29期
下厨房6月26日数据丢失事故总结
文/xiachufang
18 技巧经验技巧&经验
没有完成数据库备份节点，迁移工作就并没有结束。我们技术团队的所有人对这个事故都负有责任，这个隐患在两个月里都可能被发现，每个人都有可能提出这个工作的高优先级。也都可能提出相应的弥补工作来保证数据安全，比如在启用从节点前延长二进制日志的保存时间等。是我们的工作失误使数据库成为系统最脆弱的环节，经受不住偶然事故的冲击。二. 事故发生过程6月26日凌晨12点左右，我们开始重新建立备份节点的工作，需要把原来的从节点删除，重新安装，所以先使用了rm -f方式删除备份节点分区上的所有文件。5分钟后，发现刚才删除的是数据库主节点的分区，为防止硬盘继续写入，就马上把mysql进程停止了。所有技术人员开始应急处理。一是把整个分区dd成镜像，准备做将来硬盘恢复的备份。二是把memcache里的数据dump出来，以备可能的恢复。三是重新启用原来的从数据库，由于数据时间只到4月23日，需要调整近两月表结构变更，让最新的代码可以跑起来。当天的应急工作至凌晨4点，服务器都恢复访问，但数据停留在4月23日。在整个应急过程中，部分是紧张，部分是沟通上存在误解，还是出现了失误。当配置从数据库的技术人员完成之后，重启了服务器和memcache，恢复了正常访问。但是做memcache 导出工作的技术人员还没有完成，所以最终能从memcache里得到的那部分数据只有一半左右。事后从沃趣科技的数据库工程师那里得知，我们第一时间停止MySQL防止硬盘继续写入这个应急措施是错误的，即使分区完全没有文件，mysql的进程继续运行，只要保留这个现场，可以从内存中获取更多的数据库结构信息，对恢复数据非常有帮助。
三. 事故后恢复工作
事故后恢复工作从数据来源分为4条线索进行：
1. 硬盘上数据的恢复（主线）
2. 从memcache导出的数据恢复
3. 从binlog里恢复
4. 从搜索引擎的快照里恢复页面
以下按时间详细叙述：
? 6月26日8点，我们去机房把服务器硬盘取出来，送到了一家硬盘数据恢复公司。到下午5点左右恢复出ibdata1文件，文件可能破损。
? 6月26日12点，为了预防新插入的内容和原内容的冲突，我们把所有表的id都加到一个大值，半天的内容随后做特殊处理。
? 6月26日23点，导入完了所有memcache里的数据。
? 6月27日上午，从硬盘里又恢复出部分.ibd文件，也包含部分数据信息。已确定包含数据的ibdata1和.ibd文件有破损，无法直接使用，只能尝试从破损文件中提取部分有效信息。
? 6月27日下午，联系上杭州沃趣网络科技有限公司的陈栋、李春，开始对数据的提取工作。至凌晨1点，提取出.ibd文件的数据，恢复部分表。
? 6月28日全天，沃趣科技开始对ibdata1文件的提取，至29日凌晨1点，他们已经提出大部分数据。
? 6月28日下午，得到阿里巴巴集团的周振兴的友情支持，他开始帮忙做ibdata1文件的提取工作，至凌晨4点，他完成部分带二进制段的数据表的修复，提取到了相关内容。
“事故后恢复工作从数据来源分为4条线索进行：硬盘上数据的恢复（主线）、从memcache导出的数据恢复、从binlog里恢复、从搜索引擎的快照里恢复页面。”
投稿信箱：huangdan@https://www.doczj.com/doc/708817948.html, 19
? 6月28日下午，我们联系上北亚数据恢复中心，开始再次尝试对硬盘文件的恢复。? 6月28日晚，我们把所有从binlog来的数据导入完，完整恢复了最后10天的数据。? 6月29日中午，从沃趣科技得到的优先级较高的数据表已经恢复完成，开始恢复次优先级的数据。? 6月30日中午，提取完所有能从6月27日获取的破损数据库文件里的所有内容。至此这一阶段提取到缺失总数据量的近70%。? 6月30日下午，开始从搜索引擎快照里抓取部分菜谱重要页面，修补缺失的内容。并联系上某搜索引擎的快照部门，希望获取我们网站的全部页面快照。? 7月1日上午，北亚数据恢复中心取得很大的进展，提取到几乎是完整的ibdata1文件，至下午6点，提取到除了收藏和赞的所有数据表，我们开始把数据导入，至凌晨4点，恢复完得到的所有数据。? 7月2日整天，由于导入的旧数据和新注册的用户存在部分数据不一致，我们尽力配合用户恢复。? 7月2日下午4点，北亚提取到ibdata1剩下的文件碎片，得到了完整的ibdata1文件，mysql无报错启动，我们得到了6月26日凌晨事故前的完整数据库。至凌晨2点，我们提取出剩下的收藏和赞，恢复到数据库里。至此损失的数据内容已经恢复到99%。以下是当前主要内容的恢复情况：（未完……更多精彩内容请查看原文。
）■
原文链接：https://www.doczj.com/doc/708817948.html,/art/201306/399089.htm
观察思考
Linux运维趋势 2012年12月号 总第24期? 检查和恢复功能：用于故障恢复或者设备间
的流程迁移。 ? OpenLMI：用于系统和存储远程管理的常用基础架构；最新版本的OpenStack（又名Grizzly），包括了Heat和Ceilometer项目。二、安装过程简介Fedora 19整个安装过程也是非常的简单， 基本上和上个版本相同，这里笔者就不赘述了。图1 是集中配置界面，这个配置界面是从Fedora 18开始出现的 。
图1 Fedora 19集中配置界面
升级安装的步骤：
命令行模式，包括如下几个步骤：
#yum install fedora-upgrade
#fedora-upgrade.
下面按照提示操作，如图2：
Linux运维趋势 2013年3月号 总第25期Fedora 19 劲爆来袭：安装体验手记
文/曹江华
一、Fedora 19 简介
一直以来Ubuntu、Fedora和Mint三大Linux桌面操作系统发行版一直稳居前三名（排名情况）。2013年7月3日，Fedora项目有一款力作：Fedora 19正式版发布。Fedora 19除了桌面版之外，还提供了KDE定制版、LXDE定制版等，有兴趣的网友可以在其官网上下载试用。 据了解Fedora 18正式版一方面做了常规的软件版本更新，另外一方面加入一些新功能：内核升级至3.9.0。增加了使用Extlinux引导程序的选择，它是Syslinux引导程序家族一员。初始设置屏幕重新设计。anaconda安装程序重写(Fedora 18便已开始)，提供了对高级存储的支持，比如fcoe、iscsi、multipath。文本模式也有所改进。GRUB外观、GRUB菜单进行了修改，更加无缝化，更吸引人。node.js运行和NPM整合管理员，用于开发用于分布式设备的可扩展网络应用软件或实时应用软件； Fedora 19将传统版本的语言继续更新至PHP(5.5)，最新的版本语言为Ruby 2.0.0。Fedora 19在操作系统的管理上也做了各种改进，包括启动流程、故障恢复、系统迁移及其它。Fedora 19包括了诊断、监控和日志工具，帮助用户由被动变主动，拥有更多自由时间。显著的改进包括：
? 虚拟机存储迁移：无需主机间共享存储即可帮助用户完成虚拟机， 在用存储的迁移。
? 系统资源控制：无需重启即可修改服务设置。
20 技巧经验Linux运维趋势 2013年7月号 总第29期