IT瘾管理推荐

agentic coding 本质上是文档管理的艺术

Tue, 23 Dec 2025 09:59:55 CST

今天回东京后继续研究 agentic coding，由于本地项目是从 0 搭建的，需求和文档随着和 codex 和 cc 的沟通越来越明确，文档的复杂程度也逐渐加深。

这让我越来越觉得 agentic coding 本质上是文档管理的艺术，从 vibe coding 发展了一年后，自然语言编程似乎慢慢将软件工程转换为了文档工程。

最初，需求极其模糊。llm 会按照自己的想法为我们想做的事情设定一个 roadmap 和 mvp 版本，这是从零开始的第一步，它决定了迭代的大版本号。我一般会让 llm 在本地生成两个文件，第一个毫无疑问是 agent constitution，第二个是 http://roadmap.md 这是非常重要的文件，所有的需求，都会从这个文件的迭代 session 中派生出来，顺序是 roadmap:v0.1 -> stories/xxx.md 这里的 story 其实就是需求白板中的任务，它可能涉及到 API 或者 UI，包含几个甚至十几个复杂的任务，每一个 story 文件，都会是一个单独的文件，涵盖着某个可被测试的需求完整的结构，任务完成情况和相关联的文件路径。

stories 文件夹中每完成一个需求，我会要求 codex / cc 在 docs 对应的路径创建一系列 md 文档，以标记一个功能所涉及到的状态，如果这个功能产生了 bug，就在修复 bug 的过程中继续在这个文档中记录 bug 修复进度，于此同时，也要求它按照文档结构来组织 lib 或 api router 文件。以此类推，文档系统会形成一个巨大的网状结构，最终，它会成为整个产品的故事和描述文件。

传统的软件工程里，这个是产品经理干的活儿。但对于自然语言编程来说，这个任务变成了工程师的责任。一开始，我还设计了一个 architecture 文档，以要求 cc 用对应的技术栈来完成功能，后来，我发现随着软件的生长，强行要求一个万能的程序员按照人类的技术栈来实现功能并没有什么意义（维护已存在的项目除外）所以我废弃了这个文件，只维护产品故事和需求描述。

在整个 agentic coding 的过程中，我基本上只和文档打交道，在另外一个浏览器界面等待完成的需求被刷新，没关心过代码重构和其他技术问题，这让编程（如果还能这样定义它的话）成为了一种极其容易进入心流的对话情境，以我个人的体验来说，这是一件非常好的事儿。如果你没体验过 agentic coding，我推荐大家尝试一下！

互联网公司的管理神话破灭

Sun, 04 Feb 2024 17:21:45 CST

价值观，OKR，花名，弹性工作制等……

在过去的 20 年里，互联网行业为企业管理界贡献了许多花活儿，这其中有些是中国互联网原创的，也有不少是从硅谷学习而来属于全球互联网行业通行。

当互联网行业处于黄金上升期的时候，几乎每家成功的互联网企业都要或多或少的对外输出一下自己的企业管理方法论，有的是通过创始人演讲，有的是通过出书，也有类似腾讯和阿里巴巴这样的，直接以被投企业家俱乐部的形式来影响自己投资的创业企业。

然而，随着互联网黄金增长期的结束，全球互联网普及红利（对国内来说是人口红利）的消失，我们惊讶发现从 2020 年开始，许多过去互联网行业高举高打的管理概念正在失效……或者说，它也许从来就没有有效过。

站在这个时间点去回顾互联网公司曾经沉淀下的那些方法论，我们会发现无论是阿里巴巴、腾讯、字节跳动，还是 Google、Amazon 和 Netflix。他们的企业管理方法论可能都存在错误归因——低估自己所乘着的时代东风，高估了自身的努力（管理行为）。

因为在企业管理界，有一些明显的错误答案，剩下的全都是“正确答案”。

这是我看最近一本书《大厂人才》的感受，这本书由穆胜咨询合伙人娄珺（Samantha）出品。书中详细横向评测了字节跳动、腾讯、阿里巴巴、美团、华为等多个大厂的管理体系，并间或的对这些不同模式与传统企业管理制度做了比较。

原书作者在结论上总结的比较委婉，但我结合自身的大厂工作经历以及对本书阅读的感受，可以直说：所有互联网大厂的管理创新，可能都是画蛇添足。

以全书反思性最为明显的 OKR 为例，OKR 的“始作俑者”Google 在 2022 年启用了新的管理工具 GRAD（Googler Reviews and Devlopment, 谷歌员工评价和发展），GRAD 是一种更为绩效（偏向 KPI）而非目标导向的管理工具。

根据书中的描述，Google 使用 GRAD 取代 OKR 的主要原因可能有两个，第一个是在过去很长一段时间里，由于 OKR 的反 KPI 属性，导致日常业务中大量的经常性工作无法被考核，OKR 只能作为该公司更大的管理机制 Preformance Management 一环使用，并且只能覆盖 40% 的工作。第二个，则是 OKR 复杂的流程和评价机制本身让员工不堪重负，在许多时候，反复的对齐、拉通、复盘比简单的定期考核一个业务指标是否达成更让人痛苦。

OKR 在国内的忠实粉丝字节跳动也在 2023 年调整了它们的考核方式与考核节奏，比如从双月回顾改为季度回顾。

在 OKR 以外，一些曾经在发展早期宣誓要“去 KPI 化”的企业也在最近重新回到 KPI 考核的道路，比如百度和小米。

阿里巴巴的花名机制，也在实践中与原本的设立初衷背道而驰——原本是为了淡化职级加强扁平化管理，结果真的搞成了“江湖味儿”，公司内“门派林立”。腾讯的“赛马机制”和“自下而上”也一度使得公司缺乏 Big Picture，漏球了信息流和短视频这两个非常重要的业务。

从社会学的角度讲，现代企业的本质是个体分工协作的产物。它的作用是将一群人以特定的社会关系结合在一起，实现一个人无法实现的伟业。这意味着巴别塔可以有很多种建成方式，只要没有上帝来捣乱，任何一种方式都可以通天，而“上帝来捣乱”的方法，就是让每个人都觉得自己的方法是对的。

从 2023 年全球互联网行业的大裁员和惨状来看，互联网的企业管理方法论创新，别说可能不适用于其他企业，甚至可能连互联网行业自己都不合适。比如，早期的字节跳动被称为“App 工厂”，上一个火一个。从字节跳动在 2017 年全面启用飞书之后，就再也没有上线过任何一个现象级产品。腾讯方法论无法让腾讯复制微信，字节方法论也无法让字节复制抖音。

这意味着无论是飞书提出的“先进团队先用飞书”还是阿里的“每年将会向社会输出 1000 名在阿里工作 10 年以上的人才”，对于社会上的其他企业来说都是一个陷阱。

如果你相信这些从互联网公司来的工具、人才、方法论能够帮助你原本陷入困境的企业重振旗鼓，那你就要倒大霉咯。

这个观点倒不是书中提出的，而是我之前从字节的方法论观察到的。众所周知，虽然字节其实并不怎么输出企业管理方法论（比起阿里巴巴），但飞书却从诞生之出将“方法论”与产品捆绑进行销售。飞书在所有的媒体和互联网公司都备受好评，甚至连百度和阿里的一些团队也私下使用飞书进行一些边缘项目的协作，确实配得上“先进团队先用飞书”。

但是，这个世界本身就是由落后构成的。

我第一次认识到这一点，是我在一次参会成员年龄稍大的会议上，用飞书分享我自己的稿子（就是那个几万字的稿子）。我讲到一半，一个听众问我：你讲到第几页了？

我愣了，我讲到第几页了？飞书没有页数啊，因为飞书就没想过会有人把电子文档打印出来看。

提问者 50 多岁，以我和大多数互联网员工的视角看确实算是“岁数大了”。但他实际上也是从 90 年代开始用电脑的“弄潮儿”，你怎么都不能说人家“数字素养”不行？类似的情况其实还有几乎所有的在线文档都不支持“尾注”这个在学术写作中非常重要的功能（其实还有“修订模式”），以至于金山文档至今可以拿到腾讯文档和飞书文档都拿不到的市场份额。

是因为各种眼花缭乱的在线文档不够“先进”吗？不，是因为太过先进了，与落后的现实世界并不匹配。

除非你假定一个 35 岁全员退休的社会，否则向落后兼容，就是一个先进管理工具与生产力工具的最重要基础要素。

这个事情在 SaaS 市场其实被反复验证，所有人都说中国的 SaaS 市场不好做，然后找了许多许多理由。但时至 2024 年，就没有几家企业开门做公司敢不买 Microsoft Office，连免费的 WPS 都是因为和 Microsoft Office 做的“一模一样”，才能抢到这部分市场。以至于我之前和@ 汐笺聊 SaaS 的时候说：

你如果做了一个办公三件套，觉得自己很创新，和 Office 长得不像。那一定是你做错了，因为微软办公套件里的每个按钮都有一个你们整个团队那么多的产品和研发，还对应了 0.x%～x% 的市场份额。

你日常可以用飞书，用 notion，用 Obsidian，甚至你在小团队里也可以用这些新工具来协作。然而，一旦你要进入到更大规模的社会协作，你就离不开 Microsoft Office。字节跳动的 GR 和政府打交道也丢飞书链接吗？阿里巴巴和腾讯合作签合同难道用钉钉文档做前期互审吗？不可能的。

不仅在工具层面如此，在管理工具层面也是如此，OKR 是一个所谓“面向创新”的管理工具。但即便是在人类密集创新的最近半个世纪里，创新也并非企业的常态。创新带来的是新增长点，但这个点一旦被创出来了，后面的增长工作无一例外是由海量的人与资金在枯燥的日常工作中驱动的。

这两年其实也刚好有一个对比，一方面是由于裁员数量增大，职场社交软件脉脉上关于“空降阿里员工”的吐槽多了起来。大致的故事模版就是中小厂，来了一个阿里高 P，进来就搞一通管理+工具的改革，风风火火干三个月，轻则业务下降，重则公司倒闭。

另一方面，马斯克在 2022 年末收购推特，主打一个干翻所有管理理念，什么必要岗位，先裁掉一半员工再说。什么切换服务器要半年，我亲自坐私人飞机给你网线拔了——结果是 X 的主要业务数据并没有下滑，甚至在 AI 新业务上的进展也优于 Google。

书中也特意配了一个维度来证明这一点，这是我非常佩服作者的。她竟然能想到用几大公司离职员工的创业成功率来恒量一个企业的管理制度是否有效，而数据是这样的：

公司名称	离职员工创办公司数量	上市公司数量	IPO上岸率
华为	481	25	5.2%
美团	115	3	2.6%
腾讯	720	18	2.5%
阿里巴巴	941	16	1.7%
字节跳动	21	0	0%

数据来源：穆圣咨询、IT桔子

这个维度并不严谨，因为这个数字本身就会有漏算，而且创业成功也并非 IPO 一个衡量指标。但是我们会非常明显的看到对自己价值观与方法论自视甚高的阿里巴巴在这个比较中是非常落下风的。

在这本书中，华为是作为“传统企业”被拉进来与互联网公司做对比的，因此在横评中的每一项，华为几乎都有优势，不免让人觉得这是不是作者在拉偏手。但华为的成功本身由华为的管理方法论决定的吗？华为的方法论在别的企业执行的下去吗？

众所周知，华为在人才管理方面曾做出过一些超乎民企可及范围的事情。类似的情况，拼多多也在电商消费纠纷上有一些“别人做不到的能力”。所以，不管你想要在自己的企业里实施奋斗者文化，还是想要对供应商实施“仅退款”政策，还是要创始人掂量一下自己的斤两。

所以，还是回到我在本文开头提到的，企业管理界有一些明显的错误答案，剩下的全都是“正确答案”。在吸收别人的经验时，错误的总比正确的更重要。只要你的企业还没黄，就不要轻易效仿别人。

尤其是在现在这个下行周期里，企业黄了也不一定是你做的不对，试图模仿先进者只会让你黄的更快。

管理大型 Postgres 数据库的 3 个技巧

Mon, 06 Mar 2023 11:30:50 CST

在处理庞大的数据库时，请尝试这些方便的解决方案，以解决常见的问题。

关系型数据库 PostgreSQL（也被称为 Postgres）已经越来越流行，全球各地的企业和公共部门都在使用它。随着这种广泛的采用，数据库已经变得比以前更大了。在 Crunchy Data，我们经常与 20TB 以上的数据库打交道，而且我们现有的数据库还在继续增长。我的同事 David Christensen 和我收集了一些关于管理拥有巨大表的数据库的技巧。

大表

生产数据库通常由许多具有不同数据、大小和模式的表组成。常见的情况是，最终有一个巨大的、无序的数据库表，远远大于你数据库中的任何其他表。这个表经常存储活动日志或有时间戳的事件，而且对你的应用或用户来说是必要的。

真正的大表会因为很多原因造成挑战，但一个常见的原因是锁。对表的定期维护往往需要锁，但对大表的锁可能会使你的应用瘫痪，或导致堵塞和许多令人头痛的问题。我有一些做基本维护的技巧，比如添加列或索引，同时避免长期运行的锁。

添加索引的问题：在创建索引的过程中锁住表。如果你有一个庞大的表，这可能需要几个小时。

  CREATE INDEX ON customers (last_name)

方案：使用 CREATE INDEX CONCURRENTLY 功能。这种方法将索引创建分成两部分，一部分是短暂的锁定，以创建索引，立即开始跟踪变化，但尽量减少应用阻塞，然后是完全建立该索引，之后查询可以开始使用它。

  CREATE INDEX CONCURRENTLY ON customers (last_name)

添加列

在数据库的使用过程中，添加列是一个常见的请求，但是对于一个巨大的表来说，这可能是很棘手的，同样是由于锁的问题。

问题：当你添加一个新的默认值为一个函数的列时，Postgres 需要重写表。对于大表，这可能需要几个小时。

方案：将操作拆分为多条基本语句，总效果一致，但控制锁的时间。

添加列：

  ALTER TABLE all_my_exes ADD COLUMN location text

添加默认值：

  ALTER TABLE all_my_exes ALTER COLUMN location SET DEFAULT texas()

使用 UPDATE 来添加默认值：

  UPDATE all_my_exes SET location = DEFAULT

添加约束条件

问题: 你想添加一个用于数据验证的检查约束。但是如果你使用直接的方法来添加约束，它将锁定表，同时验证表中的所有现有数据。另外，如果在验证的任何时候出现错误，它将回滚。

  ALTER TABLE favorite_bands ADD CONSTRAINT name_check CHECK (name = 'Led Zeppelin')

方案：告诉 Postgres 这个约束，但不要验证它。在第二步中进行验证。这将在第一步中进行短暂的锁定，确保所有新的/修改过的行都符合约束条件，然后在另一步骤中进行验证，以确认所有现有的数据都通过约束条件。

告诉 Postgres 这个约束，但不要强制执行它：

  ALTER TABLE favorite_bands ADD CONSTRAINT name_check CHECK (name = 'Led Zeppelin') NOT VALID

然后在创建后验证它：

  ALTER TABLE favorite_bands VALIDATE CONSTRAINT name_check

想了解更多？

David Christensen 和我将在 3 月 9 号到 10 到在加州帕萨迪纳参加 SCaLE 的 Postgres Days。很多来自 Postgres 社区的优秀人士也会在那里。加入我们吧！

via: https://opensource.com/article/23/2/manage-large-postgres-databases

作者： Elizabeth Garrett Christensen 选题： lkxed 译者： geekpi 校对： wxy

本文由 LCTT 原创编译， Linux中国荣誉推出

非一线工程管理者的一对一沟通

Sun, 26 Feb 2023 00:00:00 CST

一线工程管理者主要管理/领导工程师完成实际的工程任务，而非一线的工程管理者需要领导一线管理者，更多的关注团队本身，因此两者在做一对一沟通的时候需要有不同的关注点。原文:One-on-Ones for (Engineering) Manager of Managers ^[1]

如果没有耐心看完全文，可以直接拉到底部看结论。

我之前已经写了很多关于一对一的文章，基本上覆盖了和一对一沟通有关的所有一般性话题。到目前为止，所有文章都适用于团队的(工程)管理者(manager)及其上级管理者(manager of managers)。为什么我会更多的考虑这个方向？因为(工程)管理者的上级管理者相对比较小众，没有太多关于这些角色的具体知识分享，就连有关工程管理的书籍也缺乏深刻见解。你有可能会发现自己被迫领导一个更大的组织结构，需要领导那些正在管理/领导其他人的人，然而这一角色并没有合适的名称，你可能会像我一样自然而然的成为"管理者的上级(manager of managers)"。这篇文章就是为你所准备的，你可以找到一些关于怎样成为(工程)管理者的上级管理者的具体细节。当然，如果你只是好奇，也可以阅读本文。

那么，"管理者的上级"和"团队管理者"之间的一对一沟通有什么不同呢？为了理解这一点，需要看看这两种类型的管理者/领导者的不同目标。

(工程)管理者的上级有什么不同点

在团队管理者的组织架构下，我会配置:

由个人贡献者组成的单一团队的(工程)管理者，或者
在某些情况下，当没有(工程)管理者或大部分管理职责已经委托给TL时，配置技术/团队Lead，或者
由个人贡献者组成的多个团队的(工程)管理者，其中所有的管理和领导活动都由一个(工程)管理者完成。技术Lead(如果有的话)是更资深的工程师，在团队中承担更多的技术领导职责。

另一方面，管理者的上级是需要领导其他团队管理者的人(见上文)，通常下面会有:

高级(工程)经理(Senior EM)
工程总监(DoE)
工程副总裁(VPoE)
工程/研发主管(HoE HoD)
首席技术官(CTO)

现在我们澄清了相关术语，接下来考虑它们的目的。团队管理者的目标是改善、促进、帮助、疏导所领导的人员的个人贡献。管理者的上级管理者的目标是被领导的管理者所领导的团队和组织。两者差别巨大，"增加了新的抽象层次(经理)" ^[1]。

一对一沟通是如何处理这种差异的呢？通常情况下，一对一谈话将围绕管理者所领导的组织，而不是他们的贡献(尽管这也会体现在沟通背景中)，所以你需要问这样的问题:

"团队的健康状况如何?"
"是什么阻碍了你的团队实现既定目标?"
避免提出下面的问题: "你的个人贡献任务做得怎么样?"等等。

不仅要对属下的管理者负责，还要对他们领导的所有人负责。 ^[4]

上级管理者一对一沟通的特点

担任的职位越高，要处理的人的问题就越多。所以在一对一交流中，要做好心理准备。有一个有效方法可以用来处理这些问题，从而可以分配一些时间在一对一沟通的其他方面。这个方法我听说了很多次，最近一个有人(开发主管)强调他们处理的跟人有关的问题比其他人多的例子，就是在我现在的公司。这是不单单是我的经验，似乎也是有效的事实，其他一些领导者也表达了同样的观点 ^[4]，所以你可以考虑一下:)。

当你被推到高级管理/领导角色时，会被期望自己负责定义更多愿景，而从一线管理者那里得到的反馈会更少。"没人会觉得有责任给你反馈" ^[2]，所以你需要自己确定公司的发展方向。作为一名上级管理者的关键区别是，你将在与你领导的团队以及同事进行一对一交流的过程中寻求反馈(形成愿景或方向)。我想再次提醒你，随着你的资历越来越高，在考虑如何实现目标时，需要考虑越来越多的同事的目标。

如果你还没有在不同的工程领域(如开发、测试、运营等)之间切换，或者你还没有在其他领域的多样化职责的经验(例如。当你是开发人员时，就可以进行自动化测试)，你将不具备其他人的专业知识。在这种情况下，当你要领导一个更大的组织时，可能不具备某些团队领域的专业知识，管理这些团队需要更严格的把握(对管理和进展的各个方面提出问题，即使是那些看起来进展很好的方面)。

"跟进所有小事情，直到确定哪些事情不需要跟进" ^[1]。例如:

正在进行招聘吗?
经理们在指导团队吗?
目标制定好了?
目标review过了?
项目状态是什么?
已经看过生产事故的事后分析报告了吗?

重要方面和特点

(工程)管理者的上级管理者比较小众，没有太多关于这些角色的具体知识分享。我已经介绍过适用于所有类型管理者/领导的一对一沟通，这是基础概念。

上级管理者的一对一对话将围绕所领导的组织，而不是管理者的个人贡献。"你不仅要对下属管理者负责，还要对他们领导的所有人负责。" ^[4]
上级管理者一对一沟通的特点:

在一对一对话中，需要处理更多关于人的问题，而不是其他类型的问题。
与领导的团队和同事进行一对一交流的过程中寻求反馈(形成愿景或方向)，因为下级管理者会觉得没有责任做这种反馈。
如果在某些团队的特定方面没有专业知识，管理这些团队就需要围绕管理和进展的各个方面提出问题。

总结

A. (工程)管理者的上级管理者是一个小众群体，没有太多关于这些职位的具体知识分享。

B. 你可能被迫领导一个更大的组织架构，领导那些正在管理/领导其他人的人。

C. 在团队管理者的组织架构下，我会配置:

由个人贡献者组成的单一团队的(工程)管理者，或者
在某些情况下，当没有(工程)管理者或大部分管理职责已经委托给TL时，配置技术/团队Lead，或者
由个人贡献者组成的多个团队的(工程)管理者，其中所有的管理和领导活动都由一个(工程)管理者完成。技术Lead(如果有的话)是更资深的工程师，在团队中承担更多的技术领导职责。

D. 管理者的上级是需要领导其他团队管理者的人(见上文)，通常下面会有:

高级(工程)经理(Senior EM)
工程总监(DoE)
工程副总裁(VPoE)
工程/研发主管(HoE HoD)
首席技术官(CTO)

团队管理者的目标是改善、促进、帮助、疏导所领导人员的个人贡献。
管理者的上级管理者的目标是所领导的团队和组织。
两者有巨大的差别，"增加了新的抽象层次(经理)" ^[1]。
一对一对话将围绕管理者所领导的组织，而不是他们的个人贡献。
"不仅要对你的下属管理者负责，还要对他们领导的所有人负责。" ^[4]
上级管理者一对一沟通的特点:

在一对一会面中，会处理更多关于人的问题，而不是其他类型的问题。
与领导的团队和同事进行一对一交流的过程中寻求反馈(形成愿景或方向)，因为下级管理者会觉得没有责任做这种反馈。
如果在某些团队的特定方面没有专业知识，管理这些团队就需要围绕管理和进展的各个方面提出问题。
"跟进所有小事情，直到确定哪些事情不需要跟进" ^[1]。例如:

正在进行招聘吗?
经理们在指导团队吗?
目标制定好了?
目标review过了?
项目状态是什么?
已经看过生产事故的事后分析报告了吗?

参考文献

[1] Camille Fournier, "The Manager’s path", 2017, book

[2] Will Larson, "An Elegant Puzzle: Systems of Engineering Management", 2019, book

[3] Dr. James Stanier, "Become an Effective Software Engineering Manager: How to Be the Leader Your Development Team Needs", 2020, book

[4] Marcus F., https://lnkd.in/dghjKmQB, youtube videos

你好，我是俞凡，在Motorola做过研发，现在在Mavenir做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI等技术始终保持着浓厚的兴趣，平时喜欢阅读、思考，相信持续学习、终身成长，欢迎一起交流学习。
微信公众号：DeepNoMind

参考资料

[1]

One-on-Ones for (Engineering) Manager of Managers: https://medium.com/@despot.jakimovski/one-on-ones-for-engineering-manager-of-managers-acf90dc1832f

- END -

微软的vscode 研发流程项目管理是如何做的？

Sat, 25 Feb 2023 22:25:37 CST

Project Management

Roadmap

The team has a 6-12 months high level Roadmapwhich defines high level themes and features to be addressed in this timeframe.

Iterations

We will work in monthly iterations on the items on the roadmap. Iterations are roughly month based, rather than week based. We will begin a milestone on a Monday and end on a Friday, meaning that each milestone can have a different duration, depending on how the weeks align.

At the end of each iteration, we want to have a version of Visual Studio Code that can be used by the VS Code community. The work planned during an iteration is captured in the iteration plan (see Iteration Plans). The feature highlights of each iteration are highlighted in the release notes.

Planning

Before each milestone, we will prioritize features to implement and bugs to fix in the upcoming iteration. Bugs are assigned the milestone for the iteration. For new features, we create new issues and label them with Plan Item. Plan Items include a check list for the Definition of Done. The Bugs, Plan Items, and Feature Requests assigned to a milestone encompasses the planned work for the upcoming month. For each Plan Item, we include the checklist for b

Definition of Done

Test Plan Item created
Keyboard accessible
Screen reader accessible
Works with the different themes, including the high contrast theme
Telemetry events in place
Release notes updated

Inside an Iteration

We work in weekly segments:

Week 1: Reduce debt introduced in the previous iteration, address critical issues uncovered in the previous iteration, plan the next iteration
Week 2: Work according to the plan
Week 3+: Work according to the plan
Final Week: Endgame
- the team tests the new features according to a test plan and updates the documentation.
- we make a pre-release available on the 'insiders' channel and invite users to help us test the pre-release.
Week 1 (next iteration):
- monitoring the pre-release and fixing critical issues.
- publish the release, sometime midweek, after 24 hours with no changes to the pre-release.

Triage

Bugs and features will be assigned a milestone, and within a milestone, they will be assigned a priority. The priority dictates the order in which issues should be addressed. An importantbug (something that we think is critical for the milestone) is to be addressed before the other bugs.

To find out when a bug fix will be available in an update, then please check the milestone that is assigned to the issue.

Please see Issue Trackingfor a description of the different workflows we are using.

Weekly

Each week we will manage work items, crossing off completed features, and triaging bugs. At the end of the milestone, we will strive for 0 bugs and 0 issues assigned to the milestone. Some bugs and features will then be either postponed to later milestones or moved back to the backlog.

End Game

The final week of the milestone is what we call the "end game" ( see running the endgame). During this week we will wrap up any feature work, we will test using a test plan Iteration Plans, and then we will fix the critical bugs for that milestone.

During the endgame we make a build available on the insiderschannel ( see also). We will monitor incoming issues from this release, fix any critical bugs that arise, and then produce a final stablerelease for the milestone and the stablechannel.

网易云音乐全链路埋点管理平台建设

Wed, 21 Dec 2022 17:39:42 CST

图片来源： https://unsplash.com

本文作者：ZYF

一、背景

在文章云音乐曙光埋点：还原数据理想国中，我们介绍了曙光埋点项目方案，该方案基于多端一致埋点对象树建设管理，实现了统一自动化埋点和链路追踪，方案高度还原了大前端埋点的理想状态、具备较强通用性和扩展性。我们围绕这套埋点方案研发了配套的埋点管理系统，以承载及埋点规则数据管理、埋点设计、埋点研发、埋点测试、埋点上线等功能，本文主要介绍该平台功能及建设思路。

二、平台现状介绍

经过前几期建设，我们已经实现了一个适配研发流程的、按版本来管理的埋点数据管理平台，其核心功能为：

1、承载埋点研发生命周期
2、承载埋点的元数据管理

我们的研发生命周期如下：

平台在埋点元数据管理设计如下，参考和学习了版本管理工具的功能，并且充分考虑了客户端的研发流程特点

1、客户端每个大版本需求研发时，BI对埋点需求进行分类，建立需求组。可以理解为基于Master CheckOut出了多个分支。
2、BI在各需求组内，按埋点需求设计埋点。设计完成后，平台会计算出埋点的变更列表，如新增对象、新增血缘关系、修改参数、删除对象、删除血缘关系。
3、上述变更由BI指派到任务，交由开发处理
4、经过一个版本迭代开发后，若任务开发测试完成处于可上线状态，会被打上版本的TAG，并且发布上线，在Master产生一个新版本；未完成的任务，则可在后续版本迭代开发完毕后再上线。

相比版本控制工具，适配研发流程的版本控制具有以下特点：

1、支持部分变更上线：需求内的变更可以自由筛选出来部分上线，可以类比为分支内提交数个文件，可以筛选出几个文件单独合入Master
2、需要走研发流程才可上线：每个埋点变更都拥有独立的研发流程控制和校验。这些流程(设计完成->开发->测试通过)需要走完后，才准许合入Master。
3、模型更加复杂：不是简单的文本，而是复杂的层级对象结构。

三、我们遇到的问题和痛点

在上述研发流程模式的落地过程中，我们发现了以下问题和痛点：

1、落地质量问题
- 漏埋：因为涉及较多埋点事件、埋点参数的组合，在某些组合下，埋点没有上报。
- 错埋：埋点参数缺失或格式不正确。
- 归因错误：埋点里的归因字段设置错误、不合理。
2、落地效率问题
- 大量重复埋点代码编写：如果涉及大量对象埋点，埋点工作势必成为大量重复劳动，影响研发效率。
- 埋点进行增量变更时，无法知道改动了什么：平台只展示了某个埋点全量信息，并未展示其增量改动（没有类似版本管理工具的Compare视图）。
3、功能痛点
- 有一些埋点长期停留在研发阶段未上线（类比于写代码时开发分支落后Master多次提交，没有去Pull Master获取最新的主线代码改动），导致这些埋点很可能是过时的，如果不进行卡点直接上线，就会导致问题
- 埋点数据是按APP+端两个维度隔离的，但实际运用时存在内嵌情况，如APP端可内嵌WEB端H5页面的功能，这种情况下，需要把原本隔离的数据进行整合，如把部分WEB埋点树挂载在APP端树上。

针对以上问题痛点，平台在近半年内进行了针对性的解决。

四、埋点质量建设

解决该问题的思路为先解决源头防止增量质量问题产生，再解决存量质量问题。

1、建设实时埋点校验功能，从源头解决埋点质量问题

客户端埋点开发完成后，需要进行"实时校验"，从而对被指派的埋点任务进行测试覆盖，其步骤如下：

客户端连接到实时校验平台，平台根据该任务需求，生成埋点校验树
客户端上报日志，平台根据埋点校验树进行校验
平台根据测试情况，决定测试是否通过
- 需求范围内有埋错：不通过，且可以查看日志看到具体为何不通过，如下图所示
- 需求范围内有漏埋：默认不通过，但事实推进落地中，存在部分分支客户端难以复现覆盖的情况，因此我们也支持了勾选某些分支无需测试的功能，如下图所示
若测试为不通过，则将卡点阻塞流程，后续无法正常上线

经过实时埋点校验功能的上线后，我们封堵住了大部分埋点错误源头，达到了较好效果。

2、建设线上埋点稽查功能，发现存量埋点问题并推进解决

