1.1.运维平台之规划路线

整个平台划分为用户中心、资源中心、监控中心、运营中心、控制中心.
用户中心(ucenter): 

        涉及用户日常工作内容, 划分为工作流系统(workflow)和账户系统(accounts). 
资源中心(resource):

        复合CMDB系统, 硬件网络层CMDB, 服务应用层CMDB, 容器微服务化CMDB等三大类, 划分为硬件资产(device)、应用及服务(appservice)、网络资源(network)、基本盘(base)、成本统计(summary).

监控中心(monitor): 

        综合告警展示处理、告警配置、合并压缩平台. 划分为告警动态(alarm)、监控控制器(controller)、告警统一平台(uaplatform).

运营中心(analysis):

       数据报表展示,类似Grafana监控报表数据、hichart图表展示(grafana无法表达)、ELK日志分析日志.(需要花更多时间开发.)

控制中心(control): 

       代码发布、配置管理、任务调度, 暂时还使用ansible进行配置控制, jenkins控制代码发布, 无法做到页面自动化操作.(待开发) .

自问自答:

1.1 为什么写一系列文档?

       其一, 现在网上有很多成品平台介绍，功能齐全格调很高, 赞赞赞. 可是我也想做一个, 可是不知道怎么下手，分享一下吧.  其二, 原稿是2017年初运维平台规则稿, 这批文档会起到承前启后作用, 用以指导后期平台开发. 其三, 职业生涯工作总结, 一系列有道云笔记和平台记录, 算是留下一些足迹, 像我们这么专业的,当然要让别人也知道(哈哈,这很重要).

2.1 在夹缝中求生存 

      起初以为开发惨, 没想到运维杂工更惨(时刻背锅,时常待命), IT行业实在太激烈, 行业要求不断上涨,.

      其一, 来自培训机构的压力, 看到他们的全面教程内容让我汗颜, 批量化产出高中级架构师, 哪里还能坐得住.

      其二, 传统IDC CDN到现在阿里云、腾讯云、ucloud等云厂商升级, 它们已经开始售卖解决方案, 只要花钱就可以帮我解决很多问题, 作为被替代产品, 不能坐以待毙.

      其三, 要做一个具备开发能力的运维, 这是一些大厂头目的血泪控诉, 前辈的语录我永记在心. 随着工作深入,维护的业务复杂度和数量越来越多, 具备开发能力写些工具方便我们维护, 不用这么累. 哎.

3.1 往事不堪回首

     于15年维护七八个邮件服务项目,需要分析邮件日志, 进行邮件日志切割和收集,最后再通过页面进行查询和作图显示. 花了不少时间处理bootsrap、jquery、ajax等前端页面知识.
     于16年重写用户控制、一期workflow, 一期CMDB, 一期监控告警(对接zabbix) 两者关联.   CMDB例如硬件服务器表单 机架图 服务器(os层)kvm vmware 华为云等机器对接, 大约300台左右.  应用项目和服务管理.  zabbix api数据抽取rrd写入落地及自定义判断.  过滤报警.
     于17年 二级CMDB(微服务和容器管理), 二期监控告警(改用openfalcon),定义立体化监控树.  docker容器大量出现,微服务项目等管理,如何对接之前应用项目和服务管理. 改改改....    弃用zabbix,改用openfalcon+grafana作图,重写数据收集脚本. 改改改.....

4.1 本质是希望有用.

     日常运维工作内容一般有CMDB、代码发布、监控、故障定位和性能优化, 人类发展的历程其实也是工具升级的过程，此运维平台其实是管理工具的集合, 提高工作效率.  本质是追求运维平台的实用性，帮助解决和提升运维工作.

5.1 青春不在, 我的28岁

     当你认定某一件事的时候, 全心全意的付出, 灌溉青春的心血, 扫清一个个障碍, 未来的路还很长呢.

     回首向来萧瑟处 也无风雨也无晴.