知鸦日报2021-09-03

线上工具对于阿姨这个群体是比较陌生的，因此为了确保我们的产品能真正被阿姨接受并熟悉，我们进行了用户体验调查，在调研中，阿姨们体现出比我们预想还要严重的使用障碍，因此我们从解决障碍出发，启动了这次改版。

大部分企业都在强调传播渠道上的创新和新的营销技术，比如是用视频号还是直播，是用今日头条还是腾讯新闻；用哪种营销云工具，社群以及裂变等。

但内容本身是否有效，是否产生有影响力并不重视，却对对内容营销产生的商机抱着高度的期望。

之前我写过《如何打造B2B营销的“内容力”》，这次我想从规划阶段开始，探讨哪些内容可写，谁来写，如何写得好，又如何让好内容传播。

在今天这个数字化时代，围绕“客户”来进行增长的公司越来越多，腾讯、小米、字节跳动，它们业务的增长线都建立在客户之上，而不是简单的新产品或新业务的叠加。

缺乏客户的支撑，增长的业务设计就会从规划变成“鬼话”，无法落地，这是大多数公司在执行战略规划时所碰到的窘境。

客户结构，包括客户的交易动因是什么（客户需求）、合理的客户构成层级是什么（客户组合）以及依据客户还可以做哪些增长衍生（客户资源）。

增长应该回归到客户，这才是评判企业是否有价值的本源。拉姆·查兰认为基于客户所实现的增长可称为“良性增长”。

线框图不是“画”出来的，而是想出来的，是确认出来的。

线框图，只是提供了一个供讨论、供评审、供确认的承载物，然后并将确认后的需求（商业需求以及设计需求），以具象的方式再传递出去。

所以，线框图本身看起来美观不美观，专业不专业，画得好不好，都不是重要的问题。

一个画在白板上的简陋的线框图，和一个无比精美专业的线框图，是很难说哪个更“好”的。

说这个，是提醒我们自己，不要忽视线框图的本质问题。所以大多关于线框图怎么画的问题，可能不是出在不知道怎么画，而是不知道为何要画，具体画什么，画了怎么用的问题。

我们上次和大家分享了 这是一篇普通的《LOGO提案教程》（上） 主要从提案的方式、LOGO展示、创意说明三个方向帮助大家更好理解提案流程，今天我们推出（教程下部）希望对你有所帮助。

我们提案的目的是什么？为什么不能直接把做好的LOGO怼给客户呢？

压测是目前科技企业及传统企业进行系统容量评估、容量规划的最佳实践方式，本文将基于京东ForceBot平台在大促(京东618、京东双11)备战中的实践历程，给大家分享平台在压测方面的技术变革。ForceBot平台是一款分布式性能测试平台，能够为全链路压测构造千万量级的压测流量，并结合全域流量录制回放、瞬时发压、智能寻点等能力，为整站容量评估与规划提供一站式的解决方案。

本文将详细讲解爱奇艺TV后台分布式实时本地Cache实践方案，给大家解决高并发问题提供一个参考。

本文将介绍爱奇艺移动端后台如何通过灰度环境优化解决以上的问题。

随着数字技术的发展，我们的生活越来越离不开音频，对音频使用和呈现方式也越来越多样化，人们也从去单纯的听录制好的音频转向录制属于自己的音频，例如录歌、会议录音、录制短视频等。我们这些音频是高质量，清晰可听的，而这依赖于设备的性能。因此，对于一个音频设备，其音频质量的好坏成为衡量该设备性能的一个重要指标。然而，在现实生活中，录制的音频中不仅会有设备本身的电流噪声，还会夹杂着周围环境中的噪声。而环境噪声并不与设备性能直接相关，一旦所录制的音频中有环境噪声的干扰就会使得音频质量变差，使得我们不能正确的对该音频设备的性能进行评估。所以，如何有效的消除环境噪声是一个值得被关注的问题。环境中噪声往往是复杂多变难以处理的，利用传统降噪方法也很难取得理想的效果。为了解决这一问题，本文将介绍一种基于模型来自动消除音频中的环境噪声的方法。该方法不仅可以用于提高音频质量检测的准确性，还适用于各种需要提高音频质量的场景中。

