数据安全

1.测试环境和生产环境应当处于不可互通的物理网络
互通就意味着同时可以访问，也就可能带来很多意想不到的安全风险，企业应当将测试环境和生产环境部署于不可互通，或者不可同时访问的网络环境中，避免因为错误连接而发生的数据库灾难。


2.对数据库的破坏性操作需要谨慎
在操作系统上的空间清理应当和数据库操作遵循同样的守则，即：在任何破坏性操作之前，应当进行反复确认并根据需要进行有效备份。
关于删除文件的一个良好习惯：以转移(MOVE)替代删除(DELETE/RM)，经过一段时间观察确保无影响后，再进行最终的文件移除。删除，这个简单的操作应当极为谨慎地对待。


3.数据环境运维必须遵守一定的安全守则
在数据环境的运维中，应当制定制度性的规范并严格执行。规范和制度会增加工作的复杂性，但也会极大地避免出现误操作的概念。无约束的技术自由，会带来无法预料的后果。良好的规范和制度，其良性输出是可以预期和预知的。


4.避免在疲劳或不清醒状态独自做出重要判断
很多故障的发生时机都是凌晨，在处置这些故障时，很多用户遇到了发生灾难。人在疲劳、熬夜或者睡梦中被叫起的半梦半醒状态下，所有的判断都可能考虑不周。所以，如同拒绝疲劳驾驶一样，应当拒绝疲劳运维，保持精神状态良好，或者至少避免在不清晰的状态下独自做出重要判断，必要时，至少获得一个额外的指导或确认。


5.重要维护应当详细检查系统各方面的安全与稳定性
在进行重要的维护操作时，应当详细检查相关资源的运行状况，确保系统当前状态的稳定稳固，确保新增加的设备、配件的健康安全，确保不要将问题引入到当前的系统中来。


6.复杂的维护需要选择停机窗口长的时段进行
即便有非常乐观的估计，在进行复杂维护时，也要尽量争取充足的停机窗口。因为隐藏的故障可能大大增加维护的复杂度，一个意外就可能导致几倍的时间 需求，所以对维护进行充足的时间考量，是我们重要的维护计划内容。


7.做好最坏的打算才能有最好的结局
通常很多工程师都会下意识地假设，进行操作系统级别维护或网络维护跟数据库无关，非常简单。但是注意，这种种因素都和数据库有关，任何一个环节出现问题都可能导致数据库故障。


8.任何业务数据库的操作都不能草率
在权限管理上，应当做到权限分离，作为业务维护人员不应当授予DBA权限，而DBA在进行非维护操作时，也无需以SUPERUSER角色进行登陆。


9.重要维护应当做好测试准备工作
在核心系统中的重要操作，应当提前做好测试工作，并且明确可能存在的故障点，并且准备回退方案。在重要的任务点上，设置两个角色，互为备份、补充和审核，避免出现误操作的概率。


10.任何关键性的修改应该两个人以上确认
任何人都有思维不清晰的时刻，而两个人同时犯一个低级错误的可能性就小得多。因此，建议执行关键操作或执行有潜在风险的操作之前，一定要找一个人同时确认脚本或命令，这样可以最大程度降低由于头脑一时不清所引发的灾难。如果身边没有熟悉数据库的人员，可以尝试将自己的步骤和操作讲给其他人听，如果你的步骤存在明显的错误，很可能在你讲解的过程中自己就发现了。


11.不要轻易的删除任何一个归档的日志
哪怕是在空间紧张的情况下，也不要轻易删除任何一个归档日志文件，压缩或者转移会是临时释放空间的办法。因为，归档日志对于数据库的恢复不可缺少。


12.事先定制明确的回退方案
我们主张在重要的变更之前，准备好回退方案，如果没有，那么至少在你进行无把握的操作前，想一想如果出现不可预期的情况，你应当如何回退。


13.制定方案并且按照方案的步骤执行
重要的维护工作应当制定方案，并且列出明确的操作步骤和命令。这些步骤和命令应当是通过测试验证的。

1.备份重于一切
在计算机系统中，通常存储是最为重要也是故障率最高的部分，硬盘总是会损坏的，数据也总是面对丢失的风险，唯一会让DBA们从梦中惊醒的就是：没有备份。


2.注意备份加密的重要性
如果不能保护备份和备份集，那么一旦发生丢失、泄露就可能导致严重的安全问题。


