第一阶段： 使用ca的监控工具ehealth和spectrum ，配合直接开发脚本或工具完成绝大部分监控。
第二阶段：配合以上工具，使用python开发资产管理系统配合监控等，配合cmdb 逐步完善功能，开发专有工具完成was的自动部署。（by chengzq）
二、自动化运维体系中CMDB的设计
企业在自动化运维建设过程中，CMDB起到的支撑作用越来越大，CMDB已不在是传统意义上的资产管理，而更加侧重在IT资源的关联上，那么CMDB该如何设计才能够让IT资源联动起来，使运维发挥最大的价值呢？在实施CMDB过程中又该注意哪些问题？ 有哪些标准化的模型？
CMDB设计原则：1.CMDB内容的获取的方式和数据库的准确性。 如何通过工具及时有效自动完成cmdb内容的更新是后续维护cmdb准确性的重要方面。
2.配置流程管理： 配置流程和cmdb 的位置同等重要，就算cmdb 再怎么正确，如果没有适合公司自身的配置管理流程，也将会乱的一塌糊涂。
3.监控: 整个cmdb包括的东西很多：主机，存储，网络，web，中间件，db ，资产等等，需要监控的指标可多可少，也可逐步完善。
CMDB设计中痛点解决：
1.我们在进行CMDB建模过程中，由于缺乏经验和一些实际的参考，造成了粒度失真，模型建立不实用的问题。 针对这类问题，我们重新梳理了数据，将数据类型标签化，标准就是能够做到动态调整数据属性，还有就是我们重新梳理了各数据类型间的关系，也重新建立联系。
2.在数据录入CMDB过程中，遇到了数据来源多，有冲突的问题，以及数据准确率低、没有及时维护的情况。 解决这类问题，首先确定了CMDB地位，以CMDB为核心修改上下游数据；还要做好对CMDB数据的定期审计，利用策略和规则统一数据的更新来源。
三、自动化运维工具分析
在企业自动化运维体系的建设中，关于工具的选型。从宏观上，可将运维工具分为两大类：一类是IT运维监控和诊断工具。另一类是运维流程和配置的自动化工具。前者主要功能是对系统进行健康及安全合规检查、对重要IT设备实施监控及时报警，主要的工具有Zabbix、Nagios、 Tivoli Monitor等。后者主要功能是配置维护和管理以及系统日志的收集分析等，主要的工具有Puppet、 Ansible等。
自动化运维工具对比：
总体来说，自动化运维产品的功能特点都大同小异，也各有千秋，如Microsoft autopiolt、BMC bladelogic、HP-Opsware、IBM-Tivoli TEC、Puppet、Saltstack、Ansible这几款产品基本上都能满足企业自动化运维的需求，在选择上还是要根据自身系统需求来。下面，简述下这几种自动化运维工具的重点。
商业化产品的优势在于服务响应较快，运维自动化的数据模型较为丰富：
BMC bladelogic产品链较为丰富，在Server、Network、Database上都有自动化的产品，这些产品的侧重点是协助日常巡检、合规性检查、漏洞扫描等，是使用较多的运维工具。
IBM-Tivoli TEC除了有和Tivoli Monitor类似的监控功能外，但更加侧重与各类资源所产生事件的关联，有比较完善的分析模型。
Microsoft autopiolt侧重于大规模的web service自动化管理，业内使用得较少，但其设计思想及模型值得学习。
HP-Opsware是较早期的一款产品，后来被惠普收购，有较多的异构设备数据，覆盖范围较广，使用得也比较少。
开源产品的优势在于成本较低、易于上手和进行二次开发：
Puppet的侧重点在配置和管理系统的状态上，是目前成熟度高的工具，但个人认为，其在实时触发上稍微弱了点。
Ansible无需安装agent，主机通过SSH协议与监控对象进行通讯，从运维成本和维护性上来说，Ansible只要关注主机的运行状态即可，不会增加额外的运维成本。
SaltStack需要在master和监控对象主机上启动进程，并且需要检测该守护进程的状态，增加了一定成本，也造成了安全隐患。
选用自动化运维工具时要考虑的因素：
1.个性化开发：所选择的运维工具应该能够结合用户痛点和用户体验，应该能够实现各类监控对象的脚本定制开发。
2.易交付、易操作：自动化运维平台工具的选择本身就是为了提高运维的工作效率，因此尽量选择本身设计简单化并且易于交付的工具。
3.与监控平台互补：自动化运维工具的选择，要结合企业监控运维平台的架构规划，对监控平台进行有效支撑和互补，尽量自动化运维组件与监控组件集成，避免重复建设。
四、监控指标
自动化运维体系是一条集监、管、控一体的能力链，而其中监控告警是其中的基础环节，监控本身也需要形成对故障的采集、处理、发现、定位、解决的一个闭环。
监控指标如何定义和采集：对于自动化运维监控指标的定义，应该以ITIL为基础，而标准和规范的制定也要结合实际需求，可以按照：监控指标梳理-->监控指标阈值设置-->指标评估，这个流程进行。
可采集以下监控指标供参考：
1.系统资源层面可按照OS、DB、Middleware、Storage这几个大类来细分；
2. 应用层面的监控指标可细分为服务进程、交易数据、日志、作业调度、批处理、报文等。
3. 硬件层面可对服务器、网络设备、存储等设备监控如电源、温度、风扇从不同维度反应设备运行情况和质量。
4. 机房环控层面监控指标可以有机房温湿度、UPS电池及主机状态、空调等。
告警如何自动分析处理：
首先要有场景，把所有涉及到的设备、日志和业务指标都统一放到这个场景中（例如：xxxx应用场景：F5哪个端口，哪些Farm，主机的CPU、网络设备端口、日志关键字还有业务指标这些全部关联到这个场景），可以根据已有的规则就行报警，要是没有规则可以把报警信息全部列出来，分析完问题后，可以新增规则，根据这些规则就可以搭建智能报警和诊断分析模型。
这方面的产品大致原理是基于业务架构，结合数据流关系，通过触发条件和一些权重算法，将监控告警信息进行筛选分类，并按照告警触发场景的规则建立关联关系。
主流的监控产品如zabbix确实有个问题，在告警自动分析和规则设定上缺少完善的模型，这种情况，大部分还是要运维人工为系统增添分析策略包括一些脚本话的开发。
IBM TIviol产品还是不错的，开放平台与AS400平台，可以自发定制告警场景，构建告警策略，有日志分析平台，可根据你的日志分析需求，进行定制开发。其实你也可以自己搭建个规则处理平台，让告警平台提供一个接口，让所有的告警都发到你的规则处理平台，进行日志分析。
监控日志的分析：
日志分析是定位故障最基础的数据来源，对日志分析的整个流程，无非就是日志采集、存储、处理、分析及故障定位这几个关键步骤。
早期的自动化运维工具和一些监控工具大都是利用系统日志来触发告警，如今的自动化运维慢慢发展到要结合企业CMDB的建设，但CMDB中，日志同样也是重要的配置项。
如果仅仅要对日志分析，可考虑使用如ELK、Hadoop等一些工具，无论是使用工具与否，做好日志分析，还是要从以上所说的几个关键步骤来做：
日志采集上要注意对大量异构日志的采集方法，做到可持续高速即可。
日志存储上方面可借助一些非关系型数据库，保证存储能够水平扩展以及进行全文索引。
日志处理分析层面要结合相关的情景数据进行监控和关联分析，这也是快速定位故障的关键。
五、自动化运维潜在风险及应对措施
自动化运维工具上线后，在减轻运维工作量的同时也带来了潜在风险，尤其是在对系统进行大批量变更时，如安全基线防护、补丁升级等工作，一旦出现问题，往往难以补救。而除了上述风险，自动运维平台自身可能也存在漏洞，很容易被黑客攻击利用，出现灾难性的后果。
措施：
1.制定比较通用的校验架构，按脚本规范编写脚本利于脚本的校验；
2. 自动化运维的管理账号权限设置是否合理，该账号是否限定了权限，能不能通过该账号重启一些重要服务;
3. 有一些像配置核查的功能也能够帮助我们找出配置的不一致，这些校验功能帮助我们查出风险；
4. 自动化运维的交互界面，对一些高危动作，如执行rm *，是否做了二次提醒和密钥验证
5. 自己编写一些脚本各数据的脚本做成定时任务执行，定时的反馈信息；
6. 还有就是一些报表，报表也可以校验数据。不同的校验方法针对不同校验级别的数据和功能;
7. 需要使用自动化运维平台实施的大规模变更，是否有完善的审核制度。
8. 对于自动化运维平台本身程序版本、运维策略，是否验证过备份和恢复。
9. 还有限制一些风险的操作，例如：rm，像这些操作就要有审核机制或者其他管理方法。应对风险还有一种就是操作日志，可以通过操作日志进行方向操作能够找回数据。
六、自动化运维人员职责范围
企业实施自动化运维后，运维团队的职责应该进行细化，至少应有如下职责分工：
1.监控运维：由值班人员7*24小时，维护监控工具，做简单的故障处理和告警通知。
2. 系统运维：由系统管理员和DBA负责，处理系统级问题
3. 应用运维：由应用人员负责，补丁更新、优化应用程序，支撑业务开发
以上3类职责划分，是IT组织架构中较为常见的运维分工。但是，在自动化运维过程中，企业需要进行大量二次开发，来实现自动化运维的工具化、平台化、定制化。因此就需要运维开发这个角色，但目前该角色定义比较模糊，传统运维角色也存在一个转型的过程。个人认为，自动化运维也是一个能将运维人员从后台辅助角色转变为保障业务质量领导者的一个过程。
以上内容由社区专家willow根据社区会员交流活动梳理撰写
暂无评论内容