在我之前的一篇文章里，初步介绍了 Jamstack 这套建站技术栈的背景以及各方面优劣势： https://zhuanlan.zhihu.com/p/281085404 所以这次这篇文章会更加深入，聊聊这套技术栈的演进以及业界的一些最佳实践。

Myntra has datacenter in region A . For diaster recovery (DR), Myntra got another datacenter in the region B. So region B became our DR region for region A.

If things go offtrack, it can lead to the unavailability of one whole region. So having at least two data centres in two different regions for business continuity makes sense.

We were using region A datacenter for serving production traffic. Region B datacenter was used for realtime state replication of databases and also to keep backup of databases.

So if region A is unavailable due to disaster, we can use backup state from region A to restore state in region B and provision stateless services in region B and then enable the production traffic in region B.

For diaster recovery, we need to do Business Impact Analysis of all the tech systems and need to arrive at the acceptable RTO and RPO thresholds.

RTO- Recovery Time Objective- Acceptable time duration threshold to restore the business function after the diaster event

RPO- Recovery Point Objective- Acceptable threshold for how back you will go back in time before diaster to restore data in usable format.

Uber’s GSS (Global Scaled Solutions) team runs scaled programs for diverse products and businesses, including but not limited to Eats, Rides, and Freight. The team transforms Uber’s ideas into agile, global solutions by designing and implementing scalable solutions. One of the areas of expertise within GSS is the Digitization vertical. The Digitization team efficiently converts physical signals into digital assets and provides services in labeling, in-field testing, data curation and validations for maps, product incubation, freight BOL (bill of lading), Eats menu uploads, etc.

All these digitization services are performed by thousands of humans (operators) working on our internal applications across many locations around the globe. While an operator is digitizing data, our backend collects a clickstream of all the user interactions in the form of raw events to the scale of 10 million events per day in AWS (Amazon Web Services) cloud infrastructure. Sometimes this data is also moved to Uber’s own data centers. Our data analytics team performs analysis on this data to improve/tweak the process, augment tooling infrastructure, address operator motivation, and improve operator skills. Analytics is usually performed by querying big data lakes and using different frontend tools for visualisation. Generally, any analytics setup has a latency (source to user) component to it and the latency of our existing (pre-COVID) infrastructure was 1 hour. With the onset of COVID-19 crisis, the digitization process had to be transitioned to work-from-home mode, leading to additional operational complexity of remotely managing a huge workforce of operators. This complexity created a gap in team’s communication, decision making, and collaboration. Where 1-hour latency of our analytics platform was previously acceptable, real-time analytics was needed to fill this gap. This blog describes how we improved latency of our data architecture by building a real-time analytics system.

While we researched approaches used for building real-time dashboards (example), we did not find an end-to-end solution, considering how rich visualization can be achieved at lower cost. We considered different visualization approaches and also looked at commercial solutions to come up with our choices. Another differentiating aspect was that our solution also addresses the need for a “single source of truth” on Amazon S3 (Amazon’s “simple storage service”), from which both streaming and batch processed dashboards would to be sourced, rather than hooking directly into the Amazon Kinesis Data Firehose stream itself. This intermediate storage lets us recover data (for the streaming window) with a replay. We production tested our visualizations with thousands of users for low load times and reliability.

订单系统存在于各行各业，如电商订单、银行流水、运营商话费账单等，是一个非常广泛、通用的系统。对于这类系统，在过去十几年发展中已经形成了经典的做法。但是随着互联网的发展，以及各企业对数据的重视，需要存储和持久化的订单量越来越大，数据的重视程度与数据规模的膨胀带来了新的挑战。首先，订单量对于数据的存储、持久化、访问带来了挑战，这不仅增加了开发面对的困难，也为系统的运维带来了挑战。其次，随着大数据技术的发展以及运营水平的不断提高，订单数据的后续数据分析工作，如流批处理、ETL，也越来越重要，这也对数据的存储系统提出了更高的要求。

