后端技术 by Tim Yang

尽管大部分技术大会的演讲材料会后公开了，但是大家还是看重现场去参加并聆听。参加一场技术大会，简单的理解是扩大自己的认知圈，感受一下不同的思维方式，深层次是希望通过讲演的感染力，获得思考、借鉴或者力量。如 @霍泰稳 在QCon上海大会keynote致辞中提到，“你正在改变世界，我们在影响你”，在一场大会中，大家通过演讲的材料或者讨论来相互影响。

在另外一方面，技术大会的参会人员大多是一种仰望学习的心态，这种情况下，演讲也会具有一些局限性。

• 知识的局部性，讲师为了内容的感染力及趣味性及易理解性，倾向于挑选领域中一些特色点来介绍，也会通过重复一些“正确的废话”获得大部分群体的共鸣。演讲不等同于老师上一堂课。
• 时间的局限性，大部分演讲时间在半小时~1小时，较难将问题深入展开并让听众领悟；另外考虑到听众多元化的背景，也尽量选择最通俗的内容来讲解
• 环境的局限性，具有丰富知识性的材料较难通过slide充分展示，同时，对于slides内容，观众由于需要跟随讲师演讲思路，未能有充分时间去理解、思考材料内容，也常常还未看清材料讲师已经翻到了下一页

基于这些看法，并考虑到对听众实际生产力改进的影响，我最近更看好小班培训对于知识学习的效果。

从讲师的角度，一场好的演讲，准备永远都是不充分的，演讲确实是一个厚积薄发的过程，尤其在内容的深度方面。除了表述的问题之外，有可能还是讲师自身认识的体系性与深度的问题。有些讲师虽然自己做过一些不错的系统，但也有可能未去深入去抽象其中的普遍性的规律，单纯复述一个强大系统的feature并不能让听众满足。讲师通过一次演讲的机会，可以整理自己的思想及体系，获得外界在领域内的反馈，更虚一点，一次好口碑的演讲，可以赢得社区的尊重及声望、建立技术品牌。

技术大会也变得越来越国际化，由于互联网传播的速度，国内公司与国外在认知层面差距不是很明显，表现为老外的技术架构栈，国内公司搭建起来的似乎非常相似。但是从内在来看，开发文化的差异短期之内不太能改变，以及在开发工具、开发框架精细化方面尚有距离。

不管在技术架构还是大数据处理分析上，大型公司都具备在架构实践及大数据挖掘方面的人才及环境的领先优势，至少从最近的一系列技术大会来看，这是一个寡头的时代。

校园招聘的季节也基本结束，校园招聘通常由多轮面试组成，在面试学生时候，社会招聘面试过程中以经验或阅历来推导能力的方法并不适用，一方面不少优秀的学生实践经验并不突出。另外一方面从实践经验及成果方面来衡量一个学生的能力也较片面。由于缺少经历方面的成果，而导致面试官对同一个候选人判断的尺度差异较大。因此最近团队内也进行了一些讨论。

讨论时候参考了Matt Might教授的The illustrated guide to a Ph.D.（可参看阮一峰的中文译本），并绘制出了一个简单的能力模型。

图中Level 1标识候选人具备专业领域（对应图中本科生的凸点）知识的应用能力，比如实现一个考虑了各种实现细节的MVC的程序，一个可以运行在实际网络环境的多人socket聊天室等。

我们期望候选人能够匹配到图中的Level 2，类似图中master’s degree, 在面试过程中能够从与候选人的交谈中看到一个较深的specialty。如何判断较深？我们认为在该项能力上，即使放到我们已有的团队范围内，该能力也达到一个峰值。看起来似乎有些难，但是人各有长，你的专长未必是别人的专长，因此超越一个团队也不是非常困难。

Level 3我们也公认比较难达到，属于特殊类人才。

