谈工作心得
制定原则：手中无刀，但你的心中要有刀
软件工程和技术领域里虽说法无定法，需求和流程随便怎么做都可以，但也并非可以天马行空恣意妄为，稍不留意就可能天塌地陷墙倒屋塌，酿成不可收拾之惨剧。下面我就说道说道。
2020年1月底2月初，首都医科大学附属复兴医院出现医护人员感染新冠肺炎事件，最终累计确诊34人，既有医护也有患者和家属，原因也非常“感人”：一位有武汉接触史的老太太，本来属于“新冠肺炎疑似病例”在发热门诊看病，但却突发奇想，通过院领导的关系，托关系找心内科ICU主任韩某，愣是从防护森严的发热门诊病房转进了云淡风轻的心内科ICU，结果横扫一片。
我一直说，工程师团队和医护团队都是专业领域机构，管理方式有相似之处。那么在这个案例里，管理者犯了什么错误？心中无原则！
心中无原则，会有一百万种死法。
原则！专业团队的管理者心中一定要有原则，你有了原则，才能要求大家“讲政治，守规矩”！同样，在做设计的时候，先把设计愿景、设计分阶段目标、设计原则写下来，在此基础上画地为牢再做设计推演，莫要天马行空恣意妄为。手中无刀，心中有刀。
作为管理者，如果不讲原则，没有规范，无法做好管理。下面的人会无所适从，因为原则天天变，今天这样，明天又那样，毫无章法。下面的人不知道往哪里重点使劲，事情就会变得一团糟。
不，没有什么法无定法，技术的世界里一定是有法则的，否则你会死得很难看，别指望我来救你，我救都救不赢。
You！Leaders！一定要通过层层叠加的“Rules”建立起本能反应，一遇到类似的事情，应激般的就知道该怎么设计，怎么行动，怎么救火。 而这些“Rules”是经历了血与火的洗礼铸造的，每一条都有来由有去路。 比如说，我在2018年定义的 DevOps 新八荣八耻，每一条都是血肉长城：
- 以随时可扩容、可缩容、可重启、可切换机房流量为荣，以不能迁移为耻。
- 以可配置为荣，以硬编码为耻。
- 以系统互备为荣，以系统单点为耻。
- 以交付时有监控报警为荣，以交付裸奔系统为耻。
- 以无状态为荣，以有状态为耻。
- 以标准化为荣，以特殊化为耻。
- 以自动化工具为荣，以人肉操作为耻。
- 以无人值守为荣，以人工介入为耻。
如何自建法则？ 从错误中学习错误！
『学校里学习最好的学生可能往往是那些最不善于从错误中学习的人，因为他们已经习惯了把错题当成失败的代名词，而不是把犯错看成学习的机会，这反而成为他们进步的主要障碍。走入社会之后，聪明的人必须善于拥抱自己的错误和不足，从而能远远超过那些与他们水平相当，但更自负的同学、同辈。』 这也就是为什么平凡人可为非凡事的缘故！ 『不要患得患失，要朝着目标努力前行。要自省自警，别人对你很到位的批评，是你能得到的最宝贵的建议。想想看，你的滑雪教练告诉你，你摔跟头是因为你滑行中的重心移动不对，此时你要是认为他在责骂你，你该多么愚蠢和低效。同理，你的上司，我，也可能会指出你工作中的缺点，有则改之，继续努力就是了。』 等有一天你依据本能（也就是你自建的法则）行事的时候，你肯定会把事情做得很好！
技术团队成龙成虫的秘诀
团队的观察者效应
错误会演变成什么，取决于你怎么看待它。你觉得它是羞耻，应该隐秘于人，最好绝口不提，那么它就会变成它它它它它它它，最终变成大灾难。你觉得它是财富，是组织进步的好机会，是推行工具和规范的切入点，那么它就会真的成为团队的不可磨灭的传承，成为宝贵财富。
错误的观察者效应： 你认为错误是财富，它就是宝贵财富。 你认为错误是失败，它立马变成灾难。 其实还有一种观察者效应。 团队的观察者效应：** 你认为团队是财富，它就是财富。 你认为团队是成本包袱，它立马变身包袱。
2017年，有赞CTO崔玉松说，我想打造出中国最好的技术团队。
技术上，有赞走过的路和大多数从小到大的创业公司差不多，都是前期专注于解决业务问题，最后架构问题在某个时间点集中爆发，导致很多的不稳定。这一点不管是阿里也好，京东也罢，还是最近交流的一些其他公司，基本上都是一样的，只是大家问题的严重程度和解决问题的速度不一样。有赞的解决方法和大家也没什么太大区别，就是组建一流底层核心架构和核心运维团队，这个团队必须得好，不然解决问题的速度非常非常慢，每天都可能宕机，会严重影响公司业务及效益。 日常业务中，我们非常鼓励大家相互补位，有问题及时寻找资源，及时获取有效的信息，鼓励大家面对面把事情说清楚。 ——2017，有赞CTO崔玉松：我想打造出中国最好的技术团队
2020年，现在来看，他可能确实做到了，有赞的技术底蕴非常强。当然上面还有一层美团，再上面还有一层阿里巴巴。
愿景初心很重要。
有的人愿景就是活下去，那么年复一年日复一日始终挣扎在生死边缘。 有的人愿景就是用三五个人做一个赚钱的小公司，那么也挺好，他能这样过一辈子。 有的人没有愿景，所以他死了。
阿里巴巴的“此时此刻，非我莫属”确实牛逼，99年就有了，可以说是阿里巴巴第一句土话。
专业的人做专业的事
我以前讲过职场（潜）规则，其中一条叫“听原始需求，不听技术解决方案”，原文如下： 『我发现很多做业务的人一方面搞不清楚什么叫原始需求，甚至连整个业务体系是怎么运转起来的都懵懵懂懂，听他说了半天，原来是在讲他认为技术上怎么解决。 另一方面他们还挺喜欢越俎代庖，原始需求还吭吭哧哧说不清楚呢，就直接拍方案，甚至迫不及待地替我们想数据库是不是加字段…… 对此，我的标准回答是：“请直接说原始需求，请不要给我讲解决方案”。 潜台词就是，你有你的专业领域，我有我的，赢得别人尊重的前提是先把自己的本职工作做好。 ** 在专业领域里，千万不能让外行领导内行！ 我发现好多做管理的都不知道这一条，总觉得我做管理的能管天下万事万物。扯淡！ **
线上故障处理总结
线上故障处理口诀： 遇事不乱，分头核查，群里同步，简单陈述，绝不恋战，恢复服务。 ** 具体解释一下。
分头核查：QA负责线下复现现象，确认问题是否存在；SA负责核查业务对应的机房、数据库、内外网流量、应用负载有无变更操作、有何异常指标。
绝不恋战：如果迟迟定位不了问题（比如五分钟之内），就不可恋战，必须快速恢复业务。第一，不要把生产环境当成测试环境，不要在线调试；第二，不要一直留着现场观察来观察去。
简单陈述：出了事儿一定各方面都动员起来了，七嘴八舌，各说各话，这时候一定要有一个临时总指挥不断地总结大家现在的进度，做精炼的“简单陈述”，发在群里，相当于一个新闻发言人。他在第一时间出来做简要综述，把WHEN/WHO/WHAT/HOW/RESULT几句话说清楚，同步给核心干部。不要点对点。请务必广播。表明我们在跟，我们在解决，所有事情都在掌握中，别怕，别慌。
没有预见性你凭什么晋升
什么是预见性？
- 市场竞争态势的预见性。
- 有没有对市场大势有一定预见性？
- 是不是时刻在关注着友商、竞品和行业动态？
- 能不能对业务做出有前瞻性的预测？
- 举例：本地生活服务市场，大的市场变化趋势是，点评—>团购—>外卖—>买单和下码—>铺机具构筑IoT壁垒—>切ERP—>带货和保理……
- 业务上的预见性。
- 需求方说什么就是什么吗？
- 产品设计成什么样就做成什么样吗？
- 一切都是顺水推舟吗？
- 你有没有力排众议，提出自己的观点和方案，而且最后事实证明你说的做的是对的？
- 技术上的预见性。
首先，技术领域瞬息万变，昨天的技术新趋势，明天就成为行业标杆的标准解决方案。低头拉车之余，必须抬头看路。Docker从2014年的微热，到2015、2016年一线互联网公司的标配，仅仅一两年时间。 其次，单一技术趋势，并不能承载中大型团队，不能承载剧烈变化的业务，我们对此需要有一个基本的判断。比如说微服务的前提是Docker容器化、服务路由和平台自动化。Docker集群编排+研发协作可视化+运维自动化+API网关+微服务，才谈得上可负重前行。 再次，当业务从零到一的时候，我们需要有一定的预见性，走一步看两步。 举例：业务刚开始试点的时候，我就预见到IoT机具铺设在全国各地，所有问题都将由我们兜底，所以必须以最快速度建设一个强大的设备强管控运维管理平台，它将是大中台体系的重要组成部分。 举例：随着业务的深入，我预见到由于机具的各种业务方都会给机具下发指令（上行和下行），比如支付成功语音播报，比如应用版本分发，比如快速改变机具上App内部状态，业务方不关心也不需要关心机具在不在线，所以我决定尽快引入设备影子，在业务方还不足够多的时候一劳永逸地解决这个问题。 做技术千万不要脚踩西瓜皮，滑到哪里算哪里。
我司研发文化=
研发哲学（Don't make me think/If it hurts, do it more and often/这个世界从来没有什么救世主/没有苦劳只有功劳/一定要有后备方案） +研发三循环方法论（研发能力/研发效率/研发活力） +研发三板斧（RCA/技术分享讲座/技术预研课题） 每一个研发组织都必须想着念着做着。
Don't make me think
大家都知道，技术人员从事的是创造性工作，加之是单核处理器，我们的上下文切换非常困难，被打断后从新进入“神游”状态往往需要十几分钟。尤其是研发经理，承担更多的责任，线上线下的问题都要照顾到，还要解答内外的各种咨询，工作时间碎片化严重。我们（包括系统）给出的信息，一定要足够简练，一目了然，让人很容易克服焦躁情绪，啪啪地就处理了，或者啪啪地二次分发出去。 不要让无用的信息折磨这些人。
其次，技术人员是“世界”的构建者，不得不做大量琐碎且枯燥的工作，其中，相当大比例的工作是重复性的，如修改配置文件适配不同环境，如打包。 重复的工作一方面容易出错，尤其是在通宵上线时，另一方面消磨人的耐心和斗志。 我在《职场培训第五期：职场的真相》中讲过解题思路：『要摒弃单纯依靠员工之间互相提醒、依靠个人认真细致来规避相同错误的固有思路，铁打营盘流水兵，靠人终归是靠不住的，最好靠遵循规则的机器』。 王淮在《以 Facebook 为案例剖析科技公司应有的工具文化》一文中谈及，基本理念就是凡是被很多人不断重复的好习惯，要将其自动化，绑定到工具之中，以"Don't make me think"的方式来推广最佳实践（best practice）。
基于以上原因，我们认为，凡是被不断重复的过程，将其工具化，绑定到自动化流程之中，减少不必要的心智负担。 这也就是过去几年里我们一季季地推进持续集成（Continuous Integration，CI）的原因，把我们的经验教训变成可重复的规则，融入工具中，融入自动化流程中，而不是一代一代口口相传。
好了，在举具体的例子之前，让我们大声读出这几条 Slogan：
- Don't make me think!
- 减少不必要的心智负担！
If it hurts, do it more and often
我们不能死于听天由命和漫不经心。 工程师为什么会听天由命？
- 因为线上日志里的异常实在是太多了，处理不过来。
- 因为异常太多了，淹没了致命异常，以至于服务挂得死死的才发现问题已经存在N久了。
- 因为明天就要提测了，代码合并冲突还有几千个。
- 每到常规版本提测时就心里打鼓，合并个代码都得预留两天时间。
- 因为画时序图好烦，所以复杂系统的数据流转靠“心算”、靠文字描述。
- 人脑容易有思维死角，一个考虑不到，系统就防不住并发提交和重复提交。
- ……
因为已然集腋成裘，所以做事前我们各种纠结和抵触，于是找各种理由拖延。 怎么办？ 我在《职业化的7个细节》里讲到， 如果一件事做起来很烦，那就把它拆成很多块儿，每天做一点，每次做一点。
这个世界从来没有什么救世主
这个哲学我过去几年里一而再再而三地讲。在《职业培训第五期：职场的真相》中，我说：过去几年里，我们深深地体会到，从来就没有什么救世主，要创造人类的幸福全靠我们自己，不要指望有什么人能救我们，只能绞尽脑汁闯阵。
为什么？ 技术团队是互联网公司里最认真最专业最实操最靠谱的一群人，如果我们凡事都要指望别人给我们解决方案和思路，指望别人比我们更认真，那这个公司就危在旦夕了。 所以，我在2012年的飞行研讨会上抛出两个 Slogan：
- 抛掉幻想，勇敢面对！
- 直面白刃战！
基于这个哲学，我们衍生出两个 Slogan：
- 不要等死！
- 向前迈半步对接！
一定要有后备方案
灾难，总是在你意料之外。 一个后备方案， 最后一条让你起死回生的路。
早年间，侯小强曾经说过： 如果你在职场，需要有三个好习惯，1，能马上做的事情马上做。2，每个事情要有始有终。3，要有这个习惯思维，没有苦劳，只有功劳。但如果没有极其努力，通常也不会有功劳。 延续着这个思维，我们过去几年里反复强调：没有结果就没有意义。不要期望公司因为你和小伙伴们有苦劳而宽容你们没有产出，这是一个商业公司。
DevOps 新八荣八耻，每一条都是血肉长城
- 以随时可扩容、可缩容、可重启、可切换机房流量为荣，以不能迁移为耻。
- 以可配置为荣，以硬编码为耻。
- 以系统互备为荣，以系统单点为耻。
- 以交付时有监控报警为荣，以交付裸奔系统为耻。
- 以无状态为荣，以有状态为耻。
- 以标准化为荣，以特殊化为耻。
- 以自动化工具为荣，以人肉操作为耻。
- 以无人值守为荣，以人工介入为耻。
核心业务流程的故障处理原则：不可恋战
第一时间叫多人一起分头查：查机房，查流量，查应用性能，查数据库，查Redis。 如果迟迟定位不了问题（比如十分钟之内），就不可恋战，必须恢复业务（三板斧）： 第一招重启应用， 第二招回退版本， 最后一招是异地多活切机房流量，把受影响的商户切到另一个机房的单元格里。 千万别在定位问题上花太多时间。
当我们谈重构的时候我们想谈什么
如果你在繁忙的业务迭代中开始系统重构，恭喜你，说明你的业务已经完成了从0到1，正在从1走向10，或者从10走向100。
两个“是否有利于”： 一，是否有利于发布部署。 二，是否有利于排除故障（是否有利于快速定位问题和解决问题）。
两个戒律： 戒律一：凡是中间件，不管是自主开发的，还是以开源软件为内核构建出来的，都必须自带监控报警，否则不允许上线。 戒律二：本着 Don't make me think 的哲学思路，所有对排除故障有帮助的信息，都必须一站式展示在交互界面上，也就是中间件的控制台上，或运维自动化平台上，或研发协作平台上。
要熟练掌握的七个人生工具
一、SWOT分析法：
- Strengths：优势
- Weaknesses：劣势
- Opportunities：机会
- Threats：威胁
- 意义：帮您清晰地把握全局，分析自己在资源方面的优势与劣势，把握环境提供的机会，防范可能存在的风险与威胁，对我们的成功有非常重要的意义。
二、PDCA循环规则
- Plan：制定目标与计划；
- Do：任务展开，组织实施；
- Check：对过程中的关键点和最终结果进行检查；
- Action：纠正偏差，对成果进行标准化，并确定新的目标，制定下一轮计划。
- 意义：每一项工作，都是一个pdca循环，都需要计划、实施、检查结果，并进一步进行改进，同时进入下一个循环，只有在日积月累的渐进改善中，才可能会有质的飞跃，才可能取得完善每一项工作，完善自己的人生。
三、6W2H法
**
- What：工作的内容和达成的目标；
- Why：做这项工作的原因；
- Who：参加这项工作的具体人员，以及负责人；
- When：在什么时间、什么时间段进行工作；
- Where：工作发生的地点 ；
- Which：哪一种方法或途径；
- How：用什么方法进行；
- How much：需要多少成本？
- 意义：做任何工作都应该从6W2H来思考，这有助于我们的思路的条理化，杜绝盲目性。我们的汇报也应该用6W2H，能节约写报告及看报告的时间。
四、SMART原则
**
- Specific 具体的；
- Measurable 可测量的；
- Attainable 可达到的；
- Relevant 相关的；
- Time based 时间的；
- 意义：人们在制定工作目标或者任务目标时，考虑一下目标与计划是不是SMART化的。只有具备SMART化的计划才是具有良好可实施性的，也才能指导保证计划得以实现。
- 特别注明：
有的又如此解释此原则： ——S代表具体(Specific)，指绩效考核要切中特定的工作指标，不能笼统； ——M代表可度量(Measurable)，指绩效指标是数量化或者行为化的，验证这些绩效指标的数据或者信息是可以获得的； ——A代表可实现(Attainable)，指绩效指标在付出努力的情况下可以实现，避免设立过高或过低的目标； ——R代表现实性(realistic)，指绩效指标是实实在在的，可以证明和观察； ——T代表有时限(time bound)，注重完成绩效指标的特定期限。
五、时间管理-重要与紧急
**
- A、重要且紧急
紧急状况 迫切的问题 限期完成的工作 你不做其他人也不能做
- B、重要不紧急
准备工作 预防措施 价值观的澄清 计划 人际关系的建立 真正的再创造 增进自己的能力
- C、紧急不重要
造成干扰的事、电话、 信件、报告 会议 许多迫在眉捷的急事 符合别人期望的事
- D、不重要不紧急
忙碌琐碎的事 广告函件 电话 逃避性活动 等待时间 优先顺序=重要性*紧迫性 在进行时间安排时，应权衡各种事情的优先顺序，要学会“弹钢琴”。 对工作要有前瞻能力，防患于未然，如果总是在忙于救火，那将使我们的工作永远处理被动之中。 **
六、任务分解法[WBS]
即Work Breakdown Structure，如何进行WBS分解：目标→任务→工作→活动 WBS分解的原则： 将主体目标逐步细化分解，最底层的任务活动可直接分派到个人去完成；每个任务原则上要求分解到不能再细分为止。 WBS分解的方法： 至上而下与至下而上的充分沟通； 一对一个别交流； 小组讨论。 WBS分解的标准： 分解后的活动结构清晰； 逻辑上形成一个大的活动； 集成了所有的关键因素包含临时的里程碑和监控点； 所有活动全部定义清楚。 意义：学会分解任务，只有将任务分解得足够细，您才能心里有数，您才能有条不紊地工作，您才能统筹安排您的时间表。 **
七、二八原则
巴列特定律：“总结果的80%是由总消耗时间中的20%所形成的。”按事情的“重要程度”编排事务优先次序的准则是建立在“重要的少数与琐碎的多数”的原理的基础上。 举例说明： 80%的销售额是源自20%的顾客； 80%的电话是来自20%的朋友； 80%的总产量来自20%的产品； 80%的财富集中在20%的人手中； 这启示我们在工作中要善于抓主要矛盾，善于从纷繁复杂的工作中理出头绪，把资源用在最重要、最紧迫的事情上。
提高提测质量
QA的职责不是开发写完扔给人家测试，这是偏见，也是好多开发人员一直有的错误的观念，QA 不是简单的验证功能性的（当然存在这种AQ），QA更多是验证程序的健壮性、容错性，所以在我们这里应该保证程序最基本的功能性问题，减少代码的回溯，这样才能不影响产品的迅速迭代，不影响产品的推进。
先写文档再写代码
好多程序员的通病就是拿到需求就开始写代码，这是相当的不负责任的，很明显这种做法有问题。应该先写自己的思路，如果功能大一些，要先写方案，评审方案。思路、方案没有问题在动手去写代码，你会发现坑会少踩好多。
一个程序员的价值是解决问题的能力
技术越好解决问题的能力越强，这个没有问题，这是一个正向比例关系。但是解决问题的能力，不仅仅包括技术，也包括沟通、业务等等其他方面。在工作中，不要仅仅的去学习各种编程技术，也要学会沟通、业务。
注意流程、规范
尤其是管理人员、组长、高程，一定要主要流程和规范，没有流程和规范就是一群乌合之众，没有任何战力可言。有了流程和规范，10个人可以做20个人的工作；没有流程和规范，20个人顶多也只能做10个人的工作，且不会有任何可维护性。