上周就开始阅读了，作为一个伴随着腾讯长大的80后，同时也身处互联网中的网中人还是挺有感触的。
其实在追新这方面我还是挺后知后觉的，除了饭否和豆瓣是第一时间开始用的，其他基本都很落后，98年开始上网，一直到01年才开始申请QQ号，微信号更是在微信红包大战的时候才申请了。而书中说的msn在06年已死，可我居然一直用到07年底，而360的东西更是从来没接触过。
对于腾讯这个公司，其实在11年以前是没有什么好感的，抄袭的王者，但是读罢以后发现还是小看了他们，其实也是自己没有很深的思考和阅历导致的。08年做视频，总觉得很简单，不就是视频文件分割走CDN，而自己负责的恰恰就是CDN，我所看到的也就是CDN，而对于调度，p2p，合并，加速视频流这些居然都视而不见。其实这些才是这家公司的核心啊，至于CDN这些都是很外围的，用自己和别家区别不大（akamai除外）。
刚上大学的时候，正是生物特别热门，那时候最好的学生都被忽悠进生物系了，这个可是改变人类未来命运的，生物医药，基因工程，可15年过去了，生物系出来的大多是当生物老师，或者转行了，水木上有生物大神最后也去了MBB中的一家做咨询了。虽然未来还是可期的。 而现在机器学习的崛起，是不是意味着我们很多工作都基本也会被替代了，首当其冲我觉得运维是最容易被替代的，一个云计算基本把所有系统运维的活给替代了，而后面的PAAS的全面普及和优化，那基本没啥应用运维的事情了，这些岗位可能在云计算公司里还会存在，但是其他公司内基本就可以取消了。 按这个逻辑下去真是越想越可怕，除了完全需要创造类的工作，其他机器都可以做啊，矮大紧在一集好莱坞的介绍里讲了好莱坞挑选剧本就完全属于一个机器行为，多少时间铺垫，什么时候高潮，有多少个高潮，结局如何收尾都是有固定模式的，但为什么好莱坞也会出好片呢？ 最近在看《腾讯传》里说的一点就是微创新可以很好的解答上面那个问题，很多东西是有一定规律，机器完全胜任，但是这个规律我们是不是再修正下，就比如PAAS平台，就拿最简单的redis来说，针对每个服务需要优化的地方也是非常多的，那我们就一点点修正，直到出来一个公式可以适配这些不同的应用，不过这个没啥难得，连AlphaGo这样超复杂的围棋机器人都可以做，这点条件根本不算啥，但是这当中就是一个训练机器人的过程。 这些所有的微创新机器人至少不能提前做，但是能很快学会。 看到国外有一个新职业叫训机师，就是给机器人喂数据，但是可悲的是这个职业的目标居然是让机器人来取代自己。 但这个世界就是这样啊，汽车出现会导致了马车的沉寂，当然现在很多旅游景点还是有的，接下来该失业的估计就是汽车司机了吧。很多职业都会随着技术的进步而消亡，只是在IT行业这个消亡的速度会非常之快。 近期看运维是最危险的了，然后写代码也挺危险了，你只要描述伪代码就直接产生对应的程序，这种工具现在有，只是还不成熟罢了，最终会不会演变成只要产品文档符合某种规范就直接生成了呢？ 虽然说是近期，那估计还能活5年吧，但是5年后的事情真是难说了。看来要不被社会所淘汰，得加快步伐了。
2016年如果从工作上来看，几乎是一事无成啊，也没研究点啥，也没提高啥，就跟黄舒骏的《马不停蹄的忧伤》里唱的一样。 从博客的荒废程度就知道今年啥都没干了。 但是自己干的很苦逼，底下兄弟们也很苦逼，整个技术部也很苦逼，原因呢？ 其实最苦逼的倒不是工作忙，忙的有意义经常还让人精神振奋，无意义的才会感觉苦逼。 看来现在是已经过了自由自在搞技术的年代了，邹哥说之前会上有人问运维能否做到40岁，中国运维的起步是1999年，到现在已经17年了，当年23岁的小伙现在也已经40岁了，不过当年那批运维现在都是各厂的管理层了，所以应该现在是没有的，未来说不好，也许运维这个岗位随着云计算的快速发展就会继续萎缩下去，最终只有一些大厂里才会存在的了。 有些趋势你是阻止不了的，你可以往基础上更专，那样确实很有前途，也可以在需求上更广。 怎么说呢，互联网发展那么多年了，但是总离不开tcp/ip的，搞这些基础的要有深度才行。常说移动电信最终给他人做嫁衣，但是那些应用厂商真的离得了这些基础运营商？ Fenng说过一句话现在看来是挺对的，“技术总是在短期内被高估，但是在长期又被低估。” 放在国内任何中小厂里都是适用的，毕竟生存是第一位的。在生存都有问题的情况下谈什么自行车呢？对于商业来说短期利益永远都是第一位的，至于长期的东西谁又能说的清楚呢？ 虽然工作上和技术上没有任何长进，但是从生活上来说是进步很多，小小球一天天的长大，球子也恢复的还不错，只是北京这雾霾天让我对家人的健康很是担心了，而且现在一点没有趋好好迹象，某些发誓2017年前要治理好雾霾的领导也滚蛋了，最终也没有提头来见。 在年末的时候老妈脚骨折了，本来还说过来给小小球过生日的计划也泡汤了，定的机票也给退了。还好恢复的挺快，居然已经拆线了，不过里面的钢钉要不要拿出来还是未知数。老妈住院几乎所有亲戚都来看了，老妈应该还挺欣慰，最好的还是姐妹俩的感情深啊。 2016年的美元价格直线上升啊，但是算了下其实1年差不多是10%的样子，但是买美元可不是为了这个，只是资产的多样配置。2016年我们见识了太多的黑天鹅事件了，所谓的民调现在看来是并不可靠，看来大多数人不会在公共场合中表达自己的真实想法，所以产生了英国脱欧，特朗普当选这样的事件。
直接使用的 https://github.com/airbnb/kafka-statsd-metrics2.git 这个将metric汇报到statsd中。 statsd是使用了collectd自带的plugin来实现的。这样等于每台服务器上都有statsd了。 最后collectd将收集到数据存储到influxdb集群中。 这个jar包在kafka 0.8.2和0.10.0上使用都没有问题。 不过在官网的readme中有些问题，故还是走了点弯路。 必须要自己编译一下。 c git clone https://github.com/airbnb/kafka-statsd-metrics2.git ./gradlew shadowJar 这样我们就可以获得 kafka-statsd-metrics2-0.4.1-all.jar 这个jar包，放入到kafka的libs下。 由于这个是依赖了datadog的statsd client，因此还要下载一个jar包。 https://repo1.maven.org/maven2/com/indeed/java-dogstatsd-client/2.0.16/java-dogstatsd-client-2.0.16.jar 配置文件官网写的没有问题，直接使用就可以了 ```c
#for metric # declare the reporter kafka.metrics.reporters=com.airbnb.kafka.KafkaStatsdMetricsReporter # enable the reporter, (false) external.kafka.statsd.reporter.enabled=true # the host of the StatsD server (localhost) external.kafka.statsd.host=localhost # the port of the StatsD server (8125) external.kafka.statsd.port=8125 # enable the support of statsd tag extension, e.g. datadog statsd (true) external.kafka.statsd.tag.enabled=true # a prefix for all metrics names (empty) external.kafka.statsd.metrics.prefix= # note that the StatsD reporter follows the global polling interval (10) kafka.metrics.polling.interval.secs=60
微服务是去年开始很热门的词汇，有幸碰到老板也想实践微服务的。但是这这中间确实碰到了很多的问题。 首先是api的规范问题，这也是从运维角度来说最重要的部分。 由于之前是单jar包的方式，原先的开发者也不关注api的规范，导致api的URL完全是凭感觉编的，这个在拆分服务的时候就特别头疼。 /api/stat/1 是指向A服务 /api/stat 又是指向B服务 另外一个是输入和输出的问题，api最关键的是保证输入输出能够长期保持一致，就跟你用第三方的api，你总不能让你新增加的response啥的吧，或者json里再增加点新的内容，当然在公司内部，我们还是可以商量的，但是不能今天这个API是做这个功能，明天就变成B功能了。 这个就很头疼了。 配置文件的统一管理，这个因为拆分成很多服务了，所以再也不能一个配置文件解决所有的问题了，那统一起来管理还是很有必要的了。 基础服务saas化（比如redis，cassandra, kafka, MySQL），这些基础通过程序包装起来供程序来申请资源，调用，容灾，升级等。这个也是对于原先的运维团队工作量最大的地方。但是也是必须的。 因为拆分成微服务后，各个服务都可能需要用到redis，是分个大redis池，还是每个服务单独一个池子呢？ 在微服务领域一般都是一个服务给一个池子，但是不应该一概而论的。我们还是要综合评估的。不能为了微服务而微服务的。 日志的汇总收集，展示。这个标准做法就是通过ELK来完成了，当然我们还用到了kafka来做这个。不过前期是做好日志格式的定义。还有别忘记分了新服务出来后要reload下日志插件，不然都还是找的老的服务。这个就扔部署脚本里一起做了。 在实际使用中发现 consul缺乏服务使用率情况，这个现在是通过监控去收集各个服务的信息再汇总到grafana中，后期是想通过kong来做api调度，然后通过这样的https://getkong.org/plugins/runscope/ 插件来实时查看。 而且consul要跟upsync模块结合的话还要自己写程序去迁移consul中service的内容到kv中，这个实时性就不高了。后面准备自己写入和删除kv。 最后：微服务的优势就是为了更好更快的扩展，降低服务之间的耦合性，但是对于开发的要求更高了，对于运维的要求也同样更高了。
jar包都通过maven+nexus来进行管理了。不想部署多套版本管理，所以有些其他程序的也想用nexus来进行版本管理，最简单的方式就是通过curl的了。当然nexus原生还提供使用npm的方式。 主要通过下面2个页面学习了下。 https://support.sonatype.com/hc/en-us/articles/213465818-How-can-I-programatically-upload-an-artifact-into-Nexus- http://stackoverflow.com/questions/4029532/upload-artifacts-to-nexus-without-maven
1 | curl -v -F r=releases -F hasPom=false -F e=zip -F g=com.timoq.blog -F a=Wordpress-frontend -F v=v1.5.2 -F p=zip -F [email protected] -u timo-deploy:PASSWORD http://blog.timoq.com/nexus/service/local/artifact/maven/content |
不过要稍微注意下，上传的Repository的policy必须是release的，不能是snapshot的，至于snapshot和release这2个policy有啥区别，可以参考 http://stackoverflow.com/questions/275555/maven-snapshot-repository-vs-release-repository 其实就是snapshot可以随时改，就是覆盖原先的版本，而release不能。
阿里云RDS有个功能叫临时升级，你可以随意升级多久，但是默认阿里云给你自动升级1年，每次都得往回退。 今天说的是一个奇葩的bug。 6月份为了大促升级了一个RDS，升级33天，就升级了cpu和memory， 可前2天发现磁盘快不够了，于是想升级磁盘到1TB，结果不允许，跳出下面的提示。 
以为还有什么东西还没续费，可看了订单里没有什么东西，都是已经支付的。找售后问就如下回复了。 
最后还是没有升级成，只能自己去清理DB了。 而阿里云的原因就是2个升级操作不能再同一时刻生效。在一个续费变配还没完成以前就不能执行其他的升级和降配的任何操作。 我觉得唯一的理由就是阿里云自己不会算这笔帐了。而这样其实是一个非常大的坑。 这种变配操作你不能设置的很长，但是设置短了可能又会导致自己的麻烦。
用了阿里云服务其实已经很多年了，但是一深入用，感觉各种问题。 这不这次又出问题了。 起因是增加了内存和CPU，阿里云只能在页面中关机，启动才能生效。 这也不说了，其它很多云也都是这样的。 这个机器原先单独加了一个磁盘，做了LVM卷，这下悲剧了，重启以后发现LVM卷丢失了。但是盘还在，没办法只能给阿里与发工单请求解决。 然后阿里云的售后要了root密码，找了半天就这样回复我 “服务器上没有看到任何有lvm创建过的痕迹，建议您其他机器先检查下创建过程是否正常。”。还特地给我截图了一下。 
要是pvs和lvs这些我能看到也就不找售后了。于是打回去让他们继续找。结果他们居然还是找到了，但是原因不知道。 
但有一点还是肯定，他们技术人员还是很敬业的，那么晚了还给我打电话呢，但是从这里可以看到，阿里云的技术是真不怎么样。 后来就懒得用那个数据恢复了。原因找不到没啥意义，我另外几台ES依然不能直接重启，不过后来试了几台，发现都没问题，应该是阿里云自己有什么bug在后台偷偷修复了给。 继续吐槽其他的吧。 原先没VPC，现在有了VPC，但是不支持迁移，也不能互访，就只能通过公网互访。 内部几乎没有标准，有的区使用xvda, xvdb这样的命名方式，但是有的区是vda, vdb也没有啥规律。 网段划分混乱，导致内部无法做nat服务都。 由于没有VPC原先，所以搞了安全组出来，结果一个机器只能有5个安全组，对于我们这种用户远远不够啊。 非高性能IO的机器可以挂载SSD云盘，但是IO还跟原先SATA磁盘一样，理由是底层不支持，但是不支持你倒是别让人挂载啊。 RDS sql审计的功能突然哪天就变成收费了的。 RDS机器居然都是100.xxx.xxx.xxx这样网段的，你们还真敢用。 SLB没有日志，导致没法查看详细的内容，经常出了问题只能摘除后端重建。 原先OSS只能有10个bucket， 不过现在已经增加到1000个，也不知道原先10个限制是怎么想出来的。 API不好用，经常碰到文档跟实际不符合，而且没有像AWS那样一个完整的SDK。 好了，吐槽就这样了。
做奶爸最重开心的就是看着自己的小宝一点点长大，特别前3个月，你会发现变化特别大。
刚出生的时候居然还有抬头纹，跟小老头似的，可一个多月就长开了。
然后你又会发现他的个子突然就高了，手指突然长长了，体重又重了，突然有一天会对着你咯咯乐了，突然有一天会发一些单音节的词了，总之一直在给你惊喜中。
拍嗝： 这是必须的，特别是前面2个月，小小球的肠胃还没发育好，所以每次吃完奶之后必须启动拍嗝程序，竖着拍，躺着按摩，必须要变换姿势。 你没有奶喂，那拍嗝自然落到你头上了。反正是必须要拍出来为止，但是有时候可能有一个嗝，有时候就比较多，这个不好判断了，主要看喝奶的时候吸了多少空气。
换尿布，如何换，什么时候换。
如何换很简单，不要勒紧大腿就行，不然时间长了会有勒痕的。
log需求主要分2种： 一个是平时给开发人员和测试人员开放实时查看的。 另外一种是用来进行存储起来进行后面的统计分析。 由于给开发和测试，他们一般都没有服务器的权限，但是又需要实时查看，毕竟有时候问题的时间日志比较好在当场表现出来，后面再去log库里查就比较麻烦了，为了解决这个问题，那就需要一个单独的日志服务器去实时收集。 同时最好是web页面去展示出来，然后可以自己定义filter。 这个需求找了一圈发现了一个叫log.io的工具，但是需要装client，而且是nodejs写的，所以还得部署一套nodejs。这个对于我们的需求是不是太重了。 我们现在所有的机器上其实都已经有fluentd了，如何利用好现在的设施是需要考虑的，我不倾向于为了实现特地目的去引入特地的工具，这样对于运维人员会更好一点，毕竟后期维护成本是必须考虑，引入一个新的工具，后面监控维护是需要一长串事情要做的。 于是最终是2个方案集合成一个方案来进行。
第一种方案kibana没有很好的认证，但是我们自己写了一个基于内部认证系统的接口挂在kinbana外面，使用nginx的subrequest来进行实现。 为了保证实时性，写入es的数据都设置为缓存10秒就进行写入，后期碰到瓶颈后再调整。 同时需要修改程序的logback，所有的log都写入到同一文件中，但是日志格式需要定义好：time，application-name， log-level, msg 这样的格式去定义好，然后在es中前3个字段都进行索引，msg内容就不索引了。 每天建立一个index，为了减少数据量index就只保留最近一周的，超过一周以上的还得从文件系统内进行查。但是开发人员一般很少查一周以上的数据。 统计分析的需求。纯文本对于各种分析工具都是最友好的，而且统计分析都是实时行要求很低的，但是又要经常看整个历史趋势的。所以对于一些长期的数据是必须要有机制来进行合并汇总的。 但是单纯文本可能占用的空间比较大，我个人是倾向用gz格式进行压缩的，而不是使用bz2格式，bz2虽然压缩比更高，但是耗费cpu time可是要高3，4倍左右了，得取一个相对经济的方法来进行。