Spotify 的设计主管从15岁辍学开始做各种 side project，几十年的经验让他认为，成功的 side project 必须是“傻傻的”，这样探索的时候就不会有包袱而更大胆更有乐趣。所有的大事一开始都是小事，谷歌 50% 的新项目诞生于著名的 20% 的业余项目。规模化、融资、竞品分析各种繁杂的问题会拖累你的进度。做事情比学习重要，因为别人不会比你更聪明，别人的经历你很难感同身受。很多成功的创业不是计划出来的。项目会吸引志同道合的人。

Side project 还有一个心里上的好处就是“很爽”，你是你的老板，你决定做什么都可以，没有人能够阻止你 ：）

1. 同理心 / 视角转换是最重要的。

   1. 意识到代码首先是为人类阅读而编写的，然后才是为机器执行。
   2. 软件是如此“柔软”，有很多方法可以实现同一目标。关键在于做出适当的权衡，以满足需求。
   3. 发明与简化：Apple Pay RFID 与 微信扫码二维码。

2. 选择可持续的架构，以减少每个功能的人力资源成本。

3. 采用模式和最佳实践。

4. 避免反模式

   • 缺少错误处理
   • 回调地狱 = 意大利面条代码 + 不可预测的错误处理
   • 过长的继承链
   • 循环依赖
   • 过于复杂的代码
     • 嵌套的三元操作
     • 注释掉未使用的代码
   • 缺少国际化，特别是 RTL 问题
   • 不要重复自己
     • 简单的复制粘贴
     • 不合理的注释

5. 有效的重构

   • 语义版本
   • 永远不要对非主要版本引入破坏性更改
     • 两腿变更

指标让含糊的点子变成好点子​

• 大致估算即可
• 专注于如何评估一个伟大的产品
• 注意，不要担心总的市场大小
  • 单纯问“最终会很大吗？”就足够了

关于产品，我们该衡量什么？​

• 用户是否得到了价值？
  • 活跃用户
  • 利润
  • 交易量
  • 留存

留存很重要​

下图显示的是每年的时间群组下在一段时间之后的留存率

如果群组留存率一直在跌没有下限的话，你的增长就好像田里的火环一样没法持续燃烧，因为

• 老用户都会被烧光
• 新用户会越来越少

你应该保持留存率处在某条线之上

相反，如果群组留存率随着时间增加了，那说明你的产品很牛逼。举个例子：

1. Whatsapp
2. Uber
3. Facebook

Tom Tunguz: 留存高意味着高估值

增长​

如果你要求很高，想要达到指数级的增长，那么，评估你每周的增长率。努力让这个每周的增长率平平的，你就会拥有指数级的增长。

迭代速度​

• 越小的公司迭代速度越有优势
• 衡量指标是指导迭代方向的关键
• 衡量迭代本身的速度

你应该多么重视衡量指标呢？​

1. 不够重视
   • 容易糊弄自己和鬼打墙
2. 非常重视
   • 你的决策会是审慎的
3. 过于重视
   • 你增加了数值，但没有增加价值

现实会是痛苦的​

• 衡量指标会打破幻觉，有时候会有点痛
• 大多数的领导靠幻觉吸引下属
• 你应该
  • 学习过去
  • 厘清现在
  • 笑对未来

Paul Graham 和 Robert Morris 在 30 岁左右做的第一个 startup，把艺术展放到网上最后被证明是个烂主意，更何况 20 多岁的年轻人。

为啥聪明人会有烂的商业主意？

1. 烂主意是直觉的产物。
   1. 人们往往看到什么就想到要干什么；而事实上，如果要干什么事情干几年的话，你最好事先掂量一下几个不同的想法。
   2. 而最悲剧的是接下来的宜家效应：尽管这是个烂主意，因为你在上面付出了心力，你会喜欢上这个主意。
   3. 怎么办？快速上手做是好事，但一定要认识到==花时间不一定会让情况变得更好。反复问自己：会有人愿意为它付钱吗？==
2. 烂主意只图牛逼不图挣钱
   1. 要挣钱就别怕脏：越是脏活累活，越少人愿意干，供求关系就越紧张，你来做，你得到的议价权就越高。
   2. 因为挣钱很难，所以你的第一目标最好是要挣钱，否则你就挣不了钱。
