上回留了个伏笔说：“做业务的技术原则：远景－目标－指标－做事；对应工作方法：监控－报警－处理－优化”
如果说，之前我懂得的更多是如何根据不同的业务发展节奏，搭建与之相配套的技术体系的话。15-16年度，可以说是我说是重要的一年，让我对于什么叫做“工程技术体系”有了一层更佳深入的认识。这层抽象，让我更懂得回到技术的本源去看事情和问题。从这里一层层扩展开去。
工程技术的本质
我最近特别喜欢在技术前面加上工程两个字。因为这些年的工作我其实经历了一个去工程化的过程，那就是太多的人开始说到互联网，说起研发开始弱化工程师这个概念，更多的是在突出“技术”这个说法。但正是对“工程”的弱化，让我们在很多时候忽视了从传统工程领域借鉴经验的机会。事实上，传统工程和如今的IT工程确实存在区别，但本质上，作为工程化理论，就永远摆脱不了一个话题：一个关于“质量”和“速度”之间永恒的矛盾。如果细想想，对于每一个Tech Lead而言，其实就是在不断的针对这两个问题进行抉择和平衡。没有什么需求是真的做不出来，只是怎么做，才能在质量和速度之间寻求一种平衡。我们知道，在相同产能条件的情况下，
- 第一、质量越高，要求的精细度越高，对应生产难度也就越大，速度也会因此而降下来。人不是机器会疲倦，会出错。
- 第二、而如果对生产速度要求较高，那么质量的下降往往不可避免。但是可以大大提高产出结果
- 第三、虽然是最后，但是很重要，那就是长期低质量对产品速度必然产生负面影线。
由这三点，演化出来一系列方法和理论和话题。我在这里把“质量”与“速度”的矛盾叫做“工程技术本质”，以说明它的地位不可撼动性。
针对业务的技术原则
那么既然Tech Lead们需要不断解决的是“质量”和“速度”的矛盾问题。于是乎，这里面就衍生出一个很有意思的话题—如何做技术决策，如何判定自己的决策是合理。在我的这个理论里，若要做好这个决策，第一部分就是要了解业务。可能这对许多人来讲不可理解，作为技术人员，我做好自己的事情就好了，为什么要了解业务呢。这件事源于以人为中心的互联网模式。随着物质的极大丰富，供给模式，从最早的粗放型生产、分销、渠道，转变通过网络快速的寻找人的需求，根据需求进行快速迭代演进从而精细化的扩充人们在某一个或几个点上的消费习惯。在探寻过程中，其实对于互联网业务来讲，就是不断的实验过程。既然是实验，那么快速看到实验结果和实验深浅的把握就显得尤为重要。所谓实验结果，就是“速度”，即越快速度看到结果，越好进行决策是更进一步实验还是改换新的方向。实验深浅，对于技术而言就是实验的“质量”
那么作为每天坐在IDE前面思考代码和逻辑思路的技术人员而言，我们无法接触真实的用户，没有时间思考和观察用户在干什么，如何才能有效的了解业务呢？我把技术人员了解业务的方法分成了四个基本过程：
远景，大多指一个业务长远的，或者一段时间的方向性目标。远景的很重要，它是指导一切的原则。当然，对于一个大的业务方向来说，形成商业收支目标是核心。但是拆解下来，不同时期，对于形成收支目标的要求不一样，有的是有也不一定是要在财务上展现。比如作为如今的滴滴，当下的最大远景就是实现盈利，但是对于在Nasdaq上市的京东而言，快速增长可能比盈利更重要。作为一个公司而言，远景往往和公司的核心管理人员以及投资人的想法相关。但是，对于一个业务的远景，往往会小许多。比如病历夹工具业务线，他当下远景就是用户活跃的持续增长。所以，绝大多数功能让用户有更强的黏着性。
目标，通常和当下所做的工作直接相关。为了实现远景，任何的业务都会拆成几个小步工作。那么目标，就是每个小步要完成的结果。这个结果可能是让用户在上传病历过程中使用不会产生疑问，也可能是让用户更快捷的在医口袋中搜到药品。作为每一个小步而言，多数业务会设立唯一的目标。当然如果优化功能都比较小，也不排除建立几个目标的可能。目标往往是团队的负责人做的定义，但是对于远景的优化角度不同，思考方式不同，小步目标也不一定是单一的。在互联网的实际环境中，目标也是可以被拿来讨论的。从这里开始，有兴趣的技术工程师，便可以参与深入的讨论。
指标，既然订立了目标，就一定要寻找可以进行衡量的目标完成好坏的指标。我们拿“让用户在上传病历过程中使用不会产生疑问”这个目标来说，这里可以建立的核心指标是“用户上传病历数增加”，这是核心业务指标。分解下来，可能还有一些其他指标，比如上传服务器反应时间在200ms以下，上传成功了70%以上等等。做任何一件事情，都应该是可衡量的，没有量化的工作，就是刷流氓好么:)。定义指标的工作，需要技术工程师的重度参与，这里包括订立那些指标，以及如何将指标反馈给BI系统或者其他数据报告系统。这一点非常重要。也是后期业务、技术团队跟踪做事好坏的核心。
做事，在了解远景，目标达成一致，以及订立好合适的指标后，大家就要开始基于指标工作了。那么指标从某种角度上讲，就是质量的衡量方法，这个一般说来，叫做质量底线标准。任何的速度，在底线标准前，都必须服从。而做事，就是考虑，如何在保证质量的基础上，尽量的提升速度。这里就是Tech Lead们的专业技能体现了。具体的方法有很多，比如XP，Scrum等的工程实践，比如新技术的引用提升研发效率，再比如团队的文化气氛等。
总结一下，技术工程师，Tech Lead都很难真的完全深入业务细节去思考逻辑关系和用户使用习惯。但是经过以上的四个步骤，可以大体梳理每一个小步的背后的逻辑，并通过一系列指标进行有效的质量监控，用一系列工程方法指导做事，提升速度。
针对工程的技术原则
上面谈到了做事，谈到了比如工程方法、新技术的引用、团队文化等，那么针对技术工程，是不是可以衡量呢？答案当然是肯定的。任何工作都应该是可以衡量的，只是指标不同。这里我总结下来还是四个步骤：监控－报警－处理－优化
为什么要衡量？
在解释具体工程上的四步方法之前，先解释一个问题。可能又不少人会问，为什么你总是说衡量。看看我说的做事顺序，其中最后一步叫做“优化”。人类进行工程实践可能有几千年的历史了，很难说哪些事情是没有干过的。但是，问题的关键在于，对于每一次“质量”和“速度”博弈的实验中，如何进行优化，才是人类和动物最大的分别。我们在不断积累经验，寻找更好的方法。这就是实验的本质，也是任何事物前进的源头。“做事”的方法许多，根据团队、实践、节奏、个人知识能力等等不同，有太多的优秀实践可以应用，但是哪种是最好的，只有在指标定一下进行有效优化，才能得到越来越好的效果。所以下面说的四步，不仅仅适用于业务开发，也适用于技术工程人员对一切问题的抽象解决方案中。
监控，在针对业务的技术原则中，我们说到了指标。我们说技术人员要深度参与指标的定义，并做好指标的数据向BI或其他数据报告系统反馈工作，这就是监控的一种，主要应用在业务的指标监控中。其实，针对技术本身也有一系列的可以做的监控指标，比如线上Bug的数量、Crash率、服务器Apex指标，应用可用性等等。但是这里需要需要特别注意的是，在我看来，监控不是目的，是为了解决问题而存在的，特别是解决上面说的业务目标。比如有段时间业务目标是满足双11的客流访问量，那么Apex、网络带宽、负载均衡的资源使用这些就是重要的监控，可能需要秒级别的信息收集。那么这个时段，其他的比如CPU数量、客户端Crash率、网页兼容性，在这个目标面前，就不需要被严密监控，可能是天级别监控就可以了。所以监控是分级别，也是分时段的。
人曾经问我，我是一个Android起家的Tech Lead，对于iOS、Java服务端，我不是很了解，要怎么才能做到很好对团队工作进行有效的带领和优化。这里我想说，通过指标监控，就可以达到目的。与相关的Tech Lead讨论针对特殊目的而细化的监控指标。报警，许多人谈论监控，更多的是一套漂亮的报表，线图、饼图、柱图、箱图各种上。这是我以前常犯的错误，以为报表意味着监控。其实，在过去一年，我学会的最重要的知识就是，展现的目的更多是为了给别人看的直观，用以表明优化的成果，是一种回朔和预测型的工具。但是做事的时候，却不应该作为工具，回到计算机或者生物的本质上，0和1才是我们认识事件最直观的方法。因此，报警在我看来是工程监控最有效的手段（工具）。这种被动式相应能够大大加强响应效率和工作效率，根据响应的情况再去寻找相应的报表或者内容数据进行分析，从而得出有效的处理方案。
设立报警的过程本身并不难，最难的是适当报警阀值的斟酌。太高起不到监控的效果，太低虚报误报使得报警无法有效应用。这个时候需要对技术有比较深入理解，对不同阶段对应指标有比较深入理解的技术人员（这里就不是一个纯工程问题，而上升到技术本身能力上），对报警阀值进行准确的把控，并持续优化。处理，这块儿没太多可说的，这是每一个工程师的老本行，根据报警问题，使用数据综合分析，数据不全可能需要进行场景复现，如果是紧急问题可能还需要采取紧急方案、备份方案、临时方案等进行解决。总之是确保报警状态恢复到正常的水平。这个时间会根据不同业务和级别的不同，处理时间也会不同。
优化，最后来到了前面说的，工程技术原则的核心，就是优化。前面说到互联网的最大特点就是实验，不断的、快速的实验，了解和提升用户的体验，帮助用户解决问题。所以，无论是对业务指标的优化，还是技术指标，或者别的什么指标的优化，总之优化是技术工程师做事的终点，也是新的一轮工作的起点。研发工程由此不断迭代向前，帮助解决一个又一个业务目标。
最后做个总结，在过去的一年里，对于上面方法的理解和应用真正改变了我将近十年的认识。过去的我，一直在学习，学习各种技术、学习各种最佳时间、学习各种方法论来解决一个又一个的研发问题。记得刚进微软那会儿，我的最大收获是如何通过互联网快速解决问题，把Google用的炉火纯青。在英国的4年里，我明白了从0到1的建设过程和研究方法。ThoughtWorks的3年让我懂得什么叫做研发体系和最佳实践。如今，在杏树林，很高兴能遇到一群志同道合的人，至少现在吧，感觉自己的理解又上升了一个新的高度，实践因什么而存在，要解决哪些问题，如何才算真正解决，解决问题的为了什么。这是我2015-16年度，最有收获的部分，共勉。