观察

说别人家的故障,总有点隔鞋搔痒,看人家笑话的感觉。

先说一个小故事吧,某一年三四月份,我和几个同事一起去拜见某大客户的IT总经理木总,聊大型系统的运维经验,聊我们的管控手段,木总很不屑的说,这些我们都做了好几年了……紧接着2个月发生了“由于某些原因将某数据库重启后,系统性能运行非常缓慢,后面发现原因是重启后SGA变为几百兆了,而正常是几十GB”,“某数据库出问题,需要恢复的时候,发现Veritas软件恢复的时候不支持,需要打一个补丁”,“所有的用户权限都是DBA,某天突然应用用户drop了个生产表,需要立即恢复”…..木总原以为这些数据库有备份、有流程、有规范的在运维了,事实上是情况已经不像他以为的那么好。比较幸运的是,我们的团队开始支持他们的系统。所以我们一直说,运维是个持续的过程,要靠专业的运维团队来做,而且流程规范要与时俱进更新和完善。

今天发生故障的是一家代码托管的创业公司gitlab.com,说实话我第一反应以为是github,虽然名字很像,其实不是。

简单介绍一下:

1. 工作了一天,疲惫的工程师YP同学在23点的时候,想把一个自己以为是空目录的文件夹rm –rf删除了。大概一两秒之后,YP同学突然意识到,他大爷的,是不是搞错机器了!没错,他确实搞错机器了!

2. 23点27分的时候,YP同学终止了这个操作,然后发现,310GB的数据,只剩4.5GB了,99%的数据已经被误删除。

3. 非常不幸的是,之前号称的所有备份都失效了:常规备份(说好像有,但是备份在哪不知道呢)、LVM备份(是24小时一次的。说YP在故障发生的6小时前做了一次,但从恢复进度来看,应该也是失败的)、Azure上的磁盘快照(以为做了,其实没做DB的)、S3上的备份好像也没成功、自动同步程序不稳定,也失效了。

阅读更多

一、为什么要进行故障演练?

伴随着海量请求、节假日峰值流量和与日俱增的系统复杂度一起出现的,很有可能是预料之中以及意料之外的各种故障。

在很多情况下,由于事故处理预案的缺失或者预案本身的不可靠,以及开发人员故障处理经验的缺失,造成在各种报警之中自乱了阵脚,从而贻误了最佳战机。

特别是一些平时线上没出现过的异常故障,一旦突然出现,往往措手不及。

系统是否足够健壮?是否有足够的能力应对故障的发生?当面临故障时会出现什么行为?我们并不希望真正线上出现故障时才去验证这些问题,这样风险太大,成本太大。

所以希望在线上环境隔离真实流量的情况下,提前模拟产生各种任何可能发生的故障,来观察系统的反应,验证预期策略。

总结一下,故障演练主要有以下几个目标:

确保系统按我们预想的方式应对故障
寻找系统中未预料到的弱点
寻找其他提高系统鲁棒性的方式来避免事故实际发生

阅读更多

从去年开始,好像就有一只无形的手一直将我与“微服务”、“平台化”、“中台化”撮合在一起,给我带来了很多的困扰和思考与收获。

平台化正兴起,从基础设施到人工智能等各个领域不断涌现的各类平台,对于软件开发人员及企业带来了深远的影响。然而,在中国提“数字化平台战略”大家可能会觉得比较抽象,比较远大空;若是提“中台”大家则会更熟悉一些。

那……中台到底是什么?会不会又是另一个Buzzword呢?这个从名字上看像是从前台与后台中间硬挤出来的新断层,它与前台和后台的区别和界限到底在哪儿?什么应该放到中台,什么又应该放到前台或是后台?它的出现到底是为了解决什么问题呢?

这一个接一个的问题就不断的涌出并萦绕在我的脑子里。直到一年多后的今天,随着参与的几个平台化、企业中台相关的项目已顺利步上正轨,终于可以坐下来回顾这一年的实践与思考,再次试图回答这些问题,并梳理成文,与大家交流探讨。

一、中台迷思

到处都在喊中台,到处都是中台,中台这个词在我看来已经被滥用了。

在一部分人眼里:中台就是技术平台,像微服务开发框架、DevOps平台、PaaS平台,容器云之类的,人们都叫它“技术中台”;
在一部份人眼里:中台就是微服务业务平台,像最常见的什么用户中心、订单中心,各种微服务集散地,人们都叫它“业务中台”;
在一些人眼里:中台应该是组织的事情,在释放潜能:平台型组织的进化路线图 (豆瓣)中就提出了平台型组织和组织中台的概念,这类组织中台在企业中主要起到投资评估与投后管理的作用,类似于企业内部资源调度中心和内部创新孵化组织,人们叫它“组织中台”。

看完本篇你就会理解,上边的这几类“中台”划分还是靠谱的,更多我看到的情况是,大家为了响应企业的“中台战略”,干脆直接将自己系统的“后端”或是“后台”改个名,就叫“中台”。

中台到底是什么?它对于企业的意义到底是什么?当我们谈中台时我们到底在谈些什么?