3. 烂主意屈服于对竞争的胆怯
   1. 竞争可能不像媒体描述的那么激烈，他们又不懂技术又不会写代码。
   2. 为什么我们会害怕？懂编程不懂商业？其实上无所谓“商业”这个词，这个词太大太抽象，以至于屏蔽了下面实实在在的问题：卖产品、搞促销、搞清楚客户想要什么、定价、客户支持、付账单等等。搞定了这些细节问题，就搞定了“商业”。
4. 烂主意太浅薄
   1. 大多数的想法是博客、日历、约会网站、社交网络的杂交。而远处有更好的、未解的难题，需求旺盛，却没有人去解决。
   2. 为什么人们难以研究客户到底想要什么？现有的教育体制教导人们如何解决问题，却无法教人们如何问问题。

搞清楚用户想要什么，这件事情里面，最难的是，你要意识到你需要花时间精力去做这件事情。如果你不知道如何开始下手？答案在卡内基的那本经典的《如何贏取友谊与影响他人》里面 —— 答案是换位思考，也就是同理心。

好在用户调研这能力是可以习得的，“聪明的创客”与“用户调研”简直就是天作之合，可以爆发出无尽的力量。

千言万语一句话：创造人民群众喜(le)闻(yu)乐(tao)见(qian)的产品和服务。

为什么要记账？​

每个人都有关于如何管理资金的建议。在谷歌搜索“管理资金”，你会找到超过 1,690,000,000 个链接。你会发现大量的生活黑客或自助文章和书籍。你会找到专业教练或收费的课程。你会找到金融和投资服务。随意尝试你感兴趣的内容，通过试错来增加你的资产。

我认为最重要的是要记住，问钱的问题源于恐惧和自我怀疑。我们都害怕变化。我们都怀疑自己能否赚更多的钱。

与其花时间担心和怀疑，不如专注于相反的事情——你的信心。如果你在玩扑克，筹码很少，你只能小额下注，赢得少量资金。当你有很多筹码时，你可以大额下注并赢得大奖。你有更多的空间去冒险。你可以尝试那些在筹码较少时无法尝试的事情。

这里的魔力在于——通过更多地了解你的财务状况，你获得了信心！拥有更多的信心，我们可以做出更好的判断，并愿意下注最佳金额以获得更大的成功，从而赢得更多。

了解你的支出并规划下一次消费

赢得更多的担忧的尽头在哪里？人们常常谈论财务自由这个流行词。然而，空谈无益，而记账恰恰回答了这个问题。

四个主要财务报表概述财务状况​

不幸的是，在我们现代生活中，记账并不容易。我们正处于一个丰盈的新纪元。我们有很多账户——现金、银行账户、支付应用、信用卡、股票或加密货币经纪账户、折扣卡……我们拥有房屋、汽车、黄金、珠宝等资产……更糟糕的是，我们中的一些人可能生活在不同的国家，必须处理不同的货币。我们如何绘制出准确的财务生活地图，并在未来的不确定性中导航？

我所说的“准确的财务生活地图”是指这四个主要财务报表：

1. 损益表：它显示我们在特定期间内赚取了多少收入。这个报表通常被认为是财务报表中最重要的，因为它反映了经营结果。
2. 资产负债表：它回答我们拥有多少资产、负债和权益。这个报表是第二重要的，因为它报告了我们资产的流动性和资本化情况。
3. 现金流量表：它报告我们的现金流入和流出，并回答我们是否产生了现金。我们需要足够的现金来支付费用和购买资产。
4. 权益表：这对你的个人会计没有帮助。然而，对于公司而言，这个报表报告它如何在利益相关者之间分配权益。

使用 beancount.io，你可以快速生成上述报表。但是等等……如何为这些报表准备数据？

双重记账确保准确性​

为了确保准确性并将错误检测内化到系统中，双重记账要求每个账户的每个条目至少有一个对应的条目到另一个账户。一笔交易涉及至少两个账户和两个操作——借记（+）和贷记（-）。

