业务要一份数据，运维代查还是给账号

结论先行：业务方要一份日志数据，只有三条路：运维代查、给账号自助查、订阅固定报表。选哪条不看谁更先进，看三个条件——这个需求多久来一次、涉及的字段是否固定、查错了的代价有多大。三条路各有各的天花板，混着用最费人：同一个需求反复代查，人在加班；账号发了没人用，权限成了摆设。

本文只谈查询入口该放在谁手上、按什么条件分流，不谈采集侧范围怎么划，也不谈平台对外接口该对接哪几家。范围与对外接口各有各的判断依据，接到这一篇里会把查询问题讲成权限问题。

三条路，各自的天花板在哪

这三条不是互相替代的关系，多数单位的实际状态是三条同时存在，只是没有分流的规则。于是出现一种典型场景：一个本该订阅报表的常规需求，被当成临时需求代查了半年；一个本该自助的高频查询，因为没人解释字段，一直在群里问。

分流的三个条件

其一，频次。一年只有两三次的需求，代查的成本低于建一套自助能力；每周都要来的需求，代查就是长期负债。

其二，字段是否固定。字段固定、条件可枚举的查询适合做模板或报表；需要临时组合多源条件、每次问法都不一样的，交给自助才划算。这里的判断标准不是「复杂不复杂」，而是「每次是否一样」。

其三，查错的代价。查错代价高的场景——对外披露、计费、合规举证——不适合完全放开自助，原因不是不信任业务方，而是出错之后很难追溯是谁用哪条语句得出的结论。这类需求适合固定报表加口径说明，把不确定性收在生成报表的那一端。

给账号之前，先做两件事

很多自助查询最后无人使用，根源不在账号，在缺两样东西。

一是字段说明。平台里的字段名是技术侧起的，业务方看不懂；同一个「成功率」在不同报表里可能是不同分母。要么整理一份字段与口径对照表，要么在查询界面上把常用字段做成中文说明。这件事看起来琐碎，实际决定了自助能不能成立。

二是查询模板。把高频问题做成几套现成条件，业务方改几个值就能出结果，不需要从零写查询。模板同时解决了口径问题——大家都从同一套模板出发，结果才可比。等用熟了，再放开自由查询，学习曲线会平缓很多。

报表订阅的边界要提前讲明

订阅制最大的误解是把它当成监控。报表能覆盖已经想到的问题，覆盖不了新出现的问题；它按周期跑，中间发生了什么它不知道。所以报表与告警的定位要分开：报表回答「这段时间怎么样」，告警回答「现在有没有事」。把两者混同，常见的结果是报表天天正常，故障却是用户先发现的。

另外，报表的口径一旦确定，改动要走变更。上游系统升级、字段含义变化、采集规则调整，都可能让同一张报表在「什么都没改」的情况下悄悄变样。可行的做法是给每张报表标注口径版本与责任人，改口径时同步通知使用方。

边界与前提

三点说明。其一，文中关于平台检索能力、自定义报表与权限分级的描述为通用设计口径，具体实现以所选平台实际提供的功能为准。其二，查询入口下放会扩大数据可见范围，涉及个人信息与敏感字段的部分，应按本单位合规口径与本文之外的分级规则另行约定。其三，本文涉及的频次与比例均为经验性参考，不同单位的实际分布差异很大，宜先统计一个月真实需求再定分流规则。

判断这件事有一个很省事的办法：把最近一个月的临时取数需求列出来，数一数有几个是重复的。重复的那几个，就是该做成模板或报表的部分。深圳市奇摩计算机有限公司在做日志平台项目时，习惯在交付阶段就带上这份清单和几套查询模板，而不是只交一个能登录的地址。预约咨询，可以按你手上的需求记录，先做一次分流。