3.应当明确闪回机制的功能
在出现常规数据误操作如删除等问题时，可优先尝试使用闪回功能进行恢复，应当明确这一机制在异常当中的重要地位。


4.应进行备份有效性的检查和确认
很多用户在部署了数据备份手段之后就认为可以高枕无忧了，而很少去检验备份的有效性和完整性，一旦出现问题需要恢复，才发现备份无效，就很难挽回了。


5.在任何破坏性操作之前，必须严格验证备份的有效性
这里所说的破坏性操作包括删除数据文件、日志文件、数据表等，在执行这些操作之前必须严格验证备份的有效性。


6.在不可逆操作之前执行备份
在需要执行不可逆操作之前，执行备份，要确保可以回退到之前的状态，以便尝试恢复失败之后，别人还有机会从头开始，这也是保护现场的概念：在进行数据表的截断、删除之前，进行备份，将备份养成一种习惯，这样才能够避免误操作之后的措手不及。


7.在可能情况下保留多份备份介质
很多事实显示，有时候单纯一份备份是不可靠的，磁带、移动硬盘等介质的备份更不可靠。所以，如果可能，对于重要数据的备份，最好保留多份介质，尤其是要对原有环境进行破坏、迁移、重构等情况。
通常备份策略，还应结合物理备份和逻辑备份、表结构备份等来实施。对于极其重要的核心表，要保持经常性备份，多一份备份就多一份安全。


8.备库是非常有力是数据保障机制
如果环境许可，对生产环境构建一个 流复制 备库容灾环境，可以在危机关头挽救数据。

数据安全运维-监控规范
1.数据库需要全面的系统规划和监控
在很多案例中发现，缺乏监控是很多灾难的根源，最常见的是缺乏空间监控，直到归档路径空间使用率达到100%，出现错误影响了业务应用，客户才意识到数据库出现了问题。按照常规运维要求，系统应当部署必要的监控手段，在空间达到一定阈值时即报警，比如空间使用率达到80%。


2.加强数据环境的空间监控
很多用户是在空间达到100%之后才去匆忙进行空间清理，匆忙常常会带来考虑不周，误操作等意外发生。所以，建议加强数据环境的存储空间监控，不要等到100%再去应急，应当总是使空间留有余量，提前进行空间维护，避免手忙脚乱的应急处理。


3.维护操作中需要实现全局监控
在系统运维的过程中，要随时保持对于各级日志的监控，如果日志出现任何错误，都要获得及时的响应和处理，不要将错误隐藏拖延至维护之后。不要以为某个环节出现问题会仅仅是局部的，系统的关联性使得一个问题会在全局放大。


4.日志监控与检查是防范问题的根本
有了备份的保障，再加上日志监控与检查才能够让数据库高枕无忧。

1.通过别名或重定义提示或者禁用rm操作
或者制定一个规范，通过mv的方式进行文件转移，通过一定时间段（如一周）观察无误后，再彻底清楚数据文件。rm操作的危险性必须得到技术人员的充分重视。


2.通过触发器约束或禁用特定的DDL操作，防范数据库风险
对于truncate等高风险的数据库DDL操作，可以考虑通过触发器进行禁止，防止未授权的操作损害数据。


3.严格进行权限管理，以最小权限原则进行授权
过度授权即是为数据库埋下安全隐患，在进行用户授权时一定要遵循最小权限授予原则，避免因为过度授权而带来的安全风险。


4.以重命名代替删除操作
不论操作系统级别还是数据库级别的删除操作，尽量以重命名替代删除，如重命名数据表，重命名数据文件，然后通过一段时间的观察和确认后再彻底删除。


5.尽量争取充足的时间
不要低估任何一次简单的维护操作，因为一个意外就可能大幅延迟你的维护时间。所以，应当尽量争取充足的时间，包括做好充足的准备工作，加快无关紧要步骤的执行，减少不必要的时间消耗，时间越充裕，你用来应对可能出现的故障的时间就越多。


6.审核你的剪切板
很多错误是由于粘贴剪切板的内容引起的，所以，当你准备向一个窗口或者命令行粘贴你看不到的内容时，提高你的警惕性。在Windows下，有很多剪贴板增强工具，可以帮助我们记录和展示剪贴板的内容，可以考虑选用。审核你的剪贴板，确保其中的内容是你期望的。


