新闻动态

完善的7*24小时服务,携手共赢,共同成长

首页 新闻动态云计算文摘 正文

居安思危:十年IT灾难全面回顾和总结

2016-01-08 18:37:15   
 
新年伊始,大家都开始上班了,2016年的第一期SpeedyCloud 云计算文摘又跟大家见面了。

这一期文摘要重点推荐第一篇文章《居安思危:十年IT灾难全面回顾和总结》。过去这10年,技术的进步确实给我们的生活带来很多方便,然而,却有很多 IT 项目以灾难收场,浪费了上万亿美金,影响到上亿人的生活。IT 行业竞争激烈,走得快,当然有好处,但有时候也不妨慢下来,读读这样的文章,让自己回头看看身边的项目,是否存在隐患。

第二篇文章分析了使用 AWS 云计算常见的五种错误,实际上,SpeedyCloud 的用户也有类似问题,推荐这篇文章,是希望大家能把云用得更好,让自己的业务更加兴旺发达。

接下来,我们推荐了两篇跟网络技术相关的文章。魅族的消息推送架构中,提及很多移动网络相关的底层技术细节,不但让你“知其然”,更“知其所以然”。另一篇来自我们的高级网络总监暴永锋,整理自他在前不久 ArchSummit 上的演讲,分析了我们在网络规划方面的收获,希望对大家有所启发。

从这一期开始,我们增加了一个新栏目:【精彩声音】。选自海内外的推特等媒体,用一两句话、几十个字,言简意赅地列举某些事实,讲述某种体验,让你看到技术世界的精彩。
 
居安思危:十年IT灾难全面回顾和总结
这是一篇长文,值得花上10-15分钟细细阅读的长文,因为它让你以更全面的角度审视你的系统,更有可能让你的系统避免一场从天而降的灾祸。

文章来自 IEEE 的“风险因素(Risk Factor)”博客,文中全面回顾了十年来的IT灾难,总结了一些经验;并且从记录的事件中精选了最有趣、最具说明性的大型IT系统与项目故障案例,制作了5个交互式的专题,对应10年灾难总结出的5大教训。

10年灾难中,包括航空公司的机场行李系统,包括美国的户口普查失败,包括国防部的战斗系统,包括澳洲的票务系统等等。其中,直接损失最大的,是2011年英国中止的国家电子病历项目,浪费金额超过120亿英镑(合 206亿美元);直接影响人数最多的,是2010年德国的银行卡日期问题,3000万人因此遭受不便。

所有这些灾难加起来,直接经济损失几近上万亿美元,间接则不可估量。

这5大教训是:

教训一:IT系统出错所导致的惊人影响,不仅浪费金钱与时间,常常还会扰乱人们的生活。

教训二:系统过于复杂而无法交付,尝试用单个系统替换多个系统的做法可能会导致毫无收获。

教训三:如果项目的生命周期规划失败,再多的金钱与时间也无法避免项目失败这一灾难。

教训四:IT故障中常常出现责任推卸,进行足够的深挖,其实任何问题都源于人类的决策。

教训五:从10年前 IEEE Spectrum的2005年软件故障特刊发布到现在,改进少得可怜。

金句:  

在以后IT开发项目的资产或审计报告中,是否愿意以简单的图表或时间线形式来发布呢?应当直观的显示出:IT项目的开始日期(也就是项目初始投入的时间与资金);项目希望完成的前三到五个功能性目标;还有在项目审查、交付与取消的关键时间点上的实际花费、完成时间、交付功能以及相对的预期值。

此外,如果项目扩展、重新定义或者重置的话,要将这些变更的细节描述地非常清楚。请别忘记指出这些变更是如何影响这些统计结果的。最后,如果项目取消的话,在最终成本统计中要记录机会成本。

标签:项目管理、故障、成本、系统思考
阅读原文
 
【精彩声音】:

我们发现:哪儿的代码部署最糟糕,哪儿的 IT 部门绩效表现和文化就最差…… (来自@EricMinick)
 
 
这五个使用 AWS 云计算的错误,你应该避免
本文来自一位 AWS 云计算咨询专家,参与了众多 Web 应用项目之后,作者分析了自己遇到的五个常见问题。

问题一、手工管理资源。人工错误是该问题导致更严重灾难的主要原因。

问题二、不使用自动扩展组。AWS 提供自动扩展功能组功能,组中的云主机可以根据监控数据自动完成扩展。然而很多人没有使用这个功能。

问题三、不分析度量数据。运维不分析数据,就像一个人不做体检一样,等到健康出严重问题的时候再着急,悔之晚矣。

问题四、忽略系统中提供的建议。AWS 提供一个 Trusted Advisor 功能,可以帮助用户检查自己的web 服务,同时提供相关建议,然而很多人对此并不关心。

