去年年底的时候，我尤其焦虑，因为圈子的缘故，我能感受到行业里的变化和趋势，所以所想和所做不能匹配的时候，焦虑难免产生。当然我们要做减法和解法。
于是这样一个分享。【万字箴言】技术焦虑的减法与解法
开年的时候我又开始做了一个新年规划的分享。
远离温水煮青蛙，新的一年做个有规划的技术人！(有彩蛋）
半年过去了，也算有了一些结果，虽然和预想的还是有差距，多多少少算是迈出几步。
以前的DBA团队很多隶属于运维部门，当然这个不是重点，而在于工作内容，在早些时候，其实我们的大量工作都是被一些事务性操作所束缚，这种束缚你想使劲摆脱这种状况，但是反而被这些琐事越缠越紧。
从我的理解里，早期的DBA的工作内容基本是分为三个方向，占用的比例大体如下。
第一部分是运维管理，比如基础的安装部署，搭建从库，数据库权限开通，系统权限开通，备份恢复，监控等，都是基础运维的范畴。
而对于一些表结构的变更，SQL审核和数据迁移类的操作大都属于运维管理类的操作。
随着业务的增长，后面的部分的比例会越来越多，越来越频繁，在这个变化的过程中，势必会引发其他模块的联动变化，比如运维开发的模块。
数据库架构和优化是一个比较大的方向，在以前的工作中，相对来说优化的空间更大，但是很多优化的策略其实更多是添加索引，查看慢日志等，很多问题都是在发生了之后才能排查，问题的解决是被动式的。至于架构，其实也是随着业务需求的变化，逐步才能对已有的架构进行完善，否则对于很多情况来说，我们默认的一主一从，或者一主多从就基本够用了，随着需求的变化和对于数据库业务服务的重视程度，架构的变化是为了更好的适应业务。
最后是运维开发，运维开发我把它分为两个大类，第一个大类是一些应用的开发，比如运维自动化系统的开发，而在早期更多是脚本的开发，第二大类分为两个子类，一个是系统/应用组件的开发，而另外一个则是内核级别的开发。系统/应用组件比如数据库中间件的开发或者定制就是一种，智能运维模块的开发也是一类，而第二个子类，内核级别的开发则不具有普遍性，因为一方面你即使开发修改了代码，但是后续的维护怎么去做，如果更加平滑这是一个问题，另外一个，对于内核的定制和改动，需要对数据库方向有着很深入的理解或者有绝对的技术权威性，否则尽管写出来了推广也会很难。
从我的理解来看，他们所占的比例在早期是一种很不平衡的状态，大体是6:3:1
而在我的理解中，事务性的工作的意义其实更在于我们可以做的更快，做得更又效率。
但是后期运维开发和架构优化的工作会越来越多，这个比例会有很大的变动，基本的比例我理解会是2:4:4
当然我也看了一些行业里的数据，这个和我的理解基本吻合，这个是一个互联网公司在使用自动化之前和之后团队工作方向的一些比例变化。
其实可以看到在运维价值提升以后，可以有更多的时间去做更有价值的事情了。
虽然不至于是喝咖啡看报纸的地步，但是我们所做的工作技术含量会提高，也所谓行业里的水涨船高，不进则退。
现在已经到了一种近乎白热化的状态，但是行业里的发展现状也是层次不齐，不是说不重要，而是你是否顺应了时代的发展。
