DBA 的两条主线
数据存储与操作包括数据库操作支持和数据库技术支持。前者关注数据生命周期中的运行活动：环境搭建、获取、备份、恢复到处置，以及性能保障；后者关注技术选型、架构、安装、升级和疑难问题。DBA 是这两个方面的核心角色，但不是唯一角色。
- 三项目标：全生命周期管理数据可用性、确保数据完整性、管理事务性能
- 五条原则：识别自动化机会、构建时考虑重用、合理使用最佳实践、明确 SLA、项目早期就让 DBA 参与
- 角色分工：生产 DBA、应用程序 DBA、过程/开发 DBA、网络存储管理员（NSA）
- 数据管理专员、架构师、网络与安全分析师也参与性能、保留与恢复规划
数据库架构与一致性取舍
集中式把所有数据放在一套系统中，管理简单但存在单点风险；分布式通过多节点横向扩展，用软件复制与故障检测提供整体可用性；联邦数据库不复制数据，而是把多个自治数据库映射成一个逻辑整体；区块链以哈希链保证交易不可篡改；云平台则提供虚拟机镜像、数据库即服务（DaaS）和托管数据库等形态。
| 架构 | 特点 | 适用场景 |
|---|---|---|
| 集中式 | 单一系统、统一管理 | 访问受限、强一致、规模可控 |
| 分布式 | 多节点横向扩展、自动故障处理 | 大规模、高并发、海量数据 |
| 联邦式 | 保留本地自治，映射为统一视图 | 异构系统集成、主数据、虚拟化访问 |
| 区块链 | 区块哈希链、不可篡改 | 交易存证、合同、健康信息交换 |
| 云 / 虚拟化 | 虚拟机镜像、DaaS、托管数据库 | 弹性伸缩、降低运维负担 |
松耦合联邦由各组件提供联邦模式；紧耦合联邦由独立进程发布统一模式，不复制数据。
| 概念 | 核心主张 | 典型场景 |
|---|---|---|
| ACID | 原子性、一致性、隔离性、持久性 | 关系型 OLTP、金融交易 |
| BASE | 基本可用、软状态、最终一致 | 大规模互联网、社交媒体、大数据 |
| CAP | 一致性、可用性、分区容错最多同时满足两项 | 分布式系统设计取舍 |
CAP 不是让你放弃一项，而是提示在分区发生时必须在一致性与可用性之间做选择。
选择与评估数据库技术
DBMS 选型会影响数据集成、应用性能和业务产能。评估既要看技术指标，也要看组织与供应商因素。全面投产前，先用小规模试点或概念验证（POC）验证成本与收益。
- 没有一种数据库架构能同时满足所有需求；多数组织会同时运行多种数据库
- 缺少事务能力的数据库不适合零售 POS 等要求强一致的场景
- 培训与交叉培训要纳入预算，尤其是支持敏捷开发时
- 技术管理可借鉴 ITIL 的过程模型：事件、问题、变更、配置管理
| 维度 | 关注点 |
|---|---|
| 技术 | 架构与复杂度、容量与速度、事务/分析类型、特殊功能、平台支持、扩展性、韧性 |
| 工具 | 监控、备份、调优、开发支持工具是否成熟 |
| 成本 | 许可、维护、计算与存储资源、总拥有成本（TCO） |
| 组织 | 风险偏好、人才储备、供应商声誉与支持策略、客户案例 |
日常运营：容量、备份、性能与变更
运营的核心是把「不可用」和「数据丢失」的概率降到可接受水平。容量要提前规划，备份要能恢复，性能要用 SLA 约束，变更要可回退。任何一项缺失，都会在事故中放大。
- 理解需求：估算首年容量与未来增长（含索引、日志、镜像），识别使用高峰与访问要求
- 规划业务连续性：按数据库重要性排序恢复优先级，制定并演练恢复计划
- 备份：按 SLA 约定频率，全量 + 增量 + 事务日志，异地保存，定期做恢复测试
- 创建与配置环境：开发、测试、UAT、预生产、生产等多环境，配置审计与访问控制
- 管理性能：设定 SLA，监控可用性与响应时间，定位慢查询、不良代码、资源争用与过载
- 变更管理：所有变更脚本化、先在低阶环境验证、经审批后实施，并准备回退方案
治理与度量
存储治理包括度量、信息资产跟踪、数据审计与有效性验证。度量不是为了好看，而是为了发现趋势、支撑容量与 SLA 决策。许可与合同也要纳入治理，否则会带来财务与法律风险。
- 定期审计许可、支持费用与租赁协议，评估过时、过保或昂贵的技术
- 数据审计检查存储是否符合合同与方法要求；数据验证检查质量与可用性
- 变更要可记录、可审计、可回退；生产变更与模型变更应建立关联
| 类别 | 指标示例 |
|---|---|
| 存储 | 数据库类型与数量、容量、已用存储、存储容器数量、队列长度 |
| 性能 | 事务频率与数量、查询性能、API 服务性能 |
| 操作 | 数据检索时间、备份大小、数据质量评估、可用性 |
| 服务 | 问题提交/解决/升级数量、平均解决时间、SLA 达成率 |
指标应与数据架构师、数据质量团队共同确定，避免只由运维视角定义。