对自动化运维系统的几点思考

为什么80%的码农都做不了架构师？>>>   

序

    在公司里开发自动化运维系统已经1年多了，从开始的浑浑噩噩到目前的有点自己的想法路有段不短的变迁过程，这里小结一下，和有兴趣的人分享。
    偶算半个java码农，开发方法不是最好的，一般的做法是用最通用大路的技术方案解决用户提出的需求，优点是实现较为简单快速，缺点是性能不够高效。

变革历史

第零代：单纯的展示主机发送过来的定制信息
    我接手的是一个简单的、由php前台+python版agent组成的小应用，作用是按照主机ip的不同，展示每个主机的信息块，包括硬件、os信息、系统状态等，虽然简陋，却是以后开发的基石。

第一代：基于ssh2框架的web前台+socket接收服务端+oracle数据库
    这个是我和同事用java开发的初版，想法是用socket接收各个agent投递过来的xml密文，存入一个独立的数据表，在定期把表里的数据更新到对应的其他数据表里。  

第二代：增加Redis缓冲层+quartz定时任务+jbpm工作流+nio版socket服务端（后来换为zmq版）
    为了解决性能瓶颈，用nosql的特性缓冲了高并发的请求，用消息总线zmq解决了接收服务端的高负载问题

还在研究的第三代：用ldap将主机信息查询与数据库脱钩

自动化运维的功能划分

1. 通用基本的系统平台：
   用户（组）-角色-权限与模块（菜单）-功能-访问url的权限体系
   系统数据字典
   内部消息（邮件）的发送与提示
   附件上传下载接口
   定时任务组件
   工作流组件
   系统日志：用户登录、操作
   可能有的：与第三方系统整合，比如单点登录（CAS）、财务软件、报警处理平台、大数据运算分析系统
   
2. 资源库：
   机房-机柜的位置信息
   网络资源：IP池、预警阀值定义、交换机流量
   真实服务器资产信息
   逻辑主机信息：注册、心跳、分组、系统状态（图表）
3. 投递信息映射数据库对应记录
   解析字典
   最新投递信息（redis层）
   历史变更记录
   相关的定时任务
   
4. 远程控制：
   基于ssh|rdp的远程操作
   远程定时任务的发布与回报
   
5. 服务配置的模板定义和推送
   软件源（插件库）管理与发送器的对接
   服务配置模板维护
   针对各种业务的节点列表和关联配置文件生成与推送
6. 信息采集与分析
   

转载于:https://my.oschina.net/yygh/blog/119408