运维工作经验汇总———高级运维工程师运维南宫乘风-Linux运维-虚拟化容器-Java-

目录

第一章 初入公司

第2章 第一阶段：解决物理服务器单电问题

第3章 第二阶段：解决服务器虚拟化问题

第4章 第三阶段：数据库备份

第5章 第四阶段：解决数据库单点

第6章 第五阶段：完善监控项

第7章 第六阶段：统一服务的安装方式

第8章 第七阶段：关键服务 NFS 迁移备份

第9章 第八阶段：服务拆分-用户和爬虫流量分离-ELK 日志收集

第10章 第九阶段：增加第二机房-大数据服务

完整架构图

整体结构演变

第一章 初入公司

1.1 架构拓扑图

1.2 存在的问题汇总

• 1.物理服务器电源单电，机房电力切割时需要关闭所有服务器，导致服务中断 4-6 小时
• 2.物理服务器配置不当，有的服务器系统盘用 SSD，数据盘反而用机械盘
• 3.服务器虚拟化 ESXi 上的虚拟机经常无故变成系统只读导致服务不可用
• 4.操作系统不统一，有 debian，有 FreeBSD
• 5.数据库单点，且没有备份以及恢复计划
• 6.keepalived 配置错误导致 HA 高可用没有生效
• 7.重要的 NFS 服务器 5T 的数据没有备份，且操作系统为 FreeBSD
• 8.zabbix 监控项过多，报警内容太多，关键报警被淹没
• 9.软件部署方式不统一，有编译/脚本/tar 包/deb 包多种安装方式
• 10.脚本不统一，脚本随处存放，命名混乱，很多不知道有没有用
• 11.没有批量操作工具，依靠纯手工或脚本操作

第2章 第一阶段：解决物理服务器单电问题

2.1 问题现象

1.物理服务器电源单模块，如果机房进行电力切割，必须关闭所有服务器，等机房电力切割结束再把所有服务器开机

2.2 导致后果

1.电力切割期间所有的业务完全中断，用户在此期间无法访问
2.服务没有做开机自启动，重新开机之后需要手动起服务
3.因为服务器老旧，关机之后可能起不来
4.因为关机时暴力 kill 了服务，导致服务器重启后数据损坏

2.3 解决方案

1.因为服务器型号老旧，厂商已经停产，买不到新电源
2.退而求次，淘宝联系卖二手服务器的卖家，购买服务器相同型号的电源
3.服务器电源属于热插拔，可以直接插上测试
4.验收方法为：
– 两个电源模块都插上电，然后拔掉第一个电源模块，查看服务器有没有重启。
– 如果服务器没有重启，再全部插上电源，然后再拔掉另一个电源，查看有没有重启
– 如果都没有重启，就证明服务器双电模块运行正常

2.4 价值体现

1.由原来业务需要中断 4-6 小时缩短为 0 中断
2.给公司减少了由于业务中断导致的经济损失
3.运维再也不用在机房通宵熬夜等待电力切割了

第3章 第二阶段：解决服务器虚拟化问题

3.1 问题现象

1.服务器虚拟化采用的是 VMware ESXi 虚拟化平台，运行的虚拟机经常无故的系统变成只读，导致服务中断

3.2 导致后果

1.虚拟机运行的服务不可用，导致业务中断，影响用户体验

3.3 解决方案

1.找台新服务器安装部署新版本的 ESXi,安装 VCenter 管理中心
2.迁移旧服务到新服务器
3.持续观察检验

3.4 价值体现

1.新版本虚拟机运行稳定，业务不会中断
2.服务器虚拟化充分利用了硬件资源，为公司节省了购买 3 台物理服务器的价格

第4章 第三阶段：数据库备份

4.1 问题现象

1.mysql 数据库只有一台主从，没有备份
2.redis 和 mongo 单点，且没有备份
3.数据库服务器数据盘均为单块 SSD 固态硬盘，一旦损坏没有修复的希望

4.2 导致后果

1.如果数据库服务器硬件或者硬盘损坏，没有数据可以提供恢复，后果不堪设想

4.3 解决方案

