一、如果现在给你 500 台服务器,你会如何管理?

个人认为无论机器规模多大,运维保障体系建设是不可缺少的一部分,当然也是最为重要的一部分,一个完整的运维系统必须包括以下几点:

  • 标准化
  • 工具化
  • 规范化
  • 流程化
  • 持续改进

1.1、 标准化

简单举例子为何要做标准化?例子:不同运维人员习惯安装软件的路径可能是不一致,A运维把软件安装在/www目录下,B运维喜欢或习惯把软件安装在/data目录上,没有标准化做支撑,要是不实现业务应用、服务流程等标准化制定和落地,将会导致日后日常管理和增加日后自动化落地难度,日积月累,这无疑导致日后成为一种隐患。

1.2、 工具化

为何要做工具化?

  • 1、大量重复性手工工作
  • 2、存在变更问题(出错、改漏等,特别是应急情况下)
  • 3、人员变更导致入门(培训、入门)门槛高
  • 4、……

做好工具化的收益?

  • 1、用脚本、自动化工具代替繁琐的重复性工作,提高工作效率
  • 2、降低出现问题概率
  • 3、某些操作发起人不局限于运维,减少运维工作,不经过运维处理,间接推动研发效率
  • 4、…….

1.3、规范化

不同运维人员写的脚本在所用的编程语言、编码、注释等方面存在巨大差异,当然最常见包括系统版本,主机名,IP不统一规范,间接或者直接增加日后程序部署、监控自动化难度,甚至影响故障排查时间。

1.4、流程化

这里简单举个例子,例如某开发变更某个版本,只在开发环境验证没有问题,但是没有经过测试人员在测试和预发布环境验证后直接上生产导致出现严重故障问题,此时要是没有严格的上线流程,将会直接给公司带来严重损失。

做好流程化我们可以根据ITIL中有十个重要的IT管理关键模块,包括配置管理、服务台、问题管理、变更管理、软件控制和发布、服务管理、容量管理、可用度管理、意外事件管理、费用管理制定相关流程化方案。

1.5、持续改进

顾名思义,这个就不多说了。

二、500台机器如何管理?

根据运维体系中标准化、规范化、流程化可推断出,运维项目管理流程包括

  • 立项阶段
  • 计划阶段
  • 运维实施阶段
  • 验收总结阶段

当然这里我们假设这里已立项成功,这里重点说明计划和运维实施阶段操作。

2.1 计划阶段

无论做啥也好,首先要做的是事前规划,整体架构规划,包括以下几点:

  • 主机类型(实体机、虚拟机(kvm、docker)、系统配置等)
  • 网络(开发、测试、灰度、生产等环境划分、中间件、db等网络划分)
  • 系统类型(centos、ubuntu等)
  • 整体架构图
  • 达到的收益

2.2 、运维实施阶段

实施阶段包括安装、安全、监控、维护等

2.2.1 安装

常规安装可以通过主流的自动化工具进行操作,例如Puppet、SaltStack、Ansible。

  • Puppet:基于Ruby语言编写。是最典型的C/S结构,需要安装服务端和客户端。
  • SaltStack:SaltStack和Puppet一样,也是C/S模式,需要安装服务端和客户端,基于Python编写,当然也可以使用ssh管理,但更多基于客户端方式。
  • Ansible:和SaltStack也是基于python开发,同时基于ssh管理,正常来说远程主机皆开通ssh,可通过key或ssh管理即可,客户端主机无需安装任何软件即可管理。
2.2.1.1 安装软件之前首选系统初始化(机器上架后必须做的事情,包括root权限、文件最大打开数、云服务器等swap分区创建,非必须开启服务等系列操作)
  • IDC机房机器安装系统后可通过ansible初始化

  • 云主机或者容器化机器初始化
    通过脚本或者工具化实现系统初始化后,打包成标准基础镜像,日后新增机器可直接引用

2.2.1.2 软件安装、升级、下架

tomcat redis mysql等安装、升级、下载只需要按照配置指定参数执行即可,例如tomcat安装

1
2
3
4
5
6
ansible-playbook -i Inventory/test  -u xxxx -b tomcat.yml \
-e exclude_jdk=1 -e JAVA_OPTS="-Ddisconf.env=test \
-server -Xms3072m -Xmx3072m -Xmn512m -XX:+UseConcMarkSweepGC -Dcom.sun.management.jmxremote \
-Dcom.sun.management.jmxremote.port=19988 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false \
-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -Xloggc:/www/web/drserviceGc.log \
-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -Xloggc:/www/web/droolServerGc.log" -e project=xxxx -e http_port=8080

