0302-0306这一周收获很大，这期间发生了两件事件让自己更加了解到自己的不足。

一

周三早上的项目开工会上，在过当天的工作计划时，我们认为一个需求需要定制开发，要前端同事进行协调开工。

老大了解到需求场景时，十分惊讶：如果所有项目的需求都以定制开发的方式进行，虽然简单快捷，但是公司产品就没有了进步空间，产品整个体系就没啥好更新迭代了，迟早走向灭亡。

此时马上组织了一个会议，沟通技术评审的重要性和怎么做。会议上，大佬首先问我们这件事情需要怎么拆解分析，小伙伴们顿时哑口无声。大佬怒喷我们读了这么多年书连个分析方式都没有，最简单的经典的5W2H分析法，也就是what，why，when，where，who，how，how much。其实我当时真的很懵，肚子里确实没有料。

在分析what的时候，每个人也在思考，罗列了几点

• 消除“定制”这个概念，做产品的组件，不是做定制
• 产品化减少重复造轮子
• 针对项目的进展，如何取一个折中的手段
• 等等...

是什么可以罗列上百种上千种，但是重要的是如何整合成根本原因：高效评估项目中的技术实现方案。

image.png

二

本周后端例会探讨一个话题，产品安全调研。其中需要调研四个内容

• 常见的攻击手段有哪些
• 产品如何应对这些攻击手段
• 目前产品是否有安全漏洞
• 如何使得产品更安全

为了准备这个调研ppt，大概整理两个晚上。

常见的攻击手段自然不用说，在网上一搜索可以找到一系列常见的攻击手段，比如XSS，CSRF等。

至于产品如何应对这些攻击手段，因为我是对产品代码比较熟悉的人，很快可以梳理出目前代码中应对漏洞的方法，比如用户权限校验，上传校验，数据库的读写权限判断等，内容也算是很丰富，能让大家了解到代码中应对的办法。

而产品是否有安全漏洞呢？这一点我分析了很久，根据自己对漏洞的了解梳理出目前产品中可能存在的问题，比如密码的加密方式过于简单，应对大流量时没有应对手段容易导致系统奔溃，过于依赖前端判断等。一波分析下来，整理了好几个问题，有点沾沾自喜，相信肯定可以在例会上大放异彩。

当时认为例会的内容做到这里已经足够了，内容也算丰富。但是例会上的汇报还是让我感叹自己思考不足，是个傻包。

在汇报产品如何应对这些攻击手段，我的内容是代码层面上应对漏洞的方式，其他同事的内容是公司的制度，比如每月一次的安全小组会议，进行系统安全检查，内容如下：

• 确认由谁执行检查
• 检查阿里云安全公告，确定我们使用的是否存在安全漏洞，重点关注服务器、ThinkPHP、Gitlab、Jenkins、Docker等是否存在安全漏洞
• 了解近一个月的行业资讯

在汇报如何使得产品更安全，我的内容是把产品代码层面上的漏洞都找出来，然后针对漏洞思考技术方式，解决漏洞，使得产品更安全。但是有的同事思考的是如何从制度上使得产品更安全。

如安全原则有:

• 身份识别和认证
• 授权
• 审计与问责

再把安全原则套在产品上：非常的beautiful，amazing。

安全原则

还有的同事思考的是：制定产品的安全防护策略。

• 主动式漏洞扫描
• 主动式巡检机制
• 积累应对攻击的常规防护手段

确实，对比其他大佬，我把产品的所有漏洞罗列出来解决其实也没有从根本原因上解决问题。漏洞安全问题千千万万，迭代的过程中总会出来新的安全问题，需要从策略上思考才能根本解决。

总结

• 目前自己思考问题，没有具体思维模型，必须刻意练习已经了解过的方式，比如5W2H分析法，混沌大学的创新模型等。
• 有时候真的太过于纠结细节问题，此问题根深蒂固，必要时必须往后退一步，从大局思考，从根源上解决问题。

交流

• 遇到问题时，大家有什么应对问题的分析方法？
• 大家是否也会太过于纠结问题的细节上，难以后退一步全局思考？