想要寻找到答案,仅仅沉寂在各自“中台”之中,如同管中窥豹,身入迷阵,是很难想清楚的。不如换个⾓度,从各类的“中台迷阵”中跳脱出来,尝试以更高的视角,从企业均衡可持续发展的角度来思考中台,反推它存在的价值。

阅读更多

最近的一个项目是风控过程数据实时统计分析和聚合的一个 OLAP 分析监控平台,日流量峰值在 10 到 12 亿上下,每年数据约 4000 亿条,占用空间大概 200T。

面对这样一个数据量级的需求,我们的数据如何存储和实现实时查询将是一个严峻的挑战。

经过对 Elasticsearch 多方调研和超过几百亿条数据的插入和聚合查询的验证之后,我们总结出以下几种能够有效提升性能和解决这一问题的方案:

集群规划
存储策略
索引拆分
压缩
冷热分区等

百亿级数据实时统计分析和聚合的优化实战

阅读更多

面试的时候,我会问面试者,你日常如何构建自己的知识体系,如何让自己更高更快更强?多数工程师并没有深入地思考过这个问题,基本上是零敲碎打,随机性大,基本上是脚踩西瓜皮滑到哪里算哪里。

第一阶段:认真构建完整的知识体系

十几年前我投身软件行业的时候,光是讲解数据库原理、操作系统、TCP/IP、组网、算法等等基础知识的原版书摞起来就等身,认认真真看完,各种上手实践,入行后,读遍 C++ 各种经典著作,读遍各种协议原文,认认真真打基础。

很多工程师都说自己平常就是在某些 IT 门户上看看推荐的博文或新闻,我说这属于典型的零敲碎打,不够刺激。

聊到这时,我会举一个例子,为什么要阅读长篇小说,因为中短篇小说就像用针扎你,而长篇小说就像把你装进一个沙袋里吊起来,从四面八方用狼牙棒打你,酣畅淋漓。构建可用的知识体系,就得读书,书是有体系结构的,你关心不关心,现阶段你用到用不到,它都讲到了,从头到尾看几遍,针扎得透透的。

何谓知识体系?

几年前,前支付宝架构师姚建东曾经在我们公司做过技术人员如何规划自己的分享讲座,他是这么论述的:

阅读更多

解读2018:我们处在一个什么样的技术浪潮当中?
最近经济寒冬的说法越来越多,身边的互联网企业裁员的也有不少,越是寒冬,我们越需要了解趋势,找准前进的方向。过去几年,互联网各种“风口”此起彼伏,到底哪些才是真正的趋势?这篇文章里我将试图分析目前互联网技术的发展,找出它们背后的原因和逻辑。

阅读更多

概述

微服务是最近非常火热的新概念,大家都在追,也都觉得很对,但是似乎没有很充足的理论基础说明这是正确的,给人的感觉是不明觉厉 。前段时间看了Mike Amundsen《远距离条件下的康威定律——分布式世界中实现团队构建》(是Design RESTful API的作者)在InfoQ上的一个分享,觉得很有帮助,结合自己的一些思考,整理了该演讲的内容。

可能出乎很多人意料之外的一个事实是,微服务很多核心理念其实在半个世纪前的一篇文章中就被阐述过了,而且这篇文章中的很多论点在软件开发飞速发展的这半个世纪中竟然一再被验证,这就是康威定律(Conway’s Law)。

阅读更多

谈谈流量红利与线下空间
城市样貌驱动的互联网产品模式

一直以来,线下空间结构和线上的产品模式就是互相影响。以城市为例,如果我们把发达国家的城市和中国的城市相比,中国的城市则是经过更多的设计和规划产生的,理性改造的因素相对较强。但是全球大部分城市的演化,则相对缓慢,城市格局的差异对随后产生的互联网时代具有重大的影响。

阅读更多

01 一次发布会回款3000万

“XX品牌的这款面膜,可以说填补了国内市场的空白,给到的扶持政策也非常给力。现在只要一次性提货999元,即可成为天使代理;一次性提货1999元,可以成为公司总监;一次性提货9999元,可以成为公司董事。最重要的是,总监和董事还可以加入我们XX女王的核心团队,了解她从一无所有到财富自由的所有绝招,你还在犹豫什么呢?看不懂的还在迟疑,有魄力的已经先行一步,你要做哪一种人呢?”

讲台上,一位顶多20来岁的女生正在慷慨激昂地发表演说。台下密集坐满了500多位大小微商从业者,大部分是女性。最终政策出来后,全场掌声轰动,一开始陆续有人跑到台前刷卡提货,后面人越来越多,要加入总监或董事的从业者很快排起了长队。

阅读更多

互联网造节,以前一般体现在电商领域,也就是物质消费层面,比如双十一、米粉节等等。内容消费层面的互联网节日,去年由喜马拉雅FM发起的123知识狂欢节应该是首例,至少是目前为止用户参与最多的。

12月3日24点,第二届喜马拉雅123知识狂欢节落下帷幕,其官方公布的“战报”显示,为期3天的知识狂欢节内容消费总额达到1.96亿元,是去年首届123知识狂欢节消费总额的近4倍。

阅读更多