今天的一些感悟

我做事情还是喜欢追求速度，当然某种程度上速度和效率是成正比的，不全是。与效率相比，我更关注的是如何把一件事情做得更好，如果只是皮毛，那么这件事情的意义本身就不是很大。

有时候感觉要把技术全部写出来还是有点难度，要迭代的东西太多，想法太多，一点一点实现自己吹的牛，其实想想还是蛮有意思的。

比如一天的事情自己就做了以下的事情。

1.安装了MongoDB 3.2, 4.0的数据库并初始化

2.配置了开源项目Themis

3.配置了开源项目OpsManage

4.梳理了CMDB的使用原则

5.开发了后端系统的看板，对系统使用率做了统计和分析

6.配置管理Channels

除此之外还包括至少另外5件工作方向和工作之外的事情，比如帮助网友处理RMAN的问题，协调沙龙的事宜。。。。

看起来一团乱麻，我挑几件事情来说下自己的感悟吧。

昨天睡觉前看群友提了下Themis,突然想起来这个项目，和设计者韩锋老师还是好朋友，简单聊了下之后，我决定做个吸星大法，把审核里的核心思想抽取出来。从11点多到忙到凌晨1点多，最后卡在了MongoDB上面，白天经过了好几波的调试，还是没有搞定，最后在下班后再摸索一次，总算可以打开一个基本的页面了。

下午的时候突然想起来OpsManage这个项目最近多了不少的好点子，就开始准备环境，借鉴点灵感。这个版本的更新确实有了很多的新特性，有一个难点的地方是Channels的部署，在里面用到了Twitered项目，pip install channels的时候总是因为Twitered因为我是带着问题而来，所以整个借鉴的过程中，大脑里就像在菜市场里买菜一样，这儿点点，那儿看看，然后把一些好的点子记下来。

下午的时候和同事聊了下关于CMDB的一些设计原则，我分了四个维度来说明，首先是查询，这个毫无疑问是必须，不用多解释。而除此之外，还有三个维度，数据变更，数据删除，数据写入。元数据写入的工作主要是一个自动完成的过程，除此之外可以提供批量的数据导入，总体来说，数据通道应该是一个统一的入口。数据变更分为两种方案，一种是元数据属性发生变化，我们直接删除，然后重新插入，要么是我们记录数据的变更细则，在这两种方案中，第二种相对会更好，我们在设计表的时候需要两个字段，create_time记录创建时间，update_time记录变更时间，根据这两个维度我们可以辨识出数据的变化情况，而对于数据删除来说，我们要秉承的就是数据不删除原则，我们可以对数据加入一些状态属性，对外的显示是有效状态，比如一台服务器，上面有很多的硬件配件，对于服务器来说，SN不发生变化，而如果发生了硬件变更，那么这个动作应该是一个业务流程触发，对于硬件配件的变更应该保留历史，这样我们后续就可以很方便的统计出硬件变更历史。

管理的艺术，其实很多人到了一定段位都会碰到。怎么样的管理是好的管理方式，有一道教科书式的题目。

有三个士兵偷溜出去玩，兵营的门禁是晚上10点，现在已是9点9分，他们离兵营12公里。若要跑步回去要1小时30分，其中有一个士兵有一辆脚踏车，可同时坐两个人，骑到营区要30分钟。他们可能在门禁之前回到兵营吗？

当然答案其实也不难，我简单阐述一下结果：

士兵1: 骑车 20分钟 走回去 30分钟，一共50分钟

士兵2:骑车20分钟 折回去 10分钟 和士兵3骑车回去 20分钟 一共50分钟

士兵3:走 30分钟等待士兵2来接 一起回去 20分钟 一共50分钟

其实这个过程会发现三个士兵的时间使用是非常平均的，管理的艺术也在于此。