内容来源：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。
我今天的分享就到这里，谢谢大家！
