支持百亿级请求的微博广告运维技术实践复杂度的增加和服务可用性的提升，使得运维工作变得越来越重要。我们可以回顾一下迄今为止运维发展的阶段。①人工阶段这个阶段的运维主要是通过人肉来操作我们的服务。由于这个阶段大部分服务都是单实例，流量服务器相对较少，我们可以通过命令行解决大部分问题。②在工具阶段，随着互联网的影响力越来越大，我们的流量也开始越来越大，我们的产品功能也开始越来越丰富。我们的单实例服务也开始向多实例和分布式发展。为了应对逐渐增多的我们开始使用一些运维工具比如Puppet，通过Shell和Python编写一些脚本来提高运维效率，减少重复劳动。③DevOps几年前，运维领域开始提出DevOps的概念，开始解决运维与开发之间的协作问题，开始将运维工作标准化、平台化。让一个产品从功能开发到测试交付，再到后期的运维，更快、更频繁、更可靠，更快地响应互联网的快速发展和产品迭代。④AiOps近两年人工智能和大数据异常火热，运维领域的很多岗位都为AI和大数据的落地提供了良好的土壤。我们也希望通过AI、大数据等技术的引入，让运维的技术水平更上一层楼。通过上面的描述，我们可以看出运维工作是互联网产品技术链中不可或缺的一环，那么我们就来看看微博广告团队，我们用什么解决方案和措施来服务微博广告产品。对于我们微博广告团队来说，服务的可用性是至关重要的，也是我们的核心KPI，所以保证广告服务的稳定性也是我们运维工作的重中之重。我们将主要通过优化系统和提高效率来保证和提高我们服务的可用性。具体涉及的内容包括系统性能评估、故障快速定位、紧急事件处理、请求链接跟踪、代码快速迭代、指标趋势预测等。▲图1-1微博广告中的运维价值2.复杂业务场景下的运维建设1.服务治理图2-1是去年IG夺冠时王思聪的一篇博文。微博广告的影响如图2-2所示。这种突然的流量波动是微博的典型特征之一。它不同于双十一和其他活动。可以提前预测路况，提前做好准备。在传统的运维场景中，流量高峰可能在你准备好之前就已经过去了。因此，应对这种突如其来的流量高峰是我们需要重点关注的问题之一。▲图2-1▲图2-2从去年开始，我们的运维团队开始以机房为中心进行服务管理。以往很多广告业务都是在单机房部署，很多多机房部署也面临着部署不均衡、流量不均衡的问题。跨机房请求无形中增加了整个广告链路的请求时间消耗。因此，当机房层面出现故障时，我们的服务可能如图2-4所示，服务的高可用无从谈起。▲图2-3▲图2-42019年上半年，经过半年多的时间，我们完成了微博广告基于机房层级的服务优化改造。共管理100多个业务，所有业务分布在两个或多个运营商和机房，避免了单个机房出现故障时广告业务不可用的情况。我们在治理过程中坚持的准备工作主要包括以下几点：多机房均衡部署服务分布在不同运营商机房承载能力冗余流量请求在同一机房上下游均匀分布发现服务瓶颈我们的系统链接。我们将生产环境的流量重新复制到生产环境，增加线上流量，发现服务性能瓶颈。图2-5是我们对某广告产品的整体性能压力测试的结果。我们可以很明显的发现图中有两个模块在流量高峰下耗时波动较大。这使我们能够相应地进行优化。▲图2-52，自动化运维平台随着互联网的发展，我们的广告产品也是日新月异，迭代频繁。我们的运维团队每天需要面对300多个业务方的在线需求，对3000多台机器进行服务变更等操作。如何提高在线服务的效率和质量，如何让变化安全可靠也是我们的重要目标之一。▲图2-6从2017年开始，我们的运维团队开发了一套自动化运维平台Kunkka，主要基于SaltStack、Jenkins等技术，可以实现服务的快速上线和快速回滚。总体架构如图2-7所示。▲图2-7Kunkka整体架构开发同学将代码提交到Gitlab后，会自动触发Jenkins的编译操作，并将编译好的包上传到Nexus。这个时候开发同学只需要选择自己要部署的目标主机即可。同时，为了应对突如其来的流量高峰和节假日流量高峰，我们还接入了公司的DCP平台，可以在我们的昆卡平台上自动生成一个Docker镜像文件，并上传到公司的镜像仓库中，这样，可用于快速部署服务到云主机，实现服务的动态扩缩容。在整个服务部署过程中，我们还加入了多级审计机制，确保在线服务的安全性。具体过程如图2-8所示。▲图2-8Kunkka上线流程图3.有效报警服务上线后，我们要做的一个很重要的工作就是给我们的服务添加一个监控和报警机制，否则我们就像盲人一样运行我们的系统服务有关情况一无所知。关于报警系统业内优秀的报警系统很多，采用的方案也基本相同。我们目前主要使用的是开源的Prometheus报警系统，这里不做详细介绍。这里我主要想谈谈我们对报警的一些思考。比如我们经常遇到的一个问题就是报警邮件的狂轰滥炸。每天会收到上百封告警邮件，很容易导致系统中一些重要的告警信息消失。对此，我们主要考虑以下三个方面：质疑需求的合理性报警聚合跟踪溯源首先，当业务方提出报警需求时，我们要学会质疑他们的需求，因为并不是每一个需求都是合理的，其实很多开发者不知道怎么报警，也不知道怎么监控自己的服务。这个时候，就是发挥我们运维人员价值的时候了。我们可以在充分了解服务架构属性的前提下提出自己的意见，与开发者一起确定每个服务需要告警的关键指标。其次，我们可以预先聚合警报。现在我们大部分的服务都是部署在多台机器上，一个服务可能部署在几百台或者几千台机器上。有时由于人为失误或上线策略，服务可能会集体下线。这时，不同主机会发出数百条相同的告警信息。对于这种场景，我们可以通过告警聚合，将一段时间内相同的告警合并成一条消息，通过一封邮件发给开发者，避免邮件轰炸。关于告警聚合，像Prometheus这样的告警系统已经支持了，所以不会有太大的发展。最后，在更高的层次上，我们可以使用一些策略和算法来关联我们的警报。很多时候，一条业务链路上的某个环节出现问题，可能会导致整条链路上的多个业务触发告警。这时候，我们可以利用服务之间的关联、上下游关系，使用依赖、算法等一些措施，屏蔽关联的告警点，只对问题的根本原因进行告警，从而减少告警的触发次数。图2-9是我们运维团队17年优化告警期间的告警数量趋势。▲图2-9有效告警4.除了在全链路Trace系统中加入告警外，在服务上线后，我们往往需要跟踪我们整个服务链路处理请求的性能指标要求。这时候我们就需要一个全链路Trace系统，方便我们实时监控自己的系统链路，及时排查和定位问题。在全链路Trace系统中，最重要的是Traceid，它需要贯穿整个链路，我们通过Traceid来关联所有的日志，从而跟踪一个请求在整个系统链路上的指标行为。图2-10是我们同意用于全链路Trace的日志格式信息。▲图2-10日志格式及分析有了日志后，我们就可以根据这些日志进行分析和关联。上面提到Traceid是我们整个系统的核心，我们通过Traceid关联所有的日志。如图2-11所示，所有的日志都会写入到Kafka中，由Flink处理后进行实时日志分析，然后写入到ClickHouse中。有了这些关键的指标数据，我们就可以在此基础上做我们想做的事情，比如形成请求跟踪、日志检索、指标统计分析等服务拓扑。▲图2-11数据采集和处理所有数据采集和分析完成后，业务方可以根据一些维度，比如UID，来跟踪用户在整个广告系统中的请求处理，如图2-12所示。然后将查询到的数据与Traceid维度关联起来展示给用户。▲图2-12业务查询3.海量索引监控平台Oops实践最后，我们来看看如何应对微博广告海量索引数据下的多维度监控需求。前面说过，监控告警就像我们的眼睛，让我们实时看到自己系统内部的运行情况。所以每个服务都应该有一些关键的指标通过我们的监控告警系统来展示，实时反馈系统的健康状态。如图3-1所示，搭建监控平台非常简单。我们对指标、日志等数据进行ETL清洗，写入时序数据库，然后通过可视化工具展示。报警的办法。但是在这个过程中，随着我们数据量的增长，我们的指标的增长，查询复杂度的增加，我们可能会遇到监控指标延迟、数据偏差、系统不稳定等问题。▲图3-1监控平台面临的挑战因此，在设计我们的监控系统时，不仅要考虑它的实现，还要考虑它的稳定性、可执行性和准确性。同时，要尽量使系统简单易用。▲图3-2监控平台的目标我们现在的监控平台Oops也是基于以上原则，经过了多年的迭代和测试。图3-3是我们目前Oops监控平台的总体架构。▲图3-3Oops监控平台架构①数据采集整个平台分为四个层次，首先是我们的数据采集。我们目前主要通过一个优秀的开源采集客户端，比如Filebeat来采集我们的日志。对于我们的使用来说，Filebeat足够高效，轻量级，灵活易用。▲图3-4Filebeat架构图②在Kafka中收集指标清洗数据后，我们根据具体的业务需求提取指标。如图3-5所示，目前主要使用Flink解析日志写入ClickHouse。同时，对于一些业务需求，我们需要关联一些索引维度。这里索引关联主要是通过HBase实现的。比如有曝光和互动的两篇日记。我们将曝光日志中的mark_id字段作为rowkey写入到HBase中，并保存一个小时。当交互日志在时间窗口内匹配到相同的mark_id时，会从HBase中取出曝光日志的内容，与交互日志结合形成新的日志，写入新的KafkaTopic中。此外，我们还将Kafka中的数据消费写入ElasticSearch和HDFS中，用于日志检索和离线计算。▲图3-5指标清洗③指标存储目前我们使用ClickHouse来存储和查询我们的监控指标。最初，选择了流行的时间序列数据库Graphite。但是在长期的使用中，我们发现Graphite在复杂的多维分析方面并没有很好的体验。去年，我们用现在的ClickHouse替换了我们的监控指标引擎。ClickHouse是一个优秀的开源OLAP引擎，在多维分析等功能上比传统时序数据库有很大的优势。同时，我们基于ClickHouse强大的功能和物化视图表引擎构建了实时指标仓库。如图3-6所示，我们将清洗后的指标写到一个原始表中，比如这里的ods_A，然后根据具体的监控需求对ods_A表进行维度聚合。再比如，我们把request维度按秒聚合成agg_A_1s，或者按psid维度按分钟聚合成agg_A_1m_psid，或者按userid维度统计每个用户的访问次数。这样就可以实现不同时间维度、不同业务维度的联合分析查询，同时提高查询响应速度和数据的复用率。原始表的存在也让我们可以根据不同的需求定制不同的复杂聚合表数据。▲图3-6实时指标仓库④指标可视化最后，我们使用Grafana来实现我们的指标可视化。Grafana应该是世界上最流行的开源监控和可视化软件。它支持多种数据源，ClickHouse就是其中之一。我们只需要写一个SQL，按照我们的想法在Grafana上以图的形式呈现即可。图3-7所示的监控图是通过如图3-8所示的简单SQL实现的。▲图3-7折线图监控指标▲图3-8折线图监控指标SQL语句对指标的监控和表格展示也很简单，一条SQL就可以完成，如图3-9所示。▲图3-9表监控指标目前我们的实时指标仓库存储120T数据量，峰值处理QPS约125万，秒级查询，多维度分析，指标监控，数据分析和微博广告链接跟踪等场景提供底层数据支持。讲师介绍了朱伟，微博广告SRE团队负责人，《智能运维：从0搭建大规模分布式AIOps系统》一书的作者之一。目前负责微博广告业务的可用性保障和优化、资源利用率的提升、监控报警系统的建设和自动化系统的推广。
