变更是运维中最常实施的场景,大规模实施的风险控制也是我们所关注的点。在我们日常工作中,变更从发起需求到实施需要经过需求评估、方案制定与评估、变更方案验证测试、变更方案评审、生产实施几个阶段。自动化的实施在
传统企业有着很多的历史资产,人员能力、技术沉淀、设备资产等等,实施自动化运维的过程中会有各方面的困难,在新的环境驱动下需要一些转变。自动化运维不仅仅是一个工具平台,而是从组织、文化、管理和技术几个方面建立一个
运维工具多而且热说明大家的痛点都相同,只是在实践中采取了不同技术路线。对于Saltstack、Ansible我只是做了了解,并没有在实践中使用,但他们与一些商业化产品的思路是相近的:流程+脚本(或API)来实现手工操作自动化。选择适
应用运维涉及到各式各样的应用系统,不同技术体系的产品,我们在做一些标准化时采取封装嵌套方式。比如服务启停,针对Windows、linux、unxi不同平台都封装了标准的统一启停脚本,脚本内部嵌套各个子服务的启停脚本,将差异性内
这个问题很大,我们的实践中都是在不同阶段设计实施的。如果是从零开始,有一个设想,但没经过实践。我觉得监控、cmdb都是数据信息的管理,要实现数据的采集和管理,告警是数据分析产生的结果。所以是不是可以建立统一的数据采
自动化离不开脚本,脚本管理上可以集中式管理和分布式管理(放在目标对象上),集中管理的好处是能够统一控制版本,避免同一操作在不同目标对象上执行不一样版本的脚本。分布式管理能够确保自动化平台对目标对象失去管控情况下
自动化运维的场景来源于日常运维的实际工作中,对日常工作归类提取,比如应用发布、应用告警处理、节假日的巡检、关键日的保障,发布就是要进行应用程序的部署,告警处理就是对告警进行一些分析检查、服务重启、服务流控等,节
配置管理是很古老的话题,我们在做自动化时采取的是小而全大集权的模式。小而全是指各专业领域建立自己的配置管理子库,管理自己所需的数据。大集权是指配置项标准集中管理,专业领域横向依赖的信息集中管理,各子库作为数据
这个问题也是我们所遇见的问题之一,我们在实施过程中采取了采样分析,提取标准步骤及公共参数的方式。对共性步骤和参数抽象形成规范,增加个性步骤及参数管理的能力,利用少量的个性步骤来实现各个应用系统差异化的问题。
自动化发布的目标是将应用服务按需求正确部署,传统情况下我们都是通过登录主机操作,能实时查看到输出结果,这样的操作有既视感,让操作人员心安。而自动化后怎么监控的问题会在初期困扰运维人员,我们通过将日志准实时采集展
关于TWT使用指南社区专家合作厂商入驻社区企业招聘投诉建议版权与免责声明联系我们 © 2024 talkwithtrend — talk with trend,talk with technologist京ICP备09031017号-30