系统运维专家Python 运维程序员

SRECon Asia Day 1

2017-05-23  本文已影响695人  iambowen

这个时节新加坡温差不大,一早上起来就有30度,而且湿度惊人,感觉比深圳都高,同时阴晴不定,随时可能下雨,大早上起来就开始暴雨……。还好在SRECon会议开始之前雨就停了,这样才可以不会狼狈的到达开会的酒店。

会议的登记注册非常简单,拿到牌子之后就可以去吃早餐了。会议总共三天时间,每天管早餐、午餐,午餐是百度赞助的,明天晚上好像还有个什么河边散步的活动,安排的挺好,外面只有linkedin和facebook、baidu的宣传,没有国内会议那么热闹,人相对较少,但是找别人沟通、聊天干扰会少些,这点比较好。

会议的第一个话题来自Linkedin,《Linkedin SRE: From Inception to Global Scale》,由两个哥们搭档介绍Linkedin SRE发展的过程,以及他们如何把SRE的能力移植到印度的办公室,除了印度英语不太好理解外,还是有些启发作用的。提问环节看到了一个熟人,REA GIA团队的JC,休息时间赶紧过去打了个招呼,大家都很吃惊,竟然能在这样的会议上遇到,GIA还有一个Matt也一起过来了,还认识了Seek的Simon,彼此打听了对方的情况,了解到REA目前正在逐渐向SRE的模型转变,现在是将原有的Guild拆分成小的Guild,如监控等,然后由这些人去考虑从公司层面改进某些方面的问题。看上去他们现在也开始关心让业务通过数据来做出产品的决策,哈,这不就是我快离职前做的事情么?于是赶紧提了下我和Clayton做的数据流水线,接受了一番吹捧。

第二个话题来自百度,《Next Generation of DevOps: AIOps in Practice@Baidu》,其实上次我已经听刘俊在北京的DevOpsDays讲过一遍了,只不过这次是用英语,而且是一男一女搭配,Ha Jingjing同学的英文水平还是不错的,可是提问的好多印度人,完全听不懂在讲什么,专门找了个人给讲师翻译才可以-_-! 话题里面介绍了百度的运维、DevOps平台的发展过程,以及百度在AIOps的实践,有些数据,比如外部流量切换大约10分钟,内部的切换大约10s。这些REA也可以做到甚至更快,不过规模要小很多。百度的AIOps做的不错,但是大部分的东西都是他们自研的,如果能在slides中给出开源的解决方案就更好了或者设计的细节就好乐,毕竟很少有公司能有这样的实力去实现所有东西。休息期间和JC他们聊天的时候,他们也觉得这个挺牛逼的,虽然做事的方式他们不太能理解 :) 。

