知乎是中文互联网高质量的问答社区，每天有上千万用户在知乎分享知识、经验和见解，找到自己的答案。文章介绍了Rancher在管理大规模集群时遇到的性能问题，特别是超级管理员用户登录时的数据加载量较大，导致UI不可用且下游集群频繁断连。通过与Rancher团队的沟通，发现问题的根本原因是集群节点总量较大。

知乎商业广告审核平台采用机器审核和人工审核相结合的方式，解决方案包括接入市面上的审核系统、使用知乎社区的天玑系统进行风控和内容审核，以及各业务线的定制化审核系统。为了提高效率，选择延后接入优先级较低的业务系统，并解决广告审核部门的痛点需求。同时，需要选择开源系统或自研系统，严格遵循项目管理过程。广告审核平台的本质是业务层、审核层和广告展示层的结合。

时间轮是一种用于高效调度任务的调度模型，通常由哈希表和链表实现。它适用于延迟任务和周期性任务，如延时任务和定时任务。相比传统的队列形式的调度器，时间轮能够批量高效地管理各种任务。定时器是调度模型的实例化，包含启动定时器、加入调度任务、终止定时器、终止调度任务、周期清算和过期处理等接口。无序列表定时器是由链表实现的，任务以将要过期的剩余时间无序存储。

商业移动端系统面临架构演进、开屏重构、错误编程、大前端玩转Grafana等挑战。技术实现边界不清晰、侵入性强、缺乏系统思考和规划会导致质量失控。商广客户端系统需要与其他业务线配合，但独立性较弱。旧技术架构存在组件耦合和依赖混乱的问题，需进行架构演进以满足商业系统定位和开发规范。商业系统面临的痛点包括需求开发周期长、产品方案受限、问题排查困难。解决这些问题需要明确商业系统的本质和定位，前瞻商业系统的最佳形态，以及商业协作的最佳实践。优秀的研发人员需要具备广阔的视野。

开屏广告是商业客户端维护的重要模块，但目前存在质量和性能问题。重构目标是管理复杂度，建设独立商业能力，提供可插拔式UI插件库设计。重构的收益包括独立运行的开屏服务、调试速度提升、代码体积缩小、开屏逻辑统一、开发周期缩短、故障率减少、开屏展示率提升等。现有开屏架构无法满足复杂场景和收入增长，重构需关注可读性、可维护性和可复用性。

稳定性测试是一项关键的测试内容，可以减少软件上线后的崩溃和性能问题。在一个视频业务版本升级后出现Crash问题，导致大量崩溃。问题的原因是缺乏前置拦截测试手段。为了解决这个问题，我们的目标是降低社区客户端的Crash量并提高版本灰度阶段的稳定性问题闭环率。我们调研了Google Monkey和Maxim自动遍历工具，最终选择了Maxim来进行自动遍历测试。Maxim是基于Monkey二次开发的工具，速度快且提供多种遍历算法和定制化功能。然而，它只能测试Android系统，不能跨平台。如果只需要测试Android系统，Maxim是一个优秀的选择。

知乎引入Flink作为实时计算引擎，构建了实时计算平台Skytree。平台支持业务的日志落地、实时数仓、广告实时特征等需求。为推广平台，引入了Flink SQL并上线了Mipha。Mipha基于Flink SQL Gateway构建，引入了Mipha MetaStore作为统一的元数据管理组件。初版平台部署在Kubernetes上，支持Flink Jar任务、监控和报警机制。然而，平台存在管理问题，如任务源代码丢失。因此，决定通过重新设计整个平台，面向SQL，推出实时计算平台2.0 Mipha。

动态化技术体系是一种跨端动态模板引擎技术方案，通过跨平台动态化SDK和多个辅助工具实现研发提效。该方案包括智能化设计平台、跨端模板动态化方案、可视化搭建平台和辅助调试工具。通过这套技术体系，开发者可以高效地完成组件的设计、开发和调试工作。动态化的基础能力包括动态化中间层、SDK能力层和模板管理提供的通用能力。该技术方案在业务使用层面还在不断探索和挖掘中。

