Welcome to唐山天啦噜网络科技有限公司!

18731518855

联系我们

PRPULAR PUSH

ATTEN:
赵总
phone:
18731518855
QQ:
925099789
ADD:
河北省唐山市路北区融通大厦2310-2312

内江研发系统

author:唐山天啦噜网络科技有限公司

【Font size: big medium smail

time:2020-04-11 11:31:03

本文由唐山天啦噜网络科技有限公司提供,重点介绍了研发系统相关内容。唐山天啦噜网络科技有限公司专业提供平台开发,oa系统开发,crm系统开发等多项产品服务。公司客户好评率高,行业口碑好,是在本行业中您的不二选择

研发体系五化:规范化、标准化、平台化、体系化、工程化- 规范化是指要先把已有的东西梳理清楚,底子摸透,然后都理顺,每个单元内部,单元之间的衔接,都有迹可循。

- 标准化是指要制定一系列的基本规则,把所有的框架建立起来,大家做事就有了一致性指导的基础,都有法可依。

- 平台化是指要规划和完善研发的技术基础设置,形成自己的一套行业通用性的核心技术并不断完善,都有势可借。

- 体系化是指要形成一套适合自己的研发过程管理方法论,沉淀出自己的团队风格和完善的人才梯队,都有理可讲。

- 工程化是指要借助前面所有的技术和管理手段,最终达到研发体系的资源最优配置和成本的最小化,都有钱可省。

应对复杂性其实有些业务并没有那么复杂,只是做的复杂了。

复杂性有两种,系统复杂性和人为复杂性。绝大部分情况都是人为复杂性。

因为我们想的复杂了,引入了过多的不可控因素,导致事情变得复杂。

我们不停的强调规范,标准,流程,模式,最佳实践,用各种手段度量和提升质量,都是在致力于消灭人为复杂性。

解决问题为导向《管理的常识》一书里说,管理的核心是不断的解决(推进工作过程中出现的各种)问题。同样地,我认为架构的核心则是不断的解决(系统设计实现与演化过程中的各种)问题。任何有挑战的事情,都充满了问题,冲突,混乱。

而解决这些问题,正是我们的价值所在,也是我们团队成功的机会。

没有什么比去解决实际问题、让系统变好更重要。系统变好了,我们的技术也变好了,公司的业务也支持的更好了,业务好了则行业也发展的更好了,行业好了就会让整个国家和民族都更好了。所以,解决问题是关键。

万维钢老师在《精英日课》里说“这个世界上的问题,分为三类”:

第一类是目标明确、路径明确的,比如你上高中的时候,你知道把几门功课都学好,就能上个好大学,这就是一个单纯问题,但是可以看到,单纯问题也可能是非常难的。钱能直接解决的问题,一般也是这类问题。 第二类是两难问题,选择就意味着放弃,比如两个女孩喜欢你,一个有钱,一个漂亮,选了有钱的就不漂亮,选了漂亮的就没有钱。路径很明确,但你面临的痛苦不是因为问题很难,而是不管你怎么处理,都需要付出失去的代价,放弃潜在的另一些可能,会在将来造成实际的损失。你跟小张结了婚,10年后天天吵架,后悔没有取晓丽,红玫瑰与白玫瑰。 第三类问题,我们叫棘手问题,这类问题,即可能没有特别明确的目标,而且也没有任何人能告诉你一个明确的路径,你现在做了什么努力,可能也短时间看不到效果,做好了不一定有很大成果,做不好肯定要背锅。大家可能都知道这个问题在,就是没有人去解决或者能去解决。最关键是,从外部的一些人看来,这些问题,很像是一个单纯问题。这特么就扯淡了。比如说,你去一家小公司的研发团队做个leader,然后第一个月你感觉到研发体系非常混乱,你随便找个老员工一问,大家都知道很乱。你信心满满,你想把BAT的经验拿来改造体系,你找你的老板说你要搞这个事儿。你搞了几个月发现,我擦,你自己把一个棘手问题当成了单纯问题:这个公司现在很多地方可能就是依赖现在这个看起来混乱的low逼办法才能正常运作。

