,微博广告全景运维概述,技术创新，变革未来,前 言,微博广告是微博重要且稳定的收入来源,微博广告服务稳定性为重中之重,微博广告运维担负 资产管理，服务稳定性，故障应急处理，成本控制等责任,运维发展阶段,03DevOps 数千台以上的规模，业务模 型复杂，开发、运维、QA 都参与到整个产品的生命周 期中,01手工运维,一般服务器规模较小，环境 比较单一，简单的脚本即可 维护,02工具化运维,服务器超过百台，环境日益 复杂，批量执行、代码发布、 配置管理等需求的出现,04AIOps 数万台服务器、混合云，虚 拟化，算法驱动运维,微博广告运维痛点,服务器数量 3000+ 业务线及辅助资源多样 产品迭代快，依赖关系复杂 流量变更，切换损失不可接受,1 资产管理 虽然有统一的 CMDB，但线上的 变更、上下线变更 不能自动同步,2 环境不统一 运行环境、依赖版 本，测试环境和线 上环境不统一,3 上线难度大 代码托管方式不一 致，无法实现自动 化测试和上线,4 运维成本高 日常工作繁琐，手 工分配服务器、手 工变更服务，人工 维护配置,01,02,03,04,运维自动化 资源管理、批量运维工具、 事件收集、配置管理,弹性计算 自动化扩缩容、多云适配、 压测和冗余度评估、分级 水位线,智能监控 海量指标、告警收敛、异 常检测、故障定位,服务治理 自动注册、自动发现、熔 断机制，负载均衡,微博广告运维方向,资源管理 基于CMDB的API，获取服务器， vip，域名等相关资源的信息，并 根据广告产品线使用情况予以记 录，更新,基础监控 包括服务器资源（CPU、内存、 网卡流量等）、业务状态,事件集中分析 ES、Flink,配置管理 配置文件（系统及应用）,批量运维工具 Puppet、salt等,持续集成和发布 Jekins等,自动化运维,Kunkka自动化运维平台,资产管理,自助终端,自动化上线,配置中心,主机,阿里云/华为云,VIP管理,DNS管理,服务发现,服务注册,服务扩缩容,服务配置,工单系统,发布,测试,代码仓库,日志审计,脚本仓库,批量管理,文件/命令下发,Kunkka组成,Kunkka Web,Git,Consul,Jenkins,Terminal,CMDB,Salt,DCP,容器/ 主机,K8s,操作层,组件层,传输层,基础层,Kunkka架构,Nexus,Celery,CI,CD,Git,Kunkka,Jenkins Master,Jenkins Slave,Jenkins Slave,Jenkins Slave,Nexus,自动化测试,SaltStack,测试环境,SaltStack,生产环境,工单系统,自动化上线,01,02,03,04,运维自动化 资源管理、批量运维工具、 事件收集、配置管理,弹性计算 自动化扩缩容、多云适配、 压测和冗余度评估、分级 水位线,智能监控 海量指标、告警收敛、异 常检测、故障定位,服务治理 自动注册、自动发现、熔 断机制，负载均衡,A,产品方面 产品线多，依赖关系复杂，发 布和变更非常频繁,B,运营(收入)方面 大型活动、重要新闻等有计划 的推广需求,C,技术方面 热点事件、突发事件，瞬间峰 值高,为什么需要弹性计算,传统的业务运维,立项,预估 容量,评审,购买新机器,CMDB,机房上线,服务部署,流量引入,报修置换,过期下架,优点： 对传统项目而言，整体可控,缺点： 申请周期太长，无法应对突发事 件 无法准确预估容量，资源浪费严 重 资源利用率较低，较难在业务间 共享,基础运维,产品运维,04 分级别决策 安全线、警戒线、致命线,02在线压力检测 自动压测、容量预估,01 多云适配 私有云、阿里云、华为云,03消耗度评测 通用评估公示和计算方法,弹性计算,弹性计算：实时动态扩缩容,弹性计算架构,Kunkka,DCP混合云平台,云服务商,私有云,阿里云,华为云,多云对接,镜像市场,下发通道,扩容模版,决策系统,自动扩 缩容,Oops,业务指标监控,自动压测,演练,决策系统,1,业务指标,压测方法：按照一定步长减少业务服务池的实例数量 压测指标：,系统：Load，Cpu_idle，Iowait，Swap,业务：5xx错误比率，接口平均耗时,基于历史数据的：,同比分析 环比分析,2 容量预测,流量趋势 扩缩容建议,Action 容量概况 辅助API,容量评估方法,avg hits定义：通过各接口的耗时分布，对访问压力进行统一的量化处理，来表示某时刻单机的消耗 计算方法描述：对处于不同区间内的请求数加权求和，来拟合实际的单机消耗量 相比于传统的 QPS、AvgTime、CPU Load 等单一指标更准确。 消耗比 计算公式： 通过压测得出系统中单机最大容量，任意时刻系统的消耗度就是实际单机消耗量与单机最大容量之比。,CPU ？,Avg_Time？,QPS？,AVG_hits !,Ahits = 0.1 * avg1 + 0.5 * avg2+ 2 * avg3+ 4 * avg4+ 8 * avg5 消耗比 = 当前容量（Ahits）/最大容量（max_Ahtis）,安全线 水位线一段时间内稳定在安 全线以上时，逐步进行缩容 逐步缩容,警戒线 水位线低于警戒线时，需要 逐步进行扩容，直到恢复 逐步扩容,致命线 水位线低于致命线时，必须 立即扩容 立即扩容,虽然有了各种实时评估指标，但用什么标准决策依然是个难点。为此，我们在系统中引入了消耗比分级水位线。 具体来讲，就是划定三条线：安全线、警戒线和致命线， 消耗比水位线基于历史数据的经验值,分级治理：水位线,在线容量评估体系,Oops,目标服务池,消耗比,水位线,线上流量,性能监控,逐步减少服 务器数量,慢速比,是,否,3,1,2,决策系统,01,ITE M,02,ITE M,03,ITE M,04,ITE M,带宽限制 混合云的架构，不可避免地会出现流量在内网 IDC 与云服务商 IDC 之间的穿透访问，因此对网络出口 设备以及专线带宽的冗余要求极高，通过演练，可 以发现出口入口设备是否有瓶颈,安全限制 企业内部敏感数据访问都对IP来源和区域进行了 限制，当大规模扩容时，这些不太固定的IP可能 会无法访问某些数据，演练有助于完善这些规则,部署效率 镜像分发效率 节点创建效率 DCP并发能力,依赖服务 扩容上万个节点时，对DNS和负载均衡设备也带来 了巨大压力，需要通过演练来测试依赖服务的上限， 并予以解决,实时演练体系,01,02,03,04,运维自动化 资源管理、批量运维工具、 事件收集、配置管理,弹性计算 自动化扩缩容、多云适配、 压测和冗余度评估、分级 水位线,智能监控 海量指标、监控告警、异 常检测、故障定位,服务治理 自动注册、自动发现、熔 断机制，负载均衡,监控面临的挑战,01,02,03,04,实时监控和离线分析,大部分监控数据来自日志，但监控不需要精确，所以没有全量收集日志的需求，但离线分析（大数据）需要 准确性，又需要收集和处理全量日志，需要平衡这两种需求，尽量减少线上服务器的消耗,海量指标运算 监控指标的维度非常多，再加上指标随时间不断变化，监控数据实时性高，当指标多到千万级甚至亿级， 每日要处理百亿级别的数据，秒级查询和展示,告警问题 在复杂环境下，随着告警范围覆盖面日益完善，告警级别分类细致，告警事件过于敏感，容易造成告警风 暴，反而干扰了运维人员对故障的判断,问题定位 监控做的越全面，各种可视化、Dashboard也越来越多，如何从众多信息中准确定位故障根源，如果过 滤重复和不相关的信息,Oops整体架构,系统日志,业务日志,性能日志,接口日志,Filebeat,Logtailer,Flink,Kafka,HBase,HDFS,Statsd,Relay,Logstash,ElasticSearch,ClickHouse,Druid,Hive,Carbon,MySQL,TSDB Redis,Graphite,Grafana,日志查询,全链路分析,数据采集,数据清洗和计算,数据存储,数据可视化,告警,监控数据流向特点,数据源,Kafka,分析,存储,离线分析： 数据全量传 输到大数据平台 然后分析计算,实时监控： 数据在客户端 聚合只发指标,采集,采集/聚合,分发,监控,告警,可视化,展示,历史数据,实时数据,海量指标监控系统流程,App,Log,Framwork,Agent,Proxy,实时监控计算,历史计算,relay,内存,SSD,TSDB,Alert 计算节点,Redis,WatchD,告警中心,九宫格,Mail/sms,API,Graphite,Grafana,在线扩缩容,成本分析,辅助决策,A/B Test,Alert 计算节点,监控指标及九宫格展示,告警的问题,01,02,03,04,告警数量巨大 运维人员需要关注整个所有部分，从系统到服务、到接口等等，维度很多，一 旦有问题，各种策略都会触发报警，报警数量多到一定程度，基本上等于没有 报警,重复告警率高 告警策略一般会周期性执行，一直到告警条件不被满足，如果服务一直不恢复， 就会重复报下去，另外，同一个故障也可能引发不同层次的告警,告警有效性不足 很多时候，网络抖动、拥堵，负载暂时过高，或者变更等原因，会触发报警，但 这类报警要么不再重现，要么可以自愈,告警模式粗放 无论是否重要、优先级如何，告警都通过邮件、短信、App PUSH发送到接收人， 经常会让真正重要的告警淹没在一大堆普通告警中,抖动收敛 抖动或