随笔分类 - 运维成长全记录
主要是运维工作中的一系列思考
摘要：在某一次系统监控的讨论会议上，我随便提出了个问题：“如何定义一个系统？”，结果答案就五花八门起来了，会议也跑题了。
为什么问这个问题，是因为某些同事觉得某个系统比较大，就往下分为子系统、组件等，往上分业务群等。有时候仔细一看，什么业务群，明摆着就是一个大的系统而已。当然，我随便说说，我也没有对这个问题有明确的定义。我想说的就是，包括系统、组件、子系统等等，这些定义我们从来没想过——流程也是这样，区别是，我们想过，但是只是凑合着用而已，定义并不清晰。
这些属于那种只可意会不可言传的东西，这就导致外部公司常常将我们“以为”的一个系统拆分为多个系统进行收费……
当然，这个问题至今仍为明确，我提出过，但是大家都认为没必要搞清楚这个问题。
阅读全文
posted @ 2014-06-18 13:26
摘要：相比PPT中被管的数个对象（像培训什么的也都在其中），我们的需求其实就要小得多，但是问题在于流程依然不清，责任依然不明。
由于近期需要解决的CMDB中的相关问题，所以着重看了下PPT中对应的部分，其他的部分慢慢研究。
看了破子的这个PPT，之前有一些迷惑的地方才清晰起来，比如属性集。
阅读全文
posted @ 2014-06-17 08:07
摘要：估计大家看到破子的这两篇都有点晕哈，我也有点晕。
两篇对比来看。
第1处，属性部分新增了动态的内容。这也是我一直考虑的问题——毕竟咱是搞监控多年，监控的数据是否存放在CMDB中也考虑了很久。因为CMDB使用的更多应当是当前状态，如果要记录性能数据的话就需要记录历史情况，这样感觉将CMDB与监控打包在一起了。我这里还是只是提供接口，CMDB可以调用。再者，CMDB有这些属性，也必须有数据来源才行。因此，接口的引入确保有监控就有动态数据，没监控就没动态数据。
阅读全文
posted @ 2014-06-16 14:02
摘要：分类的问题上比较有感悟。在之前编写新版的CMDB模型的时候，曾将刀片机、x86服务器、小型机等统一归为服务器，通过架构和机箱（刀片、机架、立式，好像是这三种）区分。由于使用的是SD，而且到我那一期时字段剩余的不多，为了方便统计和展示，才出此下策——不过当时感觉很好哈，终于一统天下了，不过也是无奈的选择。
如果分类在存储和展示上都能够自定义而且有足够的空间的话，确实如破子所说，分类是不应该吝啬的。
很好奇破子公司所用的CMDB里面的数据结构是怎么设计的，我近期在这个方面上一直存在问题，总是担心过于灵活的话会影响到性能，毕竟最终使用起来上万条记录的相互关联和查找还是会很费数据库性能的。
阅读全文
posted @ 2014-06-15 12:26
摘要：虽然之前也思考过当运维底层都被替换为云时，现有的传统运维可能就消失了，其所依赖的ITIL是不是也会消失。但是个人认为这些担心是多余的。
阅读全文
posted @ 2014-06-10 09:59
摘要：由于，基本已经完成一期的功能开发，所以要继续CMDB的开发工作了。
最近看了不少CMDB相关的文章，也思考了不少，后面将所思所想（比较浅）记录一下。
发现很多内容都记录在Wiz上，抽空整理到博客中。
阅读全文
posted @ 2014-06-10 09:36
摘要：可用性统计系统开发完成了，在测试环境测试中，计划过1~2月迁移到正式环境中。
其实这个系统还是比较简单的，但是需求收集的过程中大家都比较急躁——我指的是所有人，包括我：
1、被领导的敏捷思想忽悠的……迭代性的需求细化使大家不适应，虽然我已经尽可能减少这种影响了；
2、内部项目经验为零，对外的项目经验其实大家都有，但是对内的……需求都要满足的这种，哪些一期实现，哪些二期实现实在难以抉择；
3、除了开发和测试，项目的其他人都有别的工作要做，而且短期内都是优先级较高的……
阅读全文
posted @ 2014-06-10 09:32
摘要：看不清，依然看不清问题的实质。
个人认为，缺乏解决问题和协调问题处理能力的，其实就没必要当领导了。
不然只是白拿工资浪费公司资源。
阅读全文
posted @ 2013-11-18 07:31
|
||
浙公网安备 33010602011771号