软件包需要提前上传到内网仓库(也是为了保障网络稳定以及减少版本一致性问题)

2.2.2 安全

安全是互联网不可或缺的部分,一旦出现安全事故,影响可谓甚大。当然做好安全也不容易,不过我们可以从以下几方面入手:

  • 访问控制
  • 基线审计与入侵检测
  • 漏洞扫描
  • CI/CD安全
  • 数据安全
2.2.2.1 访问控制
  • 访问控制可通过网络隔离,主要基于以下:
    • a、网络层(各个环境隔离等)
    • b、系统层(开启防火墙,关闭不必要端口、禁止root登陆等)
    • c、应用层(数据库、缓存等只部署内网,禁止外网访问,权限访问最少化等)
  • 统一入口管理
  • 跳板机与VPN
    • a、 使用跳板机可实现运维入口统一化,达到集中访问控制和审计,当然可以选择购买商用或者开源(jumpserver)
    • b、生产机器只允许某些可信用段访问,运维人员在家远程必须通过vpn访问后才能操作
2.2.2.2 基线审计与入侵检测
  • 基线审计:可以避免某些入侵,同时也为达到国家等保要求
  • 入侵检测:云主机可通过云盾等相关检测,当然物理也可以通过安装相关安全产品,例如青藤云等
    2.2.2.3 漏洞扫描
    开源或者邀请第三方安全公司扫描
2.2.2.4 CI/CD安全

包括敏感信息泄露(脱敏处理、数据加密)、代码或镜像的安全审计(配置中心等)

2.2.2.5 数据安全,数据安全可谓重要,不久前才出现微盟系统被员工删库
  • a、访问控制,数据库等只掌握在dba手上,开发和测试无生产数据库权限
  • b、网络控制:数据库只开放需要使用的应用访问,其他机器无访问权限
  • c、备份:包括数据库数据备份、系统日志备份、应用备份(可参考/Script/Log_upload_oss)
  • d、代码泄露(github等,扫描脚本存放在/Script目录)
  • e、数据脱敏
  • f、数据库操作要经过审核平台,例如https://github.com/cookieY/Yearning
2.2.3 监控

监控是整个运维实施阶段,同时也是产品生命周期中最为重要的一环,事前及时预警利于发现故障,事后提供详数据方便排查定位问题。一个完整监控整体流程包括以下几个步骤:

  • 数据采集
  • 数据存储
  • 数据分析
  • 数据展示
  • 报警
  • 处理

监控指标包括以下几大点:

当然日常开源监控还是不少,主流监控软件包括以下:

  • zabbix
  • cacti
  • nagios
  • prometheus
  • 第三方监控(监控宝等)
  • 全链路跟踪监控apm(听云、skywalking、pinpoint等)
  • ……

常规告警路径可包括以下:

  • 钉钉
  • 邮件
  • 微信
  • 短信
  • 电话
2.2.4 维护

维护主要划分两大类,1、日常维护 2、故障处理

2.2.4 .1 日常维护

日常维护包括资产化管理、日志管理、软件变更、甚至资源扩缩容等:

  • 资产化管理,可通过cmdb平台管理,例如jumpserver跳板机自带相关功能,当然自研是不错的选择。
  • 日志管理:日常访问可通过主流的FLK,开发、测试人员查看日志通过平台查询,避免登陆服务器访问,同时也是避免部分安全问题。
  • 软件变更:日常迭代、紧急迭代可通过jenkins+ansible方式,开源发布平台瓦力、自研发布平台等,主流日常上线发布的几种方式可参考文章http://linuxops.xyz/2018/02/11/%E9%97%B2%E8%81%8A%E4%B8%80%E4%B8%8B%E4%BC%81%E4%B8%9A%E4%B8%8A%E7%BA%BF%E5%8F%91%E5%B8%83%E7%BB%8F%E5%85%B8%E6%A1%88%E4%BE%8B/
  • 资源扩缩容:顾名思义
    2.2.4 .2 故障处理
    日常故障处理可根据SLA(Service Level Agreement)服务水平协议流程处理,当然不同公司,不同业务都存在一套不同方案。当然离不开以下几大类:
  • 服务分类
  • 响应时效
  • SLA故障分类
  • 故障级别划分与定义
  • 应急团队建设
  • 故障升级机制
  • 故障处理流程
  • 个别还存在奖罚机制

最后又回到运维体系中的持续改进,互联网技术更新迭代速度可谓甚快,运维人员只有不断学习,跟上时代发展,才能不被淘汰。

Comments

2020-03-06