2017年度工作总结和计划

                                      系统运维部 DBA&DA

2017年似乎比以往过的更快，回顾整个年度，似乎也平淡无奇，非要说一点特别事情可能就以下几点：

1） 行业平台数据库节点重启事宜

2） 核心数据库系统两次停机维护

3） 数据查询系统上线&问题处理

4） 数据库问题SQL优化工作开始

5） 数据库团队介入数据架构工作

首先来看看第一部分，行业平台数据库节点重启的问题。鉴于行业平台系统高可用性的考虑，DBA搭建了行业平台RAC DB，由于当初选择操作系统是RHEL6.3，这个版本其实不是太理想，因为无法使用Oracle自带的ASMLIB软件，同时Oracle10g数据库对于RHEL6系列支持也不是很好[其中原因是新的服务器硬件不再支持旧版操作系统]，但是经过DBA努力，可以说是强制安装上去，之后经过多次测试后，没有发现问题，然后择机将行业平台从单实例数据库迁移RAC DB。

行业平台迁移到RAC DB之后大约几个月后，先后出现了6次RAC DB节点每隔2-3个月交替重启或者hung的现象。经过DBA多次从数据库，服务器，网络角度深入分析，我们大致定位到一些问题，后来又联系外面服务商诊断，他们分析的结果和我们基本一致。

后续，就是重新搭建基于RHEL6.5操作系统同时私有网络使用交换机通信的Oracle10g RAC DB，行业平台数据库切换，搭建GGS容灾，再搭建基于RHEL6.5操作系统的RAC DB，再搭建GGS容灾。

到目前为止，行业平台数据库系统已经运行整整2个月，暂时还没有发生之前出现的问题，还需要观察2-3个月时间，才能确定最终的真正原因。当然，这个问题也是从业以来遇到处理最久的问题。之所以这么久，原因众多，可能与相关每个人的技术与执行力有一定关系。

其次来看看第二部分，核心数据库两次计划停机维护。这是IPX停机维护最多的一年，从停机维护过程来看，基本都是按照计划按时进行，似乎也没有出现什么大事：

http://s6/mw690/001pA04Gzy7gXpC9YNf95&690

但是，从维护的内容来看，我们发现两次停机维护基本都是在给应用程序建立分区表。一个表是否需要建立分区表，应该在系统设计时就确定的事情，而不是运维阶段，这是软件工程。系统开发前期需要的工作没有做好，就可能给后期系统性能带来很大的影响，同时也给运维就会带来很麻烦。比如，第二次停机维护，唯一工作内容就是建立分区表，从实际建立分区表过程来看，由于数据量巨大对我们数据库，服务器，容灾系统都是一次很大的冲击，后续DBA又花了三天才全部解决。

   我们都知道有句俗语：“打江山容易，守江山难”。软件开发遵从就是软件工程学，如果你仅仅想赶进度，要软件交期，不要质量和成本，投机偷懒，那后续的工作就会加倍，不论在产品运维还是系统运维。如果可以，我们在“打江山”的地方更加努力才行。

再次来看看第三部分，IPX数据查询系统上线。这件事情，对于IPX来说算是一种进步，尽管在别的公司来说，是个基本工作范畴。进步就是进步，但是后续发生的事情，彰显了一直存在的问题，开发和运维的脱节。查询系统上线即不可使用，经过多次努力解决，最后和开发配合给出了临时解决方案，之后总结如下：

http://s13/mw690/001pA04Gzy7gXpDH0csbc&690

通过这次查询系统的问题，我们可能至少两方面需要改善：1）某些系统设计阶段需要运维参与；2）我们运维人员有时要坚持一些运维原则和底线，不要为了完成任务一味朝着不合理的方向努力，否则真变成“干活”的了。

再次来看看第四部分，数据库问题SQL优化工作开始。这绝对算是一种进步，奢望的进步，尽管在别的公司是最基本的工作。DBA每月给出的问题SQL语句竟然没有人优化，现在听来也是一件不可思议的事情。公司建立18年，IT阶段仍然处于创业公司的阶段，仍然是小作坊的模式，什么问题都可能出现，什么问题都可以理解。知道没有人改善，还一味去做，这是毅力，精神可嘉。终于开始优化了，所以算一种进步。但是，离做好还有很大差距，DBA这边还要继续努力，不仅按时分析并发出问题SQL，还要规范SQL优化流程，不要让优化变成应付的工作。

最后来看看第五部分，运维参与数据架构工作。了解数据架构之后，我们发现其是对运维工作的扩展，特别是对DB管理工作的扩展，让你有机会将开发前期的工作和运维的工作相结合，实现前后统一管理。通过数据架构的职责，我们还会发现凡是与数据有关的，都需要数据架构参与，包括上面第二部分/第三部分涉及到工作。数据架构早于运维，早于开发，系统最开始的时候就参与其中，这样结合运维的经验，我们就可能解决目前公司遇到的一些问题和潜在的问题。当然，想做好数据架构，最基本需要了解企业架构理论，数据架构理论，它是一套成熟的理论，需要相关人员进一步的研究，然后提升对数据架构的整体认识，只有这样才可能把架构工作做好，否则只做架构很少部分工作，虚有其名，对公司没有实质帮助。

如果说数据查询系统算是一种进步，SQL开始优化算是一种进步，那么运维参与数据架构就算第三种进步。

除了上述可能算是特别工作之外，还要需要特别提醒一下是我们部门的文档标准化工作。2017年文档标准化工作算是平稳的一年，没有改善和创新，但是各位同仁仍然在及时地更新我们的资产和文档，这点算是值得赞扬的。唯一不足是之前的Troubleshooting问题除了DBA之外，其他人员依旧没有改善。 运维不是干活，所有的工作都不是干活，我们都要有分享，有沟通，有产出，都要对公司负责，因为公司给你工作机会，给你发工资。你来了，你走了，必须给公司留下些什么。

当然，整个2017年工作，不仅仅只是以上部分，还有很多，在此不再一一列出。那么，针对即将到来的2018年，大致工作计划总结一下：

最后，对于IT行业，很多人都是安于现状，推一步走一步，这似乎不是很好的工作态度，毕竟成长与进步才是永恒主题。不论你是底层基本员工，还是中低层管理人员，甚至包括高层，一样都需要每年的进步与提升。世界变化太快，你随时可能被淘汰。