如何建设 研发体系

小小鲁班

研发体系五化：规范化、标准化、平台化、体系化、工程化- 规范化是指要先把已有的东西梳理清楚，底子摸透，然后都理顺，每个单元内部，单元之间的衔接，都有迹可循。
9 G: s# B2 V8 n' J4 E3 P- 标准化是指要制定一系列的基本规则，把所有的框架建立起来，大家做事就有了一致性指导的基础，都有法可依。
; M; y- Z$ f1 s* d1 g- 平台化是指要规划和完善研发的技术基础设置，形成自己的一套行业通用性的核心技术并不断完善，都有势可借。
. x3 S' w6 c; e; n- 体系化是指要形成一套适合自己的研发过程管理方法论，沉淀出自己的团队风格和完善的人才梯队，都有理可讲。
' s& {3 N- f# N% C4 O4 v- 工程化是指要借助前面所有的技术和管理手段，最终达到研发体系的资源最优配置和成本的最小化，都有钱可省。
! Y) H) Z, I# V% F
应对复杂性其实有些业务并没有那么复杂，只是做的复杂了。
$ B' b0 y5 F) q4 e复杂性有两种，系统复杂性和人为复杂性。绝大部分情况都是人为复杂性。
因为我们想的复杂了，引入了过多的不可控因素，导致事情变得复杂。
我们不停的强调规范，标准，流程，模式，最佳实践，用各种手段度量和提升质量，都是在致力于消灭人为复杂性。

解决问题为导向

《管理的常识》一书里说，管理的核心是不断的解决（推进工作过程中出现的各种）问题。同样地，我认为架构的核心则是不断的解决（系统设计实现与演化过程中的各种）问题。

任何有挑战的事情，都充满了问题，冲突，混乱。
$ {5 u0 u& w# E( B! R  b而解决这些问题，正是我们的价值所在，也是我们团队成功的机会。
8 g2 k% ]# l  D! q4 x没有什么比去解决实际问题、让系统变好更重要。系统变好了，我们的技术也变好了，公司的业务也支持的更好了，业务好了则行业也发展的更好了，行业好了就会让整个国家和民族都更好了。所以，解决问题是关键。
5 i* o0 l* D- a5 t" [) P. A$ ^万维钢老师在《精英日课》里说“这个世界上的问题，分为三类”：

