在2010年，Google发表了一篇非常重要的论文：Google-Wide Profiling: A Continuous Profiling Infrastructure for Data Centers[1]，提出了一种持续性能剖析的基础设施， 能够针对大规模的服务、集群进行海量的数据采集、分析。这种新的性能剖析手段能够提供精确可靠的性能分析结果，同时又能保持较低的性能开销。 自此以后就涌现出大量商业或者开源的持续性能剖析实现，比较典型的有Google Cloud profiler[2], Pyroscope[3]等。目前，性能剖析已然成为可观测性的又一大支柱。
去哪儿发布的数据显示，在过去一年中，其发布故障率始终保持在4‰ 以下并不断降低。作为一家出行旅游服务平台，去哪儿网如何在复杂的业务场景下，仍能保持如此低的故障率？其中功能测试左移功不可没。 本文介绍了去哪儿网通过自动化测试、智能推荐、本地化等平台的建设，在低成本、低故障率、高效率方面的显著成效，并详细介绍了各阶段的实践重难点。
在哔哩哔哩海外市场，视频上传是创作者最重要的功能之一，也是创作者对平台忠诚度和满意度的重要影响因素之一。然而，2022年Q3，产品负责人在海外对创作者进行线下访谈的过程中，发现超过50%的创作者对上传体验不满意，主要反馈有两个方面：上传速度慢、上传进度长时间卡住。这些问题严重影响了创作者的上传效率和体验，甚至导致了部分创作者放弃上传或者转投其他平台。 为了优化上传体验，提升视频上传成功率，我们于2022年Q4季度针对海外创作端上传链路进行了专项治理。但在实施之前，我们分析了面临的几方面问题和挑战： 缺少技术数据来分析具体问题，导致我们无法准确定位问题点和优化方向 东南亚相对于国内较弱的网络环境和机型环境，导致了上传链路上存在很多不稳定因素 如何在有限的人力资源下，平衡业务需求和技术需求，让产出最大化。 为了解决这些问题和挑战，我们从数据、产品、技术三个维度组织了一系列的工作
随着互联网技术以及网络基建的快速发展和普及，视频直播已经成为了一种越来越普遍的娱乐和社交方式。无论是个人还是企业，都可以通过视频直播平台进行直播活动，向观众展示自己的生活、工作或者产品。同时，视频直播也成为了一种新型的社交媒体，让人们可以在虚拟空间中进行互动交流。 RTM（Real Time Media，低延时直播）是近期逐步兴起的一种以提升客户交互体验为目标的直播解决方案，它的特点是较传统的直播解决方案，端到端延时更小达到 1 秒级别，卡顿无明显负向，RTM 的网络传输层是基于 WebRTC 技术的（RTP/RTCP 协议）。 RTM 推流相比于传统的 RTMP 推流，在网络变化响应灵敏度、弱网对抗、带宽利用率等方面都有明显优势。在抖音的 AB 实验中主播人均被看播时长/被关注/被评论显著正向，拉流音频/视频卡顿 -22.2%/-7.8%，端到端延迟 -1.6%。目前 RTM 推流在抖音秀场完成了 10% 左右的常规放量。
数据平台利用大数据智能分析、数据可视化等技术，对公司内外部经过采集、建设、管理、分析的多源异构数据进行呈现和应用，实现了数据共享、日常报表自动生成、快速和智能分析，深度挖掘数据价值，满足企业各级部门之间的数据分析应用需求。因而也具有数据量大，场景多，数据准确性要求高，查询性能要有保障等特点。
挂一部分机器，不会丢数据、不会不可服务，是对现代数据库的一个比较基本的要求。 对于早期的单机数据库，一般使用主备架构。主备架构有很多的缺陷，并且这些缺陷是无解的。穿过主备架构里各种“优化”的名词，最后也无非是选择一碗毒药而已，这几个毒药包括： 1.脑裂，两个节点同时写入的冲突数据无法合并，只能丢掉一部分。想要不脑裂？那只能牺牲可用性。 2.同步复制，备机不可用的情况下，算不算写入成功？算，可能丢数据；不算，备机不可用==集群不可用，牺牲可用性。 3.异步复制，这完全躺平了，不考虑一致性。 4.所谓semi-sync等方案，也属于主备架构的一种。 5.业务自己去容错，做针对自己业务场景的对账、补偿等方案。 其实可以看出，主备架构是CAP理论做取舍的重灾区，一致性和可用性之间的关系特别矛盾。所谓一致性和可用性“兼顾”的主备方案，实际上是“兼不顾”。
在内网上有太多的架构相关的文章了(比如大名鼎鼎的自顶向下)，我之前也写过应用架构设计的经验。但是总有种雾里看花的感觉，好像有很多相关的知识，soa、分布式事务、DDD、复杂系统重构、领域建模、业务架构、等等等，这些复杂的名词和知识感觉学了一堆仍然不得其法。 所以我准备把我这些年在支付宝做架构，自己摸索成长的内容写下来，看能否帮助到大家。
我们都知道DevOps诞生于互联网企业。Netflix、AWS等互联网企业号称每天往生产环境部署成百上千次。如此之快的部署频率让众多传统企业也跃跃欲试。所以大量的传统企业都纷纷投入巨资打造自己的DevOps基础设施 ，希望就此可以显著提高开发效率，加快新项目或新产品的投产速度。但是，他们对于DevOps基础架构是什么样子，需要具备哪些能力，如何构建，并没有一个很清晰的规划。 要想规划与打造适合传统企业的DevOps基础设施，首先需要弄清楚它必须具备哪些能力。我们尝试从基础、开发、测试、运维、项目管理五个维度来分析对DevOps的需求，从而探索DevOps基础设施与之对应的能力，并映射到一款业界流行的软件工具来承载这个能力。需要注意的是这里的目的是具象与实例化，而不是推荐使用某款软件工具。大家要根据自身实际来进行工具选型。
随着人工智能领域的迅速发展，Prompt Engineering 已成为一门备受关注的新兴技术。Prompt 是指用于引导机器学习模型生成符合预期输出的文本或代码片段。编写高效的 Prompt 对于提高模型效果至关重要。本文将探讨如何高效编写 Prompt。 一个高效的 Prompt 应由 Instruction 和 Question 两部分组成。在使用 openAPI 调用时，通常将 Instruction 通过 system 传递，将 Question 通过 user 传递。而在使用 Web 界面时，可以简单地拼接这两部分。本文的演示将以 Web 界面为主。