1.这个阶段重点是先备份数据
2.新增加一个 mysql 从库，使用 xtrabackup 在从库上每天定时备份数据
3.新增加一个 redis 从库，每天物理备份 redis 持久化的 RDB 文件
4.新增加一个 mongo 从库，每天使用 mongodump 导出数据

4.4 价值体现

1.在服务器有限和时间有限的情况下，按照紧急度优先解决数据库备份
2.降低了因为物理服务器损坏或者人为操作失误导致的数据灾难性丢失情况
3.为下一步数据库服务集群化提供了基础保障

4.5 拓扑图

第5章 第四阶段：解决数据库单点

5.1 问题现象

1.数据库故障到完全修复过程中，业务会中断，用户不能访问

5.2 导致后果

1.虽然已经做了数据库备份，但是一旦数据库损坏，恢复起来依然需要很多时间
2.由于业务代码写死了 IP 地址，一旦数据库损坏，在其他机器上恢复了，业务代码也需要变更 IP 地
址，重新发布，耗时太长

5.3 解决方案

1.对目前单点数据库升级到集群架构
2.新增加 mysql 从库。
3.redis 由单节点升级为 redis cluster 集群
4.mongo 由主从复制升级为 3 节点副本集
5.新部署 elasticsearch 服务集群

5.4 实施难点

1.对于运维来说，安装部署不复杂，但是难题在于由于数据库架构升级，从而导致业务代码连接方
式发生改变
2.因为现在的业务代码都是采用框架开发，所以很多数据库插件需要升级，比如 redis 和 mongo 都需
要升级插件才能支持集群化连接
3.需要提前在开发环境搭建部署好。然后开发测试没有问题之后，再采用轮训升级的方式逐步升级
升级数据库以及代码框架

5.5 价值体现

1.对数据库的稳定性以及安全性有了质的改变
2.由于数据库集群化，性能得到了大大的提升，用户打开网站访问速度更好，体验更好
3.由于数据库集群化，提供了冗余，所以即使服务器损坏或者维护也不会影响架构改变，用户访问
也不会中断
4.减少了因为数据库宕机或恢复导致的经济损失

5.6 拓扑图

第6章 第五阶段：完善监控项

6.1 问题现象

1.监控项报警内容太多，有时候几分钟上百条

6.2 导致后果

1.关键的报警信息被不重要的报警淹没，以至于不能第一时间发现关键问题
2.由于报警监控项配置不当，导致连锁反应，牵动很多不需要的警告
3.由于短时间大量的报警产生，对 zabbix 服务器造成很大压力，甚至导致 zabbix 服务宕机
4.如果配置了短信报警，那么大量的非关键报警导致消耗很多短信条目，很花钱！

6.3 解决方案

1.优化报警内容，只监控必须要监控的，模版自带的一些不需要的监控项停掉
2.报警分级，将报警信息按紧急度拆分，所有报警都发邮件，紧急的报警追加发送到微信
3.取消短信报警，改为邮件和微信报警
4.报警内容优化，尽量看标题就能知道报警内容是什么

6.4 价值体现

1.接受的报警量大大减少，运维的注意力可以更集中在关键的问题处理上
2.通过不同的发送介质第一时间了解问题的紧急度，比如发送到微信上的都是需要立刻处理的
3.取消短信报警为公司节省开销

第7章 第六阶段：统一服务的安装方式

7.1 问题现象

1.服务安装混乱，有脚本安装，有 tar 包安装，有 deb 包安装，有编译安装
2.软件存放目录不统一，数据存放目录不统一，脚本存放目录不统一
3.防火墙规则不统一，有一些不用的规则没有清理

7.2 导致后果

1.一些操作无法进行批量执行
2.安装服务基本需要手动操作
3.文档缺失，不知道以前怎么装的，不知道以前配了什么参数
4.防火墙规则混乱，有一些已经不用的服务，但是规则没有删除，看起来很乱

7.3 解决方案

1.引入 ansible 批量管理工具，统一服务安装方式，新服务统一使用 playbook 安装
2.统一服务安装目录，数据目录，日志目录
3.清理防火墙不用的规则，只保留必须的规则
4.编写运维文档，制定运维规范

7.4 价值体现

1.新服务安装部署由原来的按小时缩短为分钟级别，提高了运维效率
2.避免了因为手动操作敲错命令导致的不可预料后果，实现了一次编写重复运行
3.编写运维文档，为部门同事和公司留下可持续的价值输出

