共计 9861 个字符，预计需要花费 25 分钟才能阅读完成。
一分钟精髓速览
本文概述了挚文团体（陌陌和探探母公司）在微服务架构下解决故障定位问题中遇到的痛点、解决方案以及获得的成果。通过构建对立可观测平台，实现了故障疾速定位，大幅晋升了问题定位的效率。文中还探讨了存储优化、数据采集、链路追踪等相干细节。总体上，可观测平台在挚文团体外部已失去了宽泛使用和较好的业务撑持功效。
关键词：可观测性；微服务；监控；链路追踪
作者介绍
挚文团体根底平台技术总监——童子龙
TakinTalks 社区特邀讲师。2022 年退出挚文团体，目前负责陌陌和探探的根底平台部门，蕴含基础架构、中间件、监控、零碎平台等团队。曾就任于腾讯云中间件团队任职技术专家，腾讯云微服务 TSF 开源社区 Founder，专一于微服务治理、基础架构、精益治理、云计算及分布式中间件技术等。
舒适揭示：本文约 7500 字，预计破费 13 分钟浏览。
「TakinTalks 稳定性社区」公众号后盾回复“交换”进入读者交换群；回复“0809”获取课件材料；
背景
挚文团体于 2011 年成立，2014 年 12 月 11 日在美国纳斯达克交易所挂牌上市（NASDAQ: MOMO），领有陌陌、探探等多款手机利用，以及电影制作发行、节目制作等多元业务，其中两款次要社交软件——陌陌和探探，它们的月沉闷用户别离达到了亿级和千万级。此外出海等业务，在东南亚和中东地区也领有宏大的用户群体。因而，整体公司的业务规模十分宏大，领有数万级线上实例数和千万级的峰值 QPS，全天调用超过万亿次。
挚文团体是微服务畛域的晚期探索者之一。自从 2013 年 RPC 理念在国内风行以来，咱们就开始采纳微服务架构。尽管微服务架构进步了团队的合作效率，但也带来了一些问题，比方服务调用链路简单、故障定位艰难、性能瓶颈定位艰难、问题定位依赖专家教训等。
面对一直增长的业务规模和复杂度，咱们须要从零开始摸索和实际，找到一种高效且低门槛的形式来解决这些问题。
一、故障定位遇到了哪些挑战？
在晚期，咱们没有系统地实际可观测性工程，通常是像消防员一样，哪里起火了就去灭火，而后再找一些专用工具来解决问题。这导致咱们应用的工具十分多，而且彼此之间是独立的。例如，当服务利用呈现故障时，咱们须要查看根底监控、业务打点、谬误日志等；而当底层零碎呈现问题，如 CPU、内存堆栈和线程问题时，咱们又须要应用其余工具来查看。这样的状况导致整体体验十分差，解决一个问题可能须要破费 3 分钟去寻找适合的排查工具，再破费 10 分钟查看数据，而且这些数据无奈进行联动剖析，咱们还须要手动编写文档来整合信息，能力深入分析问题的本源。
这种状况带来了两个问题。首先，应用这些工具的门槛十分高，新人很难把握。其次，效率十分低下，故障排查依赖教训，须要高级专家的染指。咱们尝试过专家会诊制度，但这并不是一个最现实的解决方案，作为技术管理者，咱们心愿任何人都能参加故障排查，而不是依赖于多数资深人员的教训。如果专家刚好不在呢？线上故障排查是十分庄重的事件，不能靠个人主义和运气，更须要一套健全牢靠的工具和机制。
通过一直摸索和实际，目前挚文团体绝大部分故障定位都能在 3 分钟内实现，即便是新人无需培训也能实现相干工作。接下来，我将重点分享相干平台工程的建设办法和技术要点。
二、如何构建一站式观测平台解决？有哪些技术要点？
要解决问题定位的最初一公里，咱们的施行方向是什么？要达成哪些指标？要怎么着手做？带着这些问题咱们进行了大量的调研工作，包含钻研行业内成熟的商业产品和技术、以及访谈行业专家，理解他们的观点和实际办法，而后以此为根底，咱们设定了一个指标——建设一个对立的可观测平台，数据协同实现简略高效的可观测性能力。
2.1 可观测平台工程指标
咱们须要从两个方面来设定指标：效率和门槛。
首先，咱们的指标是让任何人，不论是老手还是较低级别的开发人员，都可能疾速精确地找到问题所在，而不须要依赖专家教训。为此，咱们打算建设一个企业级的平台工程，数据采集、剖析工具化、产品化，来升高应用门槛。
其次，咱们谋求更加全面的可观测性，笼罩整个软件生命周期。咱们须要建设欠缺的基础设施，从开发环境到测试阶段，再到生产环境，实时监测和剖析零碎的运行状态。通过及时发现并解决问题，来确保零碎的稳定性和可靠性。
2.2 分布式 Trace 追踪
咱们须要先明确分布式 Trace 追踪的目标是解决哪些问题。它能够帮忙咱们理解服务之间的调用行为，疾速定位异样问题，进行准确的链路调用性能剖析，包含办法和整个利用内的性能追踪和监控。接下来，咱们须要思考如何施行这个追踪零碎。
（分布式 Trace 整体架构）
首先咱们心愿基于开源组件的根底上自建生态，为什么保持基于开源规范自建呢？因为开源有人才规模效应，从治理角度，不心愿根底平台被自研技术栈绑架。另外，咱们心愿实现业务接入的无侵入性，缩小接入老本，并反对动静下发采集策略，使用户接入层更稳固灵便，不会给业务带来任何 Debuff。
分布式 Trace 追踪零碎整体架构分为三层：接入层、解决层和平台层。
接入层：嵌入利用过程，依照 Opentracing 协定收集 Trace 信息，通过插件化的传输协定发送给 Server 端，接入层的采集数据能够传输给任何反对 Opentracing 协定的 Server 端解决。
解决层：接管接入层采集的 Trace 数据信息，而后对采集的数据进行剖析和聚合，生成性能指标、统计数据和可视化报告，将解析后的数据长久化到 ES 集群。
平台层：负责 Trace 链路实时检索，指标统计可视化报告，Trace 配置管理下发。
动静下发策略解决了什么问题？在 Trace 采集过程中，咱们采纳了多种灵便策略。例如，咱们对于一些有价值的用户和服务，晋升采样概率；咱们能够依据 CPU 负载进行熔断，并为不同的利用设置不同的阈值，以适应不同的生产状况，保障线上业务的稳定性。
具体的架构细节将在后续进行具体解说。总体而言，接入层负责采集数据，而后通过 Kafka 传输到接收端进行聚合剖析。平台层将下发配置，并提供 Trace 实时检索和离线统计分析的能力。
然而，整个施行过程并非欲速不达。正如后面提到的，咱们是从零开始摸索这个过程，因而咱们面临了许多问题和挑战，有些状况和挑战甚至导致咱们的计划无奈顺利落地。咱们须要不断改进技术计划，以应答这些挑战。
挑战一：链路采集端保护老本高
咱们面临的第一个问题是，保护链路采集端的老本十分高。晚期咱们采纳了 SDK 的形式，因为波及多种语言和框架，如 PHP、Java 等。在理论落地过程中，咱们发现这种形式的推广老本十分高。首先，波及到的团队太多，导致沟通老本很高。其次，推广和降级的工夫十分长，因为须要失去业务方的配合。整个版本的碎片化问题也会变得十分重大，因为有些业务不迭代或者零碎自身因为各种起因无奈进行降级。
技术要点 1：下沉 Agent 模式采集链路
在进行了一些行业调研后，咱们开始调整计划——支流的 Java 语言朝着 Agent 方向改良，其余语言也尽可能地能力下沉，采纳 Instrumentation 或者 Ebpf 抓取 Syscall 机制。
Java Agent 模式采集是基于 JVM 原生机制。具体来说，咱们应用了 JVM 提供的一种叫做 JVMTI 的接口工具。它的工作原理如下图所示。
通过动静注入字节码形式，咱们能够基于 Opentracing 协定，组装服务之间的调用关系，获取办法调用工夫、主动捕捉异样以及异样日志等。这种形式有两个长处。首先，它采纳了动静注入的形式，不须要业务方去批改代码。这样就解决了之前所提到应用门槛和沟通老本高的问题。相比之前的 SDK 等形式，推广老本大大降低了。其次，因为微服务组件的生态规模越来越大，咱们能够很低成本适配各种基础设施并进行字节码注入。
技术要点 2：基于开源扩大的 Agent 插件
后面提到，咱们是基于开源组件进行扩大，并对外部的中间件插件和 RPC 插件进行定制。咱们心愿在开源范式下发展这些工作，并且心愿为社区做出奉献，将遇到的共性问题分享给开源社区一起解决。通过这种合作形式，进一步升高整体的保护老本，即便人员流动，新的共事和社区成员也可能轻松接手和保护这套零碎。
在这个过程中，有一个细节须要留神。因为一些插件可能存在不同的版本，比方 1.0 和 2.0 版本的应用办法不兼容，有些代码的出参和入参也不一样，可能会导致不兼容或逻辑产生较大变动，因而咱们还须要在一个 Agent 中解决插件版本的兼容问题，开源原生的 witnessClass 匹配的机制能比拟奇妙的解决这个问题。
此外，咱们还遇到了许多跨线程相干的问题。为了应答其中潜在的危险和矛盾，咱们对整个跨线程池调用进行了大量的梳理和治理工作。
技术要点 3：构建工具为生产推广提速
为了更好的解决推广和保护老本的问题，仅仅能力下沉依然不够，Agent 作为 Premain 探针，须要用户在启动时增加参数，实例需用重启。为了在保障推广接入过程稳固不出故障的同时，让生产推广提速，咱们构建了两个重要工具。
CI/CD 平台对于不同服务大规模单实例批量灰度工具，可能实现在同一时间大批量的服务进行单实例的扩容灰度接入，对于灰度实例主动挂载探针包，主动增加启动参数。
对于生产的大规模变更进行主动异样检测，对于线上大规模的灰度公布变更，无需 SRE 人工值守，对黄金指标的稳定和异样能自动检测告警，SRE 能疾速针对有异样服务迅速回滚，缩小因变更引起的故障范畴。
当然整个工具链构建过程比较复杂，甚至能够另起一篇，这里临时不具体开展了。
挑战二：Trace 完整性问题
Trace 的完整性问题是整个行业都面临的一个共性痛点。在采样方面，目前有两个次要方向，一个是尾部采样，另一个是后置采样。
因为陌陌和探探的调用量每天都达到万亿级别，数据量十分宏大。如果要继续地进行全量采集，存储和查问的老本将难以承受，查问性能也会受到很大影响。另一方面，如果要实现全量采集，采集端的 CPU 耗费也会十分高，因为每个 Span 都须要进行采集、传输和剖析。
尽管开源社区曾经提供了一些采样率限度策略，但这些策略并不能解决上述两个问题。如果链路缺失，咱们排查问题的效率就无奈进步，用户体验也会大打折扣。因而，咱们的指标是在不影响用户排查体验的状况下，尽可能降低成本。
在明确了这个指标后，咱们开始着手解决这个问题。
技术要点 1：老本 & 价值导向的采样策略
咱们首先依据老本和价值的考量来确定采样策略。咱们明确了用户关注的链路重要等级，例如呈现谬误、高耗时的状况以及确保整个链路拓扑图的完整性等等。在这个根底上，咱们能够进一步抉择适宜的采样策略。
技术要点 2：自定义的 Agent 采样策略
在咱们探讨自定义采样策略之前，先来谈谈行业通用的尾部采样。尾部采样是指在整个链路的 Trace 残缺采集实现后，对链路进行剖析，筛选出有价值的链路，例如呈现谬误或者耗时较长的链路，这些链路会被残缺的传输到服务器端进行进一步的剖析，保留有价值的链路，而失常的链路则会被概率性抛弃。尾部采样保留了整个链路的完整性，但对采集端的性能有较大影响，网络传输开销也比拟大。然而，对于一些性能、资源耗费敏感的业务来说，不能承受 Agent 对 CPU、内存等业务资源适度占用。为了解决这个问题，咱们提出了后置采样策略。
后置采样的思路依然是如何保留用户最关注的链路，在不削减用户体验的同时，最大限度地缩小老本和损耗。在采样前置阶段进行 CPU 阈值剖析和熔断爱护。咱们会依据利用的 CPU 应用状况判断是否进行采样，防止对业务造成额外负担。例如，如果业务的 CPU 处于较高水平，咱们就不会进行采样，以防止进一步耗费其资源。
每个探针都能够针对性地设置熔断阈值，以爱护零碎。如果没有熔断，咱们能够进行百分比的概率采样。须要留神的是，有些服务办法的 QPS 很低，可能一小时只有一两条记录，但这并不意味着这条链路不重要。因而，针对这些低频办法，咱们也须要设计一些策略来保留，以确保它们在肯定的工夫窗口内被采样到，不受概率影响。
而在申请后置阶段，谬误和高耗时的链路是必采的。如何断定高耗时，咱们会依据每个探针的预设值进行设置，以便将其记录下来并在 Tracing 链路中查看。
综合起来，咱们的采样策略是基于概率采样、低频办法兜底和后置采样的组合。这样能够最大水平地缩小对业务资源的占用，同时保留最有价值的链路。咱们的指标是在最小化节约的同时，将 Trace 采样完整性、高价值做到极致。
（常见采样形式比照）
全量采样是将所有链路都进行采集、传输和存储，但这种形式的存储老本十分高，可能须要上千亿台存储节点，老本十分低廉。
频次限度是社区比拟通用的采集形式，但它的一个很大毛病是整个拓扑图不残缺，链路的缺失重大，这会重大影响业务排查问题的效率。例如，当业务方收到一些告警并心愿通过咱们的平台进行排查时，却发现无奈看到他们的申请，这会给业务带来很大的困扰。
尾部采样集体认为惟一的毛病是对采集端的性能影响较大，网络传输老本高。但对业务来说，它的体验应该是最佳的，因为它保障了链路的完整性，无论是异样链路还是失常链路，都能残缺地展现进去。
后置采样尽管不能像尾部采样一样保障链路完整性，但咱们的指标是在不影响业务排障体验的同时，最大水平地保障链路的完整性，来节俭采集端损耗、传输老本、存储老本。最初的成绩整体也十分可观，评估下来采集老本能够升高 90.9%，存储老本能够升高 99.9%。
挑战三：Trace 存储老本
存储是整个老本中最大的一部分，无论是专门从事这一畛域的 ToB 服务公司，还是企业技术团队自身，在存储方面的老本都在一直寻求提高。挚文团体也不例外，心愿尽可能升高存储方面的老本。
技术要点 1：Trace 存储数据分析
为了实现这个指标，咱们在存储 Trace 数据时进行了大量的数据分析，而不是自觉采纳某些计划。
在进行有效性剖析时，咱们发现服务端在进行聚合剖析时会产生许多无用的 Metrics 数据，这些数据量相当大，根本达到十亿级别。对于这些无用的数据，咱们会进行优化敞开剖析和存储。
同时，咱们还会进行类型剖析和数据冷热剖析。对于常常应用和查问的数据，咱们会将其存储在性能较高的存储介质中。而对于很少应用和查问的数据，咱们会将其存储在老本较低、查问效率绝对较低的存储介质中。这样既不就义用户体验，又可能极致地压缩存储老本。
技术要点 2：Trace 存储冷热拆散
在存储方面，咱们还进行了冷热数据的拆散。对于三天内的链路数据，即时效性要求十分高的数据，咱们将其存储在高速的 SSD 存储介质中，并通过 ILM 策略主动将旧的数据同步到老本较低的 HDD 中。这些冷数据的查问可能会稍慢一些，但大多数状况下并不需要查问三天前或一周前的数据，因为这些问题通常曾经及时解决和剖析了。通过这种数据分析和存储形式的优化，咱们胜利升高了存储老本约 99%，链路调用详情的 P99 响应工夫基本上可能放弃在 100 毫秒左右的程度。
存储是一个重要的钻研畛域，大家都在致力寻找低成本、高效和高性能的存储解决方案，来取代以前的老存储计划（例如 ES）。然而，自研存储对人才密度有较高的要求。只管挚文团体的业务规模比拟宏大，但咱们没有足够的人力来反对自研存储的工作。因而，咱们更偏向于应用基于开源计划来降低成本。我置信这条路对大多数公司来说可能更适宜。
2.3 Metrics 指标监控
在 Metrics 监控方面，咱们采纳了分布式实时计算架构，并将其分为数据上报、数据计算和数据存储几个模块。通过 Agent 和 SDK 上报的形式，将数据发送到数据中心，而后通过流式计算进行分钟级和秒级的计算，及时发送监控告警告诉。
在存储方面，咱们将报警、采集策略存储在 Mongo 中，而监控时序数据则存储在 Clickhouse 中。这样的架构具备许多长处。首先，可能反对大规模指标的的数据监控——咱们仅 Metrics 指标的类型就有上万种，并且咱们的数据量十分宏大。其次，大量数据可能进行秒级、分钟级的实时计算，并且集群具备高可用、高扩展性。反对的报警策略也非常灵便。这样的架构可能满足咱们对数据实时计算和及时告警推送的需要，而不依赖对海量数据的实时查问，确保用户可能获取精确的监控数据，并及时收回告警信息。
技术要点 1：为什么不选 Prometheus
大规模、高可用、高扩大，以上提到的架构劣势是咱们通过比照行业中一些常见架构得出的论断，比方 Prometheus 和 Grafana。上面我将分享一下为什么咱们没有抉择 Prometheus。
首先，Prometheus 采集端的保护老本高。Prometheus 采纳拉取式架构，须要保护大量的指标端点，并且须要更新这些指标端点的配置信息，不论是手动配置还是应用服务发现，都减少了保护的复杂性和老本。
其次，Prometheus 有本人的数据存储引擎，然而在解决数据节点故障方面，Prometheus 的体现不佳。一旦节点产生故障，数据可能会失落，这是咱们无奈承受的，当然 Prometheus 也能应用第三方存储引擎，比方 VictoriaMetrics，但部署比较复杂，咱们在落地过程遇到问题也不少，基础设施应谋求稳固，简略高效。
第三，Prometheus 的存储引擎绝对于其余计划耗费更多的存储资源，监控的时序数据特色比拟显著，比方有肯定的周期性和重复性等。依据数据特色咱们能通过适合的压缩算法，如 Differential Compression、LZ4 等，实现比拟高的数据压缩比。
第四，Prometheus 的报警策略反对绝对不够灵便，其次告警依赖 PromQL 对海量数据的实时查问，对数据库造成的压力十分大。报警策略的剖析推送量十分大，然而在 Prometheus 架构中，每个告警都须要通过 PromQL 对数据进行查问，这给存储带来了微小的压力，PromQL 对简单策略查问（如组合策略、稳定策略）反对难度也比拟大。
最初，Prometheus 对于一些分布式计划的反对成果也不够现实，高可用集群计划保护简单，HA 模式不能保障 Server 之间的数据一致性问题和数据失落问题，横向程度扩大须要借助联邦集群模式。然而事实场景中也没有美中不足的计划，咱们须要依据本人的数据特色、策略特色，选取适宜的技术计划，就地取材，丰俭由人。
技术要点 2：数据上报
在数据上报方面，黄色局部示意须要业务方手动埋点的内容，例如会员增长趋势和业务经营数据。而绿色局部则能够通过框架主动采集、主动上报和聚合剖析。
咱们进行的剖析包含利用根底监控、根底组件监控以及主机监控等等，例如网络、磁盘和 CPU 等根底监控数据。总体而言，咱们的采集维度比拟全面，覆盖范围宽泛。能用工具解决的上工具，能自动化的不手动，咱们宁愿根底平台多走 99 步，也要让业务用户少走 1 步。
技术要点 3：告警 & 智能剖析
技术要点 4：TSDB 存储引擎
在存储引擎方面，咱们也是一直的演进，不懈的谋求老本和效率，从之前的 OpenTSDB，到当初的 Clickhouse 引擎。
在存储方面，如之前所提到的，整个行业都在关注进步查问性能和升高存储老本。当然，Clickhouse 可能并不是最佳抉择，将来可能会呈现其余新的存储介质和架构。不论是软件还是硬件，都会朝着更好的方向倒退，因而咱们须要一直优化，并呐喊大家关注这个方向。
至于 Clickhouse 的劣势，在咱们替换了之前的 TSDB 存储引擎后，查问性能失去了显著晋升。以前的 P99 均匀查问工夫约为 900 毫秒，经常出现 10s 以上的超时，当初曾经升高到 100 毫秒。同时，存储老本也升高了约 4 倍。降级后，咱们还能反对更长时间范畴的查问（最长一年的单次查问），提供更好的用户体验和老本效益。
2.4 Profile 利用性能继续剖析
Trace 更多的是解决的是服务之间的调度问题，然而对于服务外部的简单问题，比方继续的 CPU 占用、不合理的内存申请等，这些工具很难深刻利用外部进行定位。因而，咱们须要一些轻量级的工具来解决这些问题，并将相干工具进行产品化和平台化，让用户可能在平台上进行这一系列简单操作，并取得残缺的数据。
产品化的指标是确保用户不会错过任何事故现场。当利用呈现问题时，咱们心愿可能直观地查看利用过程外部的堆栈数据和信息。咱们不心愿用户错过现场，同时也不心愿采集到一些低价值的数据。因而，咱们制订了一些策略，如在异样产生时触发告警或定时采集数据，以获取一些有价值的时序数据。
时序数据有什么作用呢？在行业中，有一个差分图的概念。咱们须要理解一个办法在过来和当初的性能是否产生了变动，CPU 工夫片的占用状况是否产生了变动，以及一些趋势如何。这些信息可能帮忙咱们找到问题所在，例如某个办法的同比环比增高，就须要关注是否存在透露等更深层次的起因。这样的剖析可能揭示咱们并解决潜在的危险，防止故障的产生。
2.5 基于数据协同的故障自动化检测剖析
当可观测数据达到肯定规模和覆盖度之后，咱们开始思考能不能将所有的数据进行协同剖析，做到线上异样智能检测，并进一步对问题根因进行智能剖析。追踪 AMP 零碎、Logs、Metrics 数据中的异样值，联合黄金指标的异样稳定，基于以上海量的监控数据获取更多的谬误上下文，帮忙用户更快定位问题，以及疾速发现线上潜在问题和危险，咱们目前能做到线上的大规模变更的智能检测异样，并给出明确的谬误起因。
咱们的愿景是能做到无人值守、故障根因主动剖析，然而路漫漫其修远兮，咱们离这个指标还有间隔，国内外商业化产品能做到的也寥寥无几，落地成果也是千人千面，咱们也在一直的尝试和演进，联合本人的数据特色，真正做到解决故障根因定位的最初一公里。
三、落地成绩和业务价值
3.1 故障定位速度晋升 85%，90% 问题定位率
通过构建一个一站式的可观测平台，咱们以数据和流程的形式提炼出了最佳的故障定位门路，不再依赖教训。问题定位的工夫从之前的 20 分钟缩短到了大概 3 分钟。通过这种平台闭环的最佳实际，咱们曾经实现了 90% 左右的问题在平台上失去定位。咱们心愿可能通过其余路径和补充伎俩将残余的 10% 也能找回来。
3.2 升高应用门槛，只需 2 步即可操作
为了升高应用门槛，咱们采纳了行业标准的解决方案，重视产品的易用性，升高用户了解老本，并与现有基础设施充沛符合。这意味着应用咱们的平台无需繁琐的培训和解说，新人入职后也可能疾速上手。
3.3 升高业务接入老本，晋升接入效率超过 60%
为了推广平台，咱们十分关注业务团队的需要，业务团队最关注的无外乎三点，1. 产品的价值；2. 稳定性；3. 接入老本。通过工具化的批量接入和监控能力下沉，主动感知生产的变更异样，咱们目前能够实现对业务的无感知接入，业务无需投入任何人力老本，以前须要 4 个季度能力实现的工作，当初可能只须要 1.5 个季度就能实现，大大降低了组件推广老本。
3.4 业务性能损耗较低，大部分在 5% 以内
目前在稳定性方面，咱们可能保障约 80% 的服务的 CPU 占用率在 5% 左右，整体内存增长也较少，整个推广过程 0 故障，0 线上应急解决。
通过对各个业务线的满意度调研、主观数据和主观数据的验证，可观测平台的价值和稳定性失去了业务方的宽泛认可。
四、总结瞻望
稳定性是咱们的根本盘，而咱们的团队指标是反对公司业务在 5 分钟内发现问题、10 分钟内做出响应、15 分钟内实现复原。尽管这个指标看似直观，从整个故障的生命周期来看，须要大量的工程平台来撑持，波及不同企业环境，不同工种，笼罩软件的全生命周期，研运一体，数字化协同。
Jeff Bezos 曾说过，空有美妙的愿景没有用，你须要良好的机制来实现它，从治理的角度来看，流程不能齐全依赖人，必须通过一套无效的机制和工具来帮忙团队做好兜底工作，机制永远比人牢靠。作为根底平台这样的职能部门，咱们也须要有全局的视角，从问题登程，从业务登程，继续扫视团队的价值和指标，并制订明确的布局和门路来实现这些指标。（全文完）
！！重要告诉！！
TakinTalks 社区第二本印刷物《SRE 可靠性体系建设实战笔记》已正式启动，现公开征集共创作者，一起布道 SRE！
招募对象：运维负责人、SRE 负责人、架构师等稳定性相干职位，团队负责人 / 总监级以上
第一期参考：10 万字干货：《数字业务连续性晋升最佳实际》收费支付|TakinTalks 社区
若您无意成为本书作者之一，请您与咱们分割，获取本书目录。
增加助理小姐姐，凭截图收费支付以上所有材料
并收费退出「TakinTalks 读者交换群」
申明：本文由公众号「TakinTalks 稳定性社区」联结社区专家独特原创撰写，如需转载，请后盾回复“转载”取得受权。
本文由博客一文多发平台 OpenWrite 公布！
