运营中心数据权限三级分类实践

　　去年八月那会儿，运维部被运营中心的数据权限三级分类折腾得够呛。我原以为这活儿就是改改ACL、调调RBAC策略，结果发现根本不是那么回事——运营那帮人要的不是“能访问”，是“能访问但别让其他人知道我能访问”，甚至“能访问但别让系统记录我访问过”。那天下午三点，机房空调坏了，三十八度的环境里，我和老张蹲在机柜后面改配置，汗珠子砸在键盘上都能溅出火星子，隔壁测试组的妹子还端着奶茶过来问：“你们这三级分类到底要分到多细？连用户行为日志都要拆成三级？”

　　最扯的是第一版方案。运营总监拍着桌子说：“我们要让一线客服只能看自己处理的工单，主管能看全组工单，经理能看全部门工单。”听起来合理，但真落地就炸了。比如客服A处理完工单后，主管B要复核，这时候权限得临时提升；可复核完又得降回去，否则B就能一直看A的工单。更离谱的是，有个经理非要让系统记录“谁什么时候看了谁的工单”，但又不让被看的人知道——这他妈不是既要马儿跑又要马儿不吃草吗？那天我改配置改到晚上十点，外卖都凉了，老张叼着烟说：“这需求要是能实现，我直播吃键盘。”

　　后来我们换了思路，直接套了套“优胜劣汰”的逻辑。不是所有数据都需要三级分类，先把那些“没人看但必须存在”的数据筛出来——比如三年前的旧工单、测试环境的临时数据、已离职员工的操作记录。这些数据直接丢进“冷存储”，权限直接锁死，连经理都别想碰。剩下的“热数据”再按使用频率分：每天被访问超过十次的归一级，每周被访问超过三次的归二级，剩下的归三级。这么一分，权限策略直接少了一半，运维压力瞬间降了。

　　但最头疼的还是“权限继承”问题。运营有个奇葩规定：主管离职后，他的权限不能直接继承给新主管，得先冻结三天，让系统自动审计这三天里有没有异常访问。结果有次老李离职，新主管小王急得跳脚，打电话给我说：“哥，我这权限怎么还没下来？客户等着要数据呢！”我查了半天，发现是审计脚本卡在“检查小王是否在三天内访问过老李的工单”这一步——可小王根本没访问过啊！后来才知道，是审计规则写错了，把“访问过”写成了“没访问过”。那天我改完规则，小王在电话里说：“哥，你这改得比写代码还快。”我回他：“快个屁，我改的是你们运营自己写的bug。”

　　还有次更离谱。运营要给某个“VIP客户”单独开权限，要求这个客户的工单只能由指定的三个客服处理，其他客服连看都不能看。我原以为这简单，改改ACL就行，结果发现这客户的工单是动态生成的——比如他今天提交的工单，明天可能被转交给其他部门，这时候权限就得跟着转。更麻烦的是，这三个客服里有一个是兼职，周末不上班，权限还得自动禁用。那天我改配置改到一半，测试组的妹子突然喊：“你们看群！”原来运营在群里发了个Excel，列了二十多个“特殊权限需求”，每个需求都带着“紧急”“重要”“必须今天完成”的标签。我盯着屏幕看了三秒，直接把Excel转发给总监：“这活儿我干不了，你们自己找开发写脚本吧。”

文章配图，仅供参考

　　不过话说回来，这活儿也不是没坑。比如有个需求是“让经理能看到全部门工单，但看不到工单里的敏感信息”——可敏感信息是动态定义的，今天这个字段是敏感的，明天可能就不是了。我们最后用“标签过滤”解决，给每个字段打标签，访问时根据用户权限动态过滤。但测试的时候发现，标签打错了，导致经理能看到不该看的数据。那天我追着运营的妹子改了三版标签规则，改到最后她都快哭了：“哥，这标签到底怎么打才算对？”我回她：“我也不知道，你们运营自己定的规则，自己都不清楚吗？”

　　现在三级分类已经跑了半年，整体还算稳定。但我知道，这不过是暂时的——运营的需求永远在变，今天的三级分类，明天可能就得改成四级、五级。不过无所谓，反正优胜劣汰的逻辑还在，大不了再把那些不合理的需求筛掉。就像老张说的：“运维这活儿，就是一边修水管，一边堵漏洞，永远没个头。”

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!