zoukankan      html  css  js  c++  java
  • 运维二三事儿

    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公交车

  • 相关阅读:
    Centos下Oracle11gR2安装教程与自动化配置脚本
    你知道CPU结构也会影响Redis性能吗?
    谈谈InnoDB中的B+树索引
    理论:第十一章:大厂程序员如何使用GitHub快速开发学习
    理论:第十四章:生产环境服务器变慢如何诊断,性能评估
    理论:第十三章:堆溢出,栈溢出的出现场景以及解决方案
    理论:第十二章:Dubbo的运行原理,支持什么协议,与SpringCould相比它为什么效率要高一些,Zookeeper底层原理
    理论:第十章:公平锁,非公平锁,可重入锁,递归锁,自旋锁,读写锁,悲观锁,乐观锁,行锁,表锁,死锁,分布式锁,线程同步锁分别是什么?
    理论:第九章:JVM内存模型,算法,垃圾回收器,调优,四大引用,常见的JVM错误,类加载机制(双亲委派),创建一个对象,这个对象在内存中是怎么分配的?
    理论:第八章:线程是什么,有几种实现方式,它们之间的区别是什么,线程池实现原理,JUC并发包,ThreadLocal与Lock和Synchronize区别
  • 原文地址:https://www.cnblogs.com/luomgf/p/4998918.html
Copyright © 2011-2022 走看看