用技术小细节体现乙方MSP体系中服务大价值

做一个简单的智能分析表，其实很简单，这个不存在难度和门槛。这里面其实比较考验人的是我们对数字的敏感度有多少~~~

​

首先，理解场景化思考

我们做的比较多的分析来自于白皮书也好，经验心得也好，这些在场景化思考中并没有问题，而且还值得人学习与探讨。今天我们来聊聊如何做一个“用户眼前一亮”的售后服务感知。其次加上厂商的各类官方指导文档也越来越多，官方出品不能不服！

在很多地方有云计算架构足够稳定的环境中，我们难免会出现一些“不知所措的情况”，公司经常强调要做好服务，谁可知服务的境界在每个人的认知中都有参差不齐的理解，这话对着工程师说不也是现在大多数公司的问题，其实初衷是好的，但对工程师的冲击还是比较大的，尤其是正在技术上升期的工程师们。

发现GAP

那为何会产生这样的问题，其主因不乏以下几点：

·       工程师热爱技术，热衷于机器的忠诚度

·       心理年龄的发育迟缓

·       客户在成长，需求越来越希望人性化

·       产品竞品多且成熟，服务好才能获得用户

以上这些出现在一家做技术服务的公司，其实挺正常的也能让我理解，因为我就是这么带团队的。：）

现在主流的各种云管工具，甚至包括云厂商的原始console上都有成本分摊等利用率的分析，可想而知这件事已经不再是一个概念性的内容，而是一个实实在在需要储备的技能-财务技能，即：excel的微操能力

​

觉察技术细节

那为何我多次强调是财务技能呢，其实很重要的特点在于：始终都要用数字进行结论性的总结。那我们直接上图举例说明本次话题，怎么干这个事儿？

我们先从公有云直拉的监控数据，来看看：

特点：多、细、工程师视角

需求：基于数据分析业务特点、开源节流的’机会‘

不过过去的工作笔记，基本上都会是一种无力的状态，虽然数据准是很挺准的，但就是不知无从下手，并且厂商的逻辑你不一定能明白~（需要花一些时间来梳理），试想如果今天你的领导让你做一份用户近一个月的服务报告，你可能会从以下几个角度着手去做~！！！

若有雷同，纯属行业标准，为什么？（因为大家都是这么想的，或者领导层还是照搬标准，不会做用户思维的思考）

·       当月问题清单&跟进

·       事件跟进 威胁管理（恶意事件） 各类平台告警总结 基本服务请求受理总结

·       成本支出情况展示（无分析） 固定支出结构 按需支出结构

·       平台IAAS&SAAS&PAAS的结构一览 枚举各类资源清单

·       ~~~~~

·       ~~~

·       ~

写报告，重点是写服务报告，这个没有绝对的好~关键是在于我们接下来索要面对的人，那我这里根据一个实际场景来让大家感受下，一个具体的实际例子来表达下我们当时个人的思路。

​

抓住汇报的小尾巴

汇报人：用户级该云项目一把手

需求：在足够风险可控的前提下，对当前资源进行支出成本分析并给出方案

数据抽取思考：取什么值比较好？

答：三大件（CPU、内存、网络）的平均利用率，因为取该值做出来的结论99%不存在判断性错误。

放什么值对比比较好？

答：超过45%以上闲置，直接按照1/2的缩减来做结论。其余低于45%以1/3缩减做结论。

所以最后excel变成了这样，大家可以当个‘笑话’看看。

有意思的是，这个分析实践我在2018年就实践过了~

给到用户的材料中，用PPT的展示内容，就有了大概几个关键词：

·       本月支出&年支出测算（及支出结构分布）

·       本月计算实际工作负载（平均）情况

·       本月开销预计可调整（含风险分析）对象

·       月节省&年节省总结

·       支出调整方案细节（第一步、第二步、第三步）

·       开源节流展望

最后要用一个更高的视角来将用户的这笔省下来的钱放到更好的’位置‘，比如可以从安全加固的角度，比如可以从相关外部培训服务，再比如从扩展新架构的测试中。等等~~当然这个结论性的说法，完全取决你接下来所面对的’人‘。职位不一样，角度不一样，思维方式更不一样。

总结

当然，这里若是人工产出似乎没有所谓的企业价值体现，所以当你有了这个思维和方法，倒过来去匹配所在企业的平台价值。也就是左手一个平台截图，嘴里一个总结，右手一个表格截图的事情。无论任何时候始终要记住，脱离平台做价值的点在于’用户思维‘的思考。否则你就是一个没有灵魂的人~~

写在最后，

把增效降本做的清新脱俗（人工）生活（智能）化一些，建议不要天天倒腾方法论，来点实在的内容，比舞弄模型或者平台的价值或许效果回更好。