繁华落尽，做数据有了“面子”，更别忘了“里子”
不同于10年前，近几年团队获得了长足的进步，我们做数据的“面子”也变大了，比如在部门的工作报告中，原来只有一页不到在阐述数据工作，但现在已经能占据很大的篇幅，在公司级的项目中，大数据内容的比例也已经非常高，数据团队有更多的机会出现在公众场合。
比如每次公司经营分析会，老大都会提上一句大数据要做好服务和创新，一方面我们会有压力，另一方面也会有些自豪感，觉得做大数据是一件很有价值的事情。
这些待遇可并不是每个公司的数据团队都有的，大家默默奉献一整年，但公司老大的工作报告里可能一句话也不会提，因为被认为是常态化、事务性的后端工作，是应该做的。
表哥的出账也许很辛苦，但由于是例行工作，不放到公司的报告里也正常，但假如是做了一些优化呢？其实只要不是惊天动地的改进，这些都是小事，不值得出现在领导的报告里。
这种导向本身没什么问题，后端应该要有点做了好事不留名的觉悟，可惜的是，那个时候应该做好的事情，现在可能做不好了。
一方面可能是把原本该投入在这些事情上的资源投在了创新上，另一方面可能是应该做的事情正在发生变化，而公司仍然认为保持原有的投入就可以了。
有个词叫作路径依赖，一旦你发现有条路现在回报很大，就会拼命的投入资源，不自觉就会减少其他方面的投入，最终积重难返。
就数据工作来说，数据运维是容易被牺牲掉的，并不是说会有意减少了运维的绝对投入，而是相对于前端，运维投入的比例会相对减少，由于前端和后端往往是关联的，前端一旦做大，后端原有的保障体系就会吃紧，如果后端无法与时俱进，前端就会反受影响。
去年团队连续发生三次数据关联故障，把我的视野重新拉回到数据运维体系，这里复原下故障的经过，你会觉得有点夸张，但事情就是这么巧：
第一次故障：产品团队误删某张生产表，为了防止类似的事情发生，运维团队决定将重要表进行备份。
第二次故障：运维团队某人员手工误操作，将上一次的表再次删除。
第三次故障：在恢复表的过程中，发现运维团队第一次故障后采取的备份策略未生效。
这次删表事件对于业务产生了一定的影响，团队也做了深刻的总结，如下所述：
第一次故障的总结：
（1）取消产品团队在生产库的删表权限，建表删表操作统一运维执行（当然这会降低灵活性，大家都懂的）
（2）回收站设置时间延长
（3）重要表集群定期备份
第二次故障的总结：
（1）开发前台操作工具，降低误操作风险
（2）在前台工具未完成前，高危操作要多人确认，取消部分运维人员的后台直接操作权限
（3）运维人员技能评测和持证上岗
第三次故障的总结：
（1）运维组织进行调整，开除相关责任人
（2）运维团队重新梳理工作项，查漏补缺
这些总结看似没问题，三次故障连续发生看似偶然，但我还是觉得不对劲，比如自己已经半年没有听过一次运维的正规汇报了，在数据创新大步往前的同时，整个团队（包括自己）对于运维工作的关注度大幅降低了，这是根子问题。
第一，大家都太想show，领导安排的创新要做，但基础工作可以将就，比如近几年最优秀的人总是被优先安排去做数据产品，自己每周最关注的工作总是数据创新。
第二，业务发展太快，但运维团队没有与时俱进，比如原来运维手工的操作很少，随着前端需求越来越多，现在每天运维的后台操作工单急剧上升，忙中出错的的概率大幅提升。又比如很多数据表随着业务的高频使用价值在急剧上升，一旦出错就是大故障，但相关的数据保障机制并没有同步跟上。
后来我在想，假如这次运气好点，第三次连锁故障没有发生，也就没有这一次的反思机会了，但雷始终在那里。假如你是企业里最理解数据道道的人，一定要盯住这个灰犀牛，帮助企业守住底线。
自己做数据创新这么多年，发现数据创新做到最后，繁华落尽，拼的还是稳定的基础数据保障能力，没有这个1，后面再多的0也没啥用。
自己做得最成功的其实是很多年前就开始布局的A、B、C数据的研究，现在他们在数据产品中发挥着中流砥柱的作用，但我现在似乎忘了初心，PPT做多了，工匠心少了，不再有C、D甚至E了，这意味着潜力的挖尽。
相对于做数据挖掘和产品的，现在搞数据治理的人往往显得落寞，但能沉下心做好数据治理的，那真的是最可爱的人啊。
自己所碰到的数据产品的大多数难点问题，大多是数据问题无法解决，客户抱怨最多的，必然也是数据，界面可以将就，但数据不能。
最近团队在对产品进行分析时，发现某个产品长期被投诉，究其原因，其实来自于2年前我要求解决的一个基础数据问题，由于当初的负责人被征调去做另一个耀眼的看得见的产品去了，留下了一个对另一个新人来说完全是全新问题的烂摊子。
我要反思的东西很多。
“我等了三年，就是想等一个机会！” 谈谈数据团队如何为自己争取资源！
点击左下角“阅读原文”查看更多精彩文章，公众号推送规则变了，如果您想及时收到推送，麻烦右下角点个在看或者把本号置顶！