运维的运维工程师使用的平台、工具

Posted 2023-04-22

运维工程师使用的运维平台和工具包括： Web服务器：apache、tomcat、nginx、lighttpd 监控：nagios、ganglia、cacti、zabbix 自动部署：ansible、sshpt 配置管理：puppet、cfengine 负载均衡：lvs、haproxy 传输工具：scribe、flume 备份工具：rsync、wget 数据库：mysql、oracle、sqlserver 分布式平台：hdfs、mapreduce、spark、storm、hive 分布式数据库：hbase、cassandra、redis、MongoDB 容器：lxc、docker 虚拟化：openstack、xen、kvm 安全：kerberos、selinux、acl、iptables 问题追查：netstat、top、tcpdump、last 广义上所有开源的软件都是运维工程师会使用到的平台和工具，同时也包括运维各个技术方向上自行研发的各类平台。

参考技术A Linux运维人员必备的实用工具：
1、Nethogs：查询进程占用带宽情况
Nethogs是一个终端下的网络流量监控工具，它的特别之处在于可以显示每个进程的带宽占用情况，这样可以更直观获取网络使用情况，它支持IPv4和IPV6协议、支持本地网卡及ppp链接。
2、IOZone：硬盘读取性能测试
IOZone是一款Linux文件系统性能测试工具，可以测试不同的操作系统文件系统的读写性能。
3、IOTop：实时监控磁盘IO
IOTop命令是一个用来监控磁盘IO使用状况的TOP类工具。IOTop具有与top类似的UI，其中包括PID、用户、I/O、进程等相关信息。Linux下的IO统计工具如iostat，nmon等大多数只能统计到per设备的读写情况，如果你想知道每个进程是如何使用IO的就比较麻烦，而使用iotop命令可以很方便的查看。
4、IPtraf：网络流量监控
IPtraf是一个网络监控工具，功能比nload更强大，可以监控所有的流量，ip流量，按协议分的流量，还可以设置过滤器等。
5、IFTop：网络流量监控
IFTop是类似于Linux下面top的实时流量监控工具。iftop可以用来监控网卡的实时流量(可以指定网段)、反向解析IP、显示端口信息等。
6、HTop：进程实时监控
HTop是一个Linux下的交互式的进程浏览器，可以用来替换Linux下的TOP命令。
7、NMON：系统资源监控
Nigel's Monitor简称nmon，是由Nigel Griffiths开发的监控Linux系统性能的常用工具。通过nmon可以获取的信息有：处理器利用率、内存利用率、运行队列信息、磁盘I/O统计和网络I/O统计、进程指标等。
8、MultiTail：监控多个日志
MultiTail是个用来实现同时监控多个文档、类似tail命令功能的软件。他和tail的区别就是他会在控制台中打开多个窗口，这样使同时监控多个日志文档成为可能。
9、Tmux：连接会话终端持续化
Tmux是一个优秀的终端复用软件类似GNU Screen，比Screen更加方面、灵活和高效。为了确保连接SSH时掉线不影响任务运行。
10、NMap：安全扫描工具
Nmap，也就是Network Mapper，最早是Linux下的网络扫描和嗅探工具包。nmap是一个网络连接端扫描软件，用来扫描网上电脑开放的网络连接端。确定哪些服务运行在哪些连接端，并且推断计算机运行哪个操作系统。它是网络管理员必用的软件之一，以及用以评估网络系统安全。

我在网易云信是如何做运维的

先介绍下网易云信运维工程师的主要职责，包括但不限于软硬件部署、网络管理、应用代码维护、安全漏洞修复、容量规划、故障处理、性能优化等。

云信的运维工程师们很相信一个神圣的定律——墨菲定律：事情如果有变坏的可能，不管这种可能性有多小，它总会发生（Anything that can go wrong will go wrong）。根据墨菲定律的推论，任何一个环节都不是100%靠谱的。而对于云信这样的及时通讯云平台来说，核心功能保证99.99%的可靠性，也就是说，一年不可用时长要小于52分钟。因此容灾是必不可少的，需要把容灾做到方方面面。

首先，硬件资源都是冗余的，主要包括以下几点：

1. 服务器：双电源，双网卡bonding，系统盘raid10
2. 机柜：双电路接入，电源容量充足
3. 交换机：接入交换机堆叠并且单个交换机网卡bonding
4. 网络：核心路由器/核心交换机冗余
5. IDC：到各ISP的光纤要大于等于两条
6. 运维人员：应用运维、系统运维、DBA所有角色一主一备。

其次，整个应用架构的容灾，主要包含以下几个层次：