1970-01-01 open Income:BeancountCorp
1970-01-01 open Assets:Cash
1970-01-01 open Expenses:Food
1970-01-01 open Assets:Receivables:Alice
1970-01-01 open Assets:Receivables:Bob
1970-01-01 open Assets:Receivables:Charlie
1970-01-01 open Liabilities:CreditCard

2019-05-31 * "BeancountCorp" "5月15日至5月31日的工资"
  Income:BeancountCorp               -888 USD
  Assets:Cash                         888 USD

2019-07-12 * "Popeyes 鸡肉三明治" "与 Alice、Bob 和 Charlie 的晚餐"
  Expenses:Food 20 USD
  Assets:Receivables:Alice 20 USD
  Assets:Receivables:Bob 20 USD
  Assets:Receivables:Charlie 20 USD
  Liabilities:CreditCard -80 USD

如上面的两个例子所示，每笔交易必须满足会计等式。

资产 = 负债 + 权益（即净资产）

我们使用了 Martin Blais 的 Beancount 语法和 Jakob Schnitzer 的网络项目 Fava 来构建这个网站。如果任何交易的各方不相加为零，它将提醒你。

现在你明白我们如何强制确保账本的正确性。但是你可能会问，那些“账户”是什么？

账户作为水的桶​

将你的资产视为水在不同的桶中流入和流出，而“账户”就是那些装着你资金的桶。通过双重记账，资金如何在不同账户之间流动变得显而易见，就像水在不同桶之间流动一样。

Beancount.io 介绍了五种类型的账户。

1. 收入——其金额总是负数或借记。这是因为你在赚钱，然后资金从“收入”账户借记到你的“资产”中。
2. 支出——其金额总是正数或贷记。这是因为你在花钱，资金从“资产”或“负债”流向“支出”。
3. 负债——其金额为正数或零。你的信用卡负债就是一个很好的例子，它会周期性地上升和下降。
4. 资产——其金额为正数或零。你的现金或房屋总是有一定的价值。
5. 权益——你的净资产。系统会自动为你计算。权益 = 资产 - 负债，它反映了你的财富状况。

现在你可以使用上述关键词打开自定义账户：

1970-01-01 open Assets:Cash
1970-01-01 open Assets:Stock:Robinhood
1970-01-01 open Assets:Crypto:Coinbase
1970-01-01 open Expenses:Transportation:Taxi
1970-01-01 open Equity:OpeningBalance

商品：跟踪你的投资​

是的，你可以使用 beancount.io 跟踪你的投资。例如，我们在 2014 年以每个 100 美元的价格购买了 10 个比特币：

2014-08-08 * "购买 10 个比特币"
  Assets:Trade:Cash -1000.00 USD
  Assets:Trade:Positions  10 BTC {100.00 USD}

然后三年后，你以每个 10,000 美元 的价格出售它们（原始成本为每个 100 美元，标注为 {100.00 USD}）。

2017-12-12 * "出售 2 个比特币"
  Assets:Trade:Positions                   -2 BTC {100.00 USD} @ 10,000.00 USD
  Assets:Trade:Cash                          20,000.00 USD
  Income:Trade:PnL                          -19,800.00 USD

或者同样的交易用 @@ 20,000.00 USD 表示总价为 20,000 美元。

2017-12-12 * "出售 2 个比特币"
  Assets:Trade:Positions                   -2 BTC {100.00 USD} @@ 20,000.00 USD
  Assets:Trade:Cash                          20,000.00 USD
  Income:Trade:PnL                          -19,800.00 USD

交易的所有各方的总和，包括 -2 BTC {100.00 USD}，仍然如往常一样为零。

成本 {100.00 USD} 标签很重要，因为你可能以不同的成本购买了相同的商品。

100 BTC {10.00 USD, 2012-08-08}
10 BTC {100.00 USD, 2014-08-08}

如果你想简化这个过程，可以在开始时设置账户为 FIFO 或 LIFO。FIFO 代表先进先出，而 LIFO 代表后进先出。在美国，国税局使用 FIFO 来计算你的盈亏和税收。

1970-01-01 open Assets:Trade:Positions "FIFO"