稽查功能定位为企业日志的统计分析，解决以下问题：

1、分析日志是否按规则正确输出，检测出少参数、参数取值错误、归因错误等问题，并对这类问题进行归类，并可进一步钻取，直至能够看到原始日志的样本。
2、自定义灵活业务统计监控、报表、报警。通过监控、报表中数值变化报警来发现、辅助定位端上发版后一些bug。如：某些点位日志变少、PV/UV比例变化等。

为实现上述功能，需要对日志进行采样分析计算(可以理解为打上各种标签)，并且将计算结果存储在能够支持筛选、统计查询功能的数据库中，为典型的OLAP场景，我们选型时，采用了ClickHouse来完成这块功能，其主要考量点如下图所示

经过稽查功能上线和推进，我们的线上埋点错误数已经下降了95%，并且还在逐渐降低中，达到了较好的效果。

五、埋点效率建设

使用模版引擎自动生成代码上文提到，埋点时涉及大量重复埋点代码编写，我们针对该问题使用模版引擎语言自动生成埋点代码，且支持适配了安卓、iPhone、Web、RN等多套客户端，把代码提前生成好，能自动填写的部分全部自动填写，客户端复制代码后只需要把代码模版里剩余部分补全即可，如下图所示
展示埋点DIFF，让开发更容易理解埋点改动点

我们开发了埋点DIFF功能，相比与版本管理软件中的代码文本对比，埋点元数据是一种更加复杂的数据结构，因此在服务端计算DIFF和前端界面展示DIFF上相对来说较复杂一些。如下图所示，我们通过在原有界面上通过背景色来区分变更操作是新增、修改、还是删除。

六、研发中埋点自动Rebase到最新Master

前文提到，有一些埋点长期停留在研发阶段未上线，目前没有pull master的功能，导致：

1、这些未上线埋点元数据很可能是过时的，如果直接上线会导致业务问题。
2、无法使用到最新Master下的新增对象，或者还在使用已删除对象

因此我们对在需求池内未上线的研发阶段对象，每次上线后，都自动pull master处理。如下图所示为一个未上线需求从安卓8.8.11 Rebase到安卓8.8.12的过程，rebase后可能存在部分变更需要删除或重新研发。

rebase算法的核心在于计算出Master和本研发分支对比同一个基线的原子改动列表，并尝试依次合并，并将合并后的变更应用到基线上。其流程图如下：

其中变更合并时的逻辑如下：

人工冲突解决时，我们采用了上文“展示埋点DIFF”的功能，让埋点设计人员同时看到两方改动，并在界面中录入最终合并结果。

七、埋点跨空间打通

云音乐业务存在多个业务线，他们的“埋点空间”是相互独立的。但云音乐存在内嵌业务的情况，如云音乐APP下可内嵌LOOK直播APP、以及WEB端的H5页面等，即使云音乐APP不发版，内嵌的业务的埋点也可能会发生变化。因此需要把内嵌业务对应的的埋点树“桥接”到当前APP埋点中。针对这种诉求，我们研发了“桥梁”模式，如下图所示:

桥梁为一类特殊对象，用于衔接父子空间，如图示为衔接云音乐APP和WEB H5两个独立的埋点空间，其中云音乐APP是父空间，WEB为子空间
桥梁在父空间定义
子空间对象可设置挂载在父空间桥梁下
父空间展示埋点树时，只关心到桥梁为止
子空间展示埋点树时，会把桥梁以上所挂载的父空间树也展示出来
内嵌开发完毕后，需要使用父空间APP验证子空间的带桥梁埋点是否正确，其SPM为带父空间的完整路径

此外由于埋点按版本管理，因此埋点树若变化，必须要在平台内产生新版本，因此：

子空间发布，父空间不需要发布新版本，因为子空间埋点树对父空间不可见
父空间发布，若涉及桥梁更改，则会改变子空间埋点树，此时需要在子空间同步发布一个新版本

八、未来规划

在埋点领域中，除了纯客户端埋点，还有服务端埋点，以及双端共同完成的混合埋点，常见的混合埋点包括：

服务端下发的字段，客户端需要打到客户端埋点里
客户端上报的字段，服务端需要打到服务端埋点里

此类需求广泛存在，但未在本平台上进行管控，其流程、效率、效果是不可控、不可监控的，后续平台将把服务端埋点及服务端+客户端混合埋点也平台产品化并进行管控。

此外，网易云音乐全链路埋点管理平台前后端、客户端SDK等组件都将在近期贡献到开源社区，为业界带来更大价值。

馬斯克希望部屬學會的「向上管理」，四招讓你在職場上大展身手

Mon, 12 Dec 2022 11:23:51 CST

【為什麼我們要編譯這篇文章】

身為主管的你，是否時常覺得老闆的指令不明確，因此很難辦事，而部屬做事則常常讓你不放心？夾在中間的你，凡事都要親自操勞，早已疲憊不堪。

專家提供四個方法，讓你面對上頭老闆時輕鬆「向上管理」，並掌握「向下管理」的秘訣，在職場上事半功倍。（責任編輯：游絨絨）

你是否曾在職場上，感受到無法獲得主管充分授權，而難以大展身手？為什麼主管總是有交代不完的事項？覺得自己時常被盯進度？

不得不說，身為一個經理、主管確實不容易，但容易出現管理過度擴張、上情無法順利下達的情況。即使你的主管有一些缺點，但是讓這段職場關係正常運作，不僅符合你的最大利益，也是你的責任。也因此，如何做好「向上管理」，是讓你在工作更順暢的心法之一。

馬斯克指出「向上管理」重要性

馬斯克 2021 年 10 月發給員工的信中，示範職場如何向上管理。先別誤會，已經身為老闆馬斯克不需要向上管理，而是他在信中透露「下屬應該如何向他報告」。根據《CNBC》報導，馬斯克在信中表示， 主管可以對他的指令提出不同意見，並且指出錯誤的地方；此外，如果指令不夠明確，應該提醒他，提出還需要哪些清楚的資訊。

許多人擔心和主管提出不同意見，或向上反應時，會不利於自己，但其實和主管做好溝通，明確定義工作任務，了解業務目標，讓工作順利圓滿達成，才是符合自己的最佳利益。

討好上司？為什麼需要向上管理

所謂向上管理並不是操控你的上司，更不是「拍馬屁」！而是要了解與主管溝通的最佳方式、適時展現你的關心、實現績效目標。《哈佛商業評論》認為，向上管理是「 成為最有效率的員工，為老闆和公司創造價值」。

新創公司 Smart Workweek 創辦人Banks Benitezi ，主要在幫助企業轉型過度為每週工作 4 天，他提出向上管理的三點好處，包括建立更好的工作關係、得到更好的工作成果以及獲得心理上的安全感。

Banks Benitezi 表示，當你做好向上管理，表示你與主管和同事，正處於一種建立在誠實和對話之上的工作關係。 這可以減少誤解、減少主管的過度干預，讓主管有餘裕留心在你的職涯發展。

至於如何做到向上管理，Banks Benitezi 分享了四個方法：

1. 明確的成功指標和評估：讓主管更清楚地定義成功和評估你的績效。你需要花許多時間與主管釐清和調整優先事項、績效指標及評估。針對以上的問題進一步定義或釐清，可以幫助你和主管從一開始就保持目標一致。

2. 安排專案優先次序：通常主管可能不知道新專案如何影響進行中的項目，你必須幫助主管了解權衡取捨，安排專案輕重緩急的順序，透過這樣的流程，主管也會了解專案進度，重新評估資源、時間表以及對專案結果的期望。

3. 主動尋求回饋：當專案結束時主動尋求回饋，你正在創造一個機會微調與主管的工作關係。尋求回饋可以讓你收集有價值的意見，與主管進行對話，並儘早修正或改變你的工作方法。

4. 為自己發聲：主管可能因為忙碌，會忘記員工的職業和發展目標。所以員工如果主動提醒他們的成長目標並分享推動他們前進的想法或機會時，將有所幫助。

不懂帶人就自己做到死，主管的向下管理學

而作為一名管理者、經理，你也必須懂得「向下管理」。根據《Forbes》雜誌，擁有超過 20 年經驗的高級管理顧問 Julie Kantor 提到，主管必須克制過度管理的衝動，信任員工、適時授權，讓他們擁有自主權，同時讓員工知道你能提供他們必要的協助。

此外，Julie Kantor 同樣提到溝通的重要性，要讓組織內的資訊流通，能讓員工感受到他們的重要性，體認到他們也是組織裡的一份子；你同時也須 傾聽團隊成員的意見，有時也會讓你收穫良多，激發更多點子。在制定績效標準時，要與員工說清楚，不要模稜兩可，並具體、及時和建設性的回饋。身為一名好主管， 不吝給予表揚和讚美，能激勵部屬們有更出色的表現。

綜觀向上管理和向下管理，其實最重要就是建立主管與部屬之間的溝通，讓工作執行更順暢，身爲部屬，向上管理不僅可以讓工作順暢，也能讓自己的角色在組織中更加出色凸顯；身為主管，向下管理可以讓你事半功倍，為公司帶來更大的效益。

（本文提供合作夥伴轉載，參考資料： QUARTZ、 hbr、 forbes、 cnbc、 cultureamp，圖片來源： flickr、 unsplash）

The post 馬斯克希望部屬學會的「向上管理」，四招讓你在職場上大展身手 appeared first on TechOrange 科技報橘.

向上管理中需要告诉老板什么

Wed, 23 Nov 2022 12:30:42 CST

向上管理是一门怎么处理和自己老板关系的学问。向上管理的目标是让自己，老板，公司都取得好的结果。向上管理从来都不是简单的拍领导马屁。 Things your manager might not know列举了很多老板不知道，需要你来帮助老板了解的事情。

什么拖慢团队前进的速度

有时候团队的进度会变慢，原因可能是发现的bug比预想的多，或者是使用了一些新技术但是这些技术上手起来比较慢，或者是对其他团队有依赖。有的人可能会觉得跟老板开口说遇到了麻烦，显得自己水平不行。但是实际中很多情况并不是你的水平不行，而实一些具体困难。要勇于跟老板汇报 工作中的难点是什么，在很多情况下，老板有更多的资源和方法来帮你解决问题。解决方法可能是给你分配更多的时间（如果这个困难很重要，确实需要解决），也可能是让你找某个人帮忙（如果这个困难某个人曾经解决过），也可能是把这个困难排在后面的计划中，或者把优先级降低。

团队中的每个人在做什么

如果你和老板有很频繁的交流，比如敏捷（agile）开发中的站会（standup meeting），那么这个可能不是一个问题，老板会大概知道每个人的工作和现在的进度。但是如果你们没有这种定期的交流，那么老板可能不知道你们在做具体的什么工作。在这种情况下向老板 汇报工作进展就显得很有必要。

技术风险在哪

团队在开放的过程中总会产生一些技术债务（Technical Debt），这些技术债务积攒起来之后可能会对项目未来的发展带来很大的技术风险。你的老板很有可能不知道技术风险在哪，特别当你的老板不是技术人员出身时这个问题更加严重。你需要及时的向老板 汇报技术风险，比如那些问题可能会引起将来的什么功能开发变得很困难，或者在什么场景下产品与遇到什么样的挑战。

如何才能帮助你更好的做的你的工作

很多情况下你会觉得自己有一些地方可以改进，有时候你会疑惑为什么老板不给你必要的反馈或者支持来让你把工作做的更好。但是现实情况往往是老板并不知道你需要什么，很多时候也不知道你在苦恼什么，就算知道你遇到了麻烦，有时候他们也不知道你是想自己解决还是需要他的帮助，或者他可以提供什么帮助。这就需要你 告诉老板你需要什么帮助，比如给你分配的任务太多了，或者给你分配的任务太简单了，或者你想参加什么培训，或者时你和其他同事遇到了什么合作的难题。

更重要的，你可以 告诉老板你的目标是什么，你的职业发展规划是什么，请老板告诉你你和目标之间的差距事什么。

什么问题需要向上升级才能解决

当你遇到你们不能解决的问题时，比如需要另一个团队的配合，但是这件事不在另一个团队的优先级里。当然这个本身需要很多的练习才能很好的区分那些困难是需要向上反馈的。

你在做什么额外的工作

当你做了不在你本职工作分内的事情的时候，也需要让老板知道。这样老板会给你应得的奖励。也有一种可能是这些事情你不应该做，老板也会给你相应的建议。

超干货！彻底搞懂Golang内存管理和垃圾回收

Fri, 23 Sep 2022 00:00:00 CST

导语 | 现代高级编程语言管理内存的方式分自动和手动两种。手动管理内存的典型代表是C和C++，编写代码过程中需要主动申请或者释放内存；而Java和Go等语言使用自动的内存管理系统，由内存分配器和垃圾收集器来代为分配和回收内存，开发者只需关注业务代码而无需关注底层内存分配和回收，虽然语言帮我们处理了这部分，但是还是有必要去了解一下底层的架构设计和执行逻辑，这样可以更好的掌握一门语言，本文主要以go内存管理为切入点再到go垃圾回收，系统地讲解了go自动内存管理系统的设计和原理。

一、TCMalloc

go内存管理是借鉴了TCMalloc的设计思想，TCMalloc全称Thead-Caching Malloc，是google开发的内存分配器，为了方便理解下面的go内存管理，有必要要先熟悉一下TCMalloc。

（一）Page

操作系统对内存管理以页为单位，TCMalloc也是这样，只不过TCMalloc里的Page大小与操作系统里的大小并不一定相等，而是倍数关系。

（二） Span

一组连续的Page被称为Span，比如可以有4个页大小的Span，也可以有8个页大小的Span，Span比Page高一个层级，是为了方便管理一定大小的内存区域，Span是TCMalloc中内存管理的基本单位。

（三） ThreadCache

每个线程各自的Cache，一个Cache包含多个空闲内存块链表，每个链表连接的都是内存块，同一个链表上内存块的大小是相同的，也可以说按内存块大小，给内存块分了个类，这样可以根据申请的内存大小，快速从合适的链表选择空闲内存块。由于每个线程有自己的ThreadCache，所以ThreadCache访问是无锁的。

（四）CentralCache

是所有线程共享的缓存，也是保存的空闲内存块链表，链表的数量与ThreadCache中链表数量相同，当ThreadCache内存块不足时，可以从CentralCache取，当ThreadCache内存块多时，可以放回CentralCache。由于CentralCache是共享的，所以它的访问是要加锁的。

（五）PageHeap

PageHeap是堆内存的抽象，PageHeap存的也是若干链表，链表保存的是Span，当CentralCache没有内存的时，会从PageHeap取，把1个Span拆成若干内存块，添加到对应大小的链表中，当CentralCache内存多的时候，会放回PageHeap。

（六）TCMalloc对象分配

小对象直接从ThreadCache分配，若ThreadCache不够则从CentralCache中获取内存，CentralCache内存不够时会再从PageHeap获取内存，大对象在PageHeap中选择合适的页组成span用于存储数据。

二、GO内存管理

经过上一节对TCMalloc内存管理的描述，对接下来理解go的内存管理会有大致架构的熟悉，go内存管理架构取之TCMalloc不过在细节上有些出入，先来看一张go内存管理的架构图：

（一）Page

和TCMalloc中page相同，上图中最下方浅蓝色长方形代表一个page。

（二）Span

与TCMalloc中的Span相同，Span是go内存管理的基本单位，代码中为mspan，一组连续的Page组成1个Span，所以上图一组连续的浅蓝色长方形代表的是一组Page组成的1个Span，另外，1个淡紫色长方形为1个Span。

（三）mcache

mcache与TCMalloc中的ThreadCache类似，mcache保存的是各种大小的Span，并按Span class分类，小对象直接从mcache分配内存，它起到了缓存的作用，并且可以无锁访问。但mcache与ThreadCache也有不同点，TCMalloc中是每个线程1个ThreadCache，Go中是每个P拥有1个mcach，因为在Go程序中，当前最多有GOMAXPROCS个线程在运行，所以最多需要GOMAXPROCS个mcache就可以保证各线程对mcache的无锁访问，下图是G，P，M三者之间的关系：

（四）mcentral

mcentral与TCMalloc中的CentralCache类似，是所有线程共享的缓存，需要加锁访问，它按Span class对Span分类，串联成链表，当mcache的某个级别Span的内存被分配光时，它会向mcentral申请1个当前级别的Span。但mcentral与CentralCache也有不同点，CentralCache是每个级别的Span有1个链表，mcache是每个级别的Span有2个链表。

（五）mheap

mheap与TCMalloc中的PageHeap类似，它是堆内存的抽象，把从OS（系统）申请出的内存页组织成Span，并保存起来。当mcentral的Span不够用时会向mheap申请，mheap的Span不够用时会向OS申请，向OS的内存申请是按页来的，然后把申请来的内存页生成Span组织起来，同样也是需要加锁访问的。但mheap与PageHeap也有不同点：mheap把Span组织成了树结构，而不是链表，并且还是2棵树，然后把Span分配到heapArena进行管理，它包含地址映射和span是否包含指针等位图，这样做的主要原因是为了更高效的利用内存：分配、回收和再利用。

（六）内存分配

Go中的内存分类并不像TCMalloc那样分成小、中、大对象，但是它的小对象里又细分了一个Tiny对象，Tiny对象指大小在1Byte到16Byte之间并且不包含指针的对象。小对象和大对象只用大小划定，无其他区分，其中小对象大小在16Byte到32KB之间，大对象大小大于32KB。span规格分类上面说到go的内存管理基本单位是span，且span有不同的规格，要想区分出不同的的span，我们必须要有一个标识，每个span通过spanclass标识属于哪种规格的span，golang的span规格一共有67种，具体如下：

   //from runtime.gosizeclasses.go       
   // class  bytes/obj  bytes/span  objects  tail waste  max waste   //     1          8        8192     1024           0     87.50%   //     2         16        8192      512           0     43.75%   //     3         32        8192      256           0     46.88%   //     4         48        8192      170          32     31.52%   //     5         64        8192      128           0     23.44%   //     6         80        8192      102          32     19.07%   //     7         96        8192       85          32     15.95%   //     8        112        8192       73          16     13.56%   //     9        128        8192       64           0     11.72%   //    10        144        8192       56         128     11.82%   //    11        160        8192       51          32      9.73%   //    12        176        8192       46          96      9.59%   //    13        192        8192       42         128      9.25%   //    14        208        8192       39          80      8.12%   //    15        224        8192       36         128      8.15%   //    16        240        8192       34          32      6.62%   //    17        256        8192       32           0      5.86%   //    18        288        8192       28         128     12.16%   //    19        320        8192       25         192     11.80%   //    20        352        8192       23          96      9.88%   //    21        384        8192       21         128      9.51%   //    22        416        8192       19         288     10.71%   //    23        448        8192       18         128      8.37%   //    24        480        8192       17          32      6.82%   //    25        512        8192       16           0      6.05%   //    26        576        8192       14         128     12.33%   //    27        640        8192       12         512     15.48%   //    28        704        8192       11         448     13.93%   //    29        768        8192       10         512     13.94%   //    30        896        8192        9         128     15.52%   //    31       1024        8192        8           0     12.40%   //    32       1152        8192        7         128     12.41%   //    33       1280        8192        6         512     15.55%   //    34       1408       16384       11         896     14.00%   //    35       1536        8192        5         512     14.00%   //    36       1792       16384        9         256     15.57%   //    37       2048        8192        4           0     12.45%   //    38       2304       16384        7         256     12.46%   //    39       2688        8192        3         128     15.59%   //    40       3072       24576        8           0     12.47%   //    41       3200       16384        5         384      6.22%   //    42       3456       24576        7         384      8.83%   //    43       4096        8192        2           0     15.60%   //    44       4864       24576        5         256     16.65%   //    45       5376       16384        3         256     10.92%   //    46       6144       24576        4           0     12.48%   //    47       6528       32768        5         128      6.23%   //    48       6784       40960        6         256      4.36%   //    49       6912       49152        7         768      3.37%   //    50       8192        8192        1           0     15.61%   //    51       9472       57344        6         512     14.28%   //    52       9728       49152        5         512      3.64%   //    53      10240       40960        4           0      4.99%   //    54      10880       32768        3         128      6.24%   //    55      12288       24576        2           0     11.45%   //    56      13568       40960        3         256      9.99%   //    57      14336       57344        4           0      5.35%   //    58      16384       16384        1           0     12.49%   //    59      18432       73728        4           0     11.11%   //    60      19072       57344        3         128      3.57%   //    61      20480       40960        2           0      6.87%   //    62      21760       65536        3         256      6.25%   //    63      24576       24576        1           0     11.45%   //    64      27264       81920        3         128     10.00%   //    65      28672       57344        2           0      4.91%   //    66      32768       32768        1           0     12.50%

由上表可见最大的对象是32KB大小，超过32KB大小的由特殊的class表示，该class ID为0，每个class只包含一个对象。所以上面只有列出了1-66。内存大小转换，下面还要三个数组，分别是：class_to_size，size_to_class和class_to_allocnpages3个数组，对应下图上的3个箭头：

以第一列为例，类别1的对象大小是8bytes，所以class_to_size[1]=8；span大小是8KB，为1页，所以class_to_allocnpages[1]=1，下图是go源码中大小转换数组。

为对象寻找span，寻找span的流程如下：

计算对象所需内存大小size。

根据size到size class映射，计算出所需的size class。

根据size class和对象是否包含指针计算出span class。

获取该span class指向的span。

以分配一个包含指针大小为20Byte的对象为例，根据映射表：

   // class  bytes/obj  bytes/span  objects  tail waste  max waste   //     1          8        8192     1024           0     87.50%   //     2         16        8192      512           0     43.75%   //     3         32        8192      256           0     46.88%

size class 3，它的对象大小范围是(16，32]Byte，20Byte刚好在此区间，所以此对象的size class为3，Size class到span class的计算如下：

   // noscan为false代表对象包含指针   funcmakeSpanClass(sizeclassuint8, noscanbool)spanClass{   returnspanClass(sizeclass<<1) | spanClass(bool2int(noscan))   }

所以，对应的span class为：

   spanclass=3<<1|0=6

所以该对象需要的是span class 7指向的span，自此，小对象内存分配完成。

   //from runtime.gomalloc.go       
   var sizeclass uint8   //step1: 确定规格sizeClass   if size <= smallSizeMax-8 {   sizeclass = size_to_class8[divRoundUp(size, smallSizeDiv)]   }else{   sizeclass = size_to_class128[divRoundUp(size-smallSizeMax, largeSizeDiv)]   }   size = uintptr(class_to_size[sizeclass])   // size class到span class   spc := makeSpanClass(sizeclass, noscan)   //step2: 分配对应spanClass 的 span   span = c.alloc[spc]   v := nextFreeFast(span)   if v == 0 {   v, span, shouldhelpgc = c.nextFree(spc)   }   x = unsafe.Pointer(v)   if needzero &amp;&amp; span.needzero != 0 {   memclrNoHeapPointers(unsafe.Pointer(v), size)   }

大对象(>32KB)的分配则简单多了，直接在mheap上进行分配，首先计算出需要的内存页数和span class级别，然后优先从free中搜索可用的span，如果没有找到，会从scav中搜索可用的span，如果还没有找到，则向OS申请内存，再重新搜索2棵树，必然能找到span。如果找到的span比需求的span大，则把span进行分割成2个span，其中1个刚好是需求大小，把剩下的span再加入到free中去。

三、垃圾回收

（一）标记-清除

标记-清除算法是第一种自动内存管理，基于追踪的垃圾收集算法。算法思想在70年代就提出了，是一种非常古老的算法。内存单元并不会在变成垃圾立刻回收，而是保持不可达状态，直到到达某个阈值或者固定时间长度。这个时候系统会挂起用户程序，也就是STW，转而执行垃圾回收程序。垃圾回收程序对所有的存活单元进行一次全局遍历确定哪些单元可以回收。算法分两个部分：标记（mark）和清除（sweep）。标记阶段表明所有的存活单元，清扫阶段将垃圾单元回收。可视化可以参考下图。

标记-清除算法的优点也就是基于追踪的垃圾回收算法具有的优点：避免了引用计数算法的缺点（不能处理循环引用，需要维护指针）。缺点也很明显，需要STW。

（二）三色可达性分析

三色标记算法是对标记阶段的改进，原理如下：

起初所有对象都是白色。

从根出发扫描所有可达对象，标记为灰色，放入待处理队列。

从队列取出灰色对象，将其引用对象标记为灰色放入队列，自身标记为黑色。

重复上一步，直到灰色对象队列为空。此时白色对象即为垃圾，进行回收。

三色标记的一个明显好处是能够让用户程序和mark并发的进行，不过三色标记清除算法本身是不可以并发或者增量执行的，它需要STW，而如果并发执行，用户程序可能在标记执行的过程中修改对象的指针，导致可能将本该死亡的对象标记为存活和本该存活的对象标记为死亡，为了解决这种问题，go v1.8之后使用混合写屏障技术支持并发和增量执行，将垃圾收集的时间缩短至0.5ms以内。

（三）gc触发