本文提出了一种基于MySQL + Tablestore 的大规模订单系统设计方案。这种方案基于分层存储的思想，使用 Tablestore 辅助 MySQL 共同完成订单系统支持。在系统中，利用 MySQL 的事务能力来处理对事务强需求的写操作与部分读操作；利用 Tablestore 的检索能力、大数据存储能力等弥补 MySQL 在功能上的短板。

自动化测试是提升测试效率的有效手段，但是实践过程中，常常听到一些测试同学抱怨说自动化测试并没有发挥应有的价值，有时候甚至沦为绩效考核的工具。比如：

1. 编写了大量的自动化测试用例，却只有少量的可以正常运行；
2. 每天都会定时执行自动化测试的回归任务，却很少发现Bug；
3. 有时候自动化测试的考核指标成为测试人员的负担；
4. 开发了自动化测试平台，用户使用的频率并不太高；

之所以会出现以上情况，是因为我们并没有进行有效的自动化测试。那什么是有效的自动化测试呢？我们应该从哪些维度来衡量自动化测试的有效性呢？

支付有多种渠道，在不同的宿主环境下，可能都不一样，比如APP内的支付、微信内支付、小程序支付、浏览器内h5支付等等。这篇文章主要理清常见场景下各个支付的流程和api，后续一旦有新业务接入支付，能起到一个引导作用，少走弯路。

随着 Nodejs 对大前端技术栈的渗透，开发场景越来越多，同时和微服务外部系统交互多。面对这些复杂的场景，我们需要全局视角的错误追踪、问题定位和性能诊断。

本文以一个 MyBatis 完整示例为切入点，结合 MyBatis 底层源码分析，图文并茂的讲解 MyBatis 的核心工作机制。

本文对于基本的配置概念（如 entry 、 output 等）就不一一赘述了，着重介绍的是 splitChunks 和 manifest 两部分内容。

我们在做数据库性能压力测试、做监控和告警项，或者想要真实地了解业务数据库负载的时候，常常需要使用两个数字化的衡量指标。他们是什么？相信很多数据库从业的读者已经呼之欲出了，那就是 QPS 和 TPS。

我们经常使用到这两个指标，那我们是否清楚他们是什么，在 MySQL 中应该如何计算获得呢？

从网卡到应用程序，数据包会经过一系列组件，其中驱动做了什么？内核做了什么？为了优化，我们又能做些什么？整个过程中涉及到诸多细微可调的软硬件参数，并且相互影响，不存在一劳永逸的“银弹”。本文中又拍云系统开发高级工程师杨鹏将结合自己的的实践经验，介绍在深入理解底层机制的基础上如何做出“场景化”的最优配置。

通过对线上iOS符号解析服务的持续探索和优化，最终完整落地了一套将平均单行解析效率提升70倍的技术方案。

本文主要介绍了百度持续交付流水线集团级方案。持续交付涵盖内容广泛，本文并不讨论广义的持续交付，而是聚焦在承载持续交付部分功能的流水线的上面的构建活动。围绕流水线构建，我们介绍了一站式流水线开放平台-百度双引擎构建生态、流水线效能提升利器-智能构建中台。

随着携程海外酒店业务的发展，遍布全球的海外供应商与携程总部IDC之间的数据传输量快速增长。技术上，这种日益增长的数据量对跨境网络专线的带宽、延迟等提出了更高的要求；业务上，由于当前有限的跨境网络专线资源对业务处理效率及用户体验也造成了一定的影响；成本上，跨境网络专线作为一种昂贵的资源，通过单纯的专线扩容又会给IT成本造成巨大压力。所以我们开始思考是否可以通过公有云结合酒店直连的业务特性来解决日益增长的带宽压力和供应商接口延迟的问题。

酒店直连系统主要是使用自动化接口实现供应商或集团与携程之间的系统对接，实现静态信息、动态信息、订单功能等都通过系统的方式流转交互。目前携程大量海外酒店业务是通过酒店直连系统对接。

本文将主要从携程酒店直连服务迁移部署至AWS过程中所进行的应用架构调整及云原生改造，使用AWS后取得的技术和业务收益，在部署过程中对EKS（Amazon Elastic Kubernates Service）、DNS查询延时和跨AZ流量降低所做的成本优化等几方面进行详细介绍。