年前最后一周的正确打开姿势，写一份项目总结吧

2019-12-16

关于作者

宜娜，腾讯CSIG部门员工

导语I之前有段时间研究了下达利欧的《原则》这本书，里面提到了一点：要做一个透明人，对自己对他人都做到无限透明，那么团队协作的效率会高很多。所以，我打算将自己最近几个月做的项目--SOC图谱分析也复盘整理下，尽可能透明地呈现给大家，希望团队的小伙伴们都能够看到，在以后的协作过程中少踩坑，高效协作。同时，也是想让自己对过去的工作有个全局视角，更好地指导未来的工作，避免在下一阶段犯同样的错误、踩类似的坑。当然，也欢迎大家多多批评指正，帮助我们更快地成长~

SOC智能图谱二期开发全流程复盘总结

先说下背景，我从事的项目内容是是腾讯御见安全中心（SOC+）下的智能图谱开发，目标是：基于事件攻击链进行图挖掘分析与探索，将海量安全事件聚合成重点突出的top子图社区，并以可视化的形式展示。由我和另外一位负责算法的小伙伴主导整个功能的开发，我在其中承担了数据、算法、产品、项目等多个不同的角色。我的核心工作是数据分析，后面三个角色是在项目人力不足，而我又经验欠缺的环境下上岗的，因此踩了不少坑，积累了一些一手经验，希望能够避免以后再次踩坑。

以下是是总结全文：

一、SOC智能图谱产品落地探索总结

1.数据特征挖掘及权重设计（数据）

探索过程与总结：

路径如下：

s1.研究安全事件日志中的字段含义，并与安全运营人员讨论确认关键字段；

s2.对提炼的关键字段进行统计分析，观察其分布情况，并确认使用方法，比如分段设置权重；

s3.将不同字段权重进行整合处理；

s4.根据真实数据，对特征权重设置方案进行检验与调整。

第一步骤非常重要，需要多花点时间沟通交流，并且深刻理解，因为会直接影响算法模型的特征选取。目前用到的经验主要是团队内小伙伴的经验，没有参考行业其他公司做法，因为查到的文章一般都没有这么细致的说明。后续可以进行跟进和优化。

权重设置过程进行过3次以上的调整，原因分别是：(1).团队不同成员采用不同方法；(2).调整权重设置方式及增加字段。第(1)种原因的调整主要是前期没有沟通好导致的，有种重复劳动的感觉，后续可以优化：s1.分工明确；s2.及时同步并充分讨论，达成一致；s3.如果要另起炉灶重新探索，要明确原因和目标。第(2)种原因是正常的，随着对项目的理解加深以及现有数据的反馈，是需要不断优化和调整数据权重设置方案的。

输出：特征字段及权重设计方案。

困难：关于安全运营的知识和经验无法有第一手的经验感知，需要跟有经验的人反复沟通、确认，但还是无法保证信息的完备性。

耗时：集中耗费1周左右，但时间跨度超过1个月，算是正常时间投入。

后续建议：

s1.跟进同行业数据特征设计方案，并继续收集可以利用的数据特征；

s2.优化团队协同方式，定期沟通、充分讨论、达成一致。

2.图分割算法探索（算法）

探索过程与总结：团队三个小伙伴用不同的思路分别探索，分别从业务角度、统计角度及算法角度去思考，都给出了各自方案的结果。经过讨论后一致决定用社区发现算法来做图划分。后来发现单单用社区发现算法存在社区超大的问题，可能top3的社区边数会超过1000条，这样会给web页面展示造成很大的压力。

后来团队一个小伙伴想到了用k-core的方法将1-shell和2-core的图结构区分开后再做社区划分，这样可以将超大社区拆分成小的社区（该方法目前被图二期采纳）。但是这样做社区划分会有些严格，会将一些中心节点与复杂结构之间的边断掉，比如下图中红色方框里的边就会被断掉，我认为这种断边是不合理的。（需要跟安全运营人员再次确认，以及用真实环境的数据进行验证）

我目前想到了另一个方法是，只对二度节点做图分割，分割方法可以采用社区发现或者标签传播，具体实施情况根据后续的数据表现来选择。这样的好处是，既可以保证重要的节点与复杂结构之间的联系被保留，也能够解决社区超大的问题。同时，由于舍弃的只是1度叶子节点，关键信息并没有损失。如果一定要看叶子节点信息的话，可以在产品设计中下拓展示。（还在探索阶段，效果好的话可以在图三期中采纳）

