|
06 2014 档案
摘要：首先，这本书是Linux.CN赠送的，多谢啦~先贴一下当时读样章时的感想：
在阅读前言时，还以为这是一本专注于带领开发人员学习Linux系统运维的书籍，后来发现正文内容以排除故障的通用手段为切入点，进而引申到Linux系统各类系统故障的排除的具体方式。这些内容不仅可以引导开发人员进入DevOps的大门，更可以修正运维人员的排障方式和方法，还可以作为新手学习的入门参考。
阅读全文
posted @ 2014-06-29 14:52
摘要：整理邮件时，发现了一封很有意思的邮件——《关于三线支持力度的考核指标讨论》。
解释下，公司是一个IT服务公司，有运维有开发，但是这里的一线一般指客户服务，直接与客户打交道的那块；二线指系统运维，也就是苦逼的运维攻城狮；三线可不仅仅是程序猿了，还包括外部厂商——也就是我们运维系统的软硬件厂商。大概是这么个结构。
阅读全文
posted @ 2014-06-24 13:54
摘要：东西都上传到这里了：
https://github.com/RexKang/Zabbix/tree/master/OS/Linux-disk-discovery
需要用到的东西：
Zabbix的LLD：https://www.zabbix.com/documentation/2.0/manual/discovery/low_level_discovery
Zabbix的Agent配置：https://www.zabbix.com/documentation/2.0/manual/appendix/config/zabbix_agentd
iostat的使用：http://www.cnblogs.com/peida/archive/2012/12/28/2837345.html
阅读全文
posted @ 2014-06-19 12:59
摘要：在某一次系统监控的讨论会议上，我随便提出了个问题：“如何定义一个系统？”，结果答案就五花八门起来了，会议也跑题了。
为什么问这个问题，是因为某些同事觉得某个系统比较大，就往下分为子系统、组件等，往上分业务群等。有时候仔细一看，什么业务群，明摆着就是一个大的系统而已。当然，我随便说说，我也没有对这个问题有明确的定义。我想说的就是，包括系统、组件、子系统等等，这些定义我们从来没想过——流程也是这样，区别是，我们想过，但是只是凑合着用而已，定义并不清晰。
这些属于那种只可意会不可言传的东西，这就导致外部公司常常将我们“以为”的一个系统拆分为多个系统进行收费……
当然，这个问题至今仍为明确，我提出过，但是大家都认为没必要搞清楚这个问题。
阅读全文
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
摘要：燥热的天
海南的六月实在是让人受不了。我好像从3月份就开始开空调了。
进入6月依赖，海南的气温基本上保持在30度以上，那种潮热的感觉，真令人受不了。
每天早上0700到公司，下午1830离开公司，依然感觉到非常的热，全身出汗~
以脑袋为出汗中心的方式真令人受不了，如同淋浴一般，经常被人称作为“汗族人”……
浮躁的心
想要招聘一个符合需求的员工，三个月的试用期里真得做些什么，考察其综合素质——之前这部分有些欠缺，所以，不合适的人待在了不合适的岗位上。
如同大家连聊的时候所说到的，历届应届生中，只有07年的前后2届比较靠谱，其余的应届生大部分用三个词来描述，就是自视甚高、过于浮躁。
一口往往吃不成胖子，填鸭还得有个过程。
内部培训确实存在问题，培训的缺失、不充分无法使员工个人技能短期内满足工作要求，从而增加了其心理压力，长期的落差必然导致员工个人对所处个环境或个人产生疑惑（至于到底是环境还是个人，目前来看，取决于员工喜欢将问题归咎于哪一方）。最后再加上海南这潮热的天气，最终产生人员流动的问题。
阅读全文
posted @ 2014-06-12 09:18
摘要：之前在Zabbix的监控项目中，看到了perf_counter中有以数字化来表示项目，好奇之余，查其缘由。
Zabbix官网上也有相关的介绍~
https://www.zabbix.com/documentation/2.0/manual/config/items/perfcounters
阅读全文
posted @ 2014-06-12 08:22
摘要：默认Zabbix运行的账户是Zabbix，但在自动部署的时候，Agent与Server的先后顺序不定，而且官方不建议两者使用同一个账户。
阅读全文
posted @ 2014-06-11 10:18
摘要：虽然之前也思考过当运维底层都被替换为云时，现有的传统运维可能就消失了，其所依赖的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
|
|
浙公网安备 33010602011771号