第一类是目标明确、路径明确的，比如你上高中的时候，你知道把几门功课都学好，就能上个好大学，这就是一个单纯问题，但是可以看到，单纯问题也可能是非常难的。钱能直接解决的问题，一般也是这类问题。
第二类是两难问题，选择就意味着放弃，比如两个女孩喜欢你，一个有钱，一个漂亮，选了有钱的就不漂亮，选了漂亮的就没有钱。路径很明确，但你面临的痛苦不是因为问题很难，而是不管你怎么处理，都需要付出失去的代价，放弃潜在的另一些可能，会在将来造成实际的损失。你跟小张结了婚，10年后天天吵架，后悔没有取晓丽，红玫瑰与白玫瑰。
! X5 a& q( p0 O6 N! q第三类问题，我们叫棘手问题，这类问题，即可能没有特别明确的目标，而且也没有任何人能告诉你一个明确的路径，你现在做了什么努力，可能也短时间看不到效果，做好了不一定有很大成果，做不好肯定要背锅。大家可能都知道这个问题在，就是没有人去解决或者能去解决。最关键是，从外部的一些人看来，这些问题，很像是一个单纯问题。这特么就扯淡了。

比如说，你去一家小公司的研发团队做个leader，然后第一个月你感觉到研发体系非常混乱，你随便找个老员工一问，大家都知道很乱。你信心满满，你想把BAT的经验拿来改造体系，你找你的老板说你要搞这个事儿。你搞了几个月发现，我擦，你自己把一个棘手问题当成了单纯问题：这个公司现在很多地方可能就是依赖现在这个看起来混乱的low逼办法才能正常运作。
" v3 ~) \7 B# i1 y再比如几个常见的把棘手问题当做单纯问题的，一个创业者说我现在什么都齐备了就差一个程序员了，马云要是雇用我我一定能做一个东西打败微信，化腾要是给我足够钱和人我1年就可以打败淘宝。
所有讨论问题，如果不是你擅长的专业领域，不要想当然把别人的问题当做是单纯问题。
很不幸，我们做一些新的领域去解决IT相关问题，很可能因为各种因素交织在一起，遇到的都是棘手问题。这就需要我们能坚持做冷板凳，去追求细节，拆分问题域，逐步的解决问题。
$ W+ o* Q% t* R% V拿微服务来说，系统越来越复杂，环节多了，出错的可能性也就越大。一个解决问题的办法就是，自动化，降低人为因素的影响，也消灭服务拆分带来的这种重复劳动的复杂性，提升测试、部署、运维效率。
1） 自动化测试
建立全功能覆盖的测试case，并实现自动化，变更时全量自动回归。集成Sonar等工具，检查代码风格、单测覆盖率和成功率等，控制代码质量。我们一般要求核心业务代码，覆盖率100%；重要业务代码，覆盖率90%；一般的后端业务代码，覆盖率80%；其他代码覆盖率60%。遗留代码，维护时把本次修改设计到的代码，覆盖率提升到60%。代码风格可以参考阿里巴巴或是Google的Code Style编码规范定制适合自己团队的标准。
2）自动化部署
0 ~% ?* e6 {( ]1 `$ J借助与Jenkins、Nexus、Ansible，Docker、K8S等工具，实现多个应用的自动打包，编排，以及自动化部署，构建微服务项目的部署流水线。特别是基于K8S，我们可以实现微服务的服务自愈和自动弹性伸缩，在服务失败后重新拉起，在负载高或者低时动态控制容器数量。
7 B) p  n  X' ?3）自动化运维
# Y& Z$ f% ^4 m; ~  B* g6 C通过标准规范，配置管理工具，资源交付工具等手段的配合，逐步实现基础架构、应用、IT服务和业务运营的自动化，实现日常运维处理和运维流程的自动化，降低风险、提高效率，促进组织能力和成熟度提升。
# T8 J: F& V- I8 q; D监控与运维监控与运维是生产环境运行系统的日常工作，就像是人体的免疫细胞一样，保障着整个系统的健康运行，业务的正常运转，下面我们从5个方面说明一些微服务下的健监控和运维工作要点。
: x1 k4 z  M1 \% A% _8 C1） 系统监控
' d- @  i. i2 B( }- V系统监控是最基础的监控指标，是我们了解系统内部运行情况的直接手段。我们要对所有重要的状态进行度量和监控，全面实时的掌握系统健康状态。
2） 业务监控
$ L5 y8 M0 B0 k& B7 {  A% ?6 t业务监控意味着我们要从用户的角度看来待系统的监控指标，而不仅仅是技术角度，这样我们就能发现和分析业务指标的突然变化是什么原因造成的，跟系统本身有没有关系，有没有需要我们改进提升的地方，可以更好的支撑业务增长，影响和稳定业务指标。时常可能会出现，业务方说客户都在抱怨系统不稳定，卡了，延迟高了，但是我们从系统监控上看，系统的指标没有大的变化，那么一定是我们设定的监控指标不够，没有覆盖到业务的全流程。反过来，也说我们和业务方、和客户思考问题的角度有差异，为了更好的服务客户，我们需要调整自己的视角，从用户角度出发思考问题。
: M* k6 j/ I  r; \9 f8 B0 d3） 容量规划
! h  i2 L# z' D4 A9 Z  ?9 D只了解系统的过去和现状是不够的，因为随时可能会有突发的流量袭来，导致系统被冲击，可能会超出系统处理能力导致延迟飙升，直至系统宕机崩溃。所以我们需要在平时做好容量规划，通过持续的压测，了解到系统的极限处理能力，针对瓶颈资源持续做优化，提升处理能力，做好容量预案，随时有激增流量的扩容方案，超出处理能力的限流和熔断、系统过载保护方案，保障系统的稳定运行。
2 i: E) d: Z3 z6 [* \4） 报警预警
  ^) `' C2 j: Z$ I: f做好了业务和系统指标监控，也做了容量规划，那么我们还需要通过这些指标和容量策略，在合适的时机对系统进行干预，把系统风险提前消灭掉。所以，我们需要根据经验定义预警报警的阈值，根据容量水位进行扩容缩容的后续处理动作。特别报警预警的实时性，是我们应对线上突发异常的一个重要指标，例如对于web和app用户，如果我们在系统突发异常的10秒内收到预警，然后又花了20秒把系统重启，恢复了服务能力，那么用户可能会觉得刚才30秒是不是网络卡了一下，不会产生大规模的客诉。相反地，假如我们2分钟收到报警，又花了10分钟才处理完，这时候基本上大批客户都会感知到了这次故障，称为一个有大量客诉的事故了。
, S5 k- r+ f$ v6 N5） 故障处理
从我们的实际经验来看，导致系统出现非预期的不可用性故障，主要有三类原因：
; J% y6 B) W% _- W' C; X. Q9 {

• 人为的操作失误导致的宕机类不可用，没有标准的操作流程或者操作者没遵守流程；
• 遗漏的功能或性能相关的bug问题引起的不可用，我们的测试覆盖不足，或者对系统间的影响关系判断不准确，导致Corner-Case有遗漏；
• 不可预知的突发条件或状况引起故障的不可用，比如我们使用了AWS，突然某个时间段AWS日本某个可用区的网络突然发生了大规模超时，某个RDS的底层硬盘突然损坏等；
  这三类问题的应对策略是分别如下。
• 操作失误的应对策略：制定标准操作流程，并根据实际情况不断更新和调整，贯彻培训，严格执行，用流程来防止人为的不规范；
• 功能问题的应对策略：建立全功能覆盖的测试case，并不断扩充Corner-Case，逐步实现自动化，跟CI/CD集成，每次修改后都能及时的回归所有已知的case，不留死角。完成系统和服务依赖关系分析，梳理和合理改造影响范围。建立可跟踪的性能测试基线标准和环境，每次重构或者设计调整，都通过基线环境进行性能验证，不把性能问题带到线上。
• 突发故障的应对策略：突发问题是我们真正面临的问题，一般来说不可控，超出预期，难以通过我们的努力直接解决。所以，如何在不可靠的基础上实现应对策略，除了上面提到的容错和面向失败设计以外，我的经验就是需要在基础设施和业务服务之间，考虑再加一些中间层，特别是使用一些业内知名的成熟中间件，利用它们的主从、多副本、分片等机制，通过软件的高可用实现对硬件和网络底层问题的隔离，进而给上层的业务服务层提供高可用的基座。简单说，就是把系统的稳定性风险，从我们的基础设施或者原来在业务代码实现里写的各种策略，转移到了中间件上。另一方面，需要考虑突发故障后的系统快速恢复策略，如果我们能在用户可容忍的感知时间内把系统恢复到故障前的状态，则大部分情况下这次突发故障的影响就会非常小。所以，系统的启动时间，数据预热和配置加载时间，我们需要考虑减低平均故障处理时间（MTTR），缩减到一个可控的很小范围内，比如系统在10秒内启动，30秒内完成预热加载，这样系统发生问题时，我们不在线排查问题，迅速无脑重启即可恢复业务。
  

故障处理的第一原则是，先解决问题，然后再去考虑分析原因，复盘过程，总结经验教训，最后才是考虑要不要追责。特别强调的是，如果一个线上的发布或者变更操作，有可能造成客户的感知事件，最好就先跟客户进行一个可以预期造成业务影响的沟通，给客户同步一下操作的时间，目的，持续时间，可能造成的影响，让客户可以从容的安排和调整自己的业务，保证不受影响或者降低损失（如果停机会给客户造成损失的话）。如果技术团队对这个操作没有十足的把握，最好考虑在一个可接受的时间窗口内停机处理。对于发布造成的故障，我们一直有个说法：
5 Y$ T! M7 R# K  F* l1 D. \

如果发布可能导致宕机这件事是提前告知了客户，那么真的发生了宕机就是一个故事。相反，如果可能导致宕机这事儿没有提前告知客户，那么操作过程导致宕机，就是一个事故。

研发质量控制  这个话题很大，简单说几个质量控制点：
8 a# k8 z0 L' M) E, S, ?

• code style，格式与注释
• document，目前赶进度从简，回头补充
• code\design\sql review，从简，现在是我在看
• continuous integration，每次提交必须通过编译与unit test，不通过请团队所有人喝饮料，在执行
• inteRFace change，单方面修改接口，扣绩效
• smoketest，提测的冒烟不通过，扣绩效
• bug reopen，有bug不要紧，bug重复出现，扣绩效
• ITSM，运维事件按等级的反馈与处理速度，积压不处理扣绩效
• OnCall，定义不同等级的系统和事件响应时间，值班制度和责任人，最快要求1分钟内处理
  : X+ t5 E) G4 n2 ?- ~9 [

待补充，todo，kimmking
7 \& `0 _. V0 j! j2 {; l9 v三线运维1、值班和处理问题的过程，想办法提取共性，每次能最大化的利用劳动成果，解决和预防一大类问题，并逐渐形成日常维护知识库。
" W) r4 ~2 t5 J5 s* X) y6 T4 H6 b2、研发人员的成本较高，工作时间也很需要连续性，不能经常性的被打断，从而造成生产力发挥不出来。所以，我们一般情况下，把运维人员/实施人员作为一线运维，运营和产品人员作为二线运维，开发人员作为三线运维。在产品线经过一段时间的发展以后，积累出来常见问题处理知识库，然后80%的一般问题由一线运维处理。剩下问题的80%由二线运维处理。这样到开发人员手里之前，问题已经处理掉了96%，剩下4%的问题从来没出现过，或者有很大难度，由开发人员跟踪处理，再加入到知识库。从而形成良性循环。
KPI刚看到马东提到一个印度政府为了消灭眼镜蛇，让大家去抓，提出高价收购眼镜蛇，过一阵时间，眼镜蛇不但没有少，反而变多了。为什么？因为家家都养眼镜蛇。
对于KPI有个说法，你考核什么就会得到什么。你考核眼镜蛇，就会得到眼镜蛇。大家讨论一下，消灭眼镜蛇应该怎么制定KPI。
明确阶段目标有了明确的目标，就是团队自上而下依次分解，大家就有了任务主线。可以参考制定如下的目标（需要注意，每个阶段需要聚焦到一两个具体的目标，否则目标太多反而很难把一件事儿做通透）：
' [1 i" Z6 j" s4 }2 w1、性能指标（吞吐和延迟）：核心交易吞吐提升一倍以上（TPS：1000->10000），A业务延迟降低一半（Latency：250ms->125ms），B业务延迟降低一半（Latency：70ms->35ms）。
+ ?8 H/ v1 i: u- m2、稳定性指标（可用性，故障恢复时间）：可用性>=99.99%，A类故障恢复时间<=15分钟，季度次数<=1次。
3、质量指标：编写完善的产品需求文档、设计文档、部署运维文档，核心交易部分代码90%以上单测覆盖率和100%的自动化测试用例和场景覆盖，实现可持续的性能测试基准环境和长期持续性能优化机制。
8 _1 G) P# d4 u% U4、扩展性指标：完成代码、部署、运行时和数据多个维度的合理拆分，对于核心系统重构后的各块业务和交易模块、以及对应的各个数据存储，都可以随时通过增加机器资源实现伸缩扩展。
9 K& b  t* T: Y6 ~! _9 W+ l6 j5、可维护性指标：建立全面完善的监控指标、特别是全链路的实时性能指标数据，覆盖所有关键业务和状态，缩短监控报警响应处置时间，配合运维团队实现容量规划和管理，出现问题时可以在一分钟内拉起系统或者回滚到上一个可用版本（启动时间<=1分钟）。
$ c. j% J2 p: P& g, h: Y. L: r6、易用性指标，通过重构实现新的API接口既合理又简单，极大的满足各个层面用户的使用和需要，客户满意度持续上升。
7、业务支持指标：对于新的业务需求功能开发，在保障质量的前提下，开发效率提升一倍，开发资源和周期降低一半。
; t9 j9 O7 t& @9 @' K/ e8、核心人员指标：培养10名以上熟悉核心交易业务和新系统的一线技术人员，形成结构合理的核心研发人才梯队。
. e" B# X! N  |! X8 k结果可想而知了，目前太多了，反而没有目标。最后第一阶段只选择了稳定性作为最重要的指标，先稳住系统，然后再在后面的阶段里选择其他指标，逐步实现各个目标。
( |4 I: H" z# V4 h& C# J
/ C% s! s! t1 h0 C3 f9 y% C& W4 G
5 y) K" T! f0 T8 `

ounce

《管理的常识》一书里说，管理的核心是不断的解决（推进工作过程中出现的各种）问题。同样地，我认为架构的核心则是不断的解决（系统设计实现与演化过程中的各种）问题。