高效运维--数据库坐而论道活动

高效运维--数据库坐而论道活动

 

我我的对这5个答案的简单整理，详细内容请关注高效运维的微信公众号

 

一、如何看待DaaS（数据即服务）？DaaS有哪些要素构成？你认为目前实践较好的公司有哪些，为何？

 

你们对于耳熟能详的IaaS和PaaS都很是的了解和熟悉了，而且对于这2个名词的定义也不会有太多的分歧，可是对于DaaS有些人可能会解释为Data as a Service，也有些人会解释为Database as a Service，不过我想小军要问的确定是Data as a Service。

 

如何看待DaaS，网上一般的解释以下：“数据即服务是指与数据相关的任何服务都可以发生在一个集中化的位置，如聚合、数据质量管理、数据清洗等，而后再将数据提供给不一样的系统和用户，而无须再考虑这些数据来自于那些数据源。”我的认为DaaS应该相似一个海鲜超市，在这个超市中应该有各类各样的数据，好比金融、通信、用户行为、消费记录等等。而后用户会指定要那些数据，就如同将不一样的海鲜放到购物车中，最终将选定的这些海鲜拿到加工店根据用户的喜爱将这些海鲜（也就是数据）作成一桌子菜。

 

最终这一桌子菜才是用户真正想要的。而一个DaaS平台要能实现以上这些功能，那么就须要有以下几个要素

• 数据采集：一个超市总归是物品种类越多越好，因此数据种类也是越多越好
• 数据治理和标准化：不是全部数据都是好数据，因此要创建标准化便于准入和存储
• 数据聚合：这里会是最大的差别点，就如同一样的食材给不一样的大厨作会出来不一样的味道，因此差别化竞争应该在这里更多的体现。
• 数据服务展现：最后，展现环节就如同上菜，中国人对吃仍是讲究色香味的。

 

最后这个问题，我还真回答不上来，可是我认为较好的实践必定会出如今天生拥有数据的那些公司，好比BAT，华为，京东，美团等等，由于我的认为整套DaaS最难的地方就是最开始的地方，拥有足够多足够多样的数据才能保持领先优点。

 

 

二、关系型数据库如何应对云时代的弹性伸缩挑战？

 

随着docker等容器技术的普及，如今前端应用服务能够很是简单的就弹起来，可是关系型数据要想弹起来，或者在具体点说MySQL若是想要弹起来就不那么简单了。

 

首先咱们能够看下若是MySQL须要弹性伸缩都须要那些必要要素？

 

• 容量管理系统：咱们须要知道在何时须要伸，何时缩。
• 资源管理系统：咱们须要知道那些资源是可用的。
• 扩容迁移系统：自动完成数据的拷贝迁移和访问上线。

 

     以及和一些周边的好比监控、配管、安全审计等系统的联动。

 

     在这其中，最简单的就是扩容系统，由于这个彻底是标准化和流程化的，可是也是最难优化的，由于大部分时候迁移所需的时间都是由数据的容量决定，是最难节省下来的。

     其次，就是资源管理系统，只要作好信息采集并配合好资源隔离，那么在设定必定的规则就能够完成对资源的管理，以及推荐，也就解决了往哪里扩的问题。

     最后，最复杂的其实就是容量管理系统，想要准确的计算出在那个时间节点须要扩容或者缩容须要基于时间线的各类分析。最简单就是环比和同比，复杂的计算方法就各显神通了。

 

     最最后，我的认为相对于如今比较成熟的前端的弹性伸缩，数据库的弹性伸缩的目标不该该放在解决业务瞬时峰值上面，由于相对于前端来讲数据库的扩容所需的时间较长，极可能在扩容完毕以后峰值已通过去了。而数据库的弹性伸缩更大价值应该在对资源的充分利用上。

 

三、异地多数据中心的数据同步有几种方式，各有哪些优缺点，哪一类更适合互联网金融业务？传统数据库是否适应和知足了互联网金融业务的要求，还有哪些改进的地方？

 

     异地多数据中心其实作的最好是银行，惋惜银行貌似历来没有出来分享过。目前我记得在网络上有过度享的阿里的异地双活数据同步基础设施DRC，另外微博其实也实现了异地机房的双活。

     对于异地的数据同步有以下几种：