第三个话题来自Zendesk新加坡办公室,《How Could Small Teams Get Ready For SRE》,我看了下这些实践都太熟悉了,没什么新意,就出去facebook和linkedin展台,做题,拿点礼品,顺便跟facebook的妹子吹吹华为,她说facebook正在快速发展,伦敦和都柏林加起来2000人了,我说我们西研所有1w多人,要进军公有云,和Google、AWS一较高下,虽然内心有点虚,但是不能在未来的竞争对手面前示弱 :(。

上午的最后一个话题,我选择了Facebook的《The Service Pyramid》,大概的内容是介绍facebook的服务金字塔模型,有点类似Google SRE的服务可靠性层级,由下往上分别是:
1. 硬件的provision
2. 服务器监控/生命周期
3. 服务监控
4. 伸缩/容灾
5. 性能调优
6. 1%的问题(可用性99….%之外的问题)
每次有新的服务时,他们按照这个模型评审,然后看看那些方面存在问题,那些方面的问题去修复的收益更高,然后对症下药,显然1%的问题和性能问题,都不在优先考虑的范围,但是好的监控是必须要有的。期间了解到facebook已经有了9个数据中心,令人咋舌。

午餐和JC他们坐一起,同桌还有个facebook的哥们,聊了些家常,感觉几个月没讲英语,有点不太灵光了。不过还记得facebook的哥们讲的段子,说google和facebook的人互相看不上,google嫌弃facebook做的产品差,facebook嫌弃google做一个东西时间太长,还没有面世可能就挂了-_-! 黑的好。

下午的第一个话题是来自阿里的Wang Zhaogang,《Smart Monitoring System for Anomaly Detection on Business Trends in Alibaba》,介绍了阿里通过监控系统来收集业务数据,分析和预测其中的趋势,讲师的英文很好,只不过爱学习的印度朋友又出来问问题了:(,因为对中间分析的模型有些疑问,结束后找Zhaogang沟通时才知道他们现在是在阿里所有业务数据的基础上来做的,虽然现在有一些数据噪音的问题,但这个方向肯定是没错的,通过数据来做出/辅助业务决策,这和Clayton当初在REA发起数据流水线的想法是一致的。

下午的第二个话题我选择了CloudFare一个工程师介绍的《Managing Server Secrets at Scale with a Vaultless Password Manager》,原因是隔壁在如何Scale Graphite,而我觉得Graphite的设计已经赶不上一些新的时间序列数据库了……,同时因为最近业余时间在学习密码学相关的东西,好奇它会介绍什么,因为以前我们都是用AWS的KMS,RatticDB或者Vault去管理密码\密钥的。果然,这个实现的角度非常清奇,它的基本原理是这样:
1. 在UEFI(BIOS 2.0)中保存mater key seed
2. 服务器启动后,配置管理工具每次用master key seed 通过KDF来生成新的密码
3. Key pair 通过CSPRNG加密伪随机数生成器来生成
这样的好处在于,每台服务器有不同的master key seed,它被加密在UEFI中,所有的key pair都是在本地保存,并不需要一个专门的密码管理的服务如RatticDB、Vault,省去了维护的成本。可惜会后没有找到他,不能继续交流下细节,只能twitter提问-_-!希望明天还能见到他。

接下来我放弃了滴滴的关于《Open-Falcon》的话题,因为知道这个是小米基于zabbix开源的的监控报警工具,所以选择了Google的Nolan的话题《Managing Critical State: Distributed Consensus for Reliability》,基本上都是在讲分布式一致性算法发展历史,Paxos等。没想到Google SRE那本书关于分布式一致性的章节竟然是基于她的论文,whhat! 因为是妹子所以没有好意思上去合影 :(,失去了和大神同框的机会。

最后一轮的话题我先去听了七牛的一个妹子介绍的基于Ansible实现大规模调度的session,后来一想觉得ansible自己已经有一定了解,不如去听听隔壁讲openstack,也许将来用的上。所以结束的话题我听的是来自清华大学Xu Wei的《Talking to an OpenStack Cluster in Plain English》,感觉真是听对了。他的问题场景大致是这样,如果OpenStack管理的节点出现问题,那么查询需要大量的命令组合以及知识,这样的时间成本以及对人的要求很高。他解决的思路是通过自然语言去查询机器的状态,其次是通过最简单的规则在系统中自动发现知识,这里用到了图数据库。具体的实现是通过日志以及服务器原始的状态(通过OpenStack API)在图数据库中生成OpenStack的知识图谱,通过标签针对数据集去训练模型,最后使用类似ChatOps/Hubot这样的工具,将自然语言查询转化为模型的查询,获得结果。 这个话题值得和IaaS部门的同事分享下,同时,抛开OpenStack这个应用的场景,我可以认为这个过程是构建知识图谱,机器学习,将自然语言转化为API请求来从图谱中获得结果,适用于任何需要复杂操作才能获得内容的场景。没错,我说的就是我菊的hi社区,回去之后可以尝试针对它实现类似的事情,然后搞个机器人和espace集成。其实类似的事情在REA也做过,在hubot的基础上扩展功能,用自然语言来实现对知识的查询,功能比Xu Wei老师要简单的多。

惊喜还没有结束,因为在上次DevOpsDay认识了这次SRECon的组织者刘俊,很荣幸的被邀请到和一众讲师以及前Google SRE,《SRE运维解密》的译者孙宇聪一起共进晚餐。除了找到讲师问了一些今天讲的话题细节,还认识了不少前辈,加完微信后才发现,好多人都在8月份的上海DevOpsDays的讲师列表里……。更神奇的事情是,来自Linkedin的SRE竟然认识以前在REA一起工作的Reed Murphy,世界真是太小了……。

席间还有圈内海量八卦,内容和下面这个Chilli Crab 一样丰富:

chilli_crab.png
上一篇下一篇

猜你喜欢

热点阅读