除了专业能力之外，我们也比较看重软性素质，分成理解力、学习力、内驱力及抽象能力，四个能力之间没有严格的次序关系。由于我们技术岗位的特殊性，这几项软性能力不具备普遍性及较强的借鉴性。比如沟通及表达能力在某些岗位比较重要，但是在大部分技术岗位，相应的要求可以相对弱化。

—谈系统故障及软件质量

如果你是一个7×24小时在线服务的整体（或模块）的技术或系统负责人，你的大部分生活会如游走钢丝。

程序会出bug、资源会出故障、发布会操作错误、测试会有疏漏、安全会出漏洞、网络会有波动、服务器会突然坏掉。当产品的需求日益增多，判随工程师团队会日益增大，一个软件项目或功能从开发到上线的完成，都不可能由一人或者几个核心工程师去做，需要由不同背景、不同能力及做事风格的的开发、测试、工程师配合完成。当任一环节问题（包括有不少并非你直接可控范围之内的问题）未及时发现并带到线上之后，最终的责任会落在你的肩上。每当问题一出，你会感受到各方面的压力，有技术的缺陷、工作的失职、流程及规范执行方面的欠缺的问题；同时也会来自组织内外对你能力及人品等方面的质疑的声音。当发生问题后，你可能会独处一隅，沉浸在未能把事情做好的懊悔中。

尽管平时付出了很多辛勤与努力，在业界普遍处于KPI焦虑的环境中，技术作为底层支撑部门，出现的各种问题通常是显而易见的，不足的问题通常会被放大。

因此，你经常面临的艰难的选择是，quality, or death.

传统工作生产中，有标准化的流程及规范来提高质量、降低故障。比如六西格玛（Six Sigma）可以降低产品瑕疵率。他们有成熟的规范与制度，有熟悉制度执行的专业人员，有提供咨询服务且具有丰富经验执行的咨询公司，企业员工及业务负责人只需要按步就班，就可以把问题做得相对到位。但在互联网在线服务这种不规范的软件系统中，有没有类似的标准化流程来指导生产呢？大部分团队需要从头到尾摸索一遍，在交足学费后才能得到一套并不完善的流程及制度？

发布前流程

设计及架构，是否在开发的特性进行设计上的tradeoff？
风险及依赖，开发计划中充分考虑风险及项目依赖因素？
代码是否经过足够的review？
上线计划及风险因素是否考虑详尽？比如是否需要灰度发布？上线后检查及测试措施是否到位？是否有回滚方案，回滚是否会产生脏数据?

当故障发生时

是否有充足渠道及时发现问题？以免小问题变成大问题？
收到问题后是否有合适方式（如日志及工具）快速定位并确认问题？有时候一些用户反馈的些问题并不好测试及重现。

处理问题

是否有现成的问题处理预案？
对于新功能是否有回滚处理方法，回滚后是否存在脏数据需要修复？

总结问题

问题的根源是什么？在技术上、流程上、风险防范上各有什么可以马上执行的行动计划？

非技术因素

在很多企业中，容易把软件质量上发生的各种问题归结到单一的技术因素。但是，如果没有非技术体系的支持，一个团队不可能做到完善的高质量。

研发流程及质量改进在你企业规划中的权重是怎样？年度规划中除了业务目标、竞争环境、市场份额、产品策略之外，研发体系改进是否有一席之地？

在功能需求及产品设计阶段，是否充分考虑了技术风险及人力资源因素？是否会突然启动当前团队并不能支撑的项目？

在开发阶段，开发计划是否符合软件开发规律？开发计划是根据项目压力制定，还是从定好的交付日期来倒推开发时间表？

安全及优化，是否有专门的人力及团队？开发工程师需要面临日常的开发任务，突然被用户发现之前开发的模块存在安全问题，修复完之后发现又带出了另外一个bug？

国内大部分产品面临市场及竞争对手的压力非常大，在相对恶劣的环境下，研发技术建设大多只考虑短期收益。如果期望研发体系做到零故障或者可控的故障（比如six sigma中的99.99966%），需要长时间的体系建设与积累，包括整个企业的工作流程，同时也需要在技术基础研发上投入更多的精力。