• 第一种，最简单的就是直接使用数据库自身的同步机制，优势就是比较好部署，可是缺点就是只能在一地写入。
• 第二种，就是本身实现数据库的复制，经过读取source DB将数据同步到异地的数据库中，好处就是实现了双向复制能够支持多地写入，可是缺点异地的数据库会存在必定的时延，毕竟须要先读取后同步。（阿里的DRC相似这种）
• 第三种，本身实现一个消息中心，异地的写入都先写入消息中心，而后由消息中心把数据分发到各个数据中心，在写入到数据库中。优势就是配置比较灵活，由于消息层和数据库层其实解耦了，缺点就是依然仍是存在延迟，异地的数据库无法彻底实现同步写入。（微博的WMB相似这种）

 

     我的认为第二种方式更适合互联网金融业务，由于金融类的业务更加注重数据的安全性和一致性，先成功写入一个数据库后在同步到异地能够避免不少问题，好比回滚等。

 

     最后，不得不吐槽一下，异地多数据中心的同步问题跟重要的是网络问题，微博就曾近悲催的一年被挖断专线4次+，什么技术在挖掘机前面都是纸老虎。

 

      

 

四、传统行业DBA和互联网DBA的有哪些区别？互联网DBA是否要投入更多的精力到工具和建设中，若是是，DBA和运维开发职业有什么区别？从一个DBA成长为CTO须要提高哪些方面硬实力和软实力？

 

     对于传统行业的DBA和互联网DBA以前区别，我的认为更多的实际上是由各自的业务形态决定的，即时互联网行业，金融、社交、游戏等行业也是区别挺大的。

 

     我的认为互联网的DBA应该投入更多的精力到工具的开发和自动化系统的建设中，相对传统行业来讲，互联网的节奏要快不少，这也就意味着需求多、快、杂，为了应对这些需求，纯靠人力是不可能知足业务高速增加的，因此必定要投入更多的精力。

     而一旦工具文化和自动化系统造成必定的规模，就会进入一个正循环中，即自动化提供效率，工程师有更多的时间去开发新的自动化系统，而后时间进一步释放，最终会就能够实现用极少数的人就能够运维支持海量的服务，并能保证一个较高的服务水平。可是若是没有造成这个正向的循环，就会陷入没人开发自动化 —》 用人力堆 —》更加没人开发 —》 用更多的人 这个恶性循环中，借用@田国的运维2.0的思想，这不是人性的运维，由于没有幸福感。

     可是关键就是造成规模和效益，有时候一些“自动化”系统反而是下降效率的罪魁祸首，就如同有些流程其实并不能让事情“顺”起来同样。其实最关键的就在于分析目前最浪费人力，最机械的劳动是什么，而后集中解决No.1问题，每次如此，慢慢的就会造成效益了。我的虽然不反对作总体规划，可是也不建议什么都设计好了在开工，不少时候等都设计好了的时候需求已经变化了，互联网公司即时是内部项目页能够秉承快速试错的思路，慢慢的造成本身的体系。

     而如今流行的DevOps，我我的认为这并非一种职位，而是一种思路，能够应用到各个领域，和DBA并不冲突，并且我我的一贯认为，运维的自动化系统必定要一线运维的人参与设计和开发，由于做为需求提出者和使用者最清楚想要解决什么样子的问题，并且，在系统出现问题和变化的时候，因为是直接利益关联方，不会出现“排期”“优先级”等问题，便于快速的对系统进行修正。

 

     最后一个问题因为我我的离着CTO还有九九八十一难那么远，实在不知道怎么回答，可是从我我的同一些高level的技术人接触来讲，并不都是技术上的“完人”，更多的感受反而是比较容易沟通，视野很大，方向感很强，因此我的觉得沟通能力，大局观，情商，坚韧的性格，这些软实例应该反而更重要一些。至于技术，用技术人常说的一句话来讲就是“技术上的问题都不是问题”最后都能解决，由于大部分状况下，都没用到须要拼天赋，拼智商的状况，只要足够努力就能够了。

 

五、在云数据库运维中，每每是数据库研发团队主导了性能优化和特性开发，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等方法解决，可是我的认为没有必要去想着解决这个问题，条条大路通罗马，若是是做为运维团队，应该和研发团队有机的组成一个总体，互相利用对方的优点解决问题，毕竟是焦不离孟孟不离焦的事情，缺了谁都玩不下去。