然后当你以简写方式出售时，如 -2 BTC {}，beancount 将自动应用 FIFO 策略，出售最旧的商品。

Beancount.io​

Beancount.io 是一个云服务，用于在文本文件中记录你的财务交易，将其可视化为财务报表（损益表、资产负债表、试算表等），并帮助你过上更好的财务生活。 立即注册 - 目前处于促销期且免费！

技术

• 技术的引力方向是平均水平：随着技术的通胀，优秀的技术会趋向于平庸，平庸的公司会采纳优秀的技术。
• 市场的引力方向是马太效应：有市场的市场会更大，没市场的市场会更小。

需求​

日志与度量：日志是发生的事件，而度量是对系统健康状况的测量。

我们假设该系统的目的是提供度量——即计数器、转化率、计时器等，用于监控系统性能和健康。如果转化率大幅下降，系统应警告值班人员。

1. 监控商业指标，如注册漏斗的转化率
2. 支持各种查询，如在不同平台上（IE/Chrome/Safari，iOS/Android/桌面等）
3. 数据可视化
4. 可扩展性和可用性

架构​

构建系统的两种方式：

1. 推送模型：Influx/Telegraf/Grafana
2. 拉取模型：Prometheus/Grafana

拉取模型更具可扩展性，因为它减少了进入度量数据库的请求数量——没有热路径和并发问题。

服务器农场

特性与组件​

测量注册漏斗​

以移动应用的四步注册为例

输入手机号码 -> 验证短信代码 -> 输入姓名 -> 输入密码

每一步都有 IMPRESSION 和 POST_VERIFICATION 阶段。并发出如下度量：

{
  "sign_up_session_id": "uuid",
  "step": "VERIFY_SMS_CODE",
  "os": "iOS",
  "phase": "POST_VERIFICATION",
  "status": "SUCCESS",
  // ... ts, contexts, ...
}

因此，我们可以查询 iOS 上 VERIFY_SMS_CODE 步骤的整体转化率，如下所示：

(counts of step=VERIFY_SMS_CODE, os=iOS, status: SUCCESS, phase: POST_VERIFICATION) / (counts of step=VERIFY_SMS_CODE, os=iOS, phase: IMPRESSION)

数据可视化​

Grafana 在数据可视化工作中已经相当成熟。如果您不想暴露整个网站，可以使用 嵌入面板与 iframe。

澄清需求​

设计一个类似于 Square Cash（以下称为 Cash App）或 PayPal 的转账后端系统，以实现：

1. 从银行存款和支付
2. 账户之间转账
3. 高扩展性和可用性
4. 国际化：语言、时区、货币兑换
5. 非幂等 API 和至少一次交付的去重
6. 跨多个数据源的一致性

架构​

AWS CloudHSM

功能和组件​

支付服务​

支付数据模型本质上是“复式记账”。每个账户的每一笔入账都需要在另一个账户中有相应的对立入账。所有借方和贷方的总和等于零。

存款和支付​

交易：新用户 Jane Doe 从银行向 Cash App 存入 100 美元。这一笔交易涉及以下数据库条目：

记账表（用于历史记录）

+ 借方, 美元, 100, CashAppAccountNumber, txId
- 贷方, 美元, 100, RoutingNumber:AccountNumber, txId

交易表

txId, 时间戳, 状态（待处理/已确认）, [记账条目], 叙述

一旦银行确认交易，更新上述待处理状态和以下资产负债表，均在一笔交易中完成。

资产负债表

CashAppAccountNumber, 美元, 100

在 Cash App 内部账户之间转账​

与上述情况类似，但没有待处理状态，因为我们不需要慢速外部系统来更改其状态。所有记账表、交易表和资产负债表的更改都在一笔交易中完成。

国际化​

我们在三个维度上解决国际化问题。

1. 语言：所有文本，如文案、推送通知、电子邮件，均根据 accept-language 头部进行选择。
2. 时区：所有服务器时区均为 UTC。我们在客户端将时间戳转换为本地时区。
3. 货币：所有用户转账交易必须使用相同货币。如果他们想要跨货币转移，必须先以对 Cash App 有利的汇率兑换货币。