算法结果的好坏是直接影响该功能体验的，因此是图谱分析最核心的内容。但是目前针对这块的探索不够系统化，起码没有将图分割比较常用的方法全部试一遍。另外，在算法部署过程中，团队并没有经过充分讨论并获得一致认可的方案，这块后续需要改进。

输出：算法评估报告。

困难：算法结果不好评估（缺乏有安全运营经验的人力以及真实环境下的数据结果），需要部署给客户使用后获取反馈。这块需要继续思考是否有评估方法，不能全部依赖客户反馈来评估算法结果。

耗时：耗时3个月，3个全人力。个人觉得花费时间太久了，可能的原因是全新的领域，大家都经验不足。后续可以改进的地方是，多看相关领域的文章，找同一个领域的人多沟通，及时补齐项目需要的技能。另外，团队小伙伴可以多就问题进行讨论，系统化梳理补齐知识框架。

后续建议：

s1.团队分工，补齐图分割算法领域的所有框架知识；

s2.在项目中尝试、对比多种图分割算法；

s3.继续思考如何不依赖于客户反馈进行评估算法结果；

s4.团队定期沟通，互通有无，对采纳的算法经过充分讨论并达成一致。

3.数据库设计及代码部署（数据、算法）

探索过程与总结：关于数据库设计，先是根据图谱分析结果展示的需要设计库表，包括：边表、节点表、图属性表；后来与安全运营同事讨论后，决定将攻击事件抽离成一个新的节点在图中展示。目的是想在调研每个节点的时候，能够一眼看出是和哪些事件相关联的？（但后来发现是有更好的替代方案的）

关于数据填充与代码部署，团队小伙伴经过多次迭代调整完成，需要根据产品展示的情况来进行调整与优化。其中节点、边及图的属性主要是团队内部小伙伴讨论后确定，需要安全运营经验做支撑，但目前还没有跟安全运营人员充分讨论过，后续要继续跟进和优化。

输出：数据库表，以及完整的代码pipeline。

困难：抽离事件节点稍微有点麻烦，不过也可以解决；缺乏安全运营经验，导致对产品的表现形式把握不够。

耗时：数据库设计1人力，耗时1周，代码部署1人力，耗时1周，但后续继续跟进调整了几次。

后续建议：

s1.以终为始，多思考产品的最终目的是什么，在此基础上与安全运营同事充分讨论，既满足他们的需求，又不能全部盲从；

（图二期的图调查功能就是一个例子，费时不说，易用性还比较差）

s2.继续与安全运营人员讨论，完善图谱的属性特征；

s3.规范代码，尽量模块化不同功能；

s4.代码同步机制透明，更新后及时知会团队小伙伴。

4.图谱产品设计方案总结（产品策划）

探索过程与总结：产品展示主要包括信息展示与功能交互两部分，其中信息展示部分包括：节点（严重性等级、内外网、资产id、所属地域等）、边（事件名、所属类别、来源、频次、等级、关联端口信息等）以及事件汇总描述与社区汇总描述；功能交互部分主要包括：节点（hover，右键隐藏，右键下钻，右键备注等）、边（右键关联展示）、汇总事件与边的交互。

产品策划主要经过了4次迭代改进：

1.主要基于图谱一期结果反馈，优化交互功能与信息展示，比如将多个节点按照事件名来聚合，后来由于更换底层算法，这个设计方案直接pass掉。

（是不是一开始就不应该投入时间在这里？因为明知道后续是要换算法的。不过好在这里只投入了1周左右时间做策划，还没有设计、web及测试的投入）

2.第二版基于社区发现算法，图谱展示的是一个个小社区，安全运营人员需要从两个视角看结果：事件视角+节点视角，因此打算将之前的事件边抽离成一个节点来展示。但后来遇到了这样的问题：按重复边聚合，可能出现冲突，这个时候没有一个统一的原则。因此放弃。

