高效运维--数据库坐而论道活动
时间：2021-07-01 10:21:17
帮助过：6人阅读
但是关键就是形成规模和效益，有时候一些“自动化”系统反而是降低效率的罪魁祸首，就如同有些流程其实并不能让事情“顺”起来一样。其实最关键的就在于分析目前最浪费人力，最机械的劳动是什么，然后集中解决No.1问题，每次如此，慢慢的就会形成效益了。个人虽然不反对做整体规划，但是也不建议什么都设计好了在开工，很多时候等都设计好了的时候需求已经变化了，互联网公司即时是内部项目页可以秉承快速试错的思路，慢慢的形成自己的体系。
而现在流行的DevOps，我个人认为这并不是一种职位，而是一种思路，可以应用到各个领域，和DBA并不冲突，而且我个人一向认为，运维的自动化系统一定要一线运维的人参与设计和开发，因为作为需求提出者和使用者最清楚想要解决什么样子的问题，而且，在系统出现问题和变化的时候，由于是直接利益关联方，不会出现“排期”“优先级”等问题，便于快速的对系统进行修正。
最后一个问题由于我个人离着CTO还有九九八十一难那么远，实在不知道怎么回答，但是从我个人同一些高level的技术人接触来说，并不都是技术上的“完人”，更多的感觉反而是比较容易沟通，视野很大，方向感很强，所以个人以为沟通能力，大局观，情商，坚韧的性格，这些软实例应该反而更重要一些。至于技术，用技术人常说的一句话来说就是“技术上的问题都不是问题”最后都能解决，因为大部分情况下，都没用到需要拼天赋，拼智商的情况，只要足够努力就可以了。
5、在云数据库运维中，往往是数据库研发团队主导了性能优化和特性开发，DBA的传统职能被削弱，DBA未来的方向该如何选择？如何体现专业深度？
现在的云越来越接地气，由于云平台的不断完善，确实DBA的一些日常工作已经被machina取代了，从某个角度来说，这确实意味着DBA的传统生存空间在缩小。但是，达尔文的物竞天择，适者生存的理论在任何时代任何场景下都是适用的，既然现在云是一个无法改变的大趋势，那么就只能顺势而为，任何妄图螳臂当车，改变历史车轮前进的行为都不会有一个好的结果。所以我们需要做的事情就是寻找新的生存立足点，重新定义DBA的解释。
对于DBA的未来方向，传统的运维DBA的地位肯定会被各种RDS弱化，所以发展方向无非有三种：
- 往前，贴近业务
- 往后，贴近源码
- 转身，变成云DBA
分开说一下，转身比较好理解，RDS在万能也是需要有人开发和维护的，而这就是机会，只不过云DBA需要掌握更多的开发技巧以及面对非常多元化的问题（毕竟是面向整个社会提供服务了，不只是自家的业务），这种改变对于DBA来说相对少一些，也容易一些，但是这依托于公司，如果你不是云公司的DBA，那。。。我不是要忽悠你跳槽。
往后，贴近源码，大部分公司都是使用开源的数据库，开源软件的好处就是大家都可以用社区很活跃，缺点就是太过于重视通用性，并不见得契合各家自己的业务场景，这时候就需要系统开发类的DBA了，针对实际的场景和问题去对应的进行源码修改。只不过这种改变，对于DBA的技术能力，尤其是编程能力要求很高，且如果没有一个好的环境和导师，比较难入门，成功的几率相对小一些。
最后就是往前贴近业务，这也是我个人认为大部分DBA比较好的一个转变，目前据我个人了解大部分DBA往往都是在业务的后期才会接到需求，并且这些需求都是较为明确的，比如用什么软件，建几个表，每个表什么结构。而我个人认为目前数据库领域算是百花争鸣，这种各种的数据库层出不从，每种数据库都会有各自擅长的领域，并不是所有业务都放在MySQL就慢，也并不是所有业务都堆在Redis上就能快的，肯定有最适合业务场景的存储选型方案，而这就是DBA的机遇。相对于开发人员来说，我们DBA应该更加了解各个存储方案的优缺点和适用场景，更应该在项目之初就参与到项目的设计中，去掌控存储选型的发言权，从cache到db，给出较优的架构设计方案，甚至是库表结构的设计。
而向业务层靠近我认为也是体现DBA专业深度的一个方面，并不是一定要show一下数据库的源码或者path，个人认为只有设计一套存储方案，保障高可用，高性能，可扩展，低成本，业务意外的突增之后，我们还能将服务水平维持在一个较高的水位，且不用我们投入太多的精力，这才能体现我们的专业性。
最后，在说一下研发团队占主导地位这个事情，虽然现在社会已经不是像武侠小说中那样，谁拳头大就听谁的。但是在技术这个圈子里面，依然还是谁能解决问题，谁就会更加的有影响力，从这个角度说，研发团队占主导地位是一个无法规避的现象，毕竟很多问题只能通过path等方法解决，但是个人认为没有必要去想着解决这个问题，条条大路通罗马，如果是作为运维团队，应该和研发团队有机的组成一个整体，互相利用对方的优势解决问题，毕竟是焦不离孟孟不离焦的事情，缺了谁都玩不下去。
高效运维--数据库坐而论道活动
标签：