例如，Jane Doe 想以 0.2 的汇率将 1 美元兑换为 6.8 人民币。

记账表

- 贷方, 美元, 1, CashAppAccountNumber, txId
+ 借方, 人民币, 6.8, CashAppAccountNumber, txId, @7.55 人民币/美元
+ 借方, 美元, 0.1, ExpensesOfExchangeAccountNumber, txId

交易表、资产负债表等与存款和支付中讨论的交易类似。主要区别在于银行或供应商提供兑换服务。

如何在交易表和外部银行及供应商之间同步？​

• 使用幂等性重试以提高外部调用的成功率并确保没有重复订单。
• 检查待处理订单是否已完成或失败的两种方法。
  1. 轮询：定时作业（SWF、Airflow、Cadence 等）轮询待处理订单的状态。
  2. 回调：为外部供应商提供回调 API。
• 优雅关闭。银行网关调用可能需要数十秒才能完成，重启服务器可能会从数据库恢复未完成的交易。该过程可能会创建过多连接。为减少连接，在关闭之前停止接受新请求，并等待现有的外发请求完成。

去重​

为什么去重是一个问题？

1. 不是所有端点都是幂等的
2. 事件队列可能是至少一次的。

不是所有端点都是幂等的：如果外部系统不是幂等的怎么办？​

对于上述 轮询 情况，如果外部网关不支持幂等 API，为了不淹没重复条目，我们必须记录外部系统给我们的订单 ID 或参考 ID，并通过订单 ID 查询 GET，而不是一直使用 POST。

对于 回调 情况，我们可以确保实现幂等 API，并且无论如何我们将 待处理 更改为 已确认。

事件队列可能是至少一次的​

• 对于事件队列，我们可以使用一个完全一次的 Kafka，生产者吞吐量仅下降 3%。
• 在数据库层，我们可以使用 幂等性密钥或去重密钥。
• 在服务层，我们可以使用 Redis 键值存储。

可用性和扩展性​

• 整体故障转移策略：通过故障转移提高可用性：冷备份、热备份、温备份、主动-主动。
• 服务层扩展：AKF 扩展立方体
• 数据层扩展：CQRS 模式
• 需要速度层吗？Lambda 架构

1. 澄清需求​

1. 一旦支付成功，webhook 将回调商家。
   1. 商家开发者向我们注册 webhook 信息。
   2. 可靠且安全地向 webhook 发起 POST HTTP 请求。
2. 高可用性、错误处理和故障恢复。
   1. 异步设计。假设商家的服务器分布在全球，可能会有高达 15 秒的延迟。
   2. 至少一次交付。幂等密钥。
   3. 顺序无关。
   4. 强大且可预测的重试和短路机制。
3. 安全性、可观察性和可扩展性。
   1. 防伪造。
   2. 当商家的接收器出现故障时通知商家。
   3. 易于扩展和规模化。

2. 概述高层设计​

异步设计 + 重试 + 排队 + 可观察性 + 安全性

3. 功能和组件​

核心功能​

1. 用户访问仪表板前端向我们注册 webhook 信息 - 例如要调用的 URL、他们希望订阅的事件范围，然后从我们这里获取 API 密钥。
2. 当有新事件时，将其发布到队列中，然后被调用者消费。调用者获取注册信息并向外部服务发起 HTTP 调用。

webhook 调用者​

1. 订阅由支付状态机或其他服务发布的支付成功事件队列。

2. 一旦调用者接受事件，从用户设置服务获取 webhook URI、密钥和设置。根据这些设置准备请求。为了安全...

• 所有来自用户设置的 webhook 必须使用 HTTPS。

• 如果负载很大，预期延迟很高，并且我们希望确保目标接收器是活跃的，我们可以通过携带挑战的 ping 验证其存在。例如，Dropbox 通过发送带有“challenge”参数（一个随机字符串）的 GET 请求来验证 webhook 端点，您的端点需要将其回显作为响应。

