Chaos Monkey

说说阿里云大规模宕机

放肆的年华 提交于 2021-01-20 13:17:26
背景 云服务市场是一块大蛋糕,从如今的各大巨头都纷纷出手想分得一杯羹就能看出。而国内巨头阿里爸爸早在2009年就看准了时机,这里当然少不了要提到 阿里云 创始人:王坚。破釜沉舟的方式用命换来的成就,阿里每年投入10亿,一投就是10年。不得不服王坚和马云当初的坚持和眼光。 从上面几张图就能看出来,这利润真的是杠杠的。当然也不得不说云计算改变了如今互联网行业服务的环境和运维模式,从传统的主机、服务器到现今的云环境。 事故 云计算这几年可以说是事故不断,各大厂商为了市场吹嘘自己的产品,有多么多么的安全,但从数据我们可以看到 云事故 发生的时候,恢复和赔偿对客户还是非常不友好的,毕竟是人家制定的规则,怎么玩他说了算。 可以看出选择云服务器,对客户而言,最担心的还是数据、业务的数据安全问题和环境的稳定性问题。 阿里云 宕机(IO HANG) 国内云计算龙头,市场占比45%,可能这个数字不够直观。那就说个更恐怖的,国内近40%的网站是部署在 阿里云 上的。也就是说,加入 阿里云 全部宕机了就直接导致40%的网站无法访问。不过整体恢复算是响应非常快速的,而且未有数据丢失问题,只是造成故障时段部分网站不可用,影响业务。所以可以说这次事故影响范围非常大,但后果不是很验证。 云环境都尽可能的保证自己的稳定,但如何做好高可用和容灾是云厂商最后的博弈。这里我突然想到了netflix的Chaos

再谈谈软件测试职业发展

前提是你 提交于 2020-11-05 01:59:21
再谈谈测试职业发展 有这么个普遍现象 测试招聘者,特别是一、二线互联网公司的招聘者最苦恼的事儿就是招人。想找到一个合适的人难于上青天,每天各种撒网,简历看几百份,面大几十人,能捞到一个中意的小伙伴就谢天谢地了。但同时很多测试小伙伴发现找工作很难,特别是进大一点的厂,他们特别挑:代码要会写,要有软件架构能力,问一大坨平时根本用不到的技术问题,还挑经验,挑沟通能力,挑这挑那,有时候还特么挑学历、挑年龄。。。供求总难以匹配起来,造成了双方都很痛苦。 Why? 能力要求不匹配是最核心的问题。软件、互联网近 20 年来飞速成长,其实也经历了很多阶段。行业软件兴盛阶段和外包兴盛阶段(2000-2010 年)行业进入了大量的测试人员,当时最主流的测试实践是:重心放在系统验收阶段。测试人员的主要工作基本都投入在了基于业务的黑盒测试上,对代码能力、系统理解的能力要求不多。2010 年后,互联网行业的真正兴起让国内软件开发模式开始缓慢调头,快速迭代的模式逐步兴起,开发周期越来越短,迭代越来越快,但系统越来越越庞大、复杂。原来的测试工作模式和工作范围越来越无法满足要求了。但大量从业人员技能范围转变是一件很难的事情,行业是有巨大惯性的。 从宏观上看大量 QA 技能转变跟不上需求转变是造成市场供求不匹配的主要原因。 So What? 三个观点: 只做手工测试,不懂系统实现的测试工程师的职业发展会越来越受限。

关于 618的前世今生,我帮东哥告诉你

社会主义新天地 提交于 2020-08-12 06:12:53
最近618的广告铺天盖地,我的电脑时不时弹出618广告,手机很多app的启动界面也变成了618,在反感的同时,也在想,618为什么现在能冲出京东,成为广大电商选择的购物节呢? 接下来,我就跟你详细说一说 前言小故事 故事得追溯到1998年,那一年发生了很多大事,有一件是我出生了,另外一件,就是1998年6月18日,刘强东在北京中关村创立了“京东”,这一下,618的由此而来。 而“京东”的“京”不是北京的意思,是他的初恋女友龚小京。所以恐怕奶茶不一定喜欢这个公司名。 彼时的京东不过是个小柜台,小门店,唯一和别人的区别是,刘强东只卖正品。 2003年,一场非典,大家都关在家里面,两个电商大佬同时确定了“线上优先”战略,几乎所有的资源都投入到了线上。听起来像不像今天? 与马云不同,强东没有那么好的口才,但是强东是一个非常有血性的实干家,当时的页面系统很多都是强东直接参与,并编写出来的,据说他当时都是睡在地板上,闹钟一响就开始干。 2005年的时候,刘强东更是赌公司运,关闭了线下门店,都投入到了线上,此后成为了真正的互联网公司,2007年就拿到了第一笔投资。公司逐步步入正轨,东哥开始了自己的人生大事,和某女士生了一个孩子。 2008年,那个让人又爱又恨的年份,京东推出了618,而相对的,双十一是2009年才正式推出。同时京东升级了系统使用 Java构建,可以承担日订单十几万的冲击

10大工具汇总,多维度简化Kubernetes部署

心不动则不痛 提交于 2019-12-01 20:16:08
Kubernetes已经成为大规模部署经过编辑的应用程序的标准方法(许多人会说这是标准方法)。但是,如果Kubernetes可以帮助我们控制无序和复杂的经编辑的部署,那么有什么方法可以帮助我们控制Kubernetes呢?毕竟,它也可能是复杂、混乱和难以管理的。 随着Kubernetes的成长和演变,它的一些过度行为很可能会从内部得到控制。但是有些人并没有等到Kubernetes变得更容易使用,而是对生产中Kubernetes的许多常见问题推出了自己的解决方案。 在这里,我们重点介绍10个以各种方式简化Kubernetes的项目,从简化命令行交互,到简化应用程序部署语法,再到与AWS集成,再到为多个集群提供一个窗口。 目 录 Bitnami Cabin:适用于iOS和Android的Kubernetes面板 Kedge:简明的Kubernetes部署定义 Koki Short:可管理的Kubernetes密钥清单 Kops:Kubernetes集群的命令行操作 Kubebox:Kubernetes的终端控制台 Kube-monkey:Kubernetes的Chaos Monkey Kube-ps1:智能Kubernetes命令提示符 Kube-prompt:交互式Kubernetes客户端 Kube-shell:用于Kubernetes CLI的shell Kubespy