这篇文章主要介绍了知乎团队在工程能力方面的进展和措施。他们将研发交付过程分为准入、过程和准出三个阶段，并在每个阶段建立了相应的质量保障能力。通过设立准入标准、过程质量和准出质量指标以及线上质量预警，他们成功降低了MR数和线上质量故障。这些举措帮助提升了工程能力，提高了产品质量和研发效率。

埋点是一种方法，用于在应用中收集信息以跟踪应用使用情况。它可以通过优化产品或运营来提供数据支持。埋点测试分为需求新增和P0回归测试。需求新增测试需要确保字段准确、时机准确和次数准确。P0回归测试是为了确保重要埋点的准确性，对业务决策有重要影响。然而，人工测试存在耗时、精度不足和人员替换困难等问题。埋点自动化测试平台可以解决这些问题。它提供UI驱动和测试框架，并支持结果校验、存储和通知。投入产出方面，43个P0埋点接入自动化后，每周可节约2小时回归人力，已实现26小时收益。在接入过程中，发现了12个平台问题，为平台的稳定性和多样化做出了贡献。接入方案包括前期的可行性分析和场景统计，中期的用例完善和任务完成，后期的用例维护和文档沉淀。在接入细节方面，需要配置Android和iOS端的本地环境。

知乎使用Kafka进行消息通知、日志传输和离线数据处理。面临的挑战是提升稳定性和可维护性，以及增加业务研发效率。文章介绍了采用k8s部署Kafka的关键技术，包括固定brok等。

HDFS Federation架构解决了NameNode元信息存储的问题，但单机房容量成为瓶颈。知乎采用Router Base Federation方案，并迁移了子集群到其他机房。为了避免跨机房流量，设计了HDFS多机房方案。该方案使用pipeline方式写入3个副本，但如果副本所在的DataNode节点或客户端不在同一机房，就会产生跨机房流量。副本转移工具Balancer和Mover也可能产生跨机房流量。副本恢复时，集群会在DataNode间拷贝数据以恢复丢失副本。

本文介绍了一个质量保障体系，其中包括线下问题的拦截和线上问题的召回。监控是线上问题召回的核心手段。文章列举了建立核心业务数据监控体系、保障异常弹框和界面展示的质量稳定性以及建立数据监控指标设置流程规范等目标。同时，文章提出了监控指标的确定，包括业务指标、可用性指标和性能指标。这些指标包括响应时间、流量、成功/失败率等。另外，文章还介绍了错误码的统计以及系统层监控的重要性，系统层监控主要关注软件系统硬件设备的相关指标。为了实现项目目标，跨团队合作和任务执行效果也被强调。

大数据运维目前分为购买商业产品、维护历史遗留的Ambari、使用运维框架开发运维平台三个方向。工程化阶段的目标是快速兼容、历史接管、工程化和降低运维心智。大数据运维架构需要具备架构独立、部署友好的能力。运维工具对比中，选择了学习成本低且具备快速运维优势的Ansible进行大数据自动化运维管理。Ansible是一种用Python编写的开源自动化工具，具有强大的扩展性和可定制性，提供了主机清单、模块和角色等功能。

知乎业务发展迅速，需要建立完整的服务端监控体系来保障业务稳定运行。监控指标分为业务层、应用层和系统层。业务层监控包括综合数据监控、业务数据监控、接口监控和关键节点监控。应用层监控包括日志监控、三方依赖监控和中间层监控。主要目标是提升线上问题的感知能力，缩短问题发现周期。其中，三方依赖监控关注请求量、响应时间和成功率；日志监控用于反映服务运行状态，关注日志总量和错误日志占比；中间层监控需要根据不同中间层软件监控指标进行监测。

知乎采用多云架构，通过在线机房和离线机房的专线连接来实现算法模型的跨机房读取。早期，为解决专线带宽打满的问题，知乎部署了一套新的在线HDFS集群供算法业务使用。该架构解决了专线流量问题，但引入了维护困难和拷贝脚本实现的问题。将模型从离线HDFS集群拷贝至在线集群的过程需要业务自己实现，增加了运维负担。