程序员文档写作能力(四)-“善意的掩盖细节”是一种非常有担挡的行为

为什么我们要善意的掩盖细节？难道公司、领导不重视技术吗？喂，已经在这样想的朋友们，请你们醒醒、不要太“玻璃心”，耐心看下去。

掩盖技术细节恰恰是因为这要求写文档的技术人员更专业更有担当而不是代表“真的不去关心细节”。

善意的掩藏细节是因为这要求写文档的技术人员更专业更有担当

拿公司选“云”来说例子吧。当一个公司超过10万人，这家公司的各个部门都有自己“青睐”的供应商。

一般来说这个水比较“深”。

公司转型，要选型云，那么就选吧。

好家伙，把市面上只要做云的供应商统统叫了过来。这个部门喊自己的供应商、那个部门叫自己的亲信。

选一个云厂商，来了30多家都说自己做云。

一般来说云厂商对一家公司是很至关重要的一个选型，且只会选择一家。一旦选中，对公司来说轻易就改不了了并且还会影响到公司未来的发展方向，因为infrastructure和development是一家企业是否可以腾飞的两个核心“翅膀”。

相对被选中的云厂商来说，一旦被选中也意味着long term business可以做。

这个选型完全超越了business本身了，它更多层面是一个“战略”层面的事，踏错一步万劫不复。

可是，现在手上有30多家云厂商都说自己的云可以用。选哪家？

企业一把手是很难做出这种决定的，或者说如果当中没有有专业人士过滤一道的情况下，他很难做出“正确”的决策。

这时对于CTO、对于架构室团队来说这种场景是相当考验团队和个人能力的。

30多家你要选出一家，然后所有人的万一都说你对这一家有倾向、你拿了这家好处，你怎么解释？

如果你顺着某几个“企业内部的大诸侯”的意思选了另一家，最后无法满足业务的快速发展，所有人此时正好甩锅，说是你的“锅”，那就更惨了。

个人荣辱其实还是其次，关键是在于一家百年老店因为一些非专业因素彻底丧失了数字化转型的机会。。。隐隐约约中心里一股“侠义之气”由然而生。

斗争要讲究技巧；后发才能制人；

30多家供应商选，于是就选吧。

选要选，我们得立一个标杆，对吧。什么标杆呢？

很简单，第一先把企业全球总部颁布的安全条款-有150条+个信信息安全法+等保3的要求扔在所有供应商面前。告诉所有供应商，要进入决赛，这些条款先得签字确认并作为今后合同的附件。

我们都知道，真正做云的，都有一个基本的东西，叫“等保3”。如果是金融级别的云服务是需要等保4级别的认证的，如果是支付类你还需要有符合国家的PCIDSS协议审核通过颁布证书的私有机房或者云。

这样的云用手指头去数一下不会超过10家，30多家。。。我心里暗笑。。。这都哪里来的。。。个个号称自己是全国第一云厂商？

在我之前，其实已经有某个部门走过同样的老路了，CEO在选型会前告诉过我，其实这次选型算上我这一次已经是第3次了。

之前也是因为选型死了两任CTO。

为什么会死？

CTO是怎么被搞死的

30多家厂商，首先先要满足等保资质、要满足个信法、还要满足全球总部颁布的安全审核条令，这可得有300多条明细项啊。这一波就能淘汰一大片“号称自己可以符合的虾兵蟹将”呀，这不很简单？

于是我去做了进一步的深入了解。“死”的CTO留下两波人，这两波人中不乏有网络专家、技术专家。

于是他们这次又准备“把我这个CTO也作死”，当然，他们不是故意的哈，只是说他们这种手法真的会“作死”人。

为什么呢？来看他们之前如何作死之前的两任CTO的！

选型时我们需要说清为什么另外那么多家在“安全条令”上不能满足我们的需求？

那你要说给CEO听的呀，告诉他哪些家云供应商不符合我们的安全要求。

你们猜他们是怎么去和CEO作这件事的汇部的？

1. 上手先对着CEO说了一通网络个人信息安全法。。。每一条都说，说到第47条时（差不多有70条），这个会已经过了3个小时了；
2. 还要继续说总部颁布的那150多条security compliance，CEO摆摆手，摇摇头，手掌心对内掌背对外狠狠的一挥“这些细节难道不是你们就应该去了解的吗？你们把这些细节告诉我，我能帮到你们什么呢？要你们做什么呢？是需要我来替你们选型是吧？”