• 所有回调请求都带有头部 x-webhook-signature。这样接收者可以验证请求。

  • 对于对称签名，我们可以使用 HMAC/SHA256 签名。其值为 HMAC(webhook secret, raw request payload); Telegram 使用此方法。
  • 对于非对称签名，我们可以使用 RSA/SHA256 签名。其值为 RSA(webhook private key, raw request payload); Stripe 使用此方法。
  • 如果是敏感信息，我们还可以考虑对负载进行加密，而不仅仅是签名。

3. 向外部商家的端点发起带有事件负载和安全头的 HTTP POST 请求。

API 定义​

// POST https://example.com/webhook/
{
  "id": 1,
  "scheduled_for": "2017-01-31T20:50:02Z",
  "event": {
    "id": "24934862-d980-46cb-9402-43c81b0cdba6",
    "resource": "event",
    "type": "charge:created",
    "api_version": "2018-03-22",
    "created_at": "2017-01-31T20:49:02Z",
    "data": {
      "code": "66BEOV2A", // 或用户需要履行的订单 ID
      "name": "主权个体",
      "description": "掌握信息时代的过渡",
      "hosted_url": "https://commerce.coinbase.com/charges/66BEOV2A",
      "created_at": "2017-01-31T20:49:02Z",
      "expires_at": "2017-01-31T21:49:02Z",
      "metadata": {},
      "pricing_type": "CNY",
      "payments": [
        // ...
      ],
      "addresses": {
        // ...
      }
    }
  }
}

商家服务器应以 200 HTTP 状态码响应以确认收到 webhook。

错误处理​

如果没有收到确认，我们将使用幂等性密钥和指数退避重试，最长可达三天。最大重试间隔为 1 小时。 如果达到某个限制，则短路/标记为损坏。向商家发送电子邮件。

指标​

Webhook 调用者服务将状态发射到时序数据库以获取指标。

使用 Statsd + Influx DB 还是 Prometheus？

• InfluxDB：应用程序将数据推送到 InfluxDB。它有一个用于指标和索引的单体数据库。
• Prometheus：Prometheus 服务器定期从运行的应用程序中拉取指标值。它使用 LevelDB 进行索引，但每个指标存储在自己的文件中。

或者如果您有宽裕的预算，可以使用昂贵的 DataDog 或其他 APM 服务。

• 在西方世界，除了公众演讲，最大的社交恐惧是与陌生人开始对话。为了克服被拒绝的恐惧，意识到在大多数情况下，当你努力与他们交谈时，人们会对此表示赞赏，这很有帮助。
• 在某些情况下，不说话可能会让你显得傲慢或冷漠。开始对话可以很简单：首先，对某人微笑；其次，建立眼神接触；第三，主动自我介绍。
• 接近一群人：1，远处表现出你对这个小组的兴趣，注意发言者。2，群体会注意到并为你腾出空间。3，在你表达任何强烈观点之前，让小组对你有好感。
• 引导对话会唤起积极的情感，使人们愿意与你合作或社交。承担这一责任的一个简单方法是表现得像一个主人，问：“你叫什么名字？”强调“你”，让他们感到被重视。
• 改善对话的最佳方法是提出开放式问题，这表明你真心关心他们想说的话。
• 对话不可避免地会有尴尬的沉默。你可以通过询问与当前情境相关的开放式问题或使用FORM首字母缩略词（家庭、职业、休闲和其他）来恢复舒适的交流。
• 成为一个积极的倾听者，肢体语言很重要：避免交叉双臂、耸肩或摆弄衣物、头发或珠宝。相反，向前倾身、点头、微笑并保持眼神接触。
• 成为一个积极的倾听者，语音提示也很重要：通过询问关于细节的后续问题来参与，热情回应以表达你的兴趣，或对发言者所说的内容进行释义以澄清。
• 优雅地结束对话的第一件事是回到你讨论的重点。如果你真心想在稍后继续讨论，交换联系方式，说明你接下来要做什么（如果是熟人）握手并道别。
• 重要的是要遵循你所说的接下来要做的事情。否则，另一方可能会认为你根本不享受与他们的相处，这会伤害他们的感情。
• 以介绍你的对话伙伴给新朋友的方式结束对话是一种礼貌的方式，这将扩大他的社交网络，并确保他不会觉得你在抛弃他。或者反过来，你可以请他们介绍你给其他人。