在堆上分配大于32K byte对象的时候进行检测此时是否满足垃圾回收条件，如果满足则进行垃圾回收

   funcmallocgc(sizeuintptr, typ *_type, needzerobool)unsafe.Pointer{   ...   shouldhelpgc :=false   // 分配的对象小于 32K byte   ifsize <= maxSmallSize {   ...   }else{   shouldhelpgc =true   ...   }   ...   // gcShouldStart() 函数进行触发条件检测   ifshouldhelpgc && gcShouldStart(false) {   // gcStart() 函数进行垃圾回收   gcStart(gcBackgroundMode,false)   }   }

上面是自动垃圾回收，还有一种主动垃圾回收，通过调用runtime.GC()，这是阻塞式的。

   // GC runs a garbage collection and blocks the caller until the   // garbage collection is complete. It may also block the entire   // program.   funcGC(){   gcStart(gcForceBlockMode,false)   }

系统gc触发条件：触发条件主要关注下面代码中的中间部分：forceTrigger||memstats.heap_live>=memstats.gc_trigger。forceTrigger是forceGC的标志，后面半句的意思是当前堆上的活跃对象大于我们初始化时候设置的GC触发阈值，在malloc以及free的时候heap_live会一直进行更新。

   // gcShouldStart returns true if the exit condition for the _GCoff   // phase has been met. The exit condition should be tested when   // allocating.   //   // If forceTrigger is true, it ignores the current heap size, but   // checks all other conditions. In general this should be false.   funcgcShouldStart(forceTriggerbool)bool{   returngcphase == _GCoff && (forceTrigger || memstats.heap_live >= memstats.gc_trigger) && memstats.enablegc && panicking ==0&& gcpercent >=0   }       
   //初始化的时候设置 GC 的触发阈值   funcgcinit(){   _ = setGCPercent(readgogc())   memstats.gc_trigger = heapminimum   ...   }   // 启动的时候通过 GOGC 传递百分比 x   // 触发阈值等于 x * defaultHeapMinimum (defaultHeapMinimum 默认是 4M)   funcreadgogc()int32{   p := gogetenv("GOGC")   ifp =="off"{   return-1   }   ifn, ok := atoi32(p); ok {   returnn   }   return100   }

（四）gc过程

下列源码是基于go 1.8，由于源码过长，所以这里尽量只关注主流程

gcStart

   // gcStart 是 GC 的入口函数，根据 gcMode 做处理。   // 1. gcMode == gcBackgroundMode（后台运行，也就是并行）, _GCoff -> _GCmark   // 2. 否则 GCoff -> _GCmarktermination，这个时候就是主动 GC   funcgcStart(mode gcMode, forceTriggerbool){   ...   //在后台启动 mark worker   ifmode == gcBackgroundMode {   gcBgMarkStartWorkers()   }   ...   // Stop The World   systemstack(stopTheWorldWithSema)   ...   ifmode == gcBackgroundMode {   // GC 开始前的准备工作       
   //处理设置 GCPhase，setGCPhase 还会 开始写屏障   setGCPhase(_GCmark)       
   gcBgMarkPrepare()// Must happen before assist enable.   gcMarkRootPrepare()       
   // Mark all active tinyalloc blocks. Since we're   // allocating from these, they need to be black like   // other allocations. The alternative is to blacken   // the tiny block on every allocation from it, which   // would slow down the tiny allocator.   gcMarkTinyAllocs()       
   // Start The World   systemstack(startTheWorldWithSema)   }else{   ...   }   }

Mark

   funcgcStart(mode gcMode, forceTriggerbool){   ...   //在后台启动 mark worker   ifmode == gcBackgroundMode {   gcBgMarkStartWorkers()   }   }       
   funcgcBgMarkStartWorkers(){   // Background marking is performed by per-P G's. Ensure that   // each P has a background GC G.   for_, p :=range&allp {   ifp ==nil|| p.status == _Pdead {   break   }   ifp.gcBgMarkWorker ==0{   gogcBgMarkWorker(p)   notetsleepg(&work.bgMarkReady,-1)   noteclear(&work.bgMarkReady)   }   }   }   // gcBgMarkWorker 是一直在后台运行的，大部分时候是休眠状态，通过 gcController 来调度   funcgcBgMarkWorker(_p_ *p){   for{   // 将当前 goroutine 休眠，直到满足某些条件   gopark(...)   ...   // mark 过程   systemstack(func(){   // Mark our goroutine preemptible so its stack   // can be scanned. This lets two mark workers   // scan each other (otherwise, they would   // deadlock). We must not modify anything on   // the G stack. However, stack shrinking is   // disabled for mark workers, so it is safe to   // read from the G stack.   casgstatus(gp, _Grunning, _Gwaiting)   switch_p_.gcMarkWorkerMode {   default:   throw("gcBgMarkWorker: unexpected gcMarkWorkerMode")   casegcMarkWorkerDedicatedMode:   gcDrain(&_p_.gcw, gcDrainNoBlock|gcDrainFlushBgCredit)   casegcMarkWorkerFractionalMode:   gcDrain(&_p_.gcw, gcDrainUntilPreempt|gcDrainFlushBgCredit)   casegcMarkWorkerIdleMode:   gcDrain(&_p_.gcw, gcDrainIdle|gcDrainUntilPreempt|gcDrainFlushBgCredit)   }   casgstatus(gp, _Gwaiting, _Grunning)   })   ...   }   }

Mark阶段的标记代码主要在函数gcDrain()中实现

   // gcDrain scans roots and objects in work buffers, blackening grey   // objects until all roots and work buffers have been drained.   funcgcDrain(gcw *gcWork, flags gcDrainFlags){   ...   // Drain root marking jobs.   ifwork.markrootNext < work.markrootJobs {   for!(preemptible && gp.preempt) {   job := atomic.Xadd(&work.markrootNext, +1) -1   ifjob >= work.markrootJobs {   break   }   markroot(gcw, job)   ifidle && pollWork() {   gotodone   }   }   }       
   // 处理 heap 标记   // Drain heap marking jobs.   for!(preemptible && gp.preempt) {   ...   //从灰色列队中取出对象   varbuintptr   ifblocking {   b = gcw.get()   }else{   b = gcw.tryGetFast()   ifb ==0{   b = gcw.tryGet()   }   }   ifb ==0{   // work barrier reached or tryGet failed.   break   }   //扫描灰色对象的引用对象，标记为灰色，入灰色队列   scanobject(b, gcw)   }   }

Sweep

   funcgcSweep(mode gcMode){   ...   //阻塞式   if!_ConcurrentSweep || mode == gcForceBlockMode {   // Special case synchronous sweep.   ...   // Sweep all spans eagerly.   forsweepone() != ^uintptr(0) {   sweep.npausesweep++   }   // Do an additional mProf_GC, because all 'free' events are now real as well.   mProf_GC()   mProf_GC()   return   }       
   // 并行式   // Background sweep.   lock(&sweep.lock)   ifsweep.parked {   sweep.parked =false   ready(sweep.g,0,true)   }   unlock(&sweep.lock)   }

对于并行式清扫，在GC初始化的时候就会启动 bgsweep()，然后在后台一直循环

   funcbgsweep(cchanint){   sweep.g = getg()       
   lock(&sweep.lock)   sweep.parked =true   c <-1   goparkunlock(&sweep.lock,"GC sweep wait", traceEvGoBlock,1)       
   for{   forgosweepone() != ^uintptr(0) {   sweep.nbgsweep++   Gosched()   }   lock(&sweep.lock)   if!gosweepdone() {   // This can happen if a GC runs between   // gosweepone returning ^0 above   // and the lock being acquired.   unlock(&sweep.lock)   continue   }   sweep.parked =true   goparkunlock(&sweep.lock,"GC sweep wait", traceEvGoBlock,1)   }   }       
   funcgosweepone()uintptr{   varretuintptr   systemstack(func(){   ret = sweepone()   })   returnret   }

不管是阻塞式还是并行式，最终都会调用sweepone()。上面说过go内存管理都是基于span的，mheap_是一个全局的变量，所有分配的对象都会记录在mheap_中。在标记的时候，我们只要找到对对象对应的span进行标记，清扫的时候扫描span，没有标记的span就可以回收了。

   // sweeps one span   // returns number of pages returned to heap, or ^uintptr(0) if there is nothing to sweep   funcsweepone()uintptr{   ...   for{   s := mheap_.sweepSpans[1-sg/2%2].pop()   ...   if!s.sweep(false) {   // Span is still in-use, so this returned no   // pages to the heap and the span needs to   // move to the swept in-use list.   npages =0   }   }   }       
   // Sweep frees or collects finalizers for blocks not marked in the mark phase.   // It clears the mark bits in preparation for the next GC round.   // Returns true if the span was returned to heap.   // If preserve=true, don't return it to heap nor relink in MCentral lists;   // caller takes care of it.   func(s *mspan)sweep(preservebool)bool{   ...   }

参考资料：

1.《go语言设计与实现》

作者简介

冷易

腾讯后台开发工程师

腾讯后台开发工程师，目前负责腾讯医药平台后端开发工作，精通java、go底层设计架构，有丰富的高并发性能优化，分布式系统开发经验。

推荐阅读

Go：你之前的基准测试可能是错的。

福利
我为大家整理了一份从入门到进阶的Go学习资料礼包，包含学习建议：入门看什么，进阶看什么。关注公众号「polarisxu」，回复 ebook 获取；还可以回复「进群」，和数万 Gopher 交流学习。

技术管理者的 4 个基本思考点

Sat, 27 Aug 2022 10:53:00 CST

技术团队管理者在日常工作中可能经常会遇到如下一些状况：

自测质量差
转测 BUG 多
项目延期
加班赶工
高强度加班后，小伙伴状态不好，导致更多的问题出现

从第 1 点状况演变成第 5 种状况，第 5 点状况继续推动第 1 种状态的持续加强，从而导致整个团队的状态极差，陷入 BUG 多 –> 延期 –> 加班 –> BUG 更多 –> 更多的延期的死循环。

除了上面的死循环，可能还会有一些非功能性的问题，如性能、扩展性问题等等。

当团队大时，还可能遇到有小团队，各小团队各行其事，各为其主，心不往一处，力不出一孔。这些问题让技术团队的管理者焦头烂额。

那么如何解决这些问题呢？个人认为可以从以下 4 个方面来逐一思考和优化，从而在一定程度上解决这些问题。

1. 把正确的人放到合适的岗位

所有的执行最终都是落到人身上，有了正确的人，事情会事半功倍。说到人，我们往往会提起人的「选用育留」，这是一个很大的题目，我们不做详细的讲述，只关注选和用的一小部分。

管理上有一个在大部分场景适用的套路：选拔优先于培养。这个套路背后有两层逻辑：

改变一个人太难，比如有些人就是懒，抽一鞭子动一下；又或者家境优渥，态度佛系，无欲无求，根本就是油盐不进；又或者玻璃心，安全感差，都很难搞；
成本太高，即使这个人具备可培养性，但从 0 到 1 把一个人培养起来，时间成本太高，而管理者的时间很贵，公司等不起。

所以我们这里是选人，从现有的人中找到合适的，从人才市场找到合适的，能直接用的。

本小节主要是回答两个问题：

正确的人是怎样的？
如何把正确的人放到合适的岗位上？

1.1 选人

在人的层面，主要包括两个部分，执行者和管理者，这里管理者包括整个团队负责人自己。不同的部分，要求不同，选人的标准也不同。去掉专业技能部分，去掉历史经验部分，我们希望我们的伙伴是这样的：

喜欢和投入：对于技术热爱，对工作有投入度，能够专注于自己手上的工作，找到成就感；
知道自己想要什么：有一定长远的规划，知道自己走在什么样的路上，不限于一时一城之得失；
一路人：认同企业的价值观，价值观认同其本质上是「人以群分」；
宁缺毋滥：如果实在没有人，宁缺毋滥吗？这是一个好问题，严格来说是这样的，但实际中往往我们会妥协一部分。

我们选人一个常见的问题是注重人当下的表现和历史的成绩，然而我们选人是要解决未来的问题，更要关注其潜力。那么如何看一个人的潜力呢？如果具备以下的特性，大概率是一个有潜力的人：

有意愿，什么叫有意愿，就是指一个人想变好，有内在的动机去追求更高的目标；这里扩大一些，还包含积极的态度、好奇心和进取心；
有静气，特别是遇大事时有静气，临危不乱；遇到繁琐的事情能一步一步慢慢做好；
有度，做事有度，知道做事的边界在哪，进展有度，但是并不是事事划边界，事事划边界显得格局太小，多数事情还是从大局着眼；
能扛事，遇到事情找方法，不找借口，执行力强；
有所为，天赋决定了能达到的上限，努力程度决定了能达到的下限。努力去做，有所为，并且以现在绝大多数人的努力程度之低，还远远没有达到比拼天赋的程度。这里的有所为不仅仅是做事，更多的是学习，不停地学习，提升自己。

1.2 用人

1.2.2 人才梯队

人才梯队从时间上看分为现在和将来。现在是指盘点现有人才情况，梳理人才结构，对团队中的人进行分层，形成「梯状」。

当前状态的人才梯队分为两个层面，一个是分层，另一个是分层后的职责。当团队大一些后，需要明确团队的组织分层，这里可能是正式认命的 Leader，也可能是虚拟的负责人，不管是实的还是虚的，最终都会有一个层存在。

分层本质上是一个分饼的行为，什么样的人拥有什么样的资源，承担什么样的责任，行使什么样的权利。

作为一个研发团队的负责人，需要梳理这些层，确定是否有合适的人，这些层的负责人形成了我们所说的「人才梯队」。

德鲁克曾说：「一个组织应该使每个人，特别是每个管理人员和每个专业人员（但也包括每个管理单位）都理解自身的任务」。在我们做分层的过程中，需要关注每一层的职责和其解决的问题，如我们在软件架构设计的时候一样，每一个分层都有其作用，无用的分层只会增加性能的损耗。

对于将来，未雨绸缪。

当现在的人才正在发挥作用时，培养接班人，我们经常称之为 B 角。当有人才变动时可以快速补位上去。常用的方法有内部培养，跨团队轮岗，外部招聘等。

这块特别狠的可能要算宇宙厂了，在现有人员已经能满足工作需要的同时，会继续招聘，如果更优，可能会换人。

1.2.2 艰难的决定

在我们构建人才梯队的时候，想要做到知人善任是一件很难的事情，并且让每个人的表现都达到预期水平更难。当有些人并不能胜任他当前的工作时，我们应该怎么做？这里可能有以下两种常见的方式：

调岗，一般这种情况可能只是人岗不匹配，或者有些变化跟不上，但是对于人的部分能力还是比较认可。此时我们在公司内给他找一个匹配的岗位，更好地发挥其潜力。在技术团队最常见的例子是有些高 P 的技术同学，被推到管理岗，过了一段时间，发现适应不了，此时我们可以将其调到更能发挥其能力的岗位上来。又或者一些管理者因为团队扩大或者一些其它原因，管理的范围一下子增加了很多，一段时间后发现无法搞定这样的团队，此时可能将其调整到稍微低一级的职位上更合适一些。
离开，尽量让对方体面的离开，公司和个人都体面的分手，该赔偿的赔偿，该理解的理解，如果在外面有合适的机会，顺手推一把，也是个不错的善缘，不枉同事一场。这里经常出现的问题是犹豫不决，最终导致大家都不开心，不欢而散。管理上常说：「心要慈,刀要快」，就是要规避这种犹豫。

1.3 管理者自己

在用人中还包括管理者自己，一个技术管理者，不仅仅要注重技术，不仅仅要设定明确的目标并排出优先顺序，跟进过程发现问题解决问题，拿到结果，还要注意另一个重要的点：业务参与者。

一个优秀的管理者和一个不那么优秀的管理者的主要差别就是他们对业务的参与程度。事实证明，对所负责业务参与的程度越深，你就越能做出更加明智的决策。

什么叫业务参与度？

我认为它不是事无巨细地了解进展，应该到一线去，怎么到一线去，去写代码，去做代码评审？

到一线去，有两个层次，一个是业务的一线，用户或产品，看用户的反馈，产品的实现，二是工作的一线，看工作流程的卡点，系统化的情况，可视化的情况。不要自己去做这些事情，主要是收集信息，决策或者发现问题解决问题，这里确定做什么的原则是：你做的事情的价值大小，而价值大小可以从时间杠杆，团队杠杆上来指数级扩大，如果做一件事只有短期的一件事的价值，那这些事情就不是你应该做的，应该停下来去思考要做的事情。

2. 组织

说到组织，你是想要一个「令行禁止，使命必达」的组织，还是一个「简单可依赖」的组织？

组织是为实现共同目标而采取的一种分工协作体系，是人与人之间的关系，组织结构往往会随着组织的重大战略调整而调整。

而企业在商场中求生，随着外部环境的变化，行业的变化，内部环境的演进而会不断进行迭代，不断调整组织结构，因此我们经常需要重新设计组织结构。

2.1 设计组织结构

我们在设计组织结构的时候通常要思考以下五个问题：

组织的目标是什么？因为组织是为了共同目标而存在的人与人的关系，目标不清楚，组织结构肯定也是不清楚的。
组织由哪些层，哪些单位组成？组织是一个体系，由不同的单元组成，需要明确各层或单元分别是什么，职责是什么，其作为一个子结构需要有自己的目标和使命。
组织各部分的规模和形式应该是怎样的？根据现实的情况，在设计组织结构时需要着重考虑规模和形式，多少层级？流程型？考虑管理者的有效管理幅度。
组织的哪些部分应该结合在一起，哪些部分应该分开？
组织内各单元之间的关系和协同应该是怎样的?

设计组织结构最难的问题可能是分和合的问题，这里有一个原则：凡是做出同样的贡献的活动可以结合在一个部门中统一管理，不论它们的技术专业是什么。那些不是做出同样贡献的活动则一般不应合在一起。

在考虑组织结构，特别是研发团队的组织结构的时候，千万不可忽略了康威定律，甚至我们有时需要「逆康威定律」，通过适配康威定律，在明确技术架构方向的基础上，以组织结构的调整来推动技术架构的演进。

2.2 组织的形态

每家企业都有自己的文化和组织形式，抽象出来大致可以分为权力型，流程型和交易型，落到研发团队内部，一般只有前两种。

现在许多人强调去中心化、去科层化、去权力化，实际上，在大多数情形下，权力连接还是最直接、最简单、最有效的机制。权力组织讲究的是执行。

组织中的权力主要有四种。除了决策权，还有建议权、审核权和知情权。

决策权，对一个事情决定资源投在哪里，是不是可以做的权力；
建议权是提出方案、预案的权力。注意，这是一种权力：建议权拥有者如果未提出建议，上级决策者不能替代或强压；
审核权是对有关事项程序性、合规性的审查与核准。注意，这种权力不是对事项进行决策；只要有关事项符合程序、合乎标准和规范就予以通过放行。我们经常会看到一些企业的职能管理部门把审核权误当成了批准决定权，导致审批流程变长、决策效率降低，这是需要反思改进的。
知情权是信息共享权，即获取信息的权力。

以上 4 个权限很容易让我们想到项目管理里面的 RACI 矩阵：

谁负责：（R = Responsible），即负责执行任务的角色，他/她具体负责操控项目、解决问题。
谁批准：（A = Accountable，决策权），即对任务负全责的角色，只有经他/她同意或签署之后，项目才能得以进行，是整个事情的决策者；
咨询谁：（C = Consulted，建议权），拥有完成项目所需的信息或能力的人员，多提出建议。
通知谁： (I =Informed，知情权)，即应及时被通知结果的人员，却不必向他/她咨询、征求意见。

以上四种权力，决策权和建议权是权力主线，审核权和知情权是权力副线。主线是上下级逻辑，副线是平级或流程型逻辑，而我们往往理解的权力是主线权力。

在强权力主线的基础上，权力型组织的有以下 3 个缺点：

唯上，组织内的成员对决定其资源或发展的上级负责；
组织的发展由上级决定，当上级缺位、能力不足或脱离实际时可能会出现瞎指挥，乱指挥的情况；
层级过多，导致执行和决策的效率低下。

为规避这些缺点我们需要减少层级，增加连接和协同。

如果把管理层只分为三级，我们一般称之为高层、中级和基层。这三个层要解决的问题不同。高层解决长期发展的问题，中层解决系统效率的问题，基层解决的是事情本身的问题。

比如技术管理者常规上可以分为三个大层：

高层管理：解决长期发展的问题，使企业/团队有前途，关注的是未来，不管是技术发展的未来，还是业务发展的未来；
中层管理：解决系统效率的问题，使系统更有效率，要不断强化研发流程的统一性和适应性，确定并执行好标准和规范，提升协同的效率，标准化和系统化，同时为上层的选择和决策提供依据和保障；
基层管理：解决事情本身的问题，而事情往往会落到一线的开发同学身上，于是经常我们基层管理者的主要工作是使一线开发同学工作有成就，培养一线开发同学，提高他们承担工作的能力和意愿，帮助他们解决问题。

我们期望是每个层能做好自己的事情，但是实际上往往是高层在做中层的事情，中层在做基层的事，基层在做一线的事情，错位了。于是，我们需要将管理层归位，各行其职，更专业的做事情。

在明确职责的基础上，尽量减少管理的层级，尽量不要出现「副XX」的岗位。

在协同方面我们用流程来解决协同合作的问题。流程本身的逻辑是对事情负责，对自身的任务及向下事项/环节负责。其驱动力是责任感和依赖。百度文化里面的「简单可依赖」能较好地说明流程的底层逻辑。当我们使用流程来解决协同的问题时，要经常迭代流程以优化协同的效率：

注意流程是为了解决过程中的问题，不是为了设置卡点，每个人都有扩大自己权力的欲望，这是我们在流程建设中要特别注意的；
尽量减少流程环节，聚合责任主体，我们经常遇到一个事情在某职能部门还需要经过两三道审核的情况，这种损耗可以通过聚合责任主体的方式来解决；
控制流程时长，这里控制流程时长还包括流程环节的前置准备，就和我们开会一样，如果开会前准备充分，会议本身的时长就有极大可能减少。

用权力解决「力出一孔」的问题，用流程解决协同合作的问题。

简单来说，在权力体系的基础上，用流程连接各环节和负责主体，现在比较常见的矩阵式组织结构基本符合这个逻辑。当然这里有一个以流程为主还是以权力为主的问题，具体是哪种，还得看公司当前组织结构的逻辑。

2.3 分工的粗和细

Adam Smith 在 1776 年的《国富论》中提出了分工，分工对于手工业生产效率有较大的提高，其总结了三个优点：

熟练程度的增加，当一个人专注于一块工作，不停的练习极大的增加了熟练度，熟练度的增加将导致质量和产量的增加；
当熟练后，人们对于重复的操作进行机械化或自动化，从而更大的提高质量和产量；
分工明确了输入和输出，在明确的分工下，从一个工序转为另一个工序的时长减少了。

自从分工提出来了，产生了大量的争论，有人提出了以下的一些缺点：

一叶障目，不见泰山，分工越细，所关注的东西都小，当人陷于某个事情越来越小的部分时，其大局观往往受限，可能会导致局部提升而全局受损的情况；
分工越细意味着沟通协作成本的增加，当分工获得的收益小于沟通协作的收益时，将产生极大的成本浪费；
分工一定关系到组织结构的分块，当沟通不畅或没有沟通时，有可能出现组织上的「孤岛」

分工落到一个研发团队，我们通常按编程语言分为 Java、PHP、C++、Javascript，或按端分为安卓端、iOS 端、前端、后端、算法、数据等，又或者大一点分为开发、测试、运维，架构师。

虽然「术业有专攻」，但多跨一步会让分工后的协同更高效一些，这里最常见的可能是测试左移和测试右移。

测试左移是指在研发流程中，把测试的覆盖范围从传统的测试节点中释放出来，将其向左扩展，介入代码提测之前的部分，如开发阶段阶段，需求评审阶段，让研发人员在架构设计时就考虑产品的可测试性，并尽量进行开发自测，同时评估需求的质量，比如分析需求的合理性以及完整性等。
测试右移是指把测试的覆盖范围从传统的测试环节中切出来，将其向右扩展，更多地融入代码部署、发布，甚至上线之后的步骤中。

更极端一些，走全栈路线，一个人从头到尾完成需求的所有工序。但是这种方式，对于人员素质的要求，对于团队组织的要求和常规不一样，且人的精力是有限的，能在每个方面都做到精通的，少之又少，除非所做的事情只需要略懂即可。

思考一下，你所在团队应该如何来做？

成本和效率？组织大小？技术发展？架构演进？

3. 机制

3.1 DRI 机制

3.1.1 DRI 的由来

DRI 是 Directly Responsible Individual 的简称，中文翻译为「直接负责人」。最开始是从苹果流传出来的内部管理概念。

DRI 不是流程、过程，也不是框架，而是一个负责人，对某部分的整体负责，小到 BUG，大到技术方向。 DRI 是为了解决责任主体的问题，其有助于避免责任分散。责任分散这个概念也被称为「旁观者效应」，也就是人们身处团队中时无法对某事负起责任，责任分散到了团队中的每个成员身上，而不是集中在真正有责任的人身上，因为每个人认为那个责任应该由其他人承担，表现得像一个旁观者。

3.1.2 DRI 的职责

聚焦目标；
督促、监督团队成员完成自己的任务；
清楚团队中发生的一切；
统筹策划，搞定所有的干系人，从头到尾负责到底，说简单点就是团队成员专注的做好手上的事儿， DRI 排除干扰，解决各种烦人的问题来，发现问题，解决问题；
有一定的领导责任。

简单来说，当你是某个事情的 DRI 后，这个事情就是你自己的事情。特别是当职责不清或者突发问题时，DRI 就需要发挥主人翁的精神，拉起团队成员去分析问题，解决问题。

3.1.3 什么人适合做 DRI

DRI 和工作年限无关，和是否资深无关，和技术工种无关，你想你就是。

但是在操作过程中，我们会根据实际的场景做一些偏重。如果是一个后台的活儿居多的项目，其 DRI 大概率是后台的开发同学，如果是一个质量问题较多的项目，其 DRI 大概率是一个 QA 同学。

这里我们会充分考虑同学的主观意愿，有些同学想，有些同学不愿意，只想做好手上的工作，那么他做好他手上工作的 DRI 就可以了。

DRI 无关项目大小，无关职位高低，无关所在层级，每一件大事，小事都需要有一个 DRI，且只有一个 DRI

这玩意儿换成中文其实就是我们在标语里面经常看到的「责任到人」差不多，但是更强调责任主体的唯一性。

3.2 构建良好的协同机制

公元前 221 年，秦始皇用了十年的时间，先后灭了韩、赵、魏、楚、燕、齐六国，完成了统一中国的大业。在以后，他陆续颁布了多条律法，以稳固国家的统治，包括「书同文」、「车同轨」、「度同制」等。

一个国家，一个组织，要想成为一个高效执行的团队，一定要有标准，一定要有人告诉大家怎样做是对的。落到我们团队管理，标准，流程是必须要做的，特别是当你的团队是由若干个团队整合或融合的时候。

3.2.1 统一标准规范

当你的团队是由原来多个业务的团队融合而成，大家原来都有做一些标准，现在我们需要按统一的标准达成共识并推行下去。又或者本来标准不完善，需要系统梳理标准来达到标准的统一。

行业标准一般是为了互联互通，而对于研发团队的研发过程来说，标准主要是为了减少过程中的认知成本，提升研发的效率，比如数据库规范，大家按统一的规范来设计数据库，当有其它同学接手你负责模块的时候，能减少在基本结构的认知成本，以及在一些模块间整合或数据迁移时，对于工作会比较友好一些。

标准是什么，标准是一件行为准则，其关注的是结果。

标准和规范一般是为了告诉人们什么是好的，关注的结果，而统一标准是为了让大家互联互通。

标准不是为了成功，而是为了让整个事情不至于太坏，尽量不出现重大的问题。具体到研发团队，我们一般需要统一如下一些标准：

研发过程
- 代码风格规范
- 数据库设计规范
- 代码分干管理规范
- 代码提交规范
- 错误码规范
- Code Review 标准
- 代码权限管理规范
沟通协同
- 架构规范
- 技术方案规范
- 文档规范
- 接口规范
质量标准
- 代码质量标准
- 自动化测试标准
- 测试质量标准
- 线上质量标准
性能标准
- 服务端性能标准
- 客户端性能标准
- 前端性能标准
安全标准
- 信息安全标准
- 代码安全标准
- 数据安全标准
- 线上安全标准

3.2.2 统一流程

流程是什么？

流程是基于时间线，有一定先后序列规则的完成一件事的过程。流程是线性的、连续的。

统一流程是什么？

统一流程就是把一些验证过的好的做事方式，好的经验通过流程的方式固化下来，防止大家重蹈覆辙，在一个坑里踩多次，并且为不熟悉的同学做好指导。

我们做任何一件事都是有流程的，有些是设计过的，有些是自然而然的，设计过的流程可能是别人的经验。并且流程需要持续迭代。

在研发管理中我们常常会构建的流程如下：

敏捷流程
- 需求迭代流程
- 紧急需求流程
- 值班需求流程
研发流程
- 代码审核流程
- 代码发布流程
- 紧急发布流程
协同
- 对接流程
- 资源申请流程
- 线上问题/告警处理流程
- 事故处理流程
- 安全问题处理流程

3.2.3 统一工具

以上说了要统一标准，统一流程，这些第一步是要把这些标准和流程做出来，形成文档，落到知识库中。如果只做到这一步，这些标准和流程可能就真的只是一个文档，情况好一点，有人来推进重视，可能会落实一些，但一旦这个推进人不在了，或者不再关注了，很多形式就不了了之。

要解决这个问题只能通过工具或系统，以工具或系统的形式固化标准和流程，把这此好的经验和方式以更物理的方式沉淀下来。再以这些工具或系统为杠杆，提升整体研发的效率，创造增量的价值。

4. 系统

这里的系统不仅仅是指使用某个系统，在使用系统的基础上整合，实现我们高效执行的目的。前面我们有了机制，但是事情太多，不能让所有的事情用人来去解决，需要用系统来解决。

机制解决规模化的问题，系统解决规模固化的问题。系统解决的问题有两个层面，一个是过程跟进，一个是结果度量。

4.1 工作流和过程跟进系统

一个研发部门可以看作一个系统，需求从一端进入，经历各种正确的工序，才能变成产品，如期从另一边离开。当系统内部存在冲突，或者不和，或者互相针对，那么就会发生各种想象不到的问题，从而让整个系统的产出变少，甚至没有。

着眼于整个工作流，确认瓶颈点在哪，尽可能的运用各种技术和流程来确保工作在计划内有效的执行。因为我们知道：在代码投产之前，实际上并未产生任何价值，因为那只是困在系统里的半成品。

在实际中我们如何让大家更好的协同，更好的让这个工作流运转起来呢？以前可能是 Excel、Word 或者 todolist，再加上邮件或 IM 传来传去，现在更进一步有在线的表格协同，还有更完整的项目管理系统，如 Jira 、Trello、腾讯的 TAPD、阿里的 Teambition、禅道等。工具不同，但是目标是相同的，都是希望做到对项目执行的管控、对团队事务（问题）的跟踪，对需要多人协作任务的快速流转和处理。

除此之外，还需要文档管理，即过程中的物料也需要跟进起来，关联起来。至于是一个系统，还是多个系统，都是可以的。

系统虽有，但用得怎么样不好说，一个好的系统用不起来也是白搭，这里作为管理者需要推动起来的。

4.2 工作可视化

项目管理的系统用起来后，我们的工作流转就会落到系统里面，此时根据系统的数据，我们可以让工作可视化，透明化，能够清晰的观察工作流动的情况，从而发现瓶颈。发现问题是最难的，很多时候我们不知道有什么问题，包括自己。发现问题，才能解决问题，方法总是有的。在资源有限的情况下，对非约束点的改进看起来很正确，但实质上毫无帮助，甚至会消耗宝贵资源拖累真正需要解决的问题。

我们可以构建一些看板，看一个产品从产品到设计、到研发实现，到测试完成，上线发布，再到线上问题跟进等等的情况。看效率，看一个需求从出现想法到用户看到需要多少时间，每个环节需要多少时间，哪些需求在哪些环节停留太久？不同的需求，不同的人，不同的产品做多个层次的对比，从而发现问题解决问题，让一切都在阳光下进行。

同时，我们可以让系统和数据告诉我们，整体团队的投入如何，有多少同学的工作是可以追溯的，有多少人力是隐藏在不为人知的地方的，能看到我们的时间都去哪了。

基于这样的看板，我们从两个角度优化整个系统：

从左到右的流动，看从产品、设计、研发到运维的工作情况。为了最大程度地优化工作流，需要将工作可视化，减小每批次大小和等待间隔，通过内建质量杜绝向下游传递缺陷，并持续地优化全局目标；
从右向左的反馈，每个阶段中，应用持续、快速的工作反馈机制。通过放大反馈环防止问题复发，并缩短问题发现时间，实现快速修复。通过这种方式，我们能从源头控制质量，并在流程中嵌入相关的知识。这样不仅能创造出更安全的工作系统，还可以在灾难性事故发生前就检测到并解决它。

总体来说，先透明出来，再优化，打开黑盒，问题会简单很多。

4.3 其它

以上的两个是从任务跟进和结果度量的角度，或者说从项目管理的角度来看整个团队的运转。换一个角度，从研发同学工作本身，有没有需要系统化的地方？

代码管理是否系统化，Code Review、接口文档、接口自动化测试、Mock 数据、测试数据集管理、用户数据自动脱敏重放，代码从写完提交到代码库之后到上线，线上巡查等等这些是否有系统化？

这并不是今天我们要讲的话题，但是就系统化来说，这些都是必不可少的关键点。不管是哪方面，我们的原则是尽量减少人工介入，把人的经验变成代码和系统。

5. 后记

这篇文章务虚居多，也比较散，但是确实是技术管理者日常工作中要不停思考的点。思考这些是用来帮助厘清思路，并不具备实操性，也就是不能实际的解决问题。不同的公司，不同团队，问题不同，解决的方法也不同，欢迎一起探讨。

打开「黑盒」，问题会简单很多。常思考人、组织、机制和系统，这 4 个方面，发现其中的问题，并厘清解决问题的思路，一步一步，有节奏的去解决。

你好，我是潘锦，超过 10 年的研发管理和技术架构经历，出过书，创过业，带过百人团队，也在腾讯，A 股上市公司呆过一些年头，现在在一家 C 轮的公司负责一些技术方面的管理工作。早年做过 NOI 和 ACM，对前端架构、跨端、后端架构、云原生、DevOps 等技术始终保持着浓厚的兴趣，平时喜欢读书、思考，终身学习实践者，欢迎一起交流学习。微信公众号：架构和远方，博客： www.phppan.com

实战 HTTP 连接管理

Thu, 14 Jul 2022 16:32:50 CST

1.背景

短连接

HTTP 协议最初（0.9/1.0）是个非常简单的协议，通信过程也采用了简单的“请求 - 应答”方式。它底层的数据传输基于 TCP/IP，每次发送请求前需要先与服务器建立连接，收到响应报文后会立即关闭连接，所以就被称为“短连接”（short-lived connections）。

短连接的缺点相当严重，因为在 TCP 协议里，建立连接和关闭连接都是非常“昂贵”的操作。

长连接

针对短连接暴露出的缺点，HTTP 1.1 版本协议就提出了“长连接”的通信方式，也叫“持久连接”（persistent connections）、“连接保活”（keep alive）、“连接复用”（connection reuse）。

2.实战

注意：以下的结果都是基于 HTTP/1.1 协议。

2.1 长短连接的特点

HTTP 1.1 默认会开启长连接，相应的头字段为 Connection，它可能会出现在请求头和相应头中。请求头中出现 Connection:keep-alive,表示客户端希望和服务器进行长连接，而响应头中使用了 Connection:keep-alive 表示最后确实是用了长连接。

我们此次实战后端使用 JavaScript 的服务端框架 Koa。接下来使用一个简单的实例来演示：

后端

  const Koa = require('koa')
const app = new Koa()

app.use(async (ctx,next) => {
    ctx.body = 'hello'
})

app.listen(3002)

启动后端服务，使用浏览器打开 http://localhost:3002，我们来观察请求头和响应头。

在上面的图片中，我们可以观察客户端想要使用长连接，服务器支持并且允许开启了长连接。

接下来我们来修改一下代码：

后端

  const Koa = require('koa')
const app = new Koa()

app.use(async (ctx,next) => {
    ctx.set('Connection','close')
    ctx.body = 'hello'
})

app.listen(3002)

服务端对所有请求采用短连接的方式。我们来观察一下结果。

此时虽然客户端想使用长链接，但是服务器最后策略使用了短链接。

2.2 长链接和短链接的区别

长链接可以进行链接复用。我们接下来使用代码来演示。

后端 demo 结构

  projectRoot
|
|_static
       |
       |_test.html
       |_test1.png
       .
       .
       .
       |_test9.png
|
|_app.js

我们在 static 文件夹中放了 10 个文件，分别是 test.html 和 9 张图片。

app.js

  const Koa = require('koa')
const fs = require('fs')
const path = require('path')
const app = new Koa()


app.use(async (ctx,next) => {
    // 拿到静态文件夹的路径
    const staticPath = path.resolve(__dirname,'static')
    if(ctx.url === '/'){
        // 根路径时返回 test.html 文件
        const indexPagePath = staticPath + '/test.html'
        ctx.set('Content-Type','text/html');
        ctx.body = fs.readFileSync(indexPagePath)
    }else {
        if(ctx.url.includes('test')){
            // /testx.png 返回图片
            ctx.set('Content-Type','image/png');
            ctx.body = fs.readFileSync(staticPath + ctx.url)
        }
    }
})

app.listen(3002)

test.html

  <!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Title</title>
</head>
<body>
<img src="/test1.png"/>
<img src="/test2.png"/>
<img src="/test3.png"/>
<img src="/test4.png"/>
<img src="/test5.png"/>
<img src="/test6.png"/>
<img src="/test7.png"/>
<img src="/test8.png"/>
<img src="/test9.png"/>
</body>
</html>

接下来启动后端服务，使用浏览器打开 http://localhost:3002/test.html ,并且打开谷歌浏览器的开发者工具 Network 面板。注意，为了更好的观察现象，我们需要将网络模拟 Fast 3G，并且显示抓包表头项里面的 Connection ID 项，以及只看图片 Img 类型。

观察上面的结果，我们可以发现 Connection ID 有六个不同的 Id，剩下的三个 Id 是重复的。这个可以说明，chrome 浏览器在一个域名下只能同时创建 6 个 TCP 链接并发进行数据传输，剩下三个多余的请求为了复用 TCP 链接需要等待，我们通过 waterfall 表头也能观察到灰色的等待时间（stalled）。

接下来我们修改一下代码：

app.js

  app.use(async (ctx,next) => {
    const staticPath = path.resolve(__dirname,'static')
    if(ctx.url === '/'){
        const indexPagePath = staticPath + '/test.html'
        ctx.set('Content-Type','text/html');
        ctx.body = fs.readFileSync(indexPagePath)
    }else {
        if(ctx.url.includes('test')){
            ctx.set('Connection','close');// 使用短链接
            ctx.set('Content-Type','image/png');
            ctx.body = fs.readFileSync(staticPath + ctx.url)
        }
    }
})

服务端使用短链接之后，我们发现 Connection ID 不再重复。

2.3 长链接优化

由于长时间进行连接是很消耗服务器性能的，当链接没有数据传输或者 TCP 链接的请求数到达一定数量时，我们想要关闭长链接，这时候应该怎么做呢？

我们可以通过配置 nginx，如果配置了“keepalive_timeout 60”和“keepalive_requests 5”，意思是空闲连接最多 60 秒，最多发送 5 个请求。所以，如果连续刷新五次页面，就能看到响应头里的“Connection: close”了。

简述前端包管理工具机制和相关实践

Wed, 01 Jun 2022 00:00:00 CST

简述前端包管理工具机制和相关实践

npm 依赖管理机制

区别于 Python 的包管理工具 pip 的全局安装，npm 会安装依赖包到当前项目目录，使不同项目的依赖更成体系，这样做的好处是减轻了包作者的 API 兼容性压力；但是缺陷是如果两个项目依赖了一个相同的库，一般这个库会在这两个项目中各安装一次，即相同的依赖包会被多次安装。
我们先通过一张流程图(源自掘金)来了解下 npm install 的整体流程

可以看到执行 npm install 后依次会进行以下流程

检查 package-lock.json
通过和 package.json 对比确定是否远程获取包信息
扁平化构建依赖树
添加缓存
下载包并解压到 node_modules
生成新的 lock 文件值得注意的是，早期 npm 版本(v5.0 - v5.4)发现 package.json 和 package-lock.json 不一致时，对依赖的安装方式是不一样的。 所以对于团队而言，最佳实践应该是保持 npm 版本的一致性！

缓存机制

我们可以从流程图中看到，npm install 的流程中会查找和使用缓存，以及下载包后会添加缓存的环节。由于依赖嵌套机制，项目中 node_moudles 占用的磁盘空间无疑是最大的，如果安装时每次都通过网络下载获取，那么时间成本是巨大的。常见的优化方式是“空间换时间”，npm 也通过缓存机制来解决这个问题。
简单了解下缓存的目录的和清除机制。
通过 npm config get cache命令可以查询到缓存目录：默认是用户主目录下的 .npm/_cacache 目录。
npm cache clean --force即可强制清除缓存。

yarn 带来了什么？

yarn 是于 2016 年诞生的，它的出现解决了历史上 npm 的很多问题，比如缺乏对于依赖的完整性和一致性保障(npm v3 版本还没有 package-lock.json)，以及 npm 安装速度过慢的问题等。npm 目前已经迭代到 v8 版本，在很多方面已经借鉴了 yarn 的优点，但是我们不妨了解下 yarn 诞生时带来的理念。

确定性。通过 yarn.lock 等机制，保证了确定性，这里的确定性包括但不限于明确的依赖版本、明确的依赖安装结构等。即在任何机器和环境下，都可以以相同的方式被安装。
模块扁平化安装。将依赖包的不同版本，按照一定策略，归结为单个版本，以避免创建多个副本造成冗余。
更快的速度。yarn 采取并行安装的机制进行包的安装任务，提高了性能；yarn 引入的缓存机制使二次安装的速度更快。
更好的语义化。yarn 的命令更加简洁。 解决早期 npm 的依赖管理问题

文章的开始提到 npm 是将依赖放到项目的 node_modules 中，同时如果 node_modules 中的依赖 A 还依赖了其他依赖 B，那么 B 也会被安装到 A 的 node_modules 文件夹，依次递归最终形成非常复杂和庞大的依赖树。
这种依赖管理方式会随着项目的迭代，node_moudles 会变得越来越复杂，从而造成：

非常深的项目依赖层级，难以排查问题
依赖被重复安装，浪费磁盘，网络等资源，安装速度慢那么 yarn 是如何解决这个问题的呢？那就是模块扁平化安装机制。假如我们有这样一个文件依赖结构。

  App   
 -a@2.0   
   -b@2.0   
 -b@2.0   
 -c@1.0   
   -b@2.0

yarn 在安装依赖时会打平依赖，并对重复依赖进行提升，最终形成的依赖结构如下：

  App   
 -a@2.0   
 -b@2.0   
 -c@1.0

但是需要注意的是： 模块的安装顺序可能影响 node_modules 内的文件结构。在 npm v3 版本中，假如项目一开始依赖了 a@1.0，此时 a@1.0 会被安装在顶层目录；随着迭代，又引入了模块 b@1.0，而 b@1.0 又依赖了 a@2.0，此时 a@2.0 会被安装在 b@1.0 下，因为顶层已经有一个 a@1.0 了。

pnpm: 最先进的包管理工具？

在各个场景下，pnpm 相比较于 npm(v8)和 yarn(v3)在性能上都有不错的提升。
pnpm 之所以有如此大的性能提升，简单来说 pnpm 是通过全局 store（目录 ${os.homedir}/.pnpm-store）来存储 node_modules 依赖的 hard-links，当在项目文件中引用依赖的时候则是通过 symlink 去找到对应虚拟磁盘目录下(.pnpm 目录)的依赖地址。相比于 npm 和 yarn 会在每个项目中都安装一份 node_moudles, pnpm 的全局 store 则实现了“安装一次，所有项目复用”，这样避免了二次安装带来的时间消耗。
除此之外，pnpm 本身的设计机制解决了 monorepo 的很多痛点，比如 ”幽灵依赖“和 ”依赖重复安装“的问题。如图：下面两小节内容源自：pnpm: 最先进的包管理工具 ^[1]

幽灵依赖

Phantom dependencies 被称之为幽灵依赖，解释起来很简单，即某个包没有被安装(package.json 中并没有，但是用户却能够引用到这个包)。
引发这个现象的原因一般是因为 node_modules 结构所导致的，例如使用 yarn 对项目安装依赖，依赖里面有个依赖叫做 foo，foo 这个依赖同时依赖了 bar，yarn 会对安装的 node_modules 做一个扁平化结构的处理(npm v3 之后也是这么做的)，会把依赖在 node_modules 下打平，这样相当于 foo 和 bar 出现在同一层级下面。那么根据 nodejs 的寻径原理，用户能 require 到 foo，同样也能 require 到 bar。

  package.json -> foo(bar 为 foo 依赖)   
node_modules   
  /foo   
  /bar -> 依赖

那么这里这个 bar 就成了一个幽灵依赖，如果某天某个版本的 foo 依赖不再依赖 bar 或者 foo 的版本发生了变化，那么 require bar 的模块部分就会抛错。

依赖重复安装

这个问题其实也可以说是 hoist 导致的，这个问题可能会导致有大量的依赖的被重复安装，举个例子:
例如有个 package，下面依赖有 lib_a、lib_b、lib_c、lib_d，其中 a 和 b 依赖 util_e@1.0.0，而 c 和 d 依赖 util_e@2.0.0。
那么早期 npm 的依赖结构应该是这样的:

  - package   
  - package.json   
  - node_modules   
     - lib_a   
       - node_modules <- util_e@1.0.0   
     - lib_b   
       - node_modules <- util_e@1.0.0   
     _ lib_c   
       - node_modules <- util_e@2.0.0   
     - lib_d   
       - node_modules <- util_e@2.0.0

这样必然会导致很多依赖被重复安装，于是就有了 hoist 和打平依赖的操作:

  - package   
  - package.json   
  - node_modules   
     - util_e@1.0.0   
     - lib_a   
     - lib_b   
     _ lib_c   
       - node_modules <- util_e@2.0.0   
     - lib_d   
       - node_modules <- util_e@2.0.0

但是这样也只能提升一个依赖，如果两个依赖都提升了会导致冲突，这样同样会导致一些不同版本的依赖被重复安装多次，这里就会导致使用 npm 和 yarn 的性能损失。
如果是 pnpm 的话，这里因为依赖始终都是存在 store 目录下的 hard links ，一份不同的依赖始终都只会被安装一次，因此这个是能够被彻彻底底的消除的。

项目中的相关场景实践和常见问题

npm link

适用场景：本地调试 npm 模块，将模块链接到对应的业务项目中运行使用方法：假如我们需要把模块 pkg-a 链接到主项目 App 中，首先在 pkg-a 根目录中执行 npm link，然后在 App 根目录中执行 npm link pkg-a 即可。调试完可以使用 npm unlink 取消关联。原理：npm link 通过软连接将 pkg-a 链接到 node 模块的全局目录和可执行文件中，实现 npm 包命令的全局可执行。

npx

适用场景：在 npm 5.2.0 版本之后，npm 内置了 npx 的包。npx 是一个简单的 cli 工具，可以帮助我们快速的调试，还可以让我们在不通过 npm 安装包的前提下执行一些 npm 包。

使用方法：
Before:一般情况下，如果我们想使用 es-lint, 会先通过 npm install es-lint, 然后在项目根目录执行 ./node_modules/.bin/es-lint your_file.js 或者通过 package.json 的 npm scripts 调用 eslint。
After:npx es-lint your_file.js
原理：npx 在运行时会自动去 ./node_moudles/.bin 和环境变量寻找命令

是否提交 lock.json 到代码仓库

前面我们提到 yarn 带来了 .lock 文件的机制，使得在任何环境下执行 install，都能得到一致的 node_modules 安装结果。但是是否需要提交 lockfiles(package-lock.json/yarn.lock) 到代码仓库呢？
npm 官方文档 ^[2]是建议把 package-lock.json 文件提交到代码仓库的。在多人协作的项目中，这样做确实没有问题。但是如果开发的是库，在 npm publish 的时候最好忽略 lockfiles。因为库一般是被其他项目依赖的，在不使用 lockfiles 的情况下，由于新版 npm 和 yarn 的 hoist 机制，可以复用住项目已经加载过的包，减少依赖重复和体积。
但是存在这样一种现象：即使在一些发布时忽略 lockfiles 的库中，在主项目顶层存在相关依赖包的前提下，最终生成的 lockfile 仍然没复用主项目的包。这是为什么呢？原因是库的依赖包版本和主项目存在的依赖包版本不一致。具体看下图：主项目的 yarn.lock 中显示 browser 这个包依赖了 @babel/runtime@7.0.0

主项目 node_modules 顶层的 @babel/runtime 版本为 7.10.1

知道了原因，那么如何减少库项目的依赖项呢。到这里，解决方案也就呼之欲出了：

库项目尽量使用和主项目版本一致的依赖包
在库项目 package.json 的 “peerDevpendencies” 字段中声明主项目已有的依赖包

合入其他分支代码后编译报错

相信很多同学都遇到过和我一样的问题：当自己的 feat 分支代码合入 master 或者业务班车分支的代码时，重新 yarn 时，有时候会编译失败，报大量 "can't resolve module xxx"的错误。这种错误有很多情况是依赖版本不一致的问题，但是又极其难以定位，令人头痛。那么此时有另外一个思路，那就是从 master 拉一个最新的分支再进行合入。
但更好的解决方式是：建议在日常开发过程中，定时合入 master 代码，一方面可以合入最新的 feat，另一方面可以避免长时间不合入，最后在上线阶段合入代码，可能出现大量冲突，解决不当或遗漏而造成的编译问题。同时也可以考虑将工具升级为 pnpm，以解决潜在的“幽灵依赖”和“依赖嵌套”问题，同时带来性能上的提升。

参考资料

[1]

pnpm: 最先进的包管理工具: https://bytedance.feishu.cn/docs/doccngSUrvF0qPVmBE1rq1iPZQf

[2]

npm官方文档: https://docs.npmjs.com/cli/v7/configuring-npm/package-lock-json

git分支的管理流程

Fri, 27 May 2022 17:25:47 CST

theme: fancy

持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第2天，点击查看活动详情

现在大部分公司都是使用git来管理代码的，我今天分享一下我们司后端代码的git管理流程吧。

分支说明

分支名称	对应环境
develop	研发服务器
test	测试服务器
master	生产服务器
feature	本地服务器
masterBugFix	本地服务器
testBugFix	本地服务器

正常版本迭代流程

开发阶段

先拉取最新的develop分支的代码。
确保develop上一个版本的代码已经合并到test分支了。
基于develop分支创建自己的功能开发分支。
功能分支的命名方式：feature/人名/功能名/版本号。

测试阶段

功能开发完毕，可以先rebase一下develop分支，然后把功能分支的代码合并到develop分支。
在研发服务器上自测通过后就可以把develop分支代码合并到test分支。然后代码提测。

3.测试bug修复阶段

先拉取最新的test分支代码。
基于test分支创建测试bug修复分支testBugFix,bug修复完成后进行代码合并。testBugfix->test->develop。

4、版本上线阶段

测试通过后，test分支的代码合并到master分支，打下tag。然后就可以上线了。

正式服bug修复流程

先拉取最新的master分支代码。
基于master分支创建正式服bug修复分支masterBugFix。
正式服bug修复完成后，把代码合并到master分支，然后把master分支代码上传到测试服测试。测试不通过则继续在masterBugFix分支进行代码修改，直到测试通过。
bug修复完成之后进行代码合并，master->test->develop。

以上就是我要介绍的流程了，其实流程并没有规定一定要怎么样的，要根据自己公司的开发流程来制定就好，我所介绍的这套流程也未必适合你们使用。我的这套流程其实也是存在问题的，正式服bug修复流程中，当bug修改完提测后，本来测试服中正在测试的工作就只能停止，因为代码已经被覆盖了，要等正式服bug修复完成后再把测试服的代码恢复为test分支的代码才能继续做测试工作。所以没有流程是完美的，适合自己使用的就是好的。既然有缺陷，那就用一些规范来防止这些缺陷给我们造成不必要的麻烦，所以针对流程还必须要有相应的规范来进行约束，这样才是好的流程。

谢谢观看！

streetlamp 敬上！

苹果通过远程管理中国组装厂的工作

Wed, 11 May 2022 20:56:08 CST

苹果曾经平均每天预订 50 个往返旧金山和上海浦东机场的商务舱座位。但在 2020 年初新冠疫情暴发后，苹果叫停了派遣大批工程师的行动。那一年新 iPhone 机型的推出比往年晚了一两个月。为了应对这一情况，苹果采用了远程管理制造流程的技术。2020 年苹果美国工程团队通过视频电话指导亚洲工厂的中国同事组装 iPhone 原型机。在中国的工程师最初一切都按美国工程师的指挥行事，但渐渐地，驻华工程师被赋予了更大权力，可以自行解决问题。

目标管理体系：OKR

Fri, 29 Apr 2022 10:10:51 CST

最早接触OKR是在2014的时候，当时听了豌豆荚丁吉昌的《我们在豌豆荚如何做产品研发》分享了解的。当时听了感觉的收益良多，但在实践时却遇到了很多困难。其中最大的难度是公司当时每月都有严格的KPI考核制度，OKR虽然说是和个人绩效没有关系，但在执行的时候却发现关联脱离不了关系，越到后面越觉得只是表面上改了个名而已。总觉得需要再深入学习一遍。

什么是OKR？

OKR体系的全称是 Objectives & Key Results，即目标与关键成果。所谓OKR，O = Objective 可以理解为企业目标，KR ＝Key Results 可以理解为关键结果。浓缩在一起就是“为确保达成企业目标的关键结果分解与实施”。

OKR的发展历史

1968年，安迪格罗夫在英特尔发明了OKR这套目标管理办法；
1974年，约翰杜尔加入了英特尔，跟安迪·格罗夫学习了OKR并身体力行的践行着OKR的实施原则；
1999年，在Google成立不到一年的时候，约翰杜尔投资了他们，并向他们的领导层提出OKR的概念。虽然它的创始人谢尔盖·布林和拉里·佩奇拥有强大的创业能量和雄心勃勃的愿景，但他们没有实现这一目标的管理技术，正是OKR让Google实现了100亿美元收入的雄心勃勃的目标；
2017年，约翰杜尔发表了他的《Measure What Matters》，并将这一管理智慧，分享给50多家公司和机构。

OKR VS KPI VS MBO

彼得·德鲁克在上世纪60年代提出了 目标管理法(Management by Objectives，MBO)的思想，MBO的原理很简单，它基于两个基本原则：

不要告诉下属具体怎么做，只要告诉他们你要什么，他们就会给你满意的结果
用关键结果衡量工作绩效，即如果基础的商业问题没有解决，不论实现多少产品功能，团队整体的绩效一定会大打折扣。

第一个原则是在说如何调动团队的积极性，第二个原则是在讲怎样评估工作绩效。

此后80年代 SMART原则(Specific、Measurable、Achievable、Relevant、Time-bound) 和 关键绩效指标（Key Performance Indicators，KPI） 开始流行起来。KPI把对绩效的评估简化为对几个关键指标的考核，将关键指标当作评估标准，把员工的绩效与关键指标作出比较地评估方法，在一定程度上可以说是目标管理法与帕累托定律的有效结合。关键指标必须符合SMART原则：具体性（Specific）、衡量性(Measurable)、可达性(Attainable)、现实性(Realistic)、时限性(Time-based)。

后来英特尔公司把结合了前面的多种理论，发展成为OKR，OKR能适度弥补过度强调目标管理和KPI，导致悖离公司愿景的缺陷。1999年John Doerr把OKR引入Google。

一句话概括三者之间的差别：MBO目标管理是「主管和员工都想做的事」，KPI是「主管要员工做的事」，OKR则是「我自己想做的事」

OKR与KPI的区别

OKR表示Objectives and Key Results，即目标和关键成果，是一套定义和跟踪目标及其完成情况的管理工具和方法。KPI表示Key Performance Indicators，即关键绩效指标，是一种可量化的、被事先认可的、用来反映组织目标实现程度的重要指标体系，也是企业绩效管理过程中一个实用而且有效的工具，更是绩效管理实现过程中的一个重要内容。KPI的本质是一种管理工具，它主要是从结果上来考察绩效，不关注过程，一切用指标来说话。

OKR 主要的目的是为了更有效率的完成目标任务，并且依据项目进展来考核的一种方法。它的主要流程是这样的一个循环。

明确项目目标。
对关键性结果进行可量化的定义，并且明确达成目标的/未完成目标的措施。
共同努力达成目标。
根据项目进展进行评估。

而对于国内来说，更熟悉的其实是 KPI (Key Performance Indicator)，而 KPI 的流程则是这样的：

进行人事组织。
确定影响结果的关键性因素，并且确立 KPI 。
对关键绩效指标进行检测，并且进行实时监督。
对有错误行为的人进行监督，更甚者开除。

通过两者的对比我们能够看到，OKR 主要强调的是对于项目的推进，而 KPI 主要强调的是对人事的高效组织，前者要求的是如何更有效率的完成一个有野心的项目，而后者则强调的是如何保质保量的完成预定目标。OKR相对于KPI而言，不是一个考核工具，而是一个更具有指导性的工具，说白了，是一个PLAN-DO-REVIEW的cycle。他存在的主要目的不是考核某个团队或者员工，而是时刻提醒每一个人当前的任务是什么。每个人都有自己的OKR，每个团队有团队的OKR，无论级别高低，团队大小，都需要制订和服从OKR。这个OKR在每个季度结束之后要做一个评分。评分高低并不直接决定一个员工的晋升和待遇，而更多的是提醒员工，这个季度工作完成的怎么样，未完成的工作为什么没有完成，下一阶段的工作重心是什么。

KPI 理论上是必须严格按照 SMART 标准制订的，是否达到甚至达到比例多少（小于 100% 还是大于 100%）都是要能测量的。但这就导致一个问题，有些事情值得去做，但在做出来一部分之前无法测量因此无法制订目标，这时候就陷入了先有鸡还是先有蛋的问题了。KPI 还有一个更严重的问题，那就是为了完成可测量的目标，有可能实际执行手段与该目标要达到的愿景正好相反。举个例子来说，我们希望用户更喜欢使用我们的产品，因为喜欢无法测量，所以把 PV 写进了 KPI 里面。但在实际执行过程中，我们可以把用户原本在一个页面上就能完成的事情分到几个页面上来完成，结果 PV 达到了 KPI 指定的目标，但用户其实更讨厌我们的产品了。大家如此应付 KPI 是因为 KPI 跟绩效考核挂钩。如果 KPI 达不到那就会影响奖金，所以就算违背公司利益，违背用户利益，也要把自己的 KPI 完成了，把部门的 KPI 完成了。

KPI存在的缺陷：

没有人对最终结果负责，每个人只对自己的过程负责。
人的主观能动性被压抑。
结果高度依赖机器和管理者的指令。

OKR 解决了 KPI 的这些缺陷。首先它和绩效考核分离，把绩效考核交给 peer review（相当于360 度评价）来做。然后它强调 Key Result 必须服从 Objective，所以如果你在 Objective 上写了要让用户喜欢我们的产品，但你实际执行 Key Result 的手段违反了这一点的话，谁都能看得出来。既然 Key Result 只是用来服务于 Objective 的，那就没必要像 KPI 那样一早制订好然后强制执行了。你可以在做的过程中随意更改 Key Result，只要它们还是服务于原本的 Objective 就行。

OKR 最重要的作用就是帮助你stay focus，stay focus又能帮助你make impact。总的来说，绩效考核的核心都是 impact（Google的impact文化。衡量的是员工为Google做出了多大的impact，而不是员工是不是很努力地干了很多活，也不是员工是不是听老板的话完成了老板布置的任务。），而测量的手段都是 peer review。其实在没有 OKR 的情况下，这套绩效考核机制还是完全能操作的，但参与者就可以因为缺乏引导而没办法实现他们能实现的最大 impact。OKR 就是让你在每个季度开始之前想一想，有哪些事情从 impact 的角度来说是值得做的，有哪些事情是你想做的，然后取个交集，再列举若干有一定概率（通常建议是 2/3）能达成目标的手段。除了 make impact，OKR 还能用来引导你 stay focus 在别的事情上。

OKR 可以取代 KPI 吗？

请你来思考这样一个问题：OKR 是目标管理工具，KPI 是绩效管理工具，那么管理中所用的“目标”是“绩效”吗？

目标包括绩效，但不局限于绩效，也就是说，OKR 中可以允许添加与绩效相关的内容，但需要注意的是，一定不要将绩效与考核挂钩，更不要与奖金或薪资挂钩。

OKR 的出现不是为了取代 KPI，而且预测未来很长一段时间内 KPI 都会一直存在。

OKR 与 KPI 如何结合使用？

OKR 关注的是结果和过程，更关注过程，而 KPI 关注的只是结果，OKR 与 KPI 有效结合，才能实现“1+1>2”的价值。

只有以“一对一”这样的形式才能建立更好的沟通。

KPI 中包括的绩效指标一定是只看结果，而不看过程的，只要结果达到了就行，而 OKR 需要更多地关心过程，从结果中判断目标的具体达成情况。

OKR的作用

聚焦：对优先事项的聚焦和承诺

做正确的事，远比正确做事更重要。每个成员都朝着一个方向使劲，形成合力。

聚焦重要的工作，同时清楚什么是不重要的。
OKR是一种精准沟通的工具，能消除困惑，让我们进一步明确目标，聚焦到关键的成功要素上。

OKR 恰恰能够解决短期目标的实现问题，让目标更加聚焦，让行动脚踏实地，通过完成 KR 从而实现 O，这也正是 OKR 的基本原理。

为了让目标更加聚焦，因此在制定 O 的时候就需要考虑“做减法”，不要贪多求广，在资源有限的前提下，我们只有集中优势“兵力”，才能逐个歼灭“敌人”。

聚焦目标有什么用处？也许西蒙·斯涅克的黄金圈法则可以一定程度说明这个问题：

What – 做什么：这个无需多言，每个人都知道自己正在做着什么。
How – 怎么做：你的个人努力、才智、经验，以及可利用的资源，简而言之，比别人优秀之处。
Why – 为什么做：会考虑这件事的人少之又少。在这里，为了赚钱不算是「Why」，因为金钱数额只是一个结果。真正的「Why」是：你早上为了什么从床上爬起？你怀着什么样的信念？你凭什么得到他人的关注？

通常，我们交流、行动、思考的方式都是从外向内的，从清晰开始，然后逐渐模糊。但 OKR 的魔力在于，它的逻辑恰是由内向外的。

举个例子，一般公司的推销逻辑是：What → How → Why，而苹果的则是：Why → How → What。

事实证明，人们买的不是产品，而是你的信念。同理，我们用 OKR 指导个人工作学习时，也不是为了 What 而完成某件事，而是为了 Why ——先明确一个信念，然后让自己的步伐始终正确、坚定向它迈进。

具体来说，OKR 的力量在于：

清晰战略。OKR 工作法是结果导向，强调把时间和精力聚焦在最重要的任务上，所以它能够呈现出最需要被关注的任务/问题。
提供持续稳定动力。也正因如此，该方法尽可能地避免了目标和优先级不清晰引起的思路混乱，以及随之而来的消极怠工，提供了完成目标所需的动力和热情。
完成复杂项目。清单是一个常见且简单的思维工具，能够有效清点各项事务。但它在复杂的项目中的作用会大打折扣，因为清单不能帮助你战略性地分辨优先级，也不能结构化地添加可执行细则。而这些，正是 OKR 的强项。
整合其他任务。支线任务。需要注意的是，OKR和清单在日常中的应用并不互斥，而是相互补充——OKR 是你目前在做的主要项目，每天当然也会遇到各种与主线不相关的支线任务，这些杂事则用清单记录。重要任务。在重要和紧急的任务中，优先级最高的永远是那些紧急的任务，因为我们对于时间的压力更加敏感。但这也意味着，如果没有一个科学的规划，那么重要的任务将会无限期地被滞后下去。所以，除了复杂项目，对于那些重要不紧急任务，设置 OKR 也是非常必要的，例如学习一样乐器，或通过一门高难度考试——将这些需要持之以恒才能完成的任务，有机地拆解融合在日常生活中。

协同：团队工作的协调和联系

OKR对每个成员透明，个人与组织目标一致，相互协作。

OKR具有透明性，上自首席执行官，下至一般员工，每个人的目标都是公开的。
每个员工都将个人目标与公司计划紧密联系起来，进而明确两者之间的依赖关系，并与其他团队展开通力协作。
这种自下而上的协同，将个人贡献与组织成功联系起来，为工作赋予了特定的意义。
自下而上的OKR，则通过加深员工的主人翁意识，促进了个人的参与和创新。

《孙子兵法》云“上下同欲者胜”。制定 OKR 时，需要“自顶向下”沟通，还需要“自底向上”对齐，让下级更加充分地理解上级的目标及其意图。

上级：需要根据自己的经验，对团队价值进行全局性思考，才能制定出合理的目标。
下级：需要根据自身岗位特征和个人成长诉求，从思想和行动上充分支撑上级所制定的目标。

只有大家朝着同一个方向使劲，最终才能实现公司的组织目标，从而使得全员共同推动企业战略目标的达成，这才是 OKR 的最大价值。

我们在制定目标时，要尽可能与上级目标保持对齐，而不是完全对齐。

挑战：充分延展进而挑战不可能

允许失败，不作为考核依据，挑战更多“不可能”，释放出无限创造力。

OKR激励我们不断超越之前设定的各种可能，甚至超出我们想象力。
通过挑战极限和允许失败，OKR能够促使我们释放出最具创造力的雄心和自我。

除了金钱等物质激励以外，最有效的激励方式莫过于“成长”和“认可”，而且精神激励往往比物质激励产生的激励效果更持久。

埃德温·洛克被誉为结构化目标设定理论之父，他对目标的难易程度与实现程度之间的关系进行了大量实验和实证研究。尽管研究的范围和领域很广泛，但研究结果却出奇一致。洛克写道：“目标设定越具有挑战性，所产生的结果越佳。虽然高难度的目标与其产出结果之间的差距，通常会大于低难度目标与其产出结果之间的差距，但是前者达到的最终结果仍然比后者要好。 ”研究结果显示，设定具有挑战性目标的员工，不仅会取得更好的绩效，还会提高自我驱动力，以及对工作的投入程度。洛克指出：“设定明确而有挑战性的目标不仅可以提高工作的趣味性，同时也可以帮助人们体会到工作带来的愉悦感。 ”

如何实施OKR？

在企业中推广 OKR，最好不要请 HR 去“主导”这件事情。

在企业中推广 OKR 时，请务必记住以下三点：

一定不要强制性地去推广 OKR，更不要在大家概念不一致的情况下就大规模推广 OKR。
当大家对 OKR 理解不一致时，一定要请外部 OKR 专家到企业内部做 OKR 培训，才能快速建立共识。
要充分发挥你的领导力去影响身边的人，让高管们对 OKR 表示认同，让团队成员们尝到 OKR 的甜头，这才是我们作为领导者需要去做的事情。

OKR理念推广

明确OKR在整个组织目标体系中所处的位置

如果不能区分目标层次，在定目标的时候容易把不同颗粒度的目标混淆在一起造成思维上模糊，需要反复审视才能梳理出清晰的目标结构体系。

Mission是企业存在的理由，带给顾客的价值
Strategy是企业近期要往哪个方向走
Objective是承接战略落地的当期目标
Key Result是目标达成的关键结果(里程碑)
Key Action是支撑关键结果达成的具体动作

Mission -> Vision -> Strategy -> Objectives -> Key Results

一个企业，从使命、愿景，到战略拆解，最后到 OKR 执行。以终为始，层层递进，从诗和远方到眼前的苟且，确保我们始终在做最重要的事。

普及OKR 四个强大理念：

OKR的推广一定要从理念松土开始。首先取得一把手的认可和支持，然后对主管团队进行理念宣传，最后才是全员培训。只有当团队成员都理解并认可OKR的理念，后续推行才会获得配合支持。对OKR理念不理解或不认可的团队容易走形式。经过3轮主管团队、2轮全体员工的培训和研讨，OKR四个核心理念逐渐被大家所接受。每个理念的首字母刚好组成FAST。

Focus。聚焦最重要的目标。写下对组织和个人最有价值的事，避免瞎忙，把时间精力浪费在非战略机会点上。
Align。目标拉通对齐。组织自上而下给出战略指引，员工自下而上进行研讨承接战略目标，赋予员工自主性。
Stretch。自我挑战攻坚克难。通过自设挑战型目标，牵引组织和个人突破当前的能力限制，持续提升能力。
Track。及时跟踪刷新进展。缺乏及时的进展跟踪，目标慢慢地变得无关紧要。目标一定要有数字、可衡量。

普及好的O和KR应该符合高标准

好的Objective应该做到：

聚焦高价值。当期OKR不建议超过5个，多了容易失焦。聚焦高价值，而不是常规工作。
简洁清楚。用一句话简介清楚的描述你的目标。一句话描述不清楚通常是因为没想清楚。
振奋人心。挑战性目标的描述能够引起内心的共鸣，从而激发力量。不被认可的目标没有力量。
方向明确。目标不能太抽象，也不能含混不清，要让每个人都能看得懂。
目标对齐。下级要对齐上级的目标，即向上对齐，平级还要相互对齐，即水平对齐。

好的Key Result应该做到：

有数字可衡量。衡量Key Result达成的标准必须非常清晰，可以量化，支撑每周、每月的进展追踪。
足够挑战。核心指标的设置(如收入/销量/份额/知名度/推荐度等)必须足够挑战。完成信心50%时最佳。
足够充分。理论上所有Key Result达成后，必然导致总目标的达成。否则就说明你的Key Result不够充分。
不是任务：关键结果需要对目标产生直接影响，它不是日常任务，也不是行动计划。

一个 OKR 可以包含多个 O，每个 O 又可以包含多个 KR。O 就不应该设置太多，最多不要超过 3 个。每个 O 所包含的 KR 也无需太多，最多也不要超过 3 个。

输出团队OKR推行四步方法论

OKR的推行是深刻的组织协作方式的变革，除了做好理念布道外，还要给出清晰的方法论和步骤。寻找变革后的利益相关方进行试点打样，是比较稳妥的方式。我找到两个团队打样。一个是国家主管团队，一个是运营商销售团队。两个团队主管都非常认可OKR理念，都急于重新激活团队成员主动性，给与了高度配合。通过前后８轮的小组研讨，我们梳理出一个相对高效的团队OKR制定步骤和配套工具模板，分四步走。

组织战略解码。输入：组织给出战略指引。输出：各团队成员根据组织战略结合自身情况提出团队OKR建议。教训: 这是关键的第一步。前面几轮目标研讨并不高效，几个小时的零散讨论容易失焦，讨论没有边界。要先给出明确的组织战略方向作为指引。
团队目标众筹。输入：在白板上审视所有成员OKR提议。输出：全体成员经过讨论争辩，去重添漏，输出高标准的团队OKR，与上级目标拉通对齐。教训: 这是最耗时的一步。保证讨论质量要分两步走，先讨论哪些O有价值，再讨论需要哪些KR以及如何衡量。讨论工具建议用白板，容易擦写编辑，用表格容易框死思路。
个人目标录入。输入：团队OKR指引。输出：队员根据团队OKR指引制定个人OKR，与主管目标对齐后录入OKR系统。教训: 这是被低估的一步。没有IT系统的支撑，OKR透明围观和敏捷调整的特性很难发挥出来。除了PC端，还要加强对手机端的使用培训。
及时跟踪进展。输入：团队成员定期刷新OKR进展。输出：团队主管及时给与反馈和指导。教训: 这是最重要的一步。前面三步是制定目标，这一步是从目标到执行的关键。月度OKR进展审视会要开起来，让团队成员和主管养成每周每月推动OKR进展的习惯。

OKR的实施步骤

确定目标

目标来源于对业务战略或工作计划的分解，同时，也是确定关键成果的唯一依据。知道要去哪里的人，往往会更加清楚如何到达目的地。

确定目标时需要满足如下要求:

目标明确且具有挑战性：目标要有野心，并非百分之百能够完成目标，让员工走出能力“舒适区”，最好达到能力挑战区。
兼顾自上而下与自下而上：设定的方式总体而言是自上而下，同时鼓励员工自主发起目标比与直接上级进行讨论。
简洁、聚焦：每人每个季度目标不超过5个，强调对目标的筛选和重要性的把握，将有限的资源聚焦在最重要的事情上。
公开透明：任何层级的OKR在全公司内公开透明，保证从组织到个人目标的一致性且互不重叠。

好的目标	不好的目标
拿下南湾地区的咖啡直销零售市场	销售额提升30%。
推出一个很棒的最小化可行产品（MVP）	用户增加一倍。
改变帕洛阿尔托地区的优惠券使用习惯！	B系列产品收入增加到500万美元
完成一轮融资。	…

为什么这些是不太好的目标？因为它们实质上是关键结果。

心理学教授埃德温·洛克指出，「困难目标」往往比简单目标更能有效提升绩效。所以这个目标（ O ）更多的是指示了一种方向，不必追求必须完成，而是尽可能冲向它

制定关键结果

关键结果应该是明确的、具体的、可衡量的，产出和投入的组合（匹配）对其有所帮助。每个目标的关键结果都不要超过5个，完成所有关键结果的关键和前提是实现目标，如果目标没有实现，那就不是OKR了。

确定关键结果需要满足的条件：

必须可量化：设定可量化的关键结果能够准确衡量其完成情况，避免人浮于事。
直接性：每个KR必须是能够直接完成的，不能是间接完成，更不能通过其他协助来完成。
数量精简：每一个O分解出的KRs不超过5个，避免分散精力。
周期内灵活调整： O一旦确定一般不可改变，但KRs在一个周期内可以酌情及时调整。

追踪成果

不是年末或者整个OKR结束以后才进行结果评估，而是在整个过程中随时的追踪，在这期间，如果发现环境有变化或者某些关键结果亮起了红灯，就需要及时调整方向和资源投入。

我们需要一个新的人力资源模式来适应新的工作环境。这一模式就是持续性绩效管理体系，用于取代当前的年度评估体系。持续性绩效管理是通过一种叫作 CFR（Conversation，Feedback，Recognition）的管理工具来实现的：

对话（Conversation）：经理与员工之间真实的、高质量的交流，旨在对绩效提升起到驱动作用。
反馈（Feedback）：同事之间面对面进行双向沟通或通过网络进行交流，以评估工作进展情况并探讨未来的改进方向。
认可（Recognition）：根据个体所做贡献的大小施以对等的表彰。

和OKR一样，CFR在组织的各层级都强调透明、问责、授权和团队合作。CFR是有效沟通的“刺激物”，它能激发OKR，并将其送入正确的轨道。CFR是一个完整的交付系统，用于衡量什么才是最重要的事情，让绩效管理“直击要害”。CFR完全体现了安迪·格鲁夫创新方法的精髓和力量，也使得OKR更加人性化。

四象限看板

《OKR工作法》介绍了利用四象限图进行OKR跟踪，以周级别进行本周的回顾，掌握 “承担责任-庆祝成果” 的节奏

每周一，团队一起开会盘点 OKR，来明确本周具体负责完成哪些任务。
每周五，召开“胜利会议”，让每个团队都可以展示本周的工作成果，并准备一些酒水饮料和点心等庆祝这些成果。

第一象限-OKR当前状态：展示目标总进度和关键成果总进度。第一象限的作用是辅助团队重新明确OKR，以及盘点当前关键结果，调整关键结果信心指数。
第二象限-本周关注的任务：列出本周3~4件最重要、只有完成才能推进目标的任务，确定这几件任务的优先级。
第三象限-未来四周的计划：规划近期需要准备或支持的事项。当第二象限的事项发生变化时，第三象限的工作任务也要及时调整。
第四象限-其他状态目标：关键成果当前进展, 直观反应KR上出现的一系列问题，方便及时跟进排除。

关键结果后面的百分数是OKR的信心指数，它是一种自我预估的自信心度量，描述实现KR的信心。在项目推进过程中，根据进展情况，需要不断的调整这个信心指数。

总结评分

给一个目标结果打分最简单、最明确的方法是通过计算其相关关键结果的百分比完成率。谷歌使用0~1.0分作为计量标准，也就是说的交通灯打分法：

7~1.0分=绿色（0.7以上则代表完成目标，但是如果是1分，那么需要注意是否目标不够挑战，在下个周期需要加大挑战性；）
4~0.6分=黄色（取得了进步，但是并未完成目标）
0~0.3分=红色（并未取得进步，也没有完成目标，或者是目标挑战性太强，需要分析找出原因。）

比如我们完成了5个指标中的4个，基准得分为0.8，在绿色区域。

KR的达成要与个人的绩效考核脱钩。

承诺型 OKR

预计团队将重新安排他们的其他优先事项，以确保按计划交付0。
无法可信地承诺 OKR 上交付0 的团队必须迅速升级。这是一个关键点：在这种（常见）情况下升级不仅可以，而且是必需的。无论问题是由于对 OKR 的分歧、对其优先级的分歧，还是无法分配足够的时间/人员/资源，升级都是好的。它允许团队的管理层制定选项并解决冲突。

推论：每一个新的 OKR 都可能涉及一定程度的升级，因为它需要改变现有的优先事项和承诺。不需要更改任何团队活动的 OKR 是一种一切照旧的 OKR，它们不太可能是新的——尽管它们之前可能没有被记录下来。

在到期日之前未能达到0 的承诺 OKR 需要进行事后分析。这不是为了惩罚团队。它旨在了解在 OKR 的计划和/或执行过程中发生了什么，以便团队可以提高他们在承诺的 OKR 上可靠地达到 1.0 的能力。
承诺 OKR 类别的示例是确保服务满足本季度的 SLA（服务水平协议）；或在设定日期前为基础设施系统提供定义的功能或改进；或以某个成本点制造和交付一定数量的服务器。

抱负型 OKR

一组有抱负的 OKR 将在设计上超出团队在给定季度的执行能力。OKR 的优先级应告知团队成员在完成团队承诺后将剩余时间花在哪里的决定。一般来说，优先级较高的 OKR 应该在优先级较低的 OKR 之前完成。
理想的 OKR 及其相关的优先事项应保留在团队的 OKR 列表中，直到它们完成，并在必要时逐个季度进行。由于缺乏进展而将它们从 OKR 列表中删除是一个错误，因为它掩盖了优先级、资源可用性或对问题/解决方案缺乏理解等持续存在的问题。

推论：如果该团队拥有比当前 OKR 所有者更有效地完成 OKR 的专业知识和能力，那么将一个有抱负的 OKR 移到另一个团队的列表中是件好事。

团队经理应该评估完成他们理想的 OKR 所需的资源，并每季度提出要求，履行他们向企业表达已知需求的职责。然而，管理者不应期望获得所有必需的资源。

OKR落地前准备

落地 OKR，你最需要的是什么？你最需要的是一片适宜 OKR 的土壤，这片土壤在公司层面上来理解，就是“团队文化”。

面对沟通时，是否公开透明？
面对交付时，是否信守承诺？
面对压力时，是否勇于挑战？

团队文化是落地 OKR 的先决条件，你打算在团队中落地 OKR，就一定要逐步建立起公开透明、信守承诺和勇于挑战的团队文化。

你的团队也需要内驱力，只有将团队文化和内驱力二者相互结合，OKR 才能顺利落地。

团队内驱力不强，可以用 OKR 吗？内驱力较强的团队非常适合用 OKR，但并非内驱力不强的团队就不适合使用 OKR。内驱力不强的团队更需要用 OKR 来打造团队文化，从而进一步加速提升团队内驱力。OKR 是领导与员工建立信任的纽带。既然可以通过 OKR 提升团队内驱力，那么也应该可以通过 OKR 去打造团队文化。

在对齐 OKR 时，上级的 KR 是下级的 O 吗？

主目标和子目标之间是相对的，子目标需要向上对齐主目标。换句话说，子目标对主目标有直接支撑作用，或者说，子目标完成后，能推动主目标的完成进度。

子目标并不是下级的 KR，而是下级的 O。不要将上级的 KR 变成下级的 O，这样会降低 OKR 系统的稳定性。

OKR 所提倡的“对齐”指的是在 O 上做“支撑”，下级需要支撑上级的 O，平级之间的 O 也要考虑相互支撑，然而 KR 只是为了支撑所对应的 O。

我们在制定自己的子目标时，需要充分理解上级制定的主目标，将子目标中的 O 与主目标中的 O 进行对齐，这是“向上对齐”；此外，还要考虑横向将自己制定的 O 与同级部门制定的 O 对齐，这是“水平对齐”。

对齐一定是 O 与 O 之间的支撑关系，与 KR 没有任何直接关系。

附一：Google OKR最佳实践

编写有效的 OKR

做得不好/管理不善的 OKR 是在浪费时间，是一种空洞的管理姿态。做得好的 OKR 是一种激励管理工具，可帮助团队明确在日常工作中什么是重要的，什么要优化，以及要做出什么权衡。编写好的 OKR 并不容易，但也并非不可能。请注意以下简单规则：

目标是“Whats”

表达目标和意图；
积极但现实；
必须是有形的、客观的和明确的；对于一个理性的观察者来说，目标是否已经实现应该是显而易见的。
成功实现目标必须为 Google 提供明确的价值。

关键结果是“How”

表达可衡量的里程碑，如果实现，将以对他们的选民有用的方式推进目标；
必须描述结果，而不是活动。如果您的 KR 包含“咨询”、“帮助”、“分析”或“参与”等词，则它们描述的是活动。相反，您需要描述这些活动的最终使用影响：“在 3 月 7 日前发布来自六个 Colossus 单元的平均和尾部延迟测量值”，而不是“评估 Colossus 延迟”；
必须包括完成的证据。这些证据必须可用、可信且易于发现。证据示例包括更改列表、文档链接、注释和已发布的指标报告。

跨团队 OKR

Google 的许多重要项目都需要来自不同群体的贡献。OKR 非常适合致力于这种协调。跨团队的 OKR 应该包括所有必须实质性参与 OKR 的群体，并且承诺每个群体的贡献的 OKR 应该明确出现在每个此类群体的 OKR 中。例如，如果广告开发和广告 SRE 和网络部署必须交付以支持新的广告服务，那么所有三个团队都应该有 OKR，描述他们交付项目部分的承诺。

承诺与理想的 OKR

OKR 有两种变体，区分它们很重要：

承诺是我们同意将实现的 OKR，我们将愿意调整时间表和资源以确保它们得以交付。承诺的 OKR 的预期得分为0；低于 1.0 的分数需要解释，因为它表明计划和/或执行中存在错误。
相比之下，有抱负的 OKR 表达了我们希望世界的样子，即使我们不清楚如何到达那里和/或交付 OKR 所需的资源。理想型 OKR 的预期平均得分为7，方差很大。

经典的 OKR 写作错误和陷阱

陷阱 #1：未能区分承诺的和有抱负的 OKR

将承诺的 OKR 标记为有抱负会但增加失败的机会。团队可能不会认真对待它，也可能不会改变他们的其他优先事项以专注于交付 OKR。
另一方面，无法实现 OKR 目标将在团队中产生防御性。

陷阱 #2：一切照旧的 OKR

OKR 通常主要基于团队认为在不改变他们目前正在做的任何事情的情况下可以实现的目标，而不是团队或其客户真正想要的。

陷阱 #3：胆怯的 OKR

有抱负的 OKR 通常从当前状态开始，并有效地问：“如果我们有额外的员工并且有点幸运，我们能做什么？”，另一种更好的方法是这样开始：“如果我们摆脱了大多数限制，几年后我（或我的客户）的世界会是什么样子？”。根据定义，当首次制定 OKR 时，您不会知道如何达到这种状态——这就是为什么它是一个有抱负的 OKR。但是，如果不了解和阐明所需的最终状态，您就无法保证您将无法实现它。
试金石：如果您问客户他们真正想要什么，您的理想目标是否达到或超过了他们的要求？

陷阱 #4：故意降低表现

一个团队承诺的 OKR 应该消耗大部分但不是全部可用资源。他们承诺的 + 有抱负的 OKR 消耗的资源应该比他们的可用资源多一些。（否则他们实际上是在提交。）
无需团队的所有人数/资本即可满足所有 OKR 的团队。.. 假设要么囤积资源，要么不推动他们的团队，或两者兼而有之。这是高级管理层将员工人数和其他资源重新分配给能够
更有效利用它们的团队的提示。

陷阱 #5：低价值目标（又名“谁在乎？”OKR）。

OKR 必须承诺明确的业务价值——否则，没有理由花费资源来做这些。低价值目标 (LVO) 是指即使目标以 1.0 完成，也没有人会注意到或关心的目标。

一个经典（且诱人）的 LVO 示例：“将任务 CPU 利用率提高 3%。”此目标本身并不能直接帮助用户或 Google。然而，（可能相关的）目标是“在不改变质量/延迟的情况下将服务峰值查询所需的核心数量减少 3%。. . 并将由此产生的多余内核返回到免费池中”具有明显的经济价值。这是一个更高的目标。
这是一个试金石：OKR 能否在不提供直接最终用户或经济利益的情况下在合理情况下获得0？如果是这样，那么需要重新编写 OKR 。”

陷阱 #6：KR 不足以实现 O。

OKR 分为预期结果（目标）和实现该结果所需的可衡量步骤（关键结果）。编写 KR 时，所有关键结果的得分为0，目标得分为 1.0，这一点至关重要。
一个常见的错误是编写必要但不足以完成目标的关键结果。这个错误很诱人，因为它让团队避免与“硬”关键结果所需的困难（资源/优先级/风险）正面交锋。
这个陷阱特别有害，因为它会延迟发现实现目标需要的资源，导致目标无法按计划完成。
试金石：是否有可能在所有关键结果上都得0 分，但仍然没有达到目标的意图？如果是这样，添加或重新处理关键结果，直到它们成功完成才能保证目标也成功完成。

附二、豌豆荚的高效研发体系

选方向（立项–定方向）

愿景：一句话表达清楚要做什么；
分析市场机会和趋势，决定当前策略；
确定目标用户的特征和核心需求；
现存的解决方案和各自的优劣势；
该项目对公司的利益点；如果不做该项目，哪些竞争对手会做，对竞争对手的利益点；
需要哪些技术的支持和驱动，哪些技术是公司的弱项；
项目的紧急程度，是否需要快速推进；
发布策略；
核心衡量指标，用来衡量成功的指标。

定目标（OKR 体系–定目标）

OKR 体系（Objectives& Key Results，目标与关键成果）

OKR 首先是沟通工具。公司共有 300 多人，每个人都要写 OKR。为了便于沟通，所有这些OKR都会放在一个文档里。任何员工都可以看到 CEO 的这个季度最重要的目标是什么，HR 团队这个季度的目标是什么。
OKR是努力的方向和目标。OKR代表你到底要去哪里，而不是你要去的地方具体在哪里。
OKR必须可量化。比如健身时设定锻炼目标，如果只是定义成「我们要努力提高身体素质」，肯定不是一个好的 OKR，因为无法衡量，好的OKR是「今年的跑步时间较去年增加一倍」。
目标必须一致。制定者和执行者目标一致、团队和个人的目标一致。首先，制定公司的OKR；其次，每个团队定自己的 OKR；第三，每个工程师或设计师写各自的OKR。这三步各自独立完成，然后对照协调这三者的OKR。在豌豆荚，OKR跟个人绩效没有关系，因为OKR 系统的结果和每个人并不直接挂钩。
月度/季度会议Review。通过月度会议Review ，时时跟进OKR：在月度会议上需要确定如何去达到目标，是一个帮助达到目标的过程。通过季度会议 Review ，及时调整OKR：互联网的变化非常快，所以豌豆荚每季度有一个OKR 的 review，调整的原则是目标（Objectives）不变，只允许调整关键成果（Key Results）。

控进度（项目管理–控进度）

任务/进度勤同步。整个公司所有人的 calender，包括会议、要做的事情、项目的时间节点都需要及时同步。在整个战略布局上，如果某个项目工期非常紧，就必须进行更多的沟通，确保每一个环节都没有问题。
站立会议 (Daily Sync)。每天进行站立会议，一般控制在十分钟之内，每个人说明自己今天要做的工作，需要什么帮助，有谁可以帮忙，可以更有效的调节资源和公关。
多方位沟通（Google Docs / Gmail / Hangouts）。对非紧急的事情，两个团队或者是两个人一起讨论所有的设计。Hangouts用于做快速响应。
周会（Weekly Report）。每周总结。豌豆荚的团队产品经理要做周报，汇报这周的工作、发布、取得效果以及数据。
数据系统。MUCE 是豌豆荚的数据系统，上面有全公司所有的产品数据和运营数据。MUCE 的数据能够用来验证产品的假设、方向等

带团队（人员管理–带团队）

Re-Organization& 换组。公司鼓励员工换组，每个人都有机会到喜爱的团队做更有趣的事情。只要在原团队的绩效合格，每季度都可申请换团队或换工作内容。员工的绩效不与 OKR 挂钩，公司鼓励员工挑战难度、超越优秀，低 Level 的事情做不到优秀会被惩罚，做事不及格也会被惩罚。
One on One。在带人方面， One on One 非常重要。One on One 指的是每个团队的 manager 需要定期（最佳间隔是每周一次）与自己团队中的每个成员进行一对一讨论或者对话。在豌豆荚，manager 首先是一个教练，应该帮助自己团队的成员成长。通过 One on One，manager 需要了解每个团队成员现阶段的状态和遭遇的困扰，分享职业规划，帮助他们正确地处理问题，更好地实现个人成长。
个人 OKR 和 Performance 体系。每个员工在每个季度初需要确定自己本季度的 OKR，在一个季度结束后需要根据自己这个季度的工作完成情况给 OKR 打分。每半年公司会进行一次 Performance Review，主要是 review 员工过去半年的绩效，并根据 Performance Review 的结果变更 Job Ladder（业务职级）和薪酬。值得一提的是，在豌豆荚，所有的个人Performance Review 的成就内容及级别都是全公司共享公开的。这个对于很多公司来说是不可想象的，豌豆荚为什么要这么做？因为一方面对于豌豆荚来说可以做到更为公平和透明，另一方面也给每位豌豆提供了更好学习和成长自己的样本，激励大家在产品研发中更高质量的挑战和要求自己。

排干扰（兴趣管理–排干扰）

激发兴趣。HackDay，是豌豆荚一个特殊的节日，开始于2010年，类似黑客马拉松。通常在春节假期回来的那一周，产品设计师和工程师们 3-5 人组成一队，在连续48小时的时间里，充分展现工程团队的创意和想像力，完成一些比日常开发更 geek、更有趣的东西。
控制兴趣。PolishWeek，让公司慢下来，对已有产品的细节进行精细化的过程。在大量开发和新产品上线的过程中，我们会担心因为走得太快而对产品的细节关注不够。在连续3个工作周后，第4周通常是 PolishWeek。在 Polish Week 的这一周，豌豆荚内部不会进行新产品或新功能的开发，而主要是对现有的产品和服务进行打磨，解决一些细节问题和小 bug，譬如产品内一些字体的统一等等。平均每个 Polish Week 会解决产品中各种 Bug 大约 200 个。

参考链接：

有效管理的启发式方法

Thu, 14 Apr 2022 10:32:14 CST

原则

偏向于行动和决策，而不是计划和共识。
喜欢写作胜过会议。
了解您的产品如何在野外使用。例如，加入销售和支持电话。
通过专注于您想要实现的结果来向后工作。
通过提出开放性问题来鼓励所有权。
成为啦啦队长。经常庆祝成功并加强积极的行为。
知道如何区分可逆和不可逆的决定。
确保每份报告都了解团队、组织和公司的首要任务。
经理之下没有任何任务。即使它不是编码，也要弄脏你的手：

一对一

永远不要跳过一对一。这是接收和提供反馈的最佳平台。大多数队友重视它，通常当他们不重视它时，是因为他们没有看到一个表现得很好。
争取每周一对一。
关注5个主题：
- 可预测性：创建例行程序、设定期望、使变化正常化。
- 所有权：提供选择，明确所有权，赋予更多责任。
- 目的：阐明其任务的全局价值和重要性。
- 进步：创造里程碑，分享胜利，庆祝进步。
- 归属感：团队文化与管理。
帮助构建每个主题的问题。“在 1-10 的范围内，您如何评价：...”
- 可预测性：你对你的期望有多清楚？
- 所有权：您对决策权和方向的满意度？
- 目的：你的工作对团队有多大影响？
- 进步：每周进步的感觉？
- 归属感：你与团队的联系感？
不经常提出的其他问题：
1. 动机：
  1. 你工作的哪个部分最有趣？
  2. 在这里工作有什么不开心的？
  3. 你每周最大的时间浪费是什么？
2. 长期目标：
  1. 你想提高什么技能？
  2. 你在寻找什么样的职业道路？
  3. 您会很高兴向公司中的谁学习更多信息？
  4. 您希望更多地参与业务的哪些部分？
3. 组织意识：
  1. 您不喜欢该产品的哪些方面？
  2. 我们错过的最大机会是什么？
  3. 您认为本季度的三大优先事项是什么？球队的？组织的？
  4. 如果你是 CEO，你会做些什么不同的事情？
4. 经理的角色：
  1. 我能做些什么来更好地支持你？
  2. 如果你是我，你会改变 1 到 3 件事是什么？
  3. 您如何看待收到的反馈数量？
  4. 我需要反馈。我可以做哪些不同的事情？
  5. 我们可以做些什么来改善我们的协作方式？
5. 优先事项：
  1. 本周你的首要任务是什么？
  2. 成功会是什么样子？
  3. 什么是障碍？
鼓励您的直接下属提出主题：
有关有效的一对一的更多想法，请参阅从一对一中获得更多。
没有一种最好的管理风格。在您最初的一对一中弄清楚某人希望如何被管理：
1. 你喜欢你的前任经理什么？你不喜欢什么？
2. 你喜欢从经理那里看到什么？
报告也是经理的一对一通常更“业务”，重点是战略、团队健康和项目一致性。

辅导

默认为开放式问题：以what、how、who而不是像do、have那样的封闭式问题开始提问，是邀请对话并赋予问题所有权。
- “你有什么问题？” 比“你有什么问题吗？”更好。
- “为什么你认为这是正确的做法？” 比“这是个好主意吗？”更好。
- 回答“到目前为止你的想法是什么？” 当被问到“我该怎么办？”
总结这个人在说什么，这样你们就可以在同一页面上并找出问题所在。
- “听起来有两个问题，x 和 y。我们应该先关注哪个？”
弄清楚如何使会议富有成效：
- “下一步是什么？”
- “我们应该如何追踪这个？”

回馈

要及时，最好在提示事件的同一天提供反馈。
通过提供上下文来获得关于提供反馈和减少神秘感的支持：
- “你有10分钟吗？” ⛔️
- “你有 10 分钟的时间来谈谈今天早上的站立会议吗？”
- “我可以和你分享一些关于我们如何合作的想法吗？”
不要以赞美开头来填充负面反馈；它给出了混合的信号。
即使是积极的反馈，也要具体。
- “做得好！” ⛔️
- “我喜欢你为减少服务的内存占用而采取的举措。它鼓励我给你更多的所有权，这样我就可以专注于其他地方。”
关注数据而不是行为：
- “我注意到你没有解决你最近三个 PR 中的任何评论”
- “我注意到你没有拿起我让你做的票”
- “我注意到您的上一个功能版本没有经过任何测试”
- “你的代码有问题” ⛔️
- “你总是迟到” ⛔️
谈论为什么这很重要以及它正在影响谁：
- “我提到它是因为我们作为一个团队工作很重要”
- “我提到它是因为我分配给你的票对本季度的路线图至关重要”
一起找出解决问题的方法：
- “你觉得我们的流程怎么样？”
- “你怎么看？”
就行动计划达成一致：
- “我们如何确保下次不会错过机票到期日？”
- “你现在可以采取哪些行动？”
- “我们的行动项目是什么？”
突出积极模式（记住要具体）。
- “很高兴看到你教 X 关于 Y，让他们和你一样精通。这是高级工程师的特质。”
重播本能反应以帮助构建对话：
- “我对你的提议的最初反应是……”
- “这就是我会做的”比“这是你应该做的”更好
- “当你做 X 时，我感觉到了 Y”

战略性思考

再多一个人怎么办？
你的团队是如何推动针的？你专注于正确的事情吗？您如何知道您正在构建的功能将使客户受益？
你的产品的使命和宗旨是什么？
你的团队士气如何？你有没有问过他们在这里工作有什么不好玩的？
公司今年的首要任务是什么？三年后公司应该在哪里？
本季度您的“岩石”和“卵石”项目是什么？
您的团队在推动什么公司年度目标？以什么方式推动？
如果你升职了，你的团队中谁会接替你的位置？这个人需要获得什么技能或经验？
你团队的痛点是什么？你怎么能快 2 倍？
没有你，你的团队能运作多少？
如果公司失败了，最可能的原因是什么？
你担心什么 “狗不叫” ？

做出决定

确定决策是可逆的还是不可逆的。
- 可逆的决定很容易被改变。示例：更改站立时间、提供指导。
- 如果不进行大量返工，就无法更改不可逆转的决定。这些决定应该花费更长的时间并记录在案并进行讨论。示例：架构变更、招聘、组织变更、数据模型。
- Sam Newman的技术决策准则：
每当出现分歧时，请关注决策的预期结果，并确保团队了解您的推理。
- “虽然数据库 X 更好，但我希望我们在一个堆栈上进行标准化，以便更容易维护。”
如果有人不同意一个可逆的决定，请设定一个日期与团队重新讨论该决定。理想情况下，您还有衡量该决策成功与否的指标。
- “我理解你的担忧。让我们在一个月后重新审视这个问题，看看我们的立场。”
- “我们现在正在跟踪 X，如果它随着这些变化而有所改善，让我们在下个季度重新审视。”
如果有人不同意不可撤销的决定，请给他们机会陈述他们的观点。无论如何，每个人都应该知道决定最终是你的，团队需要不同意并完全致力于所做的决定。
记录您的决定，以便您可以参考做出这些决定的原因以及您的团队面临的权衡。

编码

避免在关键路径中编码。来自慈善专业的提示：

创作功能？ ⛔️
在有人需要休息时提供随叫随到的服务？ ✅
验尸后潜入最大的项目？ ⛔️
代码审查？ ✅
发现一个令人讨厌但似乎从未成为首要任务的 p2 错误？ ✅
坚持所有提交都必须获得批准？ ⛔️
清理监控检查并编写库来生成覆盖率？ ✅

票务和公关流程

为团队制定贡献指南。
PR 应该足够小，可以在一小时内得到适当的审查。
优先考虑 PR 以取消阻止票证。
使用 linting 或代码格式化程序（如 black ）自动处理诸如 style 之类的意见。

沟通

写作

赞成长篇写作提案而不是演示文稿。写作迫使作者思考细节和权衡。
喜欢枚举列表而不是项目符号列表；它们更容易参考。
鼓励亚马逊式的 “6 寻呼机”和“2 寻呼机”。
创作音乐。
例子：
1. 是时候建造了
2. 我们不在这里卖马鞍

电子邮件

[Action Required]如果您希望读者采取行动，请在主题前加上前缀。
按以下方式构建您的电子邮件（来自 7 Tips for Better Executive Communication）：
1. 第一段——不超过两句话。这将是标题和关键信息
2. 第二段 - 3-7 个项目符号。项目符号越多，行长越短。旨在不换行。
3. 第三（最后）段——不超过 2-3 个句子，重点关注所需的行动、后续行动和时间表。
在工作时间之外“安排发送”电子邮件，除非它们只是仅供参考或您需要立即回复。

会议

通过鼓励在开会前提出建议来避免糟糕的头脑风暴会议。

“不要将决定推迟到会议上。当场做出决定，通过长篇写作进行沟通，并利用会议进行讨论。” ——埃里克·伯恩哈德森
避免没有固定议程的同步或重复会议。
总是以行动、所有者和时间结束会议，因此很清楚下一步是什么。
对于员工会议，绕过桌子询问报告他们最关心的问题是什么。

许多经理想参加行政人员会议，因为这让他们感到被需要并让他们知道。我通过设定会议入场费来利用这种愿望：你必须承认至少有一件事情“着火了”。”——本·霍洛维茨
偶尔向与会者询问会议是否富有成效或如何改进是值得的。
在发送邀请之前，问问自己为什么不能通过电子邮件传达此会议。

招聘

如果您可以“招聘强硬”，您就可以“轻松管理”——Sue Tetzlaff，《员工体验》

招聘是经理做出的最重要的决定。

在高级工程师中寻找什么：

所有者。即使不是 100% 的责任，也要对问题负责；明白为什么。
1. “告诉我你有一次在你的职责范围之外承担了一些重要的事情。为什么它很重要？结果是什么？”
2. “告诉我你曾经为了长期目标而做出牺牲短期收益的艰难决定的经历。”
处理歧义
1. “你能告诉我你必须解决一个雄心勃勃的问题的时间吗？为什么这个问题很重要？”
2. “你能告诉我你在没有完整信息的情况下不得不做出决定的时候吗？当时的情况是什么？你冒了哪些风险？你为什么做出你做出的决定？”
团队球员。很好地接受反馈。
1. “告诉我你对某件事改变主意的时候。你背后的思考过程是什么？”
2. “说说你和你的经理意见相左的时候吧。你从这种情况中学到了什么？”
3. “说说有一次你需要一个抗拒的同伴合作。你做了什么？结果如何？”
4. “给我一个你收到的艰难或批评反馈的例子。它是什么，你做了什么？”
5. “如果我要和你的同龄人交谈，他们会对你有什么正面或负面的反馈？”
沟通者。可以表达不同层次的想法。
1. “什么造就了伟大的工程师？”
2. “向我描述一些你很熟悉的事情。”
3. “你在简历中提到了X，给我解释一下，就好像我从来没有遇到过一样？”
老师。喜欢培养其他工程师。对于高级工程师尤其重要。
1. “告诉我你曾经帮助团队中的某个人成长的经历。”
深潜者。深入挖掘一个级别以了解幕后发生的事情。
1. “告诉我有一次你试图了解团队中的一个问题，但你必须深入多层才能弄清楚。”
简化。简化问题，而不仅仅是破解事物并增加技术债务。该人是否有构建与购买的心态。
1. “告诉我一个你用简单解决方案解决的复杂问题。”
传教士。对公司的使命或技术感兴趣。
1. “向我解释一下你现在的公司做什么以及为什么它很重要。”
2. “你在[公司]工作有什么兴趣？”

需要注意什么：

在公司短期任职。如果候选人通常在公司呆不到一年，请询问他们为什么。可能有完全正当的理由，或者它可能表明该人难以使用的模式。
1. 为什么你只在 X 工作了不到 1 年？
技术菜单。仅列出使用的技术而不是解决的问题的简历可能表明人们可能没有考虑全局。也是初级工程师的典型特征。
长简历。超过 2 页可能表明该人难以提炼出重要的内容。话虽如此，长简历可能有文化原因。例如，在一些欧洲国家，鼓励简历要长。

入职

拥有良好的入职流程对于团队的成功至关重要。它确保新成员尽早做出贡献，并融入您的流程和文化。

如果您的新团队成员可以在他们加入的第一天提供错误修复，则入职流程是成功的。

入职材料：

团队使命
1. 您的团队如何为客户提供帮助？
团队成员
1. 包括：姓名、角色/职务、电子邮件、slack 用户名、github 用户名
存储库和服务
团队内部如何沟通
1. 松弛通道
2. 让自己了解情况
3. 工作时间内外的通信协议
文档
1. 代码贡献指南
2. 公关审查流程
3. 票务流程
4. 专业术语
5. 发布代码
6. How tos（例如迁移数据库，添加机密）
入门
1. 安装说明（例如 Docker、postgres）。
2. 所有预期访问的清单（例如 AWS、PagerDuty）
3. 在本地运行您的应用程序
4. 部署您的第一个错误修复
会议。您的新团队成员应该与谁见面？

向上管理

通过共享列出您的项目优先级、时间表和信心水平的文档，确保您和您的经理在同一页面上。
你的经理也需要向上管理。主动向您的经理通报项目时间表的变化，简要回答以下问题：
1. 新的时间线是什么？
2. 为什么时间线发生了变化？
3. 你对新的时间表有多自信？
没有人在乎责备或借口。自己的错误并记录您将采取的纠正措施以减轻它们的影响。

横向管理

通过提出问题而不是解决方案来获得支持。
1. “对我们来说，做功能 X 的最佳方式是什么？”
2. “我需要你做 X，这就是方法”⛔️
要求制定时间表，让您的同行对交付日期负责。
如果您不同意某个方法，请记录您的疑虑。拥有审计跟踪可以提高问责制。
创建项目启动和站立，以确保您了解其他团队的状态和优先事项。

宣布改变

变革的例子：升职、改组、重组。
承认改变的困难或机会。
通过使用叙述来解释原因来吸引情绪。
1. 为什么现在这种变化对公司很重要？
2. 这种变化对谁有影响？
用事实诉诸逻辑。
1. 这种变化将实现哪些指标？
将改变社会化以获得支持。
1. 从受影响最大的人开始。
例子：
1. Carta 的 covid-19 裁员

进一步阅读

亚马逊领导力原则：围绕领导力运作的最佳原则。
经理之路：各级管理的优秀指南。
每个工程经理都应该知道的 97 件事：收集来自不同从业者的管理技巧。
每个工程经理都应该问自己的 5 个问题
钟摆或阶梯：关于成为一名想要保持技术的经理所面临的挑战。
Hard Thing About Hard Things : 更多在行政层面，但仍然值得。
你所做的就是你是谁：为什么公司文化很重要以及如何建立一种文化。
工程管理回购：管理文章的大集合。
招聘工程领导者：招聘工程领导者。
如何比市场更聪明地招聘：伯克森的悖论和工程招聘。
LifeLabs 学习。适合新手和经验丰富的经理的绝佳研讨会。我从中学到了很多关于反馈、指导和 1-1 的知识。
软件工程师如何帮助面试他们未来的经理：工程师在面试经理时要问的问题列表。
从一对一中获得更多：如何衡量成功的一对一。
更好的执行沟通的 7 个技巧：关于如何有效沟通的技巧。
有毒的会议文化：如何避免遇到反模式。

我在 Imgur 学到的 21 项管理知识

Thu, 14 Apr 2022 09:46:36 CST

管理没有动力的人是非常困难的。让你的工作更轻松，不要这样做。
不同的人需要不同的管理方式。要适应找出是什么推动了每个人的最佳表现。
经常直接地提供反馈。作为经理，等待然后在软包装中对冲关键反馈更容易，但这是自私的。我会尽量在我能和这个人找到一个会议室时尽快给出反馈，而不是等到正式的 1:1 天后。
A 级玩家喜欢听到关于他们表现的批评性反馈，他们讨厌 B 级玩家没有听到自己的反馈。通过向每个人提供可操作的反馈并认可卓越的表现，让您的 A 级玩家感到高兴。
沟通是你会做的最困难的事情。花很多时间在这上面，无论是在你自己的沟通上，还是在改善团队成员的沟通上。
快点开火。如果你不快速解雇表现不佳的人，你就有失去表现优秀的人的风险。不要低估表现不佳的人对表现良好的人的影响。即使身体更少，您的团队也可能会移动得更快。最后，因为表现不佳而解雇比因为钱用完而不得不解雇好人要容易，所以在解雇好人之前解雇坏人。
人们需要感觉自己被倾听，而不是做出最后的决定。花时间倾听（你可能错了），做出决定，然后解释决定。在您了解做出这些决定的原因之前，不要对他人的决定发表评论。
为您做出决定的原因提供背景信息是扩展您的决策过程的一种方式。目标是让经理做出尽可能少的决定，为此，您的团队需要了解如何做出正确的决定。
清楚地定义成功，不要在没有新信息的情况下就定义失败。另一方面，当事实发生变化时，重新评估你的目标。设定可实现但困难的目标。
雇用朋友可能非常有用，因为沟通会更容易，而且你的朋友可能很聪明有才华。但你可能会以招聘经验或领域专业知识为代价。如果你不能解雇朋友，就不要雇佣他们。
以任务为导向的团队是一种竞争优势，因为它们更容易 1) 雇用和 2) 激励。
经理和个人之间采取的任何行动（晋升、更频繁的 1:1、会议中的召集）不仅在经理和个人之间，而且会影响团队中的每个人。例如，如果您提拔一个人，请确保团队的其他成员了解为什么提拔该人，以及需要做些什么来实现这一目标。
不承认自己的弱点比因为弱点的存在更容易失败，所以要提高自我意识。
有时，您必须押注于无法运行的大型资源密集型项目。小心你团队的士气损失。不是每个人都对反复失败有很大的容忍度。如果你是创始人，你可能比你的团队更习惯这个。一种技术是将迭代工作与风险更大的赌注相结合，以重建这种能量。但是您也应该尽量不要将任何功能描绘成灵丹妙药，而将真诚的个人失败视为尝试新事物的必要成本。你的公司是一个投资组合。
你花钱的方式是你可以传递的最大的文化信号之一，而且很难改变。你花钱的地方（和不花钱的地方）传达了你认为重要的东西。
避免政治的最好方法不是忽视政治，而是把时间花在它上面。定义明确的基于绩效的系统，以减少对团队成员需要做什么的混淆。
您可以做的最有用的事情之一就是提醒团队更大的图景。知道什么是重要的将有助于消除废话。
管理优秀人才的最佳方式是提供明确的目标和定期反馈（这与常规方向不同）。
虽然职业发展最终是每个人（还有谁？）的责任，但作为经理花在主动理解和实现增长上的时间是值得的。
有时人们会说脏话。有时，人们的日子不好过。不采取任何个人。
我发现一个有用的个人口头禅是“我们很幸运，但现在是时候做好事了。” 也就是说，让我们假装过去的所有成功都是我们所处环境的结果，而不是我们自己的努力或良好品质。我们现在有一个独特的机会，可以通过卓越的表现来减少对运气的依赖。除了你的自我之外，这种信念没有任何代价，它可以帮助推动自我和团队的彻底改进。

It’s terribly difficult to manage unmotivated people. Make your job easier and don’t.
Different people need different kinds of management. Be adaptable to figure out what drives each person’s best performance.
Give feedback frequently and directly. As a manager, it’s easier to wait and then hedge critical feedback in soft wrappers, but that’s selfish. I’d try to give feedback as soon as I could grab a conference room with the person, and not wait until the formal 1:1 days later.
A-players love hearing critical feedback about how they’re performing, and they hate when B-players don’t hear feedback of their own. Keep your A-players happy by providing actionable feedback to everyone and recognizing superior performance.
Communication is the most difficult thing you’ll do. Spend a lot of time on it, both on your own communication and improving the communication of the folks on your team.
Fire quickly. If you don’t fire bad performers fast, you’re at risk of losing your good performers. Don’t underestimate the effect bad performers have on good performers. Your team will likely move faster even with fewer bodies. Finally, firing for bad performance is easier than having to fire good people because you’ve run out of money, so fire the bad people before you have to fire the good people too.
People need to feel like they’ve been listened to, not to make the final call. Take the time to listen (you might be wrong), make a decision and then explain the decision. Don’t offer commentary on others’ decisions until you understand why the decisions were made.
Providing context for why you made a decision is a way to scale your decision-making process. The goal is for the manager to make as few decisions as possible, and to do this, your team needs to understand how to make good decisions.
Define success clearly and don’t flip-flop on the definition without new information. On the other hand, when the facts change, re-evaluate your goals. Set achievable but difficult targets.
Hiring friends can be very useful because communication will be easier, and your friends are probably smart and talented. But you might do so at the cost of hiring for things like experience or domain-expertise. If you can’t fire friends, don’t hire them.
Mission-oriented teams are a competitive advantage because they make it easier to 1) hire and 2) motivate.
Any action taken between a manager and an individual (a promotion, more frequent 1:1's, a call out in a meeting) is not just between the manager and the individual, but affects every person on the team. For example, if you promote one person, make sure the rest of the team understands why that person was promoted and what needs to be done to achieve the same.
You’re more likely to lose by not recognizing your weaknesses than from the presence of weakness, so aim for self-awareness.
Sometimes you’ll have to bet on big, resource intensive projects that won’t work. Be careful of the morale toll on your team. Not everyone has great tolerance for repeated failure. If you’re a founder, you probably are more used to this than your team. One technique is to mix iterative work with riskier bigger bets to rebuild this energy. But you should also try to not paint any feature as a silver bullet, and individual failure in good faith as a necessary cost of trying new things. Your company is a portfolio bet.
How you spend money is one of the biggest cultural signals you can send and is very hard to change. Where you spend money (and where you don’t) communicates what you think is important.
The best way to avoid politics isn’t to ignore politics, but to spend your time on it. Define clear merit-based systems, which reduces confusion about what your team members need to do be recognized.
One of the most helpful things you can do is remind the team of the bigger picture. Knowing what’s important will help cut through the bullshit.
The best way to manage great people is to provide clarity of purpose and regular feedback (which is different than regular direction).
While career development is ultimately the responsibility of each individual (who else?), time spent as a manager to proactively understand and enable growth is time-well spent.
Sometimes people talk shit. Sometimes people have bad days. Don’t take either personally.
A personal mantra I’ve found useful is “we were lucky but now is the time to be good.” That is to say, let us pretend that all past success was the result of our situation and not our own hard work or good qualities. We now have a unique opportunity to reduce our dependence on luck through superior performance. There is no cost to this belief except your ego, and it can help drive radical self and team improvement.

Thanks to Wagon for providing a desk and copyediting.

44 个工程管理课 | defmacro

Mon, 04 Apr 2022 22:24:25 CST

欢迎来到工程管理。这很有趣，很累，很有意义——但最重要的是它是新的！以前对你有用的东西现在不起作用了。您必须掌握一套新技能，并在此过程中改掉一些坏习惯。这是一个简短的指南，可帮助您入门。

做

吸引、培养、指导和留住人才。与工程师交谈以尽早解决问题，然后尽可能解决它们。
与每位工程师沟通下一个他们需要解决的最重要的问题。
当开发团队无法达成共识时，成为决胜局。
成为信息中心。了解每个工程师正在做什么，并帮助连接原本无法连接的点。
提供行政支持。安排问题，协调发布，并确保官僚机器不断运转。
执行行为和绩效标准。解雇恶霸和表现不佳的人。

别

亲自修复错误并发布功能。您必须编写代码才能保持有效的决胜局，但这就是您的编码职责结束的地方。
监督人们工作的质量和数量。软件工程不是装配线。如果您发现自己过于频繁地进行监督，那么您就没有吸引到合适的人或给予他们正确的激励。

动机和文化

你是做出招聘和解雇决定的人。团队中发生的一切都是您的责任。
工程是卖方市场：人们为你工作是因为他们相信你。获得他们的才能是一种特权。
权威不是免费授予的。它是通过随着时间的推移做出正确的决定而获得的。
除非必须，否则不要做决定。只要有可能，让团队自行探索想法并做出决定。
在必要时做出决定。很少有事情像停滞不前的团队那样令人沮丧。
除非有必要，否则不要放弃想法。创造一个让每个人都能安全地分享和探索想法的环境。编写代码的人有很多你没有的信息。依靠你的团队，你会做出更好的决定。
建立关于如何做出正确决策的直觉，并与你的团队建立良好的关系，这将使你成功完成 95% 的工作。用于组织工程团队的大量概念框架不会产生太大影响。它们让优秀的管理者稍微好一点，让坏的管理者稍微差一点。

情绪和人

管理恰好在我们的文化中享有盛誉，但它与其他任何技能一样。声望是一种干扰——它是善变的和任意的。谨防相信你比任何人都好。你越早克服声望，就越早专注于做好你的工作。
管理也招来了嘲笑。忽略它——那些认为管理者无用的人不了解建立一个成功的人类组织的动力。
如果你觉得有什么不对劲，那你可能是对的。不要让任何人欺负你而忽视你的感受。
如果你发现自己责备某人，那你可能是错的。没有人醒来并试图做坏事。95% 的时间你可以通过与人交谈来解决你的感受。
大多数人不会轻易分享他们的情绪。经常进行非正式的对话，梳理出所有可能出错的地方。如果可以的话，然后修复它。
你的团队期待你的领导。有勇气说出每个人都知道是真的但没有说的话。
你的报酬是为了发现和解决你的团队可能没有意识到的文化问题。有勇气说出每个人都应该知道但不知道的事情。
雇用优秀的人，然后完全信任他们。每月或每季度评估绩效，然后在必要时解雇。不要每天评价别人，这会让每个人（包括你）都发疯。
大多数智力论点都有强烈的情感暗流。一旦你学会弄清楚这些是什么，你的效率就会大大提高。

决胜局和冲突

不要太快判断；你是对的比你想象的要少。即使你确定自己在任何特定情况下都是对的，也要等到每个人的意见都被听到。
一旦每个人都被倾听，那么清楚地总结所有观点，以至于人们会说“谢谢，我希望我能想到这样说。” 列出对每个观点的任何同意点，并说明你从每个人那里学到了什么。然后做出你的决定。
一旦你做出决定，就执行它。不要让团队浪费时间兜圈子来安抚不成比例的强烈声音。
如果有重要的新信息，请重新开始讨论。
当分歧变得私人化或人们不接受合理的决定时，它就会变成冲突。
大多数冲突的发生是因为人们感觉不到被倾听。与每个人坐下来，询问他们的感受。仔细听。然后再问。然后再次。然后总结他们对他们说的话。大多数时候，这将解决问题。
如果在您竭尽全力听取每个人的意见并解决问题后冲突仍然存在，那么是时候进行艰难的对话了。

艰难的对话

尽快进行艰难的对话。等待只会让糟糕的情况变得更糟。
永远不要假设或妄下结论。永远不要在你的脑海中妖魔化人。永远不要责备、大喊大叫或诽谤。
使用非暴力沟通——这是我所知道的在不冒犯他人的情况下批评人们行为的最佳方法。这听起来像是一种管理时尚，但它确实有效（我保证）。
有勇气说出你的感受和你需要什么。人们被对方的弱点所吸引，但又被自己的弱点排斥。脆弱不是软弱。
期待人们给予你同样的礼貌。如果有人因为陈述你的需求和感受而让你感到难过，那么它会告诉你更多关于他们的信息，而不是关于你自己的信息。

毛边

人们会推动和刺激发现你的界限。知道什么时候退后，什么时候站稳，就成功了一半。
偶尔有人会推得太远。当他们这样做时，您必须表现出粗暴的优势，否则您将失去团队的权威。
一个坚定的“我不同意”通常就足够了。
如果你不想一笑而过，就不要一笑而过。有勇气表达你的真实情绪。
如果你必须对同一个人多次坚定地说“我不同意”，那么解雇他们就是你的工作。
除非你是一个反社会人士，否则解雇员工是如此困难，你会找借口不这样做。如果你一直想知道某人是否适合太久，请鼓起勇气做你认为正确的事情。
不要让人们强迫你做出你不相信的决定。他们以后会让你对他们负责，他们是对的。决定是你的责任。
相信你自己。如果你认为自己骑在马上很有趣，你就不能带领骑兵冲锋。

如何向上管理

Thu, 24 Mar 2022 12:59:59 CST

[cp]一篇很有价值的关于向上管理的推文

🔗 twitter.com/wes_kao/status/1451926441239719947

《向上管理：如何给老板需要的并且获得你想要的》

告诉你一个秘密：你的老板已经厌倦了做你的经理，他们希望被你管理。

如果你曾经遇到过这种情况，请举手。

老板：有问题随时问我。

员工：好吧，我有个问题。

老板：你为什么不能自己想办法解决呢？

这样的对话非常令人沮丧，但其实是有办法可以变通的。

以下是我的向上管理方法：

大多数人错误地认为资历越深所需要的沟通越少。讽刺的是，事实恰恰相反。

资深员工应该是最善于沟通和向上管理的。他们积极主动地进行沟通，说明他们已经处理好了问题，并能预防同类问题再次发生。

秘诀：让你的老板以为他们在管理你，但实际上，是你在管理他们。

就像绝地武士可以控制别人思想的招式一样，你越是管理你的老板，他们就越认为你的工作做得好。

管理老板的三个技巧：

1. 提供解决方案，而不是问题

2. 提出要求，而不是抱怨

3. 让你的老板了解情况

记住一点：你无法读懂你的老板的想法一样，你的老板也无法读懂你的想法。

让我们深入了解每个技巧：

1. 提供解决方案，而不是问题

我们倾向于直接提出问题：

🚫 "由于X的原因，这完全不可行！"

✅ "X会让事情变得困难，但如果我们做Y，那么成功的机会就很大！"

这表明你是积极主动的，以解决方案为导向。

2. 提出要求，而不是抱怨

当你觉得很累的时候：

🚫 "我没法一直这样做，我已经筋疲力尽了。"

✅ "在接下来的几个月里能休个假就好了，我可以将休假安排在什么时间段呢？"

这向你的老板暗示你需要休息，但以一种更积极的方式。

3. 让你的老板了解情况

战术技巧：对你正在进行的每个项目，和老板约定一个定期更新的周期。比如可以根据项目的范围，每天或每周向老板汇报进展。

这样，他们就知道你做得很好，而且他们不需要进行微观管理。

有效地向上管理起来有很多好处。对你的老板来说：

- 相信你有能力

- 相信你值得投资

- 相信你值得帮一把

当然你的老板也会因为管理好你而邀功，这也没什么...

其实让你的老板得到甜头是很好的，因为他们会对你产生正面的、温暖的、感激的心理。

翻译一下：你的老板会喜欢你的向上管理，而不知道实际上是你在管理他们。

重要提示：这些方法并不适用于坏老板--那些把你扔在那不管，恶语相向，并且拒绝承认你贡献的人。可悲的是，我们中的许多人不得不在这样的老板手下工作，其造成的伤害可能需要很多年才能消除。

如果你的老板赏识你，你就有了更多选择：

- 承担更多有意思的项目

- 在1对1会议中即兴讨论有趣的想法

- 在新的领域有更大成长空间

简而言之，你会从老板的信任中获益。

你对你与老板之间关系的控制力比你想象的要强的多，而这一切要从接受向上管理你的老板是你的责任开始。

后续：《关于如何给老板交代清楚事情的背景信息》

http://t.cn/A66XuG07[/cp]

12 个适合做外包项目的开源后台管理系统

Sun, 20 Feb 2022 02:10:41 CST

来源：toutiao.com/i6865688485706072580

  1. D2admin

开源地址：https://github.com/d2-projects/d2-admin

文档地址：https://d2.pub/zh/doc/d2-admin/

效果预览：https://d2.pub/d2-admin/preview/#/index

开源协议：MIT

2. vue-element-admin

开源地址：https://github.com/PanJiaChen/vue-element-admin

文档地址：https://panjiachen.github.io/vue-element-admin-site/zh/

效果预览：https://d2.pub/d2-admin/preview/#/index

开源协议：MIT

3. JEECG-BOOT

开源地址：https://github.com/zhangdaiscott/jeecg-boot

文档地址：https://panjiachen.github.io/vue-element-admin-site/zh/

效果预览：http://boot.jeecg.com/

开源协议：Apache-2.0 License

4. GIN-VUE-ADMIN

开源地址：https://github.com/flipped-aurora/gin-vue-admin

文档地址：https://www.gin-vue-admin.com/

效果预览：http://demo.gin-vue-admin.com/#/layout/dashboard

开源协议：Apache-2.0 License

5. vue-admin-beautiful

开源地址：https://github.com/chuzhixin/vue-admin-beautiful

文档地址：https://www.gin-vue-admin.com/

效果预览：http://beautiful.panm.cn/

开源协议：MPL-2.0 License

6. Dcat-admin

开源地址：https://github.com/jqhph/dcat-admin

文档地址：http://www.dcatadmin.com/

效果预览：http://103.39.211.179:8080/admin

开源协议：MIT License

7. RuoYi

开源地址：https://gitee.com/y_project/RuoYi

文档地址：https://doc.ruoyi.vip/

效果预览：https://vue.ruoyi.vip/index

开源协议：MIT License

8. renren-fast-vue

开源地址：https://gitee.com/renrenio/renren-fast-vue

文档地址：https://www.renren.io/guide

效果预览：http://demo.open.renren.io/renren-fast/#/home

开源协议：MIT License

9. ant-design-pro

开源地址：https://github.com/ant-design/ant-design-pro

文档地址：https://pro.ant.design/index-cn/

效果预览：https://pro.ant.design/

开源协议：MIT License

10. iview-admin

开源地址：https://github.com/iview/iview-admin

文档地址：https://lison16.github.io/iview-admin-doc/

效果预览：https://admin.iviewui.com/home

开源协议：MIT License

11. material-dashboard

开源地址：https://github.com/creativetimofficial/material-dashboard#demo

文档地址：https://demos.creative-tim.com/material-dashboard/docs/2.1/getting-started/introduction.html

效果预览：https://demos.creative-tim.com/material-dashboard/examples/dashboard.html

开源协议：MIT License

12.EAdmin

开源地址：https://github.com/suruibuas/eadmin

文档地址：http://doc.eadmin.com.cn/

效果预览：http://www.eadmin.com.cn/

开源协议：无

暂时整理这么几个后面遇到更好的再整理，如果大家有好的也欢迎评论区下面推荐

研究发现 98% 的中国儿童青少年未达心血管健康理想状态

Thu, 17 Feb 2022 20:16:56 CST

根据发表在《美国心脏病学会杂志》上的一项研究，98.3% 的中国儿童青少年未达心血管健康理想状态。研究数据来自全国 7 个省市及地区，约 7 万名中小学生参与问卷调查，有近 2 万名学生参与血样采集，通过血样可以检测血脂、血糖等评估心血管健康的指标。经过有效数据的整理，最终纳入近 1 万 5 千多名资料。结果表明，儿童青少年的超重和肥胖状况令人担忧，这个群体的心血管健康状况非常不乐观。全国单纯的肥胖率已经达到 11% 左右，超重和肥胖相加能达到 20% 左右的患病率。全国只有 1.9% 的男性和 1.6% 的女性有理想的心血管健康状况。男性和女性在心血管疾病发病率上存在差异。这种性别差异与多种因素有关，比如生理年龄差异、激素水平差异、肾功能差异、染色体差异等。

腾讯应届生怒怼管理层腾讯高管：认真反思，尽快整改

Wed, 26 Jan 2022 20:21:01 CST

　　1月25日深夜，腾讯企业微信的一名应届生员工在部门内部大群中，因“赶版本”导致的高强度加班问题，发消息怒怼管理层。网传图片显示，该员工质疑管理者在进行任务排期时，只顾进度而忽略开发人员连续加班，影响健康的问题。

　　该员工表示，他在企业微信产品部年末评奖期间，看到一位同事的评语写道：“连续20多小时高强度并行设计和开发，确保了宣传页面按时上线”“持续1周高强度完成了超过200项产品和设计走查修改”等强调高强度加班的表述。

　　他认为，因高强度加班获得表彰，某种程度上并不是一个好信号。

　　“内测延期一天，企业微信是不是马上就会倒闭？官网延迟一天上线，客户是不是就马上跑到钉钉飞书那去？是不是非得让开发人员加这20多个小时的班，才能让这个版本满你们的意？你们做任务排期的时候到底有没有考虑过手下人的死活？”该员工称。

　　1月26日，在该员工在群里发难后，其直属领导、企业微信高管等都第一时间与其本人进行了沟通。

　　另外，企业微信负责人黄铁鸣也在腾讯内部论坛上，回答了关于这个问题的讨论，以下是回答内容：

　　大家好，我是WXG企业微信产品部的负责人ted。

　　上文中的截图是昨晚我们在部门大群里发的部门即时激励表彰文档，这个表彰是对取得了阶段性进展项目和个人的一次即时激励。其中的一些表彰内容引发了咱们一位同学对部门高强度工作问题、影响健康问题的反馈，对于这位同学敢于直言问题的态度，我是认可的。

　　昨晚我们也和这位同学通了电话，认真详细地了解了同学的情况和反馈，我们了解到这位同学刚加入部门2个月，刚来压力较大，与周边同学交流下来发现大家普遍工作高强度，加上近期身边好友不幸去世产生较大内心冲击，因此情绪迸发在部门群内表达了自己对高强度工作的意见。

　　关于上文中所提及的项目，是去年底企业微信和腾讯会议、腾讯文档的联合版本公司内测项目，这个项目是21年企业微信团队最重要的项目之一，项目牵涉到3个BG（业务集团）、3个产品的联合开发，上线的时间节奏也是基于三个团队之前的共同商定而确定的，时间紧、任务重，这确实令到我们很多同学连续高强度工作才得以保证了最终按时按质交付。

　　而后的4.0版本，又因为要赶企业微信4.0版年度发布会，再次令到大家强急行军。以上的这些，作为部门负责人，同学们的辛苦我看在眼里也记在心里，我很感谢大家为了项目为了产品而拼搏，也很惭愧因为项目因为产品而让大家如此辛劳。

　　今天的事情也再次提醒了我们，持续高强度的急行军是不持久的，也势必会影响到大家的工作与生活平衡，以及健康。之前BG层面还做了一个关于同学们工作状态的调研，大家普遍反映的问题是业务的价值感、工作强度、因为绩效考核“比加班、比谁走得晚”，从部门的管理者的角度，我的态度是，绝不会仅仅是根据大家的工作时长就来判断一个人的工作表现好坏或者绩效排名，这是不客观的，也是不可持续的。

　　其实基于之前BG层面的这个调研，我们也收到了很多同学匿名反馈的中肯建议和方案，我们也已经在思考优化方案，这位同学的敢于表达再次给我们做了对于快速优化的提醒。接下来，部门管理团队会尽快商议出一整套解决此类问题的具体方案，我的大体思路如下，先同步大家：

　　1、及时做好规划。同步优化产品迭代开发的规划与节奏，以及其它相关的流程、机制，尽量避免让大家在短期内高强度的工作。

　　2、健康合理工作时间。团队内部、跨团队合作，结合协同的必要性，共同商议健康合理的作息时间。

　　3、明确评价导向。不会让大家因为顾虑到考核排序而“比加班、比谁走得晚”，各团队负责人也要在团队内明确沟通考核的标准和依据，引导健康、可持续的工作方式。

　　后续具体的方案成型后我会在部门层面进行全员沟通，充分征集部门同事的意见。

　　最后，非常感谢这位同学的直言反馈，督促了我们尽快优化调整。感谢企业微信所有同学们一直以来的辛劳付出。期待未来我们用更健康、更持久的方式一起做出让用户满意的产品。

Spring Boot 2 实战：使用 Flyway 管理你数据库的版本变更 - SegmentFault 思否

Sun, 16 Jan 2022 12:27:28 CST

1. 前言

随着项目的不断迭代，数据库表结构、数据都在发生着变化。甚至有的业务在多环境版本并行运行。数据为王的时代，管理好数据库的版本也成为了迫切的需要。如何能做到像 Git之类的版本控制工具来管理数据库？ Java项目中常用 Flyway和 Liquibase来管理数据库版本。其中 Flyway相对来说比较受欢迎。

2. Flyway 的特点

Flyway大受欢迎是因为它具有以下优点：

简单非常容易安装和学习，同时迁移的方式也很容易被开发者接受。
专一 Flyway专注于搞数据库迁移、版本控制而并没有其它副作用。
强大专为连续交付而设计。让Flyway在应用程序启动时迁移数据库。

3. Flyway 的工作机制

Flyway需要在 DB中先创建一个 metadata表 (缺省表名为 flyway_schema_history), 在该表中保存着每次 migration（迁移）的记录, 记录包含 migration脚本的版本号和 SQL脚本的 checksum值。下图表示了多个数据库版本。

对应的 metadata表记录：

installed_rank	version	description	type	script	checksum	installed_by	installed_on	execution_time	success
1	1	Initial Setup	SQL	V1__Initial_Setup.sql	1996767037	axel	2016-02-04 22:23:00.0	546	true
2	2	First Changes	SQL	V2__First_Changes.sql	1279644856	axel	2016-02-06 09:18:00.0	127	true

Flyway扫描文件系统或应用程序的类路径读取 DDL和 DML以进行迁移。根据 metadata表进行检查迁移。如果脚本声明的版本号小于或等于标记为当前版本的版本号之一，将忽略它们。其余迁移是待处理迁移：可用，但未应用。最后按版本号对它们进行排序并按顺序执行并将执行结果写入 metadata 表。

对应的 metadata表记录：

installed_rank	version	description	type	script	checksum	installed_by	installed_on	execution_time	success
1	1	Initial Setup	SQL	V1__Initial_Setup.sql	1996767037	axel	2016-02-04 22:23:00.0	546	true
2	2	First Changes	SQL	V2__First_Changes.sql	1279644856	axel	2016-02-06 09:18:00.0	127	true
3	2.1	Refactoring	JDBC	V2_1__Refactoring	axel	2016-02-10	17:45:05.4	251	true

Flyway 支持命令行（需要下载命令行工具）和 Java Api，也支持构建工具 Maven和 Gradle。这里我们将目光放在 Java Api上。

3. Flyway 的规则

Flyway是如何比较两个 SQL文件的先后顺序呢？它采用 采用左对齐原则, 缺位用 0 代替。举几个例子：

1.0.1.1 比 1.0.1 版本高。
1.0.10 比 1.0.9.4 版本高。

1.0.10 和 1.0.010 版本号一样高, 每个版本号部分的前导 0 会被忽略。

Flyway将 SQL文件分为 Versioned、 Repeatable和 Undo三种：

Versioned用于版本升级, 每个版本有唯一的版本号并只能执行一次.
Repeatable可重复执行, 当 Flyway检测到 Repeatable类型的 SQL脚本的 checksum有变动, Flyway就会重新应用该脚本. 它并不用于版本更新, 这类的 migration总是在 Versioned执行之后才被执行。
Undo用于撤销具有相同版本的版本化迁移带来的影响。但是该回滚过于粗暴，过于机械化，一般不推荐使用。一般建议使用 Versioned模式来解决。

这三种的命名规则如下图：

Prefix可配置，前缀标识，默认值 V表示 Versioned, R表示 Repeatable, U表示 Undo
Version标识版本号, 由一个或多个数字构成, 数字之间的分隔符可用点 .或下划线 _
Separator可配置, 用于分隔版本标识与描述信息, 默认为两个下划线 __
Description描述信息, 文字之间可以用下划线 _或空格分隔
Suffix可配置, 后续标识, 默认为 .sql

4. Spring Boot 集成 Flyway

Spring Boot提供了对 Flyway的自动配置。使我们可以开箱即用 Flyway进行数据库版本控制。

4.1 Flyway 依赖

你只需要引入依赖：

    <!-- 无需版本号 -->
 <dependency>
      <groupId>org.flywaydb</groupId>
      <artifactId>flyway-core</artifactId>
 </dependency>

当然你要集成你的相关数据库环境。这里我们采用 H2数据库来演示，其它数据库同理只不过方言不同。不熟悉 H2数据库的可参阅我的专题文章 Spring Boot 2 实战：H2数据库集成以及使用。

4.2 Flyway 配置

为了直观的讲解配置，首先在 Spring Boot配置文件 application.yml我们配置 H2数据库为:

    spring:
   datasource:
     #  h2 驱动
     driver-class-name: org.h2.Driver
     # h2  数据库 持久化到磁盘D:/h2 库名: flyway  mysql模式
     url: jdbc:h2:file:D:/h2/flyway;MODE=MySQL;DATABASE_TO_LOWER=TRUE
   h2:
     #    开启console 访问 默认false
     console:
       enabled: true
       settings:
         #      开启h2 console 跟踪 方便调试  默认 false
         trace: true
         #      允许console 远程访问 默认false
         web-allow-others: true
       #  h2 访问路径上下文
       path: /h2-console

对应Flyway的配置为：

    # flyway 配置
spring:
  flyway:
    # 启用或禁用 flyway
    enabled: true
    # flyway 的 clean 命令会删除指定 schema 下的所有 table, 生产务必禁掉。这个默认值是 false 理论上作为默认配置是不科学的。
    clean-disabled: true
    # SQL 脚本的目录,多个路径使用逗号分隔 默认值 classpath:db/migration
    locations: classpath:db/migration
    #  metadata 版本控制信息表 默认 flyway_schema_history
    table: flyway_schema_history
    # 如果没有 flyway_schema_history 这个 metadata 表， 在执行 flyway migrate 命令之前, 必须先执行 flyway baseline 命令
    # 设置为 true 后 flyway 将在需要 baseline 的时候, 自动执行一次 baseline。
    baseline-on-migrate: true
    # 指定 baseline 的版本号,默认值为 1, 低于该版本号的 SQL 文件, migrate 时会被忽略
    baseline-version: 1
    # 字符编码 默认 UTF-8
    encoding: UTF-8
    # 是否允许不按顺序迁移 开发建议 true  生产建议 false
    out-of-order: false
    # 需要 flyway 管控的 schema list,这里我们配置为flyway  缺省的话, 使用spring.datasource.url 配置的那个 schema,
    # 可以指定多个schema, 但仅会在第一个schema下建立 metadata 表, 也仅在第一个schema应用migration sql 脚本.
    # 但flyway Clean 命令会依次在这些schema下都执行一遍. 所以 确保生产 spring.flyway.clean-disabled 为 true
    schemas: flyway
    # 执行迁移时是否自动调用验证   当你的 版本不符合逻辑 比如 你先执行了 DML 而没有 对应的DDL 会抛出异常
    validate-on-migrate: true

请务必仔细阅读 Flyway相关配置的说明。

4.3 编写 SQL 初始化脚本

我们先编写一个初始化 SQL文件，向 H2数据库已经自动初始化的 schema flyway添加一张 sys_user表。 请注意命名规则。脚本名称为 V1.0.1__Add_table_user.sql。 SQL脚本的位置在配置的 spring.flyway.locations下。内容为：

    use `flyway`;
CREATE TABLE `sys_user`
(
    `user_id`         int(10) unsigned NOT NULL AUTO_INCREMENT,
    `username`        varchar(1024)    NOT NULL unique ,
    `encode_password` varchar(1024)       NOT NULL,
    `age`             int(3)           NOT NULL,
    PRIMARY KEY (`user_id`)
) ENGINE = InnoDB
  DEFAULT CHARSET = utf8mb4;

insert into  flyway.sys_user values (1,'Felordcn','{noop}12345',18);

启动 Spring Boot应用。打开 H2数据库控制台 http://localhost:8080/h2-console,在 JDBC URL一栏粘贴 jdbc:h2:file:D:/h2/flyway;MODE=MySQL;DATABASE_TO_LOWER=TRUE并点击 Connect按钮会进入以下界面：

这里 -1是因为我们缺省了 Flyway需要的 flyway_schema_history表。 0是因为 H2数据库自动初始化了 Schema flyway，其它数据库可能需要你手动来建立。

4.4 编写 SQL 变更脚本

我们编写一个 V1.0.0__Delete_sysuser_felordcn.sql来删除 V1.0.1__Add_table_user.sql中初始化的用户。 你会发现启动报错了，因为我们开启了校验，所以对于逻辑错误的版本会抛出异常。我们将版本号更改为 V1.0.2__Delete_sysuser_felordcn.sql再次启动。通过 H2数据库控制台我们会发现多了一条变更记录：

同时 sys_user表的数据也没有了，符合预期。

5. Flyway 最佳实践

通过上面的介绍相信你很快就会使用 Flyway进行数据库版本控制了。这里总结了一些在实际开发中的使用经验：

生产务必禁 spring.flyway.cleanDisabled=false。
尽量避免使用 Undo 模式。
开发版本号尽量根据团队来进行多层次的命名避免混乱。比如 V1.0.1__ProjectName_{Feature|fix}_Developer_Description.sql，这种命名同时也可以获取更多脚本的开发者和相关功能的信息。
spring.flyway.outOfOrder取值生产上使用 false，开发中使用 true。
多个系统公用一个数据库 schema时配置 spring.flyway.table为不同的系统设置不同的 metadata表名而不使用缺省值 flyway_schema_history。

6. 总结

今天我们对 Flyway 数据库版本迁移管理工具进行了介绍并将之与 Spring Boot 相结合。这将大大规范我们的数据库管理，提高生产效率。同时也分享了一些相当有用的生产实践经验。

相关的 DEMO 可通过关注公众号： Felordcn回复 flyway进行获取。

关注公众号：Felordcn 获取更多资讯

个人博客：https://felord.cn

@cozicoke：提醒一下大家，最近如果外出去公共场所的话一定要戴口罩。根据最新的排摸口径，疾控现在做流调的时候都是看监控回放的，如果是在和密接在同一空间接触的，没戴口罩那就是次密，集中隔离14天，戴口罩就是高筛，2+12管理。基本上戴口罩可以下降一个管理级别。所以大家外出千万记得戴口罩。

Fri, 14 Jan 2022 23:27:49 CST

@cozicoke：提醒一下大家，最近如果外出去公共场所的话一定要戴口罩。根据最新的排摸口径，疾控现在做流调的时候都是看监控回放的，如果是在和密接在同一空间接触的，没戴口罩那就是次密，集中隔离14天，戴口罩就是高筛，2+12管理。基本上戴口罩可以下降一个管理级别。所以大家外出千万记得戴口罩。

想看更多劲爆内容，请下载抽屉新热榜客户端 :
http://dig.chouti.com/qrcode/10036

围剿慢SQL，工行MySQL研发管控和治理实践（附PPT）

Thu, 13 Jan 2022 00:00:00 CST

生产上我们会通过监控自动查杀。但实际上，如果大家学过博弈论的话就会发现：是否查杀？到底怎么保持？这其实很难平衡，可能要通过实际场景去评估到底要不要去做。

接下来是慢SQL的治理。我们在2021年上半年大概发现了6670条慢SQL并落实版本优化，但正确率其实并不高，后续我们会考虑优化一些慢SQL的治理模型，将我们的准确率从20%再进行提升。

因为20%就意味着，我们的开发人员可能要花80%的无效时间去处理这方面的问题，显然违背了二八原则。虽然这个过程很痛苦，但我们确实收到一定的经营效果。本质上我们可以看到performance_schema可以用于监控MySQL运行过程中的资源消耗、资源等待等情况。这应该是MySQL 5.7以后会有的一个视图，这个视图中有一个表statements_summary_by_digest，它会记录每一条SQL的执行次数、时间，以及扫描的数据量等，通过对它们时间差的对比，获取真正的处理时间，从而判断语句是否存在问题。

Oracle的awr报告也是这样的道理，它是通过两个快照之间的差去进行比较。对于我们来说，比如8:00、9:00，我们的时间是一个语句。如图所示，它在8点执行了200次，执行时间是1800秒，扫描的记录数大概是1亿8000万；第二个是在9点，执行次数是300次，执行时间是2700秒。通过时间差可以判断，8:00~9:00之间只执行了100次，执行时间为900秒，那相当于一次执行花费了9秒，这其实就是一个标准的慢SQL。

虽然我不清楚在座各位所属应用对慢SQL的判定标准，默认应该是大于10秒的才算慢SQL。但对于我们金融行业来说，实际上超过一秒都属于慢SQL的处理范围。同时我们可以看到，它的扫描记录数大概是9000万，这样算来，它的扫描命中比例是900000：1，也就是说，我需要扫描90万条数据才能找到一条数据，这样的扫描比有很大的问题，显然存在效率问题，而我们的规范要求是100:1。

接下来是自动查杀。我们可以设置，当联机超过阈值时自动执行kill。但这样的做法在批量联机混合时存在风险，因为我们现在的批量联机用户实际上都是混合在一起的，而我们允许批量耗时超过10秒，这就很容易出现误杀。针对这一点，我们可以通过show processlist命令查看或者是通过 ps.threads去跟进线程的执行情况。

针对上述情况，我们做了两件事情：第一是推联机用户跟批量用户的分离，针对不同用户进行差异性处理。对于联机用户我们会进行自动查杀；而对于批量用户，因为我们判断它语句执行所花费的时间是合理的，所以就暂时先不管。

MySQL其实并不适合OLAP的应用，按照我的理解，我们可以通过大数据平台，也就是Hive、Spark，或者通过一些其他的方式去处理。这实际上就代表：MySQL仅局限于OLTP，其他像一些大数据平台等去做一些OLAP的处理，做到权责分离。

看到这里大家可能会说HTAP，我觉得这是一个老概念，属于新瓶装旧酒，以前Oracle其实就是HTAP数据库，但MySQL不行，所以需要结合实际业务场景做到功能和场景的分离。

ELK生命周期管理使用详解

Fri, 31 Dec 2021 07:30:47 CST

前言

一般在使用ELK对日志进行收集时，为了避免单个索引文件过大，通常按日期来对日志做切割，根据日期对产生的日志生成相应的索引。

索引名称通常如下方所示：

  nginx_log-2022.01.01
nginx_log-2022.01.02
nginx_log-2022.01.03
nginx_log-2022.01.04
nginx_log-2022.01.05

上方是从nginx采集过来的数据以天为单位来生成索引文件，从而避免索引过大影响查询效率。

该方案虽然解决了单个索引文件过大的问题，但是对于日志文件在ES中只需保留15到30天，时间再长的数据也没有多大的应用价值，同时创建大量的索引也会严重影响ES的查询效率。

所以能够定时清理已经没有价值的数据已经成为了管理ES必要之举。

本篇将通过创建随日期而变动的索引和ILM(生命周期管理)策略进行结合使用来达到有效管理ES索引的效果。

如果对Elasticsearch索引生命周期管理不是太熟悉的可以查看以下文章：

Elasticsearch索引生命周期管理

一、环境准备

	Elasticsearch	logstash	Kibana
192.168.159.128	√	√	√
192.168.159.135	√	×	×

说明

本次使用的版本统一都是7.2.0版本
两台服务器，Elasticsearch部署两个节点

二、需求

通过logstash采集日志数据，输出到Elasticsearch集群，要求如下：

以天为单位生成索引；
初始创建索引分配一个主分片和一个副本分片；
当创建索引3天后由hot阶段进入到warm阶段，并在warm阶段删除掉副本分片；
进入warm阶段12天后，从warm阶段进入到删除阶段，删除掉该索引。

三、功能

3.1 操作步骤

第一步：创建index，添加索引别名，设置别名可以写入到索引
第二步：创建索引策略，设置各个阶段进行相关的操作
第三步：创建对应模板，将新的index自动添加到创建的索引策略中
第四步：修改logstash配置文件，使其随日期变动向Elasticsearch相应索引中写入数据
第五步：查询配置是否生效

3.2 功能实现

（1）创建索引，设置索引别名为nginx_log

  # 删除索引名称为nginx_log开头的索引信息
DELETE nginx_log*
# 创建索引
PUT /%3Cnginx_log-%7Bnow%2Fd%7D-000001%3E
{
  "aliases": {
    "nginx_log":{
      "is_write_index": true
    }
  }
}

日期数学字符的百分比编码（用于日期舍入的特殊字符必须按如下方式进行URI编码）

<	%3C
>	%3E
/	%2F
{	%7B
}	%7D
\|	%7C
+	%2B
:	%3A
,	%2C

（2）创建索引策略

  # 索引策略名称为nginx_log_ilm_policy
PUT /_ilm/policy/nginx_log_ilm_policy
{
    "policy": {
        "phases": {
            "hot": {
                "actions": {}
            },
            "warm": {
                "min_age": "3d",
                "actions": {
                    "allocate": {
                        "number_of_replicas": 0
                    }
                }
            },
            "delete": {
                "min_age": "12d",
                "actions": {
                    "delete": {}
                }
            }
        }
    }
}

说明

创建索引默认在hot阶段
当3天后索引从hot阶段进入到warm阶段
在warm阶段将副本数设置成0
最后在12天后索引进入到delete阶段

也可以直接操作Kibana界面来创建索引策略

（3）创建对应模板，将新的index自动添加到创建的索引策略中

  # 创建索引模版名称为nginx_log_ilm_template
PUT _template/nginx_log_ilm_template
{
  "index_patterns": ["nginx_log-*"],
  "settings": {
    "number_of_shards": 1,
    "number_of_replicas": 1,
    "index.lifecycle.name":"nginx_log_ilm_policy", 
    "index.lifecycle.rollover_alias": "nginx_log"
  }
}

说明

参数	说明
index_patterns	模版匹配的索引名以，支持模糊匹配
number_of_shards	主分片数量
number_of_replicas	副本分片数量
index.lifecycle.name	通过索引策略名称指定模版所匹配的索引策略
index.lifecycle.rollover_alias	索引别名

（4）修改logstash配置文件，使其随日期变动向Elasticsearch相应索引中写入数据

  input {
  #beats {
  #  port => 5044
  #}
  file{
        path => "/home/es/datas/nginx_log.txt"
  }
}

output {
  elasticsearch{
        hosts => ["http://localhost:9200"]
        ilm_enabled => true
        ilm_rollover_alias => "nginx_log"
        ilm_pattern => "nginx_log-{now/d}-000001"
        ilm_policy => "nginx_log_ilm_policy"
  }
}

说明

字段	参数类型	说明
hosts	uri	设置远程实例的主机
ilm_enabled	string, one of [“true”, “false”, “auto”]	auto如果Elasticsearch为7.0.0以上版本，且启用了ILM功能则默认设置为会自动启用索引生命周期管理功能，否则将其禁用。
ilm_rollover_alias	string	过渡别名
ilm_pattern	string	模式中指定的值将附加到写别名，并在ILM创建新索
ilm_policy	string	修改此设置以使用自定义的索引生命周期管理策略，而不是默认策略。
template	a valid filesystem path	可以在此处将路径设置为自己的模板
template_name	string	定义如何在Elasticsearch中命名模板
template_overwrite	boolean	选项总是会用Elasticsearch中指定的模板或包含的模板覆盖指定的模板
timeout	number	发送到Elasticsearch的请求的超时限制

本次使用logstash来监听nginx_log.txt文件来实现数据的写入操作，在生产环境中可以换成监听beats端口。

（5）查看索引策略是否生效

方式一：通过命令查看策略是否生效

  GET nginx_log-*/_ilm/explain

输出结果

  {
  "indices" : {
    "nginx_log-2021.12.28-000001" : {
      "index" : "nginx_log-2021.12.28-000001",
      "managed" : true,
      "policy" : "nginx_log_ilm_policy",
      "lifecycle_date_millis" : 1640677049077,
      "phase" : "hot",
      "phase_time_millis" : 1640677053712,
      "action" : "complete",
      "action_time_millis" : 1640677053627,
      "step" : "complete",
      "step_time_millis" : 1640677053712,
      "phase_execution" : {
        "policy" : "nginx_log_ilm_policy",
        "phase_definition" : {
          "min_age" : "0ms",
          "actions" : { }
        },
        "version" : 1,
        "modified_date_in_millis" : 1640677053489
      }
    }
  }
}

方式二：通过Kibana中索引生命周期策略查看索引策略是否生效

通过：操作->查看链接到策略的索引，查看具体生效的索引策略

千万不要用新技术重新开发一次啊_阿朱=行业趋势+开发管理+架构-CSDN博客

Sun, 05 Dec 2021 08:02:02 CST

（1）在基础设施上做事

我个人有个洞察：2023年，中国云计算技术开始成熟，可依赖使用了。也就是说你过去是买它的云服务器，然后在服务器里安装自己的东西。但2023年以后，你不需要这么搞了，它上面有啥数据库&数据湖仓、中间件、运维&安全等等你都可以直接使用了，你不需要为你的应用基础做思考，你只关注你的应用就行了。

也就是说，你以后的工作基础是在以下这些基础设施之上工作的：

1、应用基础设施层：

电子签章、在线支付、电子发票、电子档案、银企联云、税企联云；

多端协同门户、统一身份认证管理、审批工作流引擎、IM消息

低代码开发平台、RPA、Open API开放平台、应用商店

2、中间件层：

多媒体处理中间件服务：音视频处理、视频直播中间件、云呼叫中心VOIP...

AI处理服务：视觉识别、OCR识别；语音识别；NLP；数据挖掘

IoT处理服务：IoT接入平台

3、数据层：

NewSQL、NoSQL；主数据管理；数据仓库；数字孪生、报表图表

4、IaaS层：

IaaS云原生（容器、CI/CD、多中心部署/多云部署、灰度发布）

Devops运维、安全

我看现在政府、央企大型国企，都在建设自己的政务云、国资云，而且都先从IaaS云原生开始建起，往上搭大数据平台，再搭企业协同平台，接下来才是在这个基础之上一块块搭应用。

你想想你如果在这样的基础设施之上做应用，你会怎么做应用？

（2）应用生态合作

即使你做应用，我也建议你不要自己全干应用，而是分层找生态合作。

1、个性化应用层：找外包开发公司即可。尤其是在上述的基础设施之上开发，比过去容易的多

2、行业业务应用层：找行业ISV即可，他们做的行业业务应用，挺专业

3、价值链应用：

研发设计管理-供应链管理-生产制造管理-销售管理-售后管理，这条价值链的应用找ERP厂商即可。

但研发设计工具、供应链在线采购交易、生产制造控制、营销与销售、售后维修维保，这条价值链应用，你得找不同的专业厂商来搞，这不是管理，这是真正拿工具来开展业务，没这么工具，业务都开展不了。这是很多人分不清业务工具和管控工具的。

4、职能应用：

财务、法务、人力属于职能应用。但人力也有人力管理和人力在线服务两种类别，如招聘管理是人力管理，但招聘本身是人力在线服务。学习管理系统是人力管理，但在线学习平台/知识付费平台是人力在线服务。

企业支付管理这是很多人不熟悉的。它有很多分支，如企业营销物料采购（营销部是Onwer、企业采购部是执行或管控）、企业MRO易耗品采购（生产资料部是Onwer、企业采购部是执行或管控）、员工商旅采购（行政部是Onwer、企业采购部或财务部是执行或管控）、员工福利采购（行政部是Onwer、企业采购部或行政部是执行或管控）、临时用工采购（人力部是Onwer、企业采购部是执行或管控）。这么多分枝，估计你得寻找不同的供应商采购一一针对性搞定。

不管是财务、人力，都直接找最专业的厂商分别搞定即可。

（3）应用分类处理

Gartner在2015年提出过敏态和稳态两种应用分类。

我个人理解，敏态偏外部开放性协作、快聚快散，而稳态偏内部封闭管控。用稳态架构做敏态、用敏态架构做稳态，都是找死。

即使是过去做企业内部管控系统，我过去都是应用分类处理，如

信息记录类应用

信息追溯类应用

高性能高精确计费收费交易类应用

流程勾稽关联协作类应用

预测推理、洞察决策类应用

我过去都是不同分类的应用，都有专门的架构设计。

（4）技术驱动产品设计

从2015年以来，出现了许多新技术。我们可以基于这些新技术，重新考虑应用应该如何设计。

一、数据采集环节

1、优先用AIoT技术做数据自动采集

2、其次用客户在线自助、上下游在线协同做数据自动采集

3、最后不得不员工录入时，优先用移动App进行限制性录入

4、最后不得不员工录入时，其次分场景分角色分工作流程阶段进行分段录入

二、业务过程处理环节

1、业务流程，主要通过数智化技术进行自动的、智能的：计划编制、资源调度、消息推送

2、优先用专业的单点应用，单点应用之间用协同平台、RPA平台、OpenAPI平台联动在一起

3、业务追溯，可尝试使用区块链技术

三、数据输出环节

可以使用搜索、推荐技术，而非过去的查询方法

可以使用人工智能的问答会话技术、Data2Text技术，而非过去的查询技术

可以使用数字孪生/BIM/GIS技术，而非过去的报表和图表

四、我建议做好用户体验全程管理

如用户画像、用户行为跟踪、AB测试，根据用户的行为观察来持续改进应用。而非自己拍脑门、做需求调研。

（5）模块分离

80%人用的20%功能，持续优化。

20%人用的各色特殊80%碎片功能，全部剥离到应用商店

这是以后做应用的设计原则。

（6）交付简化

企业软件交付是个最头疼的事情，经常涉及的配置有：主数据、业务参数、权限/流程、模板。

一、主数据

采取产业主数据服务，而非自己录入主数据

在主数据平台维护信息及标签图谱，而非在各个基础数据维护模块维护主数据

二、模板

采取模板应用商店+模板配置。我举个例子，如各种报销单，这典型是模板要搞定的事，而非系统要搞定的事

三、功能

采取插件应用商店+插件配置。我举个例子，如各种营销促销玩法，这典型是插件要搞定d 事，而非系统要搞定的事

四、权限

采取人员-岗位标签方式、并且内置岗位权限模板，而不是给每个员工设置详细权限

2021年敏捷管理工具推荐

Mon, 15 Nov 2021 00:00:00 CST

敏捷和DevOps已经很流行了，对应的工具也不少（例如JIRA、Azure DevOps、云效等等），我们在本篇文章里捋一捋截止到2021年11月都有哪些有名的敏捷工具。

1. JIRA

JIRA是Atlassian公司著名的敏捷管理工具，可以管理史诗（Epic)、用户故事(User Story)、任务（Task)，同时可以使用看板可以跟踪管理相关工作项的状态。
问题追踪和管理：用它管理项目，跟踪任务、bug、需求，通过jira的邮件通知功能进行协作通知，在实际工作中使工作效率提高很多

问题跟进情况的分析报告：可以随时了解问题和项目的进展情况
项目类别管理功能：可以将相关的项目分组管理
组件/模块负责人功能：可以将项目的不同组件/模块指派相应的负责人，来处理所负责的组件的Issues
项目email地址功能：每个项目可以有不同的email（该项目的通知邮件从该地址发出）
无限制的工作流：可以创建多个工作流为不同的项目使用

2. Azure DevOps

Azure DevOps 是由微软开发的服务平台，它提供了多种工具，可用于更好地进行团队协作。它还具有用于自动构建过程，测试，版本控制和程序包管理的工具。

Azure DevOps 提供了 5 个主要模块：

Azure Boards：这些是敏捷的工具，可以帮助我们规划、跟踪和讨论我们的工作，甚至与其他团队一起工作。
Azure Repos：提供无限的、云托管的私人和公共 Git 存储库。
Azure Pipelines：使用适用于任何语言、平台和云的 CI/CD 进行构建、测试和部署。
Azure Test Plans：使用适用于应用的手动测试和探索测试工具来提高代码整体质量。。
Azure Artifacts：与整个团队共享来自公共源和专用源的 Maven、npm、NuGet 和 Python 包。以简单且可缩放的方式将包共享集成到 CI/CD 管道中。

3. TAPD

TAPD（Tencent Agile Product Development）是腾讯的敏捷研发协作平台，提供贯穿敏捷研发生命周期的一站式服务。覆盖从产品概念形成、产品规划、需求分析、项目规划和跟踪、质量测试到构建发布、用户反馈跟踪的产品研发全生命周期，提供了灵活的可定制化应用和强大的集成能力，帮助研发团队有效地管理需求、资源、进度和质量，规范和改进产品研发过程，提高研发效率和产品质量。

产品功能:

敏捷需求规划：能够快速高效的对需求进行全周期管理。通过需求收集、分解，规划并实施，快速响应市场变化，灵活处理需求变更，过程可追溯，清晰更透明。
迭代计划：通过迭代进行目标制定与计划评审，完成工作分配，使用故事墙与燃尽图进行研发过程跟踪。迭代全程目标清晰，进度可控，研发过程敏捷迭代，小步快跑。
测试计划：对于迭代质量的全程把控。通过快速编写并管理测试用例，制定测试计划并执行，利用缺陷跟踪管理进行问题跟踪与解决，能够实现对测试工作的高效管理，保障产品高质量交付。
缺陷管理：对缺陷进行全方位记录与跟踪。配合缺陷统计报表对 BUG 进行统计分析，能够及时了解开发的质量并进行跟踪修复。同时可通过邮件创建定时报告发送给项目成员，让团队成员及时了解迭代开发质量。
工时管理：合理分配团队资源，利用工时进行工作量统计，配合工时花费报告，能够实时掌握团队成员工作完成情况与项目进展，过程清晰，风险可控。
文档管理：提供思维导图、在线文档、文件管理等功能，支持多人实时协作编辑，帮助团队集中管理项目文件，方便团队进行头脑风暴、内容分享与知识沉淀。

4 云效

云效提供项目管理、需求管理、缺陷管理、任务管理、迭代规划等丰富的项目管理功能及效能数据统计，支持单项目管理、跨项目协作等丰富的协作场景。

产品功能：

需求管理：管理需求从提出、设计、开发、测试、发布的完整流程。
迭代规划：提供将需求规划进迭代并完成迭代的交付。
项目管理：管理项目从创建、规划、实施、交付的完整流程。
研发效能度量：支持工时统计。

5 Leangoo

Leangoo是一个以看板为核心的敏捷项目协作工具，通过看板共享和实时同步团队工作来实现高效协同。团队工作体现为卡片，内容可以是需求、任务、问题等。
产品Backlog
Scrum任务板
用户故事

6. Ones

Ones 适用需求管理、任务管理、缺陷管理、迭代管理等敏捷场景
产品功能：

需求管理
迭代规划
缺陷管理
进度管理

大规模视频内容理解：淘宝视频内容标签的结构化分析和管理

Fri, 10 Sep 2021 09:38:48 CST

▐ 为什么要做标签？

在这种亟需深入理解视频内容的大背景下，不同的表征形态涌现。包括：

embedding表征
标签表征

其中embedding表征常用的方法包括多模态预训练模型、基于用户行为的deep match模型等等，集团内在这方面有大量优秀的工作，使用embedding表征视频内容最大的问题在于不可解释性，只能完成机器对视频的理解。

使用标签对内容进行表征的优势在于，标签是一种高度概括的自然语言，不仅完成了机器对视频内容的理解，同时完成了人到视频内容的理解。同时，标签库量级上百万，组合方式多样，保证了内容表征的多样性。

综上，对视频完成了标签挂载，可以完成以下目标：

用户可理解
算法可解释
运营可干预

▐ 我们需要什么样的标签？

为了回答这个问题，需要拆解成两个子问题。

我们需要什么样的标签库？

视频是一种分别非常不均匀的数据形态，其拍摄方式、包含物体、拍摄手法、表达重点均非常丰富，为了描述丰富多彩的视频，需要维护海量级、描述维度全面的标签库。由于视频热点更新速度非常快，因此标签库需要自动挖掘、更新，完成标签库的动态扩充。同时，由于标签是一种自然语言，标签和标签之间天然有一种推理关系，因此，标签不应割裂和独立，而是存在一种结构化的数据结构。

因此，标签库需要的特性总结如下：

标签量级大、标签维度全面；
可动态扩展
标签间有关联（结构化）

对于一个视频来说，需要打出什么样的标签？

对于一个视频，必然存在拍摄此视频的核心原因，我们将此原因概括为核心主旨标签，给出核心主旨标签，即可联想到此视频大致的描述方向。同时，视频中必然出现很多相关标签，这类标签可帮助了解视频细节内容。结合核心主旨标签和相关标签，就可以对视频内容进行全局到局部、总体到细节的理解，这也是符合人类认知习惯的。

以下面这个淘宝中常见的视频为例，其核心想表达的是一个复古清纯风格的服饰搭配教程，核心主旨为：白月光穿搭、复古清纯穿搭等；而如何穿搭才能展现这种风格？需要穿白色连衣裙、带发箍等等，因此其相关标签应为：白色连衣裙、可爱发箍、vintage等等。

视频1 一种典型的淘内视频打标的结果

标签体系框架设计

按照1.2中的分析，为完成对视频内容全面的理解，我们需要从标签库和打标算法两个大方向对整体标签体系框架进行设计，即：

（1）标签库动态维护，包括标签的动态挖掘和标签结构化

（2）视频内容打标算法

完成标签库维护和打标流程后，即可完成数据服务的对外输出和下游的业务应用。数据的对外输出包括数据生产和实时/离线的服务输出；业务应用包括运营工具、下游投放算法和标签外透等。我们设计的标签体系框架如下图所示。

图2 标签体系设计架构大图

经过标签体系算法流程，内容标签目前对视频内容进行打标、标签库进行动态管理取得的结果如下图所示。在后续章节中，我会根据 标签库动态管理、 视频内容打标算法流程、 下游应用三个大模块进行详细的介绍。

标签库动态管理

▐ 标签挖掘

为保证挖掘标签词的时效性、全面性，我们设计了两套互补的标签挖掘算法流程，再将挖掘出的标签融合起来进行人工审核。

基于autophrase的半监督新词挖掘算法流程

如下图所示，将内容语料库和置信的标签集送入autophrase模型，通过半监督的方式获取标签后，再经过一个判别标签是否有效的二分类模型得到最终挖掘出的标签。此方法挖掘标签的特点在于：

过审率较高（80%+）
新标签和置信集标签pattern相似
无法获取热门标签

基于标签pattern挖掘的新词挖掘算法流程

如下图所示，这是一种无监督的标签挖掘流程，先从内容语料库中挖掘出标签组合的pattern，再用pattern在语料库中进行匹配，获取挖掘的标签。此方法挖掘标签的特点在于：

过审率较低
标签pattern更加灵活多样
可以获取热门标签

目前，我们基于海量的站内/站外数据挖掘出500w+标签，通过数据清洗后的标签量为110w+，其中原子标签数量90w+，短语标签数量130w+，短语型标签每周增量约5000+。

▐ 标签结构化

高效地维护标签库，不仅在于标签地动态挖掘，更在于挖掘出标签后，如何结构化地管理这些标签。好的标签结构化引入了标签间信息，为标签推理认知的提供了基础知识。首先，我们按照词语粒度将标签分为原子标签和短语标签，其中原子标签是不可继续分词的标签，短语标签为原子标签组合而成的标签。

原子标签分类体系

我们首先为原子标签设计了一套分类体系，可对每个原子标签进行树状结构的划分，一级类目包括“时间”、“地点”、“人物/动植物”、“事情”、“物品”、“IP”、“机构名”、“数值”等8个大类，在一级类目中还有二级、三级、四级的树状延伸等50个小类。

通过原子标签分类体系，不仅可以细分管理每个原子标签，将短语标签拆解为原子标签进行理解，同时可以分析每个分类下原子标签情况，如发现短缺的情况可以及时补充，保证标签集合的完整充分。

短语标签分维度结构化

由于短语标签包含各种不同的高层语义信息，因此仅通过组成短语标签的原子标签进行理解是远远不够的，基于此，我们从不同语义维度设计了四种不同的短语标签结构化方法，包括：内容/商品标签、热门趋势标签/长期标签、人群兴趣标签/视频内容标签、问题型/陈述型标签。在应用中，可按照不同的需求选取不同类型的短语标签。

图4 短语标签分类体系

▐ 标签管理目前核心进展

目前标签库已实现动态管理、结构化，具体的指标如下图所示。

视频内容打标算法

▐ 视频内容打标算法流程设计

在确定视频内容打标算法流程之前，需要确定目前视频内容打标面临的困难和挑战，我对其总结如下：

标签库规模巨大：目前维护的标签库达百万，且长尾分布严重，无法使用多标签分类模型等常规打标签的解决方案。
标签库不断增长、动态扩充：目前标签库处在动态扩展的状态，标签经常变动，打标算法需要非常灵活&可扩展。
需对多模态信息进行理解：视频是一种多模态的内容形式，包括文本/图像/音频等多种模态的信息。对于不同的视频，不同模态的重要程度也不同，因此需要对多模态的信息进行综合全面的向量表征。
需区分不同标签在内容的权重：如上几条中讨论，对于一个视频，需要给出其核心主旨标签和相关标签。对算法来说，即最终标签结果需给出和视频内容的相关性分数排序。
人工标注非常困难：一个视频具体改打什么标签是一个非常主观的问题，对于不同的标注者，其对内容标签的标注结果会有巨大的差异。因此在打标算法流程设计中，需减少对标注的依赖。

综合上述对视频内容打标算法流程难点和挑战的分析，我们设计了基于“ 召回-排序”的两段式算法流程，召回是视频和标签粗粒匹配过程，排序是视频和标签细粒度匹配过程，调整标签的排序。此算法流程可以很好地解决视频内容打标过程中的难点。

图5 视频标签挂载流程大图

召回阶段

其的核心目标在于召回尽可能多、尽可能全的候选标签。为保证召回标签的全面，我按照以下四个维度进行召回：

内容信息

即内容自带的信息，包括创作者编辑的文本、语音识别结果（ASR）、文本识别结果（OCR）、画面信息。

以上面这个制作芝士烤土豆片的食谱教程视频为例：

商品信息

由于淘内视频的独特性，视频的目的是为了卖货，因此，商品信息也作为描述视频的一个维度。视频下挂载的商品、商品query、同款商品等信息作为商品信息维度的文本召回。

用户行为信息

淘内视频和用户有着大量的交互，用户行为本身也可以作为标签候选词集。因此内容搜索点击日志清洗出的query可作为表述用户行为的召回候选词。

关联内容信息

候选词集不仅应包括内容自带的信息，还应该包括关联信息，这一路召回主要通过检索方法实现：

跨模态检索模型：向量化视频和标签库直接进行跨模态检索，获取最有可能作为视频标签的词。
相似视频检索模型：需要打标的视频作为query，在千万级视频库中检索出topN相似视频，将相似视频的候选词共享到query视频。

在后续小节中，会对两种检索方法做更详细的介绍。

排序阶段

在排序阶段中，主要目标在于对视频和候选词集进行更细粒度匹配和对齐，完成候选词集的相关性排序，保留和视频相关的标签，去除不相关的词。排序模型的具体建模方式接下去会进行详细的介绍。

▐ 核心技术点

在上一部分中，除了常规模型ASR、OCR等，需要核心解决的技术目标为：

召回模块中的相似视频检索
召回模块中的跨模态检索模型
排序模块中使用的跨模态相关性判别模型

对于这三个需要解决的核心技术目标，我们抽象出三个需攻坚的核心技术点：

视频多模态内容表征模型
跨模态检索模型
跨模态相关性判别模型

在接下去几部分中，会对这三个核心技术点进行详细拆解和介绍。

▐ 视频多模态内容表征

我们目前提取的embedding基于自研的通用视频内容预训练模型。这个视频内容预训练模型借鉴了VilBert的自监督训练方法，继承了更多通用性强的预训练任务，包括内容挂载商品的一级、二级分类，内容的文本和视觉信息是否匹配。同时，由于淘系内容业务与推荐任务息息相关，因此，我们进行了大幅度的改造，对于推荐大场景改良了预训练网络和特异性预训练任务。

参考[5]LXMERT的预训练网络结构，具体输入：

visual branch图文内容：

（1）图文包含的所有图像经过Resnet抽取的1536维特征序列。维度为101536（2）图像帧位置信息序列：维度为110，表示图像处于图像序列位置视频视频：（1）视频关键帧经过Resnet抽取的1536维特征序列。101536（2）图像真位置信息序列：维度为110，表示图像处于帧序列位置

Language branch图文内容：

（1）title+body content经过中文bert编码的字id序列，维度为1128（2）字位置信息序列：维度1128，表示字在句子序列中的位置视频内容：（1）title+summary经过中文bert编码的字id序列，维度为1128（2）字位置信息序列：维度1128，表示字在句子序列中的位置

图6 视频理解基础模型网络框架

目前共5个预训练task：

图像序列随机mask掉图像序列的feature，最后用以visual为主的cross-modality feature进行mask掉的feature回归预测。
序列随机mask掉字序列的feature，最后用以Language为主的cross-modality feature进行mask掉的文字id分类预测。
内容挂载商品的110个一级类目分类
内容挂载商品的3807个叶子类目分类
visual信息和language信息是否匹配的二分类（即图像序列和文字序列是否来自同一内容）

同时，由于同时mask视觉/文本侧特征可能导致信息过度损失，参考[9]UNITER模型中的mask策略，优化训练策略，如下图所示。

经过10个epoch，使用100+块GPU，经过5天的训练，将6000w+淘内视频数据完成训练。预训练模型的参数更新参考了海量的视频数据，被上亿的标注数据进行了约束，最终产出的checkpoint可以作为后续跨模态检索、排序模型的Backbone网络，产出的768维向量可作为相似视频检索的视频向量。在视频内容的标签挂载算法流程中，这个pretrain model发挥了重要的作用。

内容表征的好坏是根据下游算法性能的提高作为衡量指标的，使用视频标题bert向量、LXMERT向量、UNITER向量在下游的跨模态检索模型、跨模态相关性模型中进行对比实验。

跨模态检索模型使用不同向量表征模型的对比结果

跨模态相关性判别模型使用不同向量表征模型的对比结果

相似视频检索模型

视频多模态预训练模型中最后一层768维fc可作为视频内容多模态的表征向量，对视频有很强的表征能力，因此可以使用此向量在视频库中检索出相似视频，用来扩充标签候选集。

使用相似视频检索对视频标签候选集进行扩充是一种非常有效的方式，使用相似视频检索的思路如下图所示，一个视频可以基于相似embedding检索的方法，在上千万的视频库中检索出最相似的N个视频，将这些相似视频的标签扩充此视频候选词集合。

基于相似视频检索方案的视频内容打标case如下所示：

图5 相似视频检索在标签召回的应用流程

▐ 跨模态检索

跨模态检索模型

如果视频和话题的向量分布被处理到相同分布空间，那么视频可以直接在标签库中检索到与其最相关的N个标签。因此我们设计了融合Graph的跨模态检索模型结构，完成视频直接到标签的检索。网络结构如下图所示。该模型主要包括文本编码模型、视频多模态编码模型、图网络算法模型、度量学习模型。

图7 融合Graph的跨模态检索模型网络框架

为了环节样本稀疏和均衡问题，单模态和跨模态端到端的度量学习进一步保证不同模态的语义一致性和单模态的判别性，我们引入了图网络构建。

我们根据用户点击行为构建文本-视频、文本-文本、视频-视频的同构图，但考虑到仅使用用户点击行为构建的图较为稀疏，因此同时引入了基于语义相似度建图，将相似的文本和相似的视频之间构建边，最终形成的图结构如下所示。

实验结果

检索衡量指标采用检索召回准确率Top1，Top5，Top20 以及Mean Rank值。

1K淘宝样本对检索性能如下：

MSCOCO Retrieval数据集的5K检索任务性能结果对比，其中对比方法主要限定采用双塔模型结构、特征提取无需相互计算，适用于大规模检索的方法。本文工作达到了与同期前沿工作具有竞争力的性能。

case展示

主题标签在千万级首猜精品视频池进行向量检索，手淘全屏页[3]主题标签召回示例case：

▐ 跨模态相关性判别

完成了最大程度的候选词集召回后，需要一个可以更加更精确判别视频和词语相似度的排序模型，从而将候选词从按照和视频的相关性分数进行排序，剔除掉不相关的词语。

此时的排序模型和上一小节的跨模态检索模型不同之处在于，跨模态检索模型目的是从上百万标签库中快速检索到和视频可能相关的词语，因此在训练过程中，视频侧和标签侧的网络结构不能融合。而在排序模型中，目的在于更精细化判断视频和候选词的相关性，且候选词数量有限，无需过度在乎时间复杂度，因此两模态之间可以进行充分融合，我们设计的网络结构如下图所示。

图8 视频标签排序模型网络框架

可以根据目的将网络结构分成三个较为独立的模块，即：

表征模块

如何对视频、候选词进行表征，可以全面刻画视频、候选词内容。这里我们主要讨论和调整了视频侧表征方式，使用视频标题、LXMERT多模态特征、UNITER多模态特征进行了对比实验，实验AUC结果如下所示。

融合模块

如何对两路特征进行融合，我们主要使用了两种融合策略，一种是最后一层MLP融合的late fusion策略，一种是使用attention metric进行attention fusion的策略，对比实验AUC如下所示。

对齐模块

两路特征表征和充份融合后，需要将两种分布在不同特征空间的模态（视频内容&标签）对齐到相同的空间分布中，才能完成不同模态的相关性度量。在这里，我们使用了融合了难样本挖掘的对比学习TripletLoss，以及将两种模态尽可能混合的Adversarial Loss。

我们对Triplet Loss和Adversarial Loss进行了对比实验，对比实验的AUC结果如下图所示，可以看到加入生成Loss后，由于增加了使两模态尽可能混合的目标，对最终相关性判别能力是有提高的。

加入用户反馈数据

由于标签数据在全屏页全量，每天有新增1w的用户点击数据，这部分数据往往更加精准，将这部分数据加入训练数据构造一个动态的训练数据集，相比于不加入这部分数据，相关性判别模型的AUC有将近3%的提升。

▐ 视频标签挂靠结果

通过我们设计的召回+排序的视频标签挂载流程，目前视频内容打标结果的统计数据如下所示。同时我们也按照标签不同分类对打标结果做了更加精细的分析：

业务应用

▐ 下游推荐算法链路

图11 标签在淘宝不同场景投放算法中的应用

全屏页召回链路

全屏页召回链路应用 （均已全量）：

冷启动：增加原子标签+短语标签召回路，完播率+18%
冷启动：增加短语标签相似关系召回，完播率+3%
主链路：增加原子标签+主题标签召回，有效vv+2%, 七天新视频vv+3%
主链路：增加短语标签相似关系，有效vv+1.5%, 七天vv提升3%, 商家视频占比+5%

逛逛召回链路

语义向量召回 (已全量)

使用视频标签、title作为视频侧表征训练视频召回深度语义DeepV2V，指标如下：

pctr +1.04% uctr +0.4% 人均时长持平，人均点击+1.1%，人均曝光+0.5%；

整体指标：pctr +1.2% uctr +0.45% 人均点击+1.36% 人均曝光+0.4%；

新鲜度指标：30d+发布的视频数量 +2%, 1-7d -4%；

曝光度指标：0-200vv视频数量：+16%，200-2k: +4%，20w+: -2%；

多样性指标：唯一视频数量+4.2%。

▐ 标签的前台透出

在首猜全屏页中，我们使用话题对视频进行圈选，在全屏页透出，基于认知主题知识，构建底bar话题标签体系，目前线上投放话题 12w，覆盖视频vv 58%，覆盖uv 1000w+, uv_ctr 1.4%。目前已全量。

图12 短语标签在淘宝不同场景透出的效果展示

▐ 用户的数据反馈

在完成全屏页全量后，每天会产生10w左右的视频-话题点击pair对，我们将上线后的点击反馈数据收集起来，形成线上透出，线下收集数据重新训练模型。

图13 线上用户数据反馈到排序模型数据流向图

最终在排序模型中，加入线上反馈数据后，AUC有3%的提升。

总结与展望

在视频内容标签接近两年的建设中，完成标签库的结构化管理，维护百万级别标签库，同时形成了“召回+排序”的算法打标流程。在下游搜索推荐算法、标签外透产品、运营圈选工具都取得了不错的业务效果。未来希望完成标签更全面的图谱化结构设计，不仅完成标签的识别，更能做到标签、内容、用户之间的认知和推理，相信有了关系、节点丰富多样的图谱化结构，会使视频内容理解如虎添翼。

Reference

[1] Peter Anderson, Xiaodong He, Chris Buehler, Damien Teney, Mark Johnson, Stephen Gould, andLei Zhang. Bottom-up and top-down attention for image captioning and visual question answering. In Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition, pp.6077–6086, 2018.

[2] Hao Tan and Mohit Bansal. Lxmert: Learning cross-modality encoder representations from transformers. In Proceedings of the 2019 Conference on Empirical Methods in Natural Language

Processing, 2019.

[3] Liunian Harold Li, Mark Yatskar, Da Yin, Cho-Jui Hsieh, and Kai-Wei Chang. Visualbert: A simple

and performant baseline for vision and language. arXiv preprint arXiv:1908.03557, 2019b.

[4] Gen Li, Nan Duan, Yuejian Fang, Daxin Jiang, and Ming Zhou. Unicoder-vl: A universal encoder

for vision and language by cross-modal pre-training, 2019a.

[5] Su W, Zhu X, Cao Y, et al. Vl-bert: Pre-training of generic visual-linguistic representations[J]. arXiv preprint arXiv:1908.08530, 2019.image-20191107143317330.pngimage-20191107151306644.png

[6] Chen Y C, Li L, Yu L, et al. UNITER: Learning UNiversal Image-TExt Representations[J]. arXiv preprint arXiv:1909.11740, 2019.

[7] Zhou L, Palangi H, Zhang L, et al. Unified Vision-Language Pre-Training

for Image Captioning and VQA[J]. arXiv preprint arXiv:1909.11059, 2019.

[8] Peng, Y. , and J. Qi . "CM-GANs." ACM Transactions on Multimedia Computing, Communications, and Applications (TOMM) 15.1(2019):1-24.

[9] Portillo-Quintero J A , Ortiz-Bayliss J C , H Terashima-Marín. A Straightforward Framework For Video Retrieval Using CLIP[J]. 2021.

[10] Xu, R. , et al. "A Proposal-based Approach for Activity Image-to-Video Retrieval." (2019).

[11] Tan, M. , and Q. V. Le . "EfficientNetV2: Smaller Models and Faster Training." (2021).

[12] Miech, Antoine , et al. "Thinking Fast and Slow: Efficient Text-to-Visual Retrieval with Transformers." (2021).

[13] Li, W. , et al. "UNIMO: Towards Unified-Modal Understanding and Generation via Cross-Modal Contrastive Learning." (2020).

[14] Chen, S. , et al. "Fine-grained Video-Text Retrieval with Hierarchical Graph Reasoning." IEEE (2020).

[15] Wray M , Doughty H , Damen D . On Semantic Similarity in Video Retrieval[J]. 2021.

[16] Yuan, L. , et al. "Tokens-to-Token ViT: Training Vision Transformers from Scratch on ImageNet." (2021).

作者 |云未
编辑|橙子君 出品|阿里巴巴新零售淘系技术

END,入群👇备注： 视频

IoT物联网时代怎么挣钱？_阿朱=行业趋势+开发管理+架构-CSDN博客

Wed, 08 Sep 2021 07:52:25 CST

元宇宙、全真互联网、数字孪生、CPS、工业互联网、可穿戴设备、智能硬件，现在好多词。

（1）应用场景

场景有很多：

1、智能消费：智能产品、智能家居家电、人可穿戴设备

2、智能交易：智能营销、智能零售商店、智能供应链、智能仓储物流

3、智能生产：智能生产设备、智能安环与消防、智能农业种植养殖

4、智能城市：智能汽车与智能交通、智能能源与智能地下管网、智能建造与智能建筑、智能办公空间

（2）基础技术支撑

我随手画了张图，给大家呈现端-管-边缘-云这四个环节的技术体系。

一、端

1、芯片【核心】：我关注RISC-V开源CPU、FPGA可编程芯片

2、模组：我关注Arduino、树莓派

3、操作系统软件【核心】：我关注Fuchsia、FreeRTOS

4、传感器、摄像头、GPS

5、数据网关硬件【核心】：这是数据集中出口

二、管

1、传输软件【核心】：消息传输中间件

2、传输硬件：5G、通信网关

三、边缘

1、IoT接入平台【核心】：这是数据集中入口

2、时序数据库软件【核心】

四、云

1、智能处理【核心】：AI处理非常有门槛

2、应用开发：快速低代码开发工具

3、数字孪生【核心】：数字孪生仿真可视化。中国人不适应数据解读，挺喜欢数据可视呈现

4、数据存储：大数据湖仓

5、云计算

（3）商业模式

刚才咱们第一节就穷举了许多场景，说明市场还是很广阔的。

但这一定是个系统软硬件集成的解决方案，尤其是各行各业都有各种迥异繁多的传感器和自动化部件，怎么大规模标准化地挣钱，这是个需要精心设计的。

我想了想，可卖的东西可能是以下这些：

一、硬件

1、端上芯片、模组

2、端上数据网关

端上操作系统软件虽然是核心，但只能开源、免费了。

3、边缘IoT接入平台：我不容易想出怎么销售/收费/计价这个东西。我目前能想到的只能是软硬一体机边缘服务器

二、软件

1、管上消息传输中间件软件

2、边缘上时序数据库软件

以上两个软件大家都很常见，按主流模式销售/收费/计费就好。

三、服务

1、AI智能处理服务：这按调用次数来收费是非常惯例的。

四、生态

1、生态硬件解决方案合作

2、硬件集成交付生态：硬件安装、数据接出，都需要服务生态

3、数字孪生可视化开发生态：数字孪生可视化软件这个工具很好，但不如消息传输中间件和时序数据库软件拿来就能用的。所以这肯定要发展生态了。靠生态抽水可能会更佳

4、具体应用开发生态

这都需要生态。不搞生态，根本做不了。

这是在IoT物联网时代，必走的商业模式。

IT瘾管理推荐

agentic coding 本质上是文档管理的艺术

互联网公司的管理神话破灭

管理大型 Postgres 数据库的 3 个技巧

大表

添加列

添加约束条件

想了解更多？

非一线工程管理者的一对一沟通

(工程)管理者的上级有什么不同点

上级管理者一对一沟通的特点

重要方面和特点

总结

参考文献

参考资料

微软的vscode 研发流程项目管理是如何做的？

Project Management

Roadmap

Iterations

Planning

Definition of Done

Inside an Iteration

Triage

Weekly

End Game

网易云音乐全链路埋点管理平台建设

一、背景

二、平台现状介绍

三、我们遇到的问题和痛点

四、埋点质量建设

1、建设实时埋点校验功能，从源头解决埋点质量问题

2、建设线上埋点稽查功能，发现存量埋点问题并推进解决

五、埋点效率建设

六、研发中埋点自动Rebase到最新Master

七、埋点跨空间打通

八、未来规划

馬斯克希望部屬學會的「向上管理」，四招讓你在職場上大展身手

馬斯克指出 「向上管理」重要性

討好上司？ 為什麼需要向上管理

不懂帶人就自己做到死，主管的向下管理學

向上管理中需要告诉老板什么

什么拖慢团队前进的速度

团队中的每个人在做什么

技术风险在哪

如何才能帮助你更好的做的你的工作

什么问题需要向上升级才能解决

你在做什么额外的工作

超干货！彻底搞懂Golang内存管理和垃圾回收

（一）Page

（二） Span

（三） ThreadCache

（四）CentralCache

（五）PageHeap

（六）TCMalloc对象分配

（一）Page

（二）Span

（三）mcache

（四）mcentral

（五）mheap

（六）内存分配

（一）标记-清除

（二）三色可达性分析

（三）gc触发

（四）gc过程

参考资料：

技术管理者的 4 个基本思考点

1. 把正确的人放到合适的岗位

1.1 选人

1.2 用人

1.2.2 人才梯队

1.2.2 艰难的决定

1.3 管理者自己

2. 组织

2.1 设计组织结构

2.2 组织的形态

2.3 分工的粗和细

3. 机制

3.1 DRI 机制

3.1.1 DRI 的由来

3.1.2 DRI 的职责

馬斯克指出「向上管理」重要性

討好上司？為什麼需要向上管理