再比如几个常见的把棘手问题当做单纯问题的,一个创业者说我现在什么都齐备了就差一个程序员了,马云要是雇用我我一定能做一个东西打败微信,化腾要是给我足够钱和人我1年就可以打败淘宝。研发系统

所有讨论问题,如果不是你擅长的专业领域,不要想当然把别人的问题当做是单纯问题。

很不幸,我们做一些新的领域去解决IT相关问题,很可能因为各种因素交织在一起,遇到的都是棘手问题。这就需要我们能坚持做冷板凳,去追求细节,拆分问题域,逐步的解决问题。

拿微服务来说,系统越来越复杂,环节多了,出错的可能性也就越大。一个解决问题的办法就是,自动化,降低人为因素的影响,也消灭服务拆分带来的这种重复劳动的复杂性,提升测试、部署、运维效率。

1) 自动化测试

建立全功能覆盖的测试case,并实现自动化,变更时全量自动回归。集成Sonar等工具,检查代码风格、单测覆盖率和成功率等,控制代码质量。我们一般要求核心业务代码,覆盖率100%;重要业务代码,覆盖率90%;一般的后端业务代码,覆盖率80%;其他代码覆盖率60%。遗留代码,维护时把本次修改设计到的代码,覆盖率提升到60%。代码风格可以参考阿里巴巴或是Google的Code Style编码规范定制适合自己团队的标准。

2)自动化部署

借助与Jenkins、Nexus、Ansible,Docker、K8S等工具,实现多个应用的自动打包,编排,以及自动化部署,构建微服务项目的部署流水线。特别是基于K8S,我们可以实现微服务的服务自愈和自动弹性伸缩,在服务失败后重新拉起,在负载高或者低时动态控制容器数量。研发系统

3)自动化运维

通过标准规范,配置管理工具,资源交付工具等手段的配合,逐步实现基础架构、应用、IT服务和业务运营的自动化,实现日常运维处理和运维流程的自动化,降低风险、提高效率,促进组织能力和成熟度提升。

监控与运维监控与运维是生产环境运行系统的日常工作,就像是人体的免疫细胞一样,保障着整个系统的健康运行,业务的正常运转,下面我们从5个方面说明一些微服务下的健监控和运维工作要点。 1) 系统监控 系统监控是最基础的监控指标,是我们了解系统内部运行情况的直接手段。我们要对所有重要的状态进行度量和监控,全面实时的掌握系统健康状态。 2) 业务监控 业务监控意味着我们要从用户的角度看来待系统的监控指标,而不仅仅是技术角度,这样我们就能发现和分析业务指标的突然变化是什么原因造成的,跟系统本身有没有关系,有没有需要我们改进提升的地方,可以更好的支撑业务增长,影响和稳定业务指标。时常可能会出现,业务方说客户都在抱怨系统不稳定,卡了,延迟高了,但是我们从系统监控上看,系统的指标没有大的变化,那么一定是我们设定的监控指标不够,没有覆盖到业务的全流程。反过来,也说我们和业务方、和客户思考问题的角度有差异,为了更好的服务客户,我们需要调整自己的视角,从用户角度出发思考问题。 3) 容量规划 只了解系统的过去和现状是不够的,因为随时可能会有突发的流量袭来,导致系统被冲击,可能会超出系统处理能力导致延迟飙升,直至系统宕机崩溃。所以我们需要在平时做好容量规划,通过持续的压测,了解到系统的极限处理能力,针对瓶颈资源持续做优化,提升处理能力,做好容量预案,随时有激增流量的扩容方案,超出处理能力的限流和熔断、系统过载保护方案,保障系统的稳定运行。 4) 报警预警 做好了业务和系统指标监控,也做了容量规划,那么我们还需要通过这些指标和容量策略,在合适的时机对系统进行干预,把系统风险提前消灭掉。所以,我们需要根据经验定义预警报警的阈值,根据容量水位进行扩容缩容的后续处理动作。特别报警预警的实时性,是我们应对线上突发异常的一个重要指标,例如对于web和app用户,如果我们在系统突发异常的10秒内收到预警,然后又花了20秒把系统重启,恢复了服务能力,那么用户可能会觉得刚才30秒是不是网络卡了一下,不会产生大规模的客诉。相反地,假如我们2分钟收到报警,又花了10分钟才处理完,这时候基本上大批客户都会感知到了这次故障,称为一个有大量客诉的事故了。 5) 故障处理 从我们的实际经验来看,导致系统出现非预期的不可用性故障,主要有三类原因:

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

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

