最近其实已经琢磨了不少的事情，有时候恨不得是十分钟干九件事情，但是我还是有些不满意，因为我似乎很多事情没有按照计划来做。所以我要吐槽一下。
先来吐槽软文
最近在朋友圈里看到不少的技术文章，有不少每每读完都有种让人伤神的感觉，因为有些文章看起来标题很丰富，但是看内容想看最后的结论，找不到，与其这样还不如多看几个段子给自己消遣消遣。有些文章看起来标题朴实，但是内容着实很丰富，这种文章毕竟是少数，我钦佩这样的文章，干干净净，朴朴实实，做技术就是技术的样子，不要带有太多的商业色彩，有些文章也确实有点货，但是读着读着感觉被带入了另一扇门，最后也会有点迷失的感觉，我有时候就很奇怪这样的文章，直到有一天听人说到软文这么一个概念，我才恍然大悟。这样一看我就看透了。然后也在偶尔会接到某某商家的电话，说想和我进一步洽谈，根据流量转发情况进行分成，坚持了几百天了，如果能有好的文章融入，着实是一件好事，不收钱也愿意接受，如果还有点外快，那就更提神了。但是他们在接触之后会发来一些链接，看着那些文章，就是完完全全的广告，这种的内容发出去，估计没几天大家就都取消关注了。现在我也不去主动推荐自己的公众号了，一种原因是感觉现在的好文章太多，拿不出手了，不能仅仅靠一个几百天的坚持来说明什么了，而且本身也说明不了什么。另一方面我想好好做自己的事情，给自己多一些空间和时间，因为自己目前也在做社群，其实有很多东西发现都是需要慢慢沉淀的，可能在某一天就会发现自己进步了一大截，我想看到自己默默成长的轨迹，在这个过程中会有很多的朋友来提问打气，已经足够了。而且现在着实没有那么多的精力了，有时候白天会把手机放在一旁，过很久才来看看手机。所以吐槽了一圈，还是要保持自己的风格，软文坚决不要，好的文章就不遗余力推广，无论是哪个社团，组织，在公众号里这就是我的小窝，我还能决定自己希望做的事情。
然后是关于运维管理自动化
最近总能听到各种运维经验之谈，总结攻略，包括我自己也在嘉年华上做了运维的一些经验分享，从我的观点来看，现在很多人都在推行自动化运维，我觉得可以再慢一些。首先看着别人做了多大的平台，多丰富的功能，多健全的维度等等。我觉得都是按需定制，别人的好不一定在你这边可行，别人的经验有很多到了你这边可能因为环境业务不通，感觉无从参考。那么这个时候就是参考这个理念了，很多功能都是逐渐完善，或者就专注于一个很小的模块，把它做好了做精了，比一个设计臃肿，已成体系然后再大刀阔斧改动的系统要好得多。
然后说自动化运维，自动化运维现在完全需要那么自动化吗，我觉得目前来看，至少从我的角度来看还么有那么多的场景确实需要，比如主备自动切换，技术肯定可行，那么自动化要这么动吗，我觉得很多场景实际上不需要这样，与其专注于这一方面，还不如更多关注于前期的更多监控优化管理。从本质上减少这种错误的概率。
现在的很多运维经验从我的观点来看都是从系统层面来入手，感觉还是缺少了很多应用层面的东西，当然一说应用就是具体的场景了，那么这些具体的场景也有一些通性。有些还是可以互相参考借鉴的。我看现在的很多运维管理工具就真是偏向系统的，其实完全可以考虑很多应用的功能，我之前的工作环境中应用运维的工作就做得非常彻底，只是公司比较低调而已，而现在的很多公司的产品相比，其实要考究的多，都说现在sql审核非常重要，sql规范非常重要，很多时候我们发现都是在后期了，那么这些问题看起来确实都是开发导致的，那么回过头来，对于开发来说，他肯定压根不需要知道哪个表所属的表空间，表中的约束名等等，这些如果从前期规划都是完全可以避免的。比如我们之前就是所有的开发语言都会有一个统一的db入口，任何的db变更，初始化都会从这个入口来完成，至于约束名，表空间等等这些都会有对应的配置匹配。有了这些基准，后期的管理和维护就会容易的多，比如分多版本，多模块，大体也会在这个框架之内，不会乱来，那么有了这些基础的制约，sql审核的工作就非常有限了，从我的感觉来看更多都是sql优化的部分，语法错误这种问题基本没有见过。我们也没有推行sql审核工具，照样可以做得很好。
如果觉得这些还听起来就那么回事，那么开发同事可以自主导入导出数据，可以自己完成备份，环境升级，环境补丁的部署都可以由开发同学自主完成，这些就不用我们做太多的干预，那么应用的运维需要不需要？所以这些问题再追根溯源，还是能够从初始化开始就能避免很多的问题，那么这些应用的工作都做得很好了，dba干嘛呢，做更有价值的工作。
今天和前阿里的哥们聊天，有一点就很好，关于数据库性能测试中的rt就是基于应用得到的一个值，这些测试基准基于完全真实的应用场景会更有说服力更有意义，哪些iops,tps之类的指标在脱离业务之外裸奔的数据还是站不住脚的，所以还是需要关注业务，这也是我在嘉年华中的运维工作中特别提到一部分业务和开发。我的用意就在此。
最后说说数据库中的技术问题
今天听同事讲数据库存储的内容，当然内容也是常规的部分，但是换做以前的我，也是感觉脱离不了这些圈圈范围。存储再能在oracle范围内将出点什么来，还不如哪些基本的概念和知识点，有时候我们可以反问一些，为什么在oracle中会这么实现，有没有其它的参考，其实可以的。很多的东西都可以去参考操作系统层面你的实现，比如操作系统层面有外存内存，外存的管理和数据库的物理管理有些类似，内存的部分和数据库中的内存管理有些类似，那么关于存储管理，多说一点就是操作系统里的初始概念，固定分区，可变分区，分页等等，这些其实都在Oracle中似乎能够看出一些痕迹，在Oracle中听起来很高大上的mutext概念，如果翻看操作系统层面的概念，本身这个概念就已经很早就提出来了。都有一些参考和借鉴之处，比如关于区段的本地管理，使用了位图的方式，那么操作系统层面还有哪些可以借鉴的东西，光算法就已经很多了，最佳适应算法，最先适用算法，位图法，其实多了解一些还是对于我们理解oracle有很多的益处的。
所以吐槽归吐槽，技术归技术，真是一码归一码，把自己的一亩三分地搞透了，搞明白了，其实本身就是一件很有价值的事情。
先来吐槽软文
最近在朋友圈里看到不少的技术文章，有不少每每读完都有种让人伤神的感觉，因为有些文章看起来标题很丰富，但是看内容想看最后的结论，找不到，与其这样还不如多看几个段子给自己消遣消遣。有些文章看起来标题朴实，但是内容着实很丰富，这种文章毕竟是少数，我钦佩这样的文章，干干净净，朴朴实实，做技术就是技术的样子，不要带有太多的商业色彩，有些文章也确实有点货，但是读着读着感觉被带入了另一扇门，最后也会有点迷失的感觉，我有时候就很奇怪这样的文章，直到有一天听人说到软文这么一个概念，我才恍然大悟。这样一看我就看透了。然后也在偶尔会接到某某商家的电话，说想和我进一步洽谈，根据流量转发情况进行分成，坚持了几百天了，如果能有好的文章融入，着实是一件好事，不收钱也愿意接受，如果还有点外快，那就更提神了。但是他们在接触之后会发来一些链接，看着那些文章，就是完完全全的广告，这种的内容发出去，估计没几天大家就都取消关注了。现在我也不去主动推荐自己的公众号了，一种原因是感觉现在的好文章太多，拿不出手了，不能仅仅靠一个几百天的坚持来说明什么了，而且本身也说明不了什么。另一方面我想好好做自己的事情，给自己多一些空间和时间，因为自己目前也在做社群，其实有很多东西发现都是需要慢慢沉淀的，可能在某一天就会发现自己进步了一大截，我想看到自己默默成长的轨迹，在这个过程中会有很多的朋友来提问打气，已经足够了。而且现在着实没有那么多的精力了，有时候白天会把手机放在一旁，过很久才来看看手机。所以吐槽了一圈，还是要保持自己的风格，软文坚决不要，好的文章就不遗余力推广，无论是哪个社团，组织，在公众号里这就是我的小窝，我还能决定自己希望做的事情。
然后是关于运维管理自动化
最近总能听到各种运维经验之谈，总结攻略，包括我自己也在嘉年华上做了运维的一些经验分享，从我的观点来看，现在很多人都在推行自动化运维，我觉得可以再慢一些。首先看着别人做了多大的平台，多丰富的功能，多健全的维度等等。我觉得都是按需定制，别人的好不一定在你这边可行，别人的经验有很多到了你这边可能因为环境业务不通，感觉无从参考。那么这个时候就是参考这个理念了，很多功能都是逐渐完善，或者就专注于一个很小的模块，把它做好了做精了，比一个设计臃肿，已成体系然后再大刀阔斧改动的系统要好得多。
然后说自动化运维，自动化运维现在完全需要那么自动化吗，我觉得目前来看，至少从我的角度来看还么有那么多的场景确实需要，比如主备自动切换，技术肯定可行，那么自动化要这么动吗，我觉得很多场景实际上不需要这样，与其专注于这一方面，还不如更多关注于前期的更多监控优化管理。从本质上减少这种错误的概率。
现在的很多运维经验从我的观点来看都是从系统层面来入手，感觉还是缺少了很多应用层面的东西，当然一说应用就是具体的场景了，那么这些具体的场景也有一些通性。有些还是可以互相参考借鉴的。我看现在的很多运维管理工具就真是偏向系统的，其实完全可以考虑很多应用的功能，我之前的工作环境中应用运维的工作就做得非常彻底，只是公司比较低调而已，而现在的很多公司的产品相比，其实要考究的多，都说现在sql审核非常重要，sql规范非常重要，很多时候我们发现都是在后期了，那么这些问题看起来确实都是开发导致的，那么回过头来，对于开发来说，他肯定压根不需要知道哪个表所属的表空间，表中的约束名等等，这些如果从前期规划都是完全可以避免的。比如我们之前就是所有的开发语言都会有一个统一的db入口，任何的db变更，初始化都会从这个入口来完成，至于约束名，表空间等等这些都会有对应的配置匹配。有了这些基准，后期的管理和维护就会容易的多，比如分多版本，多模块，大体也会在这个框架之内，不会乱来，那么有了这些基础的制约，sql审核的工作就非常有限了，从我的感觉来看更多都是sql优化的部分，语法错误这种问题基本没有见过。我们也没有推行sql审核工具，照样可以做得很好。
如果觉得这些还听起来就那么回事，那么开发同事可以自主导入导出数据，可以自己完成备份，环境升级，环境补丁的部署都可以由开发同学自主完成，这些就不用我们做太多的干预，那么应用的运维需要不需要？所以这些问题再追根溯源，还是能够从初始化开始就能避免很多的问题，那么这些应用的工作都做得很好了，dba干嘛呢，做更有价值的工作。
今天和前阿里的哥们聊天，有一点就很好，关于数据库性能测试中的rt就是基于应用得到的一个值，这些测试基准基于完全真实的应用场景会更有说服力更有意义，哪些iops,tps之类的指标在脱离业务之外裸奔的数据还是站不住脚的，所以还是需要关注业务，这也是我在嘉年华中的运维工作中特别提到一部分业务和开发。我的用意就在此。
最后说说数据库中的技术问题
今天听同事讲数据库存储的内容，当然内容也是常规的部分，但是换做以前的我，也是感觉脱离不了这些圈圈范围。存储再能在oracle范围内将出点什么来，还不如哪些基本的概念和知识点，有时候我们可以反问一些，为什么在oracle中会这么实现，有没有其它的参考，其实可以的。很多的东西都可以去参考操作系统层面你的实现，比如操作系统层面有外存内存，外存的管理和数据库的物理管理有些类似，内存的部分和数据库中的内存管理有些类似，那么关于存储管理，多说一点就是操作系统里的初始概念，固定分区，可变分区，分页等等，这些其实都在Oracle中似乎能够看出一些痕迹，在Oracle中听起来很高大上的mutext概念，如果翻看操作系统层面的概念，本身这个概念就已经很早就提出来了。都有一些参考和借鉴之处，比如关于区段的本地管理，使用了位图的方式，那么操作系统层面还有哪些可以借鉴的东西，光算法就已经很多了，最佳适应算法，最先适用算法，位图法，其实多了解一些还是对于我们理解oracle有很多的益处的。
所以吐槽归吐槽，技术归技术，真是一码归一码，把自己的一亩三分地搞透了，搞明白了，其实本身就是一件很有价值的事情。
