经过了一个十一假期,我们的日记虽然没有更新,但我们的项目并没有停止。

虽然这个项目是一个依托性能培训的项目,但对我来说,这和真实的项目并无二致。我们花了几万(根据一期的培训,估计在3-4万左右,实际费用取决于使用时间)购买云服务器,搭建一个完整的项目,从k8s到代码到监控一样也没落下,从我的经验上来看,这已经比大部分的性能项目要完整得多了。

性能分析人员(可能是一个人,也可能是一个团队)应该面对项目中的所有技术栈。记住,是所有技术栈!

在这些天里,各小组也组织了多次的会议沟通,大家也都是积极的,但是有积极的态度,不一定有积极的结果,所以我们还要说一下各组的工作成果。

根据群里的沟通来看,脚本开发组已经基本上完成了调试,现在需要造足够的基础数据来做参数化了。

分析调优组已经出了第一版各组件的性能分析决策树,虽然还没有达到完美的程度,但也有了雏形。部分分析决策树如下所示:

7DGroup性能实施项目日记4_云服务7DGroup性能实施项目日记4_决策树_02

7DGroup性能实施项目日记4_云服务_037DGroup性能实施项目日记4_性能分析_04

7DGroup性能实施项目日记4_决策树_05

对于我一直在强调的RESAR性能工程中的性能分析七步法来说,性能分析决策树是关键的一个环节,所以我们的分析组也是人最多的,倾本次项目相关人员一半(10人以上)之力来画性能分析决策树。

当然这里还缺少一些环节,如:技术组件的概念、架构图、计数器、配置参数、监控工具、关联分析逻辑等几个部分都无法通过思维导图的形式来体现,所以我们后面还需要编写文档来做详细的说明。

环境搭建组近期没有什么工作进展,主要是由于环境已经搭建完毕,环境组也只需要维护当前环境即可,但没看到他们现在进入工作状态。

架构组现在还没提交什么有价值的图,只有一开始的那两个看似非常简陋的图。

7DGroup性能实施项目日记4_云服务_06

7DGroup性能实施项目日记4_云服务_07

严格地说这两个是一个意思。从架构的角度来看,这只能算是一个逻辑图。从架构设计的角度来说有四种架构图:业务架构、技术架构、应用架构、数据架构,懂的人都知道这四个分类是从哪来的,我在这里也不赘述了。

就算是考虑4+1或C4架构图,上面架构组的交付物也是不能让人满意。

但不管怎么说,也算是有了逻辑图。

代码开发组之前给了一个接口逻辑梳理的图,我忘记放到哪里去了,只记得非常潦草,就没有保存,想来他们后面会划专业一点的接口调用图。

管理组自从制定了计划和一个方案草稿之后,这一段时间没看到有什么动作,也许有背后做的进度跟踪工作,只是我没有看到。原以为是因为我不够仔细,刚才又去查了一下项目计划。如下:

7DGroup性能实施项目日记4_性能分析_08

看起来项目计划已经没有维护了,这属于渎职呀!怪不得项目一做就废。

综上来看,总体来说有进度,只是进度可控性不强。脚本开发组和分析调优组的工作成果最为明显。其他各组工作有些懈怠,看不出有价值的产出,后面还需要管理组加强风险和进度管控。

其实对于一个性能项目来说,我觉得如果等着事情推动人往前走,那就相当被动了,这是不对的。而当你不知道一个性能项目应该做成什么样子的时候,就会做成像现在这样,虽然大家都积极了,但从结果来看,并不如人意。

虽然有些组有工作产出,但产出的结果也并不完美,在我之前看到过的性能项目中,有大大部分就像现在这个状态。

那么,怎么办呢?是时候给他们上上眼药了。

后面我要多花一些时候,在正常的培训进度保证的前提下,给他们讲讲性能项目应该如何做,这里面涉及到的管理和技术工作都是细致的,要思虑在前的。

PS:今天阿里云服务器在我们的帐户里仍然有钱的情况下,把我们的六个服务器直接给释放掉了,连个备份都没留,导致环境要重新配置,提了工单,也没有给出合理的解释,这会耽误一些时间。

7DGroup性能实施项目日记4_性能分析_09

在这里提醒一下,理智的企业一定要考虑云服务器带来的风险,看似购买云服务减少了企业的维护成本,但也要有出事故无法挽回的心理准备。


有兴趣了解我们的线上培训的,可以看下我们的招生简章和大纲。

7DGroup性能工程高级班招生简章-第二期

7D-RESAR 性能工程高级班大纲