7.没有认真看过的脚本就绝不要执行
对于DBA来说，如果一个脚本你从来没有认真读取了解过，就不要去执行，脚本中的一个错误就可能导致严重的数据灾难。我们遇到过案例，由于脚本中的一个变量错误，导致所有数据文件被删除，教训惨痛。如果实在无法审核脚本的内容，那么在进行重要操作之前，备份你的数据。


8.在执行任务之前确认连接访问的数据环境


9.避免打开过多的窗口以致操作错误
在执行任务时，保持尽量少的打开窗口，我经常见到工程师桌面打开众多凌乱的窗口，混乱与错误同行，尤其是在通宵加班等环境下。保持简洁清晰的工作界面，是一个工程师应当具备的基本素质。


10.避免匆忙之下进行重要的工作或决定
很多误操作都是因为急着下班，急着回家，临门一脚导致的失误，所以当我们去执行一项工作时，应当保持各种惨痛的案例持平和的心态，避免仓促紧急的决定。


11.测试环境和产品环境密码设置不能相同
有些测试环境或者非产品环境是利用产品环境复制得到的，DBA在建立了测试环境后，就没有修改数据库用户的登陆密码。经常性的，DBA也习惯在所有环境中设置通用的密码，这些习惯为系统带来很多风险和不确定性。


12.在高峰期禁止在数据库中进行DDL操作
DDL操作可能会导致阻塞/IO暴涨，如果系统繁忙，可能就此挂起，长时间影响系统正常运行。


13.慎重进行统计信息收集和索引创建等
统计信息收集和索引调整是优化数据库的常用手段，可是切记业务峰值期间的统计信息收集，或者收集之后导致不可预期的执行计划改变可能使数据库瞬间停滞。而贸然添加的索引，也有可能导致其他SQL执行计划恶化。


14.执行的操作系统命令需要经过测试
很多操作系统级别的命令都具有一定的危险性，如rm/mv/tar等，如果你不理解这些命令的具体含义和参数意义，那就可能犯下无法挽回的错误。


15.明确区分后台进程和用户进程
数据库的后台进程是维护数据库正常工作的必要进程，如果误操作杀掉重要的后台进程，则数据库可能立即崩溃，所以一定要注意区分后台进程和用户进程的区别。
对于终止进程的命令，要反复确认后再执行，并且注意，如果进程正在执行特定的操作，比如重建索引、truncate数据表等，意外中断可能导致严重的数据库内部错误。


16.尽量避免层层跳转的服务器登陆方式
虽然很多企业数据环境通常都要经过层层跳转才能够访问，但是不可避免的，跳转的次数增加也就增加了出错的可能性，所以应当尽量减少调整次数，禁止在一个主生产节点再跳转到另外的主生产节点。


17.完成操作后尽快退出生产业务服务器
当在生产服务器上完成工作后，应当尽快退出，以防止其他工作干扰后，因为疏忽而出现误操作。尤其当离开电脑前时，应当退出或锁定操作界面，防止他人误操作。


18.经常性确认服务器、数据库和路径标示
应当经常性确认主机名称、当前路径、数据库名称等信息，防止无意识的误操作。尤其是当重新或临时接触到操作终端时，如果不能明确看到服务器或数据库标示，则应当首先查看这些信息。
以下这些常见的命令行操作应当成为DBA的条件反射
.

1.不要采取贸然的尝试
当遇到数据库故障时，在得出清晰的分析结论和处理方法之前，不要贸然采取措施，草率的决策可能导致问题的复杂化，进而引发更加复杂的级联故障。
在数据库出现问题时，首先要保护现场，进行认真分析。


2.在完成技术分析之前不要草率进行恢复尝试
在面对灾难时，不要急于进行恢复尝试，首先应该在不改变、不破坏环境的情况，进行充分的技术分析，根据分析结果确定恢复方案，避免草率的尝试。当然，在进行实际操作之前，必须做好备份工作。再一次提示大家，无知者不能够无畏。


3.在出现问题时，不要急于做出第一个判断
最为初始的判断会决定后续恢复的走向，如果处置不当，则可能使问题恶化。如果是DBA个人的判断，很有可能走向草率的极端，错误叠加错误，所有当问题出现时，不要急于做第一个判断，除非具有十足的把握。依赖团队和专业人士，有时候可能一个电话就可以解决问题。