喏！就是这么死的，他们真会拿出每个厂商，然后每个厂商300条讲一遍，这么来个4-6小时内部评审。然后讲完了还没结论。

当评审完了，这边一些大厂已经等着我们的系统上云后做共同递推广告，留给我们时间只有4个月，而如果用这种速度选个云就得4个多月+签合同谈判+实施，这半年多就没了。企业生意不要做了。

我就是在这种情况下开始一个人接手所有被降级、折散的原IT部门的。

给到我的第一件事也是选云、也一样来了30家供应商、一样做安全资质开始做起。

其实这事很简单。

我们先来看这件事的第一步：把不符合或者不愿意签署同意我们总部颁布的安全策略以及无法满足将来等保3审计要求的云厂商上手剔除掉。

光《中华人民共和国个人信息保护法》有近70条，你一条条解释给老板看吗？Why？你是用来干什么的？这不是搞互联网技术人的本职工作吗？

好，自己学法懂法，时间不多，快速学习、抽象、总结。

• 然后把它总结成核心的7个点。
• 然后每天安排5个供应商讲标，每个给予1个半小时。
• 现场20个人一起听，每个人手里有这7大项，听完后打上分每一大项5分制打分。
• 有一项不满2.5分的就直接剔除掉。

只用了6天，30家供应商里只剩8家符合资质了。

第6天快下班时直接把这个剩下的8家以表格方式平铺在一个PPT片子里。再附上打分的标准、所有人一起对每家被淘汰供应商签字的PPT，两页，第三页附上7个打分项。一共三页片子以邮件形式发给了我们CEO。

CEO于17：20左右收到我邮件看了一眼，让秘书找我。

他告诉我，我只用了6天完成了前面有人花了2年多都搞不定的事，然后让我对这三个片子解释一下。

“你现在起有。。。我看看，40分钟时间 ，18：00下班。。。来，给我解释一下，哦。。。不，你只有39分钟了”。

于是我先从最后一张片子开始告诉他，个人信息安全法在中国被看得很重是国家领导亲自监督的下成型的，是等保审核的重中之重，没有等保你企业也不要做电商了。

CEO点点头“I Know, I Know“。

然后我告诉他为什么我归纳成7大项，比如说这一项叫“小程序对个人信息采集用户同意协议”，你对用户存储是要脱敏、独立存放的，你如果不遵守。。。500条泄漏。。。你要去担责的，因此你来看第一页里，有这些这些那些。。。。。。这就已经有11家公司不符合”。

CEO用手撓撓头“这些，都是哪些部门推荐的供应商？”

然后我把7大项里说了3项，CEO已经知道我列的这7个项如果有一项低于2.5分，这个供应商如果真的“有幸”成了自己的云厂商，那么我们的电商应用一上线即会被“因为不合规被干掉”。

他说：竟然有22家不合格？

我说：嗯，你看，选型时我方有20个人，这是他们的手写签名和打分。

于是我开始展示第二页PPT，那上面都是手打的分数和打分完每个人自己签上的名。

到此，第一轮顺利结束，我一看表，离18：00还差7分钟，于是和CEO两人闲聊了一下，还喝了他亲手调的咖啡，然后下楼回家。

3张PPT片子历时6天VS死两轮CTO近3年还没有结果！

这是第一轮“善意的掩藏细节是因为这要求写文档的技术人员更专业更有担当”这句话的意思到此是不是大家已经有了那么一点感觉了？

在上例中掩藏细节的手法

个人信息安全法、等保审计、总部颁布150多条安全策略合计达300多条细节条令。这些是细节，这些细节的结果是什么？不可能说是300多个方向，它们加在一起归纳成7个点。

我自己是互联网技术出身，对于个人信息安全法和等保当然了然于心，这是我的本职工作、是我的专业，在这个专业领域我绝对可以给出我的专业意见。无非不熟的是我对现在这家公司总部颁布的那150多个安全审计条款，这个学习很快的，因为安全领域的东西它们具有“共性”，因此也只是花了2个通宵+咨询了企业法律顾问就能达到的手段。

因此我把它们归纳成了7个打分项。

在上例中有担当的手法

在了解了这些细节和抽象以后，我要做的就是组织讲标、组织打分。有人此时会说了，那20个一起打分的人来自于各个部门，打分时里面也有他们自己“青睐”的供应商，别人为什么不敢打高分或者说你的决定才是有“偏见”、有“倾向性”呢？

