微博现在日活2亿。微博广告是微博最重要、最稳定的收入来源。没有之一，所以微博广告系统的稳定性是我们所有广告运维工作的重中之重。图片来自Pexels微博广告运维主要承担资产管理、服务稳定性维护、故障应急处理、成本控制等多项职责。微博广告运维的发展经历了以下几个阶段：从早期的小规模手工运维到工具化运维，随着服务器数量的发展，商业模式逐渐发展，发展、运维、QA都涉及到产品生命周期，我们也进入了自动化运维阶段。在新的虚拟化技术和算法技术的推动下，我们也在向AIOps方向努力。在整个运维过程中，我们遇到了很多痛点。幸福的人生都一样，不幸的人生各有各的不幸，每个公司的运维都有自己的痛点。我们有3000多台服务器，各种业务线和辅助资源，产品迭代非常快，而且依赖关系复杂，流量变化，切换损耗无法接受。在这种情况下，我们面临着资产管理难、环境不一致、上线难、运维成本高等问题。基于这些问题，微博广告运维工作主要围绕以下四个方面展开：运维自动化弹性计算智能监控服务治理运维自动化一个完善的自动化运维平台必须具备以下功能：基础监控资源管理事件集中分析配置管理批量运维工具持续集成发布基于这些功能和需求，我司广告运维自主研发了昆卡平台（微博广告运维自主研发的自动化运维平台）、资产管理、自动上线等运维平台。资产管理是基于公司的CMDB（企业级资产管理系统）获取宿主云服务器，针对微博广告的资源管理需求，构建定制化的资产管理平台。配置中心包括服务注册、服务配置等功能；自动化启动涵盖了启动过程中开发所需的节点和流程。自主终端是行业变革的功能实现。您可以通过页面完成文件或命令下发、日志审计等各种任务。Kunkka基于宿主机和容器，使用Salt作为传输层下发命令。组件层包含开源软件，操作层将命令转化为页面，通过页面进行日常工作和管理。这样的自动化运维平台基本可以满足运维日常的操作需求。昆卡平台也有自动扩缩容的功能。我们将扩展此功能。在自动扩容的基础上，根据时间段和流量进行动态判断，实现自动决策的扩容功能。为什么ElasticComputing需要ElasticComputing首先在产品方面，我们的产品线很多，依赖关系复杂。微博广告就像一座桥梁。广告商连接到左侧，客户连接到右侧。要把广告主的广告计划转化为用户的需求，让用户看到自己想看的广告。为了满足双方的不同需求，产品的变更和发布是非常重要和频繁的。其次，在运营方面，很多有促销需求计划的大型活动都有临时扩张的需求，比如618、双十一。对我们来说，这两个事件带来了很大的影响。618、双十一促销前，各广告主为了增加影响力，都会增加广告投放计划，微博广告会根据广告主的行为增加我们的曝光量，从而实现广告主的广告投放计划。转换。618、双十一促销前，各广告主为了增加影响力，都会增加广告投放计划，微博广告会根据广告主的行为增加我们的曝光量，从而实现广告主的广告投放计划。转换。传统业务运维遵循传统运维模式，扩容计划从立项到服务器上线会经历很多流程和漫长的等待。从结果来看，服务器容量得到了扩展，对于传统项目来说，整体流程可控，这是它的优势所在。它的缺点是不言而喻的，包括以下几点：第一，时效性太差。按照新浪服务器的采购周期，从审核到上线需要两个月的时间。两个月后，服务器上线。新婚明星怕是都离婚了，突发状况的车流也过去了。此外，它无法准确估计容量。在传统的商业运维模式下，范冰冰分手、大宋离婚带来的流量无法变现，我们无法评估扩容能力。此外，传统模式的资源利用率较低，服务器难以在业务间共享。在这些问题的共同作用下，诞生了动态伸缩系统。ElasticComputing：实时动态扩缩容动态扩缩容不是一个工具，而是一个完整的系统。它基于云服务，包含在线压力检测和消费评估功能，最终实现分级治理。①弹性计算架构首先简单介绍一下弹性计算的架构。弹性计算依托于昆卡自动化运维平台和Oops监控平台。在业务压测的情况下，监控业务指标，并将数据发送给容量决策系统进行决策。扩大或缩小规模的决定。在云服务商方面，我们经常使用阿里云、华为云和一些自建的私有云。DCP混合平台是我们微博另外一个团队做了几年的平台。可对接云服务，快速生成云主机，实现快速扩容。今天的焦点与业务方有着最直接的关系：业务是否应该扩大？什么时候应该扩大？应该扩大多少？我们需要解决这样的问题。②决策系统在上面的架构中，我们提到了容量决策系统。容量决策系统其实就是指计算系统，它会对我们得到的业务指标进行计算和评估。比如系统的基本信息，一些业务日志源的信息等，获取当前业务的容量，通过对历史数据的同比和环比分析，来获取流量趋势并了解下一个流量会是什么样子。这两组数据的计算结果会给出放大缩小的建议。同时，他们会对这些数据进行计算和呈现，提供辅助的API接口，为上下游部门进行数据扩容和缩容。③能力评价方法该企业目前的能力如何？它健康吗？这个指标用来评价什么？由于业务系统、业务形态、架构的差异，选择一个实时通用的指标非常具有挑战性，我们也尝试了很长时间，引入了AVG-hits的概念。对不同时间的请求数进行加权求和，以适应单机的实际消耗。这表示在不同的时间间隔内花费的时间。我们给它一个系数，大于5毫秒小于10毫秒。根据给自己的业务做一个耗时分区，这样你就可以计算出来了。事实证明，相对于以往传统的单一QPS负载，综合数据在评估业务上比这个单一的指标更准确。获取这个数据后是否可以描述当前的系统容量？答案肯定不是。AVG-hits这个概念第一次来确实有点生涩。我举个简单的例子帮助理解，比如某业务的消费指标的衡量很简单，需要通过记忆来判断消费。如果监控指标显示内存消耗已经达到80G，能不能用80G来形容当前系统消耗？这个问题比较好理解，答案肯定不是，因为不知道服务器的最大内存。如果最大值是96G，那么80G已经超过了80%，已经接近危险值了。如果最大内存为256G，消耗不到30%，是一个很安全的值。道理是一样的，仅仅得到当前的消费值并不能描述业务的当前状态，需要另外一个评价标准。该业务目前最大承载能力是多少？看内存的话，简单，但这是一个综合的评价标准，怎么得来的？作为一个经验丰富的运维，我认为根据服务器目前的硬件性能，猜测最大容量不难，但是现在2019年了，猜测还不够，我们通过压测得到最大容量值。在实际环境中，将服务器数量减少到最少，记录当前容量值作为最大容量，用压力测试前的实际消耗值除以压力测试得到的最大容量，得到服务器的消耗比例整个系统。这个消耗比例被认为是当前系统消耗的写照。什么情况下压力测试可以达到最大容量，不能再压了？有必要把服务器压下来吗？我们引入了另外一个概念叫做消耗比，它显示在最大耗时区间内的Ahits（请求数）上（PPT：慢速比=100.0*当前容量（Ahits）/最大容量（max_Ahts））和请求总数的比例超过一定比例，是影响用户的表现。当压力达到最大值时，不能再按压，此时的Ahit数将被记录为接口的最大容量。④分级治理：水位现在有一个非常重要的容量值和容量评价的消耗比例，用来描述当前的容量消耗。得到这个消耗比例后，是否可以扩容？或者可以减少吗？这里需要一个评价标准，是不是30%就扩容了？还是扩大50%？我们在分析历史数据的基础上，制定了三个水位线，包括安??全线、警戒线和致命线，将当前消耗值与水位线进行比较，在不同阶段采取不同的措施。比如现在的消耗率远低于安全线，也就是说现在的服务器部署是多余的，我们可以逐步减少容量。如果现在高于致命线，则需要进行扩展，使这个值更接近安全线，以保证系统的稳定性。⑤容量在线评估系统现在具有自动扩缩容、电流消耗、水位、容量决策系统三要素。我们如何将这三点联系在一起？我们如何将它们连接起来完成展开动作呢？这些所有环节都包含在在线容量评估系统中，可以实现压力测试的过程。刚才我们说压测不是通过流量复制来模拟测试。我们使用在线流量记录目标服务的当前（Ahits）数量，并开始减少服务器数量，直到慢速比达到临界值。此时，记录Ahits的次数，作为这个服务单元的最大消耗。获取消费值后，与水位进行比较，调用决策系统做出扩容或缩容的决策，然后连接到云服务商，完成扩容的动作。⑥在实时演练系统前进行的数据采集、计算、一系列动作，都是为了完成最后一个目标，服务拓展成功。真实服务器扩容上线后，如何保证服务健康可用？我们还有一个辅助系统，叫做扩容钻。在实时演练中，注意以下几点：部署效率：我们通过扩容演练来寻找整个扩容过程中的瓶颈。例如，我们通过DCP连接到云服务提供商来交付扩展。在真正的在线扩容过程中，DCP有时需要同时承载上千节点的并发扩容。DCP的效率是否足够？这需要在扩容演练中得到证实。带宽限制：微博和云服务商之间确实有专线，但是微博和云服务商不仅仅是微博广告的生意，还有很多其他的大玩家。而且一般在流量增加的时候，他们的扩张也很猛烈，所以带宽是否可用也是我们在日常演练过程中非常关注的一个现象。依赖服务：这方面的案例很多。在这里简单分享一下。2015年春节期间，自动扩张和收缩的过程才刚刚开始。春节晚上我们扩容了上千个节点后，突然发现负载均衡加不上去了。我之前做过演练，但不会用几千台云服务器来扩容。也许可以使用几十台云服务器来保证功能可用。到时候负载均衡的同事需要通过配置文件添加Memeber。如果没有办法把几千台服务器加到负载均衡设备上，到时候大家手忙脚乱，最后只能手动扩容节点。大家都知道春晚的流量高峰期很短，但是那天真的给了我们一个打击。接下来，在扩展练习中，我们不仅要确认负载均衡，还要确认我们所依赖的服务。比如每次发生热点事件，大家都会说微博又崩了，评论又崩了，热搜搜不到。事实上，应对高峰流量是一件大事。我解决了问题，兄弟部门没解决，兄弟部门解决了，姐妹部门又出问题了。安全限制：6.18大促期间，京东同学分享扩容时新增服务器IP和VIP冲突，微博主要表现是数据库会对很多业务请求设置白名单，但是扩容云服务器之后IP是随机的。另外，新浪对通行证有很多IP限制，所以我们通过扩容演练系统不断发现各个环节的问题，并加以解决，确保扩容操作能够顺利完成，扩容云主机真正做到安全上网。在这个系统的加持下，到目前为止，自动扩容服务处于比较稳定的状态。智能监控在上面提到的自动扩缩容系统中，提到了一个叫做Oops的系统。这是微博广告运维人员建立的智能监控系统。下面我就给大家简单介绍一下。监控的挑战说到监控，不得不说监控遇到的问题很多。市面上有很多开源的监控软件，比如常见的Zabbix，在监控数据量不大的情况下，无论是基础监控还是业务监控，这些开源软件都可以直接满足需求。但是随着监控指标的增多，而我们的指标是实时变化的，对数据的要求也比较高，这些原生的软件已经不能满足我们的需求了。此外，微博广告的业务数据是特定的。一般运维关注的数据是系统性能，而系统性能数据有时来自于业务日志。但是微博广告的业务日志是收入，很多业务日志是不能丢的，比如结算曝光。每一次曝光都是真金白银的广告投放，精准度要求高。单靠性能监控的日志采集方式无法满足需求，这也是我们面临的挑战。此外，监控系统一般都具有报警功能。如果有报警，就会出现报警问题。接下来详细介绍告警问题。我们也面临着定位的挑战。在监控越来越完善的基础上，很多开发操作都发生了变化。一旦出现问题，第一反应不是跑到服务器上看系统有什么问题，而是通过监控，看看哪些监控指标有问题。因此，监控系统将越来越面向问题定位。Oops整体架构面临的挑战作为一个监控系统，Oops的架构没有什么奇怪的。所有的监控无非就是四个阶段：从客户端采集数据、数据清洗计算、数据存储、数据展示、监控数据流特征。任何监控系统都无法逃脱这四个阶段，而是根据不同的业务进行定制化工作。对于广告业务的监控流量，我们将数据分为两类。对于一些精准数据的计算，我们采用离线分析的方式，通过采集软件将所有日志采集到Kafka中，使用计算工具进行拆解、清洗、计算。计算后存储。另一个团队针对这部分数据开发了页面展示，还有一个系统叫做Hubble，针对精细数据的展示实现了个性化、定制化的展示。另一部分是运维比较关心的数据。今天来了多少流量？多少流量才算正常？多少是不正常的？数据收集阶段发生了变化。我们不收集完整的日志，而是在客户端进行预处理并进行分类计算。例如，监控数据按照监控数据的方法进行计算；报警数据根据报警数据计算。而且根据用户阅读的需要进行分类存储，保证了高并发数据的实时性。质量指标监测系统流程下面详细介绍一下实时数据的计算。首先，在数据采集方面，如前所述，我们并没有采用全量采集的方式，而是通过Agent对数据进行处理。在数据采集阶段，在产生数据的服务器上，在不同的时间根据不同的需求进行分类聚合，最终推送回来的数据是key-value的模式和计算方式，被推送到代理。Proxy拿到打包后的数据，解包后发送到不同的计算节点，然后根据Key进行计算，打上时间戳。这个数据不准确，但是我们可以接受一些损失，只要数据的趋势是正确的。另外，对于分类计算，不同的需求被推送到不同的计算节点。存储也被分类。如果实时性要求比较强，就直接存入内存，以最细的粒度存储。前三个小时的数据以秒为单位存储，以天计算的数据以10秒、30秒为单位存储，部分单机数据以分钟为单位存储。此外，还需要上报一些历史数据，比如前一周、上月的数据，这些数据以大数据的形式存储在OpenTSDB中。存储的数据提供了一个API。通过API，我们进行分类计算和分类存储。这个分类的需求来自于用户，我们要看用户有什么需求，想要什么样的数据。比如Dashboard的显示数据会直接存储在内存中。另外，上面提到的在线扩缩容数据会获取到用户对应的数据，其他相关的获取需求API也会进行分类获取。接下来我们计算出来的部分数据会通过WatchD存储到Redis中作为报警中心的数据，因为报警数据一般只需要当前的数据，不需要去检查负载上是否有报警这台机器上个月。所以Alert节点计算出来的数据直接存储在Redis中。Redis根据报警规则将这些数据取出并通过报警中心清洗，通过各种方式推送到需求方。同时，还有一个相对个性化的陈列，叫做九宫格。我们的九宫格其实就是一个监控结合报警的功能。它是一个页面，但它具有报警功能。接下来我们来看一下监控图。下面三张图是范冰冰宣布分手获得的流量。我们的反应很灵敏，平均耗时也增加了。第三张图，自动平台拿到数据后，显示要扩容。蓝色和绿色的流量线已经降低，大部分流量已经转移到云服务器。下图就是我们的九宫格。由于时效性强，通常产品是页面，业务线是网格。每个网格记录了单台机器的详细信息。如果这组服务器中单机故障的数量超过一定比例，网格就会变色。所以一般的运维工作站上都??会有这么大的屏幕，运维可以一眼就知道自己负责的所有业务线的情况，而不是让每一台机器都显示在这里，这样就看不到业务线上的情况了。九宫格让运维更直观的看到当前告警情况。警报有很多问题。我们遇到的问题可以分为以下四个方面：①告警数量庞大。运维人员需要关注各个部分，从系统到服务、接口等，维度很多。攻略会触发警报，警报次数达到一定程度，基本相当于没有警报。②重复报警率高的报警策略一般周期性执行，直到不满足报警条件。如果服务没有恢复，会反复上报。此外，同一故障还可能触发不同级别的告警。比如我们有一个业务线叫潮粉，会有360台服务器。当流量高峰时，360服务器会同时发出警报。此类告警的重复率非常高。③告警有效性不够很多情况下，网络抖动、拥塞、临时负载过高或发生变化都会触发告警，但此类告警要么不再出现，要么可以自愈。比如硬盘快到80%就开始报警，要不要报？好像非要报，不报好像也可以。④广泛的报警方式无论重要与否，通过邮件、短信、AppPUSH等方式将报警发送给接收者，如风暴般袭击接收者，接收者无法从中获取有效信息，往往使得真正重要的警报淹没在普通警报的海洋中。针对这些问题，我们采取了以下措施：①抖动收敛抖动是这种大型服务器维护中非常普遍的现象。如果网络动摇，整个服务单位都会提醒你。对于这种抖动，我们添加了一些策略。抖动的时候，我们会前后对比，监控重复性，看是否有警告的意义，通过加入警告策略收敛。例如，当流量突然增加时，需要检查这种情况是否发生在同一个单元中。②告警分类分级详细定义告警级别、发送优先级、升级策略等，可以有效减少粗放模式下收到的告警量。比如会上报一些低优先级的告警，处理级别会低一些。③由于相同原因合并相同类型可能会触发服务池中的所有实例报警。例如，它们不能同时连接到数据库。事实上，只需要一份报告。④忽略改动我们的很多改动都是在昆卡平台上操作的。有时候开发会选择一个notification，现在就是一个change。请忽略该警告。以上措施可以解决80%的报警问题。现在大家都在往更高级的方向发展，我们也做了一些简单的探索。在原有告警数据流的情况下，引入工具SkyLine。该工具包含多种算法。在异常检测环节，它可以通过内置算法自动对我们传入的数据进行去抖动，提供流畅的数据。当得到这个数据的时候，就不需要去检测是否是报警了。该工具避免人工操作，通过Skyline对数据进行平滑处理，提供准确的数据。我们只需要根据这些数据进行规则判断，决定是否需要报警，降低了判断数据准确性的复杂度。过程。然后是根本原因分析部分。随着监测的覆盖范围越来越广，监测的准确性也越来越高。当出现故障时，开发人员会通过监控图查看可能导致故障的原因。随着Dashboard越来越多，即使是非常有经验的工作人员也很难快速定位到会出现哪一方面的原因，看哪张监控图。当流量突然增加时，Skyline会使用内部算法Luminosity寻找类似情况，同时检查其他地方是否有异常流量，并将问题的根本原因显示在TOPN上。这样可以快速查看故障发生前后哪些业务有流量变化，便于分析定位故障原因。服务治理还有一个很重要的工作——服务治理，这里只简单介绍一下。为什么我们需要服务来管理微博广告？这一阶段的主要问题是：结构越来越复杂。上面提到的微博广告的服务器数量已经达到了3000台。所以在这种服务器数量的情况下，架构会越来越复杂，对稳定性的要求也会变得非常高；多语言发展环境也对在线发布提出了挑战；资源使用是否合理，也是运维的问题。挑战。低成本和高可用的平衡针对这些问题，我们平衡了低成本和高可用，力求用最小的服务器实现最稳定的架构。在保证服务稳定性的情况下，将流量平均划分为最小的服务单元，部署在三个机房，保证一个机房宕机时，另外2/3的服务器可以承载所有的流量。关于上下游调用平衡，尽量减少跨运营商调用。微博广告消费的每一毫秒都会影响收入。我们的请求时间优化了1毫秒和1毫秒。这些损失是在网络和服务器上产生的，人工很难弥补，所以我们在这方面也很谨慎。另外，小功能会将功能的共性点抽象出来，将这些功能进行服务化，以服务为单位进行部署。服务发现与负载均衡在服务治理过程中，我们会根据服务的引入自动发现服务，最大限度减少人工干预服务变更，提高安全性和实时性，自建负载均衡将有标准的数据输入而数据发布的过程可以极大的提高后期的扩展性和易用性。服务治理成果经过近半年的服务治理，我们取得了如下成果：架构更加健壮，容灾能力提升，标准化服务器合理使用，成本控制。其中，我认为最重要的是系统、数据、Configuration标准化流程。今天分享的很多嘉宾也提到了AIOps，而这些上层的建设，取决于整个业务标准化的过程。中国有句古话，工欲善其事，必先利其器。我们所有的标准化过程都是为了为下一步的人工智能打下坚实的基础。我们希望我们的工作能够用技术来保证微博系统的稳定，帮助微博广告收入。孙艳，微博广告基础运维负责人，2009年加入新浪，参与博客、图片、视频、微博平台监控、微博广告运维10年，致力于运维自动化和产品结构优化、服务治理、智能监控和基于监控的服务容灾建设。
