运维管理
因为各个公司具体情况不同，我接下来就简单介绍一下我司关于运维管理的一些做法，给大家做个参考。
变更管理
相对来说，我们公司的变更管理比较严格，后续可能会更加严格。
变更管控
对于变更管控，比如在白天严禁做任何变更，工作时间内任何变更都不能做，即便是一些紧急或故障的修复，也是需要通过部门负责人确认、领导同意后才可以做的，确保风险可控。
变更流程
可能每个公司都有变更流程，但我们公司有一个比较特殊的地方。因为一些兼容数据库的要求可能会高一些，流程管控的每个部分都要确保到位。
变更方案
我们的变更方案是每个人要提前去做评审和验证，包括制定方案的同事和实施操作的同事，就需要变更实施人员提前在一个环境下做完整的验证，确保每个步骤都是验证通过的。
规范管理
架构规范
我自己之前在做架构师时，制定各种各样的规范是一项重点的工作。可能是养成习惯了，现在也和大家一起制定各式各样的运维规范。
但我自己感受最深的是：规范一定要有统一的标准，如果做不到统一就有可能会在后续产生问题。
比如我们之前有些开发测试环境不是那么规范，现在想改造做自动化时，发现根本就做不起来，因为每个库的情况不一样，自动化的脚本不可能适应所有情况来做这种标准化的改造。
把它弄成不标准是很简单的，但要想把不标准的改成标准的，难度就大了，尤其是在我们已经形成习惯之后。
运维规范
在 2014 年前，我们做的是纯 Oracle 数据库的运维，因为之前建立的是一个传统的金融企业，运维的都是 Oracle 数据库，但 2014 年后我们逐步转向了互联网金融。
因此我们陆续研究了 MySQL、PG、Redis、MongDB、SQL Server、HBase 等 7、8 种数据库，在运维过程中遇的坑就会比较多。
最初有很多标准，但没有一个是最佳的实践，很多也是根据业界、自己的经验制定出来的；还有各种不同的数据库里，不同的团队制定了不同标准，最后就有各种各样的标准了。
所以我们在运维中会发现各种各样的问题，最后要强制去做这方面的规范整改。
而且，之前的标准大部分都没有经过大规模使用和大规模负载的验证，很多标准并不那么统一、规范和有效。
因此，我们在运维过程中对于这种规范，还是在不断地去优化和改进，毕竟很多情况在没有遇到时，你真的是没有办法去解决这个问题。
规范优化
举个例子，最初我们并没有规定 Redis 一定要和应用放在同一个网络区域，但随着 Redis 的负载增加，我们发现防火墙已经承受不了。
当时平安的 WiFi 刚上线不久，但关于 Redis 的访问，几个实例每秒都有高达上万次调用，整个防火墙都撑不住了，还差点导致一个比较严重的故障。
在解决这个问题后，我们就制定了一条强制的规范：Redis 这种高并发访问的数据库，一定要和应用放在一起，不能有出现跨墙访问的情况。
所以这个规范也是不断去优化的，包括我们运维的一些标准。因为在最初创建标准时，我们可能会因为使用时间不长而考虑不到一些问题。
我印象比较深刻的是 MySQL 刚引入时的一个问题，对于软件的版本没有明确到小版本。
后来甚至出现有 MySQL 停库时是 5.6.22 的版本，在维护完成后就被启动成 5.6.16 的版本。
最后是通过不断地优化来确保我们的规范和实际是相结合的，避免这种问题的发生。
人员发展
团队意识
关于团队这块，需要提升每个人在团队中的作用，需要确保团队里的每个人都是有备份的。如果发展成离开谁都不行，那对团队的整体发展来说是不正常的。
所以我们在安排工作时，对于比较重要的工作，我会尽量不让熟悉的同事重复去做，而是尽量让一些不熟悉的同事参与去做。
之前每走一个资深成员，都会明显感觉到团队的整体技能或知识少了一块。为了避免类似问题的发生，从 2017 年开始我们就制定了一些策略，让大家做知识技能的分享，每周抽取两个下午，每个下午抽取一到两个小时做分享。
另一个策略是技能的积累，即把我们在工作中遇到和解决的一些问题都录入问题管理系统。
这样做有两个好处：
可以把重复的问题记录下来，因为我们想要去分析哪些问题是重复发生的、哪些是有共性的，就需要有一个这样的系统去拉对应的问题清单，最后去解决问题。
即便人员流失了，他们之前解决的一些问题和技能也能让团队其他人发现，不至于每走一个人就留下一个坑。
所以我们是通过这种手段来尽量避免人员流失或变动给团队带来的一些问题。
但说到底，这种事这是没办法完全避免的，因为数据库运维有一定的复杂度，需要依靠不断地发生故障、解决故障，包括一些人为失误来提升。
权责分明
我们的轮班人员是 7×24 小时，即上三班的方式来轮班的。之前团队有一个比较严重的问题，当一件事情发生了，轮班人员有可能将问题交接给下一班次；或是升级给其他人后，就觉得与自己没有关系了。
还有就是风险意识不强，有一些操作没有评估过影响就开始在生产库里操作。
当时我们也发生了不少问题，后来在内部重点提升两点意识：责任人意识和风险意识。
首先你需要在生产做措施前，确保要做的操作会有什么影响、导致什么后果，不能在做完后才去想这个问题：比如说我们现在每天变更，都需要提前把脚本和手册做好，让值班人员熟悉。
操作会有什么后果？后续有什么异常会发生？应对方法又是什么？……这些都是需要提前评估好的。
技能提升
关于技能提升，虽然必要的培训是必不可少的，但我们认为关键还是要靠自己的学习、理解和在实践中的积累，并没有什么好的捷径去实现，大多时候还是要通过不断地解决问题、发现问题甚至包括犯错的代价来提升的。