问题五:云主机资源使用率低。如果你的云主机空闲资源太多,就等于在浪费金钱,当然了,作为云计算的运营商,AWS 对此没意见,但是你应该考虑降低云主机的资源使用,往小了说,是给自己省钱,往大了说,是给缓解全球气候变暖问题做贡献。

标签:AWS、运维、自动扩展
阅读原文
 
【精彩声音】:

重新编写某些代码的时候,你应该努力实现直接替代可用,也就是说要完成同样的事情,在某些情况下,甚至会 bug 对应 bug。(来自:jerf
 
魅族实时消息推送架构
本文是魅族架构师于小波的演讲实录,其中提到魅族开发实时消息推送架构遇到的坑和一些心得体会,有很多技术细节值得关注。

魅族现在实时在线的用户是2500万左右,系统一天PV量是50亿左右,这个系统推送速度可以达到600万条/分钟。

系统架构分为四层:
  • 最下层:提供手机接入
  • 第二层:消息分发,提供上行消息的路由和用户下行消息路由
  • 第三层:订阅信息
  • 第四层:存储,包括离岸消息存储,包括订阅消息的存储。
 魅族遇到的坑包括:
  • 手机功耗问题
  • 移动网络问题
  • 海量连接问题
魅族的实时消息推送系统的监控中有几个重点数据:
  • 错误计数
  • 接发队列
  • 请求数
  • 处理接口调用延时
最后,于小波还提到了他们的灰度发布功能。

金句:  

我们的系统是由很多小服务组成的,我们很难依靠简单的业务监控来发现未来可能存在的问题,为什么要用“可能”这个词?假如说每一个业务都是有一个单独的集群,集群中有一个节点如果出了问题,并不会影响整个业务的使用,只有当累加到足够大的程度的时候,错误累积到很大的程度,才会导致整个系统不可用,这样其实是不行的,所以我们必须要引入一套严格的监控体系,来发现未来可能发生的问题,快速的定位出来,所以针对每一个集群里面的每一个节点都要有监控。

标签:消息、监控、灰度发布
阅读原文
 
【精彩声音】:

Google 中成功团队的五大特性:1、不怕失败;2、团队成员彼此靠得住;3、结构清晰;4、做的事情有意义;5、团队本身有影响(来自: @Carnage4Life
 
SpeedyCloud 高级网络总监暴永锋:云平台全球网络节点部署的演进
前不久的 2015 ArchSummit 大会上,我们的高级网络总监暴永锋完成了演讲《云平台全球网络节点部署的演进》,其中分享了SpeedyCloud基础设施支撑七大业务模块的应用细节,还分享了我们的全球节点部署过程及未来网络架构演进方向。欢迎点击【阅读原文】了解详细技术细节。

金句:  

云计算环境对网络需求更复杂,需要针对网络产品和解决方案实现变革。

无论是上海电信资源还是北京资源,我们实现了多节点的互联方式,无论从北京的数据中心、北京的云计算及北京服务,均可向广州提供服务和数据,我们实现跨区域地互联互通及数据冗余。我们从北京的数据,可调用至天津和廊坊,实现多机房的数据冗余节点。无论云用户从什么地方访问,都能在全国网上实现数据的漂移。

 
阅读原文
 
【精彩声音】:

当今的移动生态系统在不断发展,其规模未来也许会超过PC 行业的10倍;移动不再是新事物,或是所谓的 big thing,而是全新一代,其规模让它成为技术行业的全新中心。其他一切都会围绕它运行。(来自Benedict Evans
 
免费电子书:InfoQ 云生态专刊2015年06期
《云生态专刊》由中文技术网站InfoQ推出,目标是“打造中国最优质的云生态媒体”,包含的内容包括:
  • 引入国外云计算领域的先进思想和技术;
  • 报道国内外云厂商和生态圈的发展动态;
  • 分享深度和前沿的热点技术 关注产业发展的难点、痛点;
  • 分享解决方案 挖掘产业发展的亮点,分享宝贵经验。
2015年06期中,点评了2015年云计算的发展趋势,以及百度云、又拍云、中国移动浙江数据中心的云计算实践,此外还有 SpeedyCloud CEO 于浩撰写的卷首语《信任是云计算的核心》,值得一阅。
下载电子书
 
关注SpeedyCloud官方微博
掌握最新动态和优惠
扫描SpeedyCloud官方微信
获取价值50元免费云主机
欢迎发送邮件到social@speedycloud.cn,聊聊你对于“SpeedyCloud云计算技术文摘”的想法和建议,也欢迎你说出对于SpeedyCloud迅达云成公司的意见和看法。

*|FORWARD|*