很简单，越是搞这种事的人我告诉你们呀，越是聪明，这些人呢绝顶聪明，就是因为太聪明了，因此他们才可以一眼看出你列出来的这7个打分项可以把黑白分明到你连无端加0.1分都无法“自圆其说”的地步，他们就知道了这一波可不能再乱打分了。

这是建立在大量细致调研和长达近8年的这方面的专业知识的积累上的，是勿庸置疑的。当然，这些聪明精们还真的去佐证、旁证、甚至通过各种专业渠道去求证

• “。。。唉。。。你这个没这个证你投标时说你有。。。你怎么搞的？”
• “你这个资质有吗？没有，你当初投什么标？”
• “唉。。。XXX总，你们这个条款是要作为合同附件的，如果不作为合同附件我们可以确认，可是作为合同附件我们做不到”
• “你做不到来投什么标呀”。

喏。。。。。。我说的“毋庸置疑”。就是建立在大量细节了解和对这一行业太熟悉的基础上的“权威”。

权威是>权利！

因为我有了专业知识因此我才敢做这个“担当”，担当后被人推反这个不叫担当这个叫“卖大力丸”。企业级的技术架构不是只靠“拍胸脯”的。

继续“善意的掩盖细节”、继续“更专业更有担当”

前面一轮PK只剩得8家了，对不？剩下这8家里要在仅有的两周内选出1家来作为企业永久的云厂商。

这8家可个个不是省油的灯，我可以说BAT都包括了。

这时对于一个选型者或者说此时我更像一个在审核命案的大法官，那是轻易不能落笔的啊。

而且我看了一下这8家里。。。也有那么几家是企业内部一些诸侯的“门生”，甚至是“己有”供应商。

但是从我开始看标和之前的工作经验以及CEO给到我的数字化转型业务目标我其实心里已经圈定了只有两家做得到这个将要爆发的业务量，其它都是“扯”。

这时你不能说“你有担当，你就拍板这两家了”。难就难在如何让CEO也知道，这两家一定是最适合的、最好的。

云这个东西太技术了，我随便下面列几条核心指标，大家就知道技术到什么程度了：

1. PAAS能力；
2. SAAS能力；
3. WAF能力；
4. CDN能力；
5. AI能力；
6. 大数据能力；
7. 云主机款式、型号的区别；
8. 是否支持全球运营的能力即国际上在哪些城市有机房？
9. 扛DDOS能力；
10. 有没有近源打击、流量清洗、流量黑洞能力；
11. SLA-故障响应解决速度和保障能力；
12. 弹性扩充能力；
13. 对于微服务、最前延的一些云原生的支持能力；
14. 安全性（除去安全法规这种的安全如：病毒、补丁）；
15. 等等等

随便已经可以列出10几点点了，当时我一共列了71个点，这71个点每一个点都是可以作打分项的。

但是要知道71个点那真的是很细节了，有些已经精细化到了：同核数同内存同磁盘大小的IOPS、吞吐性能的比较“这种点了。这种点你拿去和CEO去说，你想要表达什么呢？是不是你想潜意识就是让CEO来替你拍板喽？那需要你做什么呢？你是CTO呀？

对不对？

上面这些过程化的东西大家仔细看完是不是这么一种感觉？碰到一般没受过训练的人就直接拿了71个点去打分，打完分让CEO签字了。

那要你干什么呢？

71个点代表什么？

对我的业务意味着什么？

所以我列完了71个点后。我作了一个Excel，纵向是8家云厂商的抬头、横向是71个点。

然后我依旧召集20个人进行共同打分，这次很快，因为只有8家厂商了，我们一天看3家，用了3天就把8家云厂商的分数都打出来了。

打完后汇总到我这。

然后我做了一次去重，怎么去呢？71个项里有63项所有厂商可以拿到的分数都是一样的如：你的宽带是否可以拉城际、省际间的宽带？300兆弹到500兆的宽带你的收费是一次性投入多少每年持续维保又多少。

由于这8家都不是省油的灯，都是大厂子，因此大厂子在些一些非常标准的技术规范和收费上几乎是无区别的，这是因为业界的规范和收费标准就是这些大厂子定出来的。

去重去掉63项后我发觉了有8个点，这8个点是真正的直接关系到了一个企业使用了这个云对企业今后会造成什么好的、不好的印象、是不是会在未来1年内出现“瓶颈”。

大家知道，数字化转型特别是中台，这个东西不上的时候没人知道它的威力有多大，一旦真的上成功了，对于一个企业业务一年后的变化不是一倍，而是四、五倍这样的变化（说五倍已经算少了，我们极端情况创造过一个月完成大半年的业务指标）。这种变化对于一个云的要求就是“资源不受限制、高度弹性伸缩、符合云原生标准、用多少付多少、随开随关、热扩。”。

