重新构建自动化运维平台的起步工作

每个公司随着业务的发展都会沉淀下来一套独有的问题处理流程，映射到技术线就会有一系列的解决方案。毫无疑问，起先都是基于人工或者脚本，在这个基础上逐渐沉淀成工具，然后像剥玉米皮一样把一些细节做裁剪，整合到平台里面，可以说这就是自动化平台的一个雏形了。

所以这里说的自动化平台其实不是自动化，只是做到了平台化。然后把流程打通，匹配特定的业务场景，能够达到更高的业务价值，自动化平台的优势和意义就显现出来了。

当然我这里所说的平台或者工具是理想中的状态，根据公司的实际情况，可能会有很大的差异或者准确说是差距，基于自动化平台的工作方式在互联网公司很受青睐，但是绝大多数公司都无法避免一个现实，那就是反复造轮子。

有的公司的技术沉淀还没来得及转化，还没有产生业务价值，核心开发人员就因为各种各样的原因离开这个团队或者离开公司了。这样的情况如果换下一个人来接手，很自然的，如果之前的沉淀较好，可以复用，否则就造轮子。有的工具或者平台是基于KPI的考量，或者说开发不了解具体的业务流程（比如DB方面的逻辑），运维人员（比如DBA）对于开发又不够了解，会有莫名的排斥，于是乎自动化平台还自动化不了，迭代了1.0,2.0,3.0，沉淀的那些技术很快就被败光了。

反之，情况就很喜人了，规范落实了，平台也有了，大家有更多的精力去填更多的坑，有更高要求的事情在等着我们。说实在的，这些都不能代表你很牛了，更不意味着你可以忽略这些，只能说明公司的管理和技术方向有了成效，你需要站在一个更高的角度。

所以自动化平台这件事情的意义自不必说，也不需要讨论是否应该做，肯定要做，关键是怎么做。确切的说是怎么落地，怎么开始。比如DBA团队，自动化平台对于DBA的要求会很高，比如你要回Python，Python的web框架有很多，每一个学习起来都需要周期，至于能不能融会贯通，那又是一个问题，所以不用凭空造轮子。而可以借鉴其他人的经验。这方面有商业和开源两类方案，商业的技术实现能很快落地，但是预算是资金不太好落地。开源的方案技术实现也能很快落地，还不需要其他的预算（自己开发也是时间成本和人力成本）。

开源方案我先选定了OpsManage,因为已经有了一些实现，可以基于这个很快迭代实现。

项目的地址是：https://github.com/welliamcao/OpsManage

如果要安装的话，还是需要花点功夫的，因为技术栈还算是比较全了。比自己从无到有高了n多个档次。

我做事情是结果导向，如果花了时间做一件事情，最后达不成目标，我会很焦躁。比如打算先部署这个项目，需要安装openssl-devel,结果我把自己的一套虚拟机环境给弄坏了，因为我强制删除了一个libcom的包，导致网络服务失效，系统无法启动（还好，是个虚拟机），另外一个是OEL,Oracle的Linux系统，我算是服了，OEL的版本就是1.4.2，而yum的安装需求是1.4.1，这种软件兼容性的问题搞得很上火，最后在晚上7点多重新初始化一套新的Linux部署安装。

里面的安装部署在文档里很详细了，我补充几点。

首先是pip,这是Python部署安装的神器，但是有时候网络不大好，我们可以直接连接到豆瓣的站点，后面批量安装非常流畅。新建一个目录.pip,然后在.pip目录下创建文件pip.conf

内容如下即可。 [global] index-url = http://pypi.douban.com/simple/ trusted-host = pypi.douban.com

文档里面提到的MySQL版本，其实用5.7也是可以的，而且还是推荐用新版本的，记得把sql_mode得临时设置为空，里面有些语句有潜在的SQL语法问题。

一波三折，自己也算是给自己一个小小的挑战，通过这个过程也对于整个系统的部署有了一个基本的认识。

登录成功的界面如下：

首页的样子，有点样子了，还需要继续补充。

后期在这方面要投入一些精力来不断完善。