运维是什么?

188 阅读6分钟

工作究竟是什么?

工作内容:维护服务器
学习路径:

  1. linux虚拟机 gui到cli shell编程
  2. 稍微看看主流的几门语言
  3. 再接触监控 虚拟化 集群 docker podman
  4. 最后就是自动化

方向:

  • Linux
  • 云计算

方向优点:

  • 薪资也不低了
  • 技术淘汰速度慢
  • 从业压力比较小(不知道对不对...朋友都说工作内容很杂)

要求:

  • 稳定!
  • 备份!
  • 保密!

安全相关:

  1. ssh

更改默认端口(当然如果专业要黑你,扫描下就出来了)

禁止root登录

使用普通用户+key认证+sudo规则+ip地址+用户限制

使用hostdeny类似的防爆里破解软件(超过几次尝试直接拉黑)

筛选/etc/passwd中login的用户

  1. 防火墙

防火墙生产环境一定要开,并且要遵循最小原则,drop所有,然后放行需要的服务端口。

3.精细权限和控制粒度

能使用普通用户启动的服务坚决不使用root,把各种服务权限控制到最低,控制粒度要精细。

4.入侵检测和日志监控

使用第三方软件,时刻检测系统关键文件以及各种服务配置文件的改动

比如,/etc/passwd,/etc/my.cnf,/etc/httpd/con/httpd.con等;

使用集中化的日志监控体系,监控/var/log/secure,/etc/log/message,ftp上传下载文件等报警错误日志;

另外针对端口扫描,也可以使用一些第三方软件,发现被扫描就直接拉入host.deny。这些信息对于系统被入侵后排错很有帮助。有人说过,一个公司在安全投入的成本跟他被安全攻击损失的成本成正比,安全是一个很大的话题

也是一个很基础的工作,把基础做好了,就能相当的提高系统安全性,其他的就是安全高手做的了

日常监控

1.系统运行监控

好多人踏入运维都是从监控做起,大的公司一般都有专业24小时监控运维。系统运行监控一般包括硬件占用率

常见的有,内存,硬盘,cpu,网卡,os包括登录监控,系统关键文件监控

定期的监控可以预测出硬件损坏的概率,并且给调优带来很实用的功能

2.服务运行监控

服务监控一般就是各种应用,web,db,lvs等,这一般都是监控一些指标

在系统出现性能瓶颈的时候就能很快发现并解决。

3.日志监控

这里的日志监控跟安全的日志监控类似,但这里一般都是硬件,os,应用程序的报错和警报信息

监控在系统稳定运行的时候确实没啥用,但是一旦出现问题,你又没做监控,就会很被动了

性能调优

1.深入了解运行机制

其实按一年多的运维经验来说,谈调优根本就是纸上谈兵,但是我只是想简单总结下,如果有更深入的了解,我会更新。在对软件进行优化之前,比如要深入了解一个软件的运行机制,比如nginx和apache,大家都说nginx快,那就必须知道nginx为什么快,利用什么原理,处理请求比apache,并且要能跟别人用浅显易懂的话说出来,必要的时候还要能看懂源代码,否则一切以参数为调优对象的文档都是瞎谈。

2.调优框架以及先后

熟悉了底层运行机制,就要有调优的框架和先后顺序,比如数据库出现瓶颈,好多人直接就去更改数据库的配置文件,我的建议是,先根据瓶颈去分析,查看日志,写出来调优方向,然后再入手,并且数据库服务器调优应该是最后一步,最先的应该是硬件和操作系统,现在的数据库服务器都是在各种测试之后才会发布的

适用于所有操作系统,不应该先从他入手。

3.每次只调一个参数

每次只调一个参数,这个相比大家都了解,调的多了,你就自己就迷糊了。

4.基准测试

判断调优是否有用,和测试一个新版本软件的稳定性和性能等方面,就必须要基准测试了,测试要涉及很多因素

测试是否接近业务真实需求这要看测试人的经验了,相关资料大家可以参考《高性能mysql》第三版相当的好

我的老师曾说过,没有放之四海皆准的参数,任何参数更改任何调优都必须符合业务场景

所以不要再谷歌什么什么调优了,对你的提升和业务环境的改善没有长久作用

运维心态

1.控制心态

很多rm -rf /data都在下班的前几分钟,都在烦躁的高峰,那么你还不打算控制下你的心态么

有人说了,烦躁也要上班,可是你可以在烦躁的时候尽量避免处理关键数据环境

越是有压力,越要冷静,不然会损失更多。

大多人都有rm -rf /data/mysql的经历,发现删除之后,那种心情你可以想象一下,可是如果没有备份,你急又有什么用,一般这种情况下,你就要冷静想下最坏打算了,对于mysql来说,删除了物理文件,一部分表还会存在内存中,所以断开业务,但是不要关闭mysql数据库,这对恢复很有帮助,并使用dd复制硬盘,然后你再进行恢复

当然了大多时候你就只能找数据恢复公司了。

试想一下,数据被删了,你各种操作,关闭数据库,然后修复,不但有可能覆盖文件,还找不到内存中的表了。

2.对数据负责

生产环境不是儿戏,数据库也不是儿戏,一定要对数据负责。不备份的后果是非常严重的。

3.追根究底

很多运维人员比较忙,遇到问题解决就不会再管了,记得去年一个客户的网站老是打不开,经过php代码报错

发现是session和whos_online损坏,前任运维是通过repair修复的,我就也这样修复了,但是过了几个小时,又出现了

反复三四次之后,我就去谷歌数据库表莫名损坏原因:一是myisam的bug,二是mysqlbug,三是mysql在写入过程中

被kill,最后发现是内存不够用,导致OOM kill了mysqld进程

并且没有swap分区,后台监控内存是够用的,最后升级物理内存解决。

4.测试和生产环境

在重要操作之前一定要看自己所在的机器,尽量避免多开窗口。