在我前文中提到过，一个企业要数字化转型的成功关键在于两个翅膀需要长丰满，一个翅膀叫infrastructure能力、一个翅膀叫开发能力。

很多传统型企业转型慢、甚至失败，很大程度其实和去IOE不彻底延用老旧的CDC、IDC模式有关。这里面不只是技术的问题，有企业legacy本身问题、有搞不清的“关系”层面问题。

必竟国内像BAT这么大刀阔斧、推翻式重造的只有那么3-4家企业，这种企业都有BAT在背后做推手才能做到“壮士断腕”式的改造。

因此，大家没有经历过的人可能不知道有时一个“IT的基建”上的耗费可以达到9位数，这种规模的改造很难，让人把基建和“难”以及一定耗钱划上了等号。

因此有一些云厂商也就从一开始PUA了你的企业让你觉得扩资源就要耗钱的，因为很难的，难了就代表贵！

而很多场景中的事实不是如此，如果你真的是搞专业互联网架构、设计、微服务的是明白这一层含义的。我随便举个例子来说：有时一个redis的改造比你扩10倍网线、DB容量都要来得省钱和省时间，对不？

好，回到正题。

我把这8个点摘出来，然后把这8个点对应着每个云厂商的描述、他们的资质、他们的案例，甚至。。。我还真动手做了不少POC，当然近8年的互联网的积累这方面的代码我手里还是自己平时写了上百万行代码的各种POC是有的。

对于通过描述无法充分论证的，我拿POC上去运行一下，30分钟内我就可以得到结果了。

额外多花了3天，我把一些非常明显和直接可以说明问题的点这边列出来给到各位看一下你们就明白你们会选哪家云厂商了。

核心技术区别点一、mySQL PAAS多分片机制的支持度

为什么mySQL PAAS也就算了，还要加一个“多分片机制”？

mySQL常用的互联网设计叫主从分离、读写分离。

那么一些云厂商都支持这种PAAS架构，PAAS好呀，省得自己动手去设那150多个参数了，买一个PAAS叫1主1从，直接拿到两个用户名密码企业只需要做应用就成了。

可是。。。大家有没有想过随着你的业务量不断的上升，就算你的redis、缓存、双重缓存、varnish、nosql做了再好，可是业务量的上升是很快的，比如说我们说真的落到数据库层面有每秒10万的并发连接。你们觉得这个mysql的master或者是slaver库再强，要强到什么程度可以让你开出一个max_connection=100,000？

想想都不现实。

那么就是需要支持多主、多从机制才能解决这个问题。mySQL它不是oracle，它本身是不支持这种我们叫cluster的模式的。

因此业界常用的是PXC或者是MHA来代替mySQL的cluster，但是无论是PXC还是MHA，自己去实现是很复杂的呀，那么如果PAAS层已经本身可以解决同时最最重要的是可以“热扩容”，就这一个点大家就知道对你的企业应用有多重要了。

一个企业应用运行的好好的，中午12：00业务部门做了一个推广。。。omg，下午13：00来了一个10几万的并发，此时如果你只有1主1从，你怎么玩？

好，现在我有了多主多从机制，无论多少个主还是多少个从它都只分成“主和从”两个用户名和密码，那么你的spring boot如果使用了标准的RoutingDatasource是不是连代码都不需要做改变的，同时在infrastructure层和应用层就能做到“热扩充”呢？

你们知道卡屏5分钟、15分钟对一家日销几十万单的企业意味着什么吗？这15分钟损失的钱可能超过了你3年工作的总计税前工资总额了。谁赔的起呢？

这个点，能做到的，只剩3家了。

再来一个点。

核心技术区别点二、除了有CDN图片静态缓存功能外还支持图片鉴黄、暴、反和“无损压缩算法”的能力

