内容来源：2017年6月17日，华为软件架构师马博文在“西安活动 | 6月17日DevOps MeetUp”进行《SRECon Asia 2017见闻》演讲分享。IT 大咖说（ID：itdakashuo）作为独家视频合作方，经主办方和讲者审阅授权发布。

阅读字数：1552 | 4分钟阅读

获取嘉宾演讲视频及PPT，请点击：http://t.cn/Ezw4rI2

摘要

软件系统40%-90%的开销是在维护上，对于大规模，关注软件可用性、可靠性和性能的公司，使用软件工程的方式去解决运维领域的问题就变成了一个选择。由此，Google发起了SRE(软件可靠性工程师)这样关注可靠性的组织，大名鼎鼎的Borg, Borgmon都出自SRE之手。除了Google之外，关注可靠性的其他大规模互联网公司，如Facebook、Ebay、Dropbox、Linkedin、百度、阿里等也采取类似的实践。SRECon则是这些公司分享SRE在技术、文化等方面实践的会议。最近我有幸参加在新加坡SRECon亚洲的会议，借此机会和大家分享下一些有趣的话题、idea以及我观察到的一些SRE领域的趋势。

什么是SRE

SRE就是网站可靠性工程师。SRE对技能的要求非常高，Goggle SRE中50%-60%是标准软件工程师，其余的要满足80%-90%软件工程师要求，并且了解unix细节以及网络。

SRE会用软件工程的思维去解决运维领域问题，负责可用性、性能、效率、监控、事务处理等。

SRE方法论

SRE主要关注的是研发工作，在保障服务SLA/SLO前提下最大化迭代速度。并涉及到监控系统、应急事件处理、变更管理、需求预测和容量规划、资源部署、以及效率和性能。

SRECon Asia

SRECon的主办方是USENIX，亚洲区会议主要赞助商是Baidu、Facebook和Linkedin。到会人数在250人左右。贡献话题的讲师都来自比较大的互联网公司，有Google、Facebook、Linkedin、PayPal、CloudFlare、Dropbox、Yahoo、Atlassian以及REA Group等，国内的公司有Baidu、Alibaba、Didi、QiNiu、Tingyun和Tsinghua。

监控与告警

如图所示，软件最基础的要求是监控，一切都是在监控的基础上运行，只有监控到发生了什么样的事故，才能做出相应的应急处理。事后总结问题，分析问题根源在哪里。对应的做出改进后进行测试，确认问题后修改代码然后进行发布。

Open-Falcon: Motivation

Zabbix：当管理的服务器超过2000台的时候，它的水平扩展会比较困难。

OpenTSDB：它的优点是写性能，水平扩展好，但是Query慢。

InfluxDB：国外一些小公司会使用InfluxDB。它的Query性能非常好，aggregator聚合强大，缺点是水平扩展难。

Open-Falcon: Performance

容易水平扩展，每分钟能处理百万级transaction (query/ judge/store/search)，轻松支持超过100,000主机。RRA机制，可以查询1年历史数据，100+ metric秒级响应时间，性能非常好。可以存储10年以上的metric历史数据。

问题

运维OpenStack，修复问题所需要的知识复杂，操作过多。这些知识很难Transfer。

解决思路

使用自然语言查询系统状态，好于CLI和Regex。

使用最基本的规则自动发现系统知识，构建一个知识图谱SOSG，将特定系统的查询转化为图遍历，异常检测发现隐藏的问题。

来自话题《Talking to an OpenStack Cluster in Plain English》by Xu Wei From Tsinghua

服务生命周期

双分布一致算法，Paxos算法；可靠的发射规模，发射检查表；在雅虎Hadoop基础架构服务器上无缝地管理变更，由Chef管理的45000个节点。

Reliable Launches at Scale

在上线前会检查架构、容量、可靠性、监控、自动化程度、增长趋势以及第三方（google内部）服务是否准备好，确认这些都没有问题后才会正式上线。

Managing Server Secrets at Scale with a Vaultless Password Manager 

Key/CredenHals随着服务器增多而增多。

在配置管理工具中保存Secrets，启动配置管理工具需要key/pair etc，因为每个服务器密码不能相同导致无法scale key，Key RotaHon。

还有一种方式是保存在服务器上，服务器启动时生成。root password，磁盘加密比较困难，无状态时磁盘的服务器无法存储。

事故管理

事故管理的一些挑战

如何达成更短的MTTR；

很多事故的处理比较简单，如重启等，如何自动处理这些事故；

falsealarms如何减少；

报警如何给出正确信息，快速定位问题。

服务扩展

Small,Cheap, and EffecHveTesHng forProducHon Engineers.

Merou:A Decentralized, AuditedAuthorizaHon Service

Shameon facebook and dropbox.

容量规划/性能调优

Capacity Planning and Flow Control

容量估算: 单机压测；

模拟: ab/jmeter/gatling；

复制: 复制生产环境流量；

重定向；

负载均衡: weight。

Why Flow Control

队列堆积：服务器性能降低，响应时间增加，影响应用以及用户体验。

雪崩效应；

需要限制过载的流量。

And a Formula!

计算原则：

EntranceSize= volume * RT(response Hme)

Requests= constants * LOAD * RT

流量控制原则：系统超载则限制volume，负载正常则去掉限制。

使用动态阈值控制。

总结

SRECon参会人数不少，交流效果也比较好。

可以了解到不同的公司，比如Cloudfare，亚马逊的A9。

虽然很多话题看着很小，但是大部分的话题都有可学习的地方。

可以感受到的一个运维方面的趋势是数据流水线+大数据+机器学习+AI+Bot。

我今天的分享就到这里，谢谢大家！