生产环境开发环境数据库如何更新

① 项目中的某个方法在开发和测试环境下都能查询出数据，但是在生产环境下不行，请问一般是什么原因

1. 版本升级的过程中，数据库数据是否有丢失情况

2. 如果数据没有丢失，检查你的查询语句是否正确

3. 如果确定查询语句没有问题的话，应该是数据库缓存的问题，数据库对象是没有数据的，你重启你的服务，再测试一下
   

② 如何切换开发环境和生产环境

SSL不同 开发模式：可以使用 WebLogic Server 安全服务提供的示范数字证书和示范密钥库。利用这些证书，可设计出在由 SSL 担保的环境中工作的应用程序。生产模式：不应使用示范数字证书和示范密钥库。如果这样做，将会显示警告消息。要使用正式申请的数字证书部署应用程序不同 开发模式：WebLogic Server 实例可以自动部署和更新驻留在 domain_name/autodeploy 目录中的应用程序（其中 domain_name 为域名）。生产模式：由于自动部署功能已禁用，因此必须使用 WebLogic Server 管理控制台、weblogic.Deployer 工具或 WebLogic 脚本工具 (WLST)。生产模式一般使用BEA的JDK，开发模式就无所谓了

③ 数据自动化运维应该注意哪些事项

一、基础数据概况

CMDB中文是配置管理数据库，存储与管理企业IT架构中设备的各种配置信息，与未来的IT运维管理标准化和流程化紧密关联，并且支持流程的运转。运维管理平台创建初期或初版中的CMDB更多是偏向IT资产管理，我们在这里定义的IT资产管理，暂时抛除公司个人使用的普通PC机。

日志主要存储CMDB中涉及到服务器或是其它设备的日志信息。

DB主要是所有IT系统的数据库信息，包括运维管理系统本身的数据库。由于数据库的重要性，所以在基础数据中单独一个模块管理数据库，包括生产数据库、测试数据库、开发数据库。数据库的日志放在日志模块进行统一管理，监控和备份。

知识库主要存储日常运维管理中发生的事件、问题以及一些经典问题的解决和常用的解决方案，主要起到运维管理辅助的功能。

二、基础数据三要素

基础数据要求完整、准确、实时，这三个特性缺一不可。

1.完整性

完整性，要求在数据采集整理阶段，要一一梳理，不能有遗漏。任何一个设备的疏漏都将会导致未来出现问题。例如最近的勒索病毒在防范上需要给服务器升级打补丁，这个时候就是根据服务器清单一一对照，升级。如果有遗漏落下的服务器未及时打补丁而导致病毒入侵，后果将很严重。那么，如何做到完整性呢？大致可以分为以下几步：

文档库也包括一些企业或是部门的规章制度，与供应商的合同条文等。主要是涉及到IT系统文档的一个存放和查阅的地方。

运维标准和运维流程的文档一定是必不可少的。因为运维自动化的前提就是运维的标准化和流程化。如果没有明确的标准和规范的流程，运维自动化就只能一直停留在测试环境的假想空间中。

总结

基础数据在整个运维管理中起到基础、奠基的重要作用，也是做运维管理平台的第一步和以后每一步的重要依据。一定要舍得投入时间、人力等来建立起完整、准确、实时的基础数据。打好地基，以后运维的每一步都将有条不紊地循序渐进，终将建设成属于运维的高楼大厦。

④ 什么是JAVA开发环境，测试环境及生产环境，及它的过程

1、开发环境
顾名思义，开发同学开发时使用的环境，每位开发同学在自己的dev分支上干活，提测前或者开发到一定程度，各位同学会合并代码，进行联调。
2、测试环境
也就是我们测试同学干活的环境啦，一般会由测试同学自己来部署，然后在此环境进行测试。bug修复后，需要发版更新测试环境来回归bug。
3、回归环境
回归bug的环境，其实就是我们的测试环境，在测试环境上测试、回归验证bug。
4、预发布环境
测试环境到生产环境的过渡。测试环境可能会受到一些限制，一些流程或者数据没有测试到，就可以在预发布环境进行验证，从而保证产品上线质量。
预发布环境和生产环境区别：
1）预发环境中新功能为最新代码，其他功能代码和生产环境一致。
2）预发环境和生产环境的访问域名不同。
注意事项：
1）预发布环境一般会连接生产环境的数据库，测试时要注意，以免产生脏数据，影响生产环境的使用。
5、生产环境
即线上环境，用户使用的环境。由特定人员来维护，一般人没有权限去修改。
另外，还有个灰度发布，发生在预发布环境之后，生产环境之前。
生产环境一般会部署在多台机器上，以防某台机器出现故障，这样其他机器可以继续运行，不影响用户使用。灰度发布会发布到其中的几台机器上，验证新功能是否正常。如果失败，只需回滚这几台机器即可。