• CDN是云厂商必备的，它用来静态缓存你手机端看到的那些图；
• 鉴黄、暴、反是一些商品评论、头像上传时故意有上传上万张这种图片，那个网站也不要玩了。因此做了好的是在上传图片时云自动把图片放入一个“沙盒”，在毫秒级完成图像鉴别功能，这个不是一般的能力，这一块考验的是云服务集群、云厂商AI能力的真家伙。如果有不符合规范的图片，这个图片会自动被替换成“图片无法展示的一个圆圈型当中加一横”这样的图片显示在企业的网站上的；
• 无损压缩算法，嘿嘿，这一块太多人不知道了可能。一个图片走CDN，原则上是减少了企业服务器的带宽和流量压力的。我们都知道现在的网上商城越来越丰富了，各种商品文描、轮播图一个比一个做的那个高清呀、甚至还有GIF动图，那一个个图让人看了是“垂诞欲滴”、勾起你的消费冲动，我告诉你一个烤鸡的动图可能要24兆，你。。去放在CDN，然后从CDN下载到用户手机上，哈哈，你觉得这个首页打开速度可以达到几秒？同样，你们去看BATJ的一些商城，它们也有动图，它下载到你手机上的速度有多快？毫秒级？为什么？它使用了一种类似Google的图片无损压缩算法，它和传统的压缩是不一样的，把一串什么0、1归档，NO，无损图片压缩做了好的不这么干的，它用的叫“特症还原”技术。。。有点像“移花接木法”，可以甚至对图片压缩率达到百分之几百；

如果一个CDN兼居这三者能力，还挺便宜，哎呀，这样的CDN得有多香？

核心技术区别点三、手机鉴别真伪能力

什么叫手机鉴别真伪？对呀，我前面不少博文提到过黑产有一种叫“手机墙”技术的，家里几堵墙，每堵墙上插了300-500个手机，因为对这种黑产来说手机号真的是可以不用实名就买得到呀，还很便宜，因此这些手机都只是来自于一个人。它们要么做薅羊毛、要么发动不良的攻击。

而这些手机号都有一种“行为模式”的，那么这种行为模式有一个分值区间段，低于多少区间段的手机来领你的券，这种券你给它吗？对于这种低于一定区间段的手机在领券时你可以直接给到它一个提示“亲。。。。。。活动已经结！亲。。。。。。券已经领完”。

云厂商上在web服务根上进http请求时就能在毫秒级反映出这个手机号的这种“行为分”，你们不觉得香吗？

好了，不多说，这边我只举了8个点中的3个例子。

这8个点我写成了一张PPT，就一张片子，我不可能把这些上面的论述、包括我的POC结果都附在一张PPT里的，如果要那样我写100张PPT都不够写的。

怎么办呢？我把这8个点对企业的影响用文字转变成以下这种普通大众可以听得懂的话术：

• 三合一CDN，可以让企业的微信小程序乃至今后的APP在内容上不受制于图片的内容、大小的限制。可以把微信小程序和APP做了比我们的“友商”更漂亮、更丰富同时还获得更安全的能力，打分：A厂-5分 B厂-4分 C厂-5分；
• 手别鉴别真伪能力，可以让企业具有了“业务风控”能力，可以让企业不至于自己去闭门造车的开发一套手机号风控系统而直接变成开箱即用成熟的这项API立刻用在我们8月份要准备上的第一批“领券活动”上就能起到“防损能力”；
• mySQL PAAS多分片机制，可以让我们企业在面临大促时无硬件资源上的限制，使得我们的小程序乃至今后的APP拥有“huge capacity”；

就是这样的8条总结附上CEO。

上例中掩藏细节的手法

71个点，如何证明？it's your technical business, not my job。

好，说的对，这的确是技术人员的专业知识，不需要告诉领导，在这个领域，你拿这份钱你就是权威。因此我自己去做调研。

上例中有担当的手法

我不能仅靠看资源、听别人和我瞎BLA BLA就信了另个，我要自己动手、甚至去自己建立一些sample、甚至我会用“来来来给我玩几天”，然后截图、截屏来“论证”。

因为，那群所谓的“聪明人”在你最终把8家剔的只剩3家时，他们还是会挑刺的呀。。。喏，看：“你瞎说，人家明明有”，“你拍脑袋，你说的不准”。

那我自己都亲手玩过一遍了、有截屏、有截图、同一个CASE正反两个场景我都有结果论证。

当然，最后是全票通过。

到最后只剩下三家云厂商了，此时，我把它们呈在CEO桌面，投影打出来，一看：

A、B、C三家，都符合这8点，C太贵，不要了。

剩A、B。

然后CEO给我们讲了一个总部的policy故事，故事说：有些零售商不可以用“竞争对手的产品”。

最后，只落得一家，CEO一拍板，GO。

然后我翻开了一下日历，整个云选型我用了1个半月，完成了前面3年死两个CTO都没完成的事，推动了公司开始进行数字化变革的第一步，并且这一步是迈好了。我就越发有信心走下去了。