-
之前做了部分nginx qos分析和cdn日志qos分析计算程序开发的工作，涉及到对实时的和离线的nginx 日志的qos计算。不管是研发也好，运维也好，都需要关心自己负责的domain的qos情况，以此来判断业务的运行情况，容量情况，是否需要扩容，以及验证应用的变更是否影响用户访问等等。 最常见的比如对nginx code的分析，比如计算域名的访问量，可用性（2xx+3
-
今天在一台机器上查看java进行时，运行jps -m时报如下错误：Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.但其实服务器的内存是充足的：free -m
-
之前在impala集成kerberos时，遇到了时间相关的问题，当时没有做充分的测试，对某些理解有些问题（http://caiguangguang.blog.51cto.com/1652935/1381323），今天正好做了下测试，总结如下：1.klist中expires以及renew until是由client端的/etc/krb5.conf配置文件中的参数决定（在没有超过max的情况）。ser
-
昨天老毕跟我讨论dns的问题，今天想了想，其实实际在生产环境中用到的dns大体有3种：1.内网调用DNS 一般是每个机房一组，做ms结构，主要功能是供机房内部应用之间调用解析，减少对hosts的依赖，避免硬编码。一般ms结构就可以了，不太会做其他的高可用。2.回源调用dns 和内网调用dns功能差不多，不过这个是跨机房的调用，而且一般会通过view做智能dns
-
之前负责过公司webcdn相关的设计和维护工作，同时做了些应用运维方面的工作,简单谈几个我对接触过的几款负载均衡器的了解。
-
线上使用自己开发的url monitor工具进行应用层面的监控，主要的原理使用nagios驱动pycurl做url的检测，url的检测属性（ip,port,url,httpcode等）是放在数据库里面的。对于http code的监控，当获取的http code和期望的http code不一致时，产生报警邮件。最近发现在报警邮件中，有显示current http code是200，但是
-
在做软件包管理时，如果把常用的包做成rpm的形式，然后集成到自己的yum源中，并配合puppet的package资源，可以很方便的进行自动化的操作。附一个简单spec文件，下载下来改改就可以使用：%define src_version Vipshop-Webcdn-Tengine-1.0.0
%define release 1
Name:
-
简单地说下自己对自动化的理解：首先说自动化的几个组件：1.装机自动化，软件部署和配置管理自动化主要是实现服务器系统的快速build,软件的部署和相关配置的管理，比如nginx,java,php的部署和配置分发，更新，其中也包括操作系统相关配置的标准化，比如sysctl.conf，limits.conf等。2.代码发布的自动化用于程序的自动发布，需要的几天功能，灰度发布和回滚的功能3.报警处理的自动
-
在工作中或多或少接触过部分监控工具的构建，开发和完善。结合自己的一些看法，简单地谈下一个完整的监控系统所包含的组件，欢迎大家补充。从监控的层面来看，一个比较完整的监控系统应该包含如下的层次：1.网络层面主要包含各个机房间网络状况，机房内机器网络状况，通过开源的工具smokeping可以做到2.主机层面对于网络设备来说，包括cpu,内存，端口速率，流量等对于服务器来说，从硬件到系统层面都要进行完善的
-
这几天有人问我dns使用协议的问题，之前只知道大概的一个情况，为了详细了解下，google并进行了测试，做下总结：首先dns是使用tcp + udp的。使用tcp的场景：1.区域复制2.解析返回结果比较大的时候（udp报文内容超过512字节时）3.rndc 管理dns4.udp端口不能返回解析，重新使用tcp请求解析（这个和dns的版本有关，bind9是不行的）使用udp的场景：用户解析访问。为什
-
网上看到有人写了一篇文章，关于一个合格的运维工程师应该具体哪些素质，正好前段时间有位boss也问过我这个问题。简单地写下自己的看法。。1.良好的责任心ops是直接面向生成环境的一线操作人员，任何一个不当的操作都有可能引起故障，要本着对用户负责的态度做好每一次变更。在出现故障时也要勇于承担责任而不是千方百计想着怎样掩盖自己的过失，犯错误不可怕，可怕的是犯了错误后不知反思，不去思考该如何避免。很多变更
-
最近运维部一直在倡导”精细化运维”，到底什么是精细化运维呢？精细化运维是在运维标准化、自动化、服务化做到一定程度后，建立在对系统对应用有较深入了解，并且进行日志收集详细分析的前提下，有点运维数据挖掘的意思.
就我个人感觉，其实”精细化运维”无外乎两个字，”精”和&rdq
-
公司大概有5000+以上的服务器节点，包括各种应用,我和同事共同维护大约2500+的服务器，主要包括一些视频cdn，直播视频cdn,webcdn和p2p服务器。以下是自己在运维工作中的一点经验和看法，希望对大家有所帮助 1.服务器型号的区分，为以后的统一化和标准化作硬件上的准备，很多人忽视这一点，其实如果这一点做得好会使后面的运维工作轻松很多，根据应用我们主要把服务器分为3中，cpu
菜菜光
分享到朋友圈
- 关注技术：Mysql 大数据 系统集成
- 入住博客：2010-05-28 10.8年
