解决方案:自动、实时（采集站助手）

　　解决方案:自动、实时（采集站助手）

　　产品属性

　　产品介绍

　　百度收录自动推送，秒级感知，快速、自动化，全程无需人工干预，完美配合采集器；

　　使用场景：主要用于采集站点。当采集完成内容时，无论是静态页面模式还是伪静态模式，插件都能自动获取新存储的URL，并尽快推送到百度。，增加 收录 速率。

　　

　　（提示：虚拟主机无法运行插件）

　　[插件介绍]

　　1、当一个新的文章入库时，插件会自动感知并推送到百度。如果网站是静态页面模式（插件自动判断），会在推送前自动生成对应内容的静态版本。2、当日百度推送额度用完后，将自动暂停，直至次日恢复运营；3.想要手动发布文章时，如果开启了易优系统内置插件的推送功能，为了避免插件的重复推送，可以先停止通过插件管理中的“关闭程序”按钮；4、当插件推送连续出现多次错误时，会自动停止，您可以查看推送记录中的具体信息，并重启插件；5. 每次推送都会记录结果。为避免信息过多，插件在运行期间会自动清除3天前的记录；6、主机需要有服务器的控制权限，如ECS VPS主机等，并在php配置文件中打开（window）proc_open、exec；(linux) 壳执行；具体启用方法请参考插件使用指南；7、虚拟主机无法运行插件；具体启用方法请参考插件使用指南；7、虚拟主机无法运行插件；具体启用方法请参考插件使用指南；7、虚拟主机无法运行插件；

　　

　　【如何使用插件】

　　使用方法请参考插件使用指南；

　　请注意配置中的“百度推送接口”是指完整的百度推送url，不要只填写token

　　优化的解决方案:企业自动化运维落地的18个问题

　　前不久，我们分享了《》（作者：汪洋，点击标题查看），从五个方面对自动化运维做了介绍，其中不少是作者在一线互联网公司和传统行业的实践基于实践经验。进行了比较。如何将自动化运维整合为一个整体？如何从方法论的角度理解自动化运维，构建自动化运维？看完这篇文章，很多读者都有感触和感想。

　　之后，社区进一步组织线上交流，就社区成员提出的关于自动化运维实施的一系列具体问题进行讨论和解答。在此，由社区专家汪洋总结并撰写，以供读者参考。

　　1、自动化运维平台风险

　　Q1：自动化运维风控存在问题？

　　A1：

　　首先，所有自动化功能模块的本质都在代码层面，所以需要对自动化运维功能的代码进行测试，适合开发项目管理的流程；其次，对于一些删除或修改类的操作，需要考虑不能回滚的操作不能使用复查回滚方案（这其实和手动操作没什么区别）；三是灰度策略，可以用来验证自动化操作的结果是否与预期一致。如果一致，则继续，如果不一致，则需要回滚；四是监控配合，监控系统能及时发现问题操作，及时报警；五是权限管理，对能操作自动化运维平台的人，要求严格。权限控制；第六，通过api连接的系统需要有鉴权机制。

　　Q2：如何控制自动化运维平台的安全和权限？

　　A2：

　　个人认为应该注意以下几个方面：

　　一是通过在AD域中添加角色来控制网页操作的权限；

　　二是针对接口调用的情况要有相应的权限模块；

　　三是针对运维平台本身，防止平台擅自删除、修改生产资源；

　　四、定期对平台进行安全扫描，扫描平台自身漏洞；

　　2、自动化运维平台规划

　　Q1：自动化运维建设应该如何规划？

　　A1：

　　这个问题没有固定的答案。有几个步骤需要结合具体情况。最终目标是实现所有端到端的交付。一般来说，可以分为以下几个阶段：

　　一是解决最紧迫的痛点（这里一般指运维团队最大的痛点或其他团队提出的长期没有解决的问题）；

　　二是采集IT部门其他组（开发和测试团队）的自动化运维需求，并在内部进行调度；

　　三是在解决了前两点的问题后将点串联起来，消除点之间的人肉工作；

　　四是对初步形成的自动化运维链条进行检查补缺，形成正反馈链条。

　　Q2：在自动化运维建设中，如何制定标准化规范？

　　A2：

　　标准化需要结合企业的具体情况。一般来说，以下几个方面需要标准化（供参考）。一是server pod的标准化，一个pod可以放在多台机器上，如果连接的话；另一个是物理机模型，无论是计算密集型、内存密集型、io密集型还是存储型，都需要将不同厂商的模型归纳为几种标准机型；第三，操作系统标准化，包括操作系统版本、操作系统内核参数、盘符路径等；四、软件安装标准化，包括软件版本、安装路径、日志路径、日志切割、参数调优等；五、软件部署标准化，

　　

　　Q3：在实际运维环境中，我们如何制定一套完整的自动化运维管理解决方案来支持自动化运维工作？