1. 接入层：云信使用了ospf+nginx做为了前端接入集群的负载均衡，所有nginx机器配置统一，upstream配置里添加了到后端服务器（大于1个）的健康检查
2. 应用层：各集群服务器无单点，并且保证服务器分布在不同机柜，不同交换机
3. 中间件：hbase本身就是分布式系统，其他中间件云信也做了高可用改造
4. 数据库：做为架构中最核心的一环，数据库的容灾设计也是最完善的。数据库支持主从同步，主库挂了之后，可以1分钟内自动切到从库，并且能够保证数据一致性

最后，你会问我要是IDC机房挂了怎么办？运维人员如何做到业务运行状况了如指掌？

这个时候，就需要一个强大、好用的监控系统了，监控是稳定性建设的基石；网易IM云使用网易自研的哨兵监控系统，意指向哨兵一样迅速发现并相应异常状态。我们使用哨兵做了以下几个维度的监控：

一、在监控完整性方面，自上而下做了业务监控、应用监控、基础监控，相关监控项类型如下

如某业务指标的监控趋势图

二、在监控有效性方面，通过哨兵监控系统，报警有效性达到90%以上

1. 监控数据采集、数据上报有效：数据采集失败、数据不能上报监控agent的监控采集器每天以报表形式发送到运维负责人，运维负责人进行修改
2. 报警发送方式（短信、邮件等）、报警接收人有效：每天统计短信、邮件及其他渠道的报警发送量，有异常变化（突增或者为0）以报表通知到运维负责人修改
3. 报警1分钟内到达：对自身发送器进行监控，消息堆积时及时处理解决

三、是哨兵的报警收敛功能。哨兵通过增加报警重试次数，集群报警合并等手段进行报警收敛，有效的避免了服务器数量级达到一定程度后，过多的报警会让人麻痹，进而忽略掉了真正有效的报警。

然而，虽然做了以上的工作来预防故障、快速发现故障，但故障的发生还是在所难免的，一个合适的故障处理流程能够有效的缩短故障处理时长。现在来看看云信的故障处理流程：

为了避免在遇到故障时，故障处理人员手忙脚乱，相关人员配合不到位，加长故障时长，会定期进行故障演练；验证业务容灾能力，监控报警是否可达，人员应急处理能力。

 

一个产品随着业务的日益复杂，应用系统会变的错综复杂。所以产品的运维标准化是必须的。有人会问，1个人运维10台服务器和运维1000台服务器，哪个更难一些？如果监控方式、部署方式无任何规律，1个人要支撑10台服务器就已经疲于应付；相反，如果所有的服务，都是同样的监控方式、部署方式，那么1个人运维1000台服务器，也是轻松愉快的。所以当IM云的服务器数量达到一定规模时，为了提高运维效率，解决运维管理混乱的难题，我们制定了线上运维规范，包括但不限于以下几个方面：

1. 应用部署规范：一台机器只部署一个应用；规范文件与目录结构，我们所有应用代码都在不同服务器的同一目录下，降低由于文件数量众多带来的运维风险，保证生产服务环境的整洁
2. 日志运维规范：对日志输出目录、命名、格式、分割和归档进行了规范性约束。应用相关的日志统一存放在当前应用目录结构下面的logs目录。能够方便而有效地进行应用服务的多维度监控、应用日志分析，以及提升故障发现率。
3. 代码发布规范：为减少代码上线引发的事故，提高代码上线效率。代码有固定的发布窗口，发布前必须进行发布审核，并且有完善且可执行的回滚方案
4. 监控和报警规范：云信所有应用包含基础监控和应用监控；以及云信自身的业务指标监控。报警内容清晰明确，报警接收人有效且保证在两人以上
5. 账号和权限规范：系统管理员使用root权限；代码发布使用公共账号权限；普通开发人员使用个人账号权限，个人账号权限不能在服务器上执行除家目录之外的写操作

 

无专职运维团队的企业，有哪些替代方案可以提高开发运维效率？

为了减少运维管理的成本，一定要做应用部署的隔离，有运维团队的公司会选择传统的虚拟化技术（kvm，lxc）对物理机进行初始化，现在业界比较流行的是物理机上运行Docker容器对服务进行隔离；也可以选择直接使用云计算公司提供的服务器资源。服务器的账号权限配置，软件环境配置等配置管理可以使用puppet来管理；代码部署方面可以使用gitlab+pipeline替代方案；监控系统业界比较常用的是开源的zabbix；持续集成通常使用jenkins；自动化运维工具比较流行的是使用ansible；提高应用的故障容错能力可使用Netflix Hystrix。以上部分工具，网易目前也同样在使用，而且很好用；关于工具的使用方式，google有比较成熟的文档，大家可以按需调研学习。

最后必须说一句：一个可运维、方便运维的产品，开发同学的投入功不可没。