⑤ 四步教你如何完善企业数据库安全政策

随着日益复杂的攻击和不断上升的内部数据盗窃，数据库安全成为企业信息安全团队重点关注的焦点，超越了传统的认证、授权和访问控制。一个私人数据入侵，如信用卡号或财务数据，可以给机构造成巨大的损失，更不用说诉讼和违规罚款等可能会带来的持久影响。Forrester研究公司建议机构重新制定它们的数据库安全策略，在新安全特性的应用和功能上寻找差距，这有助于帮助数据库应对新的威胁。
1、建立一个集身份验证、授权、访问控制、发现、分类，以及补丁管理于一体的坚实基础
了解哪些数据库包含敏感数据是数据库安全战略的基本要求。企业应对所有的数据库采取一个全面的库存管理，包括生产和非生产的，并且遵循相同的安全政策给它们划分类别。所有的数据库，尤其是那些存有私人数据的数据库，应该有强的认证、授权和访问控制，即使应用层已经完成了认证和授权。缺乏这些坚实基础会削弱审计、监察和加密等其他的安全措施。
此外，如果不能每季度给所有的关键数据库打补丁，那么至少半年一次，以消除已知的漏洞。使用滚动补丁或从数据库管理系统(DBMS)的供应商和其他厂商那里收集信息，以尽量减少应用补丁的停机时间。始终在测试环境下测试安全补丁，定期运行测试脚本，以确保修补程序不影响应用程序的功能或性能。
2、使用具有数据屏蔽、加密和变更管理等功能的预防措施
在建立了一个坚实和基本的数据库安全策略后，就应该开始采取预防措施，以保护重要的数据库。这样就为生产和非生产数据库提供了一个保护层。数据隐私不随着生产系统而停止，它也需要扩展到非生产环境，包括测试、开发、质量保证(QA)、分阶段和训练，基本上所有的私有数据都可以驻留。数据库安全专业人士应该评估在测试环境中或外包应用开发中用数据屏蔽和测试数据生成来保护私有数据的效果。
使用网络加密以防止数据暴露给在监听网络流量或数据静止加密的窥视者(他们关注存储在数据库中的数据)。当数据针对不同的威胁，这些加密方法可以实现相互独立。通常情况下，也不会对应用程序的功能有影响。
保护关键数据库的结构要按照标准化的变更管理程序来进行。在过去，对生产环境中的计划或其它数据库进行变更时需要关闭数据库，但新版本的数据库管理系统允许在联机时进行这些更改，这就带来了新的安全风险。一个标准化的变更管理程序能确保只有管理员在得到管理部门批准后才能改变生产数据库并且跟踪所有数据库的变更。机构还应该更新自己的备份和可行性计划，以处理数据或元数据因这些变更而发生的改变。
3、建立具有审计、监测和漏洞评估功能的数据库入侵检测系统
当重要数据发生意外变化或者检测到可疑数据时，有必要进行一个快速的调查来查看发生了什么事情。数据库里的数据和元数据可以被访问、更改甚至是删除，而且这些都可以在几秒钟的时间内完成。通过数据库审计，我们能够发现是谁改变了数据和这些数据是什么时候被改变的等问题。为了支持之前提到的管理条例标准，安全和风险管理的专业人士应该追踪私人数据的所有访问途径和变化情况，这些私人数据包括：信用卡卡号、社会安全卡卡号以及重要的数据库的名称和地址等信息。如果私人数据在没有授权的情况下被更改或者被访问，机构应该追究负责人的责任。最后，可以使用漏洞评估报告来确定数据库的安全空白地带，诸如弱效密码、过多的优先访问权、增加数据库管理员以及安全群组监测。
4、牢记安全政策、安全标准、角色分离和可用性
数据库安全策略不仅关注审计和监测，它也是一个端到端的过程，致力于减少风险、达到管理条例的要求以及防御来自内部和外部的各种攻击。数据库安全需要把注意力更多地放在填补安全空白、与其他安全政策协作以及使安全方式正式化上。在草拟你的安全策略时，要使你的数据库安全政策与信息安全政策一致;要注意行业安全标准;要强调角色分离;要清楚描述出数据恢复和数据使用的步骤。

⑥ mysql 开发环境上生产环境后数据库变化，有什么好策略呢

打补丁。代码修改表结构，扫描全表，为新字段赋值