　　A3：

　　制定自动化运维计划，需要考虑以下几个方面：一是明确制定自动化运维计划的目的，是制定自动化运维计划的指导思想；第二，明确自动化运维计划的服务对象角色；自动化运维过程中不同对象角色的出发点是什么；四、明确自动化运维计划实施过程中需要注意的安全问题（如权限细化、调用鉴权、运行审计等）；五是通过调研的方式进一步了解其他同事的运维需求；第六，规划中明确将建设自动化运维平台的规划分为几个阶段，需求分散在这些阶段；七、明确自动化运维方案将实施为自动化平台运维的具体方式（自研、外包、或基于外包的二次开发）；八是在自动化运维计划中明确平台使用过程中的正反馈流程。明确将自动化运维方案实施为自动化平台运维的具体方法（自研、外包、或基于外包的二次开发）；八是在自动化运维计划中明确平台使用过程中的正反馈流程。明确将自动化运维方案实施为自动化平台运维的具体方法（自研、外包、或基于外包的二次开发）；八是在自动化运维计划中明确平台使用过程中的正反馈流程。

　　Q4：自动化运维的建设需要分几个阶段进行？应该如何进行规划？

　　A4：

　　这个问题没有固定的答案。有几个步骤需要结合具体情况。最终目标是实现所有端到端的交付。一般来说，大致可以分为以下几个阶段：一是解决最紧迫的痛点；第二，采集IT部门其他组（开发和测试团队）的自动化运维需求；三、解决前两点问题解决后，将所有点串联起来，消除点之间的人为工作；四是对初步形成的自动化运维链条进行查漏补缺。

　　3. CMDB数据问题采集

　　Q1：CMDB建设过程中如何实现自动发现？

　　A1：

　　CMDB的自动发现一般基于以下几种方式：一是调用目标软件的api接口获取相关信息，如vmware、emc存储等；另一种是使用某种协议（公共或私有协议），比如snmp来获取相关的配置信息；三是在宿主机上执行命令并处理结果，比如在宿主机上抓取中间件的信息；四是通过执行中间件的命令获取信息。自动发现一般通过上述方法的结合来达到自动发现的目的。

　　Q2：自动化运维建设中如何选择CMDB自动采集数据？

　　A2：

　　这个问题有点大，具体到数据采集点。为了全面采集CMDB数据，需要考虑两个方面。一是CMDB采集工具本身的自动化采集能力，二是有些数据需要通过流程进行监督和人工录入，比如业务系统的名称，里面的人业务系统运维负责人、开发负责人、测试负责人在自动采集工具中不可用，需要人工维护。如果需要搭建CMDB系统，有3个思路。一、完成自研，需要团队有很强的研发能力，有人对ITIL流程有深入的了解，自动化的采集 实施缓慢；二是直接购买业务 CMDB产品的优势是可以快速上线，具有很强的自动化采集能力。缺点是有些需求可能无法直接满足，需要定制开发。还是要自己实现，好处是有基本的可用框架。

　　Q3：如何同时保证CMDB数据的实时性和一致性？

　　A3：

　　实时性：保证CMDB数据的实时性需要依赖CMDB工具的自动化采集能力；

　　一致性：一致性需要流程控制和定期的数据审计操作，可以借助CMDB平台的能力来实现。

　　4、运维工具的选择

　　Q1：选择自动化运维工具需要考虑哪些因素？

　　A1：

　　在选择自动化运维工具时，笔者认为应该考虑以下几个方面：一是自动化运维工具的成熟度，即行业内的受众。不管是商业的还是开源的，都可以从这个角度来评价；二是自动化运维工具的功能能否满足运维要求；三是如果选择开源的自动化运维工具，还要考虑该工具的技术栈是否与公司人员的技术栈相匹配；四是自动化运维工具在安全性方面是否有很好的支持；五是自动化运维工具在工作过程中对主机性能的影响，特别是在并发量大的情况下，运维工具平台本身的服务端压力；第六，还要考虑选择的自动化运维工具是否满足公司后续技术栈的开发需求。

　　Q2：自动化运维建设中运维工具的规划与集成？

　　A2：

　　您好，您提到的情况确实是目前大部分公司都存在的问题。在我看来，造成这个问题的主要原因是前期缺乏宏观层面的统筹规划，各组织各司其职，没有统筹管理。那么如何应对现有的情况呢？在我看来，需要做以下几件事：首先，需要建立一个治理组，包括每个现有系统的所有者，然后由一个leader担任组长；第二，每个系统的所有者要说明系统最初构建的背景，系统现在可以解决哪些问题，哪些问题还没有解决；三是根据第二步的讨论结果进行合并工作，合并可以合并的系统，以及不能合并但有重叠功能的，可以打通数据，进行统一执行输出；第四，管理团队需要对后续的新系统进行统一规划，避免类似事件再次发生。

　　

