9同行回答
建议推广统一日志平台，推广服务。这样在管理的角度会有统一的收口，后期运维部门可以新系统上线或服务变更时对系统层日志进行统一的纳管，应用层和业务层日志接入需求、统计需求、告警需求及分析场景可通过ITIL工单进行申请，日志平台权限管理对接ldap或IAM进行初始权限分配，后期在日志平台进行微调整，从安全角度和平台使用上会达到一个平衡。
在日志平台使用及维护过程中，第一责任部门为运维，其次是项目所属的业务部门或项目组，最后为运营或辅助决策，因此运维部门可结合企业现状进行日志规范的制定及推广，近几年各互联网的大厂或金融公司都在推动这方面的工作，实际改造过程会比较痛苦，有较多的外部系统及老的平台，改造工作量较大，但是后期效果都会比较好。
有比较好的行业日志改造实践，通过系统开发人员对现有日志进行归纳总结，生成summary日志，这样就大大的减少了开发工作。
收起银行信息系统日志分析应该从以下几个方面考虑：
1、制定日志规范和标准，规范应用日志，包括日志文件名、日志格式等，改造存量业务系统日志、新建系统日志必须根据规范执行。
2、搭建企业级日志管理平台，收集网络设备日志、存储设备日志、数据库日志、安全设备（IPS、IDS等）日志、中间件日志、应用日志等。
3、实现目标包括统一日志存储、检索、监控告警、故障定位、审计分析等
收起1、问题中，第1点需要企业从SDLC的软件研发阶段即落地标准化日志的输出，第2点重点是引入成熟的日志管理系统，1也需要。
2、虽然日志中有很多业务、客户方面的知识有待挖掘，但当前对日志的分析目前主要是运维侧在做，因问题中看起来只指应用系统日志（系统或硬件日志成熟方案很多），我觉得如果是运维侧做可以考虑如下：
1）定义企业的日志分析方向是什么：满足监管要求存储日志数据？根据关键字的监控报警？梳理出日志中的业务数据、客户体验、性能、链路关系等等？以及日志分析是提升业务连续性，还是提升IT系统交付速度，或向业务侧赋能？不同的方向，针对的平台、日志规范、日志运营不同。
2）平台建设：选择商用产品主要基于企业希望花钱减少人力资源投入，现在开源ELK的解决方案也很成熟，ES版本更新很快，且国内代理厂商也多，如果愿意投入人力资源做日志分析，值得选ELK相关方案。如要对日志进行进一步分析，可能需要对非结构化的日志进行二次加工，才能更好的使用。
3）日志规范：日志很乱，如果不只是为了简单的监控，或配置一些可视化信息，那需要推动研发侧优化日志格式与标准，需要针对特定系统进行特定的日志分析，需要加强日志运营。
1）2）3）应该是并行，没有先后，持续推动。
我觉得银行系统的日志分析这个事情，需要从以下几个方面分步推进：
1. 日志的标准化问题。
应用系统、中间件、数据库、操作系统、设备等都会有自己的日志。每一种日志都会有自己的控制参数，比如日志的级别、日志的格式、日志的标识等等。如果日志的内容、格式、提取标识不能统一，那么就算把所有的日志都能收集起来又又何用呢？
2. 日志分析的模型设计问题。
收集日志无非有这么几个功能：实时报警，趋势分析、防患未然，深度挖掘、主动优化。除了实时报警无需二次设计相关模型，其他两个功能都需要进行二次加工，从日志的时间维度和内容维度去分析可能和潜在的问题和风险，这本身是需要找到日志与日志甚至日志与其他信息的相关性。这需要在实践当中结合具体系统特点不断分析摸索。
3. 日志分析的工具和平台问题。
我们知道，日志量是非常大的，尤其是级别开得越低，日志的量级就越大。那么对于这样大的数据量，我们采用什么样的平台既能处理这样大的数据量，又能将我们的分析模型嵌入到其中，这个是需要仔细斟酌的。
所以，综合考虑，日志报警也好分析也罢，此类问题是需要从这几个方面，有先有后来考虑的。特别加一句，如果第一个问题（标准化的问题）无法逾越，那么不妨考虑二次标准化的建立，也就是说通过 “数据收集 -> 标准化加工” 的方式来形成初步的标准化，然后再跨越到第二步、第三步。
收起1、推广统一平台，自带日志，这种方式需要研发投入，并且对于有大量采购系统而非自研系统的金融行业来说，对项目管理能力，协调能力等有很高的要求。
2、统一日志平台的方式相对可落地性更高一些，同时也可以兼容不类型的日志，但是针对日志平台的解析开发工作可能会相对多一点，但是毕竟涉及到的部门和项目都比较少，可行性和可推动性高一些。
当然在有统一日志平台的同时，也可以推动各业务系统日志标准化，简化日志平台的解析开发工作复杂度，有利于日志分析的覆盖面和适应性。
以个人大型股份银行的建立历程与经验来看，比较倾向于第一种方案：
首先让自带日志标准、规范、可读、可控、可关联后，后续的服务才能发挥更大的价值；
这样的缺点是前期投入的成本较高，以明确的目标为导向。
第二种方案优点是短平快，短期收益较快，属于过程导向，如何后续要达成有效的目标会付出更高的成本。
收起