2015年终总结

每个人在回忆过去时，都有一大堆的遗憾，这个没做，那个又没做好，要是我们选择那个什么什么事情该多好啊。从这一大堆的遗憾中，我们“东山再起”，拟定了华丽的来年计划，这是一个没有边界的大饼，任何有眼光的人都觉得前途无量，每看一次都足以让人激情高涨至少一个月。但当时间一天天的流逝，激情不再，早就把当初那个让人激情澎湃的年度规划抛诸脑后了，一转眼年底将至，回忆过往，又是“竹篮打水”的一年，我们不禁会问自己：“今年，还要定计划吗？”内心一个微弱的声音回应道：“还是定一个吧，万一实现了呢?”

2014年我告诉自己要成为一名合格的python后台开发工程师，2015年3月很庆幸得到现在公司的offer，这可能对我今后的职业生涯影响都是巨大的，2014年开始独立设计开发一个小型项目，但都仅限于python基础（wxpython，外加一丁点的多线程和socket等方面的知识），就像之前去面试一个大数据相关职位时面试官说的：“你仅仅是懂一点python而已，没有其他类似openstack、服务器后台或者大数据相关的经验”。这一次的职位是软件开发工程师，工作内容是openstack开发

初入openstack

入职公司时，我所在的云计算部门才成立不久，开发人员不到10人，一半以上的被分到了控制台开发（openstack-dashboard），在组长和我的共同努力下，终于找到了与我之前工作相关的一个任务，任务内容是使用smtplib给指定的邮箱发送告警邮件。这本是再平常不过的一件小事，但在我心里却涌起一波又一波思想的浪潮，不禁感叹，事物的变化没有我们想象的那么困难，今天我会因为使用过smtplib这个库进而转到监控告警相关模块的开发，未来就不能因为我今天在某一技术上的努力而获得成功吗？

horizon，openstack-dashboard

在openstack-dashboard的开发过程中，对django框架的了解逐步加深，与之前相比，除了从《The Django Book》上看的一点基础知识外，还能实际的去组织urlconf，编写对应的view和返回展示数据的template，对网站后台开发有了一点了解，总的来说：“我在公司的云托管控制台上有了自己的页面了”。openstack-dashboard的开发大致持续了两个月，从邮件发送到部分商品的计费再到价格方案的缓存，一路荆棘丛丛，踩了不少坑。在遇到很难解决的问题时有过失落和迷茫；历经千辛万苦实现一个功能时有过成功的喜悦；维护代码时，有过恨铁不成钢的痛心疾首；有一次只做了很少的修改就很好的适应新的需求，我感到了前所未有的成就感和优越感，我终于写成了易于维护的代码，只是在所写代码中的比例还不够高

ceilometer和“开发新规”

机缘巧合，一位做ceilometer的同事因为要回家继承家族产业离开了公司，我就从Icehouse版本加入ceilometer的开发。一开始是很没底儿的，没底儿到他不想工作我也不能拿他怎么办，openstack的部署已经完全超出了我可控的范围，那么多节点，每个节点上都有多个服务，要是哪天不能正常工作了，我都不知道从哪里开始着手去查找原因。我现在能查到的最早关于ceilometer的笔记大致是这样的：“ceilometer-api部署在xx节点，ceilometer-agent-compute部署在xx节点”，搞清楚各个服务部署在哪个节点上之后，就算是“入门”了，接下来接触到ceilometer的配置，让他按照我们想要的方式跑起来

到目前为止，我们的代码和文档都提交在svn上的，没有review，开发者“各自为政”，除了早晨的站会报告下进度，余下的时间要是没有遇到搞不定的难题都不会跟其他人讨论交流。随着一个同事的加入，我们的工作方式发生了巨大的改变，变成了openstack社区一样的开发，在这套开发流程实行起来之前，大家惶恐，担心一次代码需要反复的review修改才能提交，再加上那严格的pep8可不是闹着玩的。临近切换提交代码方式前几天，同事们还在开着玩笑，有代码就赶紧提交了吧，别等着上了Gerrit到时过不了review这一关。我们这群没有在社区活动过的小伙伴担心代码规范，头疼UT。接下来一连几次的代码提交让我意识到：编码规范对于我来说其实并不难，基本上每次提交都可以做到不修改或者少量修改，我可以很快的融入到这样的开发，并且喜欢这样的开发方式