研发质量控制  这个话题很大,简单说几个质量控制点:

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

三线运维1、值班和处理问题的过程,想办法提取共性,每次能最大化的利用劳动成果,解决和预防一大类问题,并逐渐形成日常维护知识库。

2、研发人员的成本较高,工作时间也很需要连续性,不能经常性的被打断,从而造成生产力发挥不出来。所以,我们一般情况下,把运维人员/实施人员作为一线运维,运营和产品人员作为二线运维,开发人员作为三线运维。在产品线经过一段时间的发展以后,积累出来常见问题处理知识库,然后80%的一般问题由一线运维处理。剩下问题的80%由二线运维处理。这样到开发人员手里之前,问题已经处理掉了96%,剩下4%的问题从来没出现过,或者有很大难度,由开发人员跟踪处理,再加入到知识库。从而形成良性循环。

KPI刚看到马东提到一个印度政府为了消灭眼镜蛇,让大家去抓,提出高价收购眼镜蛇,过一阵时间,眼镜蛇不但没有少,反而变多了。为什么?因为家家都养眼镜蛇。

对于KPI有个说法,你考核什么就会得到什么。你考核眼镜蛇,就会得到眼镜蛇。大家讨论一下,消灭眼镜蛇应该怎么制定KPI。

明确阶段目标有了明确的目标,就是团队自上而下依次分解,大家就有了任务主线。可以参考制定如下的目标(需要注意,每个阶段需要聚焦到一两个具体的目标,否则目标太多反而很难把一件事儿做通透):

1、性能指标(吞吐和延迟):核心交易吞吐提升一倍以上(TPS:1000->10000),A业务延迟降低一半(Latency:250ms->125ms),B业务延迟降低一半(Latency:70ms->35ms)。

2、稳定性指标(可用性,故障恢复时间):可用性>=99.99%,A类故障恢复时间

3、质量指标:编写完善的产品需求文档、设计文档、部署运维文档,核心交易部分代码90%以上单测覆盖率和100%的自动化测试用例和场景覆盖,实现可持续的性能测试基准环境和长期持续性能优化机制。

4、扩展性指标:完成代码、部署、运行时和数据多个维度的合理拆分,对于核心系统重构后的各块业务和交易模块、以及对应的各个数据存储,都可以随时通过增加机器资源实现伸缩扩展。

5、可维护性指标:建立全面完善的监控指标、特别是全链路的实时性能指标数据,覆盖所有关键业务和状态,缩短监控报警响应处置时间,配合运维团队实现容量规划和管理,出现问题时可以在一分钟内拉起系统或者回滚到上一个可用版本(启动时间

6、易用性指标,通过重构实现新的API接口既合理又简单,极大的满足各个层面用户的使用和需要,客户满意度持续上升。

7、业务支持指标:对于新的业务需求功能开发,在保障质量的前提下,开发效率提升一倍,开发资源和周期降低一半。

8、核心人员指标:培养10名以上熟悉核心交易业务和新系统的一线技术人员,形成结构合理的核心研发人才梯队。

结果可想而知了,目前太多了,反而没有目标。最后第一阶段只选择了稳定性作为最重要的指标,先稳住系统,然后再在后面的阶段里选择其他指标,逐步实现各个目标。