　　Q3：如何选择自动化运维产品？

　　A3：

　　自动化运维涉及面很广。一般来说，它包括资源自助、监控、调度任务和应用发布。那么在选择产品的时候需要考虑以下几点： 一是梳理自己的痛点，也就是目前最需要解决的问题是什么；第二，计划，你计划在3年内达到什么效果；三、所选自动化运维平台的产品成熟度（同行业有多少案例）；四是自动化运维平台的开发程度，是否可以进行二次开发或支持功能扩展；五是平台的技术框架是否为主流技术框架；

　　5. 其他

　　Q1：AIOPS与自动化运维的关系？

　　A1：

　　aiops 是自动化运维的一部分。这是近几年AI大行其道后兴起的一个领域。自动化涉及运维操作的方方面面。aiops 只是将 AI 技术应用到现有的 ops 平台上。数据技术是一起使用的。

　　Q2：当前的一些先进技术，比如云计算和大数据，是否可以结合起来让自动化运维更加高效和智能？

　　A2：

　　结合云计算能力，可快速扩展自动化运维平台的服务能力；结合大数据和人工智能技术，自动化运维平台可以提供更强大的功能，这也是很多人开始关注的aiops。风险需要人工审核。例如，基于大数据和人工智能技术对某种行为进行自动操作，当你第一次使用该技术时，需要手动复核，划定优先级和重要性级别。对于低优先级和低重要性可以自动处理。

　　Q3：传统企业和互联网企业在运维方面有什么区别？

　　A3：

　　传统行业与互联网在运维方面的区别在于：首先，运维是编码的。传统行业的运维更多是在人工运维平台甚至纯人工操作的层面上，而互联网更多的是通过代码进行运维，避免人工操作，这也是互联网企业需要开发能力的原因用于操作和维护；第二个是护理点和线性化。传统行业运维在不同时期购买了大量的运营。维护平台，每个运维平台都是独立离散的。互联网的运维平台大多是线性的，可实现端到端交付和串联；第三，对人员的要求不同。互联网公司无论运维是什么级别，都需要一定的开发能力或者对一些原理的深入理解（Code级别），而传统行业更多的是操作级别的要求。

　　Q4：自动化运维平台如何更贴近业务？及时发现已经发生的风险以及将要发现的风险？

　　A4：

　　为了让自动化运维更贴近业务，首先需要采集业务的自动化运维需求，利用平台满足业务的自动化运维需求。这是要完成的第一步。其次，要对业务系统进行监控。在此基础上，需要与业务沟通风险指标，将风险指标量化，配置到自动化运维平台的监控系统中，利用平台的监控能力进行724小时监控。当指标达到报警阈值时，会通过短信、微信、邮件等方式发出报警。最后，

　　Q5：传统IT运维与自动化运维有什么区别？

　　A5：

　　之所以会出现*敏*感*词*化运维，其实是因为这些解决方案都是基于点的问题。它们都将每个点的手动操作变成了脚本化或基于平台的自动动作，这些动作是离散的，本质上仍然是一个点，不是一条线，也不是一个面。真正的自动化运维是实现端到端的自动化交付，也就是从开发到测试再到运维的全环节自动化，免去人工操作。比如创建一个redis中间件，*敏*感*词*的做法是： 1.在虚拟化平台上申请一台机器；2.为网络分配IP地址（手动）；3.通过另一个脚本初始化机器（手动执行脚本）；4. 通过安装脚本安装redis（手动安装）；5. 以电子邮件或人工方式通知申请人。自动化的做法是：提交创建reids的需求，自动化平台做完所有的事情，然后调用email接口通知申请者。

　　Q6：自动化运维自主研发的边界如何界定？不仅可以自主可控，还可以充分发挥和提高员工的能力？

　　A6：

　　自主控制有两种思路，一种是完全自研；二是基于采购自动化运维平台的二次开发。第一种情况，要求公司人员具备一定的开发能力。优点是需求可以与当地需求充分结合。缺点是人员要求比较高，平台组建速度慢；对于第二种情况，需要购买平台技术栈。实现与公司开发或运维人员相匹配的平台，要求平台开源代码或提供丰富的二次开发接口。优点是可以快速满足至少80%左右的需求，缺点是需要理解现有的代码。不够灵活。

　　以上内容由社区专家汪洋根据社区活动内容整理而成。汪洋，*敏*感*词*公司信息技术部基础架构架构师。在IEEE Computer发表论文并撰写专利“一种数据保护方法、设备和数据保护系统”（专利号：2.8）。曾就职于蚂蚁金服金融云部和某商业银行IT信息技术部。专业领域：云计算IAAS和PAAS平台规划建设基础设施高可用、高性能和容灾设计、容器化（docker）和微服务等。

　　相关文章：