一次UT的修改调试让我对UT也有了全新的认识，编写UT可以让你对被测试代码有更深层次的掌握。事情经过是这样的，在我们的需求中，需要把Alarm（Threshold和Combination）绑定到某个资源进行监控，但这在社区版本上是没有这个功能的，我新增了一个表记录ThresholdAlarm和CombinationAlarm与资源的绑定关系，并修改了告警评估的流程。这必然导致UT无法通过，逐个排查无法通过的UT，在排查的过程中，一些原本不大确定的概念渐渐变得清晰，猛然发现：我已经犯下了一个不小的错误——破坏了软件的架构。告警评估支持插件，ThresholdEvaluator是一个，CombinationEvaluator也是一个，而我需要的不是修改他们，是新增ThresholdMonitorResource、CombinationMonitorResource的插件，来实现我们的需求。相应在Alarm的存储上，Icehouse版本的ceilometer并没有完全实现插件式支持，再后来的Kilo版本是实现了的。在维护一个项目时，我们都应该做到对项目的整体架构了然于胸，才能给这完美的框架添砖加瓦。如果可以，从架构开始了解你要维护的项目

在我的开发中，要求我是全栈程序员。openstack-dashboard上实现界面的呈现，python-ceilometerclient提供访问接口，ceilometer提供核心功能。功能开发完成后，需要部署到生产环境，一两个环境尚且可以抽时间手动部署，如果是3个，5个，50个呢？我们需要一个自动化部署，在执行这个脚本前设置必要的参数，然后一键执行部署完成，于是参照同事的shell脚本，现学现卖实现了ceilometer自动化部署脚本。到此，功能算是上线开始工作了，但真的就足够了吗？显然不够，我们没有考虑数据可用性问题，ceilometer共部署两个API服务，数据库分别使用mongodb:127.0.0.1:27017，数据不统一且没有备份，一但一个数据库挂掉整个ceilometer就无法正常工作，经过一个星期的官方文档的研究，我们选定了三节点的ReplicaSet，每个ceilometer-api都连接到这个三节点的ReplicaSet集群。其实一个产品到此算是真正的上线了，接下来就是运维了，运维期间也会遇到各种各样奇葩的问题，都需要开发去定位分析，然后解决，并把遇到的问题及解决方案整理成类似FAQ的形式一同提交到了MongoDB部署文档中，希望可以借助这个文档让运维的同事接手

软件开发之外——一次数据裁剪

随着ceilometer监控资源的增多，数据成线性增长，就ceilometer-agent-compute一个服务而言，我们仅考虑目前关心的六个监控指标，按照一分钟采样一次的配置，一个资源一天将会产生60*24*10=14400条记录（我们环境中的六个监控指标还需要采集另外的四个监控指标数据进行计算转换得到），一百个资源就会有接近150w条记录，不需要多久，1个TB的硬盘就会被占满，ceilometer-api的每次请求耗时也会相应的增加（尤其是某些list的操作，因为返回结果数据量大，网络传输耗时较大）

开始分析我们的产品如何使用这些数据，分析发现我们就用户场景来看，需要的数据大致如下：

一个评估周期内的数据，需要全部保留，评估周期内总共就采样三次，数据量不大

评估周期以前到最近六小时处，也是保留全部的点

六小时以前到最近一天，每个统计窗口（15分钟）内我们保留最接近该窗口内采样数据平均值的三个点（具体几个点可以设置）

一天以前到最近两周，统计窗口变成60分钟，裁剪算法一样

两周以前到最近一个月，统计窗口变成120分钟，裁剪算法一样

一个月以前到最近六个月，统计窗口变成了1天，裁剪算法一样

六个月以后，全部删除

裁剪结束后的数据量小了至少两个数量级，节约了存储空间，节省了api请求时间。当然最好的还是不好删除数据，可以采用转移备份或者通过升级硬件性能和软件性能来满足大数据量下依旧稳定高效的api服务，这可以保证数据的完整性，但需要更多更快速的硬盘和更高性能的软件来支持

数据裁剪的脚本也有两个版本，第一个版本当数据量稍大（1000w条记录以上）不能够在一天内完成裁剪且内存消耗很大。经过修改，5000w条记录的数据量可以在8小时内完成，内存占用很小，性能已然提升了不少，但绝对还可以做的更好

他的收入是我的三倍

我们大学同一个寝室的，还没有电脑时一起去网吧玩游戏，有电脑了一起在寝室玩游戏、看电视剧，他可以一部《神探狄仁杰》就看6、7遍，可以在网吧一玩就是20小时以上，遇到问题死磕到底，下面是毕业三年后跟他的一次聊天内容，此时他的收入已经是我的三倍



说是聊天，其实这段全是他在说，我看着一行一行的文字出现在屏幕上，里面的好多行不是输出到了屏幕上那么轻，仿佛是纹到了我的心上，是那么的清晰，那么的沉重，又有一刹那觉得我已经变得卑微的心承载不了，因为每一个字都是经历了我们没有经历过的痛苦和我们无法忍耐的寂寞才换来的，很荣幸能够得到他分享这么宝贵的财富给我

为自己而工作！万幸，有这样的朋友！

2016

深入剖析ceilometer，在csdn上做专栏（写出值得10w访问量的博客）

熟悉至少一个以上的python web框架，django是其中一个

掌握关系型数据库mysql，非关系型数据库mongodb

独立完成不少于两个项目，属于自己的项目

把过去买的没看完的书全部吸收