3.第三版主要分两层展示，第一层只展示社区算法划分的社区节点，如果对某个节点感兴趣，可以下钻一层做关联调查，展示以该节点为核心的子图，此时为了同时提供事件+节点视角，采用了上一步的方案：将事件边抽离成一个节点展示，因为该层只有1跳，就不会出现重复边聚合冲突的问题了。但该方案呈现出来后，第二层可用性非常差，无法达到预期目的。

4.第四版，主要是将第三版中的关联调查拆分成另外一个图调查的功能页，和子图社区可以联动交互。

输出：产品说明文档。越详细越好，在tapd单上呈现，后续可以根据设计和web开发同事的反馈不断优化修改。

困难：没有产品经验+缺乏安全运营经验导致对产品的呈现结果不是特别清晰。

耗时：集中耗时2周左右，后续开发过程中根据反馈进行调整和优化。

后续建议：

s1.多与潜在用户沟通（安全运营人员，比如xinquan等），了解他们的核心诉求是什么，然后不断优化改进；

s2.收集整理竞品的方案，寻找对方可取的地方，然后拿来主义。

5.图谱开发流程总结（设计、web、测试）

这块我主要从自己推进的角度来总结，将踩过的坑梳理一下，避免后面再踩，也作为备忘提醒自己，在后续的合作中提升协同效率。

a.交互与视觉

产品方案在与产品经理确认过后，就可以拉起与交互和设计同事的讨论会了，重点记下哪些无法实现，哪些需要调整后实现。根据目前的经验看，一般留1周时间给到交互和设计同学，交互稿给到后，web同事就可以介入了。这里涉及到的流程是：拉起产品方案讨论会-->交互稿-->视觉稿-->产品确认-->web开发完成后，设计同学进行走查-->反馈、优化、迭代。

耗时：集中耗时1周左右

需要注意的点是：

s1.产品方案产生后，尽快跟设计同学拉起会议，定下他们的排期。s2.web开发完成后，记得反馈给设计同学进行走查。

b.web开发

在与设计同事第一次拉起会议时，同时也拉上web同学一起，需要他们评估哪些可以做哪些不能做。但这里需要注意的是，不能做的点要多找几个有经验的web同事一起评估下，否则很多有意义的需求可能就会被砍掉导致产品功能不易用（比如：图谱展示节点pin的功能，事件框与图谱交互的功能等......)。目前看，全新功能web开发需要2周时间，1周用于全力开发，1周用于修复bug。这里涉及的流程是：拉起产品方案讨论-->等交互稿+数据库准备好之后，可以投入web开发-->根据产品反馈，修复bug-->提交测试-->根据测试反馈，修复bug。

耗时：集中耗时2周左右，后续可能需要不断调整优化

需要注意的点是：s1.产品方案产生后，尽快跟web开发同学拉起会议，定下他们的排期。s2.多找几个有经验的web开发同事评估开发难点。

c.测试部署

web开发过程中，提前约好测试时间，等开发完毕即可投入测试。需要给测试同学提供的内容是：1.产品需求文档（一般以tapd单详细需求单呈现）；2.代码pipeline；3.算法设计流程+数据库。这里涉及的流程是：拉起产品方案讨论-->等web开发自测完成后，投入测试人力（构造数据比较关键，算法同学全力协助）-->给出测试反馈-->web修复bug后，再次核验，提交外发包。

耗时：集中耗时1周左右。

需要注意的点是：s1.产品方案产生后，拉上测试同学一起讨论，帮助他们明确项目背景。s2.web开发过程中，尽快跟测试同学定下排期。

二、项目流程跟进清单总结

《清单革命》这本书中提到过清单的重要性：它可以帮助我们避免因为忽略一些必要步骤而犯错或者效率低下，比如帮助医生有序、高效地完成最复杂的手术，帮助投资大鳄快速、高效地筛查最适合投资的公司，还能帮助飞行员在短时间内完成最复杂的起飞检查步骤。清单对于一个项目的高效推进也是非常有帮助的，下面就是我根据本次项目推进过程中整理出来的完整流程清单，希望在我们探索SOC智能分析第3,4,5......期的过程中，发挥指导作用，当然，后续也会根据实际情况不断优化下面的清单~

以下表格是基于上面流程所做的排期计划表，定期分享给团队小伙伴，会让大家都能够非常快速地了解项目进展如何，做到每个人都心里有数，从而协作起来也更有效~