微信实验平台主要提供微信内部各个业务场景（视频号、直播、搜一搜、公众号等）下的各类实验场景的支持，有 AB 实验、MAB 实验、BO 实验、Interleaving 实验、客户端实验、社交网络实验、双边实验等。
建设低代码平台的目的，就是通过可视化的方式，加上可复用的建设能力，用较少的投入、以较快的速度来交付应用程序。 我们通过aPaaS架构思路，复用已经实现了的开发能力，解构业务模型，形成更通用的能力，对业务进行快速编排。实现低代码，甚至部分无代码的快速定制应用。将开发模式从做加法，改进为做乘法，48小时内快速定制大部分基础应用。 我们不单需要解决今天的可见需求，同时还需要解决明天潜在的问题。实现更少的投入，更聪明的办法，建设更好的产品，产生更大的价值。
算法模型的研发具有很强的范式，首先是特征数据加工，选取一些数据作为特征。拿到特征之后，选择一个模型并进行相关的训练。第三步是把训练好的模型部署到模型平台上面。最后，决策平台会做业务流程的编排。 如图是整个平台的产品架构图。上面是各类应用场景，包括智能调度、营销&增长、司乘匹配、基础算法等。平台接入层提供内部SOA协议的接入，上面有各种各样的服务，会对接我们的平台。我们的平台分为离/近线系统和近/在线系统，其中离/近线系统包括特征平台和训练平台，近/在线系统包括模型平台和决策平台。
本文整理自灵雀云的专家工程师刘梦馨，在《蓝鲸 X DeepFlow 可观测性 Meetup》 中的分享实录，从一个毫无头绪的 K8s DNS 故障出发，分享问题的排查思路，详解排查过程中遇到的 DNS 服务、Alpine 镜像、业务代码逻辑、CNI 插件等各个层面的异常现象。整个排查过程基于 DeepFlow 的持续观测能力，实现了对故障现场的高清还原。刘老师同时也从资深用户的角度，对 DeepFlow Dashboard 提出了宝贵的易用性改善建议。
相比用户停留时间短、用完即走的 Web 页面，桌面 QQ 用户在一次登录后，可能会挂机一周以上，这段期间，如果没有严格控制好 QQ 内存占用，那么结果可能是用户交互响应变慢、甚至 Crash。在系统监控工具里，高内存占用也会被直观地反映出来，带来不好的口碑。MAC QQ 灰度期间，也听到了一些用户关于内存占用偏高的声音。即然不能置若罔闻，那么必须得痛下决心系统地来一波内存占用分析与优化。在这个过程中，团队前前后后挖出来了不少优化项，最终，可以让桌面 QQ 在内存占用上达到一个相对较低且稳定的状态。本文内容是探索桌面 QQ 内存优化上的一个阶段性小结，肯定还有更多内存优化 trick，欢迎各位多多提意见。
本文将从“样本处理”，“模型开发”，“实验管理”，“工具链及可视化“ 几个角度介绍基于 tranformers 库做的重新设计，并简单聊聊个人对“软件2.0”的看法。
随着得物业务规模的不断增加，推荐业务也越来越复杂，对推荐系统也提出了更高的要求。我们于2022年下半年启动了DGraph的研发，DGraph是一个C++项目，目标是打造一个高效易用的推荐引擎。推荐场景的特点是表多、数据更新频繁、单次查询会涉及多张表。了解这些特点，对于推荐引擎的设计非常重要。通过阅读本文，希望能对大家了解推荐引擎有一定帮助。为什么叫DGraph？因为推荐场景主要是用x2i(KVV)表推荐为主，而x2i数据是图(Graph)的边，所以我们给得物的推荐引擎取名DGraph。
