当你写了太多的数据库脚本,做了太多的自动化工作时,面对零散的新需求,尝试自动化时是否需要按使用频率提高自动化水平。
假如有个常见需求,数据库里删除一个大表里的部分数据,或者redis删除一个key
做为运维,需要考虑表有多大,是否要循环删除,删除条件是否有索引, redis的数据类型,如果是list,set,zset,需要考虑大小,是否需要循环清理
第一阶段,把循环删除动作写在一个循环脚本里。 运行脚本完成这次任务
第二阶段,把这个脚本做成通用性,以后再有类似的同样的需求,可以传参过来完成
第三阶段,判断各种情况,如,size,索引,类型 等。加上判断,以适应更多的情况
第四阶段,处理异常,加上各种异常时的处理或重试机制
第五阶段,做成页面化,可人性化的工具化,降低使用成本,目标是非dba的其他rd或运维人员可以简单使用
第六阶段,做成服务化,让目标受众除dba以外的人可以平滑(甚至无感知的)使用,将多个自动化系统集成到一个工具或一种服务
后面的就不清楚了,回想我记过的n多脚本和工具
10% 停在第一阶段
40% 停在第二阶段
20% 停在第三,四阶体贴
25% 停在第五阶段 (没错,就是这么喜欢搞页面化!)
5% 搞成业务都不知道后面有运维在支撑。
以
时间: 2024-10-11 11:28:58