dba工作总结(7篇)思维导图

刚入职场的时候，我的年终述职报告写了很多有关自己熬夜多少次，连续工作多少天，解决了什么东西之类的。又或者是堆砌了自己负责的摊子有多大，管着多少核心数据库。

直到有一次，我的直属领导和我说，别写这些了，在咱们运维团队每个人东西都不少，也都不轻松，说点有用的东西吧。

我这才意识到，这件事情其实在上司面前没什么太大意义。每个人多少工作量，负责的事情有多辛苦，其实在部门一把手面前没有我们想象的那么有说服力。从领导视角去看下属，每个人各司其职，工作量做的多和升职加薪并没有必然联系。而且有时候甚至会怀疑，这人是不是能力有限，是不是工作方式有问题，怎么忙成这样，还是他有什么别的问题？

DBA的怪圈，工作做得好，计划前置，井然有序，不出问题——存在感低。工作做的差，事故频出，别人投诉，问题多多——频繁挨批。这就导致了很多DBA非常急于在述职报告里去体现自己做了很多东西。可是从领导的眼里，这些都只是必备的工作内容，看完这份述职报告，可能内心毫无波澜。

对实验过程中用到的软件、实现技术的评价以及对于实验过程遇到的一些问题做的总结：

在第一阶段：

在实验验演示给老师看的时候，自我感觉做的挺好，能得到老师的好评和赞许，没想到的是老师看完我们的演示后提出的一系列问题让我们一时目瞪口呆。听了老师的讲解后才发现我们做的系统根本就是个废品，没有任何一家厂商愿意用我们的东西，即使免费相赠。和现实中的《餐饮管理系统》相比，我们的系统最大的不足体现在安全性方面，主要表现为以下两个方面：

运维部门永远是花钱的部门。一年多少钱，怎么花出去，都是很敏感的事情。在你描述自己今年运维的服务器多了多少的时候，可能领导想的不是你工作价值更多了，而是他要去找他的上司要的预算更多了。

因此，成本这件事情是述职报告里必须要提及的。例如今年你做了多少优化，累计为公司节省了多少厂商人天，避免了多少新硬件的采购，预估一个金额放在报告里。同时下线了多少旧设备，减少了运维成本开销，也是可以写进去的。

可能会有DBA问，我们今年就是业务扩张了很多，增长了很多设备，这事该怎么写？同一件事可能有不同的角度，可以尝试着从用更少的钱做更多的事这件事情上着手。例如今年数据库规模扩张了20%，而你动用了自己的智慧，成本只增长了10%。这种可以量化的东西是可以直接写进去的。

对于那些可以直接赚钱的系统，自己做了什么，直接或者间接为公司带来了那些收益，这些如果有更是加分项。你的领导甚至可以把这些写入他们的述职报告里，这也是IT部门向业务部门展示自己能力的关键点。

很多的时候，我们去描述自己做了什么，经常对于事情的结果不够准确，或者说，没有量化。

比如我曾经在某一年说过，自己这一年做了三次灾备演练，都成功完成。但是在领导提问的时候，他问我，用了多长时间，大概会影响多少业务量的时候，我却卡壳了。事后我反思，应该加上的最重要的东西，我却忽略了。领导更关心的是，每次灾备演练要用多长时间，根据TPS大概要影响多少业务订单，从而他要评估大概给业务部门带来的预期损失是多少。然而我对这些居然完全没想到。

从那之后，我开始关注每一份报告所关联的量化结果。备份恢复测试，最快恢复时间是多久，最长恢复时间是多久，再去询问业务部门相关同事，大概会影响多少业务量，并且写进相关报告里。性能优化，不再执着于某条单独的SQL语句，而是将整体的业务场景作为案例，可以为业务部门带来什么样的变化，业务效率提高了比分之多少，节省了多少成本等等。

一、项目进度情况

二、隐患和故障处理

三、数据库监控与优化

四、明年的打算

凡事有因有果，去年的什么什么事情，今年是怎么解决的。今年存在的问题，来年打算怎么办。这些都可以写进去。

平时我们在处理运维工单的时候，有的DBA只是单纯把状态填上，有的会把一些工作要点记录在上面，为什么发生、根因在哪，如何解决，有的甚至会给业务部门提供解决建议。这些东西我建议在时间允许的情况下尽量详细，为自己的年终述职留下足够多的素材。在述职报告的时候，就可以把今年的不足写上，加上改进方式以及预期结果。

比如我在第一年写，自己对业务了解不多，需要再来年加强这方面的学习和工作。第二年就写上，自己通过学习，加强了某某业务的了解，从而为数据库做了哪些工作，取得了什么可以量化的结果，为公司带来多少收益。形成一套组合拳，看似是去年给自己挖坑，其实是在铺垫。

作为DBA，一年能够让上面的人倾听到自己的机会其实寥寥无几，有时候升职加薪就那么点机会。忙活了一年，如果没有得到实际的收益，我相信每个人都会不开心。述职报告可能是这一年最容易展示自己的时候。有限的篇幅、有限的时间，如何让自己对公司的价值和贡献得以充分展示，有时候真的需要一些技巧。打破固有的思维定式，主动去调整自己述职方式，很有必要。