主讲人及背景

腾讯 社交网络事业群运营总监 聂鑫

• • 从开发到运维，伴随腾讯社交网络运营部成长的十年，负责过腾讯社交产品所有业务运维工作。

• • 目前主要负责 QQ、空间等产品运维团队管理工作。经历多个业务产品的诞生到蓬勃，伴随着运维团队的成长和成熟，见证着腾讯一代代运营技术的创新和发展。

• 作为运维界老兵有好多故事想和大家讲，也特别愿意听听各位经历的酸甜苦辣。

关键点

• • Root智能分析
  • 叠加告警

• • 全链路监控
  • 独一无二生命指标保障业务

• 通过机器学习来提高报警有效性

笔记

1. 1. 06年开始，腾讯采用DO分离Dev/Ops。

1. 1. 出现线上故障的很大一个原因就是因为告警泛滥，我们忽略关键告警。

1. 1. 对于“历史遗留问题/历史沿用架构”的态度是：坚决优化掉历史进程中不合理的架构。

1. 1. 腾讯内部有20+套针对监控的系统，这些系统用来保障公司业务的方方面面。
   2. 所谓“Root智能分析” 即：基于公司业务层面架构（业务/人事），将公司业务网状化。然后，通过网图，针对不同业务梳理出来一条单链路。

1. 1. 所谓“叠加告警” 即：发生告警的时候，通过上述链路，进行分析。倘若告警处于链路中连续环节，这个告警的重要程度和准确程度就越高，反之则反。
   2. 对于多告警情况，采用“故障面积算法”来给故障定性。
   3. 所谓“故障面积算法” 即：连续告警在多链路构成的矩形中所占面积大小。

1. 1. DLP-Deadline Point 即：业务生死指标。针对每个业务，不管是从业务架构层面还是系统层面，找到一个可以用来描述整个业务生或死的指标。这个指标有几个特点：
      • • 没有阈值：因为业务数据因太多因素变化，一个推广活动就会增加流量，活动结束，流量自然下降。所以，传统常规阈值实际上没有太大的作用；
      • • 只有一个：指标越多越不好把控；
      • 非业务指标：业务指标波动无规律且易受外界影响。应该使用准确且不易受外界非故障因素改变的指标。
   2. 所谓“全链路监控” 即：通过基础数值/系统日志/业务日志/业务内容/外界舆情等基本数据进行大数据分析，提取公共信息和数据。然后同大盘已有数据（历史数据/宏观安全数据）进行比较，进行判别然后告警。

1. 1. 针对重要指标的曲线，进行诸如3σ准则等法则判定，降低随机误差对数据的影响。同时引入机器图像学习，对曲线进行比较和学习，借助AI的力量合理告警。

1. 以上内容均在腾讯内部线上使用，收效非常好。

感悟

腾讯毕竟是腾讯。

很多内容和经验都非常深刻，个人认为有几点值得关注：

第一，运维引入机器学习。毫无疑问，未来是人工智能的天下。作为一个DevOps，在OPS方面，我们处理的90%的问题都是雷同的，机器取代人工是早晚的事情。当然，对于我司来说，革命尚未成功，同志仍需努力！

第二，生命指标的概念很棒。我们几乎都明白，80%的告警都属于持续告警，不重要不紧急。但是也正是这些不重要的告警导致我们忽略掉一些关键告警，人的精力毕竟有限。行话说，能用机器约束的规则，一定不要用人工。

第三，故障面积算法和小米的集群监控存在共通之处，都是把点集合到面去分析。值得细细品味。

REFERENCE

[3σ准则]: https://en.wikipedia.org/wiki/3σ_rule

The post ArchSummit深圳站学习笔记 – Part 2 appeared first on nood1es.

小米监控运维之路

主讲人及背景

小米 云平台工程师 陈帅

• • 多年从事于监控系统、部署系统、缓存系统的研发工作，热衷于自动化运维理念，独立完成公司部署系统的设计和研发，多次参与中国移动等竞标缓存系统的设计工作。

• 加入小米后，专注于小米监控的设计和研发工作，对于监控系统的应用场景和实践有较深入的理解。

关键点

• • 如何应对业务规模及数量快速增长

• • 自主开发实现监控系统

• • 提供可集成到业务代码监控SDK

• 针对集群而非单个主机进行监控

笔记

1. 1. 11年到14年，管控主机从200台增长到5000台。和我们情况类似，发展迅速，人力不足。
   2. 早期，同样全面采用Zabbix进行监控。

1. 1. 中后期（12年开始）开始自主研发监控系统。流程和Zabbix几乎一模一样。

1. 1. 提出针对主机采用“全生命周期自动化”管理。即：在机器建立、启动、交付、运行、停止、回收到销毁的过程中，都通过整个监控系统管理。去掉人工直接处理的步骤。

1. 1. Agent直接采用主动PUSH的模式（类似Zabbix主动模式）。

      系统架构

   2. 自行开发能够嵌套进业务代码的监控代码SDK，类似于NewRelic的模式。
   3. 机器体系设计采用打Tag方式，八个字段即：公司-部门-产品-集群-服务组-服务-任务组-任务。
   4. 策略模板除了可以继承外，还可以重载，即继承后复写。
   5. 针对集群而非单个主机进行监控，即：同一集群内机器，存在性能冗余。无需100%保证全可用，可用性通过简单四则运算即可完成计算。从实际上看，效果显著。
   6. 监控系统集成自动缩扩容，通过上述监控来自动动态管理。

1. 1. 大力推行Docker容器技术，容器编排框架使用的Marathon。自动缩扩容也通过其实现。
   2. 网络监控（包含网络硬件及流量监控）是很重要的项目。

1. 自动运维基于StackStorm实现。

感悟

从小米的分享来看，比较适合我司现状。其技术选型虽无太多新意，却很容易落地。不管是容器技术的大量运用还是通过Tag方式直观地管理机器，都是我们正在努力的方向。

个人认为值得注意的有两点：

第一，小米初期采用第三方开源监控系统，但后期却选择自研。这个选择不一定适合现阶段的我司。理由很简单，系统雷同又耗时。其自研系统Open-Falcon与Zabbix大同小异。虽然提供了可以嵌入业务代码的SDK等功能，但是我觉得还不足以让我们付出比较大的成本也去开发一套类似的系统。现有业务环境下，我们还是可以采用多套开源/商业方案来实现需求。当然，后期做大做强，自研势在必行。

第二，小米提到的针对集群而非单个主机进行监控的想法非常好——就类似于AWS的ELB——我们在CloudWatch里面可以直接查看针对ELB的监控数据，但是目前看来第三方监控系统都是采用以Single Host为粒度的监控方式。显然，一般集群都采用冗余且主机间低耦合模式设计，无需保证全集群100%健康度。这样可以大大降低我们的工作强度——只要在能保证生产环境安全运行的前提下，分清故障优先级，有的放矢。

REFERENCE

[Marathon]: http://mesosphere.github.io/marathon/

[StackStorm]: https://stackstorm.com/ 

[Open-Falcon]: http://open-falcon.org/

写在后面

周五周六InfoQ主办的ArchSummit深圳站在洲际召开。

含金量确实高，来了很多大佬，

票价也确实高。入门票5k起。Orz。

我司是几个人的小公司吗？？？：）

于是靠胜哥刷脸去听了两场监控相关的分享会。

The post ArchSummit深圳站学习笔记 – Part 1 appeared first on nood1es.