第8章 第七阶段：关键服务 NFS 迁移备份

8.1 问题现象

1.公司成立以来所有的图片数据都保存在一台安装 FreeBSD 操作系统的老旧服务器上且没有备份

8.2 导致后果

1.NFS 服务器的数据高达 5T，且没有备份，一旦服务器或硬盘损坏，后果不堪设想
2.由于 FreeBSD 操作系统的原因，没有办法使用 sersync 来进行实时同步备份
3.一旦服务器发生损坏，所有业务网站的图片服务都将失效，短时间没有替代方案

8.3 解决方案

1.虽然 FreeBSD 系统不能使用 sersync，但是可以使用 rsync
2.找一台性能足够服务器，使用四块 6T 磁盘制作 RAID10，安装部署 rsync 服务端和 NFS 服务端
3.分目录进行同步，总目录数据量太大，同步起来时间按天算，拆分成一个个小目录分批进行同步
4.统计记录每次同步的时间，最高在半夜业务低峰期进行同步
5.和开发沟通切换方案，开发修改代码，用户上传数据同时往 2 台服务器上写入，保证数据一致性
6.业务低峰期进行切换，在前端代理轮流更新 WEB 服务器的卸载旧 NFS，然后重新挂载新 NFS
7.修改个别权限不对的目录。测试所有上传业务是否可以正常的写入
8.为了防止意料不到的意外情况，旧服务器数据继续保留 1 个月。确定一切正常之后重做旧服务器
9.然后使用 sersync 同步数据到新服务器，持续观察，保证同步正常工作

8.4 价值体现

1.在业务不中断，数据不丢失的情况下为公司的宝贵资产提供了可靠的备份方案
2.烫手的山芋在运维手里得到了解决，荣誉感，成就感大增
3.在公司领导和同事心中留下了可靠可信赖的印象

8.5 拓扑图

第9章 第八阶段：服务拆分-用户和爬虫流量分离-ELK 日志收集

9.1 问题现象

1.因为公司有论坛，需要爬虫来爬取
2.但是爬虫的流量和用户的流量混合在了一起，且没有统一的日志管理平台查看过滤

9.2 导致后果

1.由于流量没有分离，导致当有大量的爬虫访问的时候，对服务器和数据库造成非常大的压力
2.当爬虫访问频次过高时，会导致数据库连接数变多，系统负载变高，影响用户正常服务
3.同样，由于爬虫流量和用户流量混在了一起，没有很好的办法分析压力高的原因
4.开发或者运营想看一些日志数据只能找运维解决，每次分析都要花很久，分析脚本没有办法复用

9.3 解决方案

1.新增加一台 WEB 服务器专门给爬虫使用，页面做静态化，优化爬虫抓去效率
2.数据库读写分离，爬虫抓取如果需要查询数据库，把流量指向没有业务访问的从库
3.前端代理根据访问的请求报文里的 user-agent 来分离爬虫和用户的访问流量，如果是爬虫就把流量引到给爬虫抓取的 WEB 服务器上，用户正常的流量还是正常访问 WEB 集群。
4.搭建部署 ELK 日志收集平台，集中收集所有 Nginx 访问日志，使用 kibana 作为过滤搜索和展示，
制作好用户展示数据的图表，培训部门同事 ELK 的使用和查询方法

9.4 价值体现

1.将用户和爬虫流量分离，当爬虫大量访问时候正常用户访问也不会受到影响，用户体验大大提升
2.搭建部署了 ELK 日志分析平台，方便部门同事查询数据，定位故障时间大大地缩减，大大提高了工作效率

9.5 拓扑图

第10章 第九阶段：增加第二机房-大数据服务

10.1 项目需求

1.业务发展，需要部署 Hadoop 平台和 kafka+zookeeper 服务
2.由于 IDC 机房只有一个机架，所以需要在第二机房部署

10.2 价值体现

1.测试环境测试没问题后使用 ansible 批量部署到新的大数据服务器，节省了部署时间
2.大数据服务可以更好的分析用户访问行为，根据分析结果可以更精确的给用户推送推荐内容

10.3 拓扑图

完整架构图

整体结构演变