高效运维--数据库坐而论道活动
我个人对这5个答案的简单整理，详细内容请关注高效运维的微信公众号
1、如何看待DaaS（数据即服务）？DaaS有哪些要素构成？你认为目前实践较好的公司有哪些，为什么？
大家对于耳熟能详的IaaS和PaaS都非常的了解和熟悉了，并且对于这2个名词的定义也不会有太多的分歧，但是对于DaaS有些人可能会解释为Data as a Service，也有些人会解释为Database as a Service，不过我想小军要问的肯定是Data as a Service。
如何看待DaaS，网上通常的解释如下：“数据即服务是指与数据相关的任何服务都能够发生在一个集中化的位置，如聚合、数据质量管理、数据清洗等，然后再将数据提供给不同的系统和用户，而无须再考虑这些数据来自于那些数据源。”个人认为DaaS应该类似一个海鲜超市，在这个超市中应该有各种各样的数据，比如金融、通讯、用户行为、消费记录等等。然后用户会指定要那些数据，就如同将不同的海鲜放到购物车中，最终将选定的这些海鲜拿到加工店根据用户的喜好将这些海鲜（也就是数据）做成一桌子菜。
最终这一桌子菜才是用户真正想要的。而一个DaaS平台要能实现以上这些功能，那么就需要有如下几个要素
- 数据采集：一个超市总归是物品种类越多越好，所以数据种类也是越多越好
- 数据治理和标准化：不是所有数据都是好数据，所以要建立标准化便于准入和存储
- 数据聚合：这里会是最大的差异点，就如同同样的食材给不同的大厨做会出来不同的味道，所以差异化竞争应该在这里更多的体现。
- 数据服务展示：最后，展示环节就如同上菜，中国人对吃还是讲究色香味的。
最后这个问题，我还真回答不上来，但是我认为较好的实践一定会出现在天生拥有数据的那些公司，比如BAT，华为，京东，美团等等，因为个人认为整套DaaS最难的地方就是最开始的地方，拥有足够多足够多样的数据才能保持领先优势。
2、关系型数据库如何应对云时代的弹性伸缩挑战？
随着docker等容器技术的普及，现在前端应用服务可以非常简单的就弹起来，但是关系型数据要想弹起来，或者在具体点说MySQL如果想要弹起来就不那么简单了。
首先我们可以看下如果MySQL需要弹性伸缩都需要那些必要要素？
- 容量管理系统：我们需要知道在什么时候需要伸，什么时候缩。
- 资源管理系统：我们需要知道那些资源是可用的。
- 扩容迁移系统：自动完成数据的拷贝迁移和访问上线。
以及和一些周边的比如监控、配管、安全审计等系统的联动。
在这其中，最简单的就是扩容系统，因为这个完全是标准化和流程化的，但是也是最难优化的，因为大部分时候迁移所需的时间都是由数据的容量决定，是最难节省下来的。
其次，就是资源管理系统，只要做好信息采集并配合好资源隔离，那么在设定一定的规则就可以完成对资源的管理，以及推荐，也就解决了往哪里扩的问题。
最后，最复杂的其实就是容量管理系统，想要准确的计算出在那个时间节点需要扩容或者缩容需要基于时间线的各种分析。最简单就是环比和同比，复杂的计算方法就各显神通了。
最最后，个人认为相对于现在比较成熟的前端的弹性伸缩，数据库的弹性伸缩的目标不应该放在解决业务瞬时峰值上面，因为相对于前端来说数据库的扩容所需的时间较长，很可能在扩容完毕之后峰值已经过去了。而数据库的弹性伸缩更大价值应该在对资源的充分利用上。
3、异地多数据中心的数据同步有几种方式，各有哪些优缺点，哪一类更适合互联网金融业务？传统数据库是否适应和满足了互联网金融业务的要求，还有哪些改进的地方？
异地多数据中心其实做的最好是银行，可惜银行貌似从来没有出来分享过。目前我记得在网络上有过分享的阿里的异地双活数据同步基础设施DRC，另外微博其实也实现了异地机房的双活。
对于异地的数据同步有如下几种：
- 第一种，最简单的就是直接使用数据库自身的同步机制，优点就是比较好部署，但是缺点就是只能在一地写入。
- 第二种，就是自己实现数据库的复制，通过读取source DB将数据同步到异地的数据库中，好处就是实现了双向复制可以支持多地写入，但是缺点异地的数据库会存在一定的时延，毕竟需要先读取后同步。（阿里的DRC类似这种）
- 第三种，自己实现一个消息中心，异地的写入都先写入消息中心，然后由消息中心把数据分发到各个数据中心，在写入到数据库中。优点就是配置比较灵活，因为消息层和数据库层其实解耦了，缺点就是依然还是存在延迟，异地的数据库没法完全实现同步写入。（微博的WMB类似这种）
个人认为第二种方式更适合互联网金融业务，因为金融类的业务更加注重数据的安全性和一致性，先成功写入一个数据库后在同步到异地可以避免很多问题，比如回滚等。
最后，不得不吐槽一下，异地多数据中心的同步问题跟重要的是网络问题，微博就曾近悲催的一年被挖断专线4次+，什么技术在挖掘机前面都是纸老虎。
4、传统行业DBA和互联网DBA的有哪些区别？互联网DBA是否要投入更多的精力到工具和建设中，如果是，DBA和运维开发职业有什么区别？从一个DBA成长为CTO需要提升哪些方面硬实力和软实力？
对于传统行业的DBA和互联网DBA之前区别，个人认为更多的其实是由各自的业务形态决定的，即时互联网行业，金融、社交、游戏等行业也是区别挺大的。
个人认为互联网的DBA应该投入更多的精力到工具的开发和自动化系统的建设中，相对传统行业来说，互联网的节奏要快很多，这也就意味着需求多、快、杂，为了应对这些需求，纯靠人力是不可能满足业务高速增长的，所以一定要投入更多的精力。
而一旦工具文化和自动化系统形成一定的规模，就会进入一个正循环中，即自动化提供效率，工程师有更多的时间去开发新的自动化系统，然后时间进一步释放，最终会就可以实现用极少数的人就可以运维支持海量的服务，并能保证一个较高的服务水平。但是如果没有形成这个正向的循环，就会陷入没人开发自动化 —》 用人力堆 —》更加没人开发 —》 用更多的人 这个恶性循环中，借用@田国的运维2.0的思想，这不是人性的运维，因为没有幸福感。
但是关键就是形成规模和效益，有时候一些“自动化”系统反而是降低效率的罪魁祸首，就如同有些流程其实并不能让事情“顺”起来一样。其实最关键的就在于分析目前最浪费人力，最机械的劳动是什么，然后集中解决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等方法解决，但是个人认为没有必要去想着解决这个问题，条条大路通罗马，如果是作为运维团队，应该和研发团队有机的组成一个整体，互相利用对方的优势解决问题，毕竟是焦不离孟孟不离焦的事情，缺了谁都玩不下去。