不知道下面场景是不是大部分期货公司的情况：
服务器崩了，要装一台新机器，用的kickstart光盘或u盘……亦或是，更原始的人肉下一步下一步？
什么，你应用所依赖的rpm包是上传到Linux里，一个个安装的？不是吧……
哦，用的yum的安装方式，但是竟然是用的mount挂载光盘或iso的方式，没有内网yum repo么？
监控，竟然还在用老掉牙的Hostmonitor……
系统出现问题了，要一条条的去查日志，对于日志，有没有一个更好的一个方法，做汇总、过滤、搜索？如何对日志做一个更好的监控？
虚拟化，用的VMware ESXi或者好一点用VMware vCenter, 但是，你有没有被VMWare收取“保护费”呢？
以上的一些问题，在互联网时代，已经有很多比较好的技术可以解决了。
本文下面从互联网的技术角度，来尝试解决上述的一些问题，如有浅薄之处和纰漏之处，请广大期货圈技术朋友留言点出。
注：以下技术并不是完全掌握，个人只能算刚入门的毛小子，尤其是Elastic Stack和OpenStack……但是，我会努力朝这个方向去学习和研究。
目录：
- Cobbler —— Linux自动化安装、内网yum repo
- Ansible —— 自动化部署
- GitLab —— 版本控制
- Zabbix —— 监控
- Elastic Stack —— 日志监控
- OpenStack —— 企业私有云解决方案
Cobbler —— Linux安装、内网yum仓库
Cobbler实现了各种版本Linux的自动分区、系统安装、包安装，还可以作为内网的yum源使用。
Cobbler，底层基于DHCP、PXE、TFTP、HTTP、Kickstart等技术的融合，来提供一个对外自动安装操作系统的服务。
当和Cobbler同网段的服务器启动，首先出现的界面是这样的：
上面那个图是我做实验的时候的菜单图，当然也可以根据不同操作系统和不同交易系统的不同应用来做不同的ks配置。
菜单和系统完全可以自定义，读秒时间也可以自定义。每一条菜单对应的就是一个kickstart的.ks文件（指向对应的镜像），如果有不同的系统、分区、安装包，都可以写为一个不同配置的ks文件。举个菜单的例子，可以根据不同的操作系统、交易系统、组件，来定制化安装界面，例如这样：
(local)
OL6.8-CTP-db
RHEL6.8-CTP-trade
RHEL6.8-CTP-risk
...
OL6.8-Femas_2.0-db
CentOS6.8-Femas_2.0-front
...
RHEL5.10-Sunguard_v6-sybase
RHEL5.10-Sunguard_v6-app
...
注：此处RHEL指的是Red Hat Enterprise Linux, OL指的是Oracle Linux
另外我们可以把Cobbler作为一个本地yum仓库，可以直接从网上每天同步yum源，而内网服务器，可以把yum的baseurl指向cobbler，举个CentOS7 的yum repo文件的例子，192.168.100.222就是cobbler所在的服务器地址：
cat /etc/yum.repos.d/centos7-all-in-one.repo
[centos7.4-base]
name=centos7.4-base
baseurl=http://192.168.100.222/cobbler/repo_mirror/centos7.4-base
enabled=1
priority=99
gpgcheck=0
[centos7.4-updates]
name=centos7.4-updates
baseurl=http://192.168.100.222/cobbler/repo_mirror/centos7.4-updates
enabled=1
priority=99
gpgcheck=0
[centos7.4-extras]
name=centos7.4-extras
baseurl=http://192.168.100.222/cobbler/repo_mirror/centos7.4-updates
enabled=1
priority=99
gpgcheck=0
[centos7-zabbix-3.4]
name=centos7-zabbix-3.4
baseurl=http://192.168.100.222/cobbler/repo_mirror/centos7-zabbix-3.4
enabled=1
priority=99
gpgcheck=0
[centos7-gitlab-ce]
name=centos7-zabbix-ce
baseurl=http://192.168.100.222/cobbler/repo_mirror/centos7-gitlab-ce
enabled=1
priority=99
gpgcheck=0
# 省略其他yum repo。。。。
tips: 无论是ks文件，还是repo文件，都可以用git来做版本控制，可以随时更改和添加，关于git，后面再说。
部署好Cobbler服务之后，每当我们添加一台新的服务器，需要安装操作系统的时候，只要做好raid，开机，选择对应的操作系统菜单，就可以一键自动安装了。
Ansible —— 自动化部署
Ansible是一个基于Python研发的自动化部署工具，实现了实现了批量系统配置、批量程序部署、批量运行命令等功能。利用Python的jinja2模板引擎，可以定义配置的jinja2模板，可以实现同一组类型应用根据主机的参数不同来进行变量替换。
在Ansible中，简单的一些批量操作可以使用Ad-Hoc，例如批量升级某个补丁包；还可以使用Playbook功能，实现更复杂的安装和配置，例如交易系统内的一个复杂组件的配置。
Playbook使用yaml语法，非常便于书写。
Ansible最大的一个好处是agentless，无需安装客户端，直接通过ssh来连接，并操作相应的服务器。对于大部分期货公司来说，几百台服务器，用Ansible就足够了。当然，Ansible也支持客户端模式，只是并没有无客户端模式那么好用。
我们可以把交易系统各种组件定义成一个个roles，然后书写Playbook去实现各种组件的自动配置和部署功能。
当然，应用和配置，我们也需要做到版本控制，当升级组件时候有问题了，可以更好回滚。
tips: 如果是上千台服务器的话，这时候Ansible就有点捉襟见肘了，这时候SaltStack更好用一些，不过期货公司暂时没有这么大量的服务器需要批量操作，所以SaltStack暂且不说。
Zabbix —— 监控
Zabbix是目前企业中，使用量最高的监控软件了。（不要再用HostMonitor了……真的）
Zabbix可以像Hostmonitor一样设定各种监控，并可以设定触发器阈值，可以自定义各种图表：
并且还可以选择一些重要监控，放到Dashboard里进行大屏展示，并且还可以实现slide show(幻灯片切换），有好几套界面风格可供选择（个人很喜欢上图中的Dark主体）。
当然，还有更炫酷的大屏展示，那就是……Grafana（炫酷到没有朋友）：
还可以可以自定义邮件报警、短信报警、微信报警等功能：
GitLab —— 版本控制
Git工具，在互联网公司所用甚广，例如著名的”程序员大型同性社交网站“——GayHub，哈哈，玩笑一下，是代码托管网站GitHub，在国内，也有类似的网站，如Coding.net，都是比较流行的远程Git仓库。
当然，很多期货公司可能没有开发，用不上这个东西。但其实不然，运维也可以很好的使用。
而在企业内部的话，为了方便建立私有Git仓库，一般会使用GitLab，其实在程序员中用的比较多，而对于运维人员来说，也是值得去研究的，与其他工具结合使用，可以做到很好的版本控制。
如图，我们可以建立起各个交易系统的Git仓库，在应用和配置方面做到更好的一个版本控制功能，在系统升级和回退的时候，有一个更快速和高效的方法。
在多组件升级的时候，Ansible结合GitLab,可以做到一个快速升级、快速回退。在期货公司，在有了夜盘之后，很多时候都是在下午收盘后，晚上开盘前做升级操作，时间特别紧张，如果是能做到一个快速回退，那么升级的风险度可以降到很低的程度。
当然，升级和回退不是简单的加减法，这就需要运维人员编写Playbook的时候，需要考虑到方方面面的问题。
另外GitLab可以更好的来管理技术文档。系统的操作，还有自己的一些Idea，都可以在GitLab上写出来，GitLab同GitHub一样，支持markdown语法的写作。
甚至用来管理技术合同都可以。把合同的扫描件，做一个分类归档，放在GitLab里，可以按照日期或tags进行查找，方便快捷（当然这个要设为私有仓库啦）。
Elastic Stack
在期货公司组件出现问题的时候，我们需要一个个手工的去排查日志，导致定位问题非常慢。有没有一个日志汇总的工具，可以做聚合、索引、搜索呢？使之查询更快？
有的，Elastic Stack。
Elastic Stack的框架：
beats：⽤于轻量级⽇志采集，⽀持⽂件采集，系统数据采集，特定中间件数据采集等
logstash：⽤于⽇志结构化，标签化，⽀持DSL⽅式将数据进⾏结构化
elasticsearch：⽤于提供⽇志相关的索引，使得⽇志能够有效的检索
kibana：⽤于提供⽇志检索，特定metric展示的⾯板，⽅便使⽤的UI
x-pack：⽤于监控与预警相关的组件，可以集成到es中，kibana有特定的⾯板⽤于展示UI
对于期货公司的日志量来说，基本都不用做分布式，一台足够承担，如果日后需要扩展，可以直接横向分布式扩展，非常方便。
稍微说一下虚拟化
很多公司会用VMware ESXi，偶尔有公司会去用VMware vCenter 私有云，但随着国家开始正版化的推进，出于成本考虑，更多的公司开始使用开源软件。如KVM，甚至是OpenStack私有云方案（少数研发能力较强的）。当我们还在感叹OpenStack的部署和二次开发很难的时候，互联网已经转向了Docker和Kubernetes，各种应用秒级部署……
总结：
在一个证券和期货群里，很多做了10来年的老运维说道，现在技术发展越来越快了，再往后，自己不走管理层，可能就是落后淘汰的那一批了……时代总是在变化的，真心希望我们不要成为被DevOps或AIOps淘汰的那一批人。
DevOps发展起来后，第一批失业的，可能就是公司里的初级甚至中级运维……当大部分底层工作，都自动化了，初中级运维的危机也就来了，而那时候，只能选择去学习新的知识，新的技术，要么只能被淘汰。 —— 传统运维之殇
个人一点小分享，仅供茶余饭后谈资。个人也是刚学互联网的一些技术。
另外，本人最近在找工作，有合适的公司可以介绍给我，万分感谢。