怎么总结今年呢？有很多事情做得不错，有很多事情做得不太好，不过还是简单记录一下。
家里，最重要的是周阡出生了，以后家里又多了一个捣蛋鬼
年初，陪老婆和周陌去了一趟日本冲绳，玩得还比较开心
个人身体上，今年几次感冒反复，最终让自己患上了慢性咽炎，特别难受，这个大概需要长期和病魔做斗争了
读了三本书，算是超出我的期望：《解忧杂货铺》、《海伯利安》、《海伯利安的陨落》
换了辆新车，但是，还没有开去过远方
又装修了一次，这次没那么纠结，因为明白关键不是装得怎样，而是住在里面的人都开开心心，想想，谁会注意浴室柜、吊顶是什么品牌的！
拔了四颗智齿，整个世界都清静了
用80EQ看到了土星环，木星上的条纹，还找到了M13武仙座大星团，虽然只看到了一个很模糊的毛球
工作上整体还算顺利吧，今年的云栖大会搞得还不错，产品上有也有一些新的拓展
在斗鱼，看了很多“没落游戏WAR3”主播们（Fly、护国神蛋、新老逼王infi和120、TED、Lyn等）的比赛
就这样吧，迎接2018
本文前段时间写的介绍云端企业数据管理产品DMS的“软”文，文章首发在阿里巴巴数据技术公众号，扫描下面的二维码关注：
摘要：在安全稳定的前提下，为了解决DBA的服务效率问题，十年前我们开始iDB的研发，完成手工变更的在线化，成为了DBA能力产品化的载体。在最新的4.0版本中，iDB面向云时代，是业界首创的数据库devops解决方案，形成了云时代企业数据管理的最佳实践。
在阿里巴巴，数据库团队是数据的守护者，保障着数据库的安全、稳定、高效的运行。在早期，DBA除了负责数据库的基础运维，对于研发流程中的数据库变更也都由DBA负责，包括线上库表设计、结构变更发布、数据变更、SQL审核、性能优化、容量评估等等。这种精细的业务支持方式，企业早期发展中，可以有效的保障数据库的稳定与安全，支撑业务的快速发展。
业务持续增长，很快我们遇到了两个问题：(1) DBA繁重的工作量可能会成为业务研发瓶颈；(2) 大量的重复工作会限制DBA的成长。企业快速发展中，会不断的有新业务上线，成熟的业务也会快速迭代创新，伴随会有大量的数据库相关的变更和服务，如果所有这些都由DBA来处理，那么业务繁多DBA可能成为瓶颈，另外，DBA也会陷入各种“做不完”的日常工作，很难进一步成长。
既要有DBA的安全把控能力，又希望高效支撑大量业务的发展，阿里数据库团队研发了自己的企业数据库管理平台：iDB。企业内部的研发、测试等人员，可以使用iDB完成大部分数据库相关的操作，包括数据查询、数据变更、结构变更、实例申请等等。另外，iDB产品中还继承了大量DBA的经验，比如判断哪些DDL会锁表、InnoDB表结构设计是需要主要哪些问题等等。 (more…)
·
这是一个新手的观测记录，这次观测地点是在杭州余杭地区，光害当然很严重，这次观测只是尝试找到M13，因为是新手，其实我也不确定城市里面能不能看到目标。这是我的第三个梅西耶，之前看过M45和M44。
城市观测的困难在于，光害非常严重，适应楼顶的黑暗之后肉眼大概能够看到2.0等以下的星星。而梅西耶天体肉眼亮度都比较低，需要一些亮星的引导才能找到。
我定位的思路是这样的，大角星和织女星是很好找到的。M13大致在这两颗星的连线上，大概在靠近织女星1/3的地方。具体的定位，可以沿着牧夫座的梗河一(mag.2.69)、再到贯索四(mag.2.2)，再到武仙座ζ(mag.2.85)，再到武仙座η(mag 3.45)，再到武仙座π(mag 3.15)，然后到织女星(mag 0)：
当需要在机器之间传输400GB文件的时候，你就会非常在意传输的速度了。默认情况下(约125MB带宽，网络延迟17ms，Intel E5-2430，本文后续讨论默认是指该环境)，scp的速度约为40MB，传输400GB则需要170分钟，约3小时，如果可以加速，则可以大大节约工程师的时间，让攻城师们有更多时间去看个电影，陪陪家人。
scp -r -c arcfour128 ...
scp -r -c aes192-cbc ...
scp -r -c arcfour128 -o "MACs umac-64@openssh.com" ...原因概述：
-c arcfour128或-c aes192-cbc可以大大加速scp传输-o "MACs umac-64@openssh.com"是不错的选择。-o "Compression yes"来启用压缩来观察实际案例中的情况。声明：测试与数据本身特性有很大关系，本文使用InnoDB的redo log作为测试数据。
这里对比了12种ssh中实现的加密算法和是否使用压缩的传输效率，测试文件使用的是InnoDB的1GB*4的日志文件(注意：不同类型的文件测试结果会很不同)，这里纵坐标单位为MB/s，数据分为压缩传输和不压缩传输两组：
原始数据：scp_speed.txt
(more…)Linux的top或者ps都可以查看进程的cpu利用率，那为什么还需要了解这个细节呢。编写这篇文章呢有如下三个原因：
* 希望在脚本中，能够以过”非阻塞”的方式获取进程cpu利用率 * ps无法获得进程当前时刻的CPU利用率;top则需要至少1秒才能获得进程当前的利用率 * * 好奇