运维二三事儿 1.运维二三事儿
运维也不知道从何说起，反正以解决问题，提前规划准备为终极目标，记录一下自己工作中有意思的、有教训的二三事儿....
2.配置局部化
我们在编程过程中都强调尽量少用全局变量，因为会带来很多的耦合问题，linux运维过程
中的环境配置也是一样。除非是系统的软件我们尽量全局配置，应用的配置尽量做到局部化。
linux本身是一个多用户系统，对配置的管理其实考虑得还是停周到的，有全局配置、用户配置、
当前目录配置等。但是我们的应用其特性呢。通常应用特定的的软件依赖用局部配置，即将程序放置
在启动脚本里面的，我的习惯是提供一个run.sh,kill.sh,环境的所有配置都尽量放置到该脚本中。
曾经因为开发员修改NLS_LANG导致个别应用乱码,后面查看发现是用户目录的配置的，导致。
曾经因为其他厂商实施人员修改/etc/profile导致时间同步服务失效。
- 配置的事情最好是交给维护人员来处理,开发人员再牛逼也不要随意调整,因为你没有他们熟悉环境
3.运维人员慎重对待你的操作环境
这个事情印象太深刻,我当时在做一个多进程调试,将当前活动进程数限制注释掉了,导致AIX主机的进程资源
立即耗完，root也无法登录.最后悲剧的重启。还好的是上面没有核心的业务，当时刚从学校毕业没有这种教训
认识不到位导致。
- 运维人都会干些蠢事儿，需要时刻保持清醒，不要随便在非测试环境测试，绝对不能报侥幸心里
4.kill进程需要小心
进程应该保存自己的ID，通过grep也不是安全的，这事儿还得从升级接口节点服务说起，当时
对程序名称做了加50代表5.0的字样，期间我们会不断的重启,ps -ef|grep xx获得进程重启。
一切都良好。但是我们后面发现生产环境会有挂掉重启的现象，观察也没有core文件,百思不得其解。
最后大家讨论后发现是50的自动重启脚本过滤有问题.
5.证明自己的清白
都说运维工程师是苦逼的，因为你要经常背黑锅，其实有些有些东西只要多加分析最后就可以
摘掉
5.1公司内部
在公司内部当然是会为研发背黑锅，和研发较量就看你的技术实力了，
因为毕竟东西是他们开发的。但是只要我们专研一下我们还是可以搞定的，因为没有人
比我们更了解实际需求和业务了，这个东西在稍微大一点的公司就会比较明显
因为他们这些研发离实际需求人客户太远了，我举一个例子：我们以前有一个很老
的项目一直没有推进，但是在这个过程中反馈给研发都是困难或者我们已经解决，
事实确是明白人一看就知道有问题，后来一方面因为客户压力另外也要告诉他们是可以的
所以自己开始去实现，最后当然研发就好说话了。
再一个：我们的项目是分布式加集群的架构，这样的架构好是好易于扩展还能够
好升级，但是存在一个问题延时，当然当我向研发反馈的时候他们也是不同意的，
坚信自己没有问题，这个时候如果我们对整个实现了解就好办了，我将各环节数据
延时一一记录监控，最后程现一个延时列表，后面的当然就知道了，哪个环节严重就
解决哪个环节。
- 所以运维具备开发能力是必须的饿，不说其他的，扯皮这种事情不会被糊弄
5.2公司外部
如果是面向客户服务的运维，会经常的需要和其他公司对接，因为客户的It环境
不会是一个公司搞定的，我们需要和其他公司撤，这个时候证明清白就很重要了，
因为关系到客户对我们产品的信任，其他厂商的认可度，如果处理不好会出现一旦出现这种链式环境
首先让你查查查，但是作为一名运维人自个儿应该第一时间排查，至少应该做到找上门儿来了
不会抓瞎，比如：做网络设备采集时，遇到采集没有响应，当时反馈给网络厂商，
回复是我们没有问题都是这样配置的，好吧没有问题我还能够出现不能访问，这个时候是需要
证明自己了，用第三方检测工具检测数据出来没有响应，好吧他们终于去排查了，要强调
这个时候一定要用第三方工具，大家都熟悉的。
6.运维人的沟通
7.业务运维干起了硬件网络配置
8.批量运维很爽,但请谨慎
9.快速搭建应用系统
10.数据爆增
今天XX给我反应后台程序有挤压，处理不过来，立即查看后台日志，相关参数，发现没有什么异常，参数也是我调整过的
是最优的，没有看出是那个地方的原因。但是能判定的就是肯定是那个地方有改动和异常，否则运行了半年的程序不可能
出问题。根据经验习惯的看了数据库的表空间使用情况。表空间显示使用率最高的也是87%，其实也不算高了，想来也不应该是这个地方的
问题。顿时还有点迷茫了。
抽根儿烟，思考思考。。。。
根据以往的经验，查看了表空间中的前10名的表大小，尼玛瞬间吓坏了，201601月单表居然有786G。
尼玛数据哪儿来的呢。。。
老大当然也过来一顿啪啪啪
于是首先开始排查后台5个环节。。没有查出问题。。
想来还是来看数据库多了什么数据。这个时候悲剧的是表太大，根本没法统计查询
想着从其他地方腾一点空间，
11.文件系统使用率过高要及时处理
- 逐级查看文件过大的文件夹，最后定位到要删除的文件
- 如果是暴增一定要和前几个周期的对比，观察是否有异样，是否是程序出了问题导致狂刷日志
15.1.5公交车