<阿里工程师的自我素养>读后感-技术人应该具备的一些基本素质
一、技术人具备”结构化思维”意味着什么？
1、什么是结构化思维？
结构化思维：逻辑+套路。
表达要有逻辑，所谓逻辑是指我们的结构之间必须是有逻辑关系的。
四种组织思想的逻辑关系 ：
1、演绎顺序（因果）：大前提、小前提、结论的演绎推理方式就是演绎顺序。
2、时间顺序（步骤）：第一、第二、第三；首先、然后、再者等，很多的时间顺序同时也是因果顺序。
3、空间顺序（结构）：前端、后端、数据；化整为零等都是空间顺序。
4、程度顺序（重要性）：比如最重要、次重要、不重要等。
做事要有套路：套路是指我们解决问题的方法论。
5W2H分析法，你都能从why、who、when、where、what、how和how much 七个方面去思考。
对问题域进行分析和领域知识提炼的时候，就可以用上5W2H。
2、如何进行结构化思考？
逻辑性和方法论是结构化思维的底层，那么如何进行结构化思考呢？
首先是建立中心，然后在进行分解。
建立中心：定义清楚要解决的问题，要明确目标，是我们结构的顶层节点，也是一种以终为始的思考方式。首先，要搞清楚why,然后在进行how.建立中心有两种方式：
1、自上而下：适用于问题比较明确的情况，我们只需要找到问题的核心要素即可，然后进行展开即可。
2、自下而上：对于问题不够明确的情况，我们需要对多种杂乱的内容，进行分类、剪枝、归纳汇总成一个中心。
比如：系统bug多，向上抽象是提升代码质量、向下抽象是加强测试，都可以作为中心，选择哪个中心取决于你当前要解决的问题是什么。
结构化分解：
确定完中心后，我们需要构建一个结构，使用结构化的思维对问题进行分解。分解的策略就是我们上文提到的四种逻辑顺序，即演绎顺序、时间顺序、空间顺序和程度顺序。
在做空间分解的时候，要注意满足MECE(Multually Exclusive Collectively Exhaustive,相互独立，完全穷尽)原则。
3、结构化思维应用
1、如何落地新团队？
结构化思维来理清思路，对于企业来说，核心要素无外乎就是业务、技术、人。
1. 熟悉业务
1）了解产品：任何一个团队都有自己要负责的产品，申请一个测试账号去用一下产品，是熟悉产品比较好的方式。
2）了解流程：任何业务都有自己的业务流程，而业务流里面最核心的是信息流。我们可以通过人员采访，了解关键节点的信息输入和信息输出；可以画一些泳道活动图，理清楚系统的主要角色，以及他们之间的交互关系。
3）客户走访：通过走访客户，我们可以更加获得业务的第一手资料，更加贴近业务和客户诉求。
★ 2. 熟悉技术
1）了解系统架构：可以让团队的技术人员介绍下他们当初系统设计和架构的思路。
2）了解领域模型：查看关键的核心表结构和系统 API，这样可以快速了解系统的领域模型。
3）了解代码结构：下载系统工程，熟悉整个工程结构和模块职责。以一个最重要的流程为入手点，阅读代码，看清楚核心的执行逻辑。做一个小需求，掌握相关的流程和权限。
★ 3. 熟悉人
1）了解组织结构：查看公司的组织树，知道公司大概是如何运作的，以及哪些是KP（Key Person，关键人）。比如，一个典型的电商公司会包括产品部、运营部、销售部、技术部、人力资源部、财务部、法务部等。
2）了解人员角色：了解公司都有哪些岗位，以及各岗位的职责范围。
3）拜山头：找到和自己工作息息相关的岗位人员，比如产品和运营。积极和他们沟通，向他们请教业务问题，多多交流。这样一方面可以建立更好的人际关系，另一方面也可以更快地熟悉业务。
2、如何做述职？
1、罗列问题：结构化的表述：提出问题，定义问题，分析问题，解决问题，最后是展望未来。
2、价值的背后：我主导研发的风控系统把公司的坏账率从 5% 降低到 2%,会被问：
1. 之前为什么那么高？
2. 为什么你的方法可以降低？是如何归因的？
3. 具体解决了什么问题？
4. 是否可以总结出一套办法，以后别人也能用这个办法解决这些问题？
对这些问题进行深入思考和适当呈现。
二、优秀工程师必备的三大思维，你拥有哪些？
1、产品思维
产品思维的起源是用户（或客户）价值。用户价值是通过技术手段以产品或服务的形态去解决用户的痛点，或带去爽点。
2、技术思维
技术思维的源头是需求。需求可以分成市场需求、系统需求、特性需求等不同层次，回答的是技术层面“做什么”的问题。显然，清晰表达的需求以及对需求的精确理解才能确保将事做对。
3、工程思维
工程思维的起点是流程。流程的背后是科学，以既定的步骤、阶段性的输入、输出去完成价值创造，通过过程控制确保最终结果让人满意。由于流程涉及每一个工程师的工作质量与效率，其含义不只在于定义、工具化、检查等内容，而是应基于工程师的日常工作习惯，将流程与工程师的工作环境无缝整合。
机制的含义是通过对所需解决问题的分析，以一种模式去解决同类问题。机制应体现一定的系统性，而非“头痛治头，脚痛治脚”。系统性不是一开始就能被洞察到，可能在演进的过程中逐步发现和完善的，因而需要工程师在工作的过程中不时回顾并付诸实践去落实。
三、优秀工程师必备的一项技能，你解锁了吗？
1、思考力
《金字塔原理：思考、表达和解决问题的逻辑》、《麦肯锡教我的思考武器》、《思维的本质》。
2、原理性思维
学习最重要的思考力：原理性思维、结构化思维
1、原理性思维：找出知识背后的原理
- 可以大幅度降低我们对于知识的记忆量，知识量是爆炸的，但是原理绝对是可控的
- 原理性的东西比直接的知识有更强的复用度。
- 探求原理的过程，本身很有乐趣。
如何在工作中去运用和学习这些原理，最佳实践如下：
- 对你可能用到的领域知识，建立一个基本的概念(看书、看视频、找行业资深人员)
- 多问一下问什么，并一直刨根问底(找到场景和原理的关联关系)
- 在实践中运用一下
- 结合经典的书籍系统化学习
按我们团队的实战经验来看：
1.java，linux，数据结构和算法，数据库，网络通信与分布式计算的原理，这几类是比较重要的基础知识，我们在做方案设计、编码、问题排查中会运用得很多；
2.设计模式，UML 这个是对系统架构设计必要要掌握的知识，当你经历了很多大规模的软件系统设计，回到根本上，你会发现逃不出这一块的理论和工具；
3.领域性的基本原则，比如我们上面提到的“钱货平衡”，“财务平衡公式”，“线下收银让消费者最快速度走人”，这种逻辑需要大家 get 到这些领域性的设计原理，甚至自己去总结出这种原理；
4.关于管理学，人际沟通，心理学的一些基本原理，大家可以按照自己的实际需求去看一下。
3、结构化思维
结构化思维：构建自己的知识树。
知识树要解决的问题，我们看一些场景：
- 1. 为什么我知道很多东西，但是当场景来的时候老是会记不起来使用；
- 2. 完成一个方案你只能想到一些点状的手段，还有其他方案被漏掉了；
- 3. 讲一件事情的时候逻辑非常混乱，前后没有逻辑性关联。
原因：知识学习中“索引”没有建立，也就是说，你的知识只有点，没有线！
如何熟悉一个新系统，我的步骤是：
- 1. 要一个测试账号，把相关功能走一遍，这样能非常快地了解一个系统的功能；
- 2. 看关键的核心表结构，这样可以快速了解系统的领域模型；
- 3. 根据功能步骤找到系统对外的接口列表，了解系统的 L0 业务流程；
- 4. 下载系统工程，熟悉整个工程结构和模块职责；
- 5. 以一个最重要的流程为入手点，阅读代码，看清楚核心的执行逻辑，可以变看边画时序图；
- 6. 制造一个 debug 场景，以 debug 方式走一遍流程，这样可以实际加深一下对系统的理解；
- 7. 做一个小需求，掌握相关的流程和权限；
如何训练出自己的知识树呢？
- 1. 一定要总结出自己的知识树，而不要盲从书本上的或者别人的，为什么呢？
- 2. 习惯性总结，做完任何一个事情，都习惯性地回顾一下，往自己的树上面挂新东西，这个是构建知识树的必备手段，这个总结不需要花很多时间，比如做完事情后花个几分钟回顾一下就可以，但是需要坚持；
- 3. 推荐一个很常见的工具：xmind，把自己的树记录下来；
- 4. 训练自己的思维习惯和做事方式变得结构化，当你做事情的时候，习惯性用树的方式推进，强迫自己按照这个方式来。
4、扩展性思维
扩展性思维：举一反三，拓展思维，扩展性思维的核心目标是提升我们思维的广度。
（1）举一反三：解决同类型的 N 个问题
（2）寻求更多的可能性：拓展解决问题的不同手段
5、抓重点思维:提交效率，方便记忆和传递
抓重点思维要解决的场景是：
- 1. 如果每件事情都按照知识树方式做，效率可能不会特别高，有更快的办法么？
- 2. 在对外沟通表达的时候，要表达核心思想，否则别人会很难理解你的表达内容；比如大家再晋升答辩、项目汇报的时候一定会有体会。
原因：核心思路是要抓住重点和脉络。但是抓住重点和知识结构化之间并不矛盾，而且我认为是有先后次序的，一定要先建立知识结构化，然后才能从里面筛选出重点，否则知识的体系是不完整的。
筛选重点的思路：
（1）归纳法
采用归纳法，把细节隐藏掉，呈现知识的脉络，这是一种非常好的思路；
（2）优先级法
优先级策略往往应用于在多项任务之间找到最最关键或者收益最大的那个任务项，比如完成一个事情可能有若干个步骤，其中哪个步骤是最有效的，大致可以做一个排序。
6、反思性思维：思考哪里可以做得更好
反思性思维是提升知识质量和深度的一个关键能力。因为只有不断反思才能让下一次在上一次基础上升级，而不是重复循环。
对于我们技术团队，哪些内容值得反思，我们团队的经验是：
- 1.这个项目商业价值 OK 吗？是否取得了预期的效果？
- 2.项目中我的能力有哪些问题，有哪些做得好的和不好的？
- 3.系统设计的优势和不足？
- 4.项目质量保障是否可以做得更好一些？
- 5.研发过程和项目管理是否有不足？
反思性思维的实践，注意有两个点比较关键：
- 1.反思性思维最重要的意识：做事情的过程总有优化的空间，每次都要有进步；
- 2.反思是一种习惯和潜意识，可以在不经意之间经常进行。
7、锻炼思考力的有效实践
- 1.意识觉醒：意识觉醒是提升思考力最重要的一个点。
- 2.保持信心:只要掌握了正确的方法并坚持训练，思考力绝对可以提升。
- 3.空杯心态：思考的过程其实是对人的知识进行不断刷新和重构的过程，这里一定要保证空杯心态，对新的环境，新的理念，新的技术持开放态度，否则就是自己给自己制造阻力。
- 4.思考的时间：利用碎片时间、 抓住工作的过程。
- 5.思考力提升的判断标准：广度、深度、速度。
- 6.好的工具推荐：Xmind
- 7.一定要相互分享：项目分享、周会分享、群内分享、年度/季度分享、小圈子
- 8.技术leader的思考力意识、能力和实际行动，决定了一个团队的整体思考力水平和成长速度。
在提升团队整体思考力的实践中，技术 Leader 的职责：
- 1.先要把自己变成一个思考者，自己做表率，以身作则；
- 2.意识心态上先变过来，要把团队同学的成长速度最为最重要的职责之一，没有这个意识都是空谈；
- 3.多创造思考的条件和氛围，一定要抓住任何机会（代码 reivew、方案评审、周会都可以）鼓励大家去思考和分享；
- 4.控制团队节奏，给大家学习和思考留出一定的时间；
- 5.及时的引导和示范，有的同学可能掌握会偏慢一些，这时候需要有耐心去引导同学找到思考的感觉；
- 6.不必过多干预细节，发挥大家的群体智慧，而不必做过多干预，更不能以个人的意志去强迫别人接受。
重要观点小结：
1.思考力对程序员的成长至关重要，团队和个人都需要有意或者无意识地提升思考能力。
2.对程序员最重要的思考力有：原理性思维、结构化思维、反思性思维、扩展性思维、抓重点思维。
• 原理性思维是根基，因为没有搞懂的情况下所有的知识建构都是空谈；
• 结构化思维帮助我们建立了我们的知识树；
• 反思性思维不断对知识进行重构，是实现认知升级的必备条件；
• 扩展性思维可以提升知识的广度和深度；
• 抓重点思维可以加快知识的使用效率和传递效率；
3.在提升思考力的实践中：
• 思考力提升最关键的是意识的转变；
• 要对思考力的提升充满信心；
• 多在工作中去锻炼思考力，不需要花太多额外的休息时间；
• 多相互分享；
• 团队 Leader 要团队同学的成长和把思考力提升作为最重要的内容，并拿出实际行动。
四、如何在工作中快速成长，致工程师的10个简单技巧
时间管理认知开始，感受到认知升级的强大力量。
认知升级：认知升级是连接，连接优秀的思维方式，连接解决问题的最短路径，连接一切优秀的方法。
1、思考脑与反射脑
慢思考这本书中把大脑分为反射脑、直觉脑、存储脑。思考脑管理性，反射脑管直觉，存储脑管记忆，直觉依赖习惯，用直觉做出反应，快速，但未必正确；思考脑管理性，理性依赖逻辑，缓慢，但更加正确。
直觉反射：通过大量的逻辑反复训练，提升自己的直接准确性，从狭窄的5%进入广阔的95%。
2、习以为常
把95%中的低质量习惯反射，训练成逻辑后的高质量反射需要很多的时间保障。所谓改变习惯就是在触发条件进入下一个行为时，让自己做对选择题。
3、时间管理：三八理论
时间管理：找到不被打扰的时间用于投资自己的成长。
找到不打扰的时间，比如不被打扰时间：
- 睡前：晚上回家到睡觉前，这段时间每个人都有，这里至少可以抽出 40 分钟学习，建议 11 点半之前必须睡觉，为了早起做准备；
- 早起：这里需要重点说下，如果按照我之前 8 点起床的睡眠习惯，这个时间估计用不上，所以有魄力的人可以做些改变，就是缩短睡眠时间，比如原先 8 点起床改成 6 点，相信自己，年轻人睡 6-7 个小时是够的；这样就会产生 1~1.5个小时学习时间，平时哪有这么长的时间用于学习啊；
- 晨会前：这条适合离公司近的人，在晨会开始前，早点到公司，找到 30 分钟用于学习，这类短时间的学习主要是用于学习快餐知识，找知识服务平台花钱买知识，学习人家总结好的知识。
4、注意力
专注目标事务上，知道产出预期的结果。
5、拿结果手段：执行力
执行力：想明白，然后一步一步做下去。
所谓直觉反射，就是通过大量的逻辑反复训练，提升自己的直觉准确性，从狭窄的 5% 进入广阔的 95%；
所谓以习为常，就是在触发条件发生进入下一个行为前，做对选择题；
所谓时间管理，就是找到不被打扰的时间用于投资自己；
所谓注意力，就是专注在目标事务上，直到产生期望结果；
所谓执行力，就是让自己先想明白，然后一步一步走下去；
所谓贵人，就是能够持续陪你一起输出高质量内容的人；
所谓会议，就是模拟机器学习思路，通过参与讨论获得正反馈来验证自己的观点；
所谓跳出舒适区，就是先跳出，然后进入学习区，平衡挑战和能力达到心流的体验；
所谓职业规划，就是提升工作需要的能力；
所谓时间换空间，就是慢慢来，持之以恒，成长最快；
五、技术三板斧：关于技术规划、管理、架构的思考
1、技术规划
1、全局分析，思考未来，要对未来有一定的预判。能够基于数据、基于专业、基于客户价值，同时结合顶层的战略、公司的战役情况和组织的现状做分析。
2、定目标。定义好目标以及非目标，哪些事情是不要做的也要讲明白，并且确认目标的实现路径，做好拆解。
3、以终为始，从最终结果的角度，来溯源开始。从技术支撑业务发展、平台能力输出或赋能、平台研发效能以及技术数据驱动业务等不同的角度审视结果。
2、技术管理
1、把控核心细节
2、数据化度量，通过数据驱动研发体系的重建，通过质量风险文化的宣导以及核心指标的跟进，起到督导的作用。
3、清单革命，合适是checklist，不管是代码规约、应用规范、稳定性治理等。
3、架构
1、是多元多维
2、第二和第三相辅相成的，核心是分而治之，各个击破。
、 
六、程序员如何自我学习？阿里资深技术专家这样做
1、工具要非常熟练
2、读书 和看文档
3、视频学习
4、技术新闻、twitter上技术大牛和参加技术大会
5、做项目、写demo、看源码
6、适当的硬件支持
七、从计算机知识到落地能力，你欠缺了什么？
网络丢包、卡顿、抖动很容易做扛包侠，只有找到真正的原因解决问题才会更快，否则在错误的方向上怎么发力都不对。准确的方向要靠好的基础知识和正确的逻辑以及证据来支撑，而不是猜测。
- 基础知识是决定你能否干到退休的关键因素；
- 有了基础知识不代表你能真正转化成生产力；
- 越是基础，越是几十年不变的基础越是重要；
- 知识到灵活运用要靠实践，同时才能把知识之间的联系建立起来；
- 简而言之缺的是融会贯通和运用；
- 做一个有礼有节的甩包侠；
- 在别人不给证据愚昧甩包的情况下你的机会就来了。
八、阿里资深技术专家的10年感悟
- 一个人走得快，一群人走得远
- 当你不舒服，难受或陷于困境时，应该停下来思考
- 学习能力与思维模式是一个人的核心竞争力
首先承认别人的不足、掌握优秀的学习方法、掌握搜索信息的有效方式。相对常规的模式是：当你发现问题，定义出问题，就去搜索业界最优秀的解决方案，并且花时间研究方案，了解原理，最后不断地学习实践。这种方式能够有效保证你对问题的解决方案是相对优秀的解决方案。公司对高层级的同学，必须有业界全局的视眼与思考。
如何提升获取的信息质量，这里有一些建议：
- 精确定位问题
- 梳理出关键字与概念
- “全网”搜索
- 分析研究
- 实践 & 结论 & 假设
4.具备优秀的批判性思维模型
九、如何量化考核技术人的kPI?
1、为什么需要技术KPI
2、技术KPI的量化
-
- 业务贡献：包括需求把控，业务项目和业务创新
- 技术贡献：包括设计重构、技术影响力、Code Review、创新提效、代码质量。
- 团队贡献：招聘、新人培养、团队氛围
应用质量：
- 1、你负责或者共同负责的应用质量分（代码重复率、圈复杂度、分层合理性）
- 2、你做了哪些提升应用质量的工作
十、如何成为优秀的技术主管？你要做到这三点
「技术主管」是开发团队中的某位程序员需要对一起创建系统的整个开发团队负责时所承担的角色。通常他既要对最终交付的软件系统负责，另外也会像一个程序员一样去开发实现系统。一个技术主管的 60% ～ 70% 的时间可能花在了开发任务分解分配、开发实践、技术架构评审、代码审核和风险识别上，而余下的 30% ～ 40% 的时间则花在为了保障系统按时交付所需的各种计划、协作、沟通、管理上。和团队管理者不同的是，技术主管的大部分管理工作都是针对具体研发任务和技术事务的。
技术主管具备的素养：
- 1、技术视野良好，解决问题能力与架构设计能力出色。
- 2、动手能力要强，学习能力出色。
1、开发规范
前提：API 接口格式混乱，没有标准的 RPC 服务化，代码没有统一标准的开发规范，技术框架组件非标准化等一系列问题。
开发规范内容：命令规范、统一IDE代码模板、Maven使用规范、代码 Commit 规范、统一 API 规范、异常处理规范、分支开发规范（master、develop、release、hotfix、feature）、统一日志规范、统一 MYSQL 开发规范、统一工具与框架。
2、开发流程
需求管理、技术架构评审、代码评审、发布计划评审。
需求管理：需求管理的第一步就是要梳理不同来源的需求，主要包括从产品定位出发、外部用户反馈、竞争对手情况、市场变化以及内部运营人员、客服人员、开发人员的反
馈。需求管理中最重要的就是对发散性需求的管理，往往因此也会导致产品在执行过程中不断的变更或增加需求。
技术架构评审：技术选型、高性能[TPS、QPS、RT]、高可用、可扩展性、可伸缩性、弹性处理、兼容性、安全性、可测性、可运维性、监控与报警。目标核心满足如下。
1. 设计把关，确保方案合格，各方面都考虑到了，避免缺陷和遗漏，不求方案多牛，至少不犯错。
2. 保证架构设计合理和基本一致，符合整体原则。
3. 维持对系统架构的全局认知，避免黑盒效应。
4. 通过评审发掘创新亮点，推广最佳实践。
代码评审：代码质量包括功能性代码质量和非功能性代码质量，功能质量大多通过测试能够去发现问题，非功能性代码质量用户不能直接体验到这种质量的好坏，代码质量不好，最直接的“受害者”是开发者或组织自身，因为代码质量好坏直接决定了软件的可维护性成本的高低。
代码质量应该更多的应该从可测性，可读性，可理解性，容变性等代码可维护性维度去衡量，其中 CodeReview 是保证代码质量非常重要的一个环节，建立良好的 CodeReview 规范与习惯，对于一个技术团队是一件非常重要核心的事情，没有 CodeReview 的团队没有未来。
CodeReview 我会重点关注如下事情：
1. 确认代码功能：代码实现的功能满足产品需求，逻辑的严谨和合理性是最基本的要求。同时需要考虑适当的扩展性，在代码的可扩展性和过度设计做出权衡，不编写无用逻辑和一些与代码功能无关的附加代码。
2. 编码规范：以集团开发规约、静态代码规约为前提，是否遵守了编码规范，遵循了最佳实践。除了形式上的要求外，更重要的是命名规范。目标是提高代码的可读性，降低代码可维护性成本。
3. 潜在的 BUG：可能在最坏情况下出现问题的代码，包括常见的线程安全、业务逻辑准确性、系统边界范围、参数校验，以及存在安全漏洞 ( 业务鉴权、灰产可利用漏洞 ) 的代码。
4. 文档和注释：过少（缺少必要信息）、过多（没有信息量）、过时的文档或注释，总之文档和注释要与时俱进，与最新代码保持同步。其实很多时候个人觉得良好的变量、函数命名是最好的注释，好的代码胜过注释。
5. 重复代码：当一个项目在不断开发迭代、功能累加的过程中，重复代码的出现几乎是不可避免的，通常可以通过 PMD 工具进行检测。类型体系之外的重复代码处理通常可以封装到对应的 Util 类或者 Helper 类中，类体系之内的重复代码通常可以通过继承、模板模式等方法来解决。
6. 复杂度：代码结构太复杂（如圈复杂度高），难以理解、测试和维护。
7. 监控与报警：基于产品的需求逻辑，需要有些指标来证明业务是正常 work的，如果发生异常需要有监控、报警指标通知研发人员处理，review 业务需求对应的监控与报警指标也是 Code Review 的重点事项。
- 测试覆盖率：编写单元测试，特别是针对复杂代码的测试覆盖是否足够。
发布计划评审：
1） 明确是否有外部依赖接口，如有请同步协调好业务方；
2） 发布前配置确认包括配置文件、数据库配置、中间件配置等各种配置，尤其
各种环境下的差异化配置项；
1） 二方库发布顺序，是否有依赖；
2） 应用发布顺序；
3） 数据库是否有数据变更和订正，以及表结构调整；
4） 回滚计划，必须要有回滚计划，发布出现问题要有紧急回滚策略；
5） 生产环境回归测试重点 Case。
3、技术规划与管理
系统健康度巡检、技术规划。
系统巡检重点要关注如下几点：
- 系统指标：系统 CPU、负载、内存、网络、磁盘有无异常情况波动，确认是否由发布导致，还是系统调用异常。
- 慢接口：通常 rt 大于 3s 的接口需要重点关注，极端并发场景下容易导致整个系统雪崩。
- 慢查询：MYSQL 慢查询需要重点关注，随着数据量上涨，需要对慢查询进行优化。
- 错误日志：通过错误日志去发现系统隐藏的一些 bug，避免这些 bug 被放大，甚至极端情况下会导致故障。
技术规划包括如下几点：
- 架构优化：一些结构不良、低内聚高耦合的代码则会使得哪怕是微小的需求变更或功能扩展都无从下手，修改的代价很可能超过了重写的代价。同样系统之间的耦合也需要重点去关注，遵循微服务化的原则，系统也要遵循单一职责原则，对于职责不清晰的系统去做解耦优化，进行一些模块化改造、服务隔离、公用服务抽象。
- 性能优化：基于财年对于业务量、数据量的发展评估，根据目前系统服务的QPS\RT, 需要提前规划对系统性能进行一些升级策略，包括重点关注对一些慢接口、慢查询的优化。
- 弹性与可靠性：系统提供的服务需要保障括数据一致性、幂等、防重攻击，同时也需要从熔断降级、异地多活的角度去考虑存在哪些问题，目前系统的SLA 指标是否能够达到高可用，需要做哪些优化保障系统的高可用。
- 可伸缩：应用服务是否保证无状态，关键节点发生故障能够快速转移、扩容，避免故障扩大化。
十一、在阿里做了五年技术主管，我有话想说
技术管理：不仅需要制定日常规范，包括开发规范、流程规范等，推动规范的落地，以公有的强制约定来避免不必要的内耗，另外一多半的时间可能花在了开发任务分解分配、开发实践、技术架构评审、代码审核和风险识别上，剩余的时间则花在为了保障系统按时交付所需的各种计划、协作、沟通、管理上。
1、团队建设
新到一个团队，建议暂时按部就班，主要基于以下原因：
- 团队和业务了解不够深：对于目前的团队的人员以及业务，我不够了解，不清楚这里面有哪些坑和陷阱，一旦初战不利，领导的信任度被透支，在公司恐怕难有立足之地，更不用谈论改造团队，发挥自己的才能了。
- 流程与制度：针对团队现状存在的一些问题，我初步判断并不是人的问题，很多问题是一些组织、流程、制度上的问题。我认为只有好的制度才能造就好的团队，在没有解决现有团队的痼疾之前招聘新人，不但不会带来新的生产力，反而会造成团队的混乱，应该先打下一个好的根基，再招人，才能事半功倍。
- 团队安全感：不想让团队现有的成员感觉一朝天子一朝臣，担心自己在团队中会被边缘化，成为弃儿。另外一方面能够让现有团队心理比较安全，可以安心地好好工作，不至于发生更多的动荡。
2、团队管理
作为一个团队的管理者，通常会有两种风格管理策略，简要概括为集权式的管理风格、放权式的管理风格。
集权式管理：管理者的风格是偏细节的，定义清晰的工作目标，并且把工作目标分解得非常细致，让手下的团队能按照整个计划步步为营往前推进，这是一种风格，相对来讲比较集权。
放权式管理：定义大的目标，把握大的方向，做关键性的决策。但是并不深入每个细节去管控手下团队的执行细节，以结果为导向。
3、团队文化
1、坦诚的力量，作为一个 TL，带领一支团队，我觉得最重要的是 TL 本人必须做到坦诚的态度，只有对团队坦诚，才能和团队之间形成信任，只有和团队形成了信任，才能成为一支默契的团队。
2、允许你的下属 challenge 你，管理层统一公司战略，一线员工强调使命必达
3、owner 意识
4、建立学习型的组织：团队成员要尽可能地分享自己的知识和想法，大家互相学习，也通过分享能够总结自己学习过程中零散的知识点。如何建立人才梯队的，其实就是要建立学习型组织，让大家积极参与学习与分享。
5、沟通与辅导：沟通按照沟通对象类型通常分为向下沟通 ( 同下属沟通 )、横向沟通 ( 跨团队沟通 )、向上沟通 ( 同老板沟通 )，接下来只讨论如何同下属进行沟通，最为有效沟通方式：一对一沟通。一对一沟通，又被称作一对一会议、One-on-one 等，是互联网公司常用的沟通方式。一对一沟通虽然被广泛使用，但是涉及的文章却很少，这里我给大家推荐本书《格鲁夫给经理人的第一课》、《创业维艰 : 如何完成比难更难的事》。
一对一沟通（1on1），具体聊那些内容给了一些建议，作为 TL 我通常会与团队的人聊以下话题：
1.你有没有认为自己的价值和能力被低估了吗？为什么？
2.你觉得在工作中能学到东西吗？你最近学到了什么？你还希望在哪些领域进行学习？
3.近期这段时间，对自己有哪些满意、不满意的地方？
4.目前工作中，有哪些困惑？希望我如何去帮助你？
5.对团队和我的一些期待和建议。
6.在公司战略和目标方面，你最不清楚的是什么 ?
4、招聘与解聘等
对于一个团队来说，人才是最核心、关键的。搭建技术团队招聘前，要先明确所搭团队的类型，一般来说有三种不同类型的技术团队，即项目驱动型、业务驱动型和技术驱动型。
★ 招聘步骤：
1. 根据搭建团队的目标，做好招聘计划
根据团队自身的定位，招聘合适的人才。有几点需要 TL 特别关注的，作为 TL要对候选人的成长负责，切忌因人设岗、因单独项目而招人，比如前端团队招聘一些后端开发，工程团队招聘算法，这样以来可能会导致候选人进来后很难融入到团队，没有存在感，长时间下来会导致新人离职。
2. 确定招聘需求（定岗定责）：列出每个岗位的职责、需要具备的技能及其他要求。招聘需求归根结底是需要什么样的人，与据整体业务和组织发展匹配。
3. 合理利用人才招聘渠道从我自身的经历来看，人才招聘渠道多数通过互联网招聘渠道以及朋友推荐更可靠一些，对于高级别的人才可以采用猎头定向挖人。
★ 人才筛选：
作为技术面试官，对于人才的筛选也是非常重要关键的一个环节，要根据自己团队的目标来选取合适的人才，设定完成的时间期限，将面试的重点放在专业技能、管理能力、价值观（公司认同）等方面，一般要求如下：
1. 和岗位需要的专业技能高度匹配：专业技术技能面试过关，定岗定责；
2. 沟通力强：理解公司的业务，知晓管理层，了解公司的发展方向；
3. 责任心：凡事有交代，件件有着落，事事有回音；
4. 靠谱并自带正能量：不抱怨，主动解决问题，懂得纪律的重要性，一诺千金；
5. 价值观认同：认同公司，有目标有理想、有激情有冲劲；
6. 背景调查：非常有用的一个办法，可以大幅度降低选人风险，不用怕麻烦，这个工作的付出永远都是值得的。
技术面试官需要有一定甄别人才的能力，同时有意识地提高这方面的能力，我提供以下几点建议给技术面试官：
1. 如果对候选人有些犹豫和纠结，请你放弃这个候选人，你最担心的问题往往很大概率上会发生。
2. 明确我们招聘的候选人标准，比如后端 JAVA 研发：JAVA 基础和分布式领域知识技能考察是必须的，少问记忆性问题和太理论性问题，更多地从候选人的一些实践经历中，提取出对这个候选人的更有价值的判断。
3. 一面非常重要，要保证客观、公平，后面的交叉和终面往往参考前面的评价反馈，我们今天不仅是为我们的团队选拔人才，更是为公司选拔人才，还是要高标准的要求。从心理学角度讲，必须要交叉面试，而且交叉面试官的给出的反馈往往是比较客观、中肯的，而且要以交叉面试官的评价为主。
4. 面试官切忌拿自己擅长的东西去考察候选人，需要认真的看候选人的简历，从候选人的经历中去考察这个人的综合能力。
十二、如果我是一线技术主管......
1、向上管理
1. 主动承担团队面临的挑战，给出合理的解决方案；
2. 及时向我反馈经过整理的信息和数据，甚至是结论，辅助决策；
3. 主动关心同事，组织学习，帮助大家（包括我）进步成长。
2、每天忙不完的业务怎么办
我会把团队面临的问题分一下级：
1. 重要 & 紧急，不能按时完成，则都是失败；
2. 重要不紧急，是个很好的机会；
3. 技术想法，很好的撬动业务的点；
4. 单分析只是个业务需求，看不出明显的兴奋点。
团队的人可能也有几种特性：
1. 能力强，在某领域是专家；
2. 能力一般，有潜力，但是非常有积极性；
3. 能力一般，主动性一般。
大部分主管分配任务的思路：
1. 重要 & 紧急的事情只能交给能力强的人去做，意愿上如果有问题，也要说服对方去做，因人成事，可见能力强有多重要；
2. 重要不紧急的事情就可以借事修人，如果做得好，这个人以后就有信心了，团队多了一员干将，做不好也有能力强的人给保底，不会造成业务问题；
3. 技术想法也可以交给有积极性的人做，这必然占用一些时间，那么这个人手头上无关痛痒的事情只好交给能力一般，主动性一般的人来做。
