关于自动化运维的思考-基线
DevOps几年前来看，基本都在提概念，这几年很多公司都在落地了，公司里每个自动化运维平台都不好意思。具体落实下来，做得好还是不好，水平也层次不齐。
我们不说自动化运维的意义，不讨论要不要做自动化运维。做是肯定要做，然后每个人都会有一堆的问题或者想法冒出来,why,how,when,有想法是好的，最大的问题是不知道问题在那里。
从我的理解来简单说说基线，一般来说会有如下的几个问题，基本涵盖了3W
我们来逐个说一下，不对的地方欢迎拍砖，我及时纠正。
需要做一个什么样的平台 1）在这里确切的说是DB自动化平台，因为目前的主要是数据库方向的。 2）后期怎么和其他部门的平台集成 先把DB层面的工作做好，做好了，你说的话才能让人觉得靠谱。 内部先达成共识，我们要一起做，不是你做吧，我用就好了。 3）业务价值和技术价值 短期内看只有技术价值，业务价值不大，但是成为平台后，或者有一些业务对接之后，价值才能发挥出来，就好比一辆车停在那里，还要付停车费，一旦跑起来了，业务价值远大于技术价值
谁来开发维护自动化平台 1）常见的瓶颈 开发不了解DB层面的业务，DBA对于开发的技能不够熟练，这是现状也是普遍现象。 2）DBA全员开发 能者多劳，每个人都要参与，所以我最近疯狂调研，搞开发，搞前端。 分工协作，等定好了之后，一起看看怎么分工，每个人能够承担一部分的功能，都能参与进来。 3）开发能力不够怎么办 先抛开技术，看看能做什么，需要做什么 --产品规划 前期的引导和技术预研 --技术选型和规划 由小及大，模块化实现 --避免好高骛远，眼高手低
使用什么技术架构
个人理解主要分为Python栈和Java栈，还有其他的比如go等等。 1）Python栈 前端WEB Bootstrap 后端WEB Django 任务调度 Celery + Redis Celery + MQ 批量操作 ansible 2）Java栈 前端WEB 后端WEB 任务调度 Jenkins opencron 批量操作 3）数据库 MySQL SQLlite 自定义ORM
是否需要agent
这个问题几乎无解，在有限的服务器规模怎么理解都没错。看你侧重于哪些考虑了。
有agent，数据采集和性能监控还是比较给力的。
没有agent,松耦合，部署快捷简单。
需要实现哪些功能
这个问题，如果是打算重构，重做，几乎每个人都会问，我们可以还个角度来考虑一下，自己问自己，这样也许也会有一定的收获。 1）可以反问，目前有哪些痛点 2）目前有哪些工作可以改进 3）希望今后做哪些方面的事情
可以借鉴的开源方案
目前可借鉴的方案还是蛮多的，而且国内目前开源的很多方案还是很不错的。开源项目可以参考最近火热的国内开源项目评选。
http://www.oschina.net/project/top_cn_